[FFmpeg-devel] MPEG-PS demuxer index memory usage[PATCH]

[Paul Kelly]

On Mon, 7 Jan 2008, Michael Niedermayer wrote:

> On Mon, Jan 07, 2008 at 11:37:46AM +0100, Michel Bardiaux wrote:
>> Michael Niedermayer a ?crit :
>>> On Fri, Jan 04, 2008 at 05:50:01PM +0100, Michel Bardiaux wrote:
>>>> Michael Niedermayer a ?crit :
>>>>> On Thu, Jan 03, 2008 at 10:48:49PM +0000, Paul Kelly wrote:
>>>>>> I can get over the immediate problem by simply commenting out the line
>>>>>> calling av_add_index_entry() in libavformat/mpeg.c, but would like to
>>>>>> help get a better solution into libavformat if I can.
>>>>> Disabling it with a flag is surely interresting. But i think there are
>>>>> better
>>>>> solutions.
>>>>> One for example would be a max_index_size. And when thats reached index
>>>>> entries would be pseudo randomly droped. That would limit the used
>>>>> memory and
>>>>> still speed up seeking.
>>>>>
>>>> Another possibility (not exclusive):
>>>>
>>>> if(!url_is_streamed(s->pb)) av_add_index_entry(...)
>>>>
>>>> After all, if the input is streamed, the index is unlikely to be of any
>>>> use!
>>> patch welcome
>> Here it is if it is still welcome after all the messages exchanged this
>
> patch o..., wait iam not mpeg maintainer, mans?

No news is good news? Can this go in? I'm actually more in favour of 
Michel's patch now than my own: after having done a bit of work on this I 
see that whether the index size should be limited or not is really a 
matter for the individual demuxers, as they may use it in different ways. 
If a demuxer doesn't limit the index size then that simply means it isn't 
suitable for use with a continuous stream of input data, but in many cases 
I guess that might not matter as it would not be possible anyway for 
various format-specific reasons?

MPEG-PS is IMHO though one format that should be capable of being 
processed in a continuous stream so it seems logical that a fix for that 
specific use case should go into the demuxer.

Best regards,

Paul