Allows the creation of the sdtp atom while remuxing MP4 to MP4. This
atom is required by Apple devices (iPhone, Apple TV) in order to accept
2160p medias.

The flac parser uses a fifo to buffer its data. Consequently, when
searching for sync codes of flac packets, one needs to take care of
the possibility of wraparound. This is done by using an optimized start
code search that works on each of the continuous buffers separately and
by explicitly checking whether the last pre-wrap byte and the first
post-wrap byte constitute a valid sync code.

Moreover, the last MAX_FRAME_HEADER_SIZE - 1 bytes ought not to be searched
for (the start of) a sync code because a header that might be found in this
region might not be completely available. These bytes ought to be searched
lateron when more data is available or when flushing.

Unfortunately there was an off-by-one error in the calculation of the
length to search of the post-wrap buffer: It was too large, because the
calculation was based on the amount of bytes available in the fifo from
the last pre-wrap byte onwards. This meant that a header might be
parsed twice (once prematurely and once regularly when more data is
available); it could also mean that an invalid header will be treated as
valid (namely if the length of said invalid header is
MAX_FRAME_HEADER_SIZE and the invalid byte that will be treated as the
last byte of this potential header happens to be the right CRC-8).

Should a header be parsed twice, the second instance will be the best child
of the first instance; the first instance's score will be
FLAC_HEADER_BASE_SCORE - FLAC_HEADER_CHANGED_PENALTY ( = 3) higher than
the second instance's score. So the frame belonging to the first
instance will be output and it will be done as a zero length frame (the
difference of the header's offset and the child's offset). This has
serious consequences when flushing, as returning a zero length buffer
signals to the caller that no more data will be output; consequently the
last frames not yet output will be dropped.

Furthermore, a "sample/frame number mismatch in adjacent frames" warning
got output when returning the zero-length frame belonging to the first
header, because the child's sample/frame number of course didn't match
the expected sample frame/number given its parent.

filter/hdcd-mix.flac from the FATE-suite was affected by this (the last
frame was omitted) which is the reason why several FATE-tests needed to
be updated.

Fixes ticket #5937.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

Signed-off-by: Ting Fu <ting.fu@intel.com>
Signed-off-by: Ruiling Song <ruiling.song@intel.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

Signed-off-by: Marton Balint <cus@passwd.hu>

'make fate-dnn-layer-depth2space' to run the test
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

'make fate-dnn-layer-conv2d' to run the test
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

Fixes ticket #8175
Signed-off-by: James Almer <jamrial@gmail.com>

A threshold of 1 is sufficient for simple_dump_cut.webm, 10 is used
just to be sure the next truncated file doesnt cause the same issue

Obvious alternative fixes are to simply accept that the file is broken or to
write some advanced error concealment or to
simply accept that the decoder wont stop at the end of input.

Fixes: Ticket 8069 (artifacts not the differing md5 which was there before 1afd2469)
Fixes: simple_dump_cut.webm
Fixes: regression of 1afd2469

fate-vp5 changes because the last frame is truncated and now handled
differently.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Because the lavf_container is sometimes called with only 2 arguments,
fate tests produce bash errors like this:

  tests/fate-run.sh: 299: test: =: unexpected operator

This commit fixes this.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Right now, the concat filter does not set the frame_rate value on any of
the out links. As a result, the default ffmpeg behaviour kicks in - to
copy the framerate from the first input to the outputs.

If a later input is higher framerate, this results in dropped frames; if
a later input is lower framerate it might cause judder.

This patch checks if all of the video inputs have the same framerate, and
if not it sets the out link to use '1/0' as the frame rate, the value
meaning "unknown/vfr".

A test is added to verify the VFR behaviour. The existing test for CFR
behaviour passes unchanged.

Checks that seek to start indeed seeks to start.

the info can be saved in dnn operand object without regenerating again and again,
and it is also needed for layer split/merge, and for memory reuse.

to make things step by step, this patch just focuses on c code,
the change within python script will be added later.
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

This makes the code bitexact between platforms.
Intermediate timestamps between frames are preserved.
The timebase is simplified.
Rounding differs from doubles in cases where timestamps/durations
are "funny"

