I have never said that "some of the restrictions placed by LGPL are not valid".
The LGPL license remains fully valid.
What I have said, however, is that I do not personally have an objection to
"LIVE555 Streaming Media" code being linked statically, especially within iOS
applications - which a
> I believe the operation should be performed at the logical level rather than
> bitwise:
> fCurrentPacketCompletesFrame = ((sBit != 0) && (bBit == 0)) || (eBit != 0);
Yes, you've discovered a bug (actually, a very old bug, because MPEG-1 or 2
video - especially with slices - is rarely used the
Hi Ross,
Just wanted some clarification on licensing obligations for
using Live555 Streaming Media library 2013 versions. I have read the
http://www.live555.com/liveMedia/#license and
http://www.live555.com/liveMedia/faq.html#copyright-and-license
pages to get a better understa
Hi,
While testing my application that uses Live555 for MPEG2 Video input ("MPV"), I
noticed MPEG1or2VideoRTPSource presents some slice data with the expected size,
but others are presented as individual 1384 bytes chunks, just like at the
network level.
Looking into the code, I see the follo
Hi,
As i can see - this is Samsung iPolis IP Camera - try to upgrade it to
latest firmware - should work well as it supports RTCP in new firmwares.
Marcin
WebCamera.pl
W dniu 2013-10-11 09:33, srimugu...@csa.iisc.ernet.in pisze:
Stream "rtsp://107.108.205.230:554/profile2/media.smp/";
video/H2
>> Stream "rtsp://107.108.205.230:554/profile2/media.smp/";
>> video/H264: Received 230 bytes. Presentation time: 1381472674.763904!
>
> One more thing: The "!" at the end of the presentation time indicates that
> it has not yet been synchronized via RTCP - i.e., the client has not yet
> recei
Hi Ross,
I have problems streaming live PCM audio. Audio comes either directly from
microphone (16-bit LE)
Sampling frequency is 8k, mono(1 channel).
I receive a buffer in the thread and use event trigger to signal my live555
thread.
I've created class based on DeviceSource that inherit from
Yes, you've discovered that the RTSP protocol often does not work across NAT.
To overcome this, either get rid of your NAT box, or else have your client
request RTP/RTCP-over-TCP. In the "testRTSPClient" demo application, you can
do this by changing line 229 of "testProgs/testRTSPClient.cpp" f
> Stream "rtsp://107.108.205.230:554/profile2/media.smp/";
> video/H264: Received 230 bytes. Presentation time: 1381472674.763904!
One more thing: The "!" at the end of the presentation time indicates that it
has not yet been synchronized via RTCP - i.e., the client has not yet received
a
> Isn't the testRTSPclient supposed to run infinitely?
The problem is not the RTSP client; the problem is the RTSP server (i.e., the
IP camera). For some reason it is sending back the "408" error response, and
closing the connection.
To see more clearly what is happening, please run "openRTSP"
10 matches
Mail list logo
