Theora in Matroska

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel