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>
The earlier code only used the counts from the last slice.
The two FATE tests using slices show compression improvements
due to this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary, as we already have the entries sorted by
probability and therefore implicitly by length. All we need
on top of that to build the tree is the number of entries
of a given length.
Doing so gives a 3.6% speedup of ff_mjpeg_encode_huffman_close()
here; it also saves about 640B of .text here.
The new code puts values with higher probability to the left
of the tree. The old code did not and therefore
the FATE checksums needed to be updated. Due to MJPEG's
0xFF unescaping file sizes as well as file checksums
needed to be updated; the decoded picture hashes stayed
the same. Given that codes on the left of the tree have
on average fewer bits set than codes on the right, the
file sizes mostly improve (all except vsynth3-mjpeg-444).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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>
This allows catching whether the functions write outside of
the designated rectangle, and if run with "checkasm -v", it also
prints out on which side of the rectangle the overwrite was.
Signed-off-by: Martin Storsjö <martin@martin.st>
this is a good compromise between speed and compression
-rw-r----- 1 michael michael 180987 Feb 6 14:29 lena-def.png
-rw-r----- 1 michael michael 128430 Feb 6 14:36 lena-pavg.png
-rw-r----- 1 michael michael 126269 Feb 6 14:36 lena-pmixed.png
-rw-r----- 1 michael michael 180987 Feb 6 14:35 lena-pnone.png
-rw-r----- 1 michael michael 127758 Feb 6 14:35 lena-ppaeth.png
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
This backports similar functionality from dav1d, from commits
35d1d011fda4a92bcaf42d30ed137583b27d7f6d and
d130da9c315d5a1d3968d278bbee2238ad9051e7.
This allows detecting writes out of bounds, on all 4 sides of
the intended destination rectangle.
The bounds checking also can optionally allow small overwrites
(up to a specified alignment), while still checking for larger
overwrites past the intended allowed region.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes it easier to implement custom error printouts in tests.
This is a port of dav1d's commit
13a7d78655f8747c2cd01e8a48d44dcc7f60a8e5 into ffmpeg's checkasm.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was changed 8 years ago with the introduction of the linux-perf path,
with seemingly no justification at the time. Likely a developer oversight
from testing.
This bug not only made --runs completely ineffective, but also meant that we
didn't actually correctly filter out outliers.
Fixes: e0d56f097f
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>
Many of the fields of MpegEncContext (which is also used by decoders)
are actually only used by encoders. Therefore this commit adds
a new encoder-only structure and moves all of the encoder-only
fields to it except for those which require more explicit
synchronisation between the main slice context and the other
slice contexts. This synchronisation is currently mainly provided
by ff_update_thread_context() which simply copies most of
the main slice context over the other slice contexts. Fields
which are moved to the new MPVEncContext no longer participate
in this (which is desired, because it is horrible and for the
fields b) below wasteful) which means that some fields can only
be moved when explicit synchronisation code is added in later commits.
More explicitly, this commit moves the following fields:
a) Fields not copied by ff_update_duplicate_context():
dct_error_sum and dct_count; the former does not need synchronisation,
the latter is synchronised in merge_context_after_encode().
b) Fields which do not change after initialisation (these fields
could also be put into MPVMainEncContext at the cost of
an indirection to access them): lambda_table, adaptive_quant,
{luma,chroma}_elim_threshold, new_pic, fdsp, mpvencdsp, pdsp,
{p,b_forw,b_back,b_bidir_forw,b_bidir_back,b_direct,b_field}_mv_table,
[pb]_field_select_table, mb_{type,var,mean}, mc_mb_var, {min,max}_qcoeff,
{inter,intra}_quant_bias, ac_esc_length, the *_vlc_length fields,
the q_{intra,inter,chroma_intra}_matrix{,16}, dct_offset, mb_info,
mjpeg_ctx, rtp_mode, rtp_payload_size, encode_mb, all function
pointers, mpv_flags, quantizer_noise_shaping,
frame_reconstruction_bitfield, error_rate and intra_penalty.
c) Fields which are already (re)set explicitly: The PutBitContexts
pb, tex_pb, pb2; dquant, skipdct, encoding_error, the statistics
fields {mv,i_tex,p_tex,misc,last}_bits and i_count; last_mv_dir,
esc_pos (reset when writing the header).
d) Fields which are only used by encoders not supporting slice
threading for which synchronisation doesn't matter: esc3_level_length
and the remaining mb_info fields.
e) coded_score: This field is only really used when FF_MPV_FLAG_CBP_RD
is set (which implies trellis) and even then it is only used for
non-intra blocks. For these blocks dct_quantize_trellis_c() either
sets coded_score[n] or returns a last_non_zero value of -1
in which case coded_score will be reset in encode_mb_internal().
Therefore no old values are ever used.
The MotionEstContext has not been moved yet.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It allows the callee to clobber the MMX state,
yet since 1e3dc705df this is no longer
done. So use the stricter declare_func instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit adds a 32-bit *integer* planar RGBA format.
Vulkan FFv1 decoding is best performed on separate planes, rather than
packed RGBA (i.e. RGBA128), hence this is useful as an intermediate format.
James Almer