[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Vorbis RTP issues list for Vienna
Hi Phil,
Here are a few more comments and some pointers worth checking out.
philkerr@elec.gla.ac.uk wrote:
Quoting Magnus Westerlund <magnus.westerlund@ericsson.com>:
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 +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt