Re: [FFmpeg-devel] [PATCH] avfilter: add unpremultiply filter

[Tobias Rapp]

On 01.08.2017 13:03, Paul B Mahol wrote:

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  13 ++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_premultiply.c | 307 ---
 4 files changed, 277 insertions(+), 45 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4089135..a50696a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14532,6 +14532,19 @@ ffmpeg -i INPUT -vf trim=duration=1

 @end itemize

+@section unpremultiply
+Apply alpha unpremultiply effect to input video stream using first plane
+of second stream as alpha.
+
+Both streams must have same dimensions and same pixel format.
+
+The filter accepts the following option:
+
+@table @option
+@item planes
+Set which planes will be processed, unprocessed planes will be copied.
+By default value 0xf, all planes will be processed.
+@end table


IMHO using a flags-like string "planes=rgb" would be more user-friendly 
than a bitmask. At least the documentation should tell which bit refers 
to what channel.



[...]



Some FATE test for the new filter would be welcome.

Regards,
Tobias

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

Re: [FFmpeg-devel] Possible minor bug found in AVI decoder

[Tobias Rapp]

On 12.05.2017 11:33, Eric Beuque wrote:

Hi,

i'm not really sure but i think a found a bug in the avi decoder of
avformat.

In the following function of the avidec.c:

static int avi_read_header(AVFormatContext *s)
{
...
switch (tag) {
...
case MKTAG('s', 't', 'r', 'f'):
/* stream header */
if (!size)
break;
if (stream_index >= (unsigned)s->nb_streams || avi->dv_demux) {
avio_skip(pb, size);
} else {
...
switch (codec_type) {
...
default:
st->codec->codec_type = AVMEDIA_TYPE_DATA;
st->codec->codec_id   = AV_CODEC_ID_NONE;
st->codec->codec_tag  = 0;
avio_skip(pb, size);
break;
}
}
break;
...
}

If the codec_type is AVMEDIA_TYPE_DATA, but the format is empty (size=0)
(which i think is allowed), then the codec_id is not set to
AV_CODEC_ID_NONE.

This will generate a trace when calling the avformat_find_stream_info:
"Could not find codec parameters for stream 1 (Unknown: none): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize'
options"

I'm not really sure about he AVI spec if the format is mandatory or not,
but i think there is a bug.


According to the document at 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318189(v=vs.85).aspx 
the "strf" chunk is mandatory but the data is only specified for 
audio/video streams so indeed it might be possible that a chunk size of 
0 occurs for generic data streams.


Regards,
Tobias

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add arbitrary audio FIR filter

[Tobias Rapp]

On 10.05.2017 09:12, Muhammad Faiz wrote:

On Wed, May 10, 2017 at 1:55 AM, Paul B Mahol  wrote:

ffmpeg | branch: master | Paul B Mahol  | Thu Jan 26 17:03:08 
2017 +0100| [49bbfb9d13936ee8bb7fee9983ca3710dc683a2e] | committer: Paul B Mahol

avfilter: add arbitrary audio FIR filter

Signed-off-by: Paul B Mahol 


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=49bbfb9d13936ee8bb7fee9983ca3710dc683a2e

---

 configure  |   3 +
 doc/filters.texi   |  43 
 libavfilter/Makefile   |   1 +
 libavfilter/af_afir.c  | 535 +
 libavfilter/af_afir.h  |  83 +++
 libavfilter/allfilters.c   |   1 +
 libavfilter/version.h  |   2 +-
 libavfilter/x86/Makefile   |   2 +
 libavfilter/x86/af_afir.asm|  60 +
 libavfilter/x86/af_afir_init.c |  35 +++
 10 files changed, 764 insertions(+), 1 deletion(-)

 [...]


segfault with this filtergraph

aevalsrc= 'if(n, 0, 1)',
firequalizer=
delay   = 0.023:
fixed   = off:
wfunc   = nuttall:
gain= 'if(between(f, 1000, 5000), -INF, 0)',
atrim = end_sample = 2048 [ir];

aevalsrc='0.5*sin(3000*t*t)':d=10.3 [data];

[data][ir]
afir


Not really related to this report, but in general it would be nice to 
have some fate tests for the afir filter.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: Disallow local file access by default

[Tobias Rapp]

On 31.05.2017 15:42, wm4 wrote:

On Wed, 31 May 2017 14:49:19 +0200
Michael Niedermayer  wrote:


>> [...]
>>

Security fixes should be as simple as
   possible.


Well, your fix isn't simple. It adds yet another exception with
questionable effect. It makes it more complex and harder to predict
what will actually happen, not simpler.


If people want, I can limit the local file check to the case where
the io_open callback is not set?
That way user applications which do their own sanitation would not be
affected by the check or error message and stay in full control of
what access is allowed.


That would have little value and would make it more complex too.

I'd say a good way to make this secure would be disabling the hls
protocol in builds which are security sensitive.


We already have "protocol_whitelist", --disable-protocol and application 
sandboxing as supported and generic options. I agree with wm4 that some 
special case-handling here just adds complexity.



In general there doesn't seem to be a good way. Feel free to prove me
wrong. (I tried something similar, but in addition to the security vs.
convenience tradeoff, it just didn't work.)


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avformat/hls: Disallow local file access by default

[Tobias Rapp]

On 31.05.2017 18:33, Michael Niedermayer wrote:

On Wed, May 31, 2017 at 05:18:57PM +0200, Tobias Rapp wrote:

On 31.05.2017 15:42, wm4 wrote:

On Wed, 31 May 2017 14:49:19 +0200
Michael Niedermayer <mich...@niedermayer.cc> wrote:


[...]

Security fixes should be as simple as
  possible.


Well, your fix isn't simple. It adds yet another exception with
questionable effect. It makes it more complex and harder to predict
what will actually happen, not simpler.


If people want, I can limit the local file check to the case where
the io_open callback is not set?
That way user applications which do their own sanitation would not be
affected by the check or error message and stay in full control of
what access is allowed.


That would have little value and would make it more complex too.

I'd say a good way to make this secure would be disabling the hls
protocol in builds which are security sensitive.


We already have "protocol_whitelist", --disable-protocol and
application sandboxing as supported and generic options. I agree
with wm4 that some special case-handling here just adds complexity.


"--disable-protocol" does not allow fixing this, the vulnerability
only needs the file protocol ultimatly.

similarly protocol_whitelist only helps if "file" is not on it,
no other protocol is really required for this.

I just confirmed the exploit works with
-protocol_whitelist file,crypto

sandboxing is the awnser for automated transcoding services but
the average joe end user cannot use sandboxing

What do you suggest ?


Well as far as I understand the user must
(a1) be tricked into opening a playlist file with FFmpeg
or
(a2) some software based on FFmpeg libraries, then
(b) be tricked into uploading the output file to a server under control 
of the attacker.


Adding another command-line argument will not help much for (a1) as user 
Joe Average might not find/understand it in the long list of options (or 
the options are simply hidden behind some script - but in case a script 
is executed we have lost already anyway).


For (a2) the application should put playlist muxers on the blacklist, if 
not required for normal usage. When being extra cautious this could be 
the library option's default.


Now (b) is the biggest part of the security breach. Uploading 
non-verified binary data to unknown third parties is bad. Thats the 
reason why Joe Average should also opt-out to all that telemetry or 
crash report uploading done by other applications.


But if Joe is willing to upload some data which has been generated via 
some untrusted commands he is not far from uploading other readable 
local files anyway - I see no meaningful way to prevent that from code 
within FFmpeg.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat: set the default whitelist to disable hls

[Tobias Rapp]

On 01.06.2017 13:44, Michael Niedermayer wrote:

This prevents an exploit leading to an information leak

The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.

Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfo...@google.com>

Fix inspired by: Tobias Rapp <t.r...@noa-archive.com>

Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
---
 libavformat/options_table.h | 2 +-
 libavformat/utils.c | 6 +-
 tests/fate/avformat.mak | 4 ++--
 tests/fate/filter-audio.mak | 4 ++--
 4 files changed, 10 insertions(+), 6 deletions(-)

[...]


I would prefer this patch over the one in 
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/211796.html


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] cmdutils: add log time info into report log file

[Tobias Rapp]

On 03.06.2017 08:41, Steven Liu wrote:

2017-06-03 0:30 GMT+08:00 Nicolas George :


Le quintidi 15 prairial, an CCXXV, Steven Liu a écrit :

add time info into every line of log report
the time info can be used to find out error message occur time.

Signed-off-by: Steven Liu 
---
 cmdutils.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/cmdutils.c b/cmdutils.c
index 3d428f3eea..b760a0565d 100644
--- a/cmdutils.c
+++ b/cmdutils.c
@@ -47,6 +47,7 @@
 #include "libavutil/libm.h"
 #include "libavutil/parseutils.h"
 #include "libavutil/pixdesc.h"
+#include "libavutil/time.h"
 #include "libavutil/eval.h"
 #include "libavutil/dict.h"
 #include "libavutil/opt.h"
@@ -103,6 +104,8 @@ void log_callback_help(void *ptr, int level, const char 
*fmt, va_list vl)
 static void log_callback_report(void *ptr, int level, const char *fmt, va_list 
vl)
 {
 va_list vl2;
+char *tmp_string = NULL;
+char time_value[32];
 char line[1024];
 static int print_prefix = 1;

@@ -111,7 +114,10 @@ static void log_callback_report(void *ptr, int level, 
const char *fmt, va_list v
 av_log_format_line(ptr, level, fmt, vl2, line, sizeof(line), 
_prefix);
 va_end(vl2);
 if (report_file_level >= level) {
-fputs(line, report_file);



+snprintf(time_value, sizeof(time_value), "\n[%"PRId64"] - ", 
av_gettime());
+tmp_string = av_strireplace(line, "\n", time_value);


It looks like you are printing the time of a line at the beginning of
the next line. Or am I missing something.

Also, I do not like the dynamic alloc in this function, especially since
the same task can be done without: find \n, print the time and the
single line, loop.


+fputs(tmp_string, report_file);
+av_free(tmp_string);
 fflush(report_file);
 }
 }


Regards,


Hi Nicolas,

I get some problem of the log output:

1. the log output by multiple av_log to one line,
 for example:
 av_log(NULL, "major_brand :");
 av_log(NULL, "isom\n");
 then if add the time to the line head, it will output looks like this:
 [1496470846077636] - major_brand :
[1496470846077643] - isom[1496470846077650] -

 2. but if add the time to the end of line, it maybe need control
right alignment

 3. maybe the better solution is add the time into line head when
the log level big than AV_LOG_WARNING ?



Maybe you could use the existing "print_prefix" flag to check whether a 
timestamp prefix shall be added?


And it would be good if the timestamp prefix would be made optional 
similar to the AV_LOG_PRINT_LEVEL flag.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avformat/file: increase max packet size to 256k for written files

[Tobias Rapp]

On 05.06.2017 19:16, Marton Balint wrote:

Another huge performance improvement when using SMB/CIFS as output.

Signed-off-by: Marton Balint 
---
 libavformat/file.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/file.c b/libavformat/file.c
index 264542a36a..ae7231a484 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -227,6 +227,11 @@ static int file_open(URLContext *h, const char *filename, 
int flags)

 h->is_streamed = !fstat(fd, ) && S_ISFIFO(st.st_mode);

+/* Buffer writes more than the default 32k to improve throughput especially
+ * with networked file systems */
+if (!h->is_streamed && flags & AVIO_FLAG_WRITE)
+h->max_packet_size = 262144;
+
 return 0;
 }



My tests show ~50% improved throughput rates. LGTM, but I'm not the 
maintainer of this file.


Thanks,
Tobias

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

Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?

[Tobias Rapp]

On 19.06.2017 10:28, wm4 wrote:

On Mon, 19 Jun 2017 09:38:19 +0200
Tobias Rapp <t.r...@noa-archive.com> wrote:


On 19.06.2017 02:04, 21na...@gmail.com wrote:

Le 18/06/2017 à 00:57, Sasi Inguva a écrit :

Hi,

I was the one who made that change. We needed a way to obtain individual
stream durations from a  Matroska file without reading the entire file. I
don't think it adds to the file size greatly (< 50 bytes) compared to the
size of video and audio data, hence I didn't hide it under an option.
However if u really need it I can add an option.



Hello,

Yes the size required for the tag “DURATION” is insignificant, but it is
preferable to have a choice with this tag like mkvmerge partially does
(because by default “--enable-durations” is enabled, maybe because it is
a part of “statistics-tags”, but we can disable them with
“--disable-track-statistics-tags”) and because the end user and his
software do not require it.

Yes if you can move the tag “DURATION” as an optional tag—so an argument
is needed to enable it, I will be grateful to you.


I disagree to this tag writing being opt-in. It requires marginal
runtime and storage space resources to write a duration field. The
application used for playback might change or even a new version of the
same application might make use of the tag. So it would be better to
enable it by default.

And for the tag writing being opt-out: Maintaining code also has some
cost. As far as I understand this option would just be required for some
aesthetic reason, thus I don't think it's worth adding that maintenance
cost by implementing code to make this tag opt-out.


But there's also this argument that writing these tags is silly, and
that mkvmerge should never have started it. Instead, there should be
proper EBML elements for this.


If there are proper fields for it in the container and they are 
supported by most applications, then yes: it makes no sense to duplicate 
the value into some metadata tag.


Regards,
Tobias


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

Re: [FFmpeg-devel] Why the tag “DURATION” is a necessity in Matroska files?

[Tobias Rapp]

On 19.06.2017 02:04, 21na...@gmail.com wrote:

Le 18/06/2017 à 00:57, Sasi Inguva a écrit :

Hi,

I was the one who made that change. We needed a way to obtain individual
stream durations from a  Matroska file without reading the entire file. I
don't think it adds to the file size greatly (< 50 bytes) compared to the
size of video and audio data, hence I didn't hide it under an option.
However if u really need it I can add an option.



Hello,

Yes the size required for the tag “DURATION” is insignificant, but it is
preferable to have a choice with this tag like mkvmerge partially does
(because by default “--enable-durations” is enabled, maybe because it is
a part of “statistics-tags”, but we can disable them with
“--disable-track-statistics-tags”) and because the end user and his
software do not require it.

Yes if you can move the tag “DURATION” as an optional tag—so an argument
is needed to enable it, I will be grateful to you.


I disagree to this tag writing being opt-in. It requires marginal 
runtime and storage space resources to write a duration field. The 
application used for playback might change or even a new version of the 
same application might make use of the tag. So it would be better to 
enable it by default.


And for the tag writing being opt-out: Maintaining code also has some 
cost. As far as I understand this option would just be required for some 
aesthetic reason, thus I don't think it's worth adding that maintenance 
cost by implementing code to make this tag opt-out.


Just my personal thoughts.

Tobias

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

Re: [FFmpeg-devel] [PATCH] tests/fate/fifo-muxer: update fifo-muxer dependencies

[Tobias Rapp]

On 07.05.2017 22:30, Paul B Mahol wrote:

On 5/4/17, Tobias Rapp <t.r...@noa-archive.com> wrote:

Fixes fate when configured with --disable-network.
---
 tests/fate/fifo-muxer.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/fifo-muxer.mak b/tests/fate/fifo-muxer.mak
index ef8b3b3..9c13954 100644
--- a/tests/fate/fifo-muxer.mak
+++ b/tests/fate/fifo-muxer.mak
@@ -13,7 +13,7 @@ FATE_SAMPLES_FIFO_MUXER-$(call ALLYES, FIFO_MUXER,
WAV_DEMUXER) += fate-fifo-mux

 fate-fifo-muxer-tst: libavformat/tests/fifo_muxer$(EXESUF)
 fate-fifo-muxer-tst: CMD = run libavformat/tests/fifo_muxer$(EXESUF)
-FATE_FIFO_MUXER-$(CONFIG_FIFO_MUXER) += fate-fifo-muxer-tst
+FATE_FIFO_MUXER-$(call ALLYES, FIFO_MUXER NETWORK) += fate-fifo-muxer-tst

 FATE_SAMPLES_FFMPEG += $(FATE_SAMPLES_FIFO_MUXER-yes)
 FATE_FFMPEG += $(FATE_FIFO_MUXER-yes)
--
2.7.4


LGTM


Pushed.

Thanks,
Tobias

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

[FFmpeg-devel] [PATCH] tests/fate/fifo-muxer: update fifo-muxer dependencies

[Tobias Rapp]

Fixes fate when configured with --disable-network.
---
 tests/fate/fifo-muxer.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/fifo-muxer.mak b/tests/fate/fifo-muxer.mak
index ef8b3b3..9c13954 100644
--- a/tests/fate/fifo-muxer.mak
+++ b/tests/fate/fifo-muxer.mak
@@ -13,7 +13,7 @@ FATE_SAMPLES_FIFO_MUXER-$(call ALLYES, FIFO_MUXER, 
WAV_DEMUXER) += fate-fifo-mux
 
 fate-fifo-muxer-tst: libavformat/tests/fifo_muxer$(EXESUF)
 fate-fifo-muxer-tst: CMD = run libavformat/tests/fifo_muxer$(EXESUF)
-FATE_FIFO_MUXER-$(CONFIG_FIFO_MUXER) += fate-fifo-muxer-tst
+FATE_FIFO_MUXER-$(call ALLYES, FIFO_MUXER NETWORK) += fate-fifo-muxer-tst
 
 FATE_SAMPLES_FFMPEG += $(FATE_SAMPLES_FIFO_MUXER-yes)
 FATE_FFMPEG += $(FATE_FIFO_MUXER-yes)
-- 
2.7.4


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

Re: [FFmpeg-devel] [RFC]lavu/opt: Use && instead of * in boolean expression

[Tobias Rapp]

On 05.05.2017 09:26, Carl Eugen Hoyos wrote:

2017-05-05 3:12 GMT+02:00 Aaron Levinson :

On 5/4/2017 4:32 PM, Carl Eugen Hoyos wrote:

Hi!

It may be better to disable the warning.

Carl Eugen

-num = den ? num * intnum / den : (num * intnum ? INFINITY : NAN);
+num = den ? num * intnum / den : (num && intnum ? INFINITY : NAN);


In order to preserve the original logic, why not do the following:

+num = den ? num * intnum / den : (((num * intnum) != 0) ? INFINITY : 
NAN);


Simpler patch attached.


The GCC warning is not that bad, IMHO both proposed code alternatives 
are more readable than the original line.


Just my 2c.

Tobias


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

[FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: fix aspect ratio when writing 16:9 DV frames

[Tobias Rapp]

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 libavformat/mxfenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7289e0b..da4d7b4 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1810,7 +1810,7 @@ static int mxf_parse_dv_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pkt)
 stype= vs_pack[3] & 0x1f;
 pal  = (vs_pack[3] >> 5) & 0x1;
 
-if ((vs_pack[2] & 0x07) == 0x02)
+if ((vsc_pack[2] & 0x07) == 0x02)
 sc->aspect_ratio = (AVRational){ 16, 9 };
 else
 sc->aspect_ratio = (AVRational){ 4, 3 };
-- 
2.7.4


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

[FFmpeg-devel] [PATCH 2/2] fate: add mxf_dv25/dvcpro50 regression tests

[Tobias Rapp]

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 tests/fate/avformat.mak  |  2 ++
 tests/fate/seek.mak  |  4 +++
 tests/lavf-regression.sh |  8 ++
 tests/ref/lavf/mxf_dv25  |  3 +++
 tests/ref/lavf/mxf_dvcpro50  |  3 +++
 tests/ref/seek/lavf-mxf_dv25 | 53 
 tests/ref/seek/lavf-mxf_dvcpro50 | 53 
 7 files changed, 126 insertions(+)
 create mode 100644 tests/ref/lavf/mxf_dv25
 create mode 100644 tests/ref/lavf/mxf_dvcpro50
 create mode 100644 tests/ref/seek/lavf-mxf_dv25
 create mode 100644 tests/ref/seek/lavf-mxf_dvcpro50

diff --git a/tests/fate/avformat.mak b/tests/fate/avformat.mak
index f65ef76..c9ea99a 100644
--- a/tests/fate/avformat.mak
+++ b/tests/fate/avformat.mak
@@ -25,6 +25,8 @@ FATE_LAVF-$(call ENCDEC2, MPEG1VIDEO, MP2,   MPEG1SYSTEM 
MPEGPS) += mpg
 FATE_LAVF-$(call ENCDEC,  PCM_MULAW, PCM_MULAW)  += mulaw
 FATE_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF)+= mxf
 FATE_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF_D10 MXF)+= mxf_d10
+FATE_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, MXF)+= 
mxf_dv25
+FATE_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, MXF)+= 
mxf_dvcpro50
 FATE_LAVF-$(call ENCDEC2, DNXHD,  PCM_S16LE, MXF_OPATOM MXF) += 
mxf_opatom
 FATE_LAVF-$(call ENCDEC2, DNXHD,  PCM_S16LE, MXF_OPATOM MXF) += 
mxf_opatom_audio
 FATE_LAVF-$(call ENCDEC2, MPEG4,  MP2,   NUT)+= nut
diff --git a/tests/fate/seek.mak b/tests/fate/seek.mak
index 1a6e584..c863b2a 100644
--- a/tests/fate/seek.mak
+++ b/tests/fate/seek.mak
@@ -180,6 +180,8 @@ FATE_SEEK_LAVF-$(call ENCDEC2, MPEG1VIDEO, MP2,   
MPEG1SYSTEM MPEGPS) += mpg
 FATE_SEEK_LAVF-$(call ENCDEC,  PCM_MULAW, PCM_MULAW)   += mulaw
 FATE_SEEK_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += mxf
 FATE_SEEK_LAVF-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF_D10 MXF) += mxf_d10
+FATE_SEEK_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, MXF) += mxf_dv25
+FATE_SEEK_LAVF-$(call ENCDEC2, DVVIDEO,PCM_S16LE, MXF) += 
mxf_dvcpro50
 FATE_SEEK_LAVF-$(call ENCDEC2, DNXHD,  PCM_S16LE, MXF_OPATOM MXF) += 
mxf_opatom
 FATE_SEEK_LAVF-$(call ENCDEC2, DNXHD,  PCM_S16LE, MXF_OPATOM MXF) += 
mxf_opatom_audio
 FATE_SEEK_LAVF-$(call ENCDEC2, MPEG4,  MP2,   NUT) += nut
@@ -220,6 +222,8 @@ fate-seek-lavf-mpg:  SRC = lavf/lavf.mpg
 fate-seek-lavf-mulaw:SRC = lavf/lavf.ul
 fate-seek-lavf-mxf:  SRC = lavf/lavf.mxf
 fate-seek-lavf-mxf_d10:  SRC = lavf/lavf.mxf_d10
