Is there any consistent way for a client to know that authentication has
failed? It needs to know this so it can prompt the user for their
login/password. I've been looking at the RTSPClient.cpp code, but I can't
see any consistent way that it reports an authentication failure.
This is somethi
I still believe that a BYE message should be sent from the server
when the client initiates the session ending via a TEARDOWN (or
other such) message.
Maybe, but in practice I don't think this matters one iota. If the
client sends a "TEARDOWN", it is because it has asked the stream to
end.
Hi, does the current release of live555 support Transport Stream with H264 encapsulation?
Yes. (However, indexing and 'trick play' support on such files are
not yet supported.)
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live
Is there any consistent way for a client to know that authentication has
failed? It needs to know this so it can prompt the user for their
login/password. I've been looking at the RTSPClient.cpp code, but I can't
see any consistent way that it reports an authentication failure.
thanks,
patbo
Hi, does the current release of live555 support Transport Stream with H264
encapsulation? Do we need to change live555 to do this, instead of writing
codes cleanly on top of live555? Thanks -- Joe___
live-devel mailing list
live-devel@lists.live555.com
Matt Schuckmann wrote:
Furthermore I'd be very suspicious of even doing what is suggested in
in the FAQ.
I know of at least one place in the code where things could go very
wrong:
The RTPInterface.cpp code uses 2 static hash tables when using RTP
over TCP. Should you run 2 separate threads o
I'm highly suspicious of running live555 in multiple threads even if you
do follow the FAQ.
The FAQ basically suggests that you can run 2 independent copies of
Live555 in separate threads and those 2 copies can *NOT* interact except
via global variables. I don't know for sure but I don't think t
You have inadvertently pointed out something we missed and that is how
you *intended* the server should force a shutdown of an active session
or a live feed. We had been simply destroying the RTSPClientSession
which is what happens when a TEARDOWN message has been received. And
this is how I di
Did you actually read what I said: it's in the line you quoted below
When the *TEARDOWN* message is sent by the client to the server and the
server is shutting down the session the server does not successfully
send a BYE message and it appears that it should. This *is* the behavior
is regardles
I think that SO_REAUSEPORT will continue introducing problems cause
we need to force a port when creating a socket for the RTCP channel
(RTP port + 1).
That's why the new code won't be choosing port numbers explicitly
(or, as you say 'forcing a port').
Once again, stay tuned...
--
Ross Finl
Hello Ross,
I was hoping to get an answer on the implementation below so we can
try and figure out why we cannot get the data into live555.
Thank you
Austin
Begin forwarded message:
From: "Austin Snow (pftv)"
Date: March 10, 2009 2:23:21 PM EDT
To: Post-Live555
Subject: [Live-devel] Live
I've been testing this and the problem isn't SO_REUSEPORT (indeed we
aren't setting this option).
Instead, the problem is the SO_REUSEADDR socket option ...
Guido Marelli wrote:
Hi,
I think that SO_REAUSEPORT will continue introducing problems cause we
need to force a port when creating a so
Regarding packet loss: It's important to understand that because a
LIVE555 application runs as a single thread, never writing to, or
reading from, sockets concurrently, then if packet loss occurs, then
it *must* be happening either (i) on the network, or (ii) in the
operating system of the send
I'm pretty sure that this would happen with unmodified code, just
see if your bye handler is called in OpenRTSP after sending or a
teardown message while the source is still playing.
It is, *provided that* the original source file does not have a known
duration. When streaming from a live sou
14 matches
Mail list logo
