[xiph-rtp] linphone-1.5.0 mostly complies to theora over RTP draft

[Luca Barbato]

Simon Morlat wrote:
> Hello Luca,
> 
>>> It's in file mediastreamer2/src/theora.c for those who are curious.
>>> - it uses the packed conf technique (which I still found the easiest and
>>> more flexible way in a SIP/SDP context )
>> Make sure you also inline the first conf in the sdp...
> Why ? Is this required ?

I didn't state it as strict requirement, would be a problem if I restate
it as a MUST? The reason is that this way you should cut some latency
(maybe it's pretty equal) and at least the first (and in many cases
only) stream will be decoded for sure (since sdp is delivered reliably).

Client anyway already MUST be able to understand it.

> rfc2984 has an extensive set of parameter that I don't find very useful...
> I don't think they will be used by many people around the earth.

Yes, I wasn't thinking about adding all of them.

> I suggested a 'maxframes' parameter to handle the case of an application like 
> linphone that never sends multiple frames in a single RTP packet and thus 
> does not want to support it at the receiving side, however this is not a good 
> idea. There may be the case where linphone will call a SIP server that 
> broadcast TV or whatever, so the case of multiples frames into one packet can 
> produce on a SIP phone.
> I'd rather implement the multiple frames decoding algorithm into linphone, and 
> keep the draft as simple as possible.

I don't have strong opinions about this and since the IANA section is
already pending a rewrite it won't make me write more =)

> Parameters such as max_br are redundant with already existing b=AS or b=TI SDP 
> parameters.

eh...

> Some other parameters indicate the maximum decoding capabilities of a receiver 
> (max frames per seconds, max size, max macroblocks per second and so on), 
> those ones might be interesting for small embedded devices that may be 
> limited processing or display capabilities.

Yup.

> I would prefer having them common 
> to all video codecs, but it does not seem to be the way things are going.

If I use the same names they'll be the same for 2 formats, if a third
person will use them for another codec we'll be 3, that's the design
decision I took when writing vorbis and theora: keep things as common as
possible.

> So I think it's up to you to decide such paremeters to theora draft, but I at 

No, I'm polling people for comments because MY specific purpose (having
vorbis and theora over rtp supported in media players) isn't the only
one, I have no pretenses to know what's better for my application, let
alone other different ones =)

> least recommend you to keep them:
> - optional

Agree

> - as receiver options (to allow asymetric operations)

Sure

So far what we could add are parameters to describe some limits,
possibly ripped from other generic rfcs:

- max number of frames in a packet
- decoding limits (fps, size, complexity...)

Anybody thinks that is valuable or that we could just avoid them and
hopefully wait for (write?) a generic rfc that describes them?

lu

PS: I'm still trying to push the changes suggested by Colin in a
consistent way, help proofreading and/or suggesting changes (using diff)
would be quite well accepted =)

-- 

Luca Barbato

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