[xiph-rtp] Theora over RTP

[Rhys Hawkins]

Hi,

I've been looking at the draft spec:
http://svn.xiph.org/trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt
And libtheora 1.0_alpha3, and have a query regarding implementing the
encoding side of things. For each frame, I believe I do something
like:

theora_encode_YUVin(&state, &yuv);
result = theora_encode_packetout(&state, 0, &packet);

wrap_packet_in_rtp(packet);

However, the problem I have is how the last bit is done. As far as I can
gather, there must be a way to split the ogg_packet above into the
theora data chunks required in section 2.3/2.4 of the spec. I may be
getting it wrong, but I've come to this conclusion because;
- that makes more sense to me in terms of resilience to packet loss,
- the packet received from theora_encode_packetout is often larger than
64k and the length field for the theora data chunks is only 16bits.

Could someone please tell me the correct way to break apart the
ogg_packet if that is what is necessary? Or correct where I've gone
wrong above.

Cheers,
Rhys

[Ralph Giles]

Post by Rhys Hawkins
http://svn.xiph.org/trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt
And libtheora 1.0_alpha3,

In case you're not aware, I just released alpha6 which has a number of
bug fixes over alpha3 and some MMX asm optimizations.

Post by Rhys Hawkins
and have a query regarding implementing the
encoding side of things. For each frame, I believe I do something
theora_encode_YUVin(&state, &yuv);
result = theora_encode_packetout(&state, 0, &packet);
wrap_packet_in_rtp(packet);

Yes, that's correct. As you say, wrap_packet_in_rtp() has to segment
larger theora packets and can generate any number of RTP packets
(including less than 1 if it's packing very short packets together).

I believe the length field is just for the chunk contained in a given
RTP packet; where the theora packet spans several RTP packets, the
decoder must use the fragment/continuation bits and the packet sequence
numbers to infer whether it got all the data or not.

Post by Rhys Hawkins
Could someone please tell me the correct way to break apart the
ogg_packet if that is what is necessary? Or correct where I've gone
wrong above.

Just chop it into pieces so the RTP packets you're sending fit in your
MTU. Luca has written some example code you might find useful:

http://downloads.xiph.org/releases/xiph-rtp/xiph-rtp-0.1.tar.gz
http://svn.xiph.org/trunk/xiph-rtp/

Hope that helps, and let us know if you get it working!

-r

[Rhys Hawkins]

Hi Ralph,

Post by Ralph Giles

Post by Rhys Hawkins
http://svn.xiph.org/trunk/theora/doc/draft-barbato-avt-rtp-theora-00.txt
And libtheora 1.0_alpha3,

In case you're not aware, I just released alpha6 which has a number of
bug fixes over alpha3 and some MMX asm optimizations.

I did checkout from svn before posting to see if there were any api
changes. I noticed someones been documenting which is always nice :)

Post by Ralph Giles

Post by Rhys Hawkins
and have a query regarding implementing the
encoding side of things. For each frame, I believe I do something
theora_encode_YUVin(&state, &yuv);
result = theora_encode_packetout(&state, 0, &packet);
wrap_packet_in_rtp(packet);

Yes, that's correct. As you say, wrap_packet_in_rtp() has to segment
larger theora packets and can generate any number of RTP packets
(including less than 1 if it's packing very short packets together).
I believe the length field is just for the chunk contained in a given
RTP packet; where the theora packet spans several RTP packets, the
decoder must use the fragment/continuation bits and the packet sequence
numbers to infer whether it got all the data or not.

Post by Rhys Hawkins
Could someone please tell me the correct way to break apart the
ogg_packet if that is what is necessary? Or correct where I've gone
wrong above.

Just chop it into pieces so the RTP packets you're sending fit in your
http://downloads.xiph.org/releases/xiph-rtp/xiph-rtp-0.1.tar.gz
http://svn.xiph.org/trunk/xiph-rtp/

So it appears from the example code that you can just chop it
arbitrarily. Does this mean if you loose some of the packets for a
particular frame that it is impossible to reconstruct the whole frame?
If so, is there a better way to break apart the ogg packet so that each
resulting fragmented RTP packet is decodable in isolation (H261 does
this to some degree) or is this unecessary?

If this sort of stuff has already been discussed just point me to
the mailing list archive.

Post by Ralph Giles
Hope that helps, and let us know if you get it working!

Will do.

Cheers,
Rhys

[Luca Barbato]

Post by Rhys Hawkins
So it appears from the example code that you can just chop it
arbitrarily. Does this mean if you loose some of the packets for a
particular frame that it is impossible to reconstruct the whole frame?

In this trivial case, yes.

Post by Rhys Hawkins
If so, is there a better way to break apart the ogg packet so that each
resulting fragmented RTP packet is decodable in isolation (H261 does
this to some degree) or is this unecessary?

You may try to be smart but the rfc covers just basic usage, you should
discart the packets once you notice they are wrong, but you may do other
things (like using selective retransmission) depending on your
application and on how smart your endpoint are. The behaviour shown
should be considered as the expected fallback when anything else fails.

Post by Rhys Hawkins
If this sort of stuff has already been discussed just point me to
the mailing list archive.

It wasn't discussed in such way, I'm currently trying to implement
something smarter for my thesis project and obviously lots of itchy
detail are jumping in circles (mostly due the fact I need to make the
whole architecture quite much more flexible and make configuration data
move from layers quite far apart (sdp -> rtsp -> rtp)) but in the end
that is quite good since once this work is done supporting any codec
would be a less daunting task.

Please tell me if there are some oscure parts in the reference
implementation, I wrote that code with the aim of having it easy to
understand, I hope I haven't failed much.

lu