There is one case where it doesn't work though, and I'm not sure how to
handle it. This is if I do a seek while the stream is disconnected, then it
never reconnects. In some cases I play a 10s loop where a timer do a seek
every 10s and jumps back (using absolute seeking). Those streams never
reconn
> I've therefore looked into how to best handle reconnection if the stream for
> any reason is disconnected. I noticed fairly quickly that liveMedia is taking
> care of that really good and there is no reason for me to try to implement
> any general disconnect handling, as I can't possible recon
Best possible uptime is essential for the RTSP client I'm implementing. I've
therefore looked into how to best handle reconnection if the stream for any
reason is disconnected. I noticed fairly quickly that liveMedia is taking
care of that really good and there is no reason for me to try to impleme
OK, thanks for the RTSP protocol trace that illustrates the problem.
I've changed my mind on this: I now think it should be relatively
straightforward to fix the RTSP client code so that it no longer sends out
these early RTCP 'RR' packets (when streaming RTP-over-TCP). This will be
better tha
> If I put the cursor before (let's say 30 minutes) , VLC plays it well and the
> streaming continues to be ok, even after 31:06.
>
> I suppose there is a trouble about seeking in the file when the time
> requested is above 31:06...
FYI, this bug should be fixed in the latest release (2012.08.
> This one is, I believe, an actual coding error, in the area of
> order-of-evaluation.
>
> In the macro GET_ENCODED_VAL, in VorbisAudioRTPSink.cpp on line 129 (in
> the 2012.089.30 release), there's a possibly unintended evaluation of the
> phrase:
>
> "n = n*128 + byte&0x7F;"
>
> I think, loo
> You are indeed correct: Program streams are a big "no-no" for any streaming
> situation, and I believe it's a testament to the robust, flexible design of
> the live555 library for it to recognize and correctly demux the stream.
> Unfortunately this is the constraint I have been given - we are
Good morning Ross,
You are indeed correct: Program streams are a big "no-no" for any
streaming situation, and I believe it's a testament to the robust,
flexible design of the live555 library for it to recognize and correctly
demux the stream. Unfortunately this is the constraint I have been give
