> I am experimenting with the testRTSPClient app to develop a DirectShow
> source filter to connect to a network camera outputting an H.264
> video stream. The app successfully connects to the camera and shows the
> following continuous output:
> ...
> Stream "rtsp://192.168.1.7:65534/videoSu
> I should have finished working through the advice in the FAQ - openRTSP
> successfully streamed from my cameras with the -t option, and setting the
> fourth argument of setupSubsession() to true fixed my problems.
>
> I also found that I did not need to specify the video resolution in order to
> Could this problem be related to another issue I’ve recently had with using
> proxy server with vlc as the back end server. The RTSP session timeout is
> hardcoded to 60 secs in VLC . The VLC RTSP server does support GET_PARAMETER
> and PAUSE as shown in OPTIONS. But when live555 proxy client
> I know you don’t like valgrind tool
I *do* like "valgrind". The problem with it, however, is that it frequently
reports 'errors' that aren't really errors.
Therefore, I generally don't pay attention when people send me "valgrind"
reports, unless they can also note a specific problem in the c
Ross,
Could this problem be related to another issue I've recently had with using
proxy server with vlc as the back end server. The RTSP session timeout is
hardcoded to 60 secs in VLC . The VLC RTSP server does support GET_PARAMETER
and PAUSE as shown in OPTIONS. But when live555 proxy client
Hi Ross,
I know you don't like valgrind tool, but it reports use of uninitialized memory
:
Conditional jump or move depends on uninitialised value(s)
(see: http://valgrind.org/docs/manual/mc-manual.html#mc-manual.uninitvals)
at 0x1036E23: RTCPInstance::enqueueReportBlock(
dicated (by a "Session:" header
> > "timeout" parameter in the "SETUP" response) that it wants to receive
> > periodic in-session "GET_PARAMETER" commands instead. (Some servers have
> > another bug whereby they don't use RTCP &qu
> I've compiled the latest version and unfortunately I'm seeing the exact same
> output as above, after about 2 and a half minutes of streaming, I see this:
>
> Sending request: GET_PARAMETER rtsp://86.162.35.136/axis-media/media.amp/
> RTSP/1.0
Oops, sorry - my mistake. My earlier 'fix' wasn'
> I've compiled the latest version and unfortunately I'm seeing the exact same
> output as above, after about 2 and a half minutes of streaming, I see this:
>
> Sending request: GET_PARAMETER rtsp://86.162.35.136/axis-media/media.amp/
> RTSP/1.0
You must not have upgraded properly. With the la
On 4 April 2013 10:16, Ross Finlayson wrote:
> I find this very difficult to believe - especially considering that nobody
> else has reported this problem.
>
I'm not sure what to say but GET_PARAMETER is causing problems with almost
all cameras I have here to test (excluding a Chinese no brand o
THANKS!!! For a VERY NICE library.
I am experimenting with the testRTSPClient app to develop a DirectShow
source filter to connect to a network camera outputting an H.264
video stream. The app successfully connects to the camera and shows the
following continuous output:
...
Stream "rtsp://
I should have finished working through the advice in the FAQ - openRTSP
successfully streamed from my cameras with the -t option, and setting the
fourth argument of setupSubsession() to true fixed my problems.
I also found that I did not need to specify the video resolution in order
to get a prope
12 matches
Mail list logo
