[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