> I have cloned testRTSPClient.cpp (using a non modified version assuringly i
> get packets from the video stream appearing in debug), below is modified
> version of continueAfterSETUP
No, you're totally on the wrong track here. (For starters, the
"H264VideoRTPSink" class is used only by *serv
Hi
Have been trying to use your excellent library to connect up to a camera
that is streaming RTSP/H264 unicast from a source i have no control over. I
seem to heading in right direction but I am struggling with the last bit,
getting the frame from the library so i can display it to the screen.
In general you can't reliably expect RTSP - clients or server - to work behind
a NAT. (It can work for some kinds of NAT boxes, but if you find that it works
at all, then you can consider yourself lucky.)
However, you may be able to get RTP-over-TCP streaming to work. (To request
RTP-over-TCP
When I test live555 (version 2012.02.03)client witch is behind a NAT box, RTSP
commands have finished rightly, but client can not get any RTP data. (client
RTP port:63339 NAT port:23356)
My client RTP is over UDP.Since this live555 has add hole punching for client
behind a NAT, why it doesn??t
Try "Netem"
netem provides Network Emulation
functionality for testing protocols by emulating the properties of wide area
networks. The current version emulates variable delay, loss, duplication and
re-ordering.
If you run a current 2.6 distribution, (Fedora, OpenSuse, Gentoo, Debian,
Mandriva
> Line 73 in DelayQueue.hh throws a warning when compiling for macosx.
That's odd; it doesn't for me.
> I've temporarily surrounded it with but this may not be the cleanest fix:
>
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wconversion"
> Timeval(time_base_seconds seconds
While I doubt that - in practice - a compiler would generate incorrect code in
this case, I agree that it's a possibility unless we compile with
"-fno-strict-aliasing". But I don't want to do that, because it could make the
whole of the code less efficient. (And changing the Makefiles to compi
Ross,
Line 73 in DelayQueue.hh throws a warning when compiling for macosx.
include/DelayQueue.hh:73:41: Implicit conversion loses integer precision:
'time_base_seconds' (aka 'long') to '__darwin_suseconds_t' (aka 'int')
fTv.tv_usec = useconds;
tv_usec is of type __darwin_suseconds_t which is a
> I am encountering a problem while trying to connect a large number of clients
> to the live555 Media Server. I have a single script which executes
> testRTSPClient in the background every .25 seconds and connects to the server
> to play a stream. When the number of clients reaches around 255,
Hi,
I am encountering a problem while trying to connect a large number of clients
to the live555 Media Server. I have a single script which executes
testRTSPClient in the background every .25 seconds and connects to the server
to play a stream. When the number of clients reaches around 255, how
Regarding casting between dissimilar types:
> c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include -I.
> -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64
> -Wall -DBSD=1 MatroskaFileParser.cpp
> MatroskaFileParser.cpp: In member function Boolean
> MatroskaFi
> maybe I have found a bug!?!
>
> In the method
>
> void RTSPServer::RTSPClientConnection::setRTSPResponse(char const*
> responseStr)
> {
> snprintf((char*)fResponseBuffer, sizeof fResponseBuffer,
> "RTSP/1.0 %s\r\n"
> "CSeq: %s\r\n"
> "%s\r\n" ---> should be "%s"
Hi Ross,
maybe I have found a bug!?!
In the method
void RTSPServer::RTSPClientConnection::setRTSPResponse(char const*
responseStr)
{
snprintf((char*)fResponseBuffer, sizeof fResponseBuffer,
"RTSP/1.0 %s\r\n"
"CSeq: %s\r\n"
"%s\r\n" ---> should be "%s"
Thank you Ross,
I should at this point mention that I am using the DeviceSource template
you provided as a means to retreive "live" footage from a DVR device. I
am using the code on Windows, and am synchronizing access to the frame
queue using critical sections.
For this specific case, I am pas
14 matches
Mail list logo
