[xiph-rtp] P2P Theora Header delivery; why not SDP?

David Barrett dbarrett at quinthar.com
Tue May 10 19:58:21 PDT 2005


Hi, I'm a long fan of Theora, and am starting an RTP implementation with:

http://svn.xiph.org/branches/theora-mmx/doc/draft-kerr-avt-theora-rtp-00.txt

Am I correct in understanding there are only two ways to deliver
configuration headers?

1) "in-band" using RTP
2) "out-of-band" by downloading from a URI specified in the SDP using TCP


If so, how would you recommend implementing this in a P2P setting in light
of lossy UDP transmission and NAT piercing?  I see the following
complications:

- With respect to #1, UDP is lossy, and RTP has no standard retransmission
technique.  Furthermore, due to NAT-piercing issues, the initial RTP packets
have the highest probability of being lost (because your NAT will block my
RTP packets until you "punch a hole" by sending a packet back to me).

- With respect to #2, TCP cannot pierce NATs near to the same degree as UDP.
Thus option #2 limits the range of deployment to those clients between which
TCP connections can be established.


As such, the following semi-compliant techniques come to mind:

A) Use "in-band" transmission and keep resending the headers until the first
RTCP packet has been received (effectively using to ACK the session).  The
spec says "Clients MUST be capable of dealing with periodic re-transmission
of the configuration headers", so this should work in theory, but it
certainly isn't intended.

B) Use "out-of-band" transmission with the help of a third party (publish
the headers to some TCP-enabled third party, and download from there).  This
adds centralization to an otherwise decentralized problem, along with its
resultant complications (scalability, authentication, etc.).

C) Use (B), but pre-populate it with a large library of headers from which
clients can index in a read-only fashion.  This is better, but only works if
header-generation is deterministic (ie, headers generated with the same
settings are exactly the same).  I assume it is -- can anyone confirm this?
In this way, I can just generate my headers locally, and use its CRC32 to
index into the server's library.


A and C seem like the best option to me so far, but both still rather suck
(A is unreliable, and C imposes a central solution into the mix).  

What I would prefer (and actually expected but was surprised not to find)
would be a third option where the inputs into the header-generation process
are simply specified in the SDP itself (on the assumption that
header-generation is deterministic from these, and can be computed locally).
For example:

c=IN IP4/6
m=video  RTP/AVP 98
a=rtpmap:98 theora/90000
a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720;
header=<URI of configuration header>
a=theora: <frame_width>x<frame_height>;
	<offset_x>,<offset_y>;
	<width>x<height>;
	<fps_numerator>/<fps_denominator>;
	<aspect_numerator>/<aspect_denominator>;
	<colorspace>;
	<target_bitrate>;
	<quality>;
	<dropframes_p>;
	<quick_p>;
	<keyframe_auto_p>;
	<keyframe_frequency>;
	<keyframe_frequency_force>;
	<keyframe_mindistance>;
	<keyframe_data_target_bitrate>;
	<keyframe_auto_threshold>;
	<noise_sensitivity>

When spelled out in prose it looks like a lot of data, but in practice it'd
actually look something like:

c=IN IP4/6
m=video  RTP/AVP 98
a=rtpmap:98 theora/90000
a=fmtp:98 sampling=YCbCr-4:2:2; width=1280; height=720;
header=<URI of configuration header>
a=theora: 96x64; 0,0; 96x64; 15/1; 0; 45000; 0; 0; 1; 1; 64; 64; 8; 67500;
80; 2

Is this possible?  Looking back over the [xiph-rtp] list I see a lot of
discussion about static, cached, and downloadable codebooks, but I don't see
where SDP is mentioned as an option.  Has this option already been
considered and discounted?

-david



More information about the xiph-rtp mailing list