[NUT-devel] Re: [theora-dev] Theora in Matroska

[Michael Niedermayer]

Hi

On Fri, Nov 03, 2006 at 11:02:09AM -0800, Ralph Giles wrote:
> Forgive the cross posting, this affects several projects.

and forgive me too for doing the same ... (if the disscusion
is inappropriate for any of the lists just say so and i wont CC
that one anymore ...)


> 
> On Fri, Nov 03, 2006 at 12:50:27AM -0800, Unga wrote:
> 
> > Currently Theora video in Matroska is not supported by
> > Mplayer. To enable the support Michael Niedermayer has
> > made the following proposal sometime back:
> > http://article.gmane.org/gmane.comp.video.mplayer.nut.devel/214
> 
> The proposal is that we add a recommendation to the ogg vorbis
> spec to just concatenate the headers when embedding in a container
> that needs to store them in a blob, and that readers skip leading 
> and trailing data based on known packet lengths and magic strings.
> 
> As Michael says, this works, and is just the sort of hacky spec 
> wrangling ogg is (in)famous for. :)
> 
> I guess my only comment is that this isn't particularly general. 
> While vorbis has a fixed set of header packets with "easy" to determine 
> lengths, it's possible to do a codec with external framing in mind where 
> this wouldn't work. The theora spec, for example, allows additional 
> application-defined header packets after the initial required three.
> 
> It also means a cross-encapsulator has to understand a codec's header 
> packet format to put the data in an ogg stream, which is something many 
> implementors have complained loudly about. Therefore I'd like to 
> counterpropose something with explicit packet lengths, like matroska 
> has, or the "packed header" format the vorbis and theora rtp drafts use.

ive looked at the rtp draft and as far as i understand it it concatenates
the first 2 packets and omits all further ones
"
   A Theora Packed Configuration is indicated with the payload type
   field set to 1.  Of the three headers, defined in the Theora I
   specification [16], the identification and the setup will be packed
   together, the comment header is completely suppressed.  It is up to
   the client to provide a minimal size comment header to the decoder if
   required by the implementation.
"

this definitly has my support, not that that would make any difference... :)
comments, userdata, and other non essential data does not belong to a global
codec specific header be it in rtp or any container
normal containers have their own fields to store data like author, comment,
user specified metadata and so on
yes its a nightmare to convert from ogg to other containers or back but
putting this data in the global codec specific header does not solve
anything, the data would be as usefull as random data put there, and 
for rtp resources would be wasted to ensure error free delivery of possibly
large and useless data

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is