* commit '167e004e1aca7765686ed95d7cd8ea5064d4f6f6':
h264: drop any pretense of support for data partitioning
Conflicts:
libavcodec/h264.c
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: asan_heap-uaf_3660f67_757_cov_1257014655_Hi422FR1_SONY_A.jsv
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6fd91fa11909f27902498648680dbb3d13f1f175':
h264: increase MAX_SLICES to 32
The available sample decodes correctly before, but the reporter of the bug
claims that this change reduces artifacts. This is thus merged
If someone has samples that decode differently depending in the MAX_SLICES
value, please open a ticket on trac.
Also this change should be reverted if it turns out that the artifacts
that where seen had a different cause
Merged-by: Michael Niedermayer <michaelni@gmx.at>
this also uses avpriv_find_start_code(), though no speed change is expected as
the area searched is generally small
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This limits ABI issues in case libavcodec is linked to a libavutil with larger AVFrame
Which can happen if they are shiped in seperate binary packages and libavutil is upgraded
A cleaner alternative would be to replace them by pointers but this would likely cause
a small speedloss
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '136034d86b5cb1819a2c3e6ecdfeb05dcba7140d':
h264: Remove MotionEstContext and move the relevant fields to H264Context
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '304e916a92bc17385a485bec2f957e192257ddb6':
h264_sei: name buffering period type consistently
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3a0576702825423abecb32627c530dbc4c0f73bc':
h264: store current_sps_id inside the current sps
Conflicts:
libavcodec/h264.c
libavcodec/h264_ps.c
The current_sps_id is not removed as it used in security related code.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
