[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:
for(;;){
if(have_cached_audio)
return ff_read_cache();
if(parse_packet())
return 0;
}
parse_packet(){
if(!partial_packet)
sync_to_next_packet_header();
if(video)
assemble_video_frame();
else if(braindead_audio)
assemble_audio_frame();
else
read this packet and return it
}
assemble_audio_frame(){
for(i = 0; i < ast->subpackets_in_packet; i++)
get_buffer(ast->pkt->data + subpacket_size * (i * A + ast->packet_num * B), subpacket_size);
ast->packet_num++;
}
> Ronald
More information about the ffmpeg-devel
mailing list