List Info

Thread: ffmpeg H.263 and polycom
ffmpeg H.263 and polycom
country flaguser name
United States		 2007-10-03 13:23:29 

  


  

    Good Afternoon all,

    I am writing regarding another video issue I have encountered between SimpleOpal (Opal 2.2.4) linked with the ffmpeg codec library.  I have been sucessful linking the ffmpeg lib with the SimpleOpal application and have been able to place h.263 calls between SimpleOpal and several H.263 enabled endpoints.  


   However, I recently noticed an issue while sending H.263 to a Polycom viewstation.  The decoded h.263 stream, as displayed on the viewstation seems to freeze quite frequently, then starts up again.  


If I telnet into the Polycom unit during these calls, I see a message repeating over and over again:  


 




RTP: last eBit 2 plus new sBit 0 not equal 8! (instance 0)


 


I had run into this same issue awhile ago when placing H.261 calls to the same device.  I was able to fix this issue by preserving the state of the sbit between encoded frames.  With H.263, all of the encoding, including the rtp layer is done inside the the avcodec library.  


 


Am I correct in assuming this issue is caused by the Polycom not dealing with a bitstream that is not always bit aligned?   Examining several Ethereal traces of H.263 streams I notice that most if not all seem to have the sbit and the previous frame's ebit add up to 8.  The ffmpeg h.263 stream does not seem to do that. ; I know this is not required by rfc 2190, but it seems to be standard practice.  


 


Does anyone have workaround for this? ; Is perhaps the only answer to try to patch the ffmpeg code myself?  


 


Any feedback would be appreciated.


Thanks.



 

  

  
  
   
     
    

  

    Re:  ffmpeg H.263 and polycom
  


  

     country flaguser name
Japan		
     2007-10-07 09:36:56
  


  

    
Hi,

> However, I recently noticed an issue while sending
H.263 to a Polycom
> viewstation.  The decoded h.263 stream, as displayed
on
> the viewstation seems to freeze quite frequently, then
starts up
> again.  
> If I telnet into the Polycom unit during these calls, I
see a message
> repeating over and over again:  
> 
> RTP: last eBit 2 plus new sBit 0 not equal 8! (instance
0)

This is an unnecessary requirement from Polycom
ViewStation.

> I had run into this same issue awhile ago when placing
H.261 calls
> to the same device.  I was able to fix this issue by
preserving the
> state of the sbit between encoded frames.

Was that contribution uploaded to the OpenH323 
SourceForge patch manager?

> Am I correct in assuming this issue is caused by the
Polycom not
> dealing with a bitstream that is not always bit
aligned?

Yes.

> Does anyone have workaround for this?  Is perhaps the
only answer to
> try to patch the ffmpeg code myself?

Someone claimed to have done so about 5 months ago on this
mailing list, but I
fail to see his contribution in the patch manager.
You may have to do it yourself.

Regards,


       
____________________________________________________________
________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openh323-devel mailing list
Openh323-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openh323
-devel



  


  

    
  

  
  
   
     
    






 [1-2]











   
 





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