[Live-devel] Limiting frame rate for a source

[Jan Ekholm]

On 22 apr 2014, at 23:20, Ross Finlayson <finlayson at live555.com> wrote:

>> I was hoping that there was some built in rate limitation that only caused doGetNextFrame()
>> to get called when a new frame was needed. 
> 
> No, it's the data source that decides when it delivers data.  There are two possible ways to do this:
> 
> If your data source class encodes and delivers a frame immediately when "doGetNextFrame()" is called, then presumably you are also setting "fDurationInMicroseconds" before you complete delivery to the downstream object (using "FramedSource::afterGetting()").  (If you are encoding/delivering a frame immediately, but *not* setting "fDurationInMicroseconds", then "fDurationInMicroseconds" is staying at its default value of 0, and you will be delivering frames as fast as you can generate them, which is bad :-)  In this case, to change the frame rate, just change the value of "fDurationInMicroseconds".

No, I do not set fDurationInMicroseconds, I did not even know about it. Based on my timing it does look like
the frames are sent as fast as they can be grabbed, scaled and encoded to JPEG. I assume that
fDurationInMicroseconds means the duration of that single frame and if set to the equivalent of, say,
1 second then doGetNextFrame() would be called once per second or so?

> If, however, you want your data source class to not encode/deliver a frame immediately, but instead wait for the encoder to make a new frame available, then - as you noted - the encoder will need to be a separate thread of control (so that you don't delay, waiting for the encoded frame to come available).  In this case you would implement your 'data source' class similar to the demo code that's in "DeviceSource.cpp".  Note that in this code's "doGetNextFrame()" implementation, if no frame is immediately available to be delivered, we return immediately (i.e., do not block).  Instead, we rely upon a separate thread of control (the encoder thread) later 'signaling' the availability of a new frame - e.g., using "TaskScheduler::triggerEvent()".  (Note that "triggerEvent()" is the *only* LIVE555 function that can be called from a non-LIVE555 event loop thread.)

I have used triggerEvent() successfully when I did try to run my own Boost based event loop. It did get too
messy though, but the events worked perfectly.

I think I prefer to handle the rate limitation using the first method and only complicate things if necessary.

Thank you for your explanation. I enjoy reading your answers on this mailing list, they are teaching
me a lot. 

-- 
Jan Ekholm
jan.ekholm at d-pointer.com