[FFmpeg-devel] MPEG-PS demuxer index memory usage
Michael Niedermayer
michaelni
Sat Jan 12 19:45:28 CET 2008
On Mon, Jan 07, 2008 at 08:10:17AM +0000, Paul Kelly wrote:
> On Mon, 7 Jan 2008, Michael Niedermayer wrote:
>> On Mon, Jan 07, 2008 at 01:36:39AM +0100, Baptiste Coudurier wrote:
>>> Paul Kelly wrote:
>>>> [...]
>>>>
>>>> + max_entries= s->max_index_size / sizeof(AVIndexEntry);
>>>> + if(max_entries == 0)
>>>> + return -1;
>>>> + if((unsigned)st->nb_index_entries >= max_entries){
>>>> + int in, out= 0;
>>>> + /* Halve the size of the index by removing every second entry
>>>> */
>>>> + for(in=0; in<st->nb_index_entries; in+= 2)
>>>> + st->index_entries[out++]= st->index_entries[in];
>>>> + st->nb_index_entries= out;
>>>> + }
>>>> +
>>>> entries = av_fast_realloc(st->index_entries,
>>>
>>> Just a note to remember that mov demuxer is building index containing
>>> all samples, and absolutely need all index entries to seek and demux, so
>>> you cannot remove any index entry with the current implementation.
>>
>> yes, right, i should have realized that earlier ...
>> so i guess the best would be an explicitly called ff_reduce_index() which
>> does the above. This also safes us from changing all av_add_index_entry()
>
> Do you mean to call ff_reduce_index() before av_add_index_entry() in
> individual demuxers, if it's appropriate to how they use the index? The
> attached patch does that, but only for AVFMT_GENERIC_INDEX and the mpegps
> demuxer (to solve my specific problem). If it's the right approach I could
> try adding it to the other demuxers too, but it might be better if someone
> more familiar with how they work did that.
>
> Paul
[...]
> /**
> + * Check the size of the index for the given stream against the maximum
> + * specified in the AVFormatContext. If adding another entry would go
> + * over the limit, halve the size of the index by removing every second
> + * entry.
> + *
> + * @return < 0 if no more entries may be added to the index or the stream is invalid
> + */
Trailing whitespace, and it should be more generically described, not
mentioning the precisse implementation.
Like, "ensures that the index uses less mem than what is specified as
maximimum in AVFormatContext.max_index_size. If the index is too large
it will discard entries."
[...]
> +int ff_reduce_index(AVFormatContext *s, int stream_index)
> +{
> + AVStream *st;
> + unsigned int max_entries;
> +
> + if(stream_index < 0 || stream_index >= s->nb_streams)
> + return -1;
i think it can be assumed that the parameters are valid
> + st= s->streams[stream_index];
> +
> + max_entries= s->max_index_size / sizeof(AVIndexEntry);
> + if(max_entries == 0)
> + return -1;
I dont see what harm a single entry would do with max_entries == 0.
So this and the return checking seems unneeded
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20080112/544a580e/attachment.pgp>
More information about the ffmpeg-devel
mailing list