[FFmpeg-devel] [PATCH] probe max read size
Baptiste Coudurier
baptiste.coudurier
Tue Jun 2 00:37:55 CEST 2009
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.
> 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 ?
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel
mailing list