[FFmpeg-devel] ffprobe: Do not decode zero-sized packets in ffprobe -show_frame

[Petter Ericson]

On Wed, Feb 15, 2012 at 05:39:15PM +0100, Michael Niedermayer wrote:
> On Tue, Feb 14, 2012 at 05:26:13PM +0100, Petter Ericson wrote:
> > Greetings
> > 
> > Ticket #997 details a segfault in ffprobe that was exposed by the file
> > http://titan.codemill.se/~peteri/120210144737.ts
> > 
> > This patch fixes the segfault. However, the desyncing issue that I
> > mentioned in the ticket still remains (I was sloppy when looking at the
> > output - It is still present in git master). If anyone could advice on what
> > it is that is causing transcoding to result in desynced output, I would be
> > most grateful. 
> > 
> > The patched ffmpeg passes make fate.
> > 
> > Best regards
> > 
> > Petter Ericson
> > 
> 
> >  ffprobe.c |    2 ++
> >  1 file changed, 2 insertions(+)
> > d4cd04827b5c74b8d5d67f85d3f49b9646ae392d  patch
> > commit e40952af2f5b6eccf24b34926bf09747117affdc
> > Author: Petter Ericson <petter.ericson at codemill.se>
> > Date:   Tue Feb 14 16:59:56 2012 +0100
> > 
> >     ffprobe: Do not avcodec_decode_video2 video packets with size == 0
> > 
> > diff --git a/ffprobe.c b/ffprobe.c
> > index 79f7494..e23ef98 100644
> > --- a/ffprobe.c
> > +++ b/ffprobe.c
> > @@ -1349,6 +1349,8 @@ static av_always_inline int get_decoded_frame(AVFormatContext *fmt_ctx,
> >      *got_frame = 0;
> >      switch (dec_ctx->codec_type) {
> >      case AVMEDIA_TYPE_VIDEO:
> > +        if(pkt->size == 0)
> > +            return ret;
> >          ret = avcodec_decode_video2(dec_ctx, frame, got_frame, pkt);
> 
> This also will break flushing the last frames
> the check could be moved to the non flushing codepath
> 
> [...]
> 

Ah, so it will. Amended patch attached. The reason why the check can't
easily be done in the non-flushing loop is because zero-sized audio packets
have to be passed through. One could go with just checking the codec_type,
but that would lead to quite the ugly if-condition. Easier to just have a
flushing switch to get_decode_frame imo.

Still, I have not managed to hit this particular segfault with files from
any other source, so it is likely that something weird is going on, anyway, 
especially considering the timing problems.

/P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: text/x-diff
Size: 2140 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120216/e7efc67e/attachment.bin>