thank you. the problem was simply with Vlc playback.
with other players we don't have any issues (mediaPLayer classic or
ffplay).
i can mark this as closed.
thank you ,
giacomo
2015-05-18 20:56 GMT+02:00 Marcin :
> For me the problem is that you need to start recording on an I-Frame
> first. I
Groupsock uses result of UsageEnvironment::getResultMsg as argument to
UsageEnvironment::setResultMsg which results in corrupted message
(original message is getting lost).
---
groupsock/Groupsock.cpp | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
Stas Tsymbalov
TrueConf LL
---
groupsock/GroupsockHelper.cpp | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--
Stas Tsymbalov
TrueConf LLC
http://trueconf.com/
diff --git a/groupsock/GroupsockHelper.cpp b/groupsock/GroupsockHelper.cpp
index 8508919..5e36308 100644
--- a/groupsock/GroupsockHelper.cpp
+++ b
Sometimes it is desired to use presentation time already stored with
input frames. For example when data comes already split into frames (but
not NUL units) and if frame rate can't be determined from stream itself
or frames appear with irregular intervals or even skipped entirely.
This patch add o
Right now H264or5VideoStreamParser can return 0 from parse() without
requesting more data from input source which leads to frame
delivery process becomes stalled (as
MPEGVideoStreamFramer::continueReadProcessing()
does not call afterGetting() in this case either).
This can happen for several reas
Right now if for some reason one replica stops requesting frames from
replicator but dows not deactivates whole delivery process stops as
replicator patiently waits for this replica to request frames.
This patch adds optional frame delivery timeout to StreamReplicator
which functions as follows:
Right now if replica that than has not requested current frame gets
deactivated and by that moment all other replicas received current
frame replicator never completes delivery to master replica (which it
should now) and whole delivery process gets stuck until some other
replica requests current f
Right now if replica receives current frame and then deactivated before
replicator is advanced to next frame, logic which deceides when to
advance to the next frame gets broken (assertion on StreamReplicator.cpp:265
triggers and frame advances early).
This patch fixes this by decrementing fNumDeli
Right now removing last replica triggers (wrongly) assertion on
StreamReplicator.cpp:108, because fNumPerlicas gets decremented before
deactivating.
Also if replicator is created with deleteWhenLastReplicaDies flag set
removing last replica triggers self deletion of replicator and later
deactivat
Sorry, but our software does not include any media decoding, encoding, or
transcoding functionality.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/li
Hi Team,
I am so happy after looking into you website
http://www.live555.com/liveMedia/.
I need your team help to convert .h264 files into MP4 in iOS.
I have a bunch of .h264 files in amazon s3 cloud. When i call an api i get
the list of all the amazon s3 links into the app. I need to play those
Hi,
Another question (I am sorry if some things are naturally for you, but a
lot of stuff is new for me). I am using the proxy server of live555 and
another tool to register urls at the proxy server. Suppose there is an
requirement that urls can change dynamically, which means the new url
has
A PAUSE is fine for (most) cameras that treat it as stopping the live data, as
the RTSP spec suggests.
PLAY then carries on from the current point in time.
There are a handful of cameras that don’t support PAUSE though.
TEARDOWN closes the entire session and RTP streams meaning it needs to be
in
13 matches
Mail list logo
