[xiph-rtp] vorbis-rtp update

[Luca Barbato]

Ralph Giles wrote:
> 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.

I based the graphics to the reference code, I already clarified the 
issue in the very latest draft.

> 
> 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.

The problem is from one side logic: metadata belongs to the container 
not the codec payload; on the other side it adds complexity that is 
unneeded. To put it on another point of view.. well, we have enough bits 
left to have it separate and completely optional so I could say why not.

I'm not convinced of their use or merit but I'd put them as completely 
optional. I'll prepare something soon.

> 
> 
> 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.

That will take time and I'm not sure how well is accepted. I know that 
there are early adopters, hopefully that change shouldn't be a problem 
for them since we still are byte aligned.

> 
> 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.

Just to keep separated data and codec specific information at container 
level. The Packed configuration is expected to be fragmented already

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

I guess could be expressed better. Basically the intent is to recommend 
inline SDP if the stream isn't chained.

> 
> 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?

I left that part as was, there is a note explaining that mime and sdp 
are case insensitive in that regard.

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

I hope so too. (2 if we are really quick)

lu

-- 

Luca Barbato

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