Re: [FFmpeg-devel] [PATCH] lavfi/framequeue: avoid empty structs.

2016-12-18 Thread Nicolas George 
Le nonidi 29 frimaire, an CCXXV, Nicolas George a écrit :
> Fix compilation on MSVC.

Forgot to write in the comment beore sending: this is obviously
untested.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavfi/framequeue: avoid empty structs.

2016-12-18 Thread Nicolas George 
Fix compilation on MSVC.

Signed-off-by: Nicolas George 
---
 libavfilter/framequeue.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/framequeue.h b/libavfilter/framequeue.h
index 558ea3..f5ef744638 100644
--- a/libavfilter/framequeue.h
+++ b/libavfilter/framequeue.h
@@ -44,6 +44,7 @@ typedef struct FFFrameBucket {
  * It is currently empty.
  */
 typedef struct FFFrameQueueGlobal {
+char dummy; /* C does not allow empty structs */
 } FFFrameQueueGlobal;
 
 /**
-- 
2.11.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] Fixing 3GPP Timed Text (TTXT / tx3g / mov_text) encoding for UTF-8 (ticket 6021)

2016-12-18 Thread Erik Bråthen Solem 
Accidental duplicate of patch 1818.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-devel, 1/1] libavcodec/movtextdec.c: fixing decoding for UTF-8 (ticket 6021)

2016-12-18 Thread Erik Bråthen Solem 
Done. It was assigned its own patch number (1860), so I am changing the state
of this one to "Superseded".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/1] Updated version of patch 1840 (ticket 6021)

2016-12-18 Thread Erik Bråthen Solem 
Between testing and patch generation a character was deleted by mistake, which
broke the patch. This updated version fixes this.

Original patch description:
Character offsets were interpreted as byte offsets, resulting in misplaced
styling tags where multibyte characters were involved. The entire subtitle
stream would even be rendered invalid if such a misplaced tag happened to
split a multibyte character. This patch fixes this for UTF-8; UTF-16 was and
still is broken. These are the only supported encodings according to the spec.
---
 libavcodec/movtextdec.c | 95 +++--
 1 file changed, 53 insertions(+), 42 deletions(-)

diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index 7b5b161..4cffacf 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -328,6 +328,7 @@ static int text_to_ass(AVBPrint *buf, const char *text, 
const char *text_end,
 int i = 0;
 int j = 0;
 int text_pos = 0;
+int text_pos_chars = 0;
 
 if (text < text_end && m->box_flags & TWRP_BOX) {
 if (m->w.wrap_flag == 1) {
@@ -338,50 +339,59 @@ static int text_to_ass(AVBPrint *buf, const char *text, 
const char *text_end,
 }
 
 while (text < text_end) {
-if (m->box_flags & STYL_BOX) {
-for (i = 0; i < m->style_entries; i++) {
-if (m->s[i]->style_flag && text_pos == m->s[i]->style_end) {
-av_bprintf(buf, "{\\r}");
+if ((*text & 0xC0) != 0x80) { // Boxes never split multibyte characters
+if (m->box_flags & STYL_BOX) {
+for (i = 0; i < m->style_entries; i++) {
+if (m->s[i]->style_flag &&
+text_pos_chars == m->s[i]->style_end)
+{
+av_bprintf(buf, "{\\r}");
+}
 }
-}
-for (i = 0; i < m->style_entries; i++) {
-if (m->s[i]->style_flag && text_pos == m->s[i]->style_start) {
-if (m->s[i]->style_flag & STYLE_FLAG_BOLD)
-av_bprintf(buf, "{\\b1}");
-if (m->s[i]->style_flag & STYLE_FLAG_ITALIC)
-av_bprintf(buf, "{\\i1}");
-if (m->s[i]->style_flag & STYLE_FLAG_UNDERLINE)
-av_bprintf(buf, "{\\u1}");
-av_bprintf(buf, "{\\fs%d}", m->s[i]->fontsize);
-for (j = 0; j < m->ftab_entries; j++) {
-if (m->s[i]->style_fontID == m->ftab[j]->fontID)
-av_bprintf(buf, "{\\fn%s}", m->ftab[j]->font);
+for (i = 0; i < m->style_entries; i++) {
+if (m->s[i]->style_flag
+&& text_pos_chars == m->s[i]->style_start)
+{
+if (m->s[i]->style_flag & STYLE_FLAG_BOLD)
+av_bprintf(buf, "{\\b1}");
+if (m->s[i]->style_flag & STYLE_FLAG_ITALIC)
+av_bprintf(buf, "{\\i1}");
+if (m->s[i]->style_flag & STYLE_FLAG_UNDERLINE)
+av_bprintf(buf, "{\\u1}");
+/* (No need to print font style if equal to default?) 
*/
+av_bprintf(buf, "{\\fs%d}", m->s[i]->fontsize);
+for (j = 0; j < m->ftab_entries; j++) {
+if (m->s[i]->style_fontID == m->ftab[j]->fontID)
+av_bprintf(buf, "{\\fn%s}", m->ftab[j]->font);
+}
 }
 }
 }
