The first time BasicTaskScheduler::SingeStep is called the fReadSet,
fWriteSet, and fExceptionSet are all empty and select() returns an
error (WSAINVAL) and the code starting on line 86 of
BasicTaskScheduler.cpp (did I mention I'm on Windows) gets invoked
to create a dummySocket so that the err
Boolean continuePlaying(){/*CODE will come soon*/ return true;}
I'm not sure what your question is, but once your "MyMediaSink" class
should work once you implement the "continuePlaying()" function
(etc.). I suggest that you use the "FileSink" code as a model.
--
Ross Finlayson
Live
Some additional information:
I invoke open rtsp with "-i" and "-t" options and uncomment the code
where you create and use AviFileSink.
Von: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] Im Auftrag von Dmitrij Velkin
Gesendet: Mittwoch, 29. Juni 2011 16:2
Yes, the server code needs to be checking for the "Content-length"
header, if present (which it will be for "GET_PARAMETER" and
"SET_PARAMETER"). A fix will be coming...
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mai
Hi Ross,
I followed your advice and start to implement with openRTSP. I need data in
buffer and not in file and so i wrote little class to subclass MediaSink:
class MyMediaSink:public MediaSink
{
public:
MyMediaSink(UsageEnvironment &env):MediaSink(env){buffer = new
uint8_t();}
Looks like the problem is more insidious than I thought.
The way the code starting on line 422 of RTSPServer.cpp is written it
will always assume that the message is complete when it sees the first
double \r\n regardless if it's RTP over UDP or TCP.
However, if the whole message comes in at once
Looks like there is a bug in RTSPClientSession::handleRequestBytes()
when SET_PARAMETER is sent to the server while streaming RTP over TCP
and after the PLAY command has been issued. The problem is the code
starting on or about line 422 of RTSPServer.cpp assumes that the the
message is complete
Ok here's what it looks like is happening.
I'm initializing the TaskScheduler, the usageEnvironment, and my
RTSPClient instance and then calling TaskSchedular::doEvenLoop() without
having initiated any RTSP connection (I've been doing that later after
the fact via an outside signal).
The firs
I just updated my code to use the latest Live555 code and I imeadiately
noticed that my RTSP client application is spinning on the processor and
taking up 100% of the processor it's running on. I tried running
OpenRTSP against the same server and I don't the problem. The main
difference between
