The generic code copies the main context's private data to all the
others. However that is quite dangerous, as it might end up copying some
pointers that are or will become invalid.
Since everything we actually need will be copied later in
update_thread_context(), it's safest to zero the private data in
init_thread_copy(), so it works the same way as init for the main
context.
ER with slice threads is buggy and since the merge of the libav cleanup broken
as the ER context which is supposed to be per frame has been placed in
the slice context, so there are multiple per frame which does not work as is.
Theres no bug report about ER with frame threads. If someone knows of a
case where it crashes / fails without slice threads please mail me and
open a ticket on trac.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a12d3188cbec15e22070e139fa5cc541da07e2c3':
h264: use a smaller struct for the ref lists
Conflicts:
libavcodec/h264_direct.c
libavcodec/h264_mb.c
libavcodec/h264_picture.c
libavcodec/h264_refs.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2b4c38d3c647f409080606ef02b3363ada00be2c':
h264: drop some mpegvideo remnants from draw_horiz_band()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5bf3c0fa49afd5bbf43aa841ff78007d72c80736':
h264: drop the now unused per-slice H264Contexts
Conflicts:
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '51d8725a6e4c7f989d6f0f38b59cb54a2d72846c':
h264: use the main H264Context as the parent for all slice contexts
Conflicts:
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '582683b6ac798ed2a004a4e2121b7bd47892bbfd':
h264: move remaining ER stuff into the per-slice context
Conflicts:
libavcodec/h264.h
libavcodec/h264_picture.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5bc69f38c1af71fbcbfb4b5efa77d0aeb5424c04':
error_resilience: do not require mbintra/skip tables
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '36d04801ba9d8622c2d759c172aea18561bac74d':
h264: move the scratch buffers into the per-slice context
Conflicts:
libavcodec/h264.h
libavcodec/h264_slice.c
libavcodec/svq3.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5c4b98de4d101ea715ef86847306a510afd0db0c':
h264.c: constify all uses of H264Context in slice and lower-level functions
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f42485dbce614b3f63182845da43db690b427b7c':
h264: use a separate GetBitContext for slice data
Conflicts:
libavcodec/h264.c
libavcodec/h264_cavlc.c
libavcodec/h264_parser.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2ea00e35e4e0b58f7a306dd55d8f72a21c32c946':
h264: do not abuse the context as a temporary storage in get_last_needed_nal()
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '404a416d4b1fcbf9db5569481d8181f296c01ea9':
h264: remove some remnants of data partitioning
Conflicts:
libavcodec/h264.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '56febc993b928ccc039a32158ca60b234c311875':
h264: move the slice type variables into the per-slice context
Conflicts:
libavcodec/h264.c
libavcodec/h264_cabac.c
libavcodec/h264_cavlc.c
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Also change the method for allocating them. Instead of two possible
alloc calls from different places, just ensure they are allocated at the
start of each slice. This should be simpler and less bug-prone than the
previous method.
Fixes out of array read
Fixes: asan_heap-oob_2ff30d2_3479_cov_3803648058_src13_hrc7_525_420_2.264
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '61928b68dc28e080b8c8191afe5541123c682bbd':
h264: Do not share rbsp_buffer across threads
Conflicts:
libavcodec/h264.c
See: ecbf838c7d
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '167e004e1aca7765686ed95d7cd8ea5064d4f6f6':
h264: drop any pretense of support for data partitioning
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ecab21ac47d0d4ca604bebf494017ae5090853a8':
h264: do not reset the ref lists in flush_change()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '9404a47a2d1df418946a338938eb6cdb3afed474':
h264: move parser-only variables to their own context
Conflicts:
libavcodec/h264_parser.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cf1e0786ed64e69614760bfb4ecd7adbde8e6094':
error_resilience: move the MECmpContext initialization into ER code
Conflicts:
libavcodec/error_resilience.c
libavcodec/h264.c
libavcodec/h264.h
libavcodec/h264_slice.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It does not work correctly and apparently never did. There is no
indication that this (mis)feature is ever used in the wild or even that
any software other than the reference supports it.
Since the code that attempts to support it adds some nontrivial
complexity and has resulted in several bugs in the past, it is better to
just drop it.
Currently, it needs to be initialized by the ER caller (which is
currently either a mpegvideo decoder or h264dec). However, since none of
those decoders use MECmpContext for anything except ER, it makes more
sense to handle it purely inside ER.
This like the previous attempt does not fully correctly decode this
type of non standard H.264, but it now works fully automatic
requiring no manual filters or flags to be used
See Ticket2254
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This and the next commit improve error concealment for
green-block-artifacts-from-canon-100-hs.MOV
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes use of freed memory
Fixes: case5_av_frame_copy_props.mp4
Found-by: Michal Zalewski <lcamtuf@coredump.cx>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b1b1a7370e141c912e3d0bbaa668dcee05c3ad67':
display: fix order of operands
Conflicts:
libavcodec/h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
They are not just inverses of each other.
This should restore behavior to before the introduction of framerate
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7ea1b3472a61de4aa4d41b571e99418e4997ad41':
lavc: deprecate the use of AVCodecContext.time_base for decoding
Conflicts:
libavcodec/avcodec.h
libavcodec/h264.c
libavcodec/mpegvideo_parser.c
libavcodec/utils.c
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When decoding, this field holds the inverse of the framerate that can be
written in the headers for some codecs. Using a field called 'time_base'
for this is very misleading, as there are no timestamps associated with
it. Furthermore, this field is used for a very different purpose during
encoding.
Add a new field, called 'framerate', to replace the use of time_base for
decoding.
