[FFmpeg-devel] Netgem

[Michael Niedermayer]

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)


comments welcome

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- 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/20090222/50b71960/attachment.pgp>