On 14 maj 2014, at 19:05, Ross Finlayson wrote:
>> One thing I did notice however that causes testOnDemandRTSPServer to freeze
>> is to do like this:
>>
>> 1. start testOnDemandRTSPServer and stream something (in my case a H264 file)
>> 2. start openRTSP #1 against the server
>> 3. start openR
> One thing I did notice however that causes testOnDemandRTSPServer to freeze
> is to do like this:
>
> 1. start testOnDemandRTSPServer and stream something (in my case a H264 file)
> 2. start openRTSP #1 against the server
> 3. start openRTSP #2 against the server
> 4. suspend #1 through C-z to
On 7 maj 2014, at 21:28, Ross Finlayson wrote:
>> Based on what I see it seems as if Live555 does not properly clean up the
>> first session when the
>> connection breaks. Instead it seems to close the wrong connection when the
>> time out occurs.
>
> No, based on your description I'm not see
> My own subclasses are very shallow and I can not see what else (apart from
> isSSM) that could have any effect
> on this. Nothing deadlocks in my code. What happens is that the wrong stream
> gets cut off.
If that's the case, then you should be able to verify this using
openRTSP -t
and
On 7 maj 2014, at 21:28, Ross Finlayson wrote:
>> Based on what I see it seems as if Live555 does not properly clean up the
>> first session when the
>> connection breaks. Instead it seems to close the wrong connection when the
>> time out occurs.
>
> No, based on your description I'm not see
> Based on what I see it seems as if Live555 does not properly clean up the
> first session when the
> connection breaks. Instead it seems to close the wrong connection when the
> time out occurs.
No, based on your description I'm not seeing any incorrect server behavior.
The server is timing
On 6 maj 2014, at 23:35, Jan Ekholm wrote:
>
> On 6 maj 2014, at 23:07, Ross Finlayson wrote:
>
>> Once again:
>>
In fact, I suggest that you first run the (unmodified!)
"testOnDemandRTSPServer" application, using "testRTSPClient" or "openRTSP"
as a client. Verify that this
On 6 maj 2014, at 23:07, Ross Finlayson wrote:
> Once again:
>
>>> In fact, I suggest that you first run the (unmodified!)
>>> "testOnDemandRTSPServer" application, using "testRTSPClient" or "openRTSP"
>>> as a client. Verify that this combination works OK.
It does, once I got rid of isSSM.
On 6 maj 2014, at 22:28, Ross Finlayson wrote:
>> The code I based my code on was for PassiveServerMediaSubsession which uses
>> SSM.
>
> That's your problem. If you are streaming via unicast, then you shouldn't be
> using any of the "test*Streamer.cpp" applications as a model. You need to
Once again:
>> In fact, I suggest that you first run the (unmodified!)
>> "testOnDemandRTSPServer" application, using "testRTSPClient" or "openRTSP"
>> as a client. Verify that this combination works OK.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_
> The code I based my code on was for PassiveServerMediaSubsession which uses
> SSM.
That's your problem. If you are streaming via unicast, then you shouldn't be
using any of the "test*Streamer.cpp" applications as a model. You need to
start again from the beginning, using "testOnDemandRTSPSe
On 6 maj 2014, at 20:40, Ross Finlayson wrote:
>> Testing with:
>>
>> ./testRTSPClient rtsp://192.168.1.12:8554/camera0
>>
>> it seems to work ok until the 65 second timeout occurs on the server side.
>> Perhaps it does not handle the
>> needed RTSP conversation? Same happens with ./open
>> I also now see that the server always streams over TCP
>
> No, you're mistaken about this (unless you've modified the "RTSPServer.cpp"
> code, in which case you can't expect any support on this mailing list).
> "testRTSPClient" (unless modified) always requests RTP/RTCP-over-UDP
> streaming
> Testing with:
>
> ./testRTSPClient rtsp://192.168.1.12:8554/camera0
>
> it seems to work ok until the 65 second timeout occurs on the server side.
> Perhaps it does not handle the
> needed RTSP conversation? Same happens with ./openRTSP. I see from my server
> logs that the camera
> I s
On 3 maj 2014, at 00:35, Ross Finlayson wrote:
>> I have a case where I develop both the RTSP server (based on Live555)
>> and the client (based on libav).
>
> Why not use our library for your client as well (and use "libav" just for the
> decoding)? I wouldn't be surprised if "libav's" imple
On 3 maj 2014, at 00:35, Ross Finlayson wrote:
>> I have a case where I develop both the RTSP server (based on Live555)
>> and the client (based on libav).
>
> Why not use our library for your client as well (and use "libav" just for the
> decoding)? I wouldn't be surprised if "libav's" imple
> I have a case where I develop both the RTSP server (based on Live555)
> and the client (based on libav).
Why not use our library for your client as well (and use "libav" just for the
decoding)? I wouldn't be surprised if "libav's" implementation of
RTSP/RTP/RTCP were imperfect. (E.g., if it
Hi,
>From what I can see there is no way to get some form of logging or debug info
>out
from Live555? I have a case where I develop both the RTSP server (based on
Live555)
and the client (based on libav). I'm trying to track down a problem where my
client
application randomly after 5-120 secon
18 matches
Mail list logo