-}
-if (m->box_flags & HLIT_BOX) {
-if (text_pos == m->h.hlit_start) {
-/* If hclr box is present, set the secondary color to the color
- * specified. Otherwise, set primary color to white and 
secondary
- * color to black. These colors will come from 
TextSampleModifier
- * boxes in future and inverse video technique for highlight 
will
- * be implemented.
- */
-if (m->box_flags & HCLR_BOX) {
-av_bprintf(buf, "{\\2c%02x%02x%02x&}", 
m->c.hlit_color[2],
-m->c.hlit_color[1], m->c.hlit_color[0]);
-} else {
-av_bprintf(buf, "{\\1c&}{\\2c&}");
+if (m->box_flags & HLIT_BOX) {
+if (text_pos_chars == m->h.hlit_start) {
+/* If hclr box is present, set the secondary color to the
+ * color specified. Otherwise, set primary color to white
+ * and secondary color to black. These colors will come 
from
+ * TextSampleModifier boxes in future and inverse video
+ * technique for highlight will be implemented.
+ */
+

Re: [FFmpeg-devel] [PATCH] lavfi/atempo: Avoid false triggering an assertion failure

2016-12-18 Thread Marton Balint 


On Sat, 17 Dec 2016, pkoshe...@gmail.com wrote:


From: Pavel Koshevoy 

Steps to reproduce:
./ffmpeg_g -f s16be -i /dev/null -af atempo=0.5 -y /tmp/atempo.wav
---
libavfilter/af_atempo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 59b08ec..a487882 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -914,8 +914,8 @@ static int yae_flush(ATempoContext *atempo,

atempo->state = YAE_FLUSH_OUTPUT;

-if (atempo->position[0] == frag->position[0] + frag->nsamples &&
-atempo->position[1] == frag->position[1] + frag->nsamples) {
+if (atempo->position[0] >= frag->position[0] + frag->nsamples &&
+atempo->position[1] >= frag->position[1] + frag->nsamples) {
// the current fragment is already flushed:
return 0;
}


Thanks, this indeed fixes the assertion I came accross. Do you want me to 
apply?


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] libavcodec/movtextdec.c: fixing decoding for UTF-8 (ticket 6021)

2016-12-18 Thread Michael Niedermayer 
On Sun, Dec 18, 2016 at 08:44:29PM +, Erik Bråthen Solem wrote:
> Yes, it was supposed to be box_types, not ox_types. I must have removed the b 
> by mistake after I tested the code. Should I resubmit the patch?

the change is trivial but the code that was tested should be submted
exactly, so please test and submit a corrected patch

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv3] af_hdcd: more FATE tests

2016-12-18 Thread Michael Niedermayer 
On Sun, Dec 18, 2016 at 12:48:45PM -0600, Burt P wrote:
> Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%.
> 
> Changed fate-suite sample files:
> * filter/hdcd-encoding-errors.flac (1.3M) replaced by
>   a smaller version (140K). It can be replaced because the test
>   only looks for a non-zero number of errors, so the existing test
>   will still pass.

IMO replacing files is not ok
it would change all past instances of the related fate test
a bug report refering to a fate failure could become unreproduceable
or otherwise working fate tests could start failing ...
as much as i prefer to safe a few bytes in this case i prefer to waste
some space over the potential problems

you can add files, but not remove or replace unless they are truly
unused by every past checkout

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] live_start_index & ignoring "options not found"

2016-12-18 Thread Ibrahim Tachijian 
Hey,

I use live_start_index to control which segment ffmpeg starts with on a HLS
live stream. This is working as expected.

However, when the input file is NOT a HLS live stream then using
"live_start_index"
of course gives you a "Option live_start_index not found" and then quits
ffmpeg.

I'd like to use "live_start_index" whenever the input is HLS and ignore it
when it is not HLS without knowing beforehand what I am using as input.

Is there a way to safely ignore "options not found" and continue?

Thanks,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] Fixing 3GPP Timed Text (TTXT / tx3g / mov_text) encoding for UTF-8 (ticket 6021)

2016-12-18 Thread Erik Bråthen Solem 
Good question. Since text_pos_chars never exceeds the existing 
variable text_pos, I did not think about this.

No, there are no checks. The spec says that "Authors should limit the
string in each text sample to not more than 2048 bytes, for maximum
terminal interoperability", but the code does not enforce this limit
(or the maximum uint16_t value of 65535 for that matter). The likeli-
hood of exceeding this limit is very small, but it does not hurt to
add a check. In any case text_pos >= text_pos_chars, so it should be
sufficient to check just text_pos. In mov_text_new_line_cb we only
increment by 1, so checking if s->text_pos == 0 after that is enough.
In mov_text_text_cb this check can be used instead, placed before the
length len is added to text_pos:
if (len > UINT16_MAX || (s->text_pos > UINT16_MAX - len)) // Overflow

I am new to the project's source code and do not know how errors and
warnings should be handled, but could it be an idea to print a
warning if text_pos > 2048, and print an error message and abort in
case of overflow? Or should the rest of the text just be truncated?

PS. Please excuse the duplicate patch that was sent an hour or two
ago. It is identical to the one I submitted a couple of days ago and
I have no idea why or how that happened.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-18 Thread Michael Niedermayer 
On Sun, Dec 18, 2016 at 07:41:14PM +0100, Nicolas George wrote:
> L'octidi 28 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > How does this patchset relate to the open-ness of the API ?
> > you arent saying anything about the plans, goals, intend of this (or
> > i missed it or fail to associate it with the patchset)
> 
> I am doing this to accommodate people who object to having a different
> view of AVFilterLink for the public API and the internal implementation,
> mostly Hendrik, Andreas and Clément.
> 
> As for me, I am pretty happy with the current code that gives a
> different view of AVFilterLink to the public than the one used for
> implementation. Something like that is needed because some fields have a
> type that is not itself public.
> 
> > Iam asking as it seems like this is moving libavfilter further away
> > from being "open" and centralizing control over filters more.
> > I most likely misinterpret this as i just see the change in the code
> > and dont know the whole story but IMO we should move toward a clean and
> > stable API that everyone can use.
> > That also implies to allow filters to only use public API.
> > while this patchset seems to make filters use more private api by
> > making more needed API private. I think a open API and external
> > filter support would drive developers and users towards libavfilter
> > while locking it down would likely do the opposit
>

> I am not sure I understand what you mean by openness. Do you mean
> applications writing their own filter and inserting it in a filter
> graph?

yes and ideally also installable filters like plugins
but really plugins are IMHO not hard, having an API that one can
access is the imortant part. Even without a true plugin API other
apps or users could link in filters build from a seperate package
quite easily


> If so, I can tell you it is not currently possible, and has not
> been since at least 2012-06-12 (9d0bfc5 lavfi: make AVFilterPad opaque
> after two major bumps.).

i know, but at the time all this closing down of the API happened it
was said that this was temporary (not by you and i dont remember who
said so and not limited to libavfilter) and now over 4 years later
temporary seems to be changing into the permanent end.

IMHO if you want libavfilter to be a success in the long term it needs
to be a open system with clean API that anyone can use and add filters
to.

As it is libavfilter is limited to what ffmpeg developers want INSIDE
ffmpeg. If a filter doesnt fit into that it will likely be rejected.
Which makes sense if there are external filters / plugins. But if the
only way to use a filter in libavfilter is through it being accepted
into main ffmpeg git that just makes libavfilter unfit as a _general_
filter framework.


[...]



-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/1] libavcodec/movtextdec.c: fixing decoding for UTF-8 (ticket 6021)

2016-12-18 Thread Erik Bråthen Solem 
Yes, it was supposed to be box_types, not ox_types. I must have removed the b 
by mistake after I tested the code. Should I resubmit the patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

2016-12-18 Thread wm4 
On Sun, 18 Dec 2016 19:32:16 +0100
Nicolas George  wrote:

> By "actual internal structs", I suspect you mean something similar to
> this:
> 
> typedef struct AVFormatContext {
> ...
> AVFormatInternal *internal;
> ...
> };
> 
> Introducing these structures was a big mistake. For the reasons, see the
> recent discussion about making filter_frame() non-recursive (short of
> it: it makes the actual code unreadable), plus another discussion I did
> not take part about using options on these structure (short of it: a lot
> of work if even possible).
> 
> I do not intend to extend that mistake in libavfilter. If possible, I
> would rather like to kick it out, but fortunately the current uses are
> very limited.

For buffersink, you could simply return a struct with the parameters.
As a value type, it'd be a copy and wouldn't need accessors.

Since you moved the discussion to general API issues...

Using public fields and such "internal" structs is functionally
equivalent to having an opaque struct with trivial accessors. It's
basically a style issue.

(The former approach, internal structs, is used and preferred for
AVCodecContext etc. because it has no impact on the API.)

The difference between them is essentially syntax only. Both of them
have multiple disadvantages:
- too much to deal with at once (whether it's fields or
  setters/getters), no logical separation of functionality that is
  lesser needed or doesn't make sense in some contexts. (Consider all
  these AVCodecContext fields for tuning encoders - what do they do for
  decoding? What do fields, which are audio-only, do if video is
  encoded or decoded?)
- it's unclear when these fields can be set or not. (Why _can_ you set
  a field if the graph is already "configured"? What happens then? How
  is the user supposed to know when it's ok to set them?)
- even if you argue that the previous point can be fixed by having the
  setters check the state and return an error value on misuse, it's
  complex for both API implementer and user
- many uses of this hide internal fields from the public API user,
  which is good. But at the same time, this moves away from the
  (probably worthy) goal of allowing outside implementation of
  codecs, (de)muxers, filters.

So I would suggest that instead of changing the whole API to use
accessors, we should make the API more "transactional", and force
correct use by API design. For example, we could make AVCodecContext
opaque, and provide instantiation functions that take specialized
structs (such as AVCodecParameters) to open the decoder. Making
creation and use of an API would be a good step into improving the API
IMHO. I found myself confused over what fields are always immutable in
an AVHWFramesContext, and which are mutable until "init", and that's an
example of the more classic mixed init/use API concept in ffmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/1] Fixing 3GPP Timed Text (TTXT / tx3g / mov_text) encoding for UTF-8 (ticket 6021)

2016-12-18 Thread Erik Bråthen Solem 
According to the format specification (3GPP TS 26.245, section 5.2) "storage
lengths are specified as byte-counts, wheras highlighting is specified using
character offsets." This patch replaces byte counting with character counting
for highlighting. See the following page for a link to the specification:
https://gpac.wp.mines-telecom.fr/mp4box/ttxt-format-documentation/
---
 libavcodec/movtextenc.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/libavcodec/movtextenc.c b/libavcodec/movtextenc.c