+fate-seek-lavf-mxf_dv25: SRC = lavf/lavf.mxf_dv25
+fate-seek-lavf-mxf_dvcpro50: SRC = lavf/lavf.mxf_dvcpro50
 fate-seek-lavf-mxf_opatom: SRC = lavf/lavf.mxf_opatom
 fate-seek-lavf-mxf_opatom_audio: SRC = lavf/lavf.mxf_opatom_audio
 fate-seek-lavf-nut:  SRC = lavf/lavf.nut
diff --git a/tests/lavf-regression.sh b/tests/lavf-regression.sh
index d9026de..45c877e 100755
--- a/tests/lavf-regression.sh
+++ b/tests/lavf-regression.sh
@@ -90,6 +90,14 @@ if [ -n "$do_mxf_d10" ]; then
 do_lavf mxf_d10 "-ar 48000 -ac 2" "-r 25 -vf scale=720:576,pad=720:608:0:32 
-vcodec mpeg2video -g 0 -flags +ildct+low_delay -dc 10 -non_linear_quant 1 
-intra_vlc 1 -qscale 1 -ps 1 -qmin 1 -rc_max_vbv_use 1 -rc_min_vbv_use 1 
-pix_fmt yuv422p -minrate 3k -maxrate 3k -b 3k -bufsize 120 
-top 1 -rc_init_occupancy 120 -qmax 12 -f mxf_d10"
 fi
 
+if [ -n "$do_mxf_dv25" ]; then
+do_lavf mxf_dv25 "-ar 48000 -ac 2" "-r 25 -vf scale=720:576,setdar=4/3 -vcodec 
dvvideo -pix_fmt yuv420p -b 25000k -top 0 -f mxf"
+fi
+
+if [ -n "$do_mxf_dvcpro50" ]; then
+do_lavf mxf_dvcpro50 "-ar 48000 -ac 2" "-r 25 -vf scale=720:576,setdar=16/9 
-vcodec dvvideo -pix_fmt yuv422p -b 5k -top 0 -f mxf"
+fi
+
 if [ -n "$do_mxf_opatom" ]; then
 do_lavf mxf_opatom "" "-s 1920x1080 -vcodec dnxhd -pix_fmt yuv422p -vb 36M -f 
mxf_opatom -map 0"
 fi
diff --git a/tests/ref/lavf/mxf_dv25 b/tests/ref/lavf/mxf_dv25
new file mode 100644
index 000..adecc07
--- /dev/null
+++ b/tests/ref/lavf/mxf_dv25
@@ -0,0 +1,3 @@
+de98603ecc27c2f3cefd192d4820d3f4 *./tests/data/lavf/lavf.mxf_dv25
+3833389 ./tests/data/lavf/lavf.mxf_dv25
+./tests/data/lavf/lavf.mxf_dv25 CRC=0xbdaf7f52
diff --git a/tests/ref/lavf/mxf_dvcpro50 b/tests/ref/lavf/mxf_dvcpro50
new file mode 100644
index 000..1d0cf79
--- /dev/null
+++ b/tests/ref/lavf/mxf_dvcpro50
@@ -0,0 +1,3 @@
+6c9cb62911ac16c3b55f0ad0b052c05b *./tests/data/lavf/lavf.mxf_dvcpro50
+7430189 ./tests/data/lavf/lavf.mxf_dvcpro50
+./tests/data/lavf/lavf.mxf_dvcpro50 CRC=0xe3bbe4b4
diff --git a/tests/ref/seek/lavf-mxf_dv25 b/tests/ref/seek/lavf-mxf_dv25
new file mode 100644
index 000..42b3bbd
--- /dev/null
+++ b/tests/ref/seek/lavf-mxf_dv25
@@ -0,0 +1,53 @@
+ret: 0 st:

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: fix aspect ratio when writing 16:9 DV frames

[Tobias Rapp]

On 14.09.2017 15:55, Tomas Härdin wrote:

On 2017-09-14 15:44, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  libavformat/mxfenc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7289e0b..da4d7b4 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1810,7 +1810,7 @@ static int mxf_parse_dv_frame(AVFormatContext 
*s, AVStream *st, AVPacket *pkt)

  stype    = vs_pack[3] & 0x1f;
  pal  = (vs_pack[3] >> 5) & 0x1;
-    if ((vs_pack[2] & 0x07) == 0x02)
+    if ((vsc_pack[2] & 0x07) == 0x02)
  sc->aspect_ratio = (AVRational){ 16, 9 };
  else
  sc->aspect_ratio = (AVRational){ 4, 3 };


Might want to add some { } around those two cases while you're at it


Added to the list of cosmetic changes that I'll apply after this patch 
is accepted. See attached file for reference.


Regards,
Tobias
From 2a4a95b4d930bb5b511576ab2932969a37766adf Mon Sep 17 00:00:00 2001
From: Tobias Rapp <t.r...@noa-archive.com>
Date: Thu, 14 Sep 2017 16:05:31 +0200
Subject: [PATCH] avformat/mxfenc: cosmetic changes

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 libavformat/mxfenc.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index da4d7b4..b8d3030 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -846,7 +846,7 @@ static void mxf_write_track(AVFormatContext *s, AVStream 
*st, enum MXFMetadataSe
 // write edit rate
 mxf_write_local_tag(pb, 8, 0x4B01);
 
-if (st == mxf->timecode_track && s->oformat == _mxf_opatom_muxer){
+if (st == mxf->timecode_track && s->oformat == _mxf_opatom_muxer) {
 avio_wb32(pb, mxf->tc.rate.num);
 avio_wb32(pb, mxf->tc.rate.den);
 } else {
@@ -882,7 +882,7 @@ static void mxf_write_common_fields(AVFormatContext *s, 
AVStream *st)
 // write duration
 mxf_write_local_tag(pb, 8, 0x0202);
 
-if (st != mxf->timecode_track && s->oformat == _mxf_opatom_muxer && 
st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO){
+if (st != mxf->timecode_track && s->oformat == _mxf_opatom_muxer && 
st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
 avio_wb64(pb, mxf->body_offset / mxf->edit_unit_byte_count);
 } else {
 avio_wb64(pb, mxf->duration);
@@ -1194,7 +1194,7 @@ static void 
mxf_write_generic_sound_common(AVFormatContext *s, AVStream *st, con
 
 mxf_write_generic_desc(s, st, key, size+duration_size+5+12+8+8);
 
-if (duration_size > 0){
+if (duration_size > 0) {
 mxf_write_local_tag(pb, 8, 0x3002);
 avio_wb64(pb, mxf->body_offset / mxf->edit_unit_byte_count);
 }
@@ -1328,7 +1328,7 @@ static void mxf_write_package(AVFormatContext *s, enum 
MXFMetadataSetType type,
 // write uid
 mxf_write_local_tag(pb, 16, 0x3C0A);
 mxf_write_uuid(pb, type, 0);
-av_log(s,AV_LOG_DEBUG, "package type:%d\n", type);
+av_log(s, AV_LOG_DEBUG, "package type:%d\n", type);
 PRINT_KEY(s, "package uid", pb->buf_ptr - 16);
 
 // write package umid
@@ -1770,7 +1770,7 @@ AVPacket *pkt)
 sc->codec_ul = _essence_container_uls[sc->index].codec_ul;
 sc->aspect_ratio = (AVRational){ 16, 9 };
 
-if(s->oformat == _mxf_opatom_muxer){
+if (s->oformat == _mxf_opatom_muxer) {
 mxf->edit_unit_byte_count = frame_size;
 return 1;
 }
@@ -1810,10 +1810,11 @@ static int mxf_parse_dv_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pkt)
 stype= vs_pack[3] & 0x1f;
 pal  = (vs_pack[3] >> 5) & 0x1;
 
-if ((vsc_pack[2] & 0x07) == 0x02)
+if ((vsc_pack[2] & 0x07) == 0x02) {
 sc->aspect_ratio = (AVRational){ 16, 9 };
-else
+} else {
 sc->aspect_ratio = (AVRational){ 4, 3 };
+}
 
 sc->interlaced = (vsc_pack[3] >> 4) & 0x01;
 // TODO: fix dv encoder to set proper FF/FS value in VSC pack
@@ -2097,7 +2098,7 @@ static int mxf_write_header(AVFormatContext *s)
 if (!s->nb_streams)
 return -1;
 
-if (s->oformat == _mxf_opatom_muxer && s->nb_streams !=1){
+if (s->oformat == _mxf_opatom_muxer && s->nb_streams !=1) {
 av_log(s, AV_LOG_ERROR, "there must be exactly one stream for mxf 
opatom\n");
 return -1;
 }
@@ -2212,7 +2213,7 @@ static int mxf_write_header(AVFormatContext *s)
 }
 
 spf = ff_mxf_get_samples_per_frame(s, tbc);
-if (!spf){
+if (!spf) {
 av_log(s, AV_LOG_ERROR, "Unsupported timecode frame rate 
%d/%d\n", tbc.den, tbc.num);
 return AVERROR(EINVAL);

[FFmpeg-devel] [PATCH v3] fate: add tests for psnr and ssim filter

[Tobias Rapp]

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
tested on Linux x86-32/64 and Mips (Qemu)

v3:
 - avoid precision loss due to rounding of float values

v2:
 - removed CPUFLAGS work-around for ssim filter issue
 - added metadata float value post-processing script

 tests/fate-run.sh |  9 ++
 tests/fate/filter-video.mak   | 14 
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 ++
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 ++
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 +
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 +
 tests/refcmp-metadata.awk | 61 +++
 7 files changed, 234 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
 create mode 100644 tests/refcmp-metadata.awk

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 9aa9a22..c5480c7 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -234,6 +234,15 @@ lavftest(){
 ${base}/lavf-regression.sh $t lavf tests/vsynth1 "$target_exec" 
"$target_path" "$threads" "$thread_type" "$cpuflags" "$target_samples"
 }
 
+refcmp_metadata(){
+refcmp=$1
+pixfmt=$2
+fuzz=${3:-0.001}
+ffmpeg $FLAGS $ENC_OPTS \
+-lavfi 
"testsrc2=size=300x200:rate=1:duration=5,format=${pixfmt},split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]${refcmp},metadata=print:file=-"
 \
+-f null /dev/null | awk -v ref=${ref} -v fuzz=${fuzz} -f 
${base}/refcmp-metadata.awk -
+}
+
 video_filter(){
 filters=$1
 shift
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index d1e1341..78cd471 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -747,6 +747,20 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed 
-i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
 
+REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER METADATA_FILTER
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-rgb
+fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-rgb
+fate-filter-refcmp-ssim-rgb: CMD = refcmp_metadata ssim rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim-yuv: CMD = refcmp_metadata ssim yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb 
b/tests/ref/fate/filter-refcmp-psnr-rgb
new file mode 100644
index 000..7d413f4
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0  
+lavfi.psnr.mse.r=1381.80
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=896.00
+lavfi.psnr.psnr.g=18.61
+lavfi.psnr.mse.b=277.38
+lavfi.psnr.psnr.b=23.70
+lavfi.psnr.mse_avg=851.73
+lavfi.psnr.psnr_avg=18.83
+frame:1pts:1   pts_time:1  
+lavfi.psnr.mse.r=1380.37
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=975.91
+lavfi.psnr.psnr.g=18.24
+lavfi.psnr.mse.b=435.72
+lavfi.psnr.psnr.b=21.74
+lavfi.psnr.mse_avg=930.67
+lavfi.psnr.psnr_avg=18.44
+frame:2pts:2   pts_time:2  
+lavfi.psnr.mse.r=1403.20
+lavfi.psnr.psnr.r=16.66
+lavfi.psnr.mse.g=954.05
+lavfi.psnr.psnr.g=18.34
+lavfi.psnr.mse.b=494.22
+lavfi.psnr.psnr.b=21.19
+lavfi.psnr.mse_avg=950.49
+lavfi.psnr.psnr_avg=18.35
+frame:3pts:3   pts_time:3  
+lavfi.psnr.mse.r=1452.80
+lavfi.psnr.psnr.r=16.51
+lavfi.psnr.mse.g=1001.02
+lavfi.psnr.psnr.g=18.13
+lavfi.psnr.mse.b=557.39
+lavfi.psnr.psnr.b=20.67
+lavfi.psnr.mse_avg=1003.74
+lavfi.psnr.psnr_avg=18.11
+frame:4pts:4   pts_time:4  
+lavfi.psnr.mse.r=1401.25
+lavfi.psnr.psnr.r=16.67
+lavfi.psnr.mse.g=1009.80
+lavfi.psnr.psnr.g=18.09
+lavfi.psnr.mse.b=602.42
+lavfi.psnr.psnr.b=20.33
+lavfi.psnr.mse_avg=1004.49
+lavfi.psnr.psnr_avg=18.11
diff --git a/tests/ref/fate/filter-refcmp-psnr-yuv 
b/tests/ref/fate/filter-refcmp-psnr-yuv
new file mode 100644
index 000..942542a
--- /dev/null
+++ b/tes

Re: [FFmpeg-devel] [PATCH v3] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 20.09.2017 01:38, Michael Niedermayer wrote:

On Tue, Sep 19, 2017 at 09:48:45AM +0200, Tobias Rapp wrote:

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
tested on Linux x86-32/64 and Mips (Qemu)

v3:
  - avoid precision loss due to rounding of float values

v2:
  - removed CPUFLAGS work-around for ssim filter issue
  - added metadata float value post-processing script

  tests/fate-run.sh |  9 ++
  tests/fate/filter-video.mak   | 14 
  tests/ref/fate/filter-refcmp-psnr-rgb | 45 ++
  tests/ref/fate/filter-refcmp-psnr-yuv | 45 ++
  tests/ref/fate/filter-refcmp-ssim-rgb | 30 +
  tests/ref/fate/filter-refcmp-ssim-yuv | 30 +
  tests/refcmp-metadata.awk | 61 +++
  7 files changed, 234 insertions(+)
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
  create mode 100644 tests/refcmp-metadata.awk


This seems not to work (normal x86-64 linux) but maybe ive done something silly

--- ./tests/ref/fate/filter-refcmp-psnr-rgb 2017-09-20 00:58:04.063337500 
+0200
+++ tests/data/fate/filter-refcmp-psnr-rgb  2017-09-20 00:59:26.399339234 
+0200
@@ -1,12 +1,3 @@
-frame:0pts:0   pts_time:0
-lavfi.psnr.mse.r=1381.80
-lavfi.psnr.psnr.r=16.73
-lavfi.psnr.mse.g=896.00
-lavfi.psnr.psnr.g=18.61
-lavfi.psnr.mse.b=277.38
-lavfi.psnr.psnr.b=23.70
-lavfi.psnr.mse_avg=851.73
-lavfi.psnr.psnr_avg=18.83
  frame:1pts:1   pts_time:1
  lavfi.psnr.mse.r=1380.37
  lavfi.psnr.psnr.r=16.73
[...]


It seems that my assumption that iterating a for-in loop with numerical 
indexes would walk the array in linear order does not apply to all 
versions of Awk. I'm testing with GNU Awk 4.1.3, what version of Awk is 
installed on your computer?


Will rework the loop and post a patch update.

Regards,
Tobias

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

[FFmpeg-devel] [PATCH v4] fate: add tests for psnr and ssim filter

[Tobias Rapp]

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
tested on Linux x86-32/64 and Mips (Qemu)

v4:
 - fixed iteration order of final print loop
 - update of debug output

v3:
 - avoid precision loss due to rounding of float values

v2:
 - removed CPUFLAGS work-around for ssim filter issue
 - added metadata float value post-processing script

 tests/fate-run.sh |  9 +
 tests/fate/filter-video.mak   | 14 
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 
 tests/refcmp-metadata.awk | 64 +++
 7 files changed, 237 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
 create mode 100644 tests/refcmp-metadata.awk

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 9aa9a22..c5480c7 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -234,6 +234,15 @@ lavftest(){
 ${base}/lavf-regression.sh $t lavf tests/vsynth1 "$target_exec" 
"$target_path" "$threads" "$thread_type" "$cpuflags" "$target_samples"
 }
 
+refcmp_metadata(){
+refcmp=$1
+pixfmt=$2
+fuzz=${3:-0.001}
+ffmpeg $FLAGS $ENC_OPTS \
+-lavfi 
"testsrc2=size=300x200:rate=1:duration=5,format=${pixfmt},split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]${refcmp},metadata=print:file=-"
 \
+-f null /dev/null | awk -v ref=${ref} -v fuzz=${fuzz} -f 
${base}/refcmp-metadata.awk -
+}
+
 video_filter(){
 filters=$1
 shift
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index d1e1341..78cd471 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -747,6 +747,20 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed 
-i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
 
+REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER METADATA_FILTER
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-rgb
+fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-rgb
+fate-filter-refcmp-ssim-rgb: CMD = refcmp_metadata ssim rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim-yuv: CMD = refcmp_metadata ssim yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb 
b/tests/ref/fate/filter-refcmp-psnr-rgb
new file mode 100644
index 000..7d413f4
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0  
+lavfi.psnr.mse.r=1381.80
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=896.00
+lavfi.psnr.psnr.g=18.61
+lavfi.psnr.mse.b=277.38
+lavfi.psnr.psnr.b=23.70
+lavfi.psnr.mse_avg=851.73
+lavfi.psnr.psnr_avg=18.83
+frame:1pts:1   pts_time:1  
+lavfi.psnr.mse.r=1380.37
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=975.91
+lavfi.psnr.psnr.g=18.24
+lavfi.psnr.mse.b=435.72
+lavfi.psnr.psnr.b=21.74
+lavfi.psnr.mse_avg=930.67
+lavfi.psnr.psnr_avg=18.44
+frame:2pts:2   pts_time:2  
+lavfi.psnr.mse.r=1403.20
+lavfi.psnr.psnr.r=16.66
+lavfi.psnr.mse.g=954.05
+lavfi.psnr.psnr.g=18.34
+lavfi.psnr.mse.b=494.22
+lavfi.psnr.psnr.b=21.19
+lavfi.psnr.mse_avg=950.49
+lavfi.psnr.psnr_avg=18.35
+frame:3pts:3   pts_time:3  
+lavfi.psnr.mse.r=1452.80
+lavfi.psnr.psnr.r=16.51
+lavfi.psnr.mse.g=1001.02
+lavfi.psnr.psnr.g=18.13
+lavfi.psnr.mse.b=557.39
+lavfi.psnr.psnr.b=20.67
+lavfi.psnr.mse_avg=1003.74
+lavfi.psnr.psnr_avg=18.11
+frame:4pts:4   pts_time:4  
+lavfi.psnr.mse.r=1401.25
+lavfi.psnr.psnr.r=16.67
+lavfi.psnr.mse.g=1009.80
+lavfi.psnr.psnr.g=18.09
+lavfi.psnr.mse.b=602.42
+lavfi.psnr.psnr.b=20.33
+lavfi.psnr.mse_avg=1004.49
+lavfi.psnr.psnr_avg=18.11
diff --git a/tests/ref/fate/filter-refcmp-psnr-yuv 
b/tests/ref/fate/filter-refcmp-psnr-yuv

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_fps: clean-up filter options

[Tobias Rapp]

On 22.09.2017 01:58, Michael Niedermayer wrote:

On Thu, Sep 21, 2017 at 04:55:51PM +0200, Tobias Rapp wrote:

Align order of "start_time" option to documentation and add missing
AV_OPT_FLAG_FILTERING_PARAM flag. Fix indent of "round" named constants
and clear unused field values.

Also fix some documentation cosmetics.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  doc/filters.texi |  4 ++--
  libavfilter/vf_fps.c | 12 ++--
  2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 830de54..96b3dfd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8670,12 +8670,12 @@ It accepts the following parameters:
  The desired output frame rate. The default is @code{25}.
  
  @item round

-Rounding method.
+Timestamp (PTS) rounding method.
  
  Possible values are:

  @table @option
  @item zero
-zero round towards 0
+round towards 0
  @item inf
  round away from 0
  @item down
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 1e5d07e..0db2b48 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -65,13 +65,13 @@ typedef struct FPSContext {
  #define F AV_OPT_FLAG_FILTERING_PARAM
  static const AVOption fps_options[] = {
  { "fps", "A string describing desired output framerate", OFFSET(framerate), 
AV_OPT_TYPE_VIDEO_RATE, { .str = "25" }, 0, INT_MAX, V|F },
-{ "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, V },
  { "round", "set rounding method for timestamps", OFFSET(rounding), AV_OPT_TYPE_INT, 
{ .i64 = AV_ROUND_NEAR_INF }, 0, 5, V|F, "round" },
-{ "zero", "round towards 0",  OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_ZERO }, 0, 5, V|F, "round" },
-{ "inf",  "round away from 0",OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_INF  }, 0, 5, V|F, "round" },
-{ "down", "round towards -infty", OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_DOWN }, 0, 5, V|F, "round" },
-{ "up",   "round towards +infty", OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_UP   }, 0, 5, V|F, "round" },
-{ "near", "round to nearest", OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_NEAR_INF }, 0, 5, V|F, "round" },
+{ "zero", "round towards 0", 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_ZERO }, 0, 0, V|F, "round" },
+{ "inf",  "round away from 0",   0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_INF  }, 0, 0, V|F, "round" },
+{ "down", "round towards -infty",0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_DOWN }, 0, 0, V|F, "round" },
+{ "up",   "round towards +infty",0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_UP   }, 0, 0, V|F, "round" },
+{ "near", "round to nearest",0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_NEAR_INF }, 0, 0, V|F, "round" },
+{ "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, V|F },
  { NULL }


This breaks shorthand notation like fps=30:-0.01


The order of options according to the documentation is 
[fps]:[round]:[start_time] (see 
https://ffmpeg.org/ffmpeg-filters.html#fps). It even explicitly says:


"Alternatively, the options can be specified as a flat string: fps[:round]."

But if preferred I can update the documentation instead.

Regards,
Tobias

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

[FFmpeg-devel] [PATCH 1/2] avfilter/vf_fps: clean-up filter options

[Tobias Rapp]

Align order of "start_time" option to documentation and add missing
AV_OPT_FLAG_FILTERING_PARAM flag. Fix indent of "round" named constants
and clear unused field values.

Also fix some documentation cosmetics.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 doc/filters.texi |  4 ++--
 libavfilter/vf_fps.c | 12 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 830de54..96b3dfd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8670,12 +8670,12 @@ It accepts the following parameters:
 The desired output frame rate. The default is @code{25}.
 
 @item round
-Rounding method.
+Timestamp (PTS) rounding method.
 
 Possible values are:
 @table @option
 @item zero
-zero round towards 0
+round towards 0
 @item inf
 round away from 0
 @item down
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 1e5d07e..0db2b48 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -65,13 +65,13 @@ typedef struct FPSContext {
 #define F AV_OPT_FLAG_FILTERING_PARAM
 static const AVOption fps_options[] = {
 { "fps", "A string describing desired output framerate", 
OFFSET(framerate), AV_OPT_TYPE_VIDEO_RATE, { .str = "25" }, 0, INT_MAX, V|F },
-{ "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, V 
},
 { "round", "set rounding method for timestamps", OFFSET(rounding), 
AV_OPT_TYPE_INT, { .i64 = AV_ROUND_NEAR_INF }, 0, 5, V|F, "round" },
-{ "zero", "round towards 0",  OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_ZERO }, 0, 5, V|F, "round" },
-{ "inf",  "round away from 0",OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_INF  }, 0, 5, V|F, "round" },
-{ "down", "round towards -infty", OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_DOWN }, 0, 5, V|F, "round" },
-{ "up",   "round towards +infty", OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_UP   }, 0, 5, V|F, "round" },
-{ "near", "round to nearest", OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_NEAR_INF }, 0, 5, V|F, "round" },
+{ "zero", "round towards 0", 0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_ZERO }, 0, 0, V|F, "round" },
+{ "inf",  "round away from 0",   0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_INF  }, 0, 0, V|F, "round" },
+{ "down", "round towards -infty",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_DOWN }, 0, 0, V|F, "round" },
+{ "up",   "round towards +infty",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_UP   }, 0, 0, V|F, "round" },
+{ "near", "round to nearest",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_NEAR_INF }, 0, 0, V|F, "round" },
+{ "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, 
V|F },
 { NULL }
 };
 
