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

[Phil Kerr]

Hi Tor,

Tor-Einar Jarnbjo wrote:

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

Got it.

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


The only other CRC implementation I've seen in an RFC was written in 
Verilog.  As a lot of implementations are going to be written in C/C++ 
it's a reasonable language to use, I'm not sure how many implementations 
will be written purely for a DSP stack.  I think the compromise of 
either typedefing, or explaining the sizes of the vars is good though.

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

Yes.  There may not be anything a transmitter can due during the life of 
a session, but having details of how many clients are dropping out can 
be used to plan for other strategies like running the streams at lower 
bitrates, improving infrastructure and so on.

-P

>
> Tor
>
>