Suggested-by: jb
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes timecode calculation for NTSC frame rates.
Fixes ticket #5978.

This reverts commit a9dacdee.

This patch effectively made the decoder output vfr content out of samples
where cfr is expected.

Addresses ticket #7880.
Signed-off-by: James Almer <jamrial@gmail.com>

The packet counting based approach caused excessive sdt/pat/pmt for VBR, so
let's use a timestamp based approach instead similar to how we emit PCRs.
SDT/PAT/PMT period should be consistent for both VBR and CBR from now on.

Also change the type of sdt_period and pat_period to AV_OPT_TYPE_DURATION so no
floating point math is necessary.

Fixes ticket #3714.
Signed-off-by: Marton Balint <cus@passwd.hu>

background:
DNN (deep neural network) is a sub module of libavfilter, and FATE/dnn
is unit test for the DNN module, one unit test for one dnn layer.
The unit tests are not based on the APIs exported by libavfilter,
they just directly call into the functions within DNN submodule.

There is an issue when run the following command:
build$ ../ffmpeg/configure --disable-static --enable-shared
make
make fate-dnn-layer-pad

And part of error message:
tests/dnn/dnn-layer-pad-test.o: In function `test_with_mode_symmetric':
/work/media/ffmpeg/build/src/tests/dnn/dnn-layer-pad-test.c:73: undefined reference to `dnn_execute_layer_pad'

The root cause is that function dnn_execute_layer_pad is a LOCAL symbol
in libavfilter.so, and so the linker could not find it when build dnn-layer-pad-test.
To check it, just run: readelf -s libavfilter/libavfilter.so | grep dnn

So, add dependency in fate/dnn Makefile with ffmpeg static libraries.
This is the same method used in fate/checkasm
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

This fixes make fate issue for frame thread scale in my local testing
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>

At the moment scene change detection score uses all planes to detect scene
changes. In this regard this is similar how the frozen frames detection works.
However, in classic encoding scene change detection typically only uses the Y
plane.

We might get more resonable scores for scene change if we also use only
the Y plane for calculating the score if the pixel format is YUV. Although
this will require additional work once packed YUV formats are added,
because for the moment the generic scene sad score calculation has no way
to ignore some components in a packed format.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Thilo Borgmann <thilo.borgmann@mail.de>
Signed-off-by: Zhong Li <zhong.li@intel.com>

cuda_runtime.h as well as dynlink_loader.h used nonstandard inclusion
guards with an AV_ prefix, although these files are not in an libav*/
path. So change the inclusion guards and adapt the ref file of the
source fate test accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

'make fate-dnn-layer-pad' to run the test
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Pedro Arthur <bygrandao@gmail.com>

Fixes #8031.

This avoids automatic conversions to rgb if scene change score is used in the expression.

Below is the tested results for the new added pixel format without autoscale to rgb24:
1. AV_PIX_FMT_YUVJ420P
time ./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f lavfi \
"sws_flags=+accurate_rnd+bitexact;movie=../fate-suite/svq3/Vertical400kbit.sorenson3.mov,select=gt(scene\,.25)"

master:
pkt_pts=1620|tag:lavfi.scene_score=1.000000
pkt_pts=4140|tag:lavfi.scene_score=0.875036
pkt_pts=5800|tag:lavfi.scene_score=1.000000
pkt_pts=6720|tag:lavfi.scene_score=0.461625
pkt_pts=8160|tag:lavfi.scene_score=1.000000
pkt_pts=9760|tag:lavfi.scene_score=1.000000
pkt_pts=14080|tag:lavfi.scene_score=0.838916
pkt_pts=15700|tag:lavfi.scene_score=1.000000
pkt_pts=18500|tag:lavfi.scene_score=0.474948
pkt_pts=20040|tag:lavfi.scene_score=0.379700
pkt_pts=21760|tag:lavfi.scene_score=1.000000
./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f  0.71s user 0.01s system 99% cpu 0.721 total

