[FFmpeg-devel] Netgem

[Baptiste Coudurier]

Hi Michael,

Michael Niedermayer wrote:
> On Sat, Feb 21, 2009 at 07:38:42PM -0500, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sat, Feb 21, 2009 at 7:31 PM, Baptiste Coudurier
>> <baptiste.coudurier at gmail.com> wrote:
>>> Michael, could please have a look at the "even_report" function in
>>> AVFormatContext ? I'd like to implement the redirection for mov and will
>>> use it for dref handling too.
>> Oh yes, I've had local patches for this for a long time also, I
>> considered it too dirty to ever send back, but this'd be really nice
>> to have in lavf at some point!
> 
> the event_report() in this patches looks like a dirty undocumented mess
> 
> first let make sure i understand what this is
> about, there are mov files refering to other files, so that the actual
> video / audio data is in these files.
> (not really mov specific, there is SMIL and others as well ...)
> These other files might represent full mov files or just data?
> These other files might switch depending on time aka 1 file per
> chapter?
> These other files might be 1 file per stream. So that multiple
> have to be open? (i dont see ho event_report() as is in the patch could
> handle this)
> 
> Either way there are 2 obvious ways to export such information, one is all
> at once like AVChapters and the second is as it becomes relevant.
> For the second case its important that the order of the data in
> relation to AVPackets is not messed up and AVPackets could be in a
> que and stuff, even_report() that bypasses this que is majorly
> inconvenient. But see below for some more details why i think so
> 
> what use cases are there?
> 1. simple demux->decode (with functional seeking)
> 2. transcoding the main file while leaving the references untouched
> 3. transcoding all data into a single flat file.
> 
> its especially in case 2. that the location where the reference is within
> the stream and for which stream it is must be preserved. AVPackets seem
> a natural way to handle this.
> 
> The things my tired mind sees as needed for all that are:
> A. some clean way to connect a single demuxer to several files
> B. some clean way to connect a single demuxer to several other demuxers
> C. some clean way for a demuxer to ask for other files to be opened/closed
> D. some clean way for a demuxer to ask for other demuxers to be opened/closed
> E. some clean way for a demuxer to ask for itself to be replaced by another
>    demuxer (redirect)
> 
> these are all not without thier issues ...
> but first it seems to me that returning a AVPacket that asks for these things
> is better than a new callback because
> 1. it can easily be intercepted and handled immedeatly or passed through the
>    packet que.
> 2. if it is handled immedeatly (making another file available to the demuxer)
>    it still can be passed through the que and could then at the correct time
>    cause some information display to be updated, with a independant callback
>    it might be quite tricky to just display the current filename accurately
> 3. The information is naturally associated with a stream_index
> 4. If opening of the new file is slow (network, server down or too busy)
>    a callback will lock the demuxer until the user app can fullfill the
>    request. While simply a returned AVPacket that asks for it to be opened
>    would not block the demuxer, it still could return packets for other
>    streams ...
> 
> And having the whole list available at the begin has advantages too
> like being able to open files immedeatly (and tell the user immedeatly
> that something is missing instead of later telling about a missing
> chapter as the event that asks for it comes in)
> 

I see using AVPackets has some advantages.
How would you give information back to the demuxer ?

In the case of opening an external file, the underlying ByteIOContext
needs to be available to the demuxer.
In the case of a underlying demuxer, the underlying AVFormatContext must
be available to the demuxer.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org