Since the last email I have done more work on this issue and some real world tests. Firstly I have managed to get solve the problem with the video frame being transited through the Java heap. This was surprisingly easy, it involves the following steps:-
1. Add AVFrameFormat to the list of supported input codecs for the JAWTRenderer.
2. Alter the JAWTRender Java logic to pass the AVFrame pointer rather than the frame buffer
3. Add support for directly rendering the frame from the AVFrame structure to the native renderer dll.
This approach appears to achieve the aim of never converting the frame from its native representation until the point of blitting it to the screen while not breaking the existing architecture.
I am about to investigate a similar approach for the JNIEncoder which is still receiving a frame which has passed through the SwScaler.
As for performance the real world improvement is dramatic. Jitsi was previous only usable on the highest spec machines, on all other machines it was only reliable for audio only calls or very low definition video.
The patched Jitsi is however consistently outperforming the commercial SIP client that we have been using up until now. We are managing 720p @ 30fps on most configurations available to us. One machine required the configuration to be dropped to 640x480 but then an excellent quality call continued for several hours :).
The conclusion for us is that Jitsi is now a realistic replacement for the commercial product we have been using. We are now aiming to do 1080p as combined with decent conference microphones this allows "telepresence" without usual price tag :).
So I have two questions.
Question 1 - Call statistics
Somehow I have managed to disable the video information (jitter, packet loss and encodings) from being propagated to the call information panel.
If possible I would appreciate a quick pointer on how this information is propagated out from libjitsi. E.g. where I should start looking to fix this.
Question 2 - Patches/Contributing
We are very keen that our work can be integrated into the mainline Jitsi client. However it is clear that a great deal of care and attention has been gone into Jitsi and we do not want to "step on toes" by not understanding your design or having different development goals.
At present the changes are "unfinished" code but I would like to understand what the usual procedure is and how best we can facilitate getting the finished code included. Do you have a code standards document for example?
I should note that from our point of view the current nightly build and release version of Jitsi do not function well in regard to video calling on Windows except when conditions are excellent.
As a result I strongly believe that at least a partial solution should be considered for Jitsi 1.1 (or is it 2.0?). One suggestion is I can provide some direct support to one of the dev team regarding a quick fix either on IRC or phone.
James M. Martin
Director of Development
ESP Technologies Limited - Delivering Total IT Solutions to Government
Auburn House, Ard na Greine, Ennis, Co. Clare, Ireland
Phoenix Centre, Block 6, Broomhall Business Park,
Rathnew, Co. Wicklow, Ireland.
ESP Technologies Limited is registered with the Registrar of Companies, Dublin - No. 367933
Registered Address: Auburn House, Ard na Greine, Ennis, Co. Clare, Ireland
This email is intended for the addressees named above and any other use is prohibited. It may contain confidential information. If you received this email in error, please contact the sender by return email. ESP does not accept legal responsibility for the contents of this message if it has reached you via the Internet, as Internet communications are not secure. Any opinions expressed are those of the author and are not necessarily endorsed by ESP. All ESP communications are scanned for malware & virus infection using the latest anti-viral utilities.