On 18/12/15 09:49, Anton Khirnov wrote:
> Before 741b494fa8cd28a7d096349bac183893c236e3f9, when the reference list
> modification description was invalid, the code would substitute the
> corresponding reference from the initial ("default") reference list.
> After that commit, it will just return an error.
>
> Since there are apparently invalid samples in the wild that used to play
> fine with the old code, it is a good idea to re-add some sort of error
> resilience here. So, when the reference list modification results in a
> missing frame, substitute a previous reference frame for it. The
> relevant sample again decodes fine with the same output as previously.
> ---
> Thanks to Martin for telling me about the problem. The sample is
> http://files.1f0.de/samples/h264refframeregression.mp4
>
> I wonder if we should add a FATE test for this. The file is invalid, but we
> probably still want it to
> remaing working.
> ---
> libavcodec/h264_refs.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index 46b51e0..877f6fe 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -325,7 +325,10 @@ int ff_h264_decode_ref_pic_list_reordering(H264Context
> *h, H264SliceContext *sl)
> for (index = 0; index < sl->ref_count[list]; index++) {
> if (!sl->ref_list[list][index].parent) {
> av_log(h->avctx, AV_LOG_ERROR, "Missing reference
> picture\n");
> - return -1;
> + if (index == 0 || h->avctx->err_recognition & AV_EF_EXPLODE)
> + return AVERROR_INVALIDDATA;
> + else
> + sl->ref_list[list][index] = sl->ref_list[list][index -
> 1];
> }
> }
> }
>
Sure.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
