[xiph-rtp] about theora-over-rtp draft

[Simon Morlat]

Thanks for your quick feedbacks !

> there is: the first packet is fixed in size. Check the example code in:
>
> http://svn.xiph.org/trunk/xiph-rtp/
If this is a known fact that the header is fixed size, then it should be written in the rfc.
However I don't think it's a good idea, this may prevent theora developers to make evolutions to the codec.

>
>
> > 2/ about fragment type. The draft defines 3 types: begin of packet,
> > continuation of packet, and end of packet. I think this is really very
> > redundant information: the receiver only needs to know the frontier
> > between video frames, nothing more. Setting the marker bit of the rtp
> > header to 1 for the last packet of a video frame is enough and much
> > simple.
>
> I think isn't.
Why ?

>
> > RTP (RFC3550)
> > tells it's up to payload specifications to indicate the meaning of this
> > markbit. There's no problem in using it. RFC2429-bis (payload spec for
> > H263-1998) does that.
>
> We could have a look at it again but if it was discarded even before I
> joined the development of this rfc probably there could be a reason.

You can find the rfc2429 draft here:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2429-bis-09.txt


>
> > Furthermore, for the fragmentation algorithm, it is painful to know
> > whether a fragment is a end of packet or continuation packet.
>
> Why? you just have to check the Fragment type field.
I was talking about the algorithm at the encoding side that splits a theora frame into smaller packets, not the algorithm at the receiving side.


>
> > -> I used the marker bit to indicate end-of-frames packet.
>
> If you use the marker bit you have a problem in telling if is a full
> packet or not, using the drafted way is immediate.

What problem ? The algorithm takes in four lines:
packet=rtp_get();
accumalate_into_internal_buffer(packet);
if (!marker_bit_set(packet))
	process_accumulated_buffer_and_clean_it();

>
> > 3/ I used inband sending of configuration headers. The inline SDP method
> > has a big problem for me: it forces the SDP offerer to configure its
> > theora encoder before even knowing about the bandwidth constraints of the
> > remote side (expressed using the b=<AS>: field of SDP).
>
> No, you should use offer-answer[rfc3264] to have an agreement between
> client and server see 6.2

Please explain how the SDP offerer could propose a theora configuration inlined in the sdp message before even knowing the receiving prequisite of the other side. This cannot work. Typically if the offerer want to send CIF at high bit rate, but unfortunately the other side cannot receive else than QCIF at very low bitrate, you have NO way to give him the configuration string that fits thoses requirements.
The SDP offer/answer is made of only 2 messages !

Taken from RFC3264:
"If the bandwidth attribute is present for a stream, it indicates the
   desired bandwidth that the offerer would like to receive. "

If the SDP offerer sends its theora configuration in the sdp offer message, it logically CANNOT take in account the bandwidth attribute sent by the remote side.

>
> I think Offer-Answer is a solution, maybe I could relax a bit the
> constraint, but even as is it fits already your requirement:
>
> - the encoder side knows already the maximum resolution, its side
> maximum bitrate and could set a lower bound between resolution and
> bandwidth using heuristics.
>
> - the decoder side will receive an offer with a sufficiently wide set of
> possibilities and it will pick the ones it supports
> bandwidth/hw/protocol wise.

But how the decoder side will inform the encoder side of the config it has choosen ?
Furthermore most streams are full duplex, they are two encoder side and two decoder side. We should talk about SDP offerer and answerer.
Let's imagine the SDP offerer suggests 3 theora config using various bandwidth constraint.
The SDP answerer can eventually tell which one of the config it chooses. But as it also sends a theora stream and will also suggests various theora configs int the same way
Unfortunately as the SDP offerer has no way to indicate the config it chooses as there is no third message.

As far as I understand, the only SDP offer/answer model that works is the one where each side tells its preferences and constraints about the stream they wish to receive.
Remember also that many internet access are asymetric: we really need that both sides indicates their receiving capabilities.

>
> [a completely nonstandard implementation]
Unfortunately... I want my software to work to let me see my family and friends. As we only have 512/128 adsl connection, it's important that each side properly takes in account the receiving capabilities of the other side.

Lastly, I forgot to tell about the possibility offered by the draft to put several theora frames in a single rtp packet. My opinion is that this is completely useless because RTP is done for real-time streaming, and putting several theora frames in a same rtp packet means buffering theora frames before sending them, thus it's no more real-time.
Despite this possibility is often offered by audio codecs to save bandwidth by reducing rtp overhead, it has never been used for video codecs, simply because the huge size of video packets compared to the rtp header makes the gain of bandwidth very limited. Thus it's simply more simple to rely on the underlining protocol (UDP/RTP) to know the size the video packets, and assume that each RTP packet contains at most 1 video frame.


Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/xiph-rtp/attachments/20060721/00acc481/attachment.htm