Add an option to webm_dash_manifest demuxer to specify a value for
"bandwidth" field in the DASH manifest. The value is then used by
the muxer. Fixes an existing FIXME in the code.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>
As it gives excellent encoding gains at an insignificant speed increase
and passes fate without problems, it should now be safe to enable by
default.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This merges commits 8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4 and
096a8effa3f8f3455292c958c3ed07e798def7bd by Anton Khirnov, with the
following change:
- extract_extradata_check() is added to know if the codec is supported
by the bsf before trying to initialize it. This behaviour is similar to
the old AVCodecParser.split checks.
The FATE reference changes are due to the filtered out NAL units that
the old AVCodecParser.split implementation left alone.
Decoding is unchanged as the functions that parse extradata simply
ignored said unnecessary NAL units.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '481ff3cf018811ba3235f1c236e970f32a6300b9':
fate: Add h264 and hevc extradata reload tests
Only the HEVC part is merged, see 00c80798160f930ce680f98f869c23d91a261f06
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b90c8a3d08e3f9ad4de1253376d2d1d93abb8b8c':
fate: Add tests for mov display matrix
Adapted to use ffprobe -show_entries
Merged-by: James Almer <jamrial@gmail.com>
This field is of little value, and interferes with testing side data,
since sizes can be different on multiple architectures.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.
Adds an internal helper function for bitrate guessing.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Preparation for potentially disabling merged side data by default in the
libs. Do this in particular because it affects fate tests.
The changed tests either reflect added packet side data, or the changed
packet size due to merged side data removal reducing the packet size.
The Chen-Shapiro(CS) test was used to test normality for
Lagged Fibonacci PRNG.
Normality Hypothesis Test:
The null hypothesis formally tests if the population
the sample represents is normally-distributed. For
CS, when the normality hypothesis is True, the
distribution of QH will have a mean close to 1.
Information on CS can be found here:
http://www.stata-journal.com/sjpdf.html?articlenum=st0264http://www.originlab.com/doc/Origin-Help/NormalityTest-Algorithm
Signed-off-by: Thomas Turner <thomastdt@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The constants used in the decoder used floating point precision,
and this caused different values to be generated on different
architectures. Additionally on big endian machines, the fate test
would output bytes in native order, which is different from the one
hardcoded in the test.
So, eradicate floating point numbers and use fixed point (32.32)
arithmetics everywhere, replacing constants with precomputed integer
values, and force the pixel format output to be the same in the fate
test.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.
This merges Libav commit a3a0230. It was previously skipped.
The code in flush_encoders() which sets up a "fake" format wasn't in
Libav. I'm not sure if it's a good idea, but it tends to give
behavior closer to the old one in certain corner cases.
The vp8-size-change gives different result, because now the size of
the first frame is used. libavformat reported the size of the largest
frame for some reason.
The exr tests now use the sample aspect ratio of the first frame. For
some reason libavformat determines 0/1 as aspect ratio, while the
decoder returns the correct one.
The ffm and mxf tests change the field_order values. I'm assuming
another libavformat/decoding mismatch.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This will be useful in the following commit, after which the muxer
timebase is not always available when encoding.
This merges Libav commit 3e265ca. It was previously skipped.
There are some changes with how/when the mux_timebase field is set,
because the Libav approach often causes a too imprecise time base
to be set. This is hard, because the muxer's write_header function
can readjust the timebase, at which point we might already have
encoded packets buffered. (It might be better to buffer them after
the encoder, instead of after all the timestamp handling logic
before muxing.)
The two FATE tests change because the output time base is raised
for subtitles. (Needed to avoid certain rounding issues in other
cases.)
Includes a minor merge fix by Mark Thompson, and
avconv: Move rescale to stream timebase before monotonisation
also by Mark Thompson <sw@jkqxz.net>.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This should fix the fate failure due to a truncated last frame.
Alternatively the frame could be dropped.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 664/clusterfuzz-testcase-4917047475568640
The change to fate is due to a truncated last frames which is now detected as damaged.
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
