Bitstream generated using the reference encoder, then edited to fix the
colour description and an extra metadata block added. FFmpeg decoder
output is identical to the reference decoder output.
The content used is the first three frames of "Waterfall" from the SVT
Open Content Video Test Suite 2022. This is copyright Sveriges
Television AB and is used under the Creative Commons Attribution 4.0
International License.
This bsf converts AV_PKT_DATA_NEW_EXTRADATA side data in avcc format
to in-band annexb format. However, the side data wasn't been removed
and copied from input packet to output packet. So the output packet
has mixed bitstream format. We don't support mixed bitstream format.
For example, h264_metadata report error in the following case:
ffmpeg -i foo.flv \
-bsf:v "h264_mp4toannexb,h264_metadata" \
-c copy -f null
This patch removed NEW_EXTRADATA side data after process.
This patch also add a check so only NEW_EXTRADATA in avcc format is
processed. NEW_EXTRADATA in annexb format is copied to output as is.
Reported-by: jiangjie <jiangjie618@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
A sample with a particular partitioning structure that could not be read
correctly before 26c5d8cf5d
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Since 45eeb1f785
optimal Huffman tables are the default (without slice-threading).
This made the fate-vsynth*-mjpeg-{trell-,}-huffman tests
identical to their corresponding tests without "-huffman".
This is of course wasteful, so switch the two tests with
"-huffman" counterparts back to the default tables.
Also use one of these tests to test slice threaded encoding.
It has so far been untested.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is currently not due to endianness. This forced to add
workarounds with sed in fate/mxf.mak (which are removed
in this commit).
This is supposed to fix the enhanced-flv-hevc-hdr10 test
on big endian systems.
Reviewed-by: Zhao Zhili <quinkblack-at-foxmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
With this modification the test would have caught the regression
introduced in 72bf3d3c12.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Encoding was untested before this.
Notice that the filesize degradation is partially due to
mpegvideo no longer using progressive_sequence and
progressive_frame.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Main profile of AAC is... terrible.
It enables the use of delta coding across coefficients of two frames
to try to increase compression, and it enabled one more pole for TNS
filters.
What the AAC authors failed to take into account were basic
mathematics, as MDCT leakage (e.g. the spread of each frequency when
represented in a discrete spectrum) is significant in most audio codecs.
This leads to huge variations between each frame, basically rendering
prediction completely pointless.
In fact, enabling AAC-Main prediction does not, in general, even recoup
the metadata losses from signalling the profile and prediction properties
in the first place. So you lose efficiency by using AAC Main.
The rumor is that it was put in the AAC spec for patent reasons, though
patent-wise, it has about as much use as a patent for a bicycle designed
for use by snakes.
The only other thing AAC Main changes is it permits 3-pole TNS filters.
When AAC's bands are absolutely tiny, except for very high frequency bands,
where you're likely to use PNS instead.
Just get rid of it.
In f121d95, the outlink framerate was unconditionally unset.
This breaks/bloats outputs from CFR muxers unless the user explicitly
sets a sane framerate. And the most common invocation for setpts seen in
workflows, our docs and across the web is `PTS-STARTPTS` or others of the
general form `PTS+constant` which preserves the input framerate.
Default value is false, which restores old behaviour.
Fixes#11428
This sample is rather difficult, containing a lot of subtle edge cases
which revealed errors in the VVC decoder. It covers 88.4% of lines in
libavcodec/vvc and brings the line coverage of the entire VVC fate suite
from 96.3% to 97.2%.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This fixes occasional failed tests, if doing "make fate" without a
regular "make" or "make all" inbetween.
Signed-off-by: Martin Storsjö <martin@martin.st>
The filter currently uses inaccurate frequencies, this is in preparation for
fixing that, by using numbers that will map to the equivalent value in the
future code.
Signed-off-by: Marton Balint <cus@passwd.hu>
