[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