[FFmpeg-devel] GSOC update on the CDXL demuxer

[Reimar Döffinger]

On Tue, Apr 14, 2009 at 08:42:53PM +0200, Michael Niedermayer wrote:
> On Tue, Apr 14, 2009 at 08:19:21PM +0200, Reimar D?ffinger wrote:
> > On Tue, Apr 14, 2009 at 02:09:36PM -0400, Ronald S. Bultje wrote:
> > > On Tue, Apr 14, 2009 at 2:02 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > > the format has chunk size and previous chunk size, it has width&height&sample
> > > > rate per chunk, assuming these dont change you have a shitload of things you
> > > > can check
> > > 
> > > It doesn't have sample rate. Palette size can change since it doesn't
> > > have to be there.
> > 
> > Hm, I just noticed the current demuxer doesn't handle that...
> > It might complicate things a bit for the video support.
> > Does anyone know if it's allowed to mix different encoding methods in a
> > CDXL file?
> > 
> > > All I can think of is matching w/h or prev size to
> > > current size, but that requires two packets, which is much more than
> > > the max probe size that we use right now. Chunks are >10kb. Probe size
> > > is 4kb, IIRC.
> > 
> > Probe size is whatever the application provides. 32kB for MPlayer,
> > FFmpeg I think increases probe size if it does not get a match but I do
> > not know the limit.
> 
> the probe buffer size increasing is done in av_open_input_file()
> if mplayer limits that somehow, this is a bug in mplayer ...

MPlayer uses av_probe_input_format, also 1 MB is a lot if the input is
e.g. a stream via some slow network connection. That's no problem for
FFmpeg, after all if it tries to read that much it wouldn't work at all
otherwise, but for MPlayer there might be a native demuxer that handles
the format, and prereading 1MB for nothing is not reasonable.