[FFmpeg-devel] [RFC] Handling the encapsulation of "E-distribution audio"

[Kieran Kunhya]

--- On Wed, 21/7/10, Anssi Hannula <anssi.hannula at iki.fi> wrote:

> From: Anssi Hannula <anssi.hannula at iki.fi>
> Subject: Re: [FFmpeg-devel] [RFC] Handling the encapsulation of "E-distribution audio"
> To: ffmpeg-devel at mplayerhq.hu
> Date: Wednesday, 21 July, 2010, 19:17
> Kieran Kunhya kirjoitti lauantai, 17.
> hein?kuuta 2010 20:57:36:
> > "E-Distribution audio" (Dolby E) has an odd
> encapsulation method. It is
> > designed to hide as 2-channel PCM and can contain up
> to 8 different
> > streams.? Program map changes (e.g. from 5.1 to
> 2.0) are common.? For
> > various reasons you also need to have access to the
> whole frame to decode
> > a particular channel. This doesn?t fit well with
> lavf/lavc?s model where
> > each program is separate in the container. The audio
> is actually
> > encapsulated in the PCM using SMPTE 337M which is
> similar to SPDIF
> > encapsulation.
> > 
> > Realistically the only containers that would contain
> this audio are wav,
> > mxf, ts and possibly mp4/mov. TS is more complicated
> because TS uses SMPTE
> > 302M encapsulation which creates a longer chain:
> > 
> > TS -> SMPTE 302M -> SMPTE 337M ->
> E-distribution
> > 
> > Possible solutions:
> > Some sort of chained demuxer (best option imo). I
> don?t know enough about
> > lavf/lavc internals to code this one.? This would
> presumably require some
> > discussion about the API changes (something like demux
> depth?)
> > 
> > Don?t split up into programs (e.g. a 5.1+2.0 stream
> would be treated as one
> > 8 channel stream)
> > 
> > Any other options I haven?t mentioned? What's the
> best way to handle this?
> 
> The situation seems similar to LATM, where it is TS ->
> LATM -> AAC, though 
> AFAIK multiple AAC streams in LATM is not common.
> 
> Chained demuxer would indeed be the preferred method, from
> what I can tell.
> 
> Michael posted this suggestion a year ago, though it
> probably requires more 
> refining:
> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-May/070200.html
> 

It's similar to LATM except SMPTE 337M's existence isn't flagged at all.

Questions for Michael about his proposal (or anyone else):

1. How does one flag that the "Combining Demuxer" must exist (considering it might need to exist before the latm (or whatever) has been detected)?
2. What does "Packet to ByteIOContext" involve?
3. How does one flag that a particular stream must pass through the "Combining Demuxer"?