<br><br><div class="gmail_quote">On Tue, May 11, 2010 at 4:42 PM, Jeremy Noring <span dir="ltr"><<a href="mailto:jnoring@logitech.com">jnoring@logitech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Fri, May 7, 2010 at 9:28 AM, Jeremy Noring <span dir="ltr"><<a href="mailto:jnoring@logitech.com" target="_blank">jnoring@logitech.com</a>></span> wrote:<br></div></div><div class="gmail_quote">
<div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Fri, Apr 30, 2010 at 4:19 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
It would be nice to find a simple, repeatable sequence of client operations that cause the crash. E.g., does crash ever happen if there are two complete "DESCRIBE, SETUP, SETUP, PLAY, TEARDOWN" sequences in order (i.e., not overlapping), or does it occur only when two such sequences overlap? Once you've found a repeatable situation that causes the crash, then you could also test with RTP-over-UDP, and with "reuseFirstSource" set to False.</blockquote>
</div></div></blockquote></div></div></div></blockquote><div><br>Okay, I've now managed to reproduce this with openRTSP and testOnDemandRTSPServer (which is what our RTSP server is modeled after). To reproduce it, you need to:<br>
<br>1. Have your RTSP server deliver a media session with multiple subsessions. (i.e. simply trying to reproduce with mp3AudioTest will not work; you have to have a session with audio _and_ video, for example). I simply combined the .wav and .mp3 sessions into one:<br>
<br> {<br> char const* streamName = "mp3AudioTest";<br> char const* inputFileName = "test.mp3";<br> ServerMediaSession* sms<br> = ServerMediaSession::createNew(*env, streamName, streamName,<br>
descriptionString);<br> Boolean useADUs = False;<br> Interleaving* interleaving = NULL;<br>#ifdef STREAM_USING_ADUS<br> useADUs = True;<br>#ifdef INTERLEAVE_ADUS<br> unsigned char interleaveCycle[] = {0,2,1,3}; // or choose your own...<br>
unsigned const interleaveCycleSize<br> = (sizeof interleaveCycle)/(sizeof (unsigned char));<br> interleaving = new Interleaving(interleaveCycleSize, interleaveCycle);<br>#endif<br>#endif<br> sms->addSubsession(MP3AudioFileServerMediaSubsession<br>
::createNew(*env, inputFileName, reuseFirstSource,<br> useADUs, interleaving));<br><br> // To convert 16-bit PCM data to 8-bit u-law, prior to streaming,<br> // change the following to True:<br>
inputFileName = "test.wav";<br> Boolean convertToULaw = False;<br> sms->addSubsession(WAVAudioFileServerMediaSubsession<br> ::createNew(*env, inputFileName, reuseFirstSource, convertToULaw));<br>
<br> rtspServer->addServerMediaSession(sms);<br><br> announceStream(rtspServer, sms, streamName, inputFileName);<br> }<br><br>2. Set reuseFirstSource to True<br><br>3. Run multiple openRTSP instances to repeatedly hit the RTSP server streaming with TCP. I use "openRTSP -t -d 1 url", and have a small program that calls that repeatedly.<br>
<br>Next, I'm going to isolate if this is regression in the codebase, or if it's something that was a problem before the recent RTP-over-TCP changes.<br><br></div></div><br>