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

[Michael Niedermayer]

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)


> Just replace the assert with a error return, that should cover everything.
> 
> - Hendrik
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150930/0df27ab9/attachment.sig>