[FFmpeg-devel] Netgem

[Michael Niedermayer]

On Sat, Feb 21, 2009 at 06:45:08PM -0800, Baptiste Coudurier wrote:
> 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.

adding a ByteIOContext *pb to AVStream seems like the obvious option


> In the case of a underlying demuxer, the underlying AVFormatContext must
> be available to the demuxer.

similarly, adding a AVFormatContext *sub_ctx to AVStream seems like a option
i dont know if this would be sufficient for all cases? or ideal?

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

It is not what we do, but why we do it that matters.
-------------- 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/35870886/attachment.pgp>