Re: [Live-devel] Detecting network failure
Previously I was watching RTPOverTCP_OK to determine when there was a
failure in TCP streaming, but that's since been removed. How can I
determine when streaming has ceased because the network has failed (my
internet connection goes down, for example)?
In particular, I need to do this with a DarwinInjector instance.
Previously I'd check the status of RTPOverTCP_OK every 500 msec; what
options do I now have to determine if streaming is failing?
Thanks,
Jeremy
Hi Jeremy,
When this happens do you, by chance, notice the CPU utilization go close
to 100% on your target?
I've seen this phenomenon when the client side closes an RTPOverTCP
connection in my RTP/RTSP/TCP/HTTP environment...VLC sends an RTCP BYTE,
and then closes the socket (it didn't send an RTSP TEARDOWN...can anyone
confirm that behavior??? is that correct/expected??? (I'm not sure
why it wouldn't send the TEARDOWN too)...
Anyway, as an experiment, I changed sendRTPOverTCP() helper function to
return the socket status return from send()and in sendPacket(), upon
a non-zero return from sendRTPOverTCP, I call removeStreamSocket().
In RTPInterface::sendPacket(...)
// Also, send over each of our TCP sockets:
for (tcpStreamRecord* streams = fTCPStreams; streams != NULL;
streams = streams-fNext) {
if (sendRTPOverTCP(packet, packetSize, streams-fStreamSocketNum,
streams-fStreamChannelId)) {
#ifdef DEBUG_RTP
fprintf(stderr, RTPInterface::sendRTPOverTCP()
failed...remoteStreamSocket %d, channelID %d\n,
streams-fStreamSocketNum, streams-fStreamChannelId);
#endif
removeStreamSocket(streams-fStreamSocketNum,
streams-fStreamChannelId);
}
}
Eventually, the server side will timeout the connection as the
liveness check fails, and all context, as far as I can tell, will be
intact...
This change will keep the tcpReadHandler() from calling select() (via
readSocket()-blockUntilReadable()) with a non-NULL timeout.tv_sec = 0,
which always returns 0 every time through the event loop...it also keeps
sendPacket from sending to a broken-pipe, for every packet...I'm
guessing the latter is the cause of the cpu utilization spike.
Without this change, I see the cpu utilization spike, until the liveness
check removes the session/socket, etc.
I haven't found any negative side effects to this change...and
performance seems more stable...
Randy
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
Hi Jeremy, When this happens do you, by chance, notice the CPU utilization go close to 100% on your target? I checked, and I don't experience this. Mostly, I just need a way of knowing that stuff is erroring out, but as far as I see, I don't get any feedback. The stream never times out (I'm using a DarwinInjector), none of the callbacks get fired (i.e. ByeHandler/AfterPlaying), etc. At this point I'm thinking I'll have to make code changes to make this work correctly, but maybe Ross will have some feedback. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
Hi Jeremy, When this happens do you, by chance, notice the CPU utilization go close to 100% on your target? I checked, and I don't experience this. Mostly, I just need a way of knowing that stuff is erroring out, but as far as I see, I don't get any feedback. The stream never times out (I'm using a DarwinInjector), none of the callbacks get fired (i.e. ByeHandler/AfterPlaying), etc. At this point I'm thinking I'll have to make code changes to make this work correctly, but maybe Ross will have some feedback. I just pulled the network cable on my setup (RTSPoverHTTP)...I get an EAGAIN returned from send() (as my TCP tunnel socket is non-blocking)... the TCP connection hasn't timed out...the Socket buffer just fills up... Do your send() calls fail inside sendRTPOverTCP() (with EAGAIN)? The current code checks, but doesn't return the status...it simply returns after the first failed call. Note, it is a void return from sendRTPOverTCP(), so you'd never know that data isn't making it down the stack (nor that the connection is broken). Note, I didn't conditionalize my error handling for specific errno returns...which I probably should have...and, it may be better to pass the status further up, to allow for error handling at a higher, more appropriate layer...Ross may have some ideas here (maybe a client provided error handler function could be used). In my case the send() call(s) fail with errno= broken-pipe once that connection gets closed by the peer...that is the clue upon which my experiment is triggering the cleanup (i.e. removing the socket). The status is returned at the same point that RTPOverTCP_OK would be set FALSE in previous releases of code...as you've pointed out before, that is a global, and doesn't work for multiple connections/streams...however, the returned status should. I believe both the RTP and RTCP sockets from the RTPInterface are non-blocking, so your behavior should be same (send() returns EAGAIN, after socket buffer fills up)...you could take action after some number of retry attempts on the send?? Randy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
Previously I was watching RTPOverTCP_OK to determine when there was a failure in TCP streaming, but that's since been removed. How can I determine when streaming has ceased because the network has failed (my internet connection goes down, for example)? You would detect this the same way that you would detect it for a UDP stream - e.g., because the server suddenly died. (There's no need for a special hack just for RTP-over-TCP streams.) E.g., you can periodically (i.e., using TaskScheduler::scheduleDelayedTask()) check that new data keeps arriving (into whatever object you're feeding from your RTPSource subclass). There's certainly no need to change any of the supplied LIVE555 Streaming Media code for this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
On Mon, Mar 22, 2010 at 11:43 AM, Roberts, Randy randy.robe...@flir.comwrote: Note, I didn’t conditionalize my error handling for specific errno returns…which I probably should have…and, it may be better to pass the status further up, to allow for error handling at a higher, more appropriate layer…Ross may have some ideas here (maybe a client provided error “handler” function could be used). This is basically what I'm looking for--I need the application layer to be informed when TCP communication has gone south so I can take appropriate action. It's not clear to me how to do this anymore. ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
On Mon, Mar 22, 2010 at 11:46 AM, Ross Finlayson finlay...@live555.comwrote: Previously I was watching RTPOverTCP_OK to determine when there was a failure in TCP streaming, but that's since been removed. How can I determine when streaming has ceased because the network has failed (my internet connection goes down, for example)? You would detect this the same way that you would detect it for a UDP stream - e.g., because the server suddenly died. (There's no need for a special hack just for RTP-over-TCP streams.) Okay--what is this same way you speak of? I've set breakpoints in every callback I could find, after my doEventLoop() call, etc. When I kill my internet connection mid-stream, I hit none of these breakpoints. I am using the DarwinInjector, if that changes anything. E.g., you can periodically (i.e., using TaskScheduler::scheduleDelayedTask()) check that new data keeps arriving (into whatever object you're feeding from your RTPSource subclass). There's certainly no need to change any of the supplied LIVE555 Streaming Media code for this.http://lists.live555.com/mailman/listinfo/live-devel This is code that is pushing AV to a server online--unless I'm checking for RTCP stuff, data shouldn't be arriving, should it? ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] H.264 Streaming from Live H.264 source
Hi Developers,
I have requirement to create streaming in H.264 , i am receiving stream from
live source(in H.264 format) and i have to re-stream it to another ip/port.
for that i have edited openRTSP and added one more option for re-streaming and
added following code.
RTPSink* videoSink;
iter.reset();
{while((subsession = iter.next()) != NULL) //***Create our RTPsink
variables...// Create 'groupsocks' for RTP and RTCP:charconst*
destinationAddressStr = 10.69.169.149;constunsignedshortrtpPortNum =
;constunsignedshortrtcpPortNum = rtpPortNum+1;constunsignedcharttl = 7; //
low, in case routers don't admin scopedestinationAddress.s_addr =
our_inet_addr(destinationAddressStr);
Groupsock rtpGroupsock(*env, destinationAddress, rtpPort, ttl);
Groupsock rtcpGroupsock(*env, destinationAddress, rtcpPort, ttl);structin_addr
destinationAddress;constPort rtpPort(rtpPortNum);constPort
rtcpPort(rtcpPortNum);//Create our sink...videoSink =
H264VideoRTPSink::createNew(*env,
rtpGroupsock,subsession-rtpPayloadFormat(),subsession-fmtp_profile_level_id(),subsession-fmtp_spropparametersets());
*env
exit(1);
}if(videoSink == NULL){Unable to create sink
\n;//** subsession-sink =
videoSink;
subsession-sink-startPlaying(*(subsession-readSource()),subsessionAfterPlaying,subsession);
}
But i am unable to play stream , i am using VLC player.
Can anybody help me out,
for rtpPayloadFormat,profile_level_id,sprop_parameter_sets_str in
H264VideoRTPSink::createNew , i am putting whatever i am getting from live
source.
Thanks
Vikas Srivastava
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] make the live555 scheduler working together with other schedulers
Hi, which is the best way to make the live555 library work together with another library which has its own main scheduler (for example: qt), _without using threads_? I mean: qt has app.exec(), which doesn't return, and live555 has doEventLoop(), which doesn't return Of course I could write MyScheduler and then call singleStep(), which returns, instead of calling doEventLoop(), but in this case singleStep() would return only after the select() wait (and this would block the other library, meanwhile) thanks ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] information about sdp file suport in live555......!
Hello all, Am running live media server (vS2008) in my testing server It streams the files (which are in the current directory) well... But I wanted to know whether if it can use the sdp file generated by VLC and stream the corresponding file... This functionality works in Darwin Please do mention if it can happen in this also Because when I tested it, it didn't work Before this, I want to know whether sdp is supported or not..May be if there is any flag setting(if so,mention me).. Any help is highly appreciated... Thank you.. Harish ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] RTSPoverTCP TEARDOWN
Hi Ross, Is it by design that the RTSP Teardown message (from the client) never gets processed in the RTSPOverTCP server implementation, may in lieu of other mechanisms like the RTCP BYE, or just relying upon the liveness check to timeout the session? I can see the message is discarded because we are looking for only '$' in the tcpReadHandler()I'm just wondering if that is intentional or a side-effect... Thanks, Randy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] RTSPOverTCP race condition (temporary lockout)?
Hi Ross, I thought I should open a new thread for the RTSPOverTCP lockout issue that I've come across (from my response to Jeremy's message (subject: Detecting network failure)). I apologize for the detail here...if you have any suggestions/preferences for further communications, please advise. In case it helps, I've reproduced the CPU spike with RTPoverRTSP (as well as RTSPOverHTTP)...so, I'm fairly convinced it wasn't anything I've added for RTSPOverHTTP. My test case is to simply open a VLC RTPoverRTSP client session, and immediately close it... The only reason I added the return of the send() status was to allow recovery from (avoidance of) whatever cpu bound processing loop which may have been causing the cpu utilization spike (lockout). Anyway, I was pursuing the thought that it might have had to do with the special handling for RTPOverTCP streams in sendRTPOverTCP and/or the tcpReadHandler() upon connection reset by peer. A side question/concern, is that readSocket (and readSocketExact) always use recvfrom, even though, in this case, we are reading from stream sockets...therefore, the CONNECTION state will never be considered by the socket layer. If we used recv() we might get a connection reset by peer indicationno? The problem I had when I tried that theory out, is that select() always returns timeout so we never get to the recv() or recvfrom() calls... The lockup doesn't occur every time... When it doesn't lockup, readSocket() returns with result = -1, and errno indicates the 104 (Connection reset by peer)...and therefore the background readhandler gets turned off.. When it does lockup, I do NOT get that same indication... so, I'm suspicious that temporary lockout is a result of some race condition in the timing of receiving the (VLC) peer TCP disconnect and where we are in the processing of the interleaved message(s)... VLC sends the TEARDOWN (which we don't see because once we start the tcpReadHandler we are then *only* looking for RTCP messages, NOT any further RTSP messages like TEARDOWN or SET_PARAMETER (e.g. for keepalive...true??), sometimes (why only sometimes?) followed by the RTCP BYE, then it immediately (~100us later) closes the TCP connection. I think there may be a race there that causes some grief in the tcpReadHandler() processing...where, depending on where we're at in our interleaved packet handling when the TCP connection gets reset by the peer, we end up in a non-blocking, and non-exiting near infinite loop... Regarding the TEARDOWN, it would seem we might need a more stateful implementation of the interleaved stream parsing, no? Or, is it by design that we no longer process the TEARDOWN, because we SHOULD see the RTCP BYE, or will otherwise timeout the connection?? I think the problem case is where we are waiting for the next '$'...where we call readSocket() with a non-NULL timeout (all other calls to readsocket() (for the remaining portions of the exchange) use a NULL timeout so the select call will block... FWIW, In my testing, disconnecting the network doesn't cause the CPU spike...like the quick STOP of VLC did when I was testing RTSPOverHTTP... As I mentioned in my response to Jeremy, the client session will eventually be brought down via liveness check due to inactivity...however, my linux system gets pretty locked up until that expiry triggers... I appreciate any light you may be able to shine on this one. Randy ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] RTSPoverTCP TEARDOWN
Is it by design that the RTSP Teardown message (from the client) never gets processed in the RTSPOverTCP server implementation Are you using a recent version of the code?? This problem was definitely fixed in version 2010.03.14 -- Ross Finlayson Live Networks, Inc. http://www.live555.com/___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] RTSPOverHTTP
Would you be interested in pulling this back into your baseline?? Feel free to post a patch file (made against the most recent version of the code) to the mailing list. However, I don't know when I'll be working on this...___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] RTSPoverTCP TEARDOWN
Funny, I was just replying to myself...having noticed you'd answered my question in your code comments; // Begin by reading and discarding any characters that aren't '$'. // Any such characters are probably regular RTSP responses or // commands from the server. At present, we can't do anything with // these, because we have taken complete control of reading this socket. // (Later, fix) # So, no...I am using 2009.11.27... Does this new version, by chance, handle RTCP BYEs too? Have you put any further time/thought into RTSPOverHTTP? I'll of course look at code too...(and/or release notes?). Thanks again! Randy From: live-devel-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, March 22, 2010 5:12 PM To: LIVE555 Streaming Media - development use Subject: Re: [Live-devel] RTSPoverTCP TEARDOWN Is it by design that the RTSP Teardown message (from the client) never gets processed in the RTSPOverTCP server implementation Are you using a recent version of the code?? This problem was definitely fixed in version 2010.03.14 -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Detecting network failure
I've set breakpoints in every callback I could find, after my doEventLoop() call, etc. When I kill my internet connection mid-stream, I hit none of these breakpoints. OK, it sounds like you're blocking in your RTSP client ANNOUNCE operation. This will not be a problem in the upcoming RTSPClient restructuring (that will make all RTSP client operations asynchronous). I am using the DarwinInjector, if that changes anything. E.g., you can periodically (i.e., using TaskScheduler::scheduleDelayedTask()) check that new data keeps arriving (into whatever object you're feeding from your RTPSource subclass). There's certainly no need to change any of the supplied LIVE555 Streaming Media code for this.http://lists.live555.com/mailman/listinfo/live-devel This is code that is pushing AV to a server online--unless I'm checking for RTCP stuff, data shouldn't be arriving, should it? OK, so you would need to check for RTCP packets - assuming that Darwin sends them; I don't know whether it does. If so, you could do this using RTCPInstance::setRRHandler() (assuming that Darwin sends RTCP RR packets in response to ANNOUNCE data). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] make the live555 scheduler working together with other schedulers
My approach for this kind of stuff has been to put them in separate threads (I'd probably create a thread for Live555) and then just use some sort of thread safe communication for passing events and data between the 2, e.g. a socket or thread safe queue, etc. Matt S. On 3/22/2010 2:27 AM, Alberto Alberici wrote: Hi, which is the best way to make the live555 library work together with another library which has its own main scheduler (for example: qt), _without using threads_? I mean: qt has app.exec(), which doesn't return, and live555 has doEventLoop(), which doesn't return Of course I could write MyScheduler and then call singleStep(), which returns, instead of calling doEventLoop(), but in this case singleStep() would return only after the select() wait (and this would block the other library, meanwhile) thanks ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ___ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
[Live-devel] Form hang when running live555MediaServer
Dear Ross,
I am trying to use live555MediaServer.cpp as a server , I was successfully
compiled the code in VS2008. I use a main form to present the
live555MediaServer, there has a button which triggered the below functions:
public:
void startServer(){
TaskScheduler* scheduler = BasicTaskScheduler::createNew();
UsageEnvironment* env =
BasicUsageEnvironment::createNew(*scheduler);
UserAuthenticationDatabase* authDB = NULL;
RTSPServer* rtspServer;
portNumBits rtspServerPortNum = 554;
rtspServer = DynamicRTSPServer::createNew(*env,
rtspServerPortNum, authDB);
if (rtspServer == NULL) {
rtspServerPortNum = 8554;
rtspServer = DynamicRTSPServer::createNew(*env,
rtspServerPortNum, authDB);
}
env-taskScheduler().doEventLoop();
}
When the form is running, user click on the button in order to start the
server, it hangs. My question is, Is that a way to prevent the form being
hang while the server is running ?
Thanks in advance,
Steven Choong
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Re: [Live-devel] Form hang when running live555MediaServer
On Mon, Mar 22, 2010 at 6:30 PM, steven choong lovestoryho...@gmail.comwrote:
Dear Ross,
I am trying to use live555MediaServer.cpp as a server , I was successfully
compiled the code in VS2008. I use a main form to present the
live555MediaServer, there has a button which triggered the below functions:
public:
void startServer(){
TaskScheduler* scheduler = BasicTaskScheduler::createNew();
UsageEnvironment* env =
BasicUsageEnvironment::createNew(*scheduler);
UserAuthenticationDatabase* authDB = NULL;
RTSPServer* rtspServer;
portNumBits rtspServerPortNum = 554;
rtspServer = DynamicRTSPServer::createNew(*env,
rtspServerPortNum, authDB);
if (rtspServer == NULL) {
rtspServerPortNum = 8554;
rtspServer = DynamicRTSPServer::createNew(*env,
rtspServerPortNum, authDB);
}
env-taskScheduler().doEventLoop();
}
When the form is running, user click on the button in order to start the
server, it hangs. My question is, Is that a way to prevent the form being
hang while the server is running ?
Unless startServer is on a thread, your doEventLoop() call will block
indefinitely. You need to run Live555 on a dedicated thread. Running it on
the GUI thread is not an option. Read the FAQ section about threading if
you have questions.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
