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

Kostya kostya.shishkov
Mon Mar 2 16:07:53 CET 2009

On Mon, Mar 02, 2009 at 08:10:01AM -0500, Ronald S. Bultje wrote:
> Hi,
> On Mon, Mar 2, 2009 at 8:59 AM, Kostya <kostya.shishkov at gmail.com> wrote:
> > Personally I don't like anything by Real, especially their container
> > and RV3/4 codecs. I suspect that something more generic should be done
> > to handle both video and audio mess (i.e. subpackets in single packet
> > and single frame spanning several subpackets or both).
> you mean in our implementation? I'd be interested in how you'd
> generalize that, I looked at it and it seems completely different.
> Can't wait to see what that'll look like.

Me too.

1) For audio we need stricter and simpler assembly rules - it's hard to make
something out from rm_read_audio_stream_info() and I'm pretty sure that audio
subpacket reading can be simplified on per-codec basis, for now all those
ast->audio_framesize, st->codec->block_align, ast->sub_packet_size and
ast->sub_packet_h can only give headache, especially in ff_rm_parse_packet().
I'd like to see some simpler formula for them all - oh, and I think returning
first subpacket from reassembled audio frame is not needed too (cache will
handle it).

2) Packet reading should be more sane - with index support, synchronizing to
the next packet header and actual packet parsing could be merged into one and
put into loop like:
   return ff_read_cache();
   return 0;

 else if(braindead_audio)
  read this packet and return it

 for(i = 0; i < ast->subpackets_in_packet; i++)
  get_buffer(ast->pkt->data + subpacket_size * (i * A + ast->packet_num * B), subpacket_size);

> Ronald

More information about the ffmpeg-devel mailing list