FF_COMMON_FRAME holds the contents of the AVFrame structure and is also copied
to struct Picture. Replace by an embedded AVFrame structure in struct Picture.
By observation it did not seem to handle prev_frame_num > frame_num.
This does not affect any files I have.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
One of the causes of this bug is that the h264 parser defaults low_delay
to 1, but the h264 codec defaults low_delay to 0. Really Ugly.
After many hours of looking at this, I'm still not sure how has_b_frames
is *intended* to behave, but to me the implementation appears way more
complicated than it ought to be.
My patch relies on the encoder to set an optional field in the SPS. This
works for libx264 streams, but I'm not sure that all h264 encoders will
set it.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This reverts commit a50f0bea25.
This has been implemented differently in qatar and its better they
maintain it for me instead of me having to spend an average 5sec more
per merge
Conflicts:
libavcodec/h264.c
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
By observation it did not seem to handle prev_frame_num > frame_num.
This does not affect any files I have.
(cherry picked from commit 43c0092a80f8212cbb783260bafa157f7b85126e)
* ffmpeg-mt/master:
Update todo.
h264: add an assert that copied pictures are valid picture pointers
valgrind-check: run with 1 and 3 threads
h264: When decoding a packet with multiple PPS/SPS, don't start the next thread until all of them have been read
Allow some pictures to be released earlier after 51ead6d2c40c5defdd211f435aec49b19f5f6a18
h264: fix slice threading MC reading uninitialized frame edges.
Please see ffmpeg-mt for a list of authors of these changes.
Conflicts:
libavcodec/h264.c
mt-work/valgrind-check.sh
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When backing up the top-left border, check that the top-left
(rather than left) MB indeed does belong to our slice. If it
doesn't, backing up has no positive effect but may accidentally
interfere with other threads writing in the same space.
Fixes occasional one-off effects when enabling slice-MT.
This patch lets e.g. dsputil_init chose dsp functions with respect to
the bit depth to decode. The naming scheme of bit depth dependent
functions is <base name>_<bit depth>[_<prefix>] (i.e. the old
clear_blocks_c is now named clear_blocks_8_c).
Note: Some of the functions for high bit depth is not dependent on the
bit depth, but only on the pixel size. This leaves some room for
optimizing binary size.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)).
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
In high bit depth the pixels will not be stored in uint8_t like in the
normal case, but in uint16_t. The pixel size is thus 1 in normal bit
depth and 2 in high bit depth.
Preparatory patch for high bit depth h264 decoding support.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
One of the causes of this bug is that the h264 parser defaults low_delay
to 1, but the h264 codec defaults low_delay to 0. Really Ugly.
After many hours of looking at this, I'm still not sure how has_b_frames
is *intended* to behave, but to me the implementation appears way more
complicated than it ought to be.
My patch relies on the encoder to set an optional field in the SPS. This
works for libx264 streams, but I'm not sure that all h264 encoders will
set it.
Michael Niedermayer
Diego Biurrun
Jason Garrett-Glaser
Mans Rullgard
Ronald S. Bultje
Alex Converse
Alexander Strange
Mike Scheutzow
Felipe Contreras
Oskar Arvidsson
Stefano Sabatini
Anton Khirnov