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

[Michael Niedermayer]

On Wed, Jul 21, 2010 at 01:20:43PM -0700, Kieran Kunhya wrote:
> --- 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)?

either the system allows adding it later or we could have some kind of
flag in Demuxers that indicates that a combining demuxer may become needed and
then always add one, this would add it redundantly in some cases
that would be a bit like CODEC_CAP_ for decoders


> 2. What does "Packet to ByteIOContext" involve?

a call to init_put_byte() with appropriate implementations of the read/seek
stuff with buffers and as litte memcpy as possible behind. The read packet
would call the previous demuxers read_frame or whatever.
one open issue is that the previous demuxer might not be able to fullfill the
request to provide a packet in that stream and we would have to handle that
somehow. EEither by passing EAGAIN all the way through and having the later
demuxers handle this gracefully or to make the later demuxers not attempt any
opperation causing a read that maybe cannot be satisfied.


> 3. How does one flag that a particular stream must pass through the "Combining Demuxer"?

whatever code sets up the demuxer chain/network will likely set up things.
Maybe a specific codec_id or a new field in AVStream could indicate the need
for a chained demuxer and this could then be used by the core to connect
things

To a large extend all this is of course up to who implements things as
long as its mostly sane

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100721/b43917c9/attachment.pgp>