-- 
2.7.4


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

[FFmpeg-devel] [PATCH 2/2] avfilter/vf_fps: add eof_action filter option

[Tobias Rapp]

Allows to specify the action to be performed when reading the last frame
from the internal FIFO buffer. By default the last frame is written to
filter output depending on the timestamp rounding method. When using
"pass" action the last frame is passed through if input duration
has not been reached yet.

Examples using an input file with 25Hz, 1.4sec duration:
 - "fps=fps=1:round=near" generates an output file of 1sec
 - "fps=fps=1:round=near:eof_action=pass" generates an output file of
   2sec

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 doc/filters.texi  | 12 
 libavfilter/version.h |  2 +-
 libavfilter/vf_fps.c  | 14 +-
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 96b3dfd..0dc6ba5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8695,6 +8695,18 @@ For example, this could be set to 0 to pad the beginning 
with duplicates of
 the first frame if a video stream starts after the audio stream or to trim any
 frames with a negative PTS.
 
+@item eof_action
+Action performed when reading the last frame.
+
+Possible values are:
+@table @option
+@item round
+Use same timestamp rounding method as used for other frames.
+@item pass
+Pass through last frame if input duration has not been reached yet.
+@end table
+The default is @code{round}.
+
 @end table
 
 Alternatively, the options can be specified as a flat string:
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 5d6aa5f..0366a66 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
 
 #define LIBAVFILTER_VERSION_MAJOR   6
 #define LIBAVFILTER_VERSION_MINOR 105
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 0db2b48..3fcb584 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -40,6 +40,12 @@
 #include "internal.h"
 #include "video.h"
 
+enum EOFAction {
+EOF_ACTION_ROUND,
+EOF_ACTION_PASS,
+EOF_ACTION_NB
+};
+
 typedef struct FPSContext {
 const AVClass *class;
 
@@ -52,6 +58,7 @@ typedef struct FPSContext {
 
 AVRational framerate;   ///< target framerate
 int rounding;   ///< AVRounding method for timestamps
+int eof_action; ///< action performed for last frame in FIFO
 
 /* statistics */
 int frames_in; ///< number of frames on input
@@ -72,6 +79,9 @@ static const AVOption fps_options[] = {
 { "up",   "round towards +infty",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_UP   }, 0, 0, V|F, "round" },
 { "near", "round to nearest",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_NEAR_INF }, 0, 0, V|F, "round" },
 { "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, 
V|F },
+{ "eof_action", "action performed for last frame", OFFSET(eof_action), 
AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_ROUND }, 0, EOF_ACTION_NB-1, V|F, 
"eof_action" },
+{ "round", "round similar to other frames",  0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_ROUND }, 0, 0, V|F, "eof_action" },
+{ "pass",  "pass through last frame",0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_PASS  }, 0, 0, V|F, "eof_action" },
 { NULL }
 };
 
@@ -151,9 +161,11 @@ static int request_frame(AVFilterLink *outlink)
 /* This is the last frame, we may have to duplicate it to match
  * the last frame duration */
 int j;
+int eof_rounding = (s->eof_action == EOF_ACTION_PASS) ? 
AV_ROUND_UP : s->rounding;
 int delta = av_rescale_q_rnd(ctx->inputs[0]->current_pts - 
s->first_pts,
  ctx->inputs[0]->time_base,
- outlink->time_base, s->rounding) 
- s->frames_out ;
+ outlink->time_base, eof_rounding) 
- s->frames_out;
+av_log(ctx, AV_LOG_DEBUG, "EOF frames_out:%d delta:%d\n", 
s->frames_out, delta);
 /* if the delta is equal to 1, it means we just need to output
  * the last frame. Greater than 1 means we will need duplicate
  * delta-1 frames */
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: fix aspect ratio when writing 16:9 DV frames

[Tobias Rapp]

On 15.09.2017 20:44, Michael Niedermayer wrote:

On Thu, Sep 14, 2017 at 03:44:41PM +0200, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  libavformat/mxfenc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 7289e0b..da4d7b4 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1810,7 +1810,7 @@ static int mxf_parse_dv_frame(AVFormatContext *s, 
AVStream *st, AVPacket *pkt)
  stype= vs_pack[3] & 0x1f;
  pal  = (vs_pack[3] >> 5) & 0x1;
  
-if ((vs_pack[2] & 0x07) == 0x02)

+if ((vsc_pack[2] & 0x07) == 0x02)
  sc->aspect_ratio = (AVRational){ 16, 9 };
  else
  sc->aspect_ratio = (AVRational){ 4, 3 };


LGTM

thanks


Applied, thanks for the review.

Tobias

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

Re: [FFmpeg-devel] [PATCH 2/2] fate: add mxf_dv25/dvcpro50 regression tests

[Tobias Rapp]

On 15.09.2017 22:43, Michael Niedermayer wrote:

On Thu, Sep 14, 2017 at 03:44:42PM +0200, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  tests/fate/avformat.mak  |  2 ++
  tests/fate/seek.mak  |  4 +++
  tests/lavf-regression.sh |  8 ++
  tests/ref/lavf/mxf_dv25  |  3 +++
  tests/ref/lavf/mxf_dvcpro50  |  3 +++
  tests/ref/seek/lavf-mxf_dv25 | 53 
  tests/ref/seek/lavf-mxf_dvcpro50 | 53 
  7 files changed, 126 insertions(+)
  create mode 100644 tests/ref/lavf/mxf_dv25
  create mode 100644 tests/ref/lavf/mxf_dvcpro50
  create mode 100644 tests/ref/seek/lavf-mxf_dv25
  create mode 100644 tests/ref/seek/lavf-mxf_dvcpro50


probably ok


Applied, thanks for the review.

Tobias

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avfilter/vf_fps: clean-up filter options

[Tobias Rapp]

On 04.10.2017 23:27, Michael Niedermayer wrote:

On Mon, Sep 25, 2017 at 01:31:18PM +0200, Tobias Rapp wrote:

Align order of "start_time" option within filter documentation to actual
implementation and add missing AV_OPT_FLAG_FILTERING_PARAM flag. Fix
indent of "round" named constants and clear unused field values.

Also fix some documentation cosmetics.


This sounds a bit like it could be split into multiple commits

but the content all LGTM


Patch split and applied, thanks for review.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/wavenc: replace literal numbers with enum constants

[Tobias Rapp]

On 30.09.2017 02:44, Michael Niedermayer wrote:

On Fri, Sep 29, 2017 at 05:08:15PM +0200, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  libavformat/wavenc.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)


LGTM


Pushed, thanks for review.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/wavenc: skip writing peak-of-peaks position when writing peaks only

[Tobias Rapp]

On 05.10.2017 00:05, Michael Niedermayer wrote:

On Wed, Oct 04, 2017 at 10:33:11AM +0200, Tobias Rapp wrote:

On 30.09.2017 02:48, Michael Niedermayer wrote:

On Fri, Sep 29, 2017 at 05:08:16PM +0200, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  libavformat/wavenc.c | 5 -
  tests/ref/lavf/wav_peak_only | 2 +-
  2 files changed, 5 insertions(+), 2 deletions(-)


The commit message doest say why this chnage is done


As I understand the BWF peak envelope chunk definition in EBU Tech
3285 - Supplement 3 the "dwPosPeakOfPeaks" field contains the
(absolute) byte position of the peak audio sample within the _data_
chunk:

"""
The peak-of-peaks is first audio sample whose absolute value is the
maximum value of the entire audio file.

Rather than storing the peak-of-peaks as a sample value, the
position of the peak of the peaks is stored. In other words, an
audio sample frame index is stored. An application then knows where
to read the peak of the peaks in the audio file. It would be more
difficult to store a value for peak since this is dependant on the
binary format of the audio
samples (integers, floats, double...).

If the value is 0x, then that means that the peak of the
peaks is unknown.
"""

As a peak-only file doesn't contain a data chunk it would make no
sense to store the data position.

But when looking at FFmpeg's implementation within wavenc.c I notice
now, that the implementation is using a totally different
interpretation of the spec and stores the peak frame index (position
relative to peak chunk data) instead.

In my opinion the current implementation of "dwPosPeakOfPeaks" is
wrong and the patch should actually be changed to always write "-1"
unconditionally until the peak-of-peaks feature is implemented
correctly. See attached patch update.


have you confirmed that files not created by ffmpeg mismatch what we
do ?

If so this is ok but
please bump the micro version of libavformat every time
this muxer behavior changes. So demuxers can know what they are dealing
with


Actually our own software (NOA MediaButler) always sets this field to 
"-1" when writing BWF files exactly due to the hassle of calculating the 
value. And when reading a Wave file for normalization the peak-of-peaks 
is re-calculated within the target time-range anyway, so this field is 
ignored.


Unfortunately I don't have access to other software that writes "levl" 
chunks but am putting Georg Lippitsch on CC as he did the implementation 
of BWF features within wavenc.c . I don't care if this patch is dropped, 
just stumbled over it when comparing FFmpeg BWF output to files of our 
own software and to the BWF specs.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/vf_fps: add eof_action filter option

[Tobias Rapp]

On 04.10.2017 23:34, Michael Niedermayer wrote:

On Mon, Sep 25, 2017 at 01:31:19PM +0200, Tobias Rapp wrote:

Allows to specify the action to be performed when reading the last frame
from the internal FIFO buffer. By default the last frame is written to
filter output depending on the timestamp rounding method. When using
"pass" action the last frame is passed through if input duration
has not been reached yet.

Examples using an input file with 25Hz, 1.4sec duration:
  - "fps=fps=1:round=near" generates an output file of 1sec
  - "fps=fps=1:round=near:eof_action=pass" generates an output file of
    2sec

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  doc/filters.texi  | 12 
  libavfilter/version.h |  2 +-
  libavfilter/vf_fps.c  | 14 +-
  3 files changed, 26 insertions(+), 2 deletions(-)


ok with me assuming noone (maybe nicolas ?) has comments


Pushed, thanks for the review.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/vf_fps: add eof_action filter option

[Tobias Rapp]

On 25.09.2017 13:31, Tobias Rapp wrote:

Allows to specify the action to be performed when reading the last frame
from the internal FIFO buffer. By default the last frame is written to
filter output depending on the timestamp rounding method. When using
"pass" action the last frame is passed through if input duration
has not been reached yet.

Examples using an input file with 25Hz, 1.4sec duration:
  - "fps=fps=1:round=near" generates an output file of 1sec
  - "fps=fps=1:round=near:eof_action=pass" generates an output file of
    2sec

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  doc/filters.texi  | 12 
  libavfilter/version.h |  2 +-
  libavfilter/vf_fps.c  | 14 +-
  3 files changed, 26 insertions(+), 2 deletions(-)

[...]


Ping.

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

Re: [FFmpeg-devel] [PATCH v5 2/2] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 27.09.2017 17:20, Carl Eugen Hoyos wrote:

2017-09-27 15:30 GMT+02:00 Tobias Rapp <t.r...@noa-archive.com>:

Metadata filter output is passed through an Awk script comparing floats


Is awk needed on the host or the target system?


Awk is started by fate-run.sh directly, so it is needed on the host 
system AFAICS. Note that Awk was already used before in fate-run.sh, 
which was one reason why I didn't use the proposed Perl script.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[Tobias Rapp]

On 04.10.2017 11:34, wm4 wrote:

On Wed, 4 Oct 2017 11:22:37 +0200
Michael Niedermayer  wrote:


On Wed, Oct 04, 2017 at 09:12:29AM +0200, wm4 wrote:

On Tue, 3 Oct 2017 21:40:58 +0200
Michael Niedermayer  wrote:
   

On Tue, Oct 03, 2017 at 03:15:13PM +0200, wm4 wrote:

From: Anton Khirnov 
 
   

Use the AVFrame.opaque_ref field. The original user's opaque_ref is
wrapped in the lavc struct and then unwrapped before the frame is
returned to the caller.


this is a ugly hack

one and the same field should not be used to hold both the
users opaque_ref as well as a structure which is itself not a user
opaque_ref


While the AVFrame is within libavcodec, it's libavcodec's frame, not
the user's. Thus your claim doesn't make too much sense. libavcodec
fully controls the meaning for its own AVFrames' opaque_ref, but
reconstruct the user's value when returning it.


i disagree


Well, you're wrong anyway.


such hacks should not be added, we do have enough hacks already


It's not a hack.


Changing the semantics of a field during its lifetime, even when only 
done within private code, is at least unexpected behavior.



AVFrames are not really seperated into isolated classes
There arent "the users AVFrames" vs. "the internal AVFrames"


Oh yes, there is the concept of an "owner" of an AVFrame, and the owner
of the AVFrame decides what opaque_ref means. It's quite literally for
free use by the owner of the reference.

That the code goes through some acrobatics to preserve opaque_ref as
passed in by get_buffer is just a feature.


its fragile to create and maintain such seperation with interfaces
that all wrap and unwrap the opaque_ref. Any mistake being a potential
security issue and or crash


This is done strictly when returning a valid AVFrame, so there is no
room for mistakes.


The room for mistake might not increase for external developers but it 
increases for internal developers (maintenance cost).



Its MUCH more robust and also easier to understand to use a sperate
field


No, it's not. If you fail to do call post_process() on returned
AVFrames (which is done by the same code which exchanges opaque_ref)
you have bugs that violate the API or crash anyway.


more so, opaque_ref is used in only 5 lines in the whole codebase,
so there is not much code to consider when using a different solution


We shouldn't add such special fields, we have enough hacks already. Is
that your only suggestion how to do this? Because it's a bad one.


What would be the drawback of using a separate field?

And please try to reduce the amount of emotions in this thread, and 
increase the amount of objective reasons.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/wavenc: skip writing peak-of-peaks position when writing peaks only

[Tobias Rapp]

On 30.09.2017 02:48, Michael Niedermayer wrote:

On Fri, Sep 29, 2017 at 05:08:16PM +0200, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  libavformat/wavenc.c | 5 -
  tests/ref/lavf/wav_peak_only | 2 +-
  2 files changed, 5 insertions(+), 2 deletions(-)


The commit message doest say why this chnage is done


As I understand the BWF peak envelope chunk definition in EBU Tech 3285 
- Supplement 3 the "dwPosPeakOfPeaks" field contains the (absolute) byte 
position of the peak audio sample within the _data_ chunk:


"""
The peak-of-peaks is first audio sample whose absolute value is the 
maximum value of the entire audio file.


Rather than storing the peak-of-peaks as a sample value, the position of 
the peak of the peaks is stored. In other words, an audio sample frame 
index is stored. An application then knows where to read the peak of the 
peaks in the audio file. It would be more difficult to store a value for 
peak since this is dependant on the binary format of the audio

samples (integers, floats, double...).

If the value is 0x, then that means that the peak of the peaks 
is unknown.

"""

As a peak-only file doesn't contain a data chunk it would make no sense 
to store the data position.


But when looking at FFmpeg's implementation within wavenc.c I notice 
now, that the implementation is using a totally different interpretation 
of the spec and stores the peak frame index (position relative to peak 
chunk data) instead.


In my opinion the current implementation of "dwPosPeakOfPeaks" is wrong 
and the patch should actually be changed to always write "-1" 
unconditionally until the peak-of-peaks feature is implemented 
correctly. See attached patch update.


Regards,
Tobias
From 07a2414a1154dd51b9da09bbd2c877363860e825 Mon Sep 17 00:00:00 2001
From: Tobias Rapp <t.r...@noa-archive.com>
Date: Fri, 29 Sep 2017 16:32:20 +0200
Subject: [PATCH v2 2/2] avformat/wavenc: skip writing incorrect peak-of-peaks
 position value

According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
should contain the absolute position to the maximum audio sample value,
but the current implementation writes the relative peak frame index
instead.

Fix the issue by writing the "unknown" value (-1) instead for now until
the feature is implemented correctly.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 libavformat/wavenc.c | 5 +
 tests/ref/lavf/wav_peak  | 2 +-
 tests/ref/lavf/wav_peak_only | 2 +-
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index adb20cb..a6060de 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -74,7 +74,6 @@ typedef struct WAVMuxContext {
 uint32_t peak_num_frames;
 uint32_t peak_outbuf_size;
 uint32_t peak_outbuf_bytes;
-uint32_t peak_pos_pop;
 uint16_t peak_pop;
 uint8_t *peak_output;
 int last_duration;
@@ -215,8 +214,6 @@ static void peak_write_frame(AVFormatContext *s)
 
 peak_of_peaks = FFMAX3(wav->peak_maxpos[c], wav->peak_maxneg[c],
wav->peak_pop);
-if (peak_of_peaks > wav->peak_pop)
-wav->peak_pos_pop = wav->peak_num_frames;
 wav->peak_pop = peak_of_peaks;
 
 if (wav->peak_outbuf_size - wav->peak_outbuf_bytes <
@@ -287,7 +284,7 @@ static int peak_write_chunk(AVFormatContext *s)
 avio_wl32(pb, wav->peak_block_size);/* frames per value */
 avio_wl32(pb, par->channels);   /* number of channels */
 avio_wl32(pb, wav->peak_num_frames);/* number of peak frames */
-avio_wl32(pb, wav->peak_pos_pop);   /* audio sample frame index */
+avio_wl32(pb, -1);  /* audio sample frame position 
(TODO) */
 avio_wl32(pb, 128); /* equal to size of header */
 avio_write(pb, timestamp, 28);  /* ASCII time stamp */
 ffio_fill(pb, 0, 60);
diff --git a/tests/ref/lavf/wav_peak b/tests/ref/lavf/wav_peak
index aa7e5fc..861b246 100644
--- a/tests/ref/lavf/wav_peak
+++ b/tests/ref/lavf/wav_peak
@@ -1,3 +1,3 @@
-35148d1f6e66b0080893851d917ecbf4 *./tests/data/lavf/lavf.peak.wav
+105805963fb767d00da056f42f32d9f3 *./tests/data/lavf/lavf.peak.wav
 89094 ./tests/data/lavf/lavf.peak.wav
 ./tests/data/lavf/lavf.peak.wav CRC=0x3a1da17e
diff --git a/tests/ref/lavf/wav_peak_only b/tests/ref/lavf/wav_peak_only
index dccd0e7..b203d03 100644
--- a/tests/ref/lavf/wav_peak_only
+++ b/tests/ref/lavf/wav_peak_only
@@ -1,2 +1,2 @@
-b609a363e6d490710ed52231a8d09d3c *./tests/data/lavf/lavf.peak_only.wav
+f1a8aeeae8069f3992c4d780436c3d23 *./tests/data/lavf/lavf.peak_only.wav
 832 ./tests/data/lavf/lavf.peak_only.wav
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH 1/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

[Tobias Rapp]

On 17.07.2017 16:19, Nicolas George wrote:

This reverts commit 04aa09c4bcf2d5a634a35da3a3ae3fc1abe30ef8.

The fate-ffm change is caused by field_order now being set
on the output format because the first frame arrives earlier.
The fate-mxf change is assumed to be the same.

Signed-off-by: Nicolas George 
---
  libavfilter/buffersrc.c | 25 +
  tests/ref/lavf/ffm  |  2 +-
  tests/ref/lavf/mxf  |  6 +++---
  3 files changed, 29 insertions(+), 4 deletions(-)

[...]
This commit seems to break transcoding of some input files on machines 
with a lot of CPU cores. See attached script that reproduces the problem 
("-threads 32" is used to simulate the situation of a multi-core CPU).


Sorry for noticing late but it took me some time to track down the 
problem and git bisecting it. The issue seems to be triggered by the 
high number of audio packets in the input file (~375 packets per 
second). Input files that have a lower audio packet rate work fine.


Regards,
Tobias
#!/bin/bash

# =
# Configuration

BASE_PATH="./debug"
INPUT_FILE="$BASE_PATH/ffmpeg-test-input.avi"
OUTPUT_FILE="$BASE_PATH/ffmpeg-test-output.avi"
TEMP_FILE="$BASE_PATH/ffmpeg-test-temp.wav"

FFMPEG_PATH="."
FFMPEG_BIN="$FFMPEG_PATH/build-linux/ffmpeg-dbg"

# =
# Create Input Files

mkdir -p "$BASE_PATH"

$FFMPEG_BIN \
  -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact \
  -f lavfi -graph 
"aevalsrc=sin(440*2*PI*t):sample_rate=48000:channel_layout=7.1" -i dummy1 \
  -f wav -codec:a pcm_f32le -t 30.0 -y "$TEMP_FILE"

$FFMPEG_BIN \
  -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact \
  -f lavfi -graph 
"testsrc2=size=720x576:rate=25:sar=16/15,noise=alls=40:allf=t+u" -i dummy1 \
  -i "$TEMP_FILE" \
  -f avi -codec:v ffvhuff -pix_fmt yuv422p -codec:a pcm_s24le -t 30.0 -y 
"$INPUT_FILE"

# =
# Create Output File

$FFMPEG_BIN \
  -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact \
  -threads 32 -probesize 50M -ss 3.0 -i "$INPUT_FILE" \
  -f avi -map 0:v -map 0:a -codec:v ffvhuff -pix_fmt yuv422p \
  -codec:a pcm_s24le -loglevel repeat+verbose -xerror \
  -y "$OUTPUT_FILE"

if [ $? -eq 0 ]; then
  echo "=== TEST SUCCEEDED ===";
else
  echo "=== TEST FAILED ===";
fi
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add test for asetnsamples filter with padding disabled

[Tobias Rapp]

On 08.09.2017 04:04, Michael Niedermayer wrote:

On Tue, Sep 05, 2017 at 03:13:15PM +0200, Tobias Rapp wrote:

Adds another test for asetnsamples filter where padding of the last
frame is switched off. Renames the existing test to make the difference
obvious.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  tests/fate/filter-audio.mak | 13 +
  .../fate/{filter-asetnsamples => filter-asetnsamples-nopad} |  2 +-
  .../fate/{filter-asetnsamples => filter-asetnsamples-pad}   |  0
  3 files changed, 10 insertions(+), 5 deletions(-)
  copy tests/ref/fate/{filter-asetnsamples => filter-asetnsamples-nopad} (99%)
  rename tests/ref/fate/{filter-asetnsamples => filter-asetnsamples-pad} (100%)


tested on linux x86-32 / 64, mips + migw32/64


Pushed, thanks for testing.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH v2] ffprobe: use consistent string for unspecified color_range value

[Tobias Rapp]

On 05.09.2017 15:28, Paul B Mahol wrote:

On 9/5/17, Tobias Rapp <t.r...@noa-archive.com> wrote:

On 29.08.2017 16:07, Tobias Rapp wrote:

Makes the handling of unspecified/unknown color_range values on stream
level consistent to the value used on frame level.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
   ffprobe.c  | 8 
   tests/ref/fate/ffprobe_compact | 4 ++--
   tests/ref/fate/ffprobe_csv | 4 ++--
   tests/ref/fate/ffprobe_default | 4 ++--
   tests/ref/fate/ffprobe_flat| 4 ++--
   tests/ref/fate/ffprobe_ini | 4 ++--
   tests/ref/fate/mxf-probe-dnxhd | 2 +-
   tests/ref/fate/mxf-probe-dv25  | 2 +-
   8 files changed, 16 insertions(+), 16 deletions(-)
[...]


I'd like to push this if there are no objections within the next two days.



LGTM


Pushed, thanks for review.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH v2] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 30.08.2017 12:08, Nicolas George wrote:

