[FFmpeg-devel] [RFC] stream parsing
Sat Sep 25 22:18:26 CEST 2010
On Sat, Sep 25, 2010 at 09:36:57PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 25, 2010 at 11:25:54AM +0200, Benjamin Larsson wrote:
> > On 09/25/2010 01:53 AM, Michael Niedermayer wrote:
> > > On Wed, Sep 22, 2010 at 02:02:15AM +0200, Benjamin Larsson wrote:
> > >> Hi, I've found a few files where the channel layout in the container vs
> > >> the stream miss matches (1 avi with dts and 1 mkv, issue 2137). That got
> > >> me thinking about the channel layout mask. In some containers it is
> > >> possible to just set a channel count, which leads to ffmpeg just
> > >> guessing the layout. Instead I suggest that when the channel count is >2
> > >> do a AVSTREAM_PARSE_HEADERS by default instead of trusting the
> > >> container. So what do you think would that be acceptable? Otherwise I
> > >> have to add patches like the one in issue 2137 to every demuxer that we
> > >> find broken files for.
> > >
> > > sounds wrong
> > > av_find_stream_info() could easily be made to detect the lack of precisse
> > > channel layout and in this case force at least one frame to be decoded or
> > > frames to be decoded until it is set. this may or may not need to be
> > > limited to specific codecs (we dont want too many frames decoded due to
> > > delay especially for codecs that never could set it so we might need a
> > > flag in AVCodec then)
> > > but either way something around av_find_stream_info() seems better than playing
> > > with parser flags
> > >
> > Yeah the issue is that some codecs don't know the channel count thus you
> > need the info from the container and sometimes the codec has better
> > knowledge which could possibly be different from the container (and is
> > for the 2 files in issue 2137).
> > So
> > /**
> > * Codec know the channel configuration better then the container
> > */
> > #define CODEC_CAP_CHANNEL_CONF 0x0100
> > And something in av_find_stream_info that checks that flag ?
> looks good to me once reimar agrees too
I don't disagree, I think it is a good idea.
I just think we should check that we do not move it in a direction that
will make it harder to properly support mid-stream changes though.
Also we should consider what happens in av_find_stream_info if e.g.
the first frames uses stereo and the next one 5.1, IMO we should not
end up detecting it as 5.1 just because we for some reason end up
decoding a few frames more (though the same issue already exists
for video, so you could consider it unrelated I guess...).
More information about the ffmpeg-devel