index 20e01e2..3ae015a 100644
--- a/libavcodec/movtextenc.c
+++ b/libavcodec/movtextenc.c
@@ -70,6 +70,7 @@ typedef struct {
 uint8_t style_fontsize;
 uint32_t style_color;
 uint16_t text_pos;
+uint16_t text_pos_chars;
 } MovTextContext;
 
 typedef struct {
@@ -216,10 +217,10 @@ static void mov_text_style_cb(void *priv, const char 
style, int close)
 }
 
 s->style_attributes_temp->style_flag = 0;
-s->style_attributes_temp->style_start = AV_RB16(>text_pos);
+s->style_attributes_temp->style_start = 
AV_RB16(>text_pos_chars);
 } else {
 if (s->style_attributes_temp->style_flag) { //break the style 
record here and start a new one
-s->style_attributes_temp->style_end = AV_RB16(>text_pos);
+s->style_attributes_temp->style_end = 
AV_RB16(>text_pos_chars);
 av_dynarray_add(>style_attributes, >count, 
s->style_attributes_temp);
 s->style_attributes_temp = 
av_malloc(sizeof(*s->style_attributes_temp));
 if (!s->style_attributes_temp) {
@@ -230,10 +231,10 @@ static void mov_text_style_cb(void *priv, const char 
style, int close)
 }
 
 s->style_attributes_temp->style_flag = 
s->style_attributes[s->count - 1]->style_flag;
-s->style_attributes_temp->style_start = AV_RB16(>text_pos);
+s->style_attributes_temp->style_start = 
AV_RB16(>text_pos_chars);
 } else {
 s->style_attributes_temp->style_flag = 0;
-s->style_attributes_temp->style_start = AV_RB16(>text_pos);
+s->style_attributes_temp->style_start = 
AV_RB16(>text_pos_chars);
 }
 }
 switch (style){
@@ -248,7 +249,7 @@ static void mov_text_style_cb(void *priv, const char style, 
int close)
 break;
 }
 } else {
-s->style_attributes_temp->style_end = AV_RB16(>text_pos);
+s->style_attributes_temp->style_end = AV_RB16(>text_pos_chars);
 av_dynarray_add(>style_attributes, >count, 
s->style_attributes_temp);
 
 s->style_attributes_temp = 
av_malloc(sizeof(*s->style_attributes_temp));
@@ -273,7 +274,7 @@ static void mov_text_style_cb(void *priv, const char style, 
int close)
 break;
 }
 if (s->style_attributes_temp->style_flag) { //start of new style record
-s->style_attributes_temp->style_start = AV_RB16(>text_pos);
+s->style_attributes_temp->style_start = 
AV_RB16(>text_pos_chars);
 }
 }
 s->box_flags |= STYL_BOX;
