[FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format

[Paul B Mahol]

Dana 30. 9. 2015. 17:19 osoba "Hendrik Leppkes" <h.leppkes at gmail.com>
napisala je:
>
> On Wed, Sep 30, 2015 at 4:35 PM, Paul B Mahol <onemda at gmail.com> wrote:
> > On 9/30/15, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> >> On Wed, Sep 30, 2015 at 2:51 PM, Michael Niedermayer <michaelni at gmx.at>
> >> wrote:
> >>> On Wed, Sep 30, 2015 at 02:39:21PM +0200, Hendrik Leppkes wrote:
> >>>> On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer <
michaelni at gmx.at>
> >>>> wrote:
> >>>> > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote:
> >>>> >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer
> >>>> >> <michaelni at gmx.at> wrote:
> >>>> >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote:
> >>>> >> >> The chroma format can be still unset in postinit when a badly
cut
> >>>> >> >> stream
> >>>> >> >> starts with a slice instead of a sequence header. This is a
common
> >>>> >> >> occurance when feeding avcodec from a Live TV stream.
> >>>> >> >> ---
> >>>> >> >>  libavcodec/mpeg12dec.c | 1 -
> >>>> >> >>  1 file changed, 1 deletion(-)
> >>>> >> >>
> >>>> >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> >>>> >> >> index 5d916d1..b3c2c45 100644
> >>>> >> >> --- a/libavcodec/mpeg12dec.c
> >>>> >> >> +++ b/libavcodec/mpeg12dec.c
> >>>> >> >> @@ -1389,7 +1389,6 @@ static int
> >>>> >> >> mpeg_decode_postinit(AVCodecContext *avctx)
> >>>> >> >>              case 1: avctx->chroma_sample_location =
> >>>> >> >> AVCHROMA_LOC_LEFT; break;
> >>>> >> >>              case 2:
> >>>> >> >>              case 3: avctx->chroma_sample_location =
> >>>> >> >> AVCHROMA_LOC_TOPLEFT; break;
> >>>> >> >> -            default: av_assert0(0);
> >>>> >> >>              }
> >>>> >> >>          } // MPEG-2
> >>>> >> >
> >>>> >> > This assert double checks that the context init which uses
> >>>> >> > width/height/chroma format is done after the chroma format and
w/h
> >>>> >> > has
> >>>> >> > been read from the headers
> >>>> >> > if this is reached without the headers being read then the code
is
> >>>> >> > buggy and removing the assert will not fix that bug
> >>>> >> >
> >>>> >> > also if there is no sequence header how is width/height set ?
> >>>> >> > theres a check for width/height before mpeg_decode_postinit is
> >>>> >> > called
> >>>> >> >
> >>>> >>
> >>>> >> The dimensions are set by the caller in the avctx before opening
the
> >>>> >> codec, which apparently inits the mpeg context as well.
> >>>> >>
> >>>> >> Feel free to fix it differently, error out or something, but I can
> >>>> >> trip an assert with input data, which should never happen.
> >>>> >
> >>>> > how can this be reproduced ?
> >>>> >
> >>>>
> >>>> I can only trigger it with API usage, not through the CLI tools, so I
> >>>> cannot produce a test case.
> >>>
> >>> is this with a unmodified up to date ffmpeg ?
> >>> i fixed this assert failing a while ago
> >>> (b54e03c9dc2a05324c08b503bfe7535c49c0f281)
> >>>
> >>>
> >>
> >> Its up to date, but slightly modified - but nothing pertinent to the
> >> mpeg2 decoder as far as I know.
> >> I'll just add this to the list of modifications then. I can clearly
> >> trigger this assert in a release build (which is hilarious on its own,
> >> asserts are a debugging tool), which crashes the application, so thats
> >> no good.
> >
> > WTF, can you just give sample/link something?
>
> Like I said earlier in the thread, it happens with API usage in a Live
> TV scenario. I cannot produce a sample of that.

Not even backtrace?

>
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel