[xiph-rtp] Merge all metadata in one single packet.

[Luca Barbato]

I'd like to merge all the 3 headers in one since the comment packet
should be always empty or at least about 2 order lesser than the
codebook size. That way should simplify the transmission logic a bit and
could make sense since codebook and setup should change together quite
often. I'm a bit afraid about the comment changes, since they could be
abused and really don't belong to the vorbis audio stream (and thus
should be delivered with a different medium)

That way the metadata payload could be the same in the 3 possible medium
"families": inline sdp, in band and off band.

To sum up:

- Just use one packet for all metadata

- Use the same packet layout for every vector (inline, inband, offband)

- Limit what should stay in the comment packet

Please send me some comments.

lu

[Michael Smith]

Post by Luca Barbato
I'd like to merge all the 3 headers in one since the comment packet
should be always empty or at least about 2 order lesser than the
codebook size. That way should simplify the transmission logic a bit and
could make sense since codebook and setup should change together quite
often. I'm a bit afraid about the comment changes, since they could be
abused and really don't belong to the vorbis audio stream (and thus
should be delivered with a different medium)

I think this is a bad idea. We should either disallow comment headers
altogether, or allow them at arbitrary points.

Doing otherwise will lead to the abuse we've seen with vorbis-in-ogg -
starting a new logical stream, with a full new set of headers, simply
to update the metadata shown in the client.

Given that we now have the opportunity to avoid this problem the
second time around, we should take it. Allowing comment headers at
arbitrary points solves the problem neatly, but your argument that
this should really be handled in a seperate stream is somewhat
compelling - hence my suggestion to just disallow them entirely.

Either way, packing the two really-mandatory setup packets (primary
and 'codebook') together seems reasonably sensible.

Mike

[Luca Barbato]

Post by Michael Smith
I think this is a bad idea. We should either disallow comment headers
altogether, or allow them at arbitrary points.

I see.

Post by Michael Smith
Given that we now have the opportunity to avoid this problem the
second time around, we should take it. Allowing comment headers at
arbitrary points solves the problem neatly, but your argument that
this should really be handled in a seperate stream is somewhat
compelling - hence my suggestion to just disallow them entirely.

I'd like to remove them for sake of simplicity and because I don't see
any usage that couldn't be covered in other ways (if somebody know
speaks now, please).

Post by Michael Smith
Either way, packing the two really-mandatory setup packets (primary
and 'codebook') together seems reasonably sensible.

I'll try something. Packing everything together is consistent with the
other non ogg usage of vorbis (matroska and ffmpeg families). Resending
everything just to change the comment informations is pretty overkill,
but updating the comment with the codebook and setup makes sense.

lu

[David Barrett]

How about packing the setup/codebook together into a single packet, but
allowing comments to be sent at will? In effect, we treat entirely
separate the comment and setup/codebook packets.

Personally I don't use comments, but I think it's a good feature to keep
(or, said another way, I don't see a compelling reason to remove it
entirely).

-david

Post by Luca Barbato

Post by Michael Smith
I think this is a bad idea. We should either disallow comment headers
altogether, or allow them at arbitrary points.

I see.

Post by Michael Smith
Given that we now have the opportunity to avoid this problem the
second time around, we should take it. Allowing comment headers at
arbitrary points solves the problem neatly, but your argument that
this should really be handled in a seperate stream is somewhat
compelling - hence my suggestion to just disallow them entirely.

I'd like to remove them for sake of simplicity and because I don't see
any usage that couldn't be covered in other ways (if somebody know
speaks now, please).

Post by Michael Smith
Either way, packing the two really-mandatory setup packets (primary
and 'codebook') together seems reasonably sensible.

I'll try something. Packing everything together is consistent with the
other non ogg usage of vorbis (matroska and ffmpeg families). Resending
everything just to change the comment informations is pretty overkill,
but updating the comment with the codebook and setup makes sense.
lu

[Silvia.Pfeiffer at csiro.au ()]

May I suggest that CMML (which has been developed to work as an additional track in Ogg) could be one type of separate stream that solves your metadata problem. It has been designed for exactly this purpose: to update metadata over time within a stream.

If only I got around to creating a payload format for CMML over rtp/rtsp...

Cheers,
Silvia.


-----Original Message-----
From: xiph-rtp-***@xiph.org on behalf of Michael Smith
Sent: Wed 10/5/2005 4:37 AM
To: Luca Barbato
Cc: xiph-***@xiph.org
Subject: Re: [xiph-rtp] Merge all metadata in one single packet.

Post by Luca Barbato
I'd like to merge all the 3 headers in one since the comment packet
should be always empty or at least about 2 order lesser than the
codebook size. That way should simplify the transmission logic a bit and
could make sense since codebook and setup should change together quite
often. I'm a bit afraid about the comment changes, since they could be
abused and really don't belong to the vorbis audio stream (and thus
should be delivered with a different medium)

I think this is a bad idea. We should either disallow comment headers
altogether, or allow them at arbitrary points.

Doing otherwise will lead to the abuse we've seen with vorbis-in-ogg -
starting a new logical stream, with a full new set of headers, simply
to update the metadata shown in the client.

Given that we now have the opportunity to avoid this problem the
second time around, we should take it. Allowing comment headers at
arbitrary points solves the problem neatly, but your argument that
this should really be handled in a seperate stream is somewhat
compelling - hence my suggestion to just disallow them entirely.

Either way, packing the two really-mandatory setup packets (primary
and 'codebook') together seems reasonably sensible.

Mike