I don't understand why you have the variation between the first and
subsequent calls, but I have looked into a similar problem recently.
Making calls via SimpleOpal to a Polycom ViaVideo I noticed that the
frame rate received by the polycom was 15 fps.
The application that I am developing, based on SimpleOpal operates at 30
fps. It turns out this is directly related to the videoInput device.
SimpleOpal uses a VFW input device and regardless of what I set it to,
it seems to give me 15 fps. This, I'm assuming is a limitation of the
VFW device.
On the other hand, I've derived my videoInputDevice from the
PVideoInputDeviceClass directly. In the constructor for my video input
device, I can set the frame rate to 10 fps, or 30 fps (both of these
I've verified) and that's what's actually received at the far end.
So, in my opinion if the frame rate at your encoder is varying, the
place to look is in the code for your grabber (videoInputDevice).
There's probably a Sleep or usleep down at that level that reflects what
it thinks the frame rate is.
Josh Mahonin wrote:
>Hi all,
>
>I'm having some problems with encoding at a consistent fps rate in my
>Opal/SIP app. My first call always runs at 10 frames per second,
>regardless of what I've told the camera and plugin to run at. It only
>ever runs at a custom rate on subsequent calls, despite passing the same
>options, and creating a new encoding thread each time. This error in
>fact is directly related to my previous issue of randomly losing RTP
>packets in video streams -- it was a symptom of sending 10 video frames
>(~ 50-100 packets) per second on the first call, and then two and a half
>times that value on calls after that. I fixed the symptom by alterting
>the functionality of the OpalMediaPatch, but there still appears to be
>an issue with rate control.
>
>My video input device is getting set to 24 frames per second, and using
>the MPEG plugin, I'm passing along an FPS value of 24, and a Frame Time
>value of 3750 ( = 90000 / 24 fps, I'll likely patch the mpeg plugin to
>just use the frame time convention, I'm not sure what I was thinking
>there...). The FPS value tells fmpeg what its encoding rate should be -
>I am aware of issues with ffmpeg's rate control, but I don't believe
>this is the case here. I'm also not even sure the Frame Time value is
>used for OpalPluginVideoMediaFormats. I'm calculating my FPS in-call by
>keeping track of the number of marker frames transmitted and dividing by
>call time -- there's a new patch in the patch manager that adds marker
>counting to the RTP session for anyone who wants to try it.
>
>As best as I can tell, the encoding thread will run as fast as the CPU
>will allow, although there is a Sleep() for 5 ms in
>OpalMediaPatch::Main(), as well as a PAdaptiveDelay::Delay() call in the
>V4L plugin on GetFrameData(). I've tried removing both the sleep and
>delays, and the first call will tend to transmit video at 10-15 fps,
>albeit consume large amounts of CPU. Subsequent video calls will then
>run at around their specified frame rates. If anybody has run into
>similar issues, I'd be interested in hearing from them. It seems like
>an application problem (it just might be), but there is nothing
>different about the way I talk to my camera or setup media formats,
>between my first call and calls after that - if there was, I'd likely be
>running into more problems than just rate control.
>
>Thanks,
>Josh
>
>
>
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Openh323-devel mailing list
>Openh323-devel@xxxxxxxxxxxxxxxxxxxxx
>https://lists.sourceforge.net/lists/listinfo/openh323-devel
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Openh323-devel mailing list
Openh323-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openh323-devel
[Open H.323]
[IETF SIP]
[Gnu Gatekeeper]
[Asterisk PBX]
[Fedora Linux]
[Gimp]
[Yosemite News]
[Yosemite Photos]
[Yosemite Campsites]
[ISDN Cause Codes]
