On 22 apr 2014, at 23:20, Ross Finlayson <finlay...@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.ekh...@d-pointer.com _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
