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

Michael Niedermayer michaelni
Sat Jan 5 20:16:28 CET 2008


On Sat, Jan 05, 2008 at 05:14:21PM +0000, Paul Kelly wrote:
> On Sat, 5 Jan 2008, Michael Niedermayer wrote:
>
>>> OK, first attempt at a patch is attached. Is the general idea OK? I'm not
>>> sure where the check for !url_is_streamed() should go so I haven't 
>>> included
>>> it - possibly in av_new_stream()?
>>>
>>> Paul
>>
>>> Index: libavformat/avformat.h
>>> ===================================================================
>>> --- libavformat/avformat.h	(revision 11408)
>>> +++ libavformat/avformat.h	(working copy)
>>> @@ -342,6 +342,7 @@
>>>                                      support seeking natively */
>>>      int nb_index_entries;
>>>      unsigned int index_entries_allocated_size;
>>> +    unsigned int max_index_size; /**< max memory to use for index when 
>>> demuxing */
>>>
>>>      int64_t nb_frames;                 ///< number of frames in this 
>>> stream if known or 0
>>>
>>
>> /**
>> * Stream structure.
>> * New fields can be added to the end with minor version bumps.
>>                                  ^^^
>> * Removal, reordering and changes to existing fields require a major
>> * version bump.
>> * sizeof(AVStream) must not be used outside libav*.
>> */
>> typedef struct AVStream {
>>
>> also iam slightly thinking that this would belong more to AVFormatContext
>> or what is the use case of having max_index_size differ between streams
>> and the user should be able to set it from the command line
>> if it were in AVFormatContext you only would have to add a single line to
>> the AVOption array in libavformat/utils.c
>
> Ok I understand now about the AVOption array - it's a very neat idea and I 
> agree adding it there and putting max_index_size in AVFormatContext is a 
> more logical and elegant solution than putting it in AVStream.
> BUT.. as far as I can see there would then be no way of accessing it in 
> av_add_index_entry(), because only an AVStream is passed to it. Am I right 
> that there is no way to access the "parent" AVFormatContext of an AVStream 
> struct?

yes, i think so.


>
> If that's the case then the only way I can see that having it in 
> AVFormatContext would work would be to rewrite av_add_index_entry() to take 
> a pointer to an AVFormatContext, and change everywhere it is called in all 
> the demuxers -

yes, if its in AVFormatContext av_add_index_entry() and all calls to it 
need a tiny change.
If its in AVStream, some work needs to be done in ffmpeg.c/ffplay.c/utils.c
so AVStream also uses AVOption. Having AVStream work with AVOption too is
surely welcome independant of the index stuff but will be more work ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- 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/20080105/f41bf50a/attachment.pgp>



More information about the ffmpeg-devel mailing list