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>
We violated the spec, which, despite the actual command buffer pool
*not* being involved in any functions which require external synchronization
of the pool, *require* external synchronization even if only the
command buffers are used.
This also has the effect of *significantly* speeding up execution
in case command buffers are contended.
A sample with a particular partitioning structure that could not be read
correctly before 26c5d8cf5d6dcd520e781754d986e9907d74270e
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
We currently populate the color encoding bundle and then check to see
if there's an ICC profile to attach, and set the color encoding bundle
in either case. The ICC profile overrides the color encoding bundle, so
we should not calculate enum-based color encoding if we have an ICC
profile present. Fixes several unnecessary warnings from being emitted.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
see: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance
but in short, first our API since 16years says we dont have multiple values per key
(which it supports since 9 years only)
and it causes some problems for ffprobe apparently.
I do believe the original patch is the correct direction but it requires
more changes. So revert this until other things are in place and until
we have a consensus.
This reverts commit 80b77e8e8d0630710ad6069133f397459015f139.
fix ticket #11531
the rtsp aac did not marked keyframe which cannot easy copy to output.
because f265f9c9d04863180503707bfad285f48e6bf080 commit change the AAC props to match xHE-AAC.
in some formats like MOV, need_parsing is set, so AAC can be still parsed be keyframe
but rtsp did not, so this patch add it
Signed-off-by: Jack Lau <jacklau1222@qq.com>
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current behavior when using restart_with_keyframe is that it will
recover if it also encounters any audio packet, as they are flagged as a
keyframe.
The expectation is that packets are dropped until the next _video_
keyframe.
To fix that, check if exists a video stream, if it exists check the
packet stream codec type, only letting it recover when it is a video
one. If there is no video stream, resume to the original behavior, not
checking the codec type.
Fixes ticket: #11467
Signed-off-by: Arthur Grillo <arthurgrillo@riseup.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
GNU apparently deprecated their egrep alias, replace it with 'grep -E'
to avoid getting flooded with deprecation warnings.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Just like normal close functions.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avtext_context_close() calls av_opt_free() on an AVTextFormatContext
as well as av_bprint_finalize() on the containing section_pbuf
AvBPrints, yet it can happen that the AVBPrints have not been
initialized (only zeroed) and that av_opt_set_defaults() has
not been called. This works, but it is not really documented to do so.
So ensure that the options and the AVBPrints have been initialized
when avtext_context_close() is called.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Would happen if an AVTextFormatContext's private context
could not be allocated.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avtextwriter_create_file() creates an AVIOContext whose pointer
resides in its private context. If it were not always closed on
uninit, the AVIOContext would leak, so it makes no sense
to have this parameter.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This AVTextWriter does not have any options.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use snprintf() directly instead of initializing an AVBPrint
just for this.
Reviewed-by: softworkz . <softworkz-at-hotmail.com@ffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All users (namely HEVC) that use ff_progress_frame_alloc()
should just use ff_thread_get_buffer(). Using
ff_progress_frame_get_buffer() is not a must; it is merely
a convenience wrapper.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit adds support for compiler hints.
While on AMD these are not used/needed, Nvidia benefits from them, and gives
a sizeable 10% speedup on 4k.
This commit also makes it possible for the encoder to choose a different
quantization table on a per-slice basis, as well as adding this capability
to the decoder.
Also, this commit fully fixes decoding of context=1 encoded files.
This reduces the intermediate VRAM used for RGB decoding by a
factor of 100x for 6k video.
This also speeds the decoder up by 16% for 4k RGB24 and 31% for 6k video.
This is equivalent to what the software decoder does, but with less pointers.