@@ -284,11 +285,11 @@ static void mov_text_color_cb(void *priv, unsigned int 
color, unsigned int color
 MovTextContext *s = priv;
 if (color_id == 2) {//secondary color changes
 if (s->box_flags & HLIT_BOX) {  //close tag
-s->hlit.end = AV_RB16(>text_pos);
+s->hlit.end = AV_RB16(>text_pos_chars);
 } else {
 s->box_flags |= HCLR_BOX;
 s->box_flags |= HLIT_BOX;
-s->hlit.start = AV_RB16(>text_pos);
+s->hlit.start = AV_RB16(>text_pos_chars);
 s->hclr.color = color | (0xFF << 24);  //set alpha value to FF
 }
 }
@@ -302,7 +303,10 @@ static void mov_text_text_cb(void *priv, const char *text, 
int len)
 {
 MovTextContext *s = priv;
 av_bprint_append_data(>buffer, text, len);
-s->text_pos += len;
+s->text_pos += len; // length of text in bytes
+for (int i = 0; i < len; i++)   // length of text in UTF-8 characters
+if ((text[i] & 0xC0) != 0x80)
+s->text_pos_chars++;
 }
 
 static void mov_text_new_line_cb(void *priv, int forced)
@@ -310,6 +314,7 @@ static void mov_text_new_line_cb(void *priv, int forced)
 MovTextContext *s = priv;
 av_bprint_append_data(>buffer, "\n", 1);
 s->text_pos += 1;
+s->text_pos_chars += 1;
 }
 
 static const ASSCodesCallbacks mov_text_callbacks = {
@@ -328,6 +333,7 @@ static int mov_text_encode_frame(AVCodecContext *avctx, 
unsigned char *buf,
 size_t j;
 
 s->text_pos = 0;
+s->text_pos_chars = 0;
 s->count = 0;
 s->box_flags = 0;
 s->style_entries = 0;
-- 
1.9.5 (Apple Git-50.3)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

2016-12-18 Thread Nicolas George 
L'octidi 28 frimaire, an CCXXV, James Almer a écrit :
> You didn't answer what's the gain here.

Yes I did: discuss that with Hendrik, Andreas and Clément, not me.

>How is this better than keeping the
> struct public and letting library users keep accessing its fields normally?
> Why are you trying to make libavfilter so different than the rest? We have
> scheduled the deprecation and removal of /all/ accessors, and now you want
> to add more?

I think you did not read the code carefully enough. These accessors, on
top of addressing Hendrik, Andreas and Clément's concerns, make the code
actually more robust and readable.

> If people didn't use lavfi before, they will feel less motivated to do it
> now since they can't even expect consistency with lavf or lavc.

Once again: consistency is only a means to an end.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

2016-12-18 Thread James Almer 
On 12/18/2016 3:32 PM, Nicolas George wrote:
> L'octidi 28 frimaire, an CCXXV, James Almer a écrit :
>> Is this to make AVFilterLink a fully internal struct?
> 
> As you can see in patch 6/6 in this series.
> 
>>  What's the reason
>> to do that in that case, instead of simply making its private fields
>> actually internal and private?
> 
> Can you suggest a method?
> 
>> The idea for next bump was to clean all this mess for once and for all by
> 
> Good: after this patch, there is no mess, everything is accessed through
> the buffersink API.

By breaking the API, adding extra abstraction and a bunch of new symbols.
You didn't answer what's the gain here. How is this better than keeping the
struct public and letting library users keep accessing its fields normally?
Why are you trying to make libavfilter so different than the rest? We have
scheduled the deprecation and removal of /all/ accessors, and now you want
to add more?

If people didn't use lavfi before, they will feel less motivated to do it
now since they can't even expect consistency with lavf or lavc.
And those that currently do will find themselves having to adapt their
programs without being given a reason as to why they are forced to, unlike
with other big API changes.

> 
>> deprecating all accessors, removing all the "no direct access" notes and
>> moving all the private fields in public structs (Marked with a big "not
>> part of the public API" warning like in the case of with AVFilterLink)
>> into actual internal structs.
> 
> By "actual internal structs", I suspect you mean something similar to
> this:
> 
> typedef struct AVFormatContext {
> ...
> AVFormatInternal *internal;
> ...
> };
> 
> Introducing these structures was a big mistake. For the reasons, see the
> recent discussion about making filter_frame() non-recursive (short of
> it: it makes the actual code unreadable), plus another discussion I did

Back to what i said above. You're breaking API and bothering lavfi users
to make internal code "more readable"?

> not take part about using options on these structure (short of it: a lot
> of work if even possible).
> 
> I do not intend to extend that mistake in libavfilter. If possible, I
> would rather like to kick it out, but fortunately the current uses are
> very limited.

I get you don't like it, but the objective should be to provide a familiar
and user friendly API. Opaque internal structs don't affect users, they
don't ever have to worry about them, it's one field they will never touch.
Making the entire struct internal and bloating the library with accessors
to write or read what has been for years and is expected to be public
fields only because you want another way to hide internal state is a bit
overkill and disruptively user unfriendly.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv3] af_hdcd: more FATE tests

2016-12-18 Thread Burt P 
Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%.

Changed fate-suite sample files:
* filter/hdcd-encoding-errors.flac (1.3M) replaced by
  a smaller version (140K). It can be replaced because the test
  only looks for a non-zero number of errors, so the existing test
  will still pass.
* filter/hdcd-mix.flac (958K) added. It is a much better test than
  filter/hdcd.flac (910K), which is now unused, but can't be removed.
* filter/hdcd-fake20bit.flac (168K) added. It is the first second of
  filter/hdcd.flac, with the 16-bit LSB copied into bit 20 of a 24-bit
  stream. There isn't an actual non-16-bit HDCD sample available to test.
Net change -34K. Would be -944K if hdcd.flac could be removed.

Signed-off-by: Burt P 
---
 tests/fate/filter-audio.mak | 86 ++---
 1 file changed, 74 insertions(+), 12 deletions(-)

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 9c6f7cd..b356bcc 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -255,17 +255,55 @@ fate-filter-volume: CMD = md5 -i $(SRC) -af 
aperms=random,volume=precision=fixed
 fate-filter-volume: CMP = oneline
 fate-filter-volume: REF = 4d6ba75ef3e32d305d066b9bc771d6f4
 
-FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd
-fate-filter-hdcd: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac
-fate-filter-hdcd: CMD = md5 -i $(SRC) -af hdcd -f s24le
-fate-filter-hdcd: CMP = oneline
-fate-filter-hdcd: REF = 5db465a58d2fd0d06ca944b883b33476
-
-FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze
-fate-filter-hdcd-analyze: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac
-fate-filter-hdcd-analyze: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f s24le
-fate-filter-hdcd-analyze: CMP = oneline
-fate-filter-hdcd-analyze: REF = 6e39dc4629c1e84321c0d8bc069b42f6
+# hdcd-mix.flac is a mix of three different sources which are interesting for 
various reasons:
+# first 5 seconds uses packet format A and max LLE of -7.0db
+# second 5 seconds uses packet format B and has a gain mismatch between 
channels
+# last 10 seconds is not HDCD but has a coincidental HDCD packet, it needs to 
be 10 seconds because it also tests the cdt expiration
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-mix
+fate-filter-hdcd-mix: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-mix: CMD = md5 -i $(SRC) -af hdcd -f s24le
+fate-filter-hdcd-mix: CMP = oneline
+fate-filter-hdcd-mix: REF = e7079913e90c124460cdbc712df5b84c
+
+# output will be different because of the gain mismatch in the second and 
third parts
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-mix-psoff
+fate-filter-hdcd-mix-psoff: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-mix-psoff: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false 
-f s24le
+fate-filter-hdcd-mix-psoff: CMP = oneline
+fate-filter-hdcd-mix-psoff: REF = bd0e81fe17696b825ee3515ab928e6bb
+
+# test the different analyze modes
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-pe
+fate-filter-hdcd-analyze-pe: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-analyze-pe: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f 
s24le
+fate-filter-hdcd-analyze-pe: CMP = oneline
+fate-filter-hdcd-analyze-pe: REF = bb83e97bbd0064b9b1c0ef2f2c8f0c77
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-lle
+fate-filter-hdcd-analyze-lle: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-analyze-lle: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=lle -f 
s24le
+fate-filter-hdcd-analyze-lle: CMP = oneline
+fate-filter-hdcd-analyze-lle: REF = 121cc4a681aa0caef5c664fece7a3ddc
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-cdt
+fate-filter-hdcd-analyze-cdt: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-analyze-cdt: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=cdt -f 
s24le
+fate-filter-hdcd-analyze-cdt: CMP = oneline
+fate-filter-hdcd-analyze-cdt: REF = 12136e6a00dd532994f6edcc347af1d4
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-tgm
+fate-filter-hdcd-analyze-tgm: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-analyze-tgm: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=tgm -f 
s24le
+fate-filter-hdcd-analyze-tgm: CMP = oneline
+fate-filter-hdcd-analyze-tgm: REF = a3c39f62e9b9b42c9c440d0045d5fb2f
+# the two additional analyze modes from libhdcd
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-ltgm

[FFmpeg-devel] [PATCHv2] af_hdcd: more FATE tests

2016-12-18 Thread Burt P 
Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%.

Changed fate-suite sample files:
* filter/hdcd-encoding-errors.flac (1.3M) replaced by
  a smaller version (140K). It can be replaced because the test
  only looks for a non-zero number of errors, so the existing test
  will still pass.
* filter/hdcd-mix.flac (958K) added. It is a much better test than
  filter/hdcd.flac (910K), which is now unused, but can't be removed.
* filter/hdcd-fake20bit.flac (168K) added. It is the first second of
  filter/hdcd.flac, with the 16-bit LSB copied into bit 20 of a 24-bit
  stream. There isn't an actual non-16-bit HDCD sample available to test.
Net change -34K. Would be -944K if hdcd.flac could be removed.

Signed-off-by: Burt P 
---
 tests/fate/filter-audio.mak | 86 ++---
 1 file changed, 74 insertions(+), 12 deletions(-)

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 9c6f7cd..a55e3c9 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -255,17 +255,55 @@ fate-filter-volume: CMD = md5 -i $(SRC) -af 
aperms=random,volume=precision=fixed
 fate-filter-volume: CMP = oneline
 fate-filter-volume: REF = 4d6ba75ef3e32d305d066b9bc771d6f4
 
-FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd
-fate-filter-hdcd: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac
-fate-filter-hdcd: CMD = md5 -i $(SRC) -af hdcd -f s24le
-fate-filter-hdcd: CMP = oneline
-fate-filter-hdcd: REF = 5db465a58d2fd0d06ca944b883b33476
-
-FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze
-fate-filter-hdcd-analyze: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac
-fate-filter-hdcd-analyze: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f s24le
-fate-filter-hdcd-analyze: CMP = oneline
-fate-filter-hdcd-analyze: REF = 6e39dc4629c1e84321c0d8bc069b42f6
+# hdcd-mix.flac is a mix of three different sources which are interesting for 
various reasons:
+# first 5 seconds uses packet format A and max LLE of -7.0db
+# second 5 seconds uses packet format B and has a gain mismatch between 
channels
+# last 10 seconds is not HDCD but has a coincidental HDCD packet, it needs to 
be 10 seconds because it also tests the cdt expiration
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-mix
+fate-filter-hdcd-mix: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-mix: CMD = md5 -i $(SRC) -af hdcd -f s24le
+fate-filter-hdcd-mix: CMP = oneline
+fate-filter-hdcd-mix: REF = 6a3cf7f920f419477ada264cc63b40da
+
+# output will be different because of the gain mismatch in the second and 
third parts
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-mix-psoff
+fate-filter-hdcd-mix-psoff: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-mix-psoff: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false 
-f s24le
+fate-filter-hdcd-mix-psoff: CMP = oneline
+fate-filter-hdcd-mix-psoff: REF = b841866d5730852256ca57564c55e0ef
+
+# test the different analyze modes
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-pe
+fate-filter-hdcd-analyze-pe: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-analyze-pe: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f 
s24le
+fate-filter-hdcd-analyze-pe: CMP = oneline
+fate-filter-hdcd-analyze-pe: REF = 9ddd10dfea756160456e25dd96a752b8
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-lle
+fate-filter-hdcd-analyze-lle: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-analyze-lle: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=lle -f 
s24le
+fate-filter-hdcd-analyze-lle: CMP = oneline
+fate-filter-hdcd-analyze-lle: REF = be353f79d3e653d658a6e6e99d7655c8
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-cdt
+fate-filter-hdcd-analyze-cdt: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-analyze-cdt: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=cdt -f 
s24le
+fate-filter-hdcd-analyze-cdt: CMP = oneline
+fate-filter-hdcd-analyze-cdt: REF = d828abe932e0d2bfc914eaa23c15b7f6
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-tgm
+fate-filter-hdcd-analyze-tgm: SRC = $(TARGET_SAMPLES)/filter/hdcd-mix.flac
+fate-filter-hdcd-analyze-tgm: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=tgm -f 
s24le
+fate-filter-hdcd-analyze-tgm: CMP = oneline
+fate-filter-hdcd-analyze-tgm: REF = 407ed0dc8c6fd17cc8c0b53a8b2b0e34
+# the two additional analyze modes from libhdcd
+FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
PCM_S24LE) += fate-filter-hdcd-analyze-ltgm

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-18 Thread Nicolas George 
L'octidi 28 frimaire, an CCXXV, Michael Niedermayer a écrit :
> How does this patchset relate to the open-ness of the API ?
> you arent saying anything about the plans, goals, intend of this (or
> i missed it or fail to associate it with the patchset)

I am doing this to accommodate people who object to having a different
view of AVFilterLink for the public API and the internal implementation,
mostly Hendrik, Andreas and Clément.

As for me, I am pretty happy with the current code that gives a
different view of AVFilterLink to the public than the one used for
implementation. Something like that is needed because some fields have a
type that is not itself public.

> Iam asking as it seems like this is moving libavfilter further away
> from being "open" and centralizing control over filters more.
> I most likely misinterpret this as i just see the change in the code
> and dont know the whole story but IMO we should move toward a clean and
> stable API that everyone can use.
> That also implies to allow filters to only use public API.
> while this patchset seems to make filters use more private api by
> making more needed API private. I think a open API and external
> filter support would drive developers and users towards libavfilter
> while locking it down would likely do the opposit

I am not sure I understand what you mean by openness. Do you mean
applications writing their own filter and inserting it in a filter
graph? If so, I can tell you it is not currently possible, and has not
been since at least 2012-06-12 (9d0bfc5 lavfi: make AVFilterPad opaque
after two major bumps.).

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

2016-12-18 Thread Nicolas George 
L'octidi 28 frimaire, an CCXXV, James Almer a écrit :
> Is this to make AVFilterLink a fully internal struct?

As you can see in patch 6/6 in this series.

>   What's the reason
> to do that in that case, instead of simply making its private fields
> actually internal and private?

Can you suggest a method?

> The idea for next bump was to clean all this mess for once and for all by

Good: after this patch, there is no mess, everything is accessed through
the buffersink API.

> deprecating all accessors, removing all the "no direct access" notes and
> moving all the private fields in public structs (Marked with a big "not
> part of the public API" warning like in the case of with AVFilterLink)
> into actual internal structs.

By "actual internal structs", I suspect you mean something similar to
this:

typedef struct AVFormatContext {
...
AVFormatInternal *internal;
...
};

Introducing these structures was a big mistake. For the reasons, see the
recent discussion about making filter_frame() non-recursive (short of
it: it makes the actual code unreadable), plus another discussion I did
not take part about using options on these structure (short of it: a lot
of work if even possible).

I do not intend to extend that mistake in libavfilter. If possible, I
would rather like to kick it out, but fortunately the current uses are
very limited.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] lavfi/buffersink: add accessors for the stream properties.

2016-12-18 Thread James Almer 
On 12/18/2016 9:22 AM, Nicolas George wrote:
> av_buffersink_get_frame_rate() did already exist; its argument becomes const.
> 
> TODO minor version bump

What's the purpose of adding these accessors? The only reason we have
done this before was because of the now dropped libav ABI compatibility,
since we had to add our own new fields below theirs which meant there was
no guarantee of a fixed offset. That's the reason the accessor for
frame_rate exists here, as far as i can see.
Is this to make AVFilterLink a fully internal struct? What's the reason
to do that in that case, instead of simply making its private fields
actually internal and private?

The idea for next bump was to clean all this mess for once and for all by
deprecating all accessors, removing all the "no direct access" notes and
moving all the private fields in public structs (Marked with a big "not
part of the public API" warning like in the case of with AVFilterLink)
into actual internal structs. That way public structs would finally
become fully public and user friendly again.

This change adds more abstraction and more symbols for what gain?

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-18 Thread Michael Niedermayer 
On Sun, Dec 18, 2016 at 01:22:21PM +0100, Nicolas George wrote:
> API-Change: libavfilter
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/avfilter.h |   2 +
>  libavfilter/internal.h | 199 
> +
>  libavfilter/version.h  |   3 +
>  3 files changed, 204 insertions(+)
> 
> 
> Not sure what the preferred delay would be. I suspect not many programs use
> libavfilter yet. In the meantime, all new fields must be added at both
> places and tested.

How does this patchset relate to the open-ness of the API ?
you arent saying anything about the plans, goals, intend of this (or
i missed it or fail to associate it with the patchset)

Iam asking as it seems like this is moving libavfilter further away
from being "open" and centralizing control over filters more.
I most likely misinterpret this as i just see the change in the code
and dont know the whole story but IMO we should move toward a clean and
stable API that everyone can use.
That also implies to allow filters to only use public API.
while this patchset seems to make filters use more private api by
making more needed API private. I think a open API and external
filter support would drive developers and users towards libavfilter
while locking it down would likely do the opposit

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-18 Thread wm4 
On Sun, 18 Dec 2016 13:37:44 +0100
Nicolas George  wrote:

> L'octidi 28 frimaire, an CCXXV, wm4 a écrit :
> > Did you send the same patches to Libav? This makes the API incompatible
> > with Libav.  
> 
> Their API has been non-working for a long time, even if technically
> compatible with ours. Their problem.

Can't confirm that assessment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-18 Thread Nicolas George 
L'octidi 28 frimaire, an CCXXV, wm4 a écrit :
> Did you send the same patches to Libav? This makes the API incompatible
> with Libav.

Their API has been non-working for a long time, even if technically
compatible with ours. Their problem.

Regards,

-- 
  Nicolas Ge


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-18 Thread wm4 
On Sun, 18 Dec 2016 13:22:21 +0100
Nicolas George  wrote:

> API-Change: libavfilter
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/avfilter.h |   2 +
>  libavfilter/internal.h | 199 
> +
>  libavfilter/version.h  |   3 +
>  3 files changed, 204 insertions(+)
> 
> 
> Not sure what the preferred delay would be. I suspect not many programs use
> libavfilter yet. In the meantime, all new fields must be added at both
> places and tested.
> 
> 
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index 828b270..6109e58 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -377,6 +377,7 @@ struct AVFilterContext {
>  unsigned ready;
>  };
>  
> +#if FF_API_AVFILTERLINK_PUBLIC
>  /**
>   * A link between two filters. This contains pointers to the source and
>   * destination filters between which this link exists, and the indexes of
> @@ -593,6 +594,7 @@ struct AVFilterLink {
>  #endif /* FF_INTERNAL_FIELDS */
>  
>  };
> +#endif /* FF_API_AVFILTERLINK_PUBLIC */
>  
>  /**
>   * Link two filters together.
> diff --git a/libavfilter/internal.h b/libavfilter/internal.h
> index a8b69fd..599be24 100644
> --- a/libavfilter/internal.h
> +++ b/libavfilter/internal.h
> @@ -145,6 +145,205 @@ struct AVFilterPad {
>  int needs_writable;
>  };
>  
> +#if !FF_API_AVFILTERLINK_PUBLIC
> +/**
> + * A link between two filters. This contains pointers to the source and
> + * destination filters between which this link exists, and the indexes of
> + * the pads involved. In addition, this link also contains the parameters
> + * which have been negotiated and agreed upon between the filter, such as
> + * image dimensions, format, etc.
> + */
> +struct AVFilterLink {
> +AVFilterContext *src;   ///< source filter
> +AVFilterPad *srcpad;///< output pad on the source filter
> +
> +AVFilterContext *dst;   ///< dest filter
> +AVFilterPad *dstpad;///< input pad on the dest filter
> +
> +enum AVMediaType type;  ///< filter media type
> +
> +/* These parameters apply only to video */
> +int w;  ///< agreed upon image width
> +int h;  ///< agreed upon image height
> +AVRational sample_aspect_ratio; ///< agreed upon sample aspect ratio
> +/* These parameters apply only to audio */
> +uint64_t channel_layout;///< channel layout of current buffer (see 
> libavutil/channel_layout.h)
> +int sample_rate;///< samples per second
> +
> +int format; ///< agreed upon media format
> +
> +/**
> + * Define the time base used by the PTS of the frames/samples
> + * which will pass through this link.
> + * During the configuration stage, each filter is supposed to
> + * change only the output timebase, while the timebase of the
> + * input link is assumed to be an unchangeable property.
> + */
> +AVRational time_base;
> +
> +/**
> + * Lists of formats and channel layouts supported by the input and output
> + * filters respectively. These lists are used for negotiating the format
> + * to actually be used, which will be loaded into the format and
> + * channel_layout members, above, when chosen.
> + *
> + */
> +AVFilterFormats *in_formats;
> +AVFilterFormats *out_formats;
> +
> +/**
> + * Lists of channel layouts and sample rates used for automatic
> + * negotiation.
> + */
> +AVFilterFormats  *in_samplerates;
> +AVFilterFormats *out_samplerates;
> +struct AVFilterChannelLayouts  *in_channel_layouts;
> +struct AVFilterChannelLayouts *out_channel_layouts;
> +
> +/**
> + * Audio only, the destination filter sets this to a non-zero value to
> + * request that buffers with the given number of samples should be sent 
> to
> + * it. AVFilterPad.needs_fifo must also be set on the corresponding input
> + * pad.
> + * Last buffer before EOF will be padded with silence.
> + */
> +int request_samples;
> +
> +/** stage of the initialization of the link properties (dimensions, etc) 
> */
> +enum {
> +AVLINK_UNINIT = 0,  ///< not started
> +AVLINK_STARTINIT,   ///< started, but incomplete
> +AVLINK_INIT ///< complete
> +} init_state;
> +
> +/**
> + * Graph the filter belongs to.
> + */
> +struct AVFilterGraph *graph;
> +
> +/**
> + * Current timestamp of the link, as defined by the most recent
> + * frame(s), in link time_base units.
> + */
> +int64_t current_pts;
> +
> +/**
> + * Current timestamp of the link, as defined by the most recent
> + * frame(s), in AV_TIME_BASE units.
> + */
> +int64_t current_pts_us;
> +
> +/**
> + * Index in the age array.
> + */
> +int age_index;
> +
> +/**
> + * Frame rate of the stream on the link, or

[FFmpeg-devel] [PATCH 5/6] lavfi/tests/filtfmts: include internal.h.

2016-12-18 Thread Nicolas George 
Signed-off-by: Nicolas George 
---
 libavfilter/tests/filtfmts.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/tests/filtfmts.c b/libavfilter/tests/filtfmts.c
index f59199c..199d74d 100644
--- a/libavfilter/tests/filtfmts.c
+++ b/libavfilter/tests/filtfmts.c
@@ -30,6 +30,7 @@
 
 #include "libavfilter/avfilter.h"
 #include "libavfilter/formats.h"
+#include "libavfilter/internal.h"
 
 static void print_formats(AVFilterContext *filter_ctx)
 {
-- 
2.10.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/6] lavd/lavfi: use buffersink accessors.

2016-12-18 Thread Nicolas George 
Signed-off-by: Nicolas George 
---
 libavdevice/lavfi.c | 37 +++--
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index f9b2694..eca3f15 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -312,31 +312,32 @@ av_cold static int lavfi_read_header(AVFormatContext 
*avctx)
 
 /* fill each stream with the information in the corresponding sink */
 for (i = 0; i < lavfi->nb_sinks; i++) {
-AVFilterLink *link = 
lavfi->sinks[lavfi->stream_sink_map[i]]->inputs[0];
+AVFilterContext *sink = lavfi->sinks[lavfi->stream_sink_map[i]];
+AVRational time_base = av_buffersink_get_time_base(sink);
 AVStream *st = avctx->streams[i];
-st->codecpar->codec_type = link->type;
-avpriv_set_pts_info(st, 64, link->time_base.num, link->time_base.den);
-if (link->type == AVMEDIA_TYPE_VIDEO) {
+st->codecpar->codec_type = av_buffersink_get_type(sink);
+avpriv_set_pts_info(st, 64, time_base.num, time_base.den);
+if (av_buffersink_get_type(sink) == AVMEDIA_TYPE_VIDEO) {
 st->codecpar->codec_id   = AV_CODEC_ID_RAWVIDEO;
-st->codecpar->format = link->format;
-st->codecpar->width  = link->w;
-st->codecpar->height = link->h;
+st->codecpar->format = av_buffersink_get_format(sink);
+st->codecpar->width  = av_buffersink_get_w(sink);
+st->codecpar->height = av_buffersink_get_h(sink);
 st   ->sample_aspect_ratio =
-st->codecpar->sample_aspect_ratio = link->sample_aspect_ratio;
+st->codecpar->sample_aspect_ratio = 
av_buffersink_get_sample_aspect_ratio(sink);
 avctx->probesize = FFMAX(avctx->probesize,
- link->w * link->h *
- 
av_get_padded_bits_per_pixel(av_pix_fmt_desc_get(link->format)) *
+ av_buffersink_get_w(sink) * 
av_buffersink_get_h(sink) *
+ 
av_get_padded_bits_per_pixel(av_pix_fmt_desc_get(av_buffersink_get_format(sink)))
 *
  30);
-} else if (link->type == AVMEDIA_TYPE_AUDIO) {
-st->codecpar->codec_id= av_get_pcm_codec(link->format, -1);
-st->codecpar->channels= avfilter_link_get_channels(link);
-st->codecpar->format  = link->format;
-st->codecpar->sample_rate = link->sample_rate;
-st->codecpar->channel_layout = link->channel_layout;
+} else if (av_buffersink_get_type(sink) == AVMEDIA_TYPE_AUDIO) {
+st->codecpar->codec_id= 
av_get_pcm_codec(av_buffersink_get_format(sink), -1);
+st->codecpar->channels= av_buffersink_get_channels(sink);
+st->codecpar->format  = av_buffersink_get_format(sink);
+st->codecpar->sample_rate = av_buffersink_get_sample_rate(sink);
+st->codecpar->channel_layout = 
av_buffersink_get_channel_layout(sink);
 if (st->codecpar->codec_id == AV_CODEC_ID_NONE)
 av_log(avctx, AV_LOG_ERROR,
"Could not find PCM codec for sample format %s.\n",
-   av_get_sample_fmt_name(link->format));
+   av_get_sample_fmt_name(av_buffersink_get_format(sink)));
 }
 }
 
@@ -400,7 +401,7 @@ static int lavfi_read_packet(AVFormatContext *avctx, 
AVPacket *pkt)
 /* iterate through all the graph sinks. Select the sink with the
  * minimum PTS */
 for (i = 0; i < lavfi->nb_sinks; i++) {
-AVRational tb = lavfi->sinks[i]->inputs[0]->time_base;
+AVRational tb = av_buffersink_get_time_base(lavfi->sinks[i]);
 double d;
 int ret;
 
-- 
2.10.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 6/6] lavfi: make AVFilterLink opaque in two major bumps.

2016-12-18 Thread Nicolas George 
API-Change: libavfilter
Signed-off-by: Nicolas George 
---
 libavfilter/avfilter.h |   2 +
 libavfilter/internal.h | 199 +
 libavfilter/version.h  |   3 +
 3 files changed, 204 insertions(+)


Not sure what the preferred delay would be. I suspect not many programs use
libavfilter yet. In the meantime, all new fields must be added at both
places and tested.


diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 828b270..6109e58 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -377,6 +377,7 @@ struct AVFilterContext {
 unsigned ready;
 };
 
+#if FF_API_AVFILTERLINK_PUBLIC
 /**
  * A link between two filters. This contains pointers to the source and
  * destination filters between which this link exists, and the indexes of
@@ -593,6 +594,7 @@ struct AVFilterLink {
 #endif /* FF_INTERNAL_FIELDS */
 
 };
