> The stream will freeze after a few minutes. When the stream is opened
> directly, it does not freeze:
>
> ./testProgs/testRTSPClient rtsp://86.146.236.49/media/video1
Sorry, but I can't access this stream.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
__
With version 2012.12.24, live555ProxyServer can proxy Sony, Vivotek, Axis
and other IP cameras, but after upgrading to 2013.01.25 or newer (tried
with 2013.04.01 also), the proxy freezes with all of the above IP cameras.
I have made a stream publicly available, to reproduce, run:
./proxyServer/li
> OK, then I think my mistake is to presume those timestamps are adjusted for
> the server's timezone settings. In fact, they must be UTC values, with no
> way to determine the timezone they originated from. In retrospect - duh,
> that's how you'd expect timestamps to work, and that's probably
OK, then I think my mistake is to presume those timestamps are adjusted for
the server's timezone settings. In fact, they must be UTC values, with no
way to determine the timezone they originated from. In retrospect - duh,
that's how you'd expect timestamps to work, and that's probably already
do
I deal with security cameras and over time, the resolutions have been getting
higher.
They love to crank up the quality and resolution to give users that initial:
"Wow this camera has a nice picture"
But our customers are bandwidth sensitive and the first thing we have to do is
change the setti
As long as the object that you feed to your "H264VideoRTPSink" is a
"H264VideoStreamFramer" - or a subclass thereof - everything should work OK.
But rather than writing your own subclass of "H264VideoStreamFramer", why not
just use the "H264VideoStreamDiscreteFramer" subclass that we have alread
I concur; IP cameras are supporting higher and higher resolutions, and their
maximum encoded frame size (particularly for I-frames) naturally increases in
proportion. This can be mitigated by using H.264 slices but not many of them
seem to do so.
That’s not necessarily a reason to increase t
Thanks for the quick answer. I have to add that I have not changed a
single line of code in the source code, so I don't get it ? My previous
code was working because I implemented the same Boolean function that
returns the "isCurrentNALUnitEndsAU" so the type cast was working anyway.
But now tha
> I recently updated to the latest version of the library (March 23rd 2013
> version) but I came across a new issue with H264VideoRTPSink. In the
> function doSpecialFrameHandling there is "specific" type cast of the frame
> source to H264VideoStreamFramer
>
That's correct. That code has been
Hi there,
I recently updated to the latest version of the library (March 23rd 2013
version) but I came across a new issue with H264VideoRTPSink. In the
function doSpecialFrameHandling there is "specific" type cast of the frame
source to H264VideoStreamFramer but since my source is not this clas
> I have query regarding .aac audio file. In testprogs/ directory we have
> executable file for every type of format(like .mpeg4, .h264, .mpeg1or2 etc)
> but not for .aac(or we can say ADTS format) , streaming this format is only
> given through testOndemandRTSPserver .why?
Simply because
Hi,
I have query regarding .aac audio file. In testprogs/ directory we
have executable file for every type of format(like .mpeg4, .h264, .mpeg1or2
etc) but not for .aac(or we can say ADTS format) , streaming this format is
only given through testOndemandRTSPserver .why? is it not possible to
s
This unfortunately seems more common than not. I have several Axis,
Vivotek, Sony, ACTi, D-Link, Lilin and Chinese no brand cameras and they
are all generating ridiculously large frames :(
Maybe the value can be an argument option without having to recompile? - Or
maybe it can be larger but still
> I had been going under the assumption that I could interpret the presentation
> times in terms of the server's wallclock. I just realized that, in fact,
> presentation time appears to have been converted to the client's local time
No. The received frames' presentation times (once they've bee
14 matches
Mail list logo
