[FFmpeg-devel] [RFC] stream parsing
Reimar Döffinger
Reimar.Doeffinger
Sat Sep 25 12:45:18 CEST 2010
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 ?
I don't think there's a point since it fixes at most half the issue.
For those formats where this can happen, it is also possible
that the channel count changes in the middle.
If that cases is handled correctly, this automatically becomes
a non-issue (and the container value could mean "better upmix
even if it is stereo now, because it will have 5 channels later").
More information about the ffmpeg-devel
mailing list