Hi,
On Fri, Nov 16, 2012 at 8:43 AM, Janne Grunau <janne-li...@jannau.net>wrote:
> Fixes a crash in fuzzed file nasa-8s2.ts_s20033 caused by a too large
> has_b_frames value. low_delay keeps getting re-enabled from the the
> presumely broken SPS.
> ---
> libavcodec/h264.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264.c b/libavcodec/h264.c
> index c30c478..7935fe6 100644
> --- a/libavcodec/h264.c
> +++ b/libavcodec/h264.c
> @@ -2346,8 +2346,10 @@ static int h264_set_parameter_from_sps(H264Context
> *h)
>
> if (s->flags & CODEC_FLAG_LOW_DELAY ||
> (h->sps.bitstream_restriction_flag &&
> - !h->sps.num_reorder_frames))
> + !h->sps.num_reorder_frames)) {
> s->low_delay = 1;
> + s->avctx->has_b_frames = 0;
> + }
>
So I'm going to have to wonder what happens to the delayed frames already
cached in h->delayed_pics[]? Are they still output? What happens if we
concatenate a delayed h264 file by a file that has this kind of sps header?
Ronald
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
