OK, thanks. Updated now.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Thanks (and special thanks for the detailed explanation in the comment that you
included with the patch).
I have just installed a new version (2012.09.12) of the "LIVE555 Streaming
Media" code that fixes this.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
The attached patch enables wis-streamer to work with current 3.x.x kernels.
- remove float_t because it's unused and conflicts with math.h
- in the Makefile put libliveMedia.a to the first place, otherwise
linking fails
- make search for the audio device compatible with the current sysfs paths
The attached patch enables MPlayer using librtsp to connect to the RTSP
server.
When running
mplayer rtsp://10.10.4.10/
then it sends the OPTIONS URL like this: OPTIONS rtsp://10.10.4.10:554
RTSP/1.0
note there's no trailing slash after the port and the current code fails
to parse it and
> One last question on this, as I'm in the middle of reorganizing the code.
> Shouldn't it be safe to create the rtspClient object in another thread?
Once again, NO! "RTSPClient" objects - like all subclasses of class "Medium" -
update shared data structures (stored within the "UsageEnvironment"
The code example below is called from an external thread. Is that ok
No - absolutely not!!! What you're trying to do - call
"TaskScheduler::scheduleDelayedTask()" from an external thread - is
extremely wrong!
Look folks, how many times do I have to say this: A LIVE555 application runs
as
Hi
We had the same problem, and we solved it by creating cbr ts files stuffed
with NULL packets.
The following thread shows the ffmpeg command parameters to create h.264
cbr files:
http://stackoverflow.com/questions/7125446/encoding-h-264-cbr-videos-with-ffmpeg
Mojtaba Nouri
Soroush HighTech Ltd.
On 9/10/2012 5:51 PM, Warren Young wrote:
If you take
a guess at the GOP length, you can infer frame rate.
I meant bit rate, obviously.
We've tried to get a CBR stream out of ffmpeg, just to prove to
ourselves that stream variability is the problem. We haven't succeeded.
Apparently ffmpeg
> I agree It seems unlikely that it would be stuck in recvfrom() following a
> successful select, but it does.
Well, if the "makeSocketNonBlocking()" function
("groupsock/GroupsockHelper.cpp", line 171) - which is called for all RTP/RTCP
and RTSP sockets - is not working for you, then you're go
I agree It seems unlikely that it would be stuck in recvfrom() following a
successful select, but it does. I have proven this with debugging.
I checked the windows docs and if the flags are not set correctly on socket
creation, the default will block forever. I am looking for where this socket
> The code example below is called from an external thread. Is that ok
No - absolutely not!!! What you're trying to do - call
"TaskScheduler::scheduleDelayedTask()" from an external thread - is extremely
wrong!
Look folks, how many times do I have to say this: A LIVE555 application runs as
Right now Live555 loop run in separate thread. The clean up function can be
called from the another thread
No! You cannot safely do this! Read the FAQ (that you were asked to do
before posting to this mailing list)!
Apart from "triggerEvent()" (see below), all calls to LIVE555 code *must*
> I have a problem with pulling RTSP streams that needs to be reliable. If the
> stream stops I have a watchdog that times out after 5 seconds and changes my
> watch variable so the event loop in basic task scheduler will exit.
>
> The problem is in one edge case, I have debugged found that the
I have a problem with pulling RTSP streams that needs to be reliable. If the
stream stops I have a watchdog that times out after 5 seconds and changes my
watch variable so the event loop in basic task scheduler will exit.
The problem is in one edge case, I have debugged found that the flag is n
> Thanks, ill do this.
> Is it safe to do the same (code posted above) from "event trigger" - access to
> hashtable and shutdown all the clients?
I didn't have time to look at your code in detail. However - as I noted in my
previous message - the function "shutdownStream()" in
"testProgs/testRT
> No! You cannot safely do this! Read the FAQ (that you were asked to do
before posting to this mailing list)!
>
> Apart from "triggerEvent()" (see below), all calls to LIVE555 code *must* be
done within the LIVE555 thread - e.g., from a LIVE555 event handler.
>
> Now, you may wish to signal t
> Right now Live555 loop run in separate thread. The clean up function can be
> called from the another thread
No! You cannot safely do this! Read the FAQ (that you were asked to do before
posting to this mailing list)!
Apart from "triggerEvent()" (see below), all calls to LIVE555 code *must*
Hello.
I am looking for safe code to terminate all active RTSPClient (and their
connections) without stopping main Live555 loop.
Right now Live555 loop run in separate thread. The clean up function can be
called from the another thread and looks like this:
void RTSPSession::cleanup()
{
18 matches
Mail list logo
