List Info

Thread: Re: video




Re: video
user name
2007-09-06 07:11:04
Hi,

On 9/6/07, Patryk Czerwonko <patryk.czerwonkocomarch.com> wrote:
> I almost implemented video(windows) in
SipXtapi-media-update. I added h.263
> codec instead of h.264 because h.264 (FFMpeg) has only
decoding on LGPL,
> encoding is on GPL licence because FFMpeg uses x264 to
encode. I will be
> ready to commit changes next week but I don't have
subversion account. Maybe
> someone help me.

I'm sorry, I have not coordinated your effort and gave no
pointers to ongoing
work. Trying to redress this error now.

As Andrzej Ciarkowski already wrote, he was working actively
on video support
last weeks too and his patches were accepted and commited
to
media-update branch. He contributed a good piece of code for
grabbing
video under Windows (with DirectShow) and some other fixes
and
improvements for video related code. He's doing a good job,
but I believe
that two heads are better then one. So, I hope you'll be
able to collaborate and
join your forces, as it may greatly speed up the overall
process.

Sure, it would be interesting to see your patches,
especially for H.263 codec.
For patches to be commited to svn, they should pass review
for overall
quality of code and for coding style conformance. If your
patches will pass
the review, I'll be glad to commit them. For codec change
from H.264 to H.263
I'll also add that this should be done in configurable way.
We should be able
to change codec *at least* at compilatrion time, better at
runtime, sure. Hence
it shold at least not break existing code.

Here I'll enumerate task for further improvement of video
related code:

1) Merge all video related code to sipXtapi branch. Right
now sipXtapi branch
is far more advanced internally then media-update branch and
it further evolve
from day to day. If we want video support in sipXtapi to be
maintained
in constant way we should merge this code to sipXtapi
branch. This may be
done by backporting sipXtapi changes to media-update branch
(svnmerge
is already set up on it) or vice versa - taking media-update
branch changes
to sipXtapi branch. I'm not sure which way is
better/faster.

2) Generalization of sipXmediaLib video part - right now it
is implemented in
hardwired way. Ideally it should be changed to be more like
audio part,
where all audio processing is done by so called
"processing resources",
wired together in configurable way. Also such things as
video codecs should
be done configurable, so it would be possible to change them
runtime,
add new video codecs and so on.

3) Support for video conferences should be added. Right now
I believe only
peer-to-peer calls are supported, because video parts are
hard wired and
it is not possible to add more connections to the call
flowgraph.

It's only main things to mention, each of which may be
splitted to many
small subtasks. We're waiting for your contributions to make
all this real.
I believe with the help of community we'll make sipXtapi the
greatest SIP
library over the world!

-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
_______________________________________________
sipxtapi-dev mailing list
sipxtapi-devlist.sipfoundry.org
List Archive: http
://list.sipfoundry.org/archive/sipxtapi-dev/

[1]

about | contact  Other archives ( Real Estate discussion Medical topics )