* commit '17a63ff0cd187b9e50e4a47862750295976853b1':
h264: update flag name in ff_h264_decode_ref_pic_list_reordering()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '98cc9efc5f6b4dc847ed3b9b60b1c3bcd14e6791':
h264: prevent two matching fields from being both a short/long ref combination
See: 92002db3eb
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4d388c0cd05dd4de545e8ea333ab4de7d67ad12d':
h264_refs: make sure not to write over the bounds of the default ref list
Conflicts:
libavcodec/h264_refs.c
This condition should be impossible and was checked for by asserts.
the asserts are moved up in this merge to gurantee that no out of array
access can happen even if the state is "impossible".
Also if such impossible states could somehow be created, that should
be dealt with and not silently ignored.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a553c6a347d3d28d7ee44c3df3d5c4ee780dba23':
lavc: use buf[0] instead of data[0] in checks whether a frame is allocated
Conflicts:
libavcodec/h264_refs.c
libavcodec/mpegvideo.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '28096e0a806e57376541e6222d315619906e3c55':
h264: wait for initial complete frame before outputing frames
Conflicts:
doc/APIchanges
libavcodec/h264.c
libavcodec/mpegvideo.h
libavutil/frame.h
libavutil/version.h
See: a64b028aeb (as well as various later commits)
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Do not consider it an error if we have no frames and should discard one.
This condition can easily happen when decoding is started from an I frame
Fixes Ticket2811
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When decoding succeeded the array is copied into the permanent one.
This prevents inconsistencies
Fixes assertion failure
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1b6f84a98665a15130e969fd6b460a05d50090c1':
h264_refs: Do not print check_opcodes() return value
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The return value provides no useful information and removing the printing
avoids the following warning:
libavcodec/h264_refs.c:788:15: warning: 'i' may be used uninitialized in this function [-Wuninitialized]
* commit '7fa00653a550c0d24b3951c0f9fed6350ecf5ce4':
h264: add a parameter to the FIELD_PICTURE macro.
h264: add a parameter to the FRAME_MBAFF macro.
Conflicts:
libavcodec/h264.c
libavcodec/h264_loopfilter.c
libavcodec/h264_refs.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Most of the changes are just trivial are just trivial replacements of
fields from MpegEncContext with equivalent fields in H264Context.
Everything in h264* other than h264.c are those trivial changes.
The nontrivial parts are:
1) extracting a simplified version of the frame management code from
mpegvideo.c. We don't need last/next_picture anymore, since h264 uses
its own more complex system already and those were set only to appease
the mpegvideo parts.
2) some tables that need to be allocated/freed in appropriate places.
3) hwaccels -- mostly trivial replacements.
for dxva, the draw_horiz_band() call is moved from
ff_dxva2_common_end_frame() to per-codec end_frame() callbacks,
because it's now different for h264 and MpegEncContext-based
decoders.
4) svq3 -- it does not use h264 complex reference system, so I just
added some very simplistic frame management instead and dropped the
use of ff_h264_frame_start(). Because of this I also had to move some
initialization code to svq3.
Additional fixes for chroma format and bit depth changes by
Janne Grunau <janne-libav@jannau.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit 'd8c772de53d29afb1bada88afa859fce8489c668':
nutdec: Always return a value from nut_read_timestamp()
configure: Make warnings from -Wreturn-type fatal errors
x86: ABS2: port to cpuflags
vdpau: Remove av_unused attribute from function declaration
h264: fix ff_generate_sliding_window_mmcos() prototype.
Conflicts:
configure
libavformat/nutdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Clobbering these tables will temporarily clobber the template used
as a basis for other threads to start decoding from. If the other
decoding thread updates from the template right at that moment,
subsequent threads will get invalid (or, usually, none at all) mmco
tables. This leads to invalid reference lists and subsequent decode
failures.
Therefore, instead, decode the mmco tables only for the first slice in
a field or frame. For other slices, decode the bits and ensure they
are identical to the mmco tables in the first slice, but don't ever
clobber the context state. This prevents other threads from using a
clobbered/invalid template as starting point for decoding, and thus
fixes decoding in these cases.
This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with
frame-multithreading enabled.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Clobbering these tables will temporarily clobber the template used
as a basis for other threads to start decoding from. If the other
decoding thread updates from the template right at that moment,
subsequent threads will get invalid (or, usually, none at all) mmco
tables. This leads to invalid reference lists and subsequent decode
failures.
Therefore, instead, decode the mmco tables only for the first slice in
a field or frame. For other slices, decode the bits and ensure they
are identical to the mmco tables in the first slice, but don't ever
clobber the context state. This prevents other threads from using a
clobbered/invalid template as starting point for decoding, and thus
fixes decoding in these cases.
This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with
frame-multithreading enabled.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
