Re: [AVT] Vorbis RTP issues list for Vienna

[[e-mail]]

Hi Magnus,


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

Agreed.  The size should be less than 64k, even if IPv6 can accomodate it and in
normal use they are typically under 15k.  Having very large codebooks wizzing
around is less than optimal.  

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

I have a feeling that this limit is artifically low and I'll check the to see if
it can be raised to allow larger Vorbis frames to be aggregated as you outlined
in your previous feedback.

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

Agreed.

> 
> > 
> >>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'll review this section and alter to remove any ambiguity.

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

Will do.

Cheers

Phil

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




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

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