Hi, On 9/6/07, Patryk Czerwonko <[EMAIL PROTECTED]> 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 [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