patch applied:
pkt_pts=1620|tag:lavfi.scene_score=1.000000
pkt_pts=4140|tag:lavfi.scene_score=0.668643
pkt_pts=5800|tag:lavfi.scene_score=0.996721
pkt_pts=6720|tag:lavfi.scene_score=0.357390
pkt_pts=8160|tag:lavfi.scene_score=0.886268
pkt_pts=9760|tag:lavfi.scene_score=0.926219
pkt_pts=14080|tag:lavfi.scene_score=0.650033
pkt_pts=15700|tag:lavfi.scene_score=1.000000
pkt_pts=18500|tag:lavfi.scene_score=0.316402
pkt_pts=20040|tag:lavfi.scene_score=0.269509
pkt_pts=21760|tag:lavfi.scene_score=1.000000
./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f  0.19s user 0.01s system 81% cpu 0.240 total

2. AV_PIX_FMT_YUV420P
time ./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f lavfi \
"sws_flags=+accurate_rnd+bitexact;movie=../Passengers_Breakfast_1080-sdr.mkv,select=gt(scene\,.2)"
master:
pkt_pts=3587|tag:lavfi.scene_score=0.462364
pkt_pts=4838|tag:lavfi.scene_score=0.419519
pkt_pts=6548|tag:lavfi.scene_score=0.397027
pkt_pts=9968|tag:lavfi.scene_score=0.419245
pkt_pts=12471|tag:lavfi.scene_score=0.413084
pkt_pts=16225|tag:lavfi.scene_score=0.506370
pkt_pts=19645|tag:lavfi.scene_score=0.507538
pkt_pts=22314|tag:lavfi.scene_score=0.504319
pkt_pts=24817|tag:lavfi.scene_score=0.417544
pkt_pts=25651|tag:lavfi.scene_score=0.413916
pkt_pts=26652|tag:lavfi.scene_score=0.487707
18.58s user 0.07s system 99% cpu 18.663 total

patch applied:
pkt_pts=3587|tag:lavfi.scene_score=0.272173
pkt_pts=4838|tag:lavfi.scene_score=0.247841
pkt_pts=6548|tag:lavfi.scene_score=0.233134
pkt_pts=9968|tag:lavfi.scene_score=0.247253
pkt_pts=12471|tag:lavfi.scene_score=0.244129
pkt_pts=16225|tag:lavfi.scene_score=0.302531
pkt_pts=19645|tag:lavfi.scene_score=0.303560
pkt_pts=22314|tag:lavfi.scene_score=0.301861
pkt_pts=24817|tag:lavfi.scene_score=0.249331
pkt_pts=25651|tag:lavfi.scene_score=0.247096
pkt_pts=26652|tag:lavfi.scene_score=0.287728
10.90s user 0.06s system 99% cpu 10.967 total

3. AV_PIX_FMT_YUV422P

time ./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f lavfi \
"sws_flags=+accurate_rnd+bitexact;movie=../Passengers_Breakfast_1080-sdr.mkv,format=yuv422p,select=gt(scene\,.2)"
master:

patched applied:
pkt_pts=3587|tag:lavfi.scene_score=0.224017
pkt_pts=4838|tag:lavfi.scene_score=0.204225
pkt_pts=9968|tag:lavfi.scene_score=0.204636
pkt_pts=12471|tag:lavfi.scene_score=0.202772
pkt_pts=16225|tag:lavfi.scene_score=0.248765
pkt_pts=19645|tag:lavfi.scene_score=0.250144
pkt_pts=22314|tag:lavfi.scene_score=0.248802
pkt_pts=24817|tag:lavfi.scene_score=0.208362
pkt_pts=25651|tag:lavfi.scene_score=0.205777
pkt_pts=26652|tag:lavfi.scene_score=0.230742

4.  AV_PIX_FMT_YUV420P10
time ./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f lavfi \
"sws_flags=+accurate_rnd+bitexact;movie=../Passengers_Breakfast_4k.mkv,select=gt(scene\,.2)"

