[xiph-rtp] Updated Vorbis and new Theora I-D's

[Tor-Einar Jarnbjo]

Phil Kerr wrote:

> Do you mean that it isn't clear that each Vorbis payload needs a VDT 
> octet?  There is only one VDT per packet, but after working on the 
> Theora I-D (which uses an 8 bit field) it became clear that it is 
> possible to have a VDT for each payload packet.  What do other think, 
> stick with only allowing one payload type per packet or allow mixed?  
> There will be complications for fragmented packets though of the mixed 
> route is taken.

Hi Phil,

As Ralph already pointed out, is the packet type already defined by the 
first octet in the packet data. What I mean is, that I don't see any 
reason for including this in the payload header as well. Alternatively 
use the two bit VDT field in the payload header, but then skip the first 
octet of the packet data, as the packet type is already defined.

>> It may also be relevant, that the datatype sizes are implementation 
>> dependent and that the quoted C function may produce wrong results on 
>> systems where ints are not 32 bits or chars not 8 bit.
>>  
>
> Good point.  The biggest issue is 32 bit ints as I don't think there 
> are many platforms which use a different size for unsigned chars 
> (might be worth checking though).

I haven't been programming much C for some time, but I am pretty sure, 
that DSP systems often have wider chars than 8 bits, as the DSP is not 
able to address the memory more exactly than e.g. every 4 bytes. 
Platforms using Unicode as the default character encoding may also have 
16 or 32 bits chars. A simple fix for the example code could be to use 
typedefs like UINT32 and UINT8 and then simply write a few lines of 
text, explaining that they are unsigned 32 and 8 bit integers. A better 
fix would be to write a more detailed pseudo language description of the 
algorithm or perhaps refer to another RFC where the same algorithm is 
already used and described or at least rewrite the example code to not 
use C mechanisms and syntax not easily understood by non-C-programmers. 
As is, the code example assumes knowledge of underflow handling 
(assigning -1 to an unsigned int) and the meaning of the >>, ^ and ~ 
operators is not exactly intuitive.

>> * Section 3.2 and 6: In 3.2 it's stated that "feedback reports on 
>> lost and dropped packets MUST be sent back via RTCP". In section 6, 
>> this requirement is reduced to that "Vorbis clients SHOULD send 
>> regular receiver reports detailing congestion." At least in a 
>> multicast scenario, it's mostly pointless for the client to report 
>> packet loss to the server, as there is no way to fix the situation.
>>  
>
> I know the AVT are keen on having this kind of info feeded back for 
> monitoring.  Perhaps the first MUST can be reduced to a SHOULD? 


I am not sure what the AVT is meaning and not, but it does not make 
sense to me at all for a client to send feedbackreports to a multicast 
transmitter, as the transmitter is probably not able to do anything 
about bad reception anyway. Or is the purpose of this to let the 
transmitter use e.g. RTSP mechanisms to redirect the client to a lower 
bandwith stream?

Tor