[FFmpeg-devel] [PATCH] Make RM demuxer behave better with -an option

Kostya kostya.shishkov
Mon Feb 2 21:31:09 CET 2009


On Mon, Feb 02, 2009 at 07:46:15PM +0100, Michael Niedermayer wrote:
> On Mon, Feb 02, 2009 at 09:19:06PM +0200, Kostya wrote:
> > The story so far:
> >  FFmpeg now has RV30, RV40 (my fault) and AAC (not my fault) support. When
> > trying to decode RV40+AAC RM file with -an option video decoder produces
> > a lot of garbage and may crash. As I've investigated, that happens because
> > with -an option specified RM demuxer begins to feed audio packets to video
> > decoder.
> 
> summary: rm demuxer doenst want to waste food

Well, RM container completely isolates packets and frames, so frame can just occupy
a part of packet or several packets (in case of video) so its handling is not
that sane. That should please Mans a bit - the fact he's not RM maintainer.
 
> > 
> >  With this patch demuxer resets the number of pending audio packets (so they
> > won't be demuxed) and skips them (syncing to the next packet header tends to
> > produce false positive matches somewhere inside packet data).
> 
> > Index: libavformat/rmdec.c
> > ===================================================================
> > --- libavformat/rmdec.c	(revision 16915)
> > +++ libavformat/rmdec.c	(working copy)
> > @@ -650,6 +650,12 @@
> >      if(  (st->discard >= AVDISCARD_NONKEY && !(*flags&2))
> >         || st->discard >= AVDISCARD_ALL){
> >          av_free_packet(pkt);
> > +        if(st->codec->codec_id == CODEC_ID_AAC && st->discard >= AVDISCARD_ALL){
> 
> why the AAC check?

Haven't seen that occuring with anything else. But I suspect Ronald is
right and it should be treated elsewhere (well, that's not the first time).
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB




More information about the ffmpeg-devel mailing list