master:
pkt_pts=3587|tag:lavfi.scene_score=0.269890
pkt_pts=4838|tag:lavfi.scene_score=0.248957
pkt_pts=6548|tag:lavfi.scene_score=0.234619
pkt_pts=9969|tag:lavfi.scene_score=0.224912
pkt_pts=12471|tag:lavfi.scene_score=0.225158
pkt_pts=16225|tag:lavfi.scene_score=0.289809
pkt_pts=19645|tag:lavfi.scene_score=0.285013
pkt_pts=22314|tag:lavfi.scene_score=0.280295
pkt_pts=24817|tag:lavfi.scene_score=0.206486
pkt_pts=25651|tag:lavfi.scene_score=0.208556
pkt_pts=26652|tag:lavfi.scene_score=0.249577
./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f  76.03s user 0.22s system 99% cpu 1:16.27 total

patch applied
pkt_pts=3587|tag:lavfi.scene_score=0.269890
pkt_pts=4838|tag:lavfi.scene_score=0.248957
pkt_pts=6548|tag:lavfi.scene_score=0.234619
pkt_pts=9969|tag:lavfi.scene_score=0.224912
pkt_pts=12471|tag:lavfi.scene_score=0.225158
pkt_pts=16225|tag:lavfi.scene_score=0.289809
pkt_pts=19645|tag:lavfi.scene_score=0.285013
pkt_pts=22314|tag:lavfi.scene_score=0.280295
pkt_pts=24817|tag:lavfi.scene_score=0.206486
pkt_pts=25651|tag:lavfi.scene_score=0.208556
pkt_pts=26652|tag:lavfi.scene_score=0.249577
./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f  50.27s user 0.20s system 99% cpu 50.476 total

5. AV_PIX_FMT_RGBA, AV_PIX_FMT_ABGR, AV_PIX_FMT_BGRA, AV_PIX_FMT_GRAY8
are tested by format= with the fate sample: Vertical400kbit.sorenson3.mov like below:
time ./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f lavfi \
"sws_flags=+accurate_rnd+bitexact;movie=../fate-suite/svq3/Vertical400kbit.sorenson3.mov,format=rgba,select=gt(scene\,.25)"

patch applied:
pkt_pts=1620|tag:lavfi.scene_score=1.000000
pkt_pts=4140|tag:lavfi.scene_score=0.656277
pkt_pts=5800|tag:lavfi.scene_score=1.000000
pkt_pts=6720|tag:lavfi.scene_score=0.346218
pkt_pts=8160|tag:lavfi.scene_score=0.987686
pkt_pts=9760|tag:lavfi.scene_score=1.000000
pkt_pts=14080|tag:lavfi.scene_score=0.629187
pkt_pts=15700|tag:lavfi.scene_score=1.000000
pkt_pts=18500|tag:lavfi.scene_score=0.356211
pkt_pts=20040|tag:lavfi.scene_score=0.284775
pkt_pts=21760|tag:lavfi.scene_score=1.000000

6. AV_PIX_FMT_YUVJ422P
time ./ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags -bitexact -f lavfi \
"sws_flags=+accurate_rnd+bitexact;movie=../fate-suite/svq3/Vertical400kbit.sorenson3.mov,format=yuvj422p,select=gt(scene\,.25)"

patch applied:
pkt_pts=1620|tag:lavfi.scene_score=0.838281
pkt_pts=4140|tag:lavfi.scene_score=0.541382
pkt_pts=5800|tag:lavfi.scene_score=0.780588
pkt_pts=6720|tag:lavfi.scene_score=0.298274
pkt_pts=8160|tag:lavfi.scene_score=0.699106
pkt_pts=9760|tag:lavfi.scene_score=0.730136
pkt_pts=14080|tag:lavfi.scene_score=0.537742
pkt_pts=15700|tag:lavfi.scene_score=0.811946
pkt_pts=18500|tag:lavfi.scene_score=0.263382
pkt_pts=21760|tag:lavfi.scene_score=0.880773
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

why change .4 to .25, it's for:
one scenecut(pkt_pts=20040) isn't detected by 0.4 threshold

why not change to 0.3 instead of 0.25:
it will miss the scenecut(pkt_pts=20040) after applying the next
patch which enables yuvj420

for fate testing, it's better to catch all scenecut scenes.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

English was used before.
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Operates in the same way as the h264-levels test.

The tests previously rounded the timestamps. Its better in a fate test to preserve
the data from the demuxer and decoder.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>