+#endif /* FF_API_AVFILTERLINK_PUBLIC */
 
 /**
  * Link two filters together.
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index a8b69fd..599be24 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -145,6 +145,205 @@ struct AVFilterPad {
 int needs_writable;
 };
 
+#if !FF_API_AVFILTERLINK_PUBLIC
+/**
+ * A link between two filters. This contains pointers to the source and
+ * destination filters between which this link exists, and the indexes of
+ * the pads involved. In addition, this link also contains the parameters
+ * which have been negotiated and agreed upon between the filter, such as
+ * image dimensions, format, etc.
+ */
+struct AVFilterLink {
+AVFilterContext *src;   ///< source filter
+AVFilterPad *srcpad;///< output pad on the source filter
+
+AVFilterContext *dst;   ///< dest filter
+AVFilterPad *dstpad;///< input pad on the dest filter
+
+enum AVMediaType type;  ///< filter media type
+
+/* These parameters apply only to video */
+int w;  ///< agreed upon image width
+int h;  ///< agreed upon image height
+AVRational sample_aspect_ratio; ///< agreed upon sample aspect ratio
+/* These parameters apply only to audio */
+uint64_t channel_layout;///< channel layout of current buffer (see 
libavutil/channel_layout.h)
+int sample_rate;///< samples per second
+
+int format; ///< agreed upon media format
+
+/**
+ * Define the time base used by the PTS of the frames/samples
+ * which will pass through this link.
+ * During the configuration stage, each filter is supposed to
+ * change only the output timebase, while the timebase of the
+ * input link is assumed to be an unchangeable property.
+ */
+AVRational time_base;
+
+/**
+ * Lists of formats and channel layouts supported by the input and output
+ * filters respectively. These lists are used for negotiating the format
+ * to actually be used, which will be loaded into the format and
+ * channel_layout members, above, when chosen.
+ *
+ */
+AVFilterFormats *in_formats;
+AVFilterFormats *out_formats;
+
+/**
+ * Lists of channel layouts and sample rates used for automatic
+ * negotiation.
+ */
+AVFilterFormats  *in_samplerates;
+AVFilterFormats *out_samplerates;
+struct AVFilterChannelLayouts  *in_channel_layouts;
+struct AVFilterChannelLayouts *out_channel_layouts;
+
+/**
+ * Audio only, the destination filter sets this to a non-zero value to
+ * request that buffers with the given number of samples should be sent to
+ * it. AVFilterPad.needs_fifo must also be set on the corresponding input
+ * pad.
+ * Last buffer before EOF will be padded with silence.
+ */
+int request_samples;
+
+/** stage of the initialization of the link properties (dimensions, etc) */
+enum {
+AVLINK_UNINIT = 0,  ///< not started
+AVLINK_STARTINIT,   ///< started, but incomplete
+AVLINK_INIT ///< complete
+} init_state;
+
+/**
+ * Graph the filter belongs to.
+ */
+struct AVFilterGraph *graph;
+
+/**
+ * Current timestamp of the link, as defined by the most recent
+ * frame(s), in link time_base units.
+ */
+int64_t current_pts;
+
+/**
+ * Current timestamp of the link, as defined by the most recent
+ * frame(s), in AV_TIME_BASE units.
+ */
+int64_t current_pts_us;
+
+/**
+ * Index in the age array.
+ */
+int age_index;
+
+/**
+ * Frame rate of the stream on the link, or 1/0 if unknown or variable;
+ * if left to 0/0, will be automatically copied from the first input
+ * of the source filter if it exists.
+ *
+ * Sources should set it to the best estimation of the real frame rate.
+ * If the source frame rate is unknown or variable, set this to 1/0.
+ * Filters should update it if necessary depending on

[FFmpeg-devel] [PATCH 3/6] ffplay: use buffersink accessors.

2016-12-18 Thread Nicolas George 
Signed-off-by: Nicolas George 
---
 ffplay.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index 911fd7f..90bd97b 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2075,7 +2075,7 @@ static int audio_thread(void *arg)
 goto the_end;
 
 while ((ret = av_buffersink_get_frame_flags(is->out_audio_filter, 
frame, 0)) >= 0) {
-tb = is->out_audio_filter->inputs[0]->time_base;
+tb = av_buffersink_get_time_base(is->out_audio_filter);
 #endif
 if (!(af = frame_queue_peek_writable(>sampq)))
 goto the_end;
@@ -2183,7 +2183,7 @@ static int video_thread(void *arg)
 last_format = frame->format;
 last_serial = is->viddec.pkt_serial;
 last_vfilter_idx = is->vfilter_idx;
-frame_rate = filt_out->inputs[0]->frame_rate;
+frame_rate = av_buffersink_get_frame_rate(filt_out);
 }
 
 ret = av_buffersrc_add_frame(filt_in, frame);
@@ -2204,7 +2204,7 @@ static int video_thread(void *arg)
 is->frame_last_filter_delay = av_gettime_relative() / 100.0 - 
is->frame_last_returned_time;
 if (fabs(is->frame_last_filter_delay) > AV_NOSYNC_THRESHOLD / 10.0)
 is->frame_last_filter_delay = 0;
-tb = filt_out->inputs[0]->time_base;
+tb = av_buffersink_get_time_base(filt_out);
 #endif
 duration = (frame_rate.num && frame_rate.den ? 
av_q2d((AVRational){frame_rate.den, frame_rate.num}) : 0);
 pts = (frame->pts == AV_NOPTS_VALUE) ? NAN : frame->pts * 
av_q2d(tb);
@@ -2641,7 +2641,7 @@ static int stream_component_open(VideoState *is, int 
stream_index)
 case AVMEDIA_TYPE_AUDIO:
 #if CONFIG_AVFILTER
 {
-AVFilterLink *link;
+AVFilterContext *sink;
 
 is->audio_filter_src.freq   = avctx->sample_rate;
 is->audio_filter_src.channels   = avctx->channels;
@@ -2649,10 +2649,10 @@ static int stream_component_open(VideoState *is, int 
stream_index)
 is->audio_filter_src.fmt= avctx->sample_fmt;
 if ((ret = configure_audio_filters(is, afilters, 0)) < 0)
 goto fail;
-link = is->out_audio_filter->inputs[0];
-sample_rate= link->sample_rate;
-nb_channels= avfilter_link_get_channels(link);
-channel_layout = link->channel_layout;
+sink = is->out_audio_filter;
+sample_rate= av_buffersink_get_sample_rate(sink);
+nb_channels= av_buffersink_get_channels(sink);
+channel_layout = av_buffersink_get_channel_layout(sink);
 }
 #else
 sample_rate= avctx->sample_rate;
-- 
2.10.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/6] ffmpeg: use buffersink accessors.

2016-12-18 Thread Nicolas George 
Signed-off-by: Nicolas George 
---
 ffmpeg.c| 46 --
 ffmpeg_filter.c | 12 ++--
 2 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index e4890a4..ff177e0 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1014,6 +1014,7 @@ static void do_video_out(OutputFile *of,
 AVPacket pkt;
 AVCodecContext *enc = ost->enc_ctx;
 AVCodecParameters *mux_par = ost->st->codecpar;
+AVRational frame_rate;
 int nb_frames, nb0_frames, i;
 double delta, delta0;
 double duration = 0;
@@ -1024,9 +1025,9 @@ static void do_video_out(OutputFile *of,
 if (ost->source_index >= 0)
 ist = input_streams[ost->source_index];
 
-if (filter->inputs[0]->frame_rate.num > 0 &&
-filter->inputs[0]->frame_rate.den > 0)
-duration = 1/(av_q2d(filter->inputs[0]->frame_rate) * 
av_q2d(enc->time_base));
+frame_rate = av_buffersink_get_frame_rate(filter);
+if (frame_rate.num > 0 && frame_rate.den > 0)
+duration = 1/(av_q2d(frame_rate) * av_q2d(enc->time_base));
 
 if(ist && ist->st->start_time != AV_NOPTS_VALUE && ist->st->first_dts != 
AV_NOPTS_VALUE && ost->frame_rate.num)
 duration = FFMIN(duration, 1/(av_q2d(ost->frame_rate) * 
av_q2d(enc->time_base)));
@@ -1416,7 +1417,7 @@ static int reap_filters(int flush)
 av_log(NULL, AV_LOG_WARNING,
"Error in av_buffersink_get_frame_flags(): %s\n", 
av_err2str(ret));
 } else if (flush && ret == AVERROR_EOF) {
-if (filter->inputs[0]->type == AVMEDIA_TYPE_VIDEO)
+if (av_buffersink_get_type(filter) == AVMEDIA_TYPE_VIDEO)
 do_video_out(of, ost, NULL, AV_NOPTS_VALUE);
 }
 break;
@@ -1427,25 +1428,26 @@ static int reap_filters(int flush)
 }
 if (filtered_frame->pts != AV_NOPTS_VALUE) {
 int64_t start_time = (of->start_time == AV_NOPTS_VALUE) ? 0 : 
of->start_time;
+AVRational filter_tb = av_buffersink_get_time_base(filter);
 AVRational tb = enc->time_base;
 int extra_bits = av_clip(29 - av_log2(tb.den), 0, 16);
 
 tb.den <<= extra_bits;
 float_pts =
-av_rescale_q(filtered_frame->pts, 
filter->inputs[0]->time_base, tb) -
+av_rescale_q(filtered_frame->pts, filter_tb, tb) -
 av_rescale_q(start_time, AV_TIME_BASE_Q, tb);
 float_pts /= 1 << extra_bits;
 // avoid exact midoints to reduce the chance of rounding 
differences, this can be removed in case the fps code is changed to work with 
integers
 float_pts += FFSIGN(float_pts) * 1.0 / (1<<17);
 
 filtered_frame->pts =
-av_rescale_q(filtered_frame->pts, 
filter->inputs[0]->time_base, enc->time_base) -
+av_rescale_q(filtered_frame->pts, filter_tb, 
enc->time_base) -
 av_rescale_q(start_time, AV_TIME_BASE_Q, enc->time_base);
 }
 //if (ost->source_index >= 0)
 //*filtered_frame= 
*input_streams[ost->source_index]->decoded_frame; //for me_threshold
 
-switch (filter->inputs[0]->type) {
+switch (av_buffersink_get_type(filter)) {
 case AVMEDIA_TYPE_VIDEO:
 if (!ost->frame_aspect_ratio.num)
 enc->sample_aspect_ratio = 
filtered_frame->sample_aspect_ratio;
@@ -3148,19 +3150,19 @@ static int init_output_stream_encode(OutputStream *ost)
 
 switch (enc_ctx->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
-enc_ctx->sample_fmt = ost->filter->filter->inputs[0]->format;
+enc_ctx->sample_fmt = 
av_buffersink_get_format(ost->filter->filter);
 if (dec_ctx)
 enc_ctx->bits_per_raw_sample = FFMIN(dec_ctx->bits_per_raw_sample,
  
av_get_bytes_per_sample(enc_ctx->sample_fmt) << 3);
-enc_ctx->sample_rate= ost->filter->filter->inputs[0]->sample_rate;
-enc_ctx->channel_layout = 
ost->filter->filter->inputs[0]->channel_layout;
-enc_ctx->channels   = 
avfilter_link_get_channels(ost->filter->filter->inputs[0]);
+enc_ctx->sample_rate= 
av_buffersink_get_sample_rate(ost->filter->filter);
+enc_ctx->channel_layout = 
av_buffersink_get_channel_layout(ost->filter->filter);
+enc_ctx->channels   = 
av_buffersink_get_channels(ost->filter->filter);
 enc_ctx->time_base  = (AVRational){ 1, enc_ctx->sample_rate };
 break;
 case AVMEDIA_TYPE_VIDEO:
 enc_ctx->time_base = av_inv_q(ost->frame_rate);
 if (!(enc_ctx->time_base.num && enc_ctx->time_base.den))
-enc_ctx->time_base = ost->filter->filter->inputs[0]->time_base;
+enc_ctx->time_base =

Re: [FFmpeg-devel] [PATCH] avformat/tls: add tls url_get_file_handle

2016-12-18 Thread wm4 
On Sat, 17 Dec 2016 20:17:54 +0100
Michael Niedermayer  wrote:

> On Sun, Oct 16, 2016 at 10:28:21AM -0400, jayri...@gmail.com wrote:
> > From: Jay Ridgeway 
> > 
> > Support url_get_file_handle on TLS streams.
> > ---
> >  libavformat/tls_gnutls.c  | 7 +++
> >  libavformat/tls_openssl.c | 7 +++
> >  libavformat/tls_schannel.c| 7 +++
> >  libavformat/tls_securetransport.c | 7 +++
> >  4 files changed, 28 insertions(+)  
> 
> applied
> 
> thx
> 
> [...]

What is this even supposed to be useful for???
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/tls: add tls url_get_file_handle

2016-12-18 Thread wm4 
On Sat, 17 Dec 2016 20:17:54 +0100
Michael Niedermayer  wrote:

> On Sun, Oct 16, 2016 at 10:28:21AM -0400, jayri...@gmail.com wrote:
> > From: Jay Ridgeway 
> > 
> > Support url_get_file_handle on TLS streams.
> > ---
> >  libavformat/tls_gnutls.c  | 7 +++
> >  libavformat/tls_openssl.c | 7 +++
> >  libavformat/tls_schannel.c| 7 +++
> >  libavformat/tls_securetransport.c | 7 +++
> >  4 files changed, 28 insertions(+)  
> 
> applied
> 
> thx
> 
> [...]

What is this even supposed to be useful for???
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] af_hdcd: more FATE tests

2016-12-18 Thread Burt P. 
On Sun, Dec 18, 2016 at 3:30 AM, Hendrik Leppkes  wrote:
> On Sun, Dec 18, 2016 at 8:42 AM, Burt P  wrote:
>> Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%.
>>
>> Changed fate-suite sample files:
>> * filter/hdcd-encoding-errors.flac (1.3M) replaced by
>>   filter/hdcd-encoding-errors2.flac (140K)
>> * filter/hdcd-mix.flac (2.2M) added
>> * filter/hdcd-fake20bit.flac (168K) added
>> * filter/hdcd.flac (910K) removed, although it was a nice tune and
>>   the samples that replace it are terrible sounds.
>> Net change +290K.
>>
>
> We cannot delete samples because that would break old versions of FATE
> (which is vital for bisecting etc), so knowing and accounting for
> that, would that change any of these choices to add/remove samples?
> Because the net change goes to around +2.5M without any removals.
>

Well, hdcd-encoding-errors2.flac could simply be named
hdcd-encoding-errors.flac and it should not affect the test that uses it,
even in an old version. There only needs to be a non-zero number of
errors, 2 is as good as 4.

The sample hdcd.flac is a nice sound, but it isn't a very interesting
example of HDCD for testing. hdcd-mix.flac is a concatenation of three
different samples, each one interesting in a different way, and it does
quite a bit for code coverage. I will, however, try to make it smaller.

-- 
Burt
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

2016-12-18 Thread Nicolas George 
Le primidi 21 frimaire, an CCXXV, Nicolas George a écrit :
> I will do so after the end of this week if I see no news.

Done.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] af_hdcd: more FATE tests

2016-12-18 Thread Hendrik Leppkes 
On Sun, Dec 18, 2016 at 8:42 AM, Burt P  wrote:
> Additional/Modified FATE tests improve code coverage from 63.7% to 98.1%.
>
> Changed fate-suite sample files:
> * filter/hdcd-encoding-errors.flac (1.3M) replaced by
>   filter/hdcd-encoding-errors2.flac (140K)
> * filter/hdcd-mix.flac (2.2M) added
> * filter/hdcd-fake20bit.flac (168K) added
> * filter/hdcd.flac (910K) removed, although it was a nice tune and
>   the samples that replace it are terrible sounds.
> Net change +290K.
>

We cannot delete samples because that would break old versions of FATE
(which is vital for bisecting etc), so knowing and accounting for
that, would that change any of these choices to add/remove samples?
Because the net change goes to around +2.5M without any removals.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel