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
mh...@sighthound.com
—
Sent from Mailbox
On Fri, May 1, 2015 at 2:58 PM, Ross Finlayson <finlay...@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?
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
