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

[Luca Barbato]

Simon Morlat wrote:
> So this does not make a big difference.

Agree

> I had a little question: when receiving multiple frames in a single RTP 
> packet, should we assume that it's always Full-Fragment ?

You collate always complete frames.

> 
>>> To sum up all this discussion, I'd like this draft to:
>>> - clarify the packed-conf message (limit between header and tables)
>> Agreed.

Something will appear soon.

>>
>>> - explain a SDP operation that let each side to configure asymetrically
>>> in a simple offer-answer (only 2 messages) scheme (for me it implies to
>>> NOT transmit inline encoder configuration in SDP, which prevents the
>>> offerer to adapt to the other end).
>> Sounds reasonable.

I'll add a reference to the xu's draft about this, I _think_ it should
cover everything.

> I think you 'll get more and more feedbacks from telephony developers in that 
> way... Perhaps they'll be more convincing than me !

I love to get feedback, but keep in mind that this rfc covers EVERY
usage of theora, not just telephony.

> The problem is not a programming one. I could have implemented the draft 
> already (with probably twice more lines than my "lightweighted" version.

point me your code please

> 
> My problem is that a I think complexity is adequate when there is a need to 
> solve a particular problem.

hm...

> 
> * To solve the problem of frame fragmentation, I think one bit is enough. The 
> four item enum proposed in this draft is full of redundancy and makes the 
> implementation a bit more complex for no value added.

beside a bit more resilient IMHO.

> 
> * You tried to solve the problem of rtp header overhead by proposing a 
> multi-frame per rtp packet structure, that's ok but my feeling is that the 
> rtp header overhead is not a problem at all. So the complexity of handling 
> multiple frames per packet is not justified, for me.

You may not use it, and unpacking a collated frame requires about 4-8
lines more.

> 
> * One big problem for me is to setup a RTP session through SDP with 2 
> messages: for me the theora draft is "too simple" as it does not answer 
> clearly on how to achieve this.

Not the point of the rfc, the Offer-Answer related rfc are already there
 and probably
http://www.ietf.org/internet-drafts/draft-xu-mmusic-sdp-codec-param-01.txt

will help a lot.

> 
> The reason why I think I might not be totally wrong is that this draft has 
> choosen different design principles than mpeg4 and h263, and I don't see any 
> reasons for that.

the h263+ rfc looks a bit more complex, the receiver is supposed to dig
a bit deeper in the rtp packets, thus making it quite codec specific.

the current implementation is consistent with rtp-vorbis, it is quite
simple and is more or less a "implement one get 2" approach.

> 
> I'll try to implement the draft fully in a future release, with some 
> workaround for SDP until the draft clarifies that part.

I'll try to think something, but it will be along the lines sdp-codec-param.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero