[xiph-rtp] vorbis-rtp update

[Ralph Giles]

On Tue, Oct 11, 2005 at 07:31:12AM +0200, Luca Barbato wrote:

> The fixes are coming nicely and hopefully it could be sent to ietf soon.

Thanks for all your work updating the draft! Unfortunately, I'm not 
happy with it yet. Sorry for not responding recently. I didn't have 
anything to add in September, and then got busy.

I think it's worth reproducing Aaron's table of the meaning of the C and 
F flags in the payload header. Working out what's meant from the 
definitions is confusing, so some additional text summarizing the 
combination outside the example would help, and stating that RTP 
payloads can be packed or fragmented but not both. Not sure if this 
should go in section 2.2 or 3.

  http://lists.xiph.org/pipermail/xiph-rtp/2005-February/000142.html

Also, the flags should be 0|0 instead of 0|1 in Figure 5 for a packed 
payload.


I agree with David that the comment header packets should be allowed,
probably at arbitrary points in the stream. Please change the text to
permit this.

I guess you're trying to keep them out of the packet setup data block 
that gets CRCd, but the packet is required by the spec, and not allowing 
it destroys the transmissibility of Ogg Vorbis streams. It's true of
course that this packet can be abused, but as we've always said, the
only idea was to provide a saner alternative to ID3 tagging. Of course
a separate metadata stream (using vorbis metadata packets or something
more capable) is a better idea, but I think inline metadata transmission
can still be useful.


You haven't updated Phil's payload header aside from the CF flags, and
the decoder setup is still based on the CRC32 I decided against. This 
needs to be changed as well. I guess we never really got consensus for 
how big the setup mapping field should be, but I'd like you to update
the text to use my proposed scheme in the meantime:

  http://lists.xiph.org/pipermail/xiph-rtp/2005-April/000194.html

Note that this also ups the number of vorbis packets field to 5 bits;
for theora we wanted to keep it at 4 with 2 reserved bits because of
the larger average packet size.

Can you explain again your reasoning for using the packed header 
format for inline transmission? It always made more sense to me
to use the same packetization as for data and let the payload
header indicate the matching ident. Especially since the codebooks
will usually have to be fragmented.


Typo in section 4: "methodsMAY" Also the last sentence of paragraph 4 
doesn't make sense.


In section 5 you give the MIME type as audio/vorbis, but in 5.1 it's 
audio/VORBIS. Does the capitalization mean something, or is that an
error?


Anyway, that's my first review pass. Hopefully we can at least get an 
updated draft for the 64th meeting.

 -r