[Asterisk-Dev] video in iax2 spec

[Steve Kann]

On Apr 28, 2005, at 8:47 PM, Ben Lear wrote:
>
> I just wish to know *how* it is to work. And if there currently is no 
> *how*
> then work towards establishing one, before running off on a mini code 
> fest.

My "mini code fest" as you so eloquently put it, is basically in the 
"proof of concept" phase;  Presently, it uses this library called 
"PortVideoSDL" for capture (which isn't really stable, and I've needed 
to hack to get YUV from cameras to even have a chance at decent 
performance.  My idea is to get a skeleton of code together which I can 
use for experimentation and to define a proper API for what I need from 
a capture module, amongst other things.  At this point, the actual 
details of packetization aren't that important, as they're unlikely to 
be performance issues, and for most codecs, I think I can make a 
prototype by just stuffing the raw output from the encoders into 
frames, and playing it back;  At least, that seems to be working for me 
so far.   (Except for theora, of course).

Once I get to the point where I have a platform where I can get a video 
call amongst two or three boxes, I'll start refining the APIs, and look 
into the packetization.

>> So, yes, I am interested in making the payload formats the
>> same as RTP, such that you can have iaxclient go through
>> asterisk, and interoperate with RTP clients, but it's not
>> something _I_ need to have done; it's a service to the
>> community. I don't plan on doing any of the work in rtp.c,
>> chan_sip, or any of that stuff.
>
> Nor do I. However, I would like to establish how it will eventually 
> work and
> someone can write it down and we can go off on our merry ways and meet 
> up at
> some later stage; and everything being equal be able to crank up a 
> video
> conversation. now that would be cool :P


Perhaps, but if nobody is planning on actually doing the work, it's a 
big waste of time talking about it for months and years.   We can talk 
now, till we're blue in the face, and write it down (aren't we doing 
that now), and all we'll accomplish is to have some more stuff for 
people to read when they want to have the same conversation later?


>> I haven't settled on a codec that I'd like to use yet
>> (although I've written basic drivers for ffmpeg[with it's
>> subformats] and theora), but, theora, being unencumbered, is
>> a huge plus.
>
> To declare Theora "Unencumbered" is a higly debatable subject, though 
> really
> it matters not in this context.

Sure it is.   Very few things don't infringe on patents these days.  If 
you read (jutta's?) page, GSM audio is probably encumbered -- but it 
appears that it's not being enforced.   But, so is "swinging sideways 
on a swing", the peanut butter sandwich, and the combover.  (well, it 
looks like smuckers lost the claim on _all_ peanut butter 
sandwiches..).  The question is whether or not it is being enforced.  
Clearly, people using MPEG4 and H264 are getting sued over it, but 
nobody is being sued over Theora.  (It also appears that people aren't 
being sued over H.263 either, which is strange, because most of the 
MPEG4 patents probably cover it as well).

Here's a post from On2 with a honest evaluation of it's status:
http://lists.xiph.org/pipermail/theora-dev/2003-February/000435.html


>
>> The quality from theora is similar to
>> H.263/MPEG4, although the present library needs a lot of
>> optimization, as it's seems an order of magnitude slower than ffmpeg
>> at the moment.
>>
>> If anyone wants to contribute to the cause, we can certainly broaden
>> the goals.
>
> Get the spec sorted first, then I'm sure more people will be more 
> inclined
> to help out with the coding.

I doubt it, honestly -- I don't see a big line of people out there 
saying "hey, I'm just itching to work on videoconferencing support in 
asterisk and iaxclient -- if only there was a spec on packet framing!"  
I think developers will be more attracted by a prototype.

This isn't all to say that we ought not do specifications first, before 
there's real implementations all over the place, or at least do 
specifications alongside them.   It's a lot easier to write 
specifications when you have a reference implementation being developed 
alongside the text.

-SteveK