[Iaxclient-devel] [Asterisk-Dev] Re: video in iax2 spec

[Stefano Falsetto]

Alle 16:32, giovedì 7 luglio 2005, Steve Kann ha scritto:

> There's quite a few things you're talking about here -- much of this
> might be more appropriate for the iaxclient-devel list though:
Here we are! :-) 
I think will spend many time on this project, 'cause I think I will work on it 
for my thesis.

> First, the status of video in iaxclient right now:  What I have in there
> is really just some test code.  At best, what it will do is make an IAX2
> audio call, while at the same time, capturing, encoding, and perhaps
> decoding local video.  (I.e. it will display either the raw captured
> video, or the captured video after encoding and decoding).  
> It doesn't yet have any provision for sending video over the network, or
> receiving video from the network.
Yes, I've read the code invovled. At the moment I'm interested in ffmpeg use 
for H.264 codec. In the future I hope I will be able to do an H.324M gateway 
with iax client. So I'm very interested in deciding what policy to use for 
better transfer audio and video on the net. What problems must be studied?

> There's a few network things that need to be worked out before that's
> going to work well -- defining specifically what the packetization of
> video frames look like, how to send some out-of-band information that's
> necessary (like Theora codebooks, etc).
This means that you wants to add something like a signalling protocol that 
helps iax to mantain syncronism? 

> Also, in iaxclient itself, there's a bunch of things that need work.
> The present "PortVideo-SDL" stuff in there is rather inflexible, and
> doesn't have the functionality we need.   It's also GPL, and I'd much
> prefer to have something with a less restrictive license, because the
> GPL conflicts with the license for iLBC, for example, and precludes
> using other kinds of encumbered codecs, like H.264, etc.  So, we need to
> work on that whole issue.
I see you point. But... If we try to concentrate on "conceptual" problems 
about the encoding/decoding and network related, without be too "close" to 
the particular implementation of the camera interfaces? 
At the moment we're basically using v4l and SDL. I think that on the Internet 
we can found some implementation that fullfills your requirements, still 
using these two libraries. 
My idea is:
at the moment we will try to develop a "more complete" proof of code still 
using PortVideo-SDL, adding some networking code. When we will stabilize the 
requirements (and in what way it must be done), we will looking for a better 
capturing library.

What do you think?

[...]
> >./testcall -F 23 15 90000 352 288 -V -f iax_output.raw 127.0.0.1
> Yeah, the H264 stuff in there right now doesn't seem to work properly;
> I think all the other formats work though.
Mmmh.. I've used the ffmpeg library in version 0.4.9-pre1 and from CVS, but 
all codecs from 18 to 24, are giving the same wrong output.
If I'm not wrong, in display_video function, the v parameter can contain 
wheter raw data or decoded data. So the vodeoolay structure must be used in 
different ways...

> I'm not sure what happens if you try to use "-f" with vtestcall -- at
> best it would only do something for audio.  If you don't use "-f", then
> the normal audio layer will be used, and you'll get an audio call that
> works, along with the local video stuff as described above.
If you think it can be useful, i can send to you an attach with this file. 
It's not an audio file...
(I think) Due to the fact that I'm using asterisk and testcall on the same 
machine, if I run testcall without -f option it say me a bunch of:

PaHost_OpenStream: could not open /dev/dsp for O_RDONLY
PaHost_OpenStream: ERROR - result = -10000
PaHost_OpenStream: could not open /dev/dsp for O_RDWR
PaHost_OpenStream: ERROR - result = -10000
PaHost_OpenStream: could not open /dev/dsp for O_RDONLY
PaHost_OpenStream: ERROR - result = -10000
PortAudio error at opening separate input stream: Host error.

[...]
> I haven't done much work on it recently, but I plan to get back to it
> sometime soon, and would definitely make time to work with people who
> are interested in helping to move it forward..
:-) So we are at least in two!


P.S. Sorry for my english :-)

-- 
Cheers,
  Stefano Falsetto
  GNU Rot[t]Log maintainer
    http://www.gnu.org/software/rottlog