Re: [AVT] Vorbis RTP issues list for Vienna

[Magnus Westerlund <[e-mail]>]

Hi Phil,

Here are a few more comments and some pointers worth checking out.


[e-mail] wrote:
> Quoting Magnus Westerlund <[e-mail]>:


>>7. Section 2.3: Third paragraph, page 5: The limitation that a Vorbis 
>>packet shall not be larger than 64k bytes. What about IPv6 Jumbograms 
>>and the fragmentation process? It seem possible to have larger packets 
>>although it would be a bad idea.
> 
> 
> The codebooks can be far greater than 64k in size but a limit was imposed to
> allow it to be transported inside a RTCP packet and to reduce the delay a client
> may have in waiting for a large codebook to be received.   Perhaps a note
> detailing that transport over IPv6 allows greater packet size would cover this
> scenario.
> 

I think that we need to clear consider how to get these codebooks 
transported. A larger than 64kb codebook should neither be transported 
in SDP or in RTCP. I think that using HTTP can clearly be an 
alternative, and only provide the URI to the codebook.

I wouldn't try to transport a codebook over RTCP that results in a RTCP 
packet many time the MTU due to the high number of IP fragments. Further 
such a packet will severely reduce the RTCP report rate in both directions.

> 
>>8. Section 2.3, fifth paragraph: Why it the length field only a single 
>>byte? In some use cases it seems that having aggregation only for 
>>packets smaller than 256 bytes may be limiting. Have you studied what 
>>the frequency different packets are created. If you have a lot of 
>>packets in the size of 257-500 bytes they may be advantageous to be able 
>>to aggregate.
> 
> 
> The length field size was specified in the original draft-moffitt-vorbis-rtp I-D
> and it's been kept as it seems a fair limit, losing a packet with a 64 or 128
> Vorbis frames will cause a greater skip than 32.  Aggregating packets larger
> than 256 bytes is allowed so your scenario is catered for.  When you read this
> section did you get the impression that this was not allowed?  If so it can be
> altered to make it clearer.

The first indication is the second paragraph in section 3: "Any Vorbis 
packet that is larger than 256 octets and less than the path-MTU MUST be 
placed in a RTP packet by itself.". Secondly the payload format does not 
describe a mechanism to allow it.

> 
>>10. Section 2.3: How does one perform RTP TS recovery for the individual 
>>Vorbis packets in an aggregated packet? Are the RTP TS not needed or are 
>>there some implicit method. Please clarify.
> 
> 
> This needs further investigation.

This is probably one of the most important things as most decoders and 
error recovery mechanism needs to receive the frames/packets in timing 
order plus with detection of lost frames.

> 
>>21. Section 4.1, how to utilize the subtype in this APP packet is not 
>>defined.
>>
>>22. Section 4.1 Why have have flags for the different parts when you are 
>>required to send all of the fields?
> 
> 
> All of the header information is required for the initial setup of the clients
> decoder but the codebook and metadata may change mid-session.  The meta-data
> will probably be the most dynamic (track number/title/artist changing) and the
> flags are used to indicate the payload sub-type.  The VORB RTCP packet can
> contain one, or all of the sub headers components.

That was not how I read the text. See section 4.1 paragraph 2 on page 
11. There is a MUST there in the third sentence that I interpreted as 
requiring all as needed.

I think that sending this meta information in RTCP can be appropriate, 
or in the packet stream if RTP retransmission is used. However the 
codebooks will most probably need special treatment, unless they are no 
bigger than a 1 kb.

> 
>>29. Section 5: The usage of "u=", I don't think it is appropriate to use 
>>"u=" to include an URI to the codebooks and other stream information.
>>
>>30. Section 5: The usage of "c=", The Vorbis payload format can't 
>>redefine the usage of "c=" field or require it to be used. SIP use the 
>>field to declare the receiver address, while RTSP does not use it at all.
>>
>>31. Section 5.1, I think that all Vorbis specific SDP attributes should 
>>be sent in the a=fmtp line and be declared as required MIME parameters 
>>if they always must be present. Why are there no parameter for the 
>>codebook itself? Also an URI to this information could be included here. 
>>However the implications that a client must follow a link to fetch this 
>>information must be further explained.
> 
> 
> I'll look into this further.

I would suggest that you take a look at the MIME and SDP sections of the 
  H264 payload format (draft-ietf-avt-h264-02.txt) or the AMR payload 
format (RFC 3267).

Cheers


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt