header packing for xiph codecs

At some point we talked about there being a general need to
pack the 
necessary decoder initialization headers for codecs like
Vorbis and 
Theora into a single binary blob, and how it would be nice
if there were 
some standard way to do that.

I've been pushing for something like that in the RTP payload
specs, 
which are going through a new round. So, what do you think
of the 
following:

- 24 bit "unique id" marking the header for
reference
- number of headers, encoded as a variable-length unsigned
integer, 
  using the 'v' method from the nut spec

- for each header:
  * length of the header in bytes, encoded using the 'v'
method
  * header data, padded out to the nearest byte boundary

Comments please,
 -r

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

Hi

On Mon, May 07, 2007 at 03:22:17PM -0700, Ralph Giles
wrote:
> At some point we talked about there being a general
need to pack the 
> necessary decoder initialization headers for codecs
like Vorbis and 
> Theora into a single binary blob, and how it would be
nice if there were 
> some standard way to do that.
> 
> I've been pushing for something like that in the RTP
payload specs, 
> which are going through a new round. So, what do you
think of the 
> following:
> 
> - 24 bit "unique id" marking the header for
reference
> - number of headers, encoded as a variable-length
unsigned integer, 
>   using the 'v' method from the nut spec
> 
> - for each header:
>   * length of the header in bytes, encoded using the
'v' method
>   * header data, padded out to the nearest byte
boundary
> 
> Comments please,

well any standardized packing is a big improvement for
everyone who has to
deal with xiph codecs in situations where multiple global
packets are
not possible ...

your specific suggestion above seems like a fairly simple
and flexible
choice

one thing though which id like to say (again) is that the
global headers
generally contain only data essential for decoding the
stream. and because
of that things like RTP and containers might try very hard
to keep them
intact possibly at the expense of startup delay and file
size ...
so putting comments, description and other metadata in them
is IMO a very
bad idea ...

PS: as a quite off topic note, IMO RTP should be more
generic and not
require a new RFC for every codec (this is shitty design
IMHO)
if it where just for things like the header packing that
would be 
understandable, but looking at for example the 200kb of text
needed
to describe h.264-rtp i feel the urge to vomit, 200kb should
be enough
to describe a RTP like protocol which supports all current
and future
mpeg and h.26x codecs and propriatery variants

[...]

-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest
or treaty, and
there is nothing more to fear from them, then he is always
stirring up
some war or other, in order that the people may require a
leader. -- Plato

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

On Tue, May 08, 2007 at 02:59:02AM +0200, Michael
Niedermayer wrote:

> one thing though which id like to say (again) is that
the global headers
> generally contain only data essential for decoding the
stream. and because
> of that things like RTP and containers might try very
hard to keep them
> intact possibly at the expense of startup delay and
file size ...
> so putting comments, description and other metadata in
them is IMO a very
> bad idea ...

Sure. In particular, the rtp draft has a mechanism for
transmitting 
metadata updates separately, and currently says an encoder
may want
to strip the metadata.

I was just trying to make it simple and consistent, so you
can pass 
everything if you want, and not have to think too hard about
it.

Anyone else I should run this by? I guess matroska have
already done a 
format (similar, but using Ogg-style lacing for the length
fields) so I 
guess it's too late for them. Anyone else working on
containers?

> PS: as a quite off topic note, IMO RTP should be more
generic and not
> require a new RFC for every codec (this is shitty
design IMHO)

It's even worse than Ogg! :^)

 -r
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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

Michael Niedermayer wrote:
> PS: as a quite off topic note, IMO RTP should be more
generic and not
> require a new RFC for every codec (this is shitty
design IMHO)

I'm trying to make at least vorbis and theora consistent and
pretty much
 the same beside what you store in the sdp (video vs audio
info),
hopefully dirac would fit into the framework too.

> if it where just for things like the header packing
that would be 
> understandable, but looking at for example the 200kb of
text needed
> to describe h.264-rtp i feel the urge to vomit, 200kb
should be enough
> to describe a RTP like protocol which supports all
current and future
> mpeg and h.26x codecs and propriatery variants

h264 it the easiest rtp packetizer I read since mpegaudio,
go figure...

lu - mpeg4 is the real joy...

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/
~lu_zero

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

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