[Live-devel] Handling timeout in getNextFrame

Zaphod Beeblebrox beeblebrox at sighthound.com
Fri May 1 13:25:55 PDT 2015


Ross,




Thank you for clarification. I do see your point about aborting the client side right away (you were correct about this being a client app), however, considering other possible causes (temporary packet loss? some other momentary hiccup on the LAN?), I prefer to keep session closure (e.g.  OnClose being called, session is clearly gone), and inter-packet timeout separate. Thanks for confirming stopGettingFrames() will reset the state.




Apologies about the pseudonym -- used one of the internal aliases/nicknames without thinking much of it (trying to keep the various lists traffic aliased for easier filtering).




Best,

Markus Hahn

mhahn at sighthound.com


—
Sent from Mailbox

On Fri, May 1, 2015 at 2:58 PM, Ross Finlayson <finlayson at live555.com>
wrote:

>> Okay, let me try being more specific:
>> 
>> 1) The application streams RTSP H264 video. 
> By “streams”, do you mean transmits, or receives?
> If you mean “transmits”, then what is generating the H.264 video?  Is it coming from a file, or from a device (that the OS treats as a file)?
> If you mean “receives” (which, from the context, I think you do), then do the (unmodified!) “testRTSPClient” and “openRTSP” applications work OK for receiving this RTSP stream?
> You should begin by running the supplied “openRTSP” application:
> 	http://www.live555.com/openRTSP/ <http://www.live555.com/openRTSP/> 	(note, in particular, the “-D <maximum-inter-packet-gap>” option; you may find that useful)
> and the “testRTSPClient” demo application, and familiarize yourself with this code, before you dive into trying to write your own RTSP client.
> If a call to “getNextFrame()” does not return any data - i.e., the ‘after getting’ (“OnData”, in your example) function does not get called, then that simply means that the upstream object has stopped delivering data.  (If the upstream object has ‘closed', then the “OnClose” function will get called.)  In any case, you should never call “getNextFrame()” again until the ‘after getting’ function gets called (indicating the reception of data).  In fact, our code is deliberately set up to prevent this (if you try, you’ll get the "attempting to read more than once at the same time” error message).
> You *could*, if you wish, call “stopGettingFrames()”, and then call “getNextFrame()” again.  But what would be the point?  The upstream object stopped delivering data for a good reason (presumably because the RTSP server stopped sending data).  There’s no point in trying again (other than by tearing down the RTSP session, and creating a new one).
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> ps. I don’t take kindly to people using silly pseudonyms in a professional forum like this.  Why do you choose not to disclose your real name?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150501/cc3bca84/attachment.html>


More information about the live-devel mailing list