>> I have now installed a new version (2016.09.05) of the “LIVE555 Streaming
>> Media” code that should, I believe, fix a problem (actually, one error and
>> one warning) that showed up in this log. I hope this helps!
> From my initial tests the Valgring error message seems to have been solved
> I have now installed a new version (2016.09.05) of the “LIVE555 Streaming
> Media” code that should, I believe, fix a problem (actually, one error and
> one warning) that showed up in this log. I hope this helps!
From my initial tests the Valgring error message seems to have been solved, I
Hi!
Following up this pending discussion:
http://lists.live555.com/pipermail/live-devel/2016-March/019977.html
> Another thing I suggest is running your code under ?valgrind?. If - as I
> suspect - the code is trying to access an object that has recently been
> deleted, then ?valgrind? may be
Hi Mark,
> I just read the rtcp.cpp and find a problem in multicast mode.
> In RTCPInstance::incomingReportHandler1(), from line 342
There's a report of a similar problem which is affecting me also.
You can see the symptoms here:
http://lists.live555.com/pipermail/live-devel/2011-May/013313.html
Hi Praya,
>> We have been facing this problem of live streaming stopping exactly after
>> half an hour.
>> The same code works on Linux OS but windows this issue is there.
> On further testing I noticed that the stream works for 35 minutes, stops for
> 35 minutes
> and again recovers after 35 m
> Do you have any insights what could be the problem here ?
> It seems to happen on different devices using live555 to stream
> h264 via RTSP. I use ARM based DM6467 and Bruno is running live555
> application on a PC.
My setup is the Ubuntu Server Linux 10.04 LTS.
I believe that system instabilit
> Unable to determine our source address: This computer has an invalid IP
> address: 0x0
I had this problem on my linux box when the live555 RTSP server is launched on
boot, more than one network interface is configured and one of them has a
dynamic IP served by a DHCP.
I don't know if this is
>> I'm streaming h264 via RTSP. The video is produced by
>> hardware encoder. In my code I use H264VideoStreamDiscreteFramer
>> class and event triggers to notify the streamer thread about
>> the availability of new h264 buffer.
> What is your video source ? Is it h264 or something else ?
My vide
Hi Felix,
I have a similar problem.
After 3 days playing I couldn't access the RTP/RTCP server PC anymore. Pinging
didn't work either. Only after a reboot everything is ok.
A few days later the same happened.
And now I discovered something even stranger:
I sniffed the network traffic going to an
Hi,
> now am not able to edit these programs , Tough all the headers are
> present in include folders am not able to compile the edited programs.
> i have pasted the errors here, Pls check and help me.
> [root at caserver testProgs]# g++ testMP3Streamer.cpp
> testMP3Streamer.cpp:20:24: liveMedia
> now am not able to edit these programs , Tough all the headers are
> present in include folders am not able to compile the edited programs.
> i have pasted the errors here, Pls check and help me.
> [root at caserver testProgs]# g++ testMP3Streamer.cpp
> testMP3Streamer.cpp:20:24: liveMedia.
Ross,
> I'm a bit puzzled by this, though for two reasons:
> 1/ You are not using a "MPEG2TransportStreamFramer" in front of your
> "MultiFramedRTPSink", so the latter should not be getting a
> "durationInMicroseconds" value other than 0.
> 2/ You are using a recent version of the code (because yo
Ross,
The time period between the stream stopping and consequent recover is exactly
35:47.50 with a variance less than 10 msecs and this goes forever.
Could you know any action that could be causing this behavior (so
deterministic) in my linux system?
In my previous post I think didn't understa
Ross,
Thank you for the fast feedback.
After doing some more tests it seems the video stream recovers from the
blocking after a call to AlarmHandler::handleTimeout().
Here's the stack trace:
H264VideoDiscreteFramer::doGetNextFrame() at H264VideoDiscreteFramer.cpp:35
0x804fbba
InputESSourceReco
Hi,
I'm using Live555 to send H.264 ES video over Transport Stream using
MPEG2TransportStreamFromESSource but the video stream blocks for >20 minutes in
every hour or so.
The goal is to deliver a live video stream using an H.264 video encoder as the
source, initial tests showed that Transport
15 matches
Mail list logo