Le tridi 13 fructidor, an CCXXV, Tobias Rapp a écrit :

Metadata output is passed through an Awk script reducing precision of
floats to account for architecture differences (e.g x86-32 vs. x86-64).


I do not like that approach at all: it will miss small differences
introduced inadvertently by changes, making the test less useful, but
would detect falsely rounding differences that fall near the cutoff
(0.499 -> 0.501).

I had posted I script to make approximate comparisons of text files; I
still like this approach better.


It is true that the "precision" parameter of your approach can be half 
the "fuzz" parameter of my approach. Also the "precision" parameter 
would be defined per float value while this patch uses a normalized 
"fuzz" parameter that is scaled depending on the float value's exponent.


There are three considerations that made me choose the current path of 
implementation:


a) With the proposed patch it is possible to generate/update a reference 
file simply by using "make fate GEN=1".


b) Adding a test with slightly more tolerance than needed is better than 
having no test at all.


c) As far as I can see Perl is currently not a dependency for "make 
fate" and I didn't want to add it.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH v2] fate: add tests for psnr and ssim filter

[Tobias Rapp]

Metadata output is passed through an Awk script reducing precision of
floats to account for architecture differences (e.g x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
v2:
 - removed CPUFLAGS work-around for ssim filter issue
 - added metadata float value post-processing script

 tests/fate-run.sh |  9 +++
 tests/fate/filter-video.mak   | 14 +++
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 +++
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 +++
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 +++
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 +++
 tests/refcmp-metadata.awk | 41 +++
 7 files changed, 214 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
 create mode 100644 tests/refcmp-metadata.awk

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 9aa9a22..5af9a36 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -234,6 +234,15 @@ lavftest(){
 ${base}/lavf-regression.sh $t lavf tests/vsynth1 "$target_exec" 
"$target_path" "$threads" "$thread_type" "$cpuflags" "$target_samples"
 }
 
+refcmp_metadata(){
+refcmp=$1
+pixfmt=$2
+fuzz=${3:-0.01}
+ffmpeg $FLAGS $ENC_OPTS \
+-lavfi 
"testsrc2=size=300x200:rate=1:duration=5,format=${pixfmt},split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]${refcmp},metadata=print:file=-"
 \
+-f null /dev/null | awk -v fuzz=${fuzz} -f ${base}/refcmp-metadata.awk 
-
+}
+
 video_filter(){
 filters=$1
 shift
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 670d9de..9f2fca7 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -717,6 +717,20 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed 
-i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
 
+REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER METADATA_FILTER
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-rgb
+fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-rgb
+fate-filter-refcmp-ssim-rgb: CMD = refcmp_metadata ssim rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim-yuv: CMD = refcmp_metadata ssim yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb 
b/tests/ref/fate/filter-refcmp-psnr-rgb
new file mode 100644
index 000..16b2208
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0  
+lavfi.psnr.mse.r=1380.00
+lavfi.psnr.psnr.r=16.70
+lavfi.psnr.mse.g=896.00
+lavfi.psnr.psnr.g=18.60
+lavfi.psnr.mse.b=277.00
+lavfi.psnr.psnr.b=23.70
+lavfi.psnr.mse_avg=852.00
+lavfi.psnr.psnr_avg=18.80
+frame:1pts:1   pts_time:1  
+lavfi.psnr.mse.r=1380.00
+lavfi.psnr.psnr.r=16.70
+lavfi.psnr.mse.g=976.00
+lavfi.psnr.psnr.g=18.20
+lavfi.psnr.mse.b=436.00
+lavfi.psnr.psnr.b=21.70
+lavfi.psnr.mse_avg=931.00
+lavfi.psnr.psnr_avg=18.40
+frame:2pts:2   pts_time:2  
+lavfi.psnr.mse.r=1400.00
+lavfi.psnr.psnr.r=16.70
+lavfi.psnr.mse.g=954.00
+lavfi.psnr.psnr.g=18.30
+lavfi.psnr.mse.b=494.00
+lavfi.psnr.psnr.b=21.20
+lavfi.psnr.mse_avg=950.00
+lavfi.psnr.psnr_avg=18.40
+frame:3pts:3   pts_time:3  
+lavfi.psnr.mse.r=1450.00
+lavfi.psnr.psnr.r=16.50
+lavfi.psnr.mse.g=1000.00
+lavfi.psnr.psnr.g=18.10
+lavfi.psnr.mse.b=557.00
+lavfi.psnr.psnr.b=20.70
+lavfi.psnr.mse_avg=1000.00
+lavfi.psnr.psnr_avg=18.10
+frame:4pts:4   pts_time:4  
+lavfi.psnr.mse.r=1400.00
+lavfi.psnr.psnr.r=16.70
+lavfi.psnr.mse.g=1010.00
+lavfi.psnr.psnr.g=18.10
+lavfi.psnr.mse.b=602.00
+lavfi.psnr.psnr.b=20.30
+lavfi.psnr.mse_avg=1000.00
+lavfi.psnr.psnr_avg=18.10
diff --git a/tests/ref/fate/filter-refcmp-psnr-yuv 
b/tests/ref/fate/filter-refcmp-psnr-yuv
new file mode 100644
index 000..b84c156
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-yuv
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0  
+lavfi.psnr.mse.y=222.00
+lavfi.psnr.psnr.y=24.7

Re: [FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter

[Tobias Rapp]

On 13.09.2017 15:10, Ronald S. Bultje wrote:

Hi,

On Wed, Sep 6, 2017 at 4:04 PM, Ashish Pratap Singh 
wrote:


From: Ashish Singh 

Hi, this patch changes previous one to framesync2.
SIMD is a work in progress for this filter.

Signed-off-by: Ashish Singh 
---
  Changelog   |   1 +
  doc/filters.texi|  16 ++
  libavfilter/Makefile|   1 +
  libavfilter/allfilters.c|   1 +
  libavfilter/vf_vmafmotion.c | 413 ++
++
  libavfilter/vmaf_motion.h   |  42 +
  6 files changed, 474 insertions(+)
  create mode 100644 libavfilter/vf_vmafmotion.c
  create mode 100644 libavfilter/vmaf_motion.h



One more general comment on this filter: it appears to me that the motion
is calculated based on the reference, and we only use the "main" to apply
the metadata to. Although this makes sense from the "vmaf" filter
perspective, I'm actually wondering if - from the perspective of the
"vmafmotion" filter alone, it wouldn't be simpler to just have a single
filterpad input ("reference") and apply the metadata on it (when used by
itself). (The "vmaf" filter could still apply metadata on the "main").

What do people think? Would you prefer the "vmaf" and "vmafmotion" to
consistently apply the metadata on the "main" video frames, or would you
prefer that the "vmafmotion" filter more accurately presents which frame is
used for the motion scoring, which also happens to lead to simpler code /
filterchains?


So when I understand this correctly the "vmafmotion" filter would work 
similar (in structure) to the "idet" filter, comparing consecutive 
frames on a single filterpad input and attaching metadata to the output 
frames? Yes, that would make using the "vmafmotion" filter more simple 
and flexible, IMHO.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] fate: increase fuzz for refcmp filter tests

[Tobias Rapp]

On 29.09.2017 00:10, Michael Niedermayer wrote:

On Thu, Sep 28, 2017 at 09:27:23AM +0200, Tobias Rapp wrote:

Should fix failing tests on GNU/kFreeBSD x86_32.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
Michael: Have put you on CC as you seem to be the owner of the affected 
machines.


LGTM


Pushed, thanks.

Regards,
Tobias

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

[FFmpeg-devel] [PATCH 1/2] avformat/wavenc: replace literal numbers with enum constants

[Tobias Rapp]

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 libavformat/wavenc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index 7f3059e..adb20cb 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -331,7 +331,7 @@ static int wav_write_header(AVFormatContext *s)
 ffio_fill(pb, 0, 28);
 }
 
-if (wav->write_peak != 2) {
+if (wav->write_peak != PEAK_ONLY) {
 /* format header */
 fmt = ff_start_tag(pb, "fmt ");
 if (ff_put_wav_header(s, pb, s->streams[0]->codecpar, 0) < 0) {
@@ -363,7 +363,7 @@ static int wav_write_header(AVFormatContext *s)
 wav->maxpts = wav->last_duration = 0;
 wav->minpts = INT64_MAX;
 
-if (wav->write_peak != 2) {
+if (wav->write_peak != PEAK_ONLY) {
 /* info header */
 ff_riff_write_info(s);
 
@@ -381,7 +381,7 @@ static int wav_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 AVIOContext *pb  = s->pb;
 WAVMuxContext*wav = s->priv_data;
 
-if (wav->write_peak != 2)
+if (wav->write_peak != PEAK_ONLY)
 avio_write(pb, pkt->data, pkt->size);
 
 if (wav->write_peak) {
@@ -426,7 +426,7 @@ static int wav_write_trailer(AVFormatContext *s)
 avio_flush(pb);
 
 if (s->pb->seekable & AVIO_SEEKABLE_NORMAL) {
-if (wav->write_peak != 2 && avio_tell(pb) - wav->data < UINT32_MAX) {
+if (wav->write_peak != PEAK_ONLY && avio_tell(pb) - wav->data < 
UINT32_MAX) {
 ff_end_tag(pb, wav->data);
 avio_flush(pb);
 }
-- 
2.7.4


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

[FFmpeg-devel] [PATCH 2/2] avformat/wavenc: skip writing peak-of-peaks position when writing peaks only

[Tobias Rapp]

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 libavformat/wavenc.c | 5 -
 tests/ref/lavf/wav_peak_only | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index adb20cb..7a4acf9 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -287,7 +287,10 @@ static int peak_write_chunk(AVFormatContext *s)
 avio_wl32(pb, wav->peak_block_size);/* frames per value */
 avio_wl32(pb, par->channels);   /* number of channels */
 avio_wl32(pb, wav->peak_num_frames);/* number of peak frames */
-avio_wl32(pb, wav->peak_pos_pop);   /* audio sample frame index */
+if (wav->write_peak == PEAK_ONLY)   /* audio sample frame index */
+avio_wl32(pb, -1);
+else
+avio_wl32(pb, wav->peak_pos_pop);
 avio_wl32(pb, 128); /* equal to size of header */
 avio_write(pb, timestamp, 28);  /* ASCII time stamp */
 ffio_fill(pb, 0, 60);
diff --git a/tests/ref/lavf/wav_peak_only b/tests/ref/lavf/wav_peak_only
index dccd0e7..b203d03 100644
--- a/tests/ref/lavf/wav_peak_only
+++ b/tests/ref/lavf/wav_peak_only
@@ -1,2 +1,2 @@
-b609a363e6d490710ed52231a8d09d3c *./tests/data/lavf/lavf.peak_only.wav
+f1a8aeeae8069f3992c4d780436c3d23 *./tests/data/lavf/lavf.peak_only.wav
 832 ./tests/data/lavf/lavf.peak_only.wav
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH v4] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 20.09.2017 11:01, Tobias Rapp wrote:

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
tested on Linux x86-32/64 and Mips (Qemu)

v4:
  - fixed iteration order of final print loop
  - update of debug output

v3:
  - avoid precision loss due to rounding of float values

v2:
  - removed CPUFLAGS work-around for ssim filter issue
  - added metadata float value post-processing script

  tests/fate-run.sh |  9 +
  tests/fate/filter-video.mak   | 14 
  tests/ref/fate/filter-refcmp-psnr-rgb | 45 
  tests/ref/fate/filter-refcmp-psnr-yuv | 45 
  tests/ref/fate/filter-refcmp-ssim-rgb | 30 
  tests/ref/fate/filter-refcmp-ssim-yuv | 30 
  tests/refcmp-metadata.awk | 64 +++
  7 files changed, 237 insertions(+)
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
  create mode 100644 tests/refcmp-metadata.awk

[...]


I'd like to push this soon, if there are no objections (Nicolas?).

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_fps: clean-up filter options

[Tobias Rapp]

On 23.09.2017 17:05, Michael Niedermayer wrote:

On Fri, Sep 22, 2017 at 08:52:26AM +0200, Tobias Rapp wrote:

On 22.09.2017 01:58, Michael Niedermayer wrote:

On Thu, Sep 21, 2017 at 04:55:51PM +0200, Tobias Rapp wrote:

Align order of "start_time" option to documentation and add missing
AV_OPT_FLAG_FILTERING_PARAM flag. Fix indent of "round" named constants
and clear unused field values.

Also fix some documentation cosmetics.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  doc/filters.texi |  4 ++--
  libavfilter/vf_fps.c | 12 ++--
  2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 830de54..96b3dfd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8670,12 +8670,12 @@ It accepts the following parameters:
  The desired output frame rate. The default is @code{25}.
  @item round
-Rounding method.
+Timestamp (PTS) rounding method.
  Possible values are:
  @table @option
  @item zero
-zero round towards 0
+round towards 0
  @item inf
  round away from 0
  @item down
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 1e5d07e..0db2b48 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -65,13 +65,13 @@ typedef struct FPSContext {
  #define F AV_OPT_FLAG_FILTERING_PARAM
  static const AVOption fps_options[] = {
  { "fps", "A string describing desired output framerate", OFFSET(framerate), 
AV_OPT_TYPE_VIDEO_RATE, { .str = "25" }, 0, INT_MAX, V|F },
-{ "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, V },
  { "round", "set rounding method for timestamps", OFFSET(rounding), AV_OPT_TYPE_INT, 
{ .i64 = AV_ROUND_NEAR_INF }, 0, 5, V|F, "round" },
-{ "zero", "round towards 0",  OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_ZERO }, 0, 5, V|F, "round" },
-{ "inf",  "round away from 0",OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_INF  }, 0, 5, V|F, "round" },
-{ "down", "round towards -infty", OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_DOWN }, 0, 5, V|F, "round" },
-{ "up",   "round towards +infty", OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_UP   }, 0, 5, V|F, "round" },
-{ "near", "round to nearest", OFFSET(rounding), AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_NEAR_INF }, 0, 5, V|F, "round" },
+{ "zero", "round towards 0", 0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_ZERO }, 0, 0, V|F, "round" },
+{ "inf",  "round away from 0",   0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_INF  }, 0, 0, V|F, "round" },
+{ "down", "round towards -infty",0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_DOWN }, 0, 0, V|F, "round" },
+{ "up",   "round towards +infty",0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_UP   }, 0, 0, V|F, "round" },
+{ "near", "round to nearest",0, AV_OPT_TYPE_CONST, { .i64 = 
AV_ROUND_NEAR_INF }, 0, 0, V|F, "round" },
+{ "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, V|F },
  { NULL }


This breaks shorthand notation like fps=30:-0.01


The order of options according to the documentation is
[fps]:[round]:[start_time] (see
https://ffmpeg.org/ffmpeg-filters.html#fps). It even explicitly
says:

"Alternatively, the options can be specified as a flat string: fps[:round]."

But if preferred I can update the documentation instead.


Whichever makes more users happy.

(we maybe should avoid 2 different implementation behaviours if we
  dont already have 2, i have not checked if we had a different order in
  the code in the past)


Looking at the history of vf_fps.c apparently the current order of 
options exists since August 2013 (commit 
b69b075ac607419a840da798b089de8ea7630d4b). So it might be better to just 
update documentation to the established implementation.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH v2 1/2] avfilter/vf_fps: clean-up filter options

[Tobias Rapp]

Align order of "start_time" option within filter documentation to actual
implementation and add missing AV_OPT_FLAG_FILTERING_PARAM flag. Fix
indent of "round" named constants and clear unused field values.

Also fix some documentation cosmetics.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 doc/filters.texi | 22 +++---
 libavfilter/vf_fps.c | 12 ++--
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index b09c3a0..a46865f 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8669,13 +8669,21 @@ It accepts the following parameters:
 @item fps
 The desired output frame rate. The default is @code{25}.
 
+@item start_time
+Assume the first PTS should be the given value, in seconds. This allows for
+padding/trimming at the start of stream. By default, no assumption is made
+about the first frame's expected PTS, so no padding or trimming is done.
+For example, this could be set to 0 to pad the beginning with duplicates of
+the first frame if a video stream starts after the audio stream or to trim any
+frames with a negative PTS.
+
 @item round
-Rounding method.
+Timestamp (PTS) rounding method.
 
 Possible values are:
 @table @option
 @item zero
-zero round towards 0
+round towards 0
 @item inf
 round away from 0
 @item down
@@ -8687,18 +8695,10 @@ round to nearest
 @end table
 The default is @code{near}.
 
-@item start_time
-Assume the first PTS should be the given value, in seconds. This allows for
-padding/trimming at the start of stream. By default, no assumption is made
-about the first frame's expected PTS, so no padding or trimming is done.
-For example, this could be set to 0 to pad the beginning with duplicates of
-the first frame if a video stream starts after the audio stream or to trim any
-frames with a negative PTS.
-
 @end table
 
 Alternatively, the options can be specified as a flat string:
-@var{fps}[:@var{round}].
+@var{fps}[:@var{start_time}[:@var{round}]].
 
 See also the @ref{setpts} filter.
 
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index 1e5d07e..a5e51c3 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -65,13 +65,13 @@ typedef struct FPSContext {
 #define F AV_OPT_FLAG_FILTERING_PARAM
 static const AVOption fps_options[] = {
 { "fps", "A string describing desired output framerate", 
OFFSET(framerate), AV_OPT_TYPE_VIDEO_RATE, { .str = "25" }, 0, INT_MAX, V|F },
-{ "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, V 
},
+{ "start_time", "Assume the first PTS should be this value.", 
OFFSET(start_time), AV_OPT_TYPE_DOUBLE, { .dbl = DBL_MAX}, -DBL_MAX, DBL_MAX, 
V|F },
 { "round", "set rounding method for timestamps", OFFSET(rounding), 
AV_OPT_TYPE_INT, { .i64 = AV_ROUND_NEAR_INF }, 0, 5, V|F, "round" },
-{ "zero", "round towards 0",  OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_ZERO }, 0, 5, V|F, "round" },
-{ "inf",  "round away from 0",OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_INF  }, 0, 5, V|F, "round" },
-{ "down", "round towards -infty", OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_DOWN }, 0, 5, V|F, "round" },
-{ "up",   "round towards +infty", OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_UP   }, 0, 5, V|F, "round" },
-{ "near", "round to nearest", OFFSET(rounding), AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_NEAR_INF }, 0, 5, V|F, "round" },
+{ "zero", "round towards 0", 0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_ZERO }, 0, 0, V|F, "round" },
+{ "inf",  "round away from 0",   0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_INF  }, 0, 0, V|F, "round" },
+{ "down", "round towards -infty",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_DOWN }, 0, 0, V|F, "round" },
+{ "up",   "round towards +infty",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_UP   }, 0, 0, V|F, "round" },
+{ "near", "round to nearest",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_NEAR_INF }, 0, 0, V|F, "round" },
 { NULL }
 };
 
-- 
2.7.4


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

[FFmpeg-devel] [PATCH v2 2/2] avfilter/vf_fps: add eof_action filter option

[Tobias Rapp]

Allows to specify the action to be performed when reading the last frame
from the internal FIFO buffer. By default the last frame is written to
filter output depending on the timestamp rounding method. When using
"pass" action the last frame is passed through if input duration
has not been reached yet.

Examples using an input file with 25Hz, 1.4sec duration:
 - "fps=fps=1:round=near" generates an output file of 1sec
 - "fps=fps=1:round=near:eof_action=pass" generates an output file of
   2sec

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 doc/filters.texi  | 12 
 libavfilter/version.h |  2 +-
 libavfilter/vf_fps.c  | 14 +-
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index a46865f..1b48793 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8695,6 +8695,18 @@ round to nearest
 @end table
 The default is @code{near}.
 
+@item eof_action
+Action performed when reading the last frame.
+
+Possible values are:
+@table @option
+@item round
+Use same timestamp rounding method as used for other frames.
+@item pass
+Pass through last frame if input duration has not been reached yet.
+@end table
+The default is @code{round}.
+
 @end table
 
 Alternatively, the options can be specified as a flat string:
diff --git a/libavfilter/version.h b/libavfilter/version.h
index fb382d4..8191c59 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
 
 #define LIBAVFILTER_VERSION_MAJOR   6
 #define LIBAVFILTER_VERSION_MINOR 106
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c
index a5e51c3..dbafd2c 100644
--- a/libavfilter/vf_fps.c
+++ b/libavfilter/vf_fps.c
@@ -40,6 +40,12 @@
 #include "internal.h"
 #include "video.h"
 
+enum EOFAction {
+EOF_ACTION_ROUND,
+EOF_ACTION_PASS,
+EOF_ACTION_NB
+};
+
 typedef struct FPSContext {
 const AVClass *class;
 
@@ -52,6 +58,7 @@ typedef struct FPSContext {
 
 AVRational framerate;   ///< target framerate
 int rounding;   ///< AVRounding method for timestamps
+int eof_action; ///< action performed for last frame in FIFO
 
 /* statistics */
 int frames_in; ///< number of frames on input
@@ -72,6 +79,9 @@ static const AVOption fps_options[] = {
 { "down", "round towards -infty",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_DOWN }, 0, 0, V|F, "round" },
 { "up",   "round towards +infty",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_UP   }, 0, 0, V|F, "round" },
 { "near", "round to nearest",0, AV_OPT_TYPE_CONST, { 
.i64 = AV_ROUND_NEAR_INF }, 0, 0, V|F, "round" },
+{ "eof_action", "action performed for last frame", OFFSET(eof_action), 
AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_ROUND }, 0, EOF_ACTION_NB-1, V|F, 
"eof_action" },
+{ "round", "round similar to other frames",  0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_ROUND }, 0, 0, V|F, "eof_action" },
+{ "pass",  "pass through last frame",0, AV_OPT_TYPE_CONST, { 
.i64 = EOF_ACTION_PASS  }, 0, 0, V|F, "eof_action" },
 { NULL }
 };
 
