Hi Ross,
I don't need SDP/RTP/RTCP features in the RTSP server. What would be the best
way to turn those features off gracefully? I would like to be able to only
setup and teardown an RTSP session.
Thanks.
___
live-devel mailing list
live-devel@lists.l
Aww.. i was hoping for a really easy way out =)
I was trying to avoid queuing incoming data.
Thanks for the suggestions. I'll probably go the watchVariable route..
-Chad
Ross Finlayson
>I'd like to just call doGetNextFrame() at my own pace when I have data
>ready for it.
No, "getNextFrame()" (and thus "doGetNextFrame()") must be called by
the downstream object, when it is willing to receive data - i.e., the
'pull' model.
What you can do, however, is arrange to call your "deli
Hi everybody,
I'm writing my own framed MPEG DeviceSource. I would like to be able to
Push MPEG data rather than have scheduled (Pull) data queries.
Currently my code looks something like:
void DeviceSource::doGetNextFrame()
{
if( available )
deliverFrame();
else
>For test the new function , I needed to send a "PLAYING" again after
>the first "PLAYING"
You mean "PLAY", of course...
>but, UDP have data loss. therefore, I try to use TCP.
You have run into a known limitation of the current RTSP server code.
If RTP-over-TCP streaming is used, then the serv
Dear live555 Friends,
I am trying to modify the Live555 streaming server (testOnDemandRTSPServer.exe)
with some added functions.
After function added, i am using the OPENRTSP to do the tests.
For test the new function , I needed to send a "PLAYING" again after the first
"PLAYING"
Therefo
As you've noted/realized, any packet loss - other than network packet
loss - that occurs in a system that uses our code *must* be the fault
of insufficient buffering inside the OS. I.e., this is an OS
problem, and any fix/workaround needs to address this.
Unfortunately there is no good way fo
Hi Ross, hi Nitin,
I am also experimenting packet lost or malformed packets when I use high
bitrate clips and rtp over tcp streaming transport.
When I turn on the DEBUG mode, I noticed that sendRTPoverTCP generally returns
"failed" status. The errno is set to EAGAIN (or EWOULDBLOCK)
and is not
Hi Ross,
Thanks for the reply. We further debug this issue and trace the problem to
**
Line100 :- makeSocketNonBlocking(fGS->socketNum()) in RTPInterface.cpp file.
**
