[FFmpeg-devel] [PATCH] probe max read size

[Michael Niedermayer]

On Mon, Jun 01, 2009 at 03:37:55PM -0700, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > On Mon, Jun 01, 2009 at 12:36:54PM -0700, Baptiste Coudurier wrote:
> >> Michael Niedermayer wrote:
> >>> On Sun, May 31, 2009 at 02:53:34AM -0700, Baptiste Coudurier wrote:
> >>>> Hi,
> >>>>
> >>>> After some tests, it seems more reasonable to stop probing after some
> >>>> max size to avoid consuming to much memory.
> >>> Maybe we then should replace probe_packets by a size based thing,
> >>> having 2 is uglier than one if one is sufficient
> >> Sure. Problem is per stream counting is not reasonable since streams
> >> might not have many packets present this will cause much buffering.
> > 
> > but without per stream counting streams starting once the threashold is
> > reached should fail to be probed or some streams would only be returned
> > at eof ...
> 
> I think that, in memory constrained systems, user will want to limit:
> - raw_packet_buffer size
> - probing data size (which is btw still a problem, pd->buf must be
> released at some point if codec is not probed).
> 
> To achieve this, I think both sizes must be globally bounded.
> 
> Maybe by s->probesize or another field, but ideally it must be user
> configurable.

Either way the value that counts the amount remaining must be in a context
not on the stack of av_read_*

also if it is in the context it can be set by the user


> 
> > If we want a packet limit of PL and a byte limit of BL then
> > 
> > init(){
> >     counter= BL
> > }
> > ...
> > counter -= packet.size + BL/PL;
> > if(counter > 0)
> > 
> > could be used, per stream, iam not sure if this is a good idea or if
> > we rather should keep 2 counter
> > 
> > Geometrically, this limit check has an area of a triangle that is within the
> > limit while the normal 2 variable check uses a rectangle, i feel that a triangle
> > is supperior ;)
> 
> Sure, is packet limit still wanted if we have global byte limit though ?

assuming you have a 1mb size limit and a stream containing gsm
it wont ever be probebed successfully because we have no gsm probe
it has 13kbit/sec which means that no packet will be returned to the
user app for ~10 minutes when then finally all the packets will be
returned for these 10min


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20090602/d7fab2fb/attachment.pgp>