[FFmpeg-devel] [RFC] per format probe buffer sizes

Michael Niedermayer michaelni
Tue Apr 15 19:52:39 CEST 2008


On Tue, Apr 15, 2008 at 08:32:57PM +0300, Kostya wrote:
> On Tue, Apr 15, 2008 at 06:58:06PM +0200, Michael Niedermayer wrote:
> > On Tue, Apr 15, 2008 at 06:06:33PM +0200, Benjamin Larsson wrote:
> > > Hello, while trying to work out how to get dts in wav detection to work 
> > > properly I found out that there was a problem with the size of the probe 
> > > buffer. Right now it starts from 2048 and increases the size until a 
> > > format is detected. And when the wav format is used with a command line 
> > > like "ffmpeg -i dts.wav test.wav" the format is detected in the first 
> > > try. And reliable dts detection in a test file I had will need more. It 
> > > found the first SYNC word after 3072 bytes. So for this to work we need 
> > > to increase this buffer, one could either do it globally or just for the 
> > > needed format. Before the actual probing that finds the wav format 
> > > (utils.c:447) there is another probe (utils:433). My suggestion is that 
> > > we add a flag and size parameter to the format struct and let this probe 
> > > call fetch this value so it can be used later in the real 
> > > probe(utils.c:447). This way we can add per format probe sizes which 
> > > might useful.
> > > 
> > > So what do you think of this idea ?
> > 
> > First i think it is wav and it should use the wav demuxer. And i would like
> > to hear some argument why this cant work that way.
> > 
> > Second you can add a
> > if(size<4567) //dts needs that at least so wav - dts differntiation is possible
> >     return 0;
> > in the wav probe function to achive what you want
> 
> My suggestion was something similar - provide flag and desired probe size so
> probe function won't even try that format unless probe buffer size is big enough.
> 
> Of course it can be done with checking of AVProbeData.buf_size inside read_probe()
> but that's a bit hacky IMO and not proof against possible future changes.

Its as future proof as your suggestion. But your suggestion adds a flag and a
int to ALL demuxers we support this are just 2 lines in 1 demuxer.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080415/6ed9e1b1/attachment.pgp>



More information about the ffmpeg-devel mailing list