@@ -151,9 +161,11 @@ static int request_frame(AVFilterLink *outlink)
 /* This is the last frame, we may have to duplicate it to match
  * the last frame duration */
 int j;
+int eof_rounding = (s->eof_action == EOF_ACTION_PASS) ? 
AV_ROUND_UP : s->rounding;
 int delta = av_rescale_q_rnd(ctx->inputs[0]->current_pts - 
s->first_pts,
  ctx->inputs[0]->time_base,
- outlink->time_base, s->rounding) 
- s->frames_out ;
+ outlink->time_base, eof_rounding) 
- s->frames_out;
+av_log(ctx, AV_LOG_DEBUG, "EOF frames_out:%d delta:%d\n", 
s->frames_out, delta);
 /* if the delta is equal to 1, it means we just need to output
  * the last frame. Greater than 1 means we will need duplicate
  * delta-1 frames */
-- 
2.7.4


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

[FFmpeg-devel] [PATCH] fate: increase fuzz for refcmp filter tests

[Tobias Rapp]

Should fix failing tests on GNU/kFreeBSD x86_32.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
Michael: Have put you on CC as you seem to be the owner of the affected 
machines.

 tests/fate/filter-video.mak | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 78cd471..c19f301 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -750,16 +750,16 @@ fate-filter-meta-4560-rotate0: CMD = framecrc -flags 
+bitexact -c:a aac_fixed -i
 REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER METADATA_FILTER
 
 FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-rgb
-fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24
+fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24 0.001
 
 FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-yuv
-fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p
+fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p 0.0015
 
 FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-rgb
-fate-filter-refcmp-ssim-rgb: CMD = refcmp_metadata ssim rgb24
+fate-filter-refcmp-ssim-rgb: CMD = refcmp_metadata ssim rgb24 0.015
 
 FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-yuv
-fate-filter-refcmp-ssim-yuv: CMD = refcmp_metadata ssim yuv422p
+fate-filter-refcmp-ssim-yuv: CMD = refcmp_metadata ssim yuv422p 0.015
 
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH v4] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 26.09.2017 09:54, Tobias Rapp wrote:

On 20.09.2017 11:01, Tobias Rapp wrote:

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
tested on Linux x86-32/64 and Mips (Qemu)

v4:
  - fixed iteration order of final print loop
  - update of debug output

v3:
  - avoid precision loss due to rounding of float values

v2:
  - removed CPUFLAGS work-around for ssim filter issue
  - added metadata float value post-processing script

  tests/fate-run.sh |  9 +
  tests/fate/filter-video.mak   | 14 
  tests/ref/fate/filter-refcmp-psnr-rgb | 45 
  tests/ref/fate/filter-refcmp-psnr-yuv | 45 
  tests/ref/fate/filter-refcmp-ssim-rgb | 30 
  tests/ref/fate/filter-refcmp-ssim-yuv | 30 
  tests/refcmp-metadata.awk | 64 
+++

  7 files changed, 237 insertions(+)
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
  create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
  create mode 100644 tests/refcmp-metadata.awk

[...]


I'd like to push this soon, if there are no objections (Nicolas?).


Unfortunately the patch could not be applied as the reference files 
contain trailing whitespace.


Not sure what would be the preferred way to fix this:
- somehow change the git attributes to treat the reference files as 
binary (if possible)

- change the fate test to trim filter output line-by-line
- change the metadata filter itself to trim the affected lines
?

Regards,
Tobias

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

[FFmpeg-devel] [PATCH v5 1/2] avfilter/f_metadata: avoid trailing whitespace in filter output

[Tobias Rapp]

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 libavfilter/f_metadata.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index 23bc254..523a94d 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -314,14 +314,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 break;
 case METADATA_PRINT:
 if (!s->key && e) {
-s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%-7s\n",
+s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%s\n",
  inlink->frame_count_out, av_ts2str(frame->pts), 
av_ts2timestr(frame->pts, >time_base));
 s->print(ctx, "%s=%s\n", e->key, e->value);
 while ((e = av_dict_get(*metadata, "", e, AV_DICT_IGNORE_SUFFIX)) 
!= NULL) {
 s->print(ctx, "%s=%s\n", e->key, e->value);
 }
 } else if (e && e->value && (!s->value || (e->value && s->compare(s, 
e->value, s->value {
-s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%-7s\n",
+s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%s\n",
  inlink->frame_count_out, av_ts2str(frame->pts), 
av_ts2timestr(frame->pts, >time_base));
 s->print(ctx, "%s=%s\n", s->key, e->value);
 }
-- 
2.7.4


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

[FFmpeg-devel] [PATCH v5 2/2] fate: add tests for psnr and ssim filter

[Tobias Rapp]

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
tested on Linux x86-32/64 and Mips (Qemu)

v5:
  - fixed trailing whitespace within reference files

v4:
  - fixed iteration order of final print loop
  - update of debug output

v3:
  - avoid precision loss due to rounding of float values

v2:
  - removed CPUFLAGS work-around for ssim filter issue
  - added metadata float value post-processing script

 tests/fate-run.sh |  9 +
 tests/fate/filter-video.mak   | 14 
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 
 tests/refcmp-metadata.awk | 64 +++
 7 files changed, 237 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
 create mode 100644 tests/refcmp-metadata.awk

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 9aa9a22..c5480c7 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -234,6 +234,15 @@ lavftest(){
 ${base}/lavf-regression.sh $t lavf tests/vsynth1 "$target_exec" 
"$target_path" "$threads" "$thread_type" "$cpuflags" "$target_samples"
 }
 
+refcmp_metadata(){
+refcmp=$1
+pixfmt=$2
+fuzz=${3:-0.001}
+ffmpeg $FLAGS $ENC_OPTS \
+-lavfi 
"testsrc2=size=300x200:rate=1:duration=5,format=${pixfmt},split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]${refcmp},metadata=print:file=-"
 \
+-f null /dev/null | awk -v ref=${ref} -v fuzz=${fuzz} -f 
${base}/refcmp-metadata.awk -
+}
+
 video_filter(){
 filters=$1
 shift
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index d1e1341..78cd471 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -747,6 +747,20 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed 
-i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
 
+REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER METADATA_FILTER
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-rgb
+fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-rgb
+fate-filter-refcmp-ssim-rgb: CMD = refcmp_metadata ssim rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim-yuv: CMD = refcmp_metadata ssim yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb 
b/tests/ref/fate/filter-refcmp-psnr-rgb
new file mode 100644
index 000..f06db57
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0
+lavfi.psnr.mse.r=1381.80
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=896.00
+lavfi.psnr.psnr.g=18.61
+lavfi.psnr.mse.b=277.38
+lavfi.psnr.psnr.b=23.70
+lavfi.psnr.mse_avg=851.73
+lavfi.psnr.psnr_avg=18.83
+frame:1pts:1   pts_time:1
+lavfi.psnr.mse.r=1380.37
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=975.91
+lavfi.psnr.psnr.g=18.24
+lavfi.psnr.mse.b=435.72
+lavfi.psnr.psnr.b=21.74
+lavfi.psnr.mse_avg=930.67
+lavfi.psnr.psnr_avg=18.44
+frame:2pts:2   pts_time:2
+lavfi.psnr.mse.r=1403.20
+lavfi.psnr.psnr.r=16.66
+lavfi.psnr.mse.g=954.05
+lavfi.psnr.psnr.g=18.34
+lavfi.psnr.mse.b=494.22
+lavfi.psnr.psnr.b=21.19
+lavfi.psnr.mse_avg=950.49
+lavfi.psnr.psnr_avg=18.35
+frame:3pts:3   pts_time:3
+lavfi.psnr.mse.r=1452.80
+lavfi.psnr.psnr.r=16.51
+lavfi.psnr.mse.g=1001.02
+lavfi.psnr.psnr.g=18.13
+lavfi.psnr.mse.b=557.39
+lavfi.psnr.psnr.b=20.67
+lavfi.psnr.mse_avg=1003.74
+lavfi.psnr.psnr_avg=18.11
+frame:4pts:4   pts_time:4
+lavfi.psnr.mse.r=1401.25
+lavfi.psnr.psnr.r=16.67
+lavfi.psnr.mse.g=1009.80
+lavfi.psnr.psnr.g=18.09
+lavfi.psnr.mse.b=602.42
+lavfi.psnr.psnr.b=20.33
+lavfi.psnr.mse_avg=1004.49
+lavfi.psnr.psnr_avg=18.11
diff --git a/tests/ref/fate/filter-refcmp-psnr-yuv 
b/test

Re: [FFmpeg-devel] [PATCH v5 1/2] avfilter/f_metadata: avoid trailing whitespace in filter output

[Tobias Rapp]

On 27.09.2017 15:50, Paul B Mahol wrote:

On 9/27/17, Tobias Rapp <t.r...@noa-archive.com> wrote:

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  libavfilter/f_metadata.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)



lgtm


Pushed both patches.

Thanks,
Tobias

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

Re: [FFmpeg-devel] [PATCH v3] fate: add tests for some video source filters

[Tobias Rapp]

On 31.08.2017 02:50, Michael Niedermayer wrote:

On Tue, Aug 29, 2017 at 04:49:58PM +0200, Tobias Rapp wrote:

On 25.07.2017 11:11, Tobias Rapp wrote:

Adds FATE tests for the previously untested allrgb, allyuv, rgbtestsrc,
smptebars, smptehdbars and yuvtestsrc filters.

Also adds a test for testsrc2 filter with rgb+alpha.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  tests/fate/filter-video.mak| 24 ++
  tests/ref/fate/filter-allrgb   | 10 
  tests/ref/fate/filter-allyuv   | 10 
  tests/ref/fate/filter-rgbtestsrc   | 10 
  tests/ref/fate/filter-smptebars| 10 
  tests/ref/fate/filter-smptehdbars  | 10 
  tests/ref/fate/filter-testsrc2-rgba| 75 ++
  tests/ref/fate/filter-yuvtestsrc-yuv444p   | 10 
  tests/ref/fate/filter-yuvtestsrc-yuv444p12 | 10 
  9 files changed, 169 insertions(+)
  create mode 100644 tests/ref/fate/filter-allrgb
  create mode 100644 tests/ref/fate/filter-allyuv
  create mode 100644 tests/ref/fate/filter-rgbtestsrc
  create mode 100644 tests/ref/fate/filter-smptebars
  create mode 100644 tests/ref/fate/filter-smptehdbars
  create mode 100644 tests/ref/fate/filter-testsrc2-rgba
  create mode 100644 tests/ref/fate/filter-yuvtestsrc-yuv444p
  create mode 100644 tests/ref/fate/filter-yuvtestsrc-yuv444p12

[...]


Ping.


tested on x86 32 /64 arm mips linux // mingw32/64

LGTM

thx



Pushed, thanks for comprehensive testing!

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] libavcodec: fix field_order labelling

[Tobias Rapp]

On 27.08.2017 19:13, Marton Balint wrote:



On Sat, 12 Aug 2017, Dave Rice wrote:

[..]

Also utils.c associates these field order values with the following 
labels:



AV_FIELD_TB  -> "top coded first (swapped)";
AV_FIELD_BT -> "bottom coded first (swapped)";


From my reading, I infer that "top coded first (swapped)” means "top 
coded first, bottom displayed first”; however in practice from files 
generated by QuickTime and FFmpeg files with a value of TB have the 
top field displayed first, so I think the labels are swapped. In the 
patch below I suggest using “top first (interleaved)” for TB and 
“bottom first (interleaved)” for BT.


Comments?


From de871b3fa891fa0ae6856461c1f8305cc889cde7 Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Sat, 12 Aug 2017 12:30:43 -0400
Subject: [PATCH] libavcodec: fix field_order labelling

---
libavcodec/avcodec.h | 4 ++--
libavcodec/utils.c   | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c594993766..37c39072b3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1726,8 +1726,8 @@ enum AVFieldOrder {
    AV_FIELD_PROGRESSIVE,
    AV_FIELD_TT,  //< Top coded_first, top displayed first
    AV_FIELD_BB,  //< Bottom coded first, bottom displayed first
-    AV_FIELD_TB,  //< Top coded first, bottom displayed first
-    AV_FIELD_BT,  //< Bottom coded first, top displayed first
+    AV_FIELD_TB,  //< Interleaved coding, top displayed first
+    AV_FIELD_BT,  //< Interleaved coding, bottom displayed first
};


I agree that a lot of stuff in the codebase is consistent with the 
updated descriptions. However, as far as I see libavformat/mxfdec.c 
seems to follow the existing docs, so I think that needs changing as well.


In mxfdec.c the value of field_order is constructed from VideoLineMap 
and FieldDominance. The VideoLineMap property indicates coded field 
order and the FieldDominance property indicated whether display field 
order is flipped compared to the coded order or not.


So yes, mxfdec.c is following the current documentation of AVFieldOrder 
and applying the patch would conflict with the MXF specs, AFAICS.


CC-ing Jérôme Martinez as he has much more experience with MXF 
real-world file variations.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH v2] ffprobe: use consistent string for unspecified color_range value

[Tobias Rapp]

Makes the handling of unspecified/unknown color_range values on stream
level consistent to the value used on frame level.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 ffprobe.c  | 8 
 tests/ref/fate/ffprobe_compact | 4 ++--
 tests/ref/fate/ffprobe_csv | 4 ++--
 tests/ref/fate/ffprobe_default | 4 ++--
 tests/ref/fate/ffprobe_flat| 4 ++--
 tests/ref/fate/ffprobe_ini | 4 ++--
 tests/ref/fate/mxf-probe-dnxhd | 2 +-
 tests/ref/fate/mxf-probe-dv25  | 2 +-
 8 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/ffprobe.c b/ffprobe.c
index ba10563..b2e8949 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -1925,11 +1925,11 @@ static void print_pkt_side_data(WriterContext *w,
 writer_print_section_footer(w);
 }
 
-static void print_color_range(WriterContext *w, enum AVColorRange color_range, 
const char *fallback)
+static void print_color_range(WriterContext *w, enum AVColorRange color_range)
 {
 const char *val = av_color_range_name(color_range);
 if (!val || color_range == AVCOL_RANGE_UNSPECIFIED) {
-print_str_opt("color_range", fallback);
+print_str_opt("color_range", "unknown");
 } else {
 print_str("color_range", val);
 }
@@ -2157,7 +2157,7 @@ static void show_frame(WriterContext *w, AVFrame *frame, 
AVStream *stream,
 print_int("top_field_first",frame->top_field_first);
 print_int("repeat_pict",frame->repeat_pict);
 
-print_color_range(w, frame->color_range, "unknown");
+print_color_range(w, frame->color_range);
 print_color_space(w, frame->colorspace);
 print_primaries(w, frame->color_primaries);
 print_color_trc(w, frame->color_trc);
@@ -2534,7 +2534,7 @@ static int show_stream(WriterContext *w, AVFormatContext 
*fmt_ctx, int stream_id
 else   print_str_opt("pix_fmt", "unknown");
 print_int("level",   par->level);
 
-print_color_range(w, par->color_range, "N/A");
+print_color_range(w, par->color_range);
 print_color_space(w, par->color_space);
 print_color_trc(w, par->color_trc);
 print_primaries(w, par->color_primaries);
diff --git a/tests/ref/fate/ffprobe_compact b/tests/ref/fate/ffprobe_compact
index 910837d..4a0f4ee 100644
--- a/tests/ref/fate/ffprobe_compact
+++ b/tests/ref/fate/ffprobe_compact
@@ -27,6 +27,6 @@ 
frame|media_type=video|stream_index=1|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12
 
packet|codec_type=video|stream_index=2|pts=6144|pts_time=0.12|dts=6144|dts_time=0.12|duration=2048|duration_time=0.04|convergence_duration=N/A|convergence_duration_time=N/A|size=3|pos=1023544|flags=K_
 
frame|media_type=video|stream_index=2|key_frame=1|pkt_pts=6144|pkt_pts_time=0.12|pkt_dts=6144|pkt_dts_time=0.12|best_effort_timestamp=6144|best_effort_timestamp_time=0.12|pkt_duration=2048|pkt_duration_time=0.04|pkt_pos=1023544|pkt_size=3|width=100|height=100|pix_fmt=rgb24|sample_aspect_ratio=1:1|pict_type=I|coded_picture_number=0|display_picture_number=0|interlaced_frame=0|top_field_first=0|repeat_pict=0|color_range=unknown|color_space=unknown|color_primaries=unknown|color_transfer=unknown|chroma_location=unspecified
 
stream|index=0|codec_name=pcm_s16le|profile=unknown|codec_type=audio|codec_time_base=1/44100|codec_tag_string=PSD[16]|codec_tag=0x10445350|sample_fmt=s16|sample_rate=44100|channels=1|channel_layout=unknown|bits_per_sample=16|id=N/A|r_frame_rate=0/0|avg_frame_rate=0/0|time_base=1/44100|start_pts=0|start_time=0.00|duration_ts=N/A|duration=N/A|bit_rate=705600|max_bit_rate=N/A|bits_per_raw_sample=N/A|nb_frames=N/A|nb_read_frames=6|nb_read_packets=6|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnails=0|tag:E=mc²|tag:encoder=Lavc
 pcm_s16le
-stream|index=1|codec_name=rawvideo|profile=unknown|codec_type=video|codec_time_base=1/25|codec_tag_string=RGB[24]|codec_tag=0x18424752|width=320|height=240|coded_width=320|coded_height=240|has_b_frames=0|sample_aspect_ratio=1:1|display_aspect_ratio=4:3|pix_fmt=rgb24|level=-99|color_range=N/A|color_space=unknown|color_transfer=unknown|color_primaries=unknown|chroma_location=unspecified|field_order=unknown|timecode=N/A|refs=1|id=N/A|r_frame_rate=25/1|avg_frame_rate=25/1|time_base=1/51200|start_pts=0|start_time=0.00|duration_ts=N/A|duration=N/A|bit_rate=N/A|max_bit_rate=N/A|bits_per_raw_sample=N/A|nb_frames=N/A|nb_read_frames=4|nb_read_packets=4|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposit

Re: [FFmpeg-devel] [PATCH v2] ffprobe: use consistent string for unspecified color_range value

[Tobias Rapp]

On 29.08.2017 16:07, Tobias Rapp wrote:

Makes the handling of unspecified/unknown color_range values on stream
level consistent to the value used on frame level.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  ffprobe.c  | 8 
  tests/ref/fate/ffprobe_compact | 4 ++--
  tests/ref/fate/ffprobe_csv | 4 ++--
  tests/ref/fate/ffprobe_default | 4 ++--
  tests/ref/fate/ffprobe_flat| 4 ++--
  tests/ref/fate/ffprobe_ini | 4 ++--
  tests/ref/fate/mxf-probe-dnxhd | 2 +-
  tests/ref/fate/mxf-probe-dv25  | 2 +-
  8 files changed, 16 insertions(+), 16 deletions(-)
[...]


I'd like to push this if there are no objections within the next two days.

Regards,
Tobias

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

[FFmpeg-devel] [PATCH] fate: add test for asetnsamples filter with padding disabled

[Tobias Rapp]

Adds another test for asetnsamples filter where padding of the last
frame is switched off. Renames the existing test to make the difference
obvious.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 tests/fate/filter-audio.mak | 13 +
 .../fate/{filter-asetnsamples => filter-asetnsamples-nopad} |  2 +-
 .../fate/{filter-asetnsamples => filter-asetnsamples-pad}   |  0
 3 files changed, 10 insertions(+), 5 deletions(-)
 copy tests/ref/fate/{filter-asetnsamples => filter-asetnsamples-nopad} (99%)
 rename tests/ref/fate/{filter-asetnsamples => filter-asetnsamples-pad} (100%)

diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 5035e8f..35ad0f8 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -84,10 +84,15 @@ fate-filter-anequalizer: tests/data/filtergraphs/anequalizer
 fate-filter-anequalizer: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
 fate-filter-anequalizer: CMD = framecrc -i $(SRC) -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/anequalizer
 
-FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETNSAMPLES, WAV, PCM_S16LE, 
PCM_S16LE, WAV) += fate-filter-asetnsamples
-fate-filter-asetnsamples: tests/data/asynth-44100-2.wav
-fate-filter-asetnsamples: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
-fate-filter-asetnsamples: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETNSAMPLES, WAV, PCM_S16LE, 
PCM_S16LE, WAV) += fate-filter-asetnsamples-pad
+fate-filter-asetnsamples-pad: tests/data/asynth-44100-2.wav
+fate-filter-asetnsamples-pad: SRC = 
$(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-asetnsamples-pad: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1
+
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETNSAMPLES, WAV, PCM_S16LE, 
PCM_S16LE, WAV) += fate-filter-asetnsamples-nopad
+fate-filter-asetnsamples-nopad: tests/data/asynth-44100-2.wav
+fate-filter-asetnsamples-nopad: SRC = 
$(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-asetnsamples-nopad: CMD = framecrc -i $(SRC) -af 
asetnsamples=512:p=0
 
 FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETRATE, WAV, PCM_S16LE, PCM_S16LE, 
WAV) += fate-filter-asetrate
 fate-filter-asetrate: tests/data/asynth-44100-2.wav
diff --git a/tests/ref/fate/filter-asetnsamples 
b/tests/ref/fate/filter-asetnsamples-nopad
similarity index 99%
copy from tests/ref/fate/filter-asetnsamples
copy to tests/ref/fate/filter-asetnsamples-nopad
index 23cf11b..c1cc01a 100644
--- a/tests/ref/fate/filter-asetnsamples
+++ b/tests/ref/fate/filter-asetnsamples-nopad
@@ -520,4 +520,4 @@
 0, 262656, 262656,  512, 2048, 0xb881fa44
 0, 263168, 263168,  512, 2048, 0xb7cdf1f3
 0, 263680, 263680,  512, 2048, 0x1e9b17b5
-0, 264192, 264192,  512, 2048, 0xfd82313e
+0, 264192, 264192,  408, 1632, 0xf412313e
diff --git a/tests/ref/fate/filter-asetnsamples 
b/tests/ref/fate/filter-asetnsamples-pad
similarity index 100%
rename from tests/ref/fate/filter-asetnsamples
rename to tests/ref/fate/filter-asetnsamples-pad
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH v3] fate: add tests for some video source filters

[Tobias Rapp]

On 25.07.2017 11:11, Tobias Rapp wrote:

Adds FATE tests for the previously untested allrgb, allyuv, rgbtestsrc,
smptebars, smptehdbars and yuvtestsrc filters.

Also adds a test for testsrc2 filter with rgb+alpha.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  tests/fate/filter-video.mak| 24 ++
  tests/ref/fate/filter-allrgb   | 10 
  tests/ref/fate/filter-allyuv   | 10 
  tests/ref/fate/filter-rgbtestsrc   | 10 
  tests/ref/fate/filter-smptebars| 10 
  tests/ref/fate/filter-smptehdbars  | 10 
  tests/ref/fate/filter-testsrc2-rgba| 75 ++
  tests/ref/fate/filter-yuvtestsrc-yuv444p   | 10 
  tests/ref/fate/filter-yuvtestsrc-yuv444p12 | 10 
  9 files changed, 169 insertions(+)
  create mode 100644 tests/ref/fate/filter-allrgb
  create mode 100644 tests/ref/fate/filter-allyuv
  create mode 100644 tests/ref/fate/filter-rgbtestsrc
  create mode 100644 tests/ref/fate/filter-smptebars
  create mode 100644 tests/ref/fate/filter-smptehdbars
  create mode 100644 tests/ref/fate/filter-testsrc2-rgba
  create mode 100644 tests/ref/fate/filter-yuvtestsrc-yuv444p
  create mode 100644 tests/ref/fate/filter-yuvtestsrc-yuv444p12

[...]


Ping.

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

Re: [FFmpeg-devel] FFmpeg 3.4

[Tobias Rapp]

On 08.10.2017 13:58, Reto Kromer wrote:

Michael Niedermayer wrote:


Of course if the majority wants me to wait with the release,
its easy to wait for as long as people want me to wait ...


Form an user's perspective, I would be delighted to have a new
release. Thank you very much indeed! Reto


+1

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

Re: [FFmpeg-devel] [PATCH 1/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

[Tobias Rapp]

On 17.10.2017 20:12, Nicolas George wrote:

Le sextidi 26 vendémiaire, an CCXXVI, Tobias Rapp a écrit :

This commit seems to break transcoding of some input files on machines with
a lot of CPU cores. See attached script that reproduces the problem
("-threads 32" is used to simulate the situation of a multi-core CPU).

Sorry for noticing late but it took me some time to track down the problem
and git bisecting it. The issue seems to be triggered by the high number of
audio packets in the input file (~375 packets per second). Input files that
have a lower audio packet rate work fine.


Thanks for reporting. I fear this will be tricky to debug.

I think the change you  have tracked cannot be the cause of the issue,
since it does not touch anything related to threading.


Yes, I also don't see why this patch correlates with the number of 
threads. But when bypassing the push_frame() function from the patch by 
adding an immediate "return 0" the problem disappears.



What this change does, on the other hand, is increase the efficiency of
the scheduling in lavfi. That can cause more work for filters that do
use threading, and reveal a race condition there.

I do not have access to a 32-core system. Can the problem be reproduced
with your script with just "-threads 32" without such a system? How
ofter does it manifest?


I'm able to reproduce the issue reliably on each run of the test script 
on three test machines:


- Windows 64bit 32-core, without "-threads 32"
- Windows 64bit 2-core, with "-threads 32"
- GNU/Linux 64bit 2-core, with "-threads 32"

What seem to help as a work-around is adding "-max_muxing_queue_size 1000".

Regards,
Tobias

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

[FFmpeg-devel] [PATCH v2] avformat/wavenc: skip writing incorrect peak-of-peaks position value

[Tobias Rapp]

According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
should contain the absolute position to the maximum audio sample value,
but the current implementation writes the relative peak frame index
instead.

Fix the issue by writing the "unknown" value (-1) for now until the
feature is implemented correctly.

Previous version reviewed-by: Peter Bubestinger <p.bubestin...@av-rd.com>
Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
v2:
 - added version micro bump
 - more code clean-up

 libavformat/version.h|  2 +-
 libavformat/wavenc.c | 11 +--
 tests/ref/lavf/wav_peak  |  2 +-
 tests/ref/lavf/wav_peak_only |  2 +-
 4 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/libavformat/version.h b/libavformat/version.h
index 0feb788..8ae091f 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR   0
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/libavformat/wavenc.c b/libavformat/wavenc.c
index adb20cb..159119d 100644
--- a/libavformat/wavenc.c
+++ b/libavformat/wavenc.c
@@ -74,8 +74,6 @@ typedef struct WAVMuxContext {
 uint32_t peak_num_frames;
 uint32_t peak_outbuf_size;
 uint32_t peak_outbuf_bytes;
-uint32_t peak_pos_pop;
-uint16_t peak_pop;
 uint8_t *peak_output;
 int last_duration;
 int write_bext;
@@ -195,7 +193,6 @@ static void peak_write_frame(AVFormatContext *s)
 {
 WAVMuxContext *wav = s->priv_data;
 AVCodecParameters *par = s->streams[0]->codecpar;
-int peak_of_peaks;
 int c;
 
 if (!wav->peak_output)
@@ -213,12 +210,6 @@ static void peak_write_frame(AVFormatContext *s)
 wav->peak_maxpos[c] =
 FFMAX(wav->peak_maxpos[c], wav->peak_maxneg[c]);
 
-peak_of_peaks = FFMAX3(wav->peak_maxpos[c], wav->peak_maxneg[c],
-   wav->peak_pop);
-if (peak_of_peaks > wav->peak_pop)
-wav->peak_pos_pop = wav->peak_num_frames;
-wav->peak_pop = peak_of_peaks;
-
 if (wav->peak_outbuf_size - wav->peak_outbuf_bytes <
 wav->peak_format * wav->peak_ppv) {
 wav->peak_outbuf_size += PEAK_BUFFER_SIZE;
@@ -287,7 +278,7 @@ static int peak_write_chunk(AVFormatContext *s)
 avio_wl32(pb, wav->peak_block_size);/* frames per value */
 avio_wl32(pb, par->channels);   /* number of channels */
 avio_wl32(pb, wav->peak_num_frames);/* number of peak frames */
-avio_wl32(pb, wav->peak_pos_pop);   /* audio sample frame index */
+avio_wl32(pb, -1);  /* audio sample frame position 
(not implemented) */
 avio_wl32(pb, 128); /* equal to size of header */
 avio_write(pb, timestamp, 28);  /* ASCII time stamp */
 ffio_fill(pb, 0, 60);
diff --git a/tests/ref/lavf/wav_peak b/tests/ref/lavf/wav_peak
index aa7e5fc..861b246 100644
--- a/tests/ref/lavf/wav_peak
+++ b/tests/ref/lavf/wav_peak
@@ -1,3 +1,3 @@
-35148d1f6e66b0080893851d917ecbf4 *./tests/data/lavf/lavf.peak.wav
+105805963fb767d00da056f42f32d9f3 *./tests/data/lavf/lavf.peak.wav
 89094 ./tests/data/lavf/lavf.peak.wav
 ./tests/data/lavf/lavf.peak.wav CRC=0x3a1da17e
diff --git a/tests/ref/lavf/wav_peak_only b/tests/ref/lavf/wav_peak_only
index dccd0e7..b203d03 100644
--- a/tests/ref/lavf/wav_peak_only
+++ b/tests/ref/lavf/wav_peak_only
@@ -1,2 +1,2 @@
-b609a363e6d490710ed52231a8d09d3c *./tests/data/lavf/lavf.peak_only.wav
+f1a8aeeae8069f3992c4d780436c3d23 *./tests/data/lavf/lavf.peak_only.wav
 832 ./tests/data/lavf/lavf.peak_only.wav
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

[Tobias Rapp]

On 23.11.2017 00:10, Derek Buitenhuis wrote:

On 11/22/2017 10:52 PM, Carl Eugen Hoyos wrote:

start_line = fields * (i ^ (par->field_order == AV_FIELD_BB ||
par->field_order == AV_FIELD_BT));

Which are imo less ugly.


Can't agree.

It's needlessly less readable bit fiddling.


+1

It may save some lines by in my opinion the current code is more 
readable and maintainable in case there are changes to AVFieldOrder (see 
discussion at 
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/215698.html).


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] fix bug in af_pan channel coefficient parser

[Tobias Rapp]

On 21.11.2017 20:01, Michael Niedermayer wrote:

On Tue, Nov 21, 2017 at 02:24:23PM +0100, Tobias Rapp wrote:

On 20.11.2017 22:15, Michael Niedermayer wrote:

On Mon, Nov 20, 2017 at 05:14:15PM +0100, Nicolas George wrote:

Tobias Rapp (2017-11-20):

Would it be OK to backport the fix into release/3.4? I can do the
cherry-picking but am unsure about the policies and what other older
releases should possibly be adapted, too.


I do not know how backporting to releases work either, but I have of
course no objection in principle.


simple cherry pick with the hex hash in the commit message (-x)
test if it still all works and push


Backported the fix to release/3.4

Not sure what other releases are still maintained as the list within
the MAINTAINERS file looks outdated (2.5 to 2.8).


The ones we list on the download page should be updated if they are
affected


Which would currently mean release branches 3.4 to 2.8. From testing it 
seems that releases 3.2 and earlier do not support a pan filter string 
like "stereo|c0=c0-c2|c1=c1-c2", error message is 'Syntax error near 
"-c2"'. So backported the fix to release/3.3 additionally only.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

[Tobias Rapp]

On 22.11.2017 23:52, Carl Eugen Hoyos wrote:

2017-11-22 16:41 GMT+01:00 Tobias Rapp <t.r...@noa-archive.com>:

Writes one set of field framing information for progressive streams and
two sets for interlaced streams. Fixes ticket #6383.

Unfortunately the OpenDML v1.02 document is not very specific what value
to use for start_line when frame data is not coming from a capturing
device, so this is just using 0/1 depending on the field order as a
best-effort guess.


I believe your approach is sane but the only available examples
may indicate that it should be set to something like height / 2 ;-(


Indeed my main problem is that I have not found some real-world example 
file with two sets of field framing information. I scanned the files at 
http://streams.videolan.org/samples/ but out of >900 AVI files only 
about 40 files contain a vprp chunk but none contains two fields.


I have found two files that have FieldPerFrame=2 (indicating an 
interlaced video stream) but they contain a truncated vprp chunk (no 
field framing information):

http://streams.videolan.org/samples/V-codecs/MJPEGs/matrox-capture.avi
http://streams.videolan.org/samples/avi/TRA3106.avi

As this clearly doesn't match the specs I didn't want to follow these 
two examples.


I can use height/2 for start_line offset instead of 1 if that sounds 
better, to me it would look like an indication that the fields are 
stored separated, but no strong opinion from my side.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

[Tobias Rapp]

Writes one set of field framing information for progressive streams and
two sets for interlaced streams. Fixes ticket #6383.

Unfortunately the OpenDML v1.02 document is not very specific what value
to use for start_line when frame data is not coming from a capturing
device, so this is just using 0/1 depending on the field order as a
best-effort guess.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 libavformat/avienc.c | 38 +++---
 libavformat/version.h|  2 +-
 tests/ref/fate/copy-trac2211-avi |  4 ++--
 3 files changed, 30 insertions(+), 14 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 483f5b5..efe67ce 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -501,8 +501,14 @@ static int avi_write_header(AVFormatContext *s)
 AVRational dar = av_mul_q(st->sample_aspect_ratio,
   (AVRational) { par->width,
  par->height });
-int num, den;
+int num, den, fields, i;
 av_reduce(, , dar.num, dar.den, 0x);
+if (par->field_order == AV_FIELD_TT || par->field_order == 
AV_FIELD_BB ||
+par->field_order == AV_FIELD_TB || par->field_order == 
AV_FIELD_BT) {
+fields = 2; // interlaced
+} else {
+fields = 1; // progressive
+}
 
 avio_wl32(pb, 0); // video format   = unknown
 avio_wl32(pb, 0); // video standard = unknown
@@ -514,17 +520,27 @@ static int avi_write_header(AVFormatContext *s)
 avio_wl16(pb, num);
 avio_wl32(pb, par->width);
 avio_wl32(pb, par->height);
-avio_wl32(pb, 1); // progressive FIXME
-
-avio_wl32(pb, par->height);
-avio_wl32(pb, par->width);
-avio_wl32(pb, par->height);
-avio_wl32(pb, par->width);
-avio_wl32(pb, 0);
-avio_wl32(pb, 0);
+avio_wl32(pb, fields); // fields per frame
+
+for (i = 0; i < fields; i++) {
+int start_line;
+if (par->field_order == AV_FIELD_TT || par->field_order == 
AV_FIELD_TB) {
+start_line = (i == 0) ? 0 : 1;
+} else if (par->field_order == AV_FIELD_BB || par->field_order 
== AV_FIELD_BT) {
+start_line = (i == 0) ? 1 : 0;
+} else {
+start_line = 0;
+}
 
-avio_wl32(pb, 0);
-avio_wl32(pb, 0);
+avio_wl32(pb, par->height / fields); // compressed bitmap 
height
+avio_wl32(pb, par->width);   // compressed bitmap width
+avio_wl32(pb, par->height / fields); // valid bitmap height
+avio_wl32(pb, par->width);   // valid bitmap width
+avio_wl32(pb, 0);// valid bitmap X offset
+avio_wl32(pb, 0);// valid bitmap Y offset
+avio_wl32(pb, 0);// valid X offset in T
+avio_wl32(pb, start_line);   // valid Y start line
+}
 ff_end_tag(pb, vprp);
 }
 
diff --git a/libavformat/version.h b/libavformat/version.h
index feb1461..7fe3710 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR   2
-#define LIBAVFORMAT_VERSION_MICRO 102
+#define LIBAVFORMAT_VERSION_MICRO 103
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/tests/ref/fate/copy-trac2211-avi b/tests/ref/fate/copy-trac2211-avi
index 007349e..06d81e5 100644
--- a/tests/ref/fate/copy-trac2211-avi
+++ b/tests/ref/fate/copy-trac2211-avi
@@ -1,5 +1,5 @@
-6f6b211cbc8de9871e8e09e64048e2f9 *tests/data/fate/copy-trac2211-avi.avi
-1777924 tests/data/fate/copy-trac2211-avi.avi
+0920978f3f8196413c43f0033b55a5b6 *tests/data/fate/copy-trac2211-avi.avi
+1777956 tests/data/fate/copy-trac2211-avi.avi
 #tb 0: 1/14
 #media_type 0: video
 #codec_id 0: rawvideo
-- 
2.7.4


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

Re: [FFmpeg-devel] AMD external header

[Tobias Rapp]

On 28.11.2017 10:25, Timo Rothenpieler wrote:
Your use-case looks like an argument for moving the external headers 
into some separate repository. Not that I personally care much about 
bundling or not bundling. To me the more important question seems to 
be whether to auto-enable the encoders/decoders that depend on the 
external headers and libraries or not.


At least nvenc will stay as auto-enable even with out-of-tree headers, 
except that it will obviously check if it has the required headers 
available.


What confuses me is that libraries like libopus/libx264/... must be 
manually enabled while the library behind nvenc is auto-enabled.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

[Tobias Rapp]

On 22.11.2017 16:58, Derek Buitenhuis wrote:

On 11/22/2017 3:41 PM, Tobias Rapp wrote:

Writes one set of field framing information for progressive streams and
two sets for interlaced streams. Fixes ticket #6383.

Unfortunately the OpenDML v1.02 document is not very specific what value
to use for start_line when frame data is not coming from a capturing
device, so this is just using 0/1 depending on the field order as a
best-effort guess.


Looking at the OpenDML spec, I think this indeed is the best we can do without
deeper knowledge of where the source signal came from, or copying it from a
pre-existing file, within the existing avformat scaffolding.

Code itself seems OK.


Copied part of the commit message as a comment to the code and pushed. 
Thanks Carl and Derek for the review.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

[Tobias Rapp]

On 25.11.2017 18:31, Derek Buitenhuis wrote:

On 11/25/2017 2:40 PM, Clément Bœsch wrote:

Maybe "libavresample is not maintained by the FFmpeg project and will be
dropped at the next major bump. Please use libswresample instead."

And it probably needs a longer explanation somewhere (website/news/...)


All API functions should be properly marked as deprecated in the headers.

Relying on a stderr warning to help migrate API users is silly, who is
going to be watching stderr using a /library/?


+1

Please avoid the AVStream.codec -> AVStream.codecpar scenario. I don't 
remember how often I was asked by users looking at the logs how they can 
avoid the "Using AVStream.codec to pass codec parameters to muxers is 
deprecated, use AVStream.codecpar instead" warning.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

[Tobias Rapp]

On 26.11.2017 21:51, James Almer wrote:

Every bitstream filter behaves as intended now, so there's no need to
wait for the first packet of every stream.

Signed-off-by: James Almer 
---
  libavformat/avformat.h |  2 +-
  libavformat/internal.h |  6 -
  libavformat/mux.c  | 52 --
  libavformat/options_table.h|  2 +-
  libavformat/tests/fifo_muxer.c | 52 --
  tests/ref/fate/fifo-muxer-tst  |  1 -
  6 files changed, 12 insertions(+), 103 deletions(-)

[...]


I'm just curious: Will this fix ticket #6375?

Regards,
Tobias

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

Re: [FFmpeg-devel] AMD external header

[Tobias Rapp]

On 27.11.2017 17:14, Pavel Koshevoy wrote:

On Mon, Nov 27, 2017 at 8:25 AM, Nicolas George  wrote:

Mironov, Mikhail (2017-11-27):

#1
policy: do not include external headers
goal: minimize maintenance efforts and increase stability of the project
action: remove NVidia headers


Add to the goal: avoid being complicit of free-riders on the Libre
software bandwagon.


That is unnecessarily un-diplomatic and will likely offend the
contributors from nvidia and amd.

Personally, I would prefer if the bundled external headers were
installed together with ffmpeg public headers (so nvenc/cuda/etc...
weren't simply private headers within ffmpeg).  There are some nvenc
APIs I need to query hardware capabilities to avoid setting nvenc
codec parameters that would cause the codec to fail to initialize via
ffmpeg apis.  Given that ffmpeg already includes the headers that
declare those APIs I've been able to use them without installing nvenc
SDK separately, but since they are private headers in the ffmpeg
source tree it feels dirty to do that.


Your use-case looks like an argument for moving the external headers 
into some separate repository. Not that I personally care much about 
bundling or not bundling. To me the more important question seems to be 
whether to auto-enable the encoders/decoders that depend on the external 
headers and libraries or not.


Regards,
Tobias

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

Re: [FFmpeg-devel] AMD external header

[Tobias Rapp]

On 01.12.2017 00:32, Marton Balint wrote:


On Wed, 29 Nov 2017, Mironov, Mikhail wrote:


Hi,
This conversation is very entertaining but leads us nowhere.
May I suggest to go down to business of enabling HW encoders by default?
Yesterday Mark submitted the initial implementation and I really want
to thank him for his mentoring and participation - it was very useful.
The submission doesn't have AMD header so AMD encoder is off in any 
default build.
I counted responses to my posts and found six people are for the 
default enabling

of HW blocks one way or another: by including headers or pulling them out
automatically using git (I guess via submodules?).
Two people want to remove external headers and disable default HW 
acceleration.
Question is: how to move forward on practical terms? I really don’t 
know how this team makes such decisions.
Or maybe it is impasse case and  all want to keep things the way they 
are today?


The project has a voting system which was used in the past for issues 
where no consensus was reached. A voting however is a tedious process 
which usually leaves a few frustrated people on the losing side, so I'd 
say that is a last resort.


+1

An alternative solution to adding AMD or removing Nvidia headers might 
be to simply disable the Nvidia hwaccel autodetection, and require the 
user to explicitly enable it. That seems mostly fair to me, and keeps 
the current status of the headers.


Still some decision about these external headers should be made but the 
outcome would have less impact on user experience.


What is the current policy for adding a library on the 
HWACCEL_AUTODETECT_LIBRARY_LIST versus putting it on 
HWACCEL_LIBRARY_LIST? Is it different from 
EXTERNAL_AUTODETECT_LIBRARY_LIST / EXTERNAL_LIBRARY_LIST?


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] tests/fate/mov: Disable fate-mov-invalid-elst-entry-count, the test does not work reliable currently

[Tobias Rapp]

On 05.12.2017 01:38, Michael Niedermayer wrote:

Noone is known to work on fixing this, so it should be disabled

Signed-off-by: Michael Niedermayer 
---
  tests/fate/mov.mak | 1 -
  1 file changed, 1 deletion(-)

diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 680baea773..869784fd31 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -6,7 +6,6 @@ FATE_MOV = fate-mov-3elist \
 fate-mov-1elist-ends-last-bframe \
 fate-mov-2elist-elist1-ends-bframe \
 fate-mov-3elist-encrypted \
-   fate-mov-invalid-elst-entry-count \
 fate-mov-gpmf-remux \
 fate-mov-440hz-10ms \
 fate-mov-ibi-elst-starts-b \



Maybe add a FIXME comment to the test itself so that somebody reading 
the file doesn't think it is missing in this list by accident?


Regards,
Tobias

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

[FFmpeg-devel] [PATCH][RFC] avcodec/dpxenc: add option to force color transfer characteristics

[Tobias Rapp]

Based on a patch by Kieran O'Leary. Fixes ticket #6023.

Open topics:
 - is there some mapping missing in color_trc_to_dpx?
 - the default for color_trc is DPX_TRC_UNDEFINED, would it be better to
   use DPX_TRC_USER_DEFINED instead?
 - do we need a separate encoder option for the colorimetric
   specification field? If yes, do we try to map the value from frame
   color_trc/color_primaries/...?

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 doc/encoders.texi   | 43 
 libavcodec/dpxenc.c | 80 +++--
 tests/ref/lavf/dpx  | 12 
 3 files changed, 127 insertions(+), 8 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 88ef8f9..f3f36bf 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1312,6 +1312,49 @@ disabled
 A description of some of the currently available video encoders
 follows.
 
+@section dpx
+
+Digital Moving-Picture Exchange (DPX) image encoder.
+
+@subsection Options
+
+@table @option
+@item dpx_color_trc @var{integer}
+DPX color transfer characteristics (see Table 5A in SMPTE 268M-2003).
+
+@table @option
+@item user
+User Defined
+@item print
+Printing Density
+@item linear
+Linear
+@item log
+Logarithmic
+@item video
+Unspecified Video
+@item smpte274m
+SMPTE-274M
+@item itur709
+ITU-R 709-4
+@item itur601bg
+ITU-R 601-5 (system B or G)
+@item itur601m
+ITU-R 601-5 (system M)
+@item ntsc
+NTSC Composite Video
+@item pal
+PAL Composite Video
+@item zlinear
+Z-Linear
+@item zhomogen
+Z-Homogeneous
+@end table
+
+Default value is derived from encoder, when mapping is available.
+
+@end table
+
 @section Hap
 
 Vidvox Hap video encoder.
diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
index a596033..ddcd53b 100644
--- a/libavcodec/dpxenc.c
+++ b/libavcodec/dpxenc.c
@@ -22,17 +22,56 @@
 #include "libavutil/common.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/pixfmt.h"
 #include "avcodec.h"
 #include "internal.h"
 
 typedef struct DPXContext {
+AVClass *class;
 int big_endian;
 int bits_per_component;
 int num_components;
 int descriptor;
 int planar;
+int color_trc;
 } DPXContext;
 
+enum DPXTransferCharacteristic {
+DPX_TRC_UNDEFINED= -1,
+DPX_TRC_USER_DEFINED = 0,
+DPX_TRC_PRINTING_DENSITY = 1,
+DPX_TRC_LINEAR   = 2,
+DPX_TRC_LOG  = 3,   // Logarithmic
+DPX_TRC_UNSPECIFIED_VIDEO= 4,
+DPX_TRC_SMPTE274M= 5,   // SMPTE 274M
+DPX_TRC_ITUR709  = 6,   // ITU-R 709-4
+DPX_TRC_ITUR601BG= 7,   // ITU-R 601-5 system B or G (625)
+DPX_TRC_ITUR601M = 8,   // ITU-R 601-5 system M (525)
+DPX_TRC_COMPOSITE_VIDEO_NTSC = 9,   // Composite video (NTSC), see SMPTE 
170M
+DPX_TRC_COMPOSITE_VIDEO_PAL  = 10,  // Composite video (PAL), see ITU-R 
624-4
+DPX_TRC_Z_LINEAR = 11,
+DPX_TRC_Z_HOMOGENEOUS= 12,
+DPX_TRC_NB
+};
+
+static int color_trc_to_dpx(enum AVColorTransferCharacteristic color_trc)
+{
+switch (color_trc) {
+case AVCOL_TRC_LINEAR:
+return DPX_TRC_LINEAR;
+case AVCOL_TRC_LOG:
+return DPX_TRC_LOG;
+case AVCOL_TRC_BT709:
+return DPX_TRC_ITUR709;
+case AVCOL_TRC_SMPTE170M:
+return DPX_TRC_COMPOSITE_VIDEO_NTSC;
+default:
+return DPX_TRC_UNDEFINED;
+}
+}
+
 static av_cold int encode_init(AVCodecContext *avctx)
 {
 DPXContext *s = avctx->priv_data;
@@ -178,6 +217,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 {
 DPXContext *s = avctx->priv_data;
 int size, ret, need_align, len;
+int color_trc = s->color_trc;
 uint8_t *buf;
 
 #define HEADER_SIZE 1664  /* DPX Generic header */
@@ -200,6 +240,14 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 return ret;
 buf = pkt->data;
 
+if (color_trc < 0)
+color_trc = color_trc_to_dpx(frame->color_trc);
+if (color_trc < 0)
+color_trc = color_trc_to_dpx(avctx->color_trc);
+av_log(avctx, AV_LOG_TRACE, "codec_color_trc:%s frame_color_trc:%s 
dpx_color_trc:%d\n",
+   av_color_transfer_name(avctx->color_trc), 
av_color_transfer_name(frame->color_trc),
+   color_trc);
+
 memset(buf, 0, HEADER_SIZE);
 
 /* File information header */
@@ -218,8 +266,8 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 write32(buf + 772, avctx->width);
 write32(buf + 776, avctx->height);
 buf[800] = s->descriptor;
-buf[801] = 2; /* linear transfer */
-buf[802] = 2; /* linear colorimetric */
+buf[801] = color_trc; /* transfer characteristics */
+buf[802] = color_trc; /* colorimetric speci

Re: [FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

[Tobias Rapp]

On 20.11.2017 14:47, Tobias Rapp wrote:

Fixes ticket #6383.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  libavformat/avienc.c | 10 --
  libavformat/version.h|  2 +-
  tests/ref/fate/copy-trac2211-avi |  2 +-
  3 files changed, 10 insertions(+), 4 deletions(-)

[...]


Please ignore this patch, it is incomplete.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] fix bug in af_pan channel coefficient parser

[Tobias Rapp]

On 19.11.2017 17:39, Nicolas George wrote:

L'octidi 28 brumaire, an CCXXVI, Michael Roitzsch a écrit :

Hi FFmpeg team,

I was using af_pan to subtract one audio file from another. I first used an 
amerge filter and then configured the pan filter with a channel formula like 
c0=c0-c2|c1=c1-c3.

However, this does not work as expected. In debug output, I can see that 
channel 0 correctly uses gain coefficients 1 and -1 for c0 and c2. But channel 
1 incorrectly uses -1 and -1 for c1 and c3.

I looked into the code and found that the sign handling is currently wrong. 
When the last contribution of a formula is subtracted, the sign variable will 
be correctly set to -1 in line 191. But when then leaving the gains loop in 
line 189, because we reached the end of the formula for an output channel, sign 
is not reset. We therefore re-enter the gains loop for the next output channel 
with sign still -1. The first gain in this new formula will therefore be 
negated.

The attached patch fixes the problem for me.


Thanks, applied.


Would it be OK to backport the fix into release/3.4? I can do the 
cherry-picking but am unsure about the policies and what other older 
releases should possibly be adapted, too.


Regards,
Tobias

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

[FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

[Tobias Rapp]

Fixes ticket #6383.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 libavformat/avienc.c | 10 --
 libavformat/version.h|  2 +-
 tests/ref/fate/copy-trac2211-avi |  2 +-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 483f5b5..b702d9e 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -501,8 +501,14 @@ static int avi_write_header(AVFormatContext *s)
 AVRational dar = av_mul_q(st->sample_aspect_ratio,
   (AVRational) { par->width,
  par->height });
-int num, den;
+int num, den, fields;
 av_reduce(, , dar.num, dar.den, 0x);
+if (par->field_order == AV_FIELD_TT || par->field_order == 
AV_FIELD_BB ||
+par->field_order == AV_FIELD_TB || par->field_order == 
AV_FIELD_BT) {
+fields = 2; // interlaced
+} else {
+fields = 1; // progressive
+}
 
 avio_wl32(pb, 0); // video format   = unknown
 avio_wl32(pb, 0); // video standard = unknown
@@ -514,7 +520,7 @@ static int avi_write_header(AVFormatContext *s)
 avio_wl16(pb, num);
 avio_wl32(pb, par->width);
 avio_wl32(pb, par->height);
-avio_wl32(pb, 1); // progressive FIXME
+avio_wl32(pb, fields); // fields per frame
 
 avio_wl32(pb, par->height);
 avio_wl32(pb, par->width);
diff --git a/libavformat/version.h b/libavformat/version.h
index feb1461..7fe3710 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR   2
-#define LIBAVFORMAT_VERSION_MICRO 102
+#define LIBAVFORMAT_VERSION_MICRO 103
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
diff --git a/tests/ref/fate/copy-trac2211-avi b/tests/ref/fate/copy-trac2211-avi
index 007349e..82c5609 100644
--- a/tests/ref/fate/copy-trac2211-avi
+++ b/tests/ref/fate/copy-trac2211-avi
@@ -1,4 +1,4 @@
-6f6b211cbc8de9871e8e09e64048e2f9 *tests/data/fate/copy-trac2211-avi.avi
+cdec6984b94933ad42113b35ee246409 *tests/data/fate/copy-trac2211-avi.avi
 1777924 tests/data/fate/copy-trac2211-avi.avi
 #tb 0: 1/14
 #media_type 0: video
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH] fix bug in af_pan channel coefficient parser

[Tobias Rapp]

On 20.11.2017 22:15, Michael Niedermayer wrote:

On Mon, Nov 20, 2017 at 05:14:15PM +0100, Nicolas George wrote:

Tobias Rapp (2017-11-20):

Would it be OK to backport the fix into release/3.4? I can do the
cherry-picking but am unsure about the policies and what other older
releases should possibly be adapted, too.


I do not know how backporting to releases work either, but I have of
course no objection in principle.


simple cherry pick with the hex hash in the commit message (-x)
test if it still all works and push


Backported the fix to release/3.4

Not sure what other releases are still maintained as the list within the 
MAINTAINERS file looks outdated (2.5 to 2.8).


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] configure: Allow users to disable all hwaccel libraries

[Tobias Rapp]

On 07.12.2017 10:31, Gyan Doshi wrote:

On 12/7/2017 12:59 PM, Tobias Rapp wrote:


Why not add the HWACCEL_AUTODETECT_LIBRARY_LIST to --disable-hwaccels?


That is a better choice but there wasn't a bespoke case for 
'--disable-hwaccels', so originally ignored that possibility. Added it 
in attached (new) patch.


Either one - this or original patch - works for me.


This one makes more sense to me as "disable all hwaccels" implicitly 
includes autodetected hwaccels, but that's just my personal opinion. I 
leave it to the maintainer of the file to decide what to push.


Regards,
Tobias

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Tobias Rapp]

On 29.11.2017 07:33, Jeyapal, Karthick wrote:

ffmpeg | branch: master | Jeyapal, Karthick  | Wed Nov 29 
14:33:07 2017 +0800| [815e34b5b4ed8fbb6c9d7b7b042ae49848bc170c] | committer: Steven 
Liu

libavformat/hlsenc: Persistent HTTP connections supported as an option


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=815e34b5b4ed8fbb6c9d7b7b042ae49848bc170c

---

  doc/muxers.texi  |  3 +++
  libavformat/hlsenc.c | 48 +---
  2 files changed, 44 insertions(+), 7 deletions(-)

[...]


This patch seems to break building ffmpeg with --disbale-network. Error 
message from build is:


libavformat/libavformat.a(hlsenc.o): In function `hlsenc_io_open':
/home/tobias/Projects/ffmpeg-git-master/build-linux/src/libavformat/hlsenc.c:265: 
undefined reference to `ff_http_do_new_request'

collect2: error: ld returned 1 exit status
/home/tobias/Projects/ffmpeg-git-master/Makefile:107: recipe for target 
'ffmpeg-dbg_g' failed

make: *** [ffmpeg-dbg_g] Error 1
libavformat/libavformat.a(hlsenc.o): In function `hlsenc_io_open':
/home/tobias/Projects/ffmpeg-git-master/build-linux/src/libavformat/hlsenc.c:265: 
undefined reference to `ff_http_do_new_request'

collect2: error: ld returned 1 exit status
/home/tobias/Projects/ffmpeg-git-master/Makefile:107: recipe for target 
'ffprobe-dbg_g' failed

make: *** [ffprobe-dbg_g] Error 1

Can you take a look?

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix complie error when disable-network

[Tobias Rapp]

On 04.12.2017 16:36, Steven Liu wrote:

Signed-off-by: Steven Liu 
---
  libavformat/hlsenc.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index aeeed5bcd2..7dc8f4237b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -45,7 +45,9 @@
  
  #include "avformat.h"

  #include "avio_internal.h"
+#if CONFIG_HTTP_PROTOCOL
  #include "http.h"
+#endif
  #include "hlsplaylist.h"
  #include "internal.h"
  #include "os_support.h"
@@ -245,13 +247,15 @@ static int hlsenc_io_open(AVFormatContext *s, AVIOContext 
**pb, char *filename,
AVDictionary **options) {
  HLSContext *hls = s->priv_data;
  int http_base_proto = is_http_proto(filename);
-int err;
+int err = AVERROR_MUXER_NOT_FOUND;
  if (!*pb || !http_base_proto || !hls->http_persistent) {
  err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE, options);
+#if CONFIG_HTTP_PROTOCOL
  } else {
  URLContext *http_url_context = ffio_geturlcontext(*pb);
  av_assert0(http_url_context);
  err = ff_http_do_new_request(http_url_context, filename);
+#endif
  }
  return err;
  }



Thanks, this fixes the compile error.

Nit: there is a typo in the commit subject "complie" -> "compile"

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] configure: Allow users to disable all hwaccel libraries

[Tobias Rapp]

On 30.11.2017 11:58, Gyan Doshi wrote:

On 11/30/2017 4:19 PM, Clément Bœsch wrote:


Is --disable-autodetect broken/not complete for you?


This disables more than just the hwaccel libs. I've tested my patch 
locally and configure lists no entries under External Libraries 
Providing Hardware Acceleration, unlike with --disable-hwaccels.


Why not add the HWACCEL_AUTODETECT_LIBRARY_LIST to --disable-hwaccels?

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 01/27] avcodec: add color_range to AVCodec struct and use it

[Tobias Rapp]

On 11.12.2017 14:22, Paul B Mahol wrote:

On 12/11/17, Hendrik Leppkes  wrote:

On Mon, Dec 11, 2017 at 12:07 PM, Paul B Mahol  wrote:


Fine, but it's inevitable that the encoder supports the J formats still
for a while.



Why are you all dismissive about this?



Because we have an established way to remove things like this, and
that doesn't happen over night.
Its not ok for stuff to stop working without a replacement in place
for a sufficient time before that, so people can migrate.

First, implement replacement and add visible deprecation messages -
and then wait the established deprecation period before actually
removing it.


Bullshit, J formats are deprecated for ages.


ffmpeg -i input.avi -f avi -codec:v mjpeg -pix_fmt yuvj420p -y output.avi

Prints warning "deprecated pixel format".

ffmpeg -i input.avi -f avi -codec:v mjpeg -pix_fmt yuv420p -color_range 
jpeg -y output.avi


Prints warning "incompatible pixel format" plus "deprecated pixel format".

Guess which command-line is currently implemented in my (and I assume 
most other) scripts. I very much welcome your work on cleaning up this 
mess, but please allow for some migration period.


Best regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH v2] avformat/wavenc: skip writing incorrect peak-of-peaks position value

[Tobias Rapp]

On 25.10.2017 20:01, Michael Niedermayer wrote:

On Wed, Oct 25, 2017 at 07:55:52PM +0200, Michael Niedermayer wrote:

On Tue, Oct 24, 2017 at 11:47:21AM +0200, Tobias Rapp wrote:

According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
should contain the absolute position to the maximum audio sample value,
but the current implementation writes the relative peak frame index
instead.

Fix the issue by writing the "unknown" value (-1) for now until the
feature is implemented correctly.

Previous version reviewed-by: Peter Bubestinger <p.bubestin...@av-rd.com>
Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
v2:
  - added version micro bump
  - more code clean-up

  libavformat/version.h|  2 +-
  libavformat/wavenc.c | 11 +--
  tests/ref/lavf/wav_peak  |  2 +-
  tests/ref/lavf/wav_peak_only |  2 +-
  4 files changed, 4 insertions(+), 13 deletions(-)


will apply, thanks


rather LGTM, feel free to apply


Applied, thanks for review.

Regards,
Tobias

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

[FFmpeg-devel] [PATCH] fate: add more tests for hue video filter

[Tobias Rapp]

Adds tests for the hue angle and brightness filter parameters.
Renames the existing saturation parameter test for consistency.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 tests/fate/filter-video.mak | 10 --
 tests/ref/fate/filter-hue   |  1 -
 tests/ref/fate/filter-hue1  |  1 +
 tests/ref/fate/filter-hue2  |  1 +
 tests/ref/fate/filter-hue3  |  1 +
 5 files changed, 11 insertions(+), 3 deletions(-)
 delete mode 100644 tests/ref/fate/filter-hue
 create mode 100644 tests/ref/fate/filter-hue1
 create mode 100644 tests/ref/fate/filter-hue2
 create mode 100644 tests/ref/fate/filter-hue3

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 17d6363..f2ab263 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -499,8 +499,14 @@ fate-filter-edgedetect: CMD = video_filter 
"format=gray,perms=random,edgedetect"
 FATE_FILTER_VSYNTH-$(call ALLYES, FORMAT_FILTER PERMS_FILTER 
EDGEDETECT_FILTER) += fate-filter-edgedetect-colormix
 fate-filter-edgedetect-colormix: CMD = video_filter 
"format=gbrp,perms=random,edgedetect=mode=colormix" -frames:v 20
 
-FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue
-fate-filter-hue: CMD = video_filter "perms=random,hue=s=sin(2*PI*t)+1" 
-frames:v 20
+FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue1
+fate-filter-hue1: CMD = video_filter "perms=random,hue=s=sin(2*PI*t)+1" 
-frames:v 20
+
+FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue2
+fate-filter-hue2: CMD = video_filter "perms=random,hue=h=18*n" -frames:v 20
+
+FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue3
+fate-filter-hue3: CMD = video_filter "perms=random,hue=b=n-10" -frames:v 20
 
 FATE_FILTER_VSYNTH-$(CONFIG_IDET_FILTER) += fate-filter-idet
 fate-filter-idet: CMD = framecrc -flags bitexact -idct simple -i $(SRC) -vf 
idet -frames:v 25 -flags +bitexact
diff --git a/tests/ref/fate/filter-hue b/tests/ref/fate/filter-hue
deleted file mode 100644
index 2f1ae61..000
--- a/tests/ref/fate/filter-hue
+++ /dev/null
@@ -1 +0,0 @@
-hue 57463dd9bc17156a51b704dd7271c863
diff --git a/tests/ref/fate/filter-hue1 b/tests/ref/fate/filter-hue1
new file mode 100644
index 000..7059ba7
--- /dev/null
+++ b/tests/ref/fate/filter-hue1
@@ -0,0 +1 @@
+hue157463dd9bc17156a51b704dd7271c863
diff --git a/tests/ref/fate/filter-hue2 b/tests/ref/fate/filter-hue2
new file mode 100644
index 000..2e060e1
--- /dev/null
+++ b/tests/ref/fate/filter-hue2
@@ -0,0 +1 @@
+hue2e951ae8ffb279552abc4354c4de7cb5b
diff --git a/tests/ref/fate/filter-hue3 b/tests/ref/fate/filter-hue3
new file mode 100644
index 000..14a8379
--- /dev/null
+++ b/tests/ref/fate/filter-hue3
@@ -0,0 +1 @@
+hue3149dc22f5dc9f578f7d281dc3120c09b
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH 06/13] avformat/mxfenc: Add Sample width/height/x offset/y offset, Display x offset and F2 offset

[Tobias Rapp]

On 08.05.2018 12:40, Tomas Härdin wrote:

mån 2018-05-07 klockan 12:38 +0200 skrev Michael Niedermayer:

Signed-off-by: Michael Niedermayer 

+if (sc->interlaced) {
+//Display F2 Offset
+mxf_write_local_tag(pb, 4, 0x3217);
+avio_wb32(pb, -((st->codecpar->height - display_height)&1));


Negative values for DisplayF2Offset are not valid


Can't say anything about the formula but according to The MXF Book (ISBN 
978-0240806938, page 187) the DisplayF2Offset property is defined as 
Int32, not UInt32.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] fate: add more tests for hue video filter

[Tobias Rapp]

On 10.05.2018 23:04, Michael Niedermayer wrote:

On Wed, May 09, 2018 at 12:05:48PM +0200, Tobias Rapp wrote:

Adds tests for the hue angle and brightness filter parameters.
Renames the existing saturation parameter test for consistency.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  tests/fate/filter-video.mak | 10 --
  tests/ref/fate/filter-hue   |  1 -
  tests/ref/fate/filter-hue1  |  1 +
  tests/ref/fate/filter-hue2  |  1 +
  tests/ref/fate/filter-hue3  |  1 +
  5 files changed, 11 insertions(+), 3 deletions(-)
  delete mode 100644 tests/ref/fate/filter-hue
  create mode 100644 tests/ref/fate/filter-hue1
  create mode 100644 tests/ref/fate/filter-hue2
  create mode 100644 tests/ref/fate/filter-hue3


should be ok


Pushed, thanks for review.

Regards,
Tobias

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

[FFmpeg-devel] [PATCH] avfilter/vsrc_testsrc: add pal75bars and pal100bars video filter sources

[Tobias Rapp]

Generates color bar test patterns based on EBU PAL recommendations.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 Changelog|   1 +
 doc/filters.texi |  10 +++-
 libavfilter/Makefile |   2 +
 libavfilter/allfilters.c |   2 +
 libavfilter/version.h|   2 +-
 libavfilter/vsrc_testsrc.c   | 106 ++-
 tests/fate/filter-video.mak  |   6 +++
 tests/ref/fate/filter-pal100bars |  10 
 tests/ref/fate/filter-pal75bars  |  10 
 9 files changed, 146 insertions(+), 3 deletions(-)
 create mode 100644 tests/ref/fate/filter-pal100bars
 create mode 100644 tests/ref/fate/filter-pal75bars

diff --git a/Changelog b/Changelog
index c9f1200..562fbc4 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,7 @@ version :
 - amplify filter
 - fftdnoiz filter
 - aderivative and aintegral audio filters
+- pal75bars and pal100bars video filter sources
 
 
 version 4.0:
diff --git a/doc/filters.texi b/doc/filters.texi
index 7646efb..cf15186 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17825,13 +17825,15 @@ ffplay -f lavfi 
life=s=300x200:mold=10:r=60:ratio=0.1:death_color=#C83232:life_c
 @anchor{color}
 @anchor{haldclutsrc}
 @anchor{nullsrc}
+@anchor{pal75bars}
+@anchor{pal100bars}
 @anchor{rgbtestsrc}
 @anchor{smptebars}
 @anchor{smptehdbars}
 @anchor{testsrc}
 @anchor{testsrc2}
 @anchor{yuvtestsrc}
-@section allrgb, allyuv, color, haldclutsrc, nullsrc, rgbtestsrc, smptebars, 
smptehdbars, testsrc, testsrc2, yuvtestsrc
+@section allrgb, allyuv, color, haldclutsrc, nullsrc, pal75bars, pal100bars, 
rgbtestsrc, smptebars, smptehdbars, testsrc, testsrc2, yuvtestsrc
 
 The @code{allrgb} source returns frames of size 4096x4096 of all rgb colors.
 
@@ -17846,6 +17848,12 @@ The @code{nullsrc} source returns unprocessed video 
frames. It is
 mainly useful to be employed in analysis / debugging tools, or as the
 source for filters which ignore the input data.
 
+The @code{pal75bars} source generates a color bars pattern, based on
+EBU PAL recommendations with 75% color levels.
+
+The @code{pal100bars} source generates a color bars pattern, based on
+EBU PAL recommendations with 100% color levels.
+
 The @code{rgbtestsrc} source generates an RGB test pattern useful for
 detecting RGB vs BGR issues. You should see a red, green and blue
 stripe from top to bottom.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f83a2b3..c68ef05 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -390,6 +390,8 @@ OBJS-$(CONFIG_MANDELBROT_FILTER) += 
vsrc_mandelbrot.o
 OBJS-$(CONFIG_MPTESTSRC_FILTER)  += vsrc_mptestsrc.o
 OBJS-$(CONFIG_NULLSRC_FILTER)+= vsrc_testsrc.o
 OBJS-$(CONFIG_OPENCLSRC_FILTER)  += vf_program_opencl.o opencl.o
+OBJS-$(CONFIG_PAL75BARS_FILTER)  += vsrc_testsrc.o
+OBJS-$(CONFIG_PAL100BARS_FILTER) += vsrc_testsrc.o
 OBJS-$(CONFIG_RGBTESTSRC_FILTER) += vsrc_testsrc.o
 OBJS-$(CONFIG_SMPTEBARS_FILTER)  += vsrc_testsrc.o
 OBJS-$(CONFIG_SMPTEHDBARS_FILTER)+= vsrc_testsrc.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 099c191..b44093d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -380,6 +380,8 @@ extern AVFilter ff_vsrc_mandelbrot;
 extern AVFilter ff_vsrc_mptestsrc;
 extern AVFilter ff_vsrc_nullsrc;
 extern AVFilter ff_vsrc_openclsrc;
+extern AVFilter ff_vsrc_pal75bars;
+extern AVFilter ff_vsrc_pal100bars;
 extern AVFilter ff_vsrc_rgbtestsrc;
 extern AVFilter ff_vsrc_smptebars;
 extern AVFilter ff_vsrc_smptehdbars;
diff --git a/libavfilter/version.h b/libavfilter/version.h
index b1c73be..c32afce 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,7 +30,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVFILTER_VERSION_MAJOR   7
-#define LIBAVFILTER_VERSION_MINOR  23
+#define LIBAVFILTER_VERSION_MINOR  24
 #define LIBAVFILTER_VERSION_MICRO 100
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index a790974..8d76ae9 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -1252,7 +1252,7 @@ AVFilter ff_vsrc_yuvtestsrc = {
 
 #endif /* CONFIG_YUVTESTSRC_FILTER */
 
-#if CONFIG_SMPTEBARS_FILTER || CONFIG_SMPTEHDBARS_FILTER
+#if CONFIG_PAL75_FILTER || CONFIG_PAL100_FILTER || CONFIG_SMPTEBARS_FILTER || 
CONFIG_SMPTEHDBARS_FILTER
 
 static const uint8_t rainbow[7][4] = {
 { 180, 128, 128, 255 }, /* 75% white */
@@ -1264,6 +1264,16 @@ static const uint8_t rainbow[7][4] = {
 {  35, 212, 114, 255 }, /* 75% blue */
 };
 
+static const uint8_t rainbow100[7][4] = {
+{ 235, 128, 128, 255 }, /* 100% white */
+{ 210,  16, 146, 255 }, /* 100% yellow */
+{ 170, 166,  16, 255 }, /* 100% cyan */
+{ 145,  54,  34, 255 }, /* 100% green */
+{ 10

Re: [FFmpeg-devel] [PATCH] avutil/error: document av_err2str

[Tobias Rapp]

On 17.05.2018 11:24, Zhao Zhili wrote:

---
  libavutil/error.h | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/libavutil/error.h b/libavutil/error.h
index 71df4da..b357bfa 100644
--- a/libavutil/error.h
+++ b/libavutil/error.h
@@ -115,6 +115,9 @@ static inline char *av_make_error_string(char *errbuf, 
size_t errbuf_size, int e
  /**
   * Convenience macro, the return value should be used only directly in
   * function arguments but never stand-alone.
+ *
+ * @warning The macro uses compound literal which was introduced in C99. It may
+ *  not work in C++.
   */
  #define av_err2str(errnum) \
  av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0}, 
AV_ERROR_MAX_STRING_SIZE, errnum)



If not using the macro is enough to silence affected C++ compilers, I 
prefer this patch over the other one that hides the macro with ifdefs.


Regards,
Tobias

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

Re: [FFmpeg-devel] compound literal in public header file

[Tobias Rapp]

On 16.05.2018 11:27, Tomas Härdin wrote:

ons 2018-05-16 klockan 11:16 +0200 skrev Tobias Rapp:

On 16.05.2018 10:29, Tomas Härdin wrote:

ons 2018-05-16 klockan 10:18 +0800 skrev Zhao Zhili:

The av_err2str macro in libavutil/error.h use compound literal:

#define av_err2str(errnum) \
   av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
AV_ERROR_MAX_STRING_SIZE, errnum)

C++ compiler may not support it or treat the usage as invalid.
For example, g++ 5.4 raise an error: taking address of temporary
array.

1. Should the macro be defined for C only?
2. Or make it as valid C++? (I don't know how to do that)


First of all, this shouldn't matter since av_err2str is not actually
used in any header. libavutil/timer.h makes use of it in another macro,
so that also doesn't matter.

Second, libavutil is a C library, not a C++ library. However, it might
be nicer to make that a static inline function, if possible. Or move it
to an internal header, since it doesn't look like something that should
be exposed as part of the public API.


ffmpeg.c/ffprobe.c is using it for assembling log messages and I'm using
it in my private tools, too. As it is a convenient utility function I
would prefer to keep it in the public headers of libavutil.


ffmpeg.c/ffprobe.c are C.. :)

If you're in C++, why don't you just write your own variant that
returns std::string?


Yes, I am referring to usage of the libavutil headers in C. If the macro 
is only hidden for C++ and available in C, that would be OK for me. But 
if the static inline function variant would support both C and C++, this 
would look like a solution where C++ users are not forced to implement a 
more "integrated" replacement but of course have the option to do so.


Regards,
Tobias

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

Re: [FFmpeg-devel] compound literal in public header file

[Tobias Rapp]

On 16.05.2018 10:29, Tomas Härdin wrote:

ons 2018-05-16 klockan 10:18 +0800 skrev Zhao Zhili:

The av_err2str macro in libavutil/error.h use compound literal:

#define av_err2str(errnum) \
  av_make_error_string((char[AV_ERROR_MAX_STRING_SIZE]){0},
AV_ERROR_MAX_STRING_SIZE, errnum)

C++ compiler may not support it or treat the usage as invalid.
For example, g++ 5.4 raise an error: taking address of temporary
array.

1. Should the macro be defined for C only?
2. Or make it as valid C++? (I don't know how to do that)


First of all, this shouldn't matter since av_err2str is not actually
used in any header. libavutil/timer.h makes use of it in another macro,
so that also doesn't matter.

Second, libavutil is a C library, not a C++ library. However, it might
be nicer to make that a static inline function, if possible. Or move it
to an internal header, since it doesn't look like something that should
be exposed as part of the public API.


ffmpeg.c/ffprobe.c is using it for assembling log messages and I'm using 
it in my private tools, too. As it is a convenient utility function I 
would prefer to keep it in the public headers of libavutil.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: Use the colour properties from the input stream when doing transcode

[Tobias Rapp]

On 22.05.2018 00:07, Mark Thompson wrote:

On 16/05/18 08:19, Haihao Xiang wrote:

In lavc/hevec_vaapi, colour properties in AVCodecContext are needed to
write the sequence header

Tested by the command below:
ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i input-with-hdr.mkv -c:v hevc_vaapi
-profile:v main10 output.h265

Signed-off-by: Haihao Xiang 
---
  fftools/ffmpeg.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5a19a09d9a..80b5441f8f 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3298,6 +3298,10 @@ static int init_output_stream_encode(OutputStream *ost)
  dec_ctx = ist->dec_ctx;
  
  enc_ctx->chroma_sample_location = dec_ctx->chroma_sample_location;

+enc_ctx->color_range= dec_ctx->color_range;
+enc_ctx->color_primaries= dec_ctx->color_primaries;
+enc_ctx->color_trc  = dec_ctx->color_trc;
+enc_ctx->colorspace = dec_ctx->colorspace;
  } else {
  for (j = 0; j < oc->nb_streams; j++) {
  AVStream *st = oc->streams[j];



There are outstanding patches passing color_range through the filter chain (see 
), and 
that would be the right solution for the rest of these properties as well, but it 
would require significantly more work.

I think hacking it like this is ok for now?  It's not worse than before since a 
change during filtering wasn't visible anyway, and the manual options do still 
work to override it.  I think the commit message could be a little clearer 
about the problem (really, that this colour information doesn't pass through 
filtering) and its limitations (requires a single input matched to the output; 
will write the wrong thing if filtering changes anything) though, or maybe that 
could be explained in a comment.

Does anyone else have any thoughts on this?  If there are no objections then I 
would apply it updated with a clearer explanation.


Recently I checked why interlacing information is not forwarded 
correctly from the decoded+filtered frame to the encoder and noticed 
that the encoder is just updated too late to be picked up by the muxer 
when writing header information. I think something similar is happening 
here.


Initializing the encoder here will fix the situation in case the filter 
graph between decoder and encoder doesn't change one of the settings, 
else it will write wrong information -- which is worse than the status 
quo. In my opinion the best solution would be to change ffmpeg.c to 
write a header after it has fetched a frame from each output filter 
graph, so it can use the actual output frame properties. Until then a 
work-around is to initialize the encoder manually on the command-line, 
in case you are able to determine the output values in advance (e.g. by 
using ffprobe).


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: Use the colour properties from the input stream when doing transcode

[Tobias Rapp]

On 25.05.2018 07:58, Xiang, Haihao wrote:

On Thu, 2018-05-24 at 11:15 +0100, Mark Thompson wrote:


For example:

ffmpeg -i bt709_input.mkv -vf colorspace=bt2020 bt2020_output.mkv

will have the output file marked as BT.709 after this patch, where previously
it was "unspecified".  (Explicitly setting -color_primaries/-color_trc/-
colorspace on the output works in both cases.)


I agree with you it's not worse than before as we don't get the expected result
in both cases.


Not quite: When a file says "I don't know this property value" you have 
a chance to lookup the value somewhere else or use a default. When it 
says "I know the value" and gives a wrong value, you completely loose trust.


So in my opinion this patch should not be applied, as it possibly makes 
ffmpeg generate files with wrong information where it just had no 
information before. The correct approach would be to set the encoder 
properties from output frame data and only write a header once the 
encoders have been initialized completely.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avfilter/vsrc_testsrc: add pal75bars and pal100bars video filter sources

[Tobias Rapp]

On 18.05.2018 15:23, Paul B Mahol wrote:

On 5/17/18, Tobias Rapp <t.r...@noa-archive.com> wrote:

Generates color bar test patterns based on EBU PAL recommendations.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  Changelog|   1 +
  doc/filters.texi |  10 +++-
  libavfilter/Makefile |   2 +
  libavfilter/allfilters.c |   2 +
  libavfilter/version.h|   2 +-
  libavfilter/vsrc_testsrc.c   | 106
++-
  tests/fate/filter-video.mak  |   6 +++
  tests/ref/fate/filter-pal100bars |  10 
  tests/ref/fate/filter-pal75bars  |  10 
  9 files changed, 146 insertions(+), 3 deletions(-)
  create mode 100644 tests/ref/fate/filter-pal100bars
  create mode 100644 tests/ref/fate/filter-pal75bars



lgtm


Applied, thanks for the review.

Regards,
Tobias

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter/vsrc_testsrc: fix a preprocessor check

[Tobias Rapp]

On 18.05.2018 22:43, James Almer wrote:

ffmpeg | branch: master | James Almer  | Fri May 18 17:42:57 
2018 -0300| [79126ce80e21f2bc986fef7b8f0d6335136538da] | committer: James Almer

avfilter/vsrc_testsrc: fix a preprocessor check

Signed-off-by: James Almer 


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=79126ce80e21f2bc986fef7b8f0d6335136538da

---

  libavfilter/vsrc_testsrc.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index 8d76ae9271..f06714807f 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -1252,7 +1252,7 @@ AVFilter ff_vsrc_yuvtestsrc = {
  
  #endif /* CONFIG_YUVTESTSRC_FILTER */
  
-#if CONFIG_PAL75_FILTER || CONFIG_PAL100_FILTER || CONFIG_SMPTEBARS_FILTER || CONFIG_SMPTEHDBARS_FILTER

+#if CONFIG_PAL75BARS_FILTER || CONFIG_PAL100BARS_FILTER || 
CONFIG_SMPTEBARS_FILTER || CONFIG_SMPTEHDBARS_FILTER
  
  static const uint8_t rainbow[7][4] = {

  { 180, 128, 128, 255 }, /* 75% white */



I'm sorry for the oversight. Thanks for fixing it!

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: Use the colour properties from the input stream when doing transcode

[Tobias Rapp]

On 28.05.2018 09:30, Xiang, Haihao wrote:

On Sat, 2018-05-26 at 17:29 +0100, Mark Thompson wrote:

On 25/05/18 07:57, Tobias Rapp wrote:

On 25.05.2018 07:58, Xiang, Haihao wrote:

On Thu, 2018-05-24 at 11:15 +0100, Mark Thompson wrote:


For example:

ffmpeg -i bt709_input.mkv -vf colorspace=bt2020 bt2020_output.mkv

will have the output file marked as BT.709 after this patch, where
previously
it was "unspecified".  (Explicitly setting -color_primaries/-color_trc/-
colorspace on the output works in both cases.)


I agree with you it's not worse than before as we don't get the expected
result
in both cases.


Not quite: When a file says "I don't know this property value" you have a
chance to lookup the value somewhere else or use a default. When it says "I
know the value" and gives a wrong value, you completely loose trust.


Right, that is a compelling argument.  I agree with you, so I definitely won't
apply the patch in this form.



According the comment in avcodec.h, the color properties in AVCodecContext
should be set by user for encoding. I think ffmpeg is the user in the case
below. Where are the color properties set if we don't set the default values in
init_output_stream_encode()?

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format
vaapi -i input-with-hdr.mkv -c:v hevc_vaapi -profile:v main10 output.h265


Setting color properties in init_output_stream_encode() basically looks 
OK, but the question "when" seems more important than "where". It should 
be called after some output frame is available, and use that to 
initialize the encoder. Currently the current AVFrame is not available 
in init_output_stream_encode(), only the buffersink properties.


Hopefully somebody with more knowledge about FFmpeg infrastructure will 
make a recommendation on how this should be solved: By adding color 
properties and other frame data to the buffersink interface? Or by 
making the current/last frame available in init_output_stream_encode()? 
Or ...?


It doesn't need to be auto-negotiated like in the mentioned patch series 
for color_range, it just needs to be forwarded properly from filter 
graph output to the encoder.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg: properly initialize output stream field order

[Tobias Rapp]

On 26.04.2018 16:06, Tobias Rapp wrote:

Fixes stream field order written by avformat_write_header when "top"
option is specified on the command-line.

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
  fftools/ffmpeg.c | 6 ++
  1 file changed, 6 insertions(+)

[...]


Pushed, thanks to both of you for the review.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] add dumpwave filter

[Tobias Rapp]

On 10.01.2018 18:18, Kyle Swanson wrote:

Hi,

For this to be a part of libavfilter the output needs to be more generic
than the just the Soundcloud format. If we want this to be generally useful
it should probably just output an array of floats between 0.0 and 1.0. The
consumer of this data (JS library, or whatever) can use this in whatever
way it wants.


I agree. If the BWF Peak Envelope output which was suggested in the 
other thread does not match your demands and filter implementation is 
actually necessary I would prefer if the filter would attach the RMS 
value(s) as frame metadata instead of directly dumping to file. Frame 
metadata can then be re-used by other filters or dumped into file by 
using the existing "ametadata" filter.


This would be similar to:

ffmpeg -i input-file -f null -filter:a 
"asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file.dat" 
/dev/null


BTW: The "astats" filter already provides some RMS values.


If you send another patch, just reply to this thread because
that makes it easier to follow (sending a patch as an attachment is OK).
Here are some critiques:

[...]


Also when sending patches adding an increased version number helps 
sorting out which is the latest one (git format-patch -v2 ...).


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

[Tobias Rapp]

On 05.01.2018 11:18, Jerome Martinez wrote:

0001-FFV1-make-RGB48-support-as-non-experimental.patch

From cd1bfe68a1a809700f25e593ac21ca3876d265ad Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 5 Jan 2018 11:09:01 +0100
Subject: [PATCH] FFV1: make RGB48 support as non-experimental


make => mark

BTW: common subject line format would be something like 
"avcodec/ffv1enc: mark RGB48 support as non-experimental"



Resulting bitstream was tested with a conformance checker
using the last draft of FFV1 specifications.
---
 libavcodec/ffv1enc.c | 4 
 1 file changed, 4 deletions(-)


Otherwise LGTM.

Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.

[Tobias Rapp]

On 10.01.2018 09:34, Дмитрий Гуменюк wrote:

There is no existing dumping format for RMS. How to make it generic?


Some of my applications use the following pattern to dump audio envelope 
data during transcoding:


ffmpeg -i input-file -f [...] output-file \
  -f wav -write_peak only peak-file

The data format of "peak-file" follows EBU Tech 3285 Supplement 3 (BWF 
Peak Envelope Chunk).


Regards,
Tobias

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

[FFmpeg-devel] [PATCH 1/2] examples/filtering_audio: added loop for draining the filtergraph

[Tobias Rapp]

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 doc/examples/filtering_audio.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
index 18d6ca2..070d0cb3 100644
--- a/doc/examples/filtering_audio.c
+++ b/doc/examples/filtering_audio.c
@@ -280,6 +280,25 @@ int main(int argc, char **argv)
 }
 av_packet_unref();
 }
+if (ret == AVERROR_EOF) {
+/* signal EOF to the filtergraph */
+if (av_buffersrc_add_frame_flags(buffersrc_ctx, NULL, 0) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error while closing the 
filtergraph\n");
+goto end;
+}
+
+/* pull remaining frames from the filtergraph */
+while (1) {
+ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+break;
+if (ret < 0)
+goto end;
+print_frame(filt_frame);
+av_frame_unref(filt_frame);
+}
+}
+
 end:
 avfilter_graph_free(_graph);
 avcodec_free_context(_ctx);
-- 
2.7.4


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

[FFmpeg-devel] [PATCH 2/2] examples/filtering_video: added loop for draining the filtergraph

[Tobias Rapp]

Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
 doc/examples/filtering_video.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 9b607ba..be00a1b 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -276,6 +276,25 @@ int main(int argc, char **argv)
 }
 av_packet_unref();
 }
+if (ret == AVERROR_EOF) {
+/* signal EOF to the filtergraph */
+if (av_buffersrc_add_frame_flags(buffersrc_ctx, NULL, 0) < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error while closing the 
filtergraph\n");
+goto end;
+}
+
+/* pull remaining frames from the filtergraph */
+while (1) {
+ret = av_buffersink_get_frame(buffersink_ctx, filt_frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+break;
+if (ret < 0)
+goto end;
+display_frame(filt_frame, buffersink_ctx->inputs[0]->time_base);
+av_frame_unref(filt_frame);
+}
+}
+
 end:
 avfilter_graph_free(_graph);
 avcodec_free_context(_ctx);
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH] add dumpwave filter

[Tobias Rapp]

On 15.01.2018 13:48, Dmytro Humeniuk wrote:



On 15 Jan 2018, at 09:14, Tobias Rapp <t.r...@noa-archive.com> wrote:

On 13.01.2018 23:52, Дмитрий Гуменюк wrote:

Hi,

On 13 Jan 2018, at 01:37, Дмитрий Гуменюк <dmitry.gumen...@gmail.com> wrote:

Hi


On 12 Jan 2018, at 13:32, Дмитрий Гуменюк <dmitry.gumen...@gmail.com> wrote:


On 12 Jan 2018, at 13:17, Tobias Rapp <t.r...@noa-archive.com> wrote:

On 12.01.2018 12:16, Дмитрий Гуменюк wrote:

Hi

On 11 Jan 2018, at 09:20, Tobias Rapp <t.r...@noa-archive.com> wrote:

On 10.01.2018 18:18, Kyle Swanson wrote:

Hi,
For this to be a part of libavfilter the output needs to be more generic
than the just the Soundcloud format. If we want this to be generally useful
it should probably just output an array of floats between 0.0 and 1.0. The
consumer of this data (JS library, or whatever) can use this in whatever
way it wants.


I agree. If the BWF Peak Envelope output which was suggested in the other 
thread does not match your demands and filter implementation is actually 
necessary I would prefer if the filter would attach the RMS value(s) as frame 
metadata instead of directly dumping to file. Frame metadata can then be re-

RMS values may be counted for several frames or only for a half of a frame

used by other filters or dumped into file by using the existing "ametadata" 
filter.

This would be similar to:

ffmpeg -i input-file -f null -filter:a 
"asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file.dat" 
/dev/null

I like this idea, but won’t asetnsamples affect performance by creating fifo 
queue? And it may require some effort to parse long output


I added asetnsamples to define the audio frame size (interval of values from astats). You 
can reduce the number of lines printed by ametadata by using the 
"key=lavfi.astats.foo" option.

I used asetnsamples as well, and I measured performance while transcoding - it 
appears to be slight slower

I think output is now more generic and I got rid of long switch/case, thanks 
for support

Here is most recent patch, seems like all comments are addressed, did I miss 
something?


I still would prefer to have the value attached as frame metadata, then dumped into file via the 
existing "ametadata" filter. Even better would be to integrate the statistic value (if 
missing) into the "astats" filter.

If your concern is the output format of "ametadata" then some output format 
extension (CSV/JSON) needs to be discussed for ametadata/metadata.

If your concern is performance then please add some numbers. In my tests using an approx. 
5 minutes input WAV file (48kHz, stereo) the run with "asetnsamples" was 
considerably faster than the run without (1.7s vs. 13.9s)

Hi
As I mentioned previously adding metadata to each frame is not possible
as value may be counted for several frames or only for a half of a frame

I used 2 hours long 48kHz mp3 
https://s3-eu-west-1.amazonaws.com/balamii/SynthSystemSystersJAN2018.mp3
For this purposes I set up CentOS AWS EC2 nano instance
Then I transcoded it while filtering like following (just to recreate real 
situation):
1. -filter:a 
"asetnsamples=192197,astats=metadata=on,ametadata=print:file=stats-file.dat" 
out.mp3
2. -filter:a "dumpwave=n=192197:f=-" out.mp3
Results:
1. 244810550046 nanoseconds
2. 87494286740 nanoseconds

One of the possible use cases - to set up 2 chains of asetnsamples->metadata - 
for example:
"asetnsamples=192197,astats=metadata=on,ametadata=print:file=stats-file.dat,asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file1.dat”
 for sure it will affect performance
Comparing with "dumpwave=n=192197:f=out1,dumpwave=n= 22050:f=out2"


Sorry, I misunderstood your concerns regarding asetnsamples filter 
performance. The numbers I provided have been for


"asetnsamples=22050,astats=metadata=on,ametadata=print:file=stats-file.dat"

versus

"astats=metadata=on,ametadata=print:file=stats-file.dat"

When comparing astats+ametadata versus dumpwave it is obvious that a 
specialized filter which only calculates one statistic value is faster 
than a filter that calculates multiple statistics. But still my opinion 
is that if the dumpwave filter is to be added to the codebase it should 
be more generic (i.e. output frame metadata similar to the psnr/ssim 
filters for video).


Regards,
Tobias

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