Deanna Earley | 26 Apr 10:34 2016
Picon

liveMedia repositories

Good morning all (or whatever time of day it is for you)

Firstly, I'm aware of the policy not to maintain any official source repositories or archived versions.

Unfortunately, many of us have much larger projects, and in many cases pull in external libraries.
At least in my case, I've found this easier when I can just "hg pull -U" with incremental updates whenever I
need to do a code update.
This also helps when upgrading old code as you can upgrade in steps, testing as you go.

As such, I have each released archive pulled into repository, and pushed to GitHub and Bitbucket (for git
and mercurial respectively).
https://github.com/DeeHants/liveMedia
https://bitbucket.org/earlsoft/livemedia

They include all the releases I could find back to 2004 (most of them from 2011 onwards), and are the full,
unmodified contents of the archives, less any temporary/debug files.

To be absolutely clear, these are unofficial mirrors and provided on a best effort basis.

Kind regards

--

-- 
Deanna Earley | Lead developer | icatchercctv

w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338
Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325
Eric_Hsieh | 26 Apr 09:00 2016

How to update SDPLines info?

Hi Ross,

Run rtsp server based on OnDemandServerMediaSubsession class.
We found the server will always return the same SDP into back to the rtsp client, even we update the NEW SDP
info when call createNewRTPSink. So, my question is, how to control live555 library update SDP info?
Thanks a lot.
This electronic mail transmission is intended only for the named recipient. It contains information
which may be privileged,confidential and exempt from disclosure under applicable law. Dissemination,
distribution, or copying of this communication by anyone other than the recipient or the recipient's
agent is strictly prohibited. If this electronic mail transmission is received in error, Please notify
us immediately and delete the message and all attachments of it from your computer system. Thank you for
your cooperation.
Ayuso, Fermin | 21 Apr 15:22 2016

Smaller MTU

Hi all,

 

I need some help.

 

I have a RTSP Server implementation working ok, based on testOnDemandRTSPServer.

Now, I want to apply this implementation in a network that has an smaller MTU than the standard one(MTU:1300).

Live555 is very smart, so the packets throw through this network are splitted in two parts, that’s perfect, but the second packet is small and causes that network has to deal with more packets.

In order to reduce the number of packets which my server sends through the net, I want to tell Live555 to reduce the size of the packets to fit into the smaller MTU.

 

I read that I can change it in MultiFramedRTPSink, but I don’t use this class in my code, so changing setPacketSizes doesn’t seem to change anything.

 

How can I do that?

 

Thanks for all.



Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation.
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Ben Rush | 19 Apr 22:32 2016
Picon

strange behavior with Android 5.0 lollipop media player

We've been using Live555 very successfully now for a while but have encountered a quirk that is likely due to a bug or oddity in the media player on Android 5.0 Lollipop. The problem is that it's becoming a bit of a showstopper for us (a major client is using this particular version of Android), and I'm wondering if there is possibly a way to work around the player's quirk. I know this is likely not considered a bug in Live555, but perhaps there's a quick setting in the server that can save us for the time being. 

It's easy to duplicate (at least on these phones). If you spin up Live555 and connect the phone's native MediaPlayer, everything works fine. However, if any client is already connected to the server, then the phones NEVER work. The stream never shows up. 

Investigating with Wireshark shows that the RTSP and RTCP handshakes are identical in both situations with one exception: the initial RTCP Sender Report sent by the server to the phone when the phone is connecting the first time has a Sender's Packet count of 0, but when a client has already been streaming on the server, the packet count is >0. In looking at the specification it's unclear as to whether this should be zero for a new client, or whether client connecting to an already running stream should expect this to be >0, but since this is the ONLY difference, I have to imagine this is the "problem". But I'm going to assume it's a bug in the CLIENT since this is the first time we've EVER seen this issue. 

One more reason I think this is the issue: if I turn off reuseFirstSource when creating the session, the phones connect just fine regardless of their order. But, again, having this option set to TRUE seems to be good for performance reasons. 

I guess what I'm looking for is confirmation that the Sender's packet count SHOULD be >0 for a client connecting to an already running stream, and as to whether anybody has any experience in dealing with this situation or ideas on how to get around it. 

Thanks in advance. 

FYI - I can provide Wireshark files if you need. 
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Saskia van Emst | 19 Apr 13:18 2016

ProxyServer switching backend source

Hi all,

First of all thanks a lot for the software ☺ 

For an IP camera, connected to wireless networks, I’m using the proxy so that the stream can be viewed
multiple times without increasing the bandwidth over the wireless link.

Now I am wondering if it is possible to let the proxy switch the backend stream to a different rtsp url. When a
certain event is triggered (e.g. the connection switches from Wi-Fi to 4G) I would like the proxy to serve a
different back-end stream on the same front-end url.

For example:

1. rtsp://proxyserver/video-stream <- rtsp://ip-cam/highquality
2. Connection switches, some trigger is sent to the proxy server
3. rtsp://proxyserver/video-stream <- rtsp://ip-cam/lowquality

With the REGISTER command using the included test program I can include a new stream, but when I specify an
existing [proxy-URL-suffix] I get '451 Invalid parameter'.
I guess this means this scenario is simply not supported, and only new back-end streams can be added?

Would it be possible to do something like this, and if so would it be very hard to implement or could there be a
quick fix?

If I change the image parameters in the camera then the stream keeps working so I guess it is possible to
change quality/resolution of a stream while it is being viewed.

Thanks for any input / ideas.

Best regards,

Saskia van Emst

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
John Finlay | 18 Apr 16:35 2016

Media server stack overflow when large number of streams started simultaneously

Hi

 

We are experiencing a stack overflow in Live555 Media Server (version 2016.04.01) when trying to simultaneously start a large number of streams that are all using the same H264 source file. In our test we are trying to simultaneously start 200 streams however I have observed the issue happening with as few as 40 being started simultaneously.

 

The issue seems to be occurring due to the way Live555 generates the SDP line it sends back to the client in response to the RTSP DESCRIBE request. When getAuxSDPLine in H264VideoFileServerMediaSubsession is called it makes a recursive call to doEventLoop, from what I understand this is done as it needs to process the first frame of the video to get the values required to generate the SDP line. The issue with this is that if there is another RTSP DESCRIBE request queued waiting to be processed it will result in another call to getAuxSDPLine and a further recursive call to doEventLoop. If there is a large enough number of RTSP DESCRIBE requests queued this recursive calling continues until a stack overflow occurs.

 

Obviously we could increase the size of the stack when building the application however this isn’t really a scalable solution. If anyone has any suggestions of how we could stop this behaviour they would be greatly appreciated.

 

Thanks,

John

 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Davood Falahati | 15 Apr 21:42 2016
Picon

Re: live-devel Digest, Vol 149, Issue 10

I compiled live555 following the instruction and everything went good. I have all required headers and libraries in /usr/local/include and /usr/local/libs. Then,  I made a new C++ project in Xcode and I copied the content of simpleRTSPClient.cpp to my project. I tried to compile it and I receive that error.

Davood Falahati,

Isfahan University of Technology.



On Fri, Apr 15, 2016 at 11:30 PM, <live-devel-request <at> ns.live555.com> wrote:
Send live-devel mailing list submissions to
        live-devel <at> lists.live555.com

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.live555.com/mailman/listinfo/live-devel
or, via email, send a message with subject or body 'help' to
        live-devel-request <at> lists.live555.com

You can reach the person managing the list at
        live-devel-owner <at> lists.live555.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of live-devel digest..."


Today's Topics:

   1. Re: problem in compiling simpleRtspClient (Ross Finlayson)


----------------------------------------------------------------------

Message: 1
Date: Fri, 15 Apr 2016 09:06:12 -0700
From: Ross Finlayson <finlayson <at> live555.com>
To: LIVE555 Streaming Media - development & use
        <live-devel <at> ns.live555.com>
Subject: Re: [Live-devel] problem in compiling simpleRtspClient
Message-ID: <98936BF5-315E-4714-B506-BF294BC39121 <at> live555.com>
Content-Type: text/plain; charset=utf-8

OK, so you?re not linking your new application with the LIVE555 libraries properly - which means that something is wrong with your ?Makefile?.

Does the *original* ?testRTSPClient? - in the ?live/testProgs? directory - compile and link OK?  If so, then just do the same thing that we do in that directory, using a similar ?Makefile?.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/




------------------------------

Subject: Digest Footer

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


------------------------------

End of live-devel Digest, Vol 149, Issue 10
*******************************************

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Davood Falahati | 15 Apr 12:37 2016
Picon

problem in compiling simpleRtspClient

Dear Community,

I am interested in live streaming with your precious library. I am on MacOsx Elcaptain and I made project with the following command:

./genMakeFiles macosx
./make
./make install

everything went well and I have installed libraries in /usr/local/lib and headers in /usr/loca/include/liveMedia . etc.

I am using xCode 7. I created a C++ project and copied testRtspClient, in my main file.

I have added all the headers and libraries in my project settings, now I receive the below error. I could not find a proper help covering what to do on Internet. Would you please help me?


----------------------------
Undefined symbols for architecture x86_64:
  "strDup(char const*)", referenced from:
      DummySink::DummySink(UsageEnvironment&, MediaSubsession&, char const*) in main.o
  "RTSPClient::sendRequest(RTSPClient::RequestRecord*)", referenced from:
      vtable for ourRTSPClient in main.o
  "RTSPClient::sendPlayCommand(MediaSession&, void (*)(RTSPClient*, int, char*), char const*, char const*, float, Authenticator*)", referenced from:
      setupNextSubsession(RTSPClient*) in main.o
  "RTSPClient::sendPlayCommand(MediaSession&, void (*)(RTSPClient*, int, char*), double, double, float, Authenticator*)", referenced from:
      setupNextSubsession(RTSPClient*) in main.o
  "RTSPClient::sendSetupCommand(MediaSubsession&, void (*)(RTSPClient*, int, char*), unsigned char, unsigned char, unsigned char, Authenticator*)", referenced from:
      setupNextSubsession(RTSPClient*) in main.o
  "RTSPClient::setRequestFields(RTSPClient::RequestRecord*, char*&, unsigned char&, char const*&, char*&, unsigned char&)", referenced from:
      vtable for ourRTSPClient in main.o
  "RTSPClient::sendDescribeCommand(void (*)(RTSPClient*, int, char*), Authenticator*)", referenced from:
      openURL(UsageEnvironment&, char const*, char const*) in main.o
  "RTSPClient::sendTeardownCommand(MediaSession&, void (*)(RTSPClient*, int, char*), Authenticator*)", referenced from:
      shutdownStream(RTSPClient*, int) in main.o
  "RTSPClient::RTSPClient(UsageEnvironment&, char const*, int, char const*, unsigned short, int)", referenced from:
      ourRTSPClient::ourRTSPClient(UsageEnvironment&, char const*, int, char const*, unsigned short) in main.o
  "RTSPClient::~RTSPClient()", referenced from:
      ourRTSPClient::ourRTSPClient(UsageEnvironment&, char const*, int, char const*, unsigned short) in main.o
      ourRTSPClient::~ourRTSPClient() in main.o
  "FramedSource::getNextFrame(unsigned char*, unsigned int, void (*)(void*, unsigned int, unsigned int, timeval, unsigned int), void*, void (*)(void*), void*)", referenced from:
      DummySink::continuePlaying() in main.o
  "MediaSession::createNew(UsageEnvironment&, char const*)", referenced from:
      continueAfterDESCRIBE(RTSPClient*, int, char*) in main.o
  "RTCPInstance::setByeHandler(void (*)(void*), void*, unsigned char)", referenced from:
      shutdownStream(RTSPClient*, int) in main.o
      continueAfterSETUP(RTSPClient*, int, char*) in main.o
  "MediaSubsession::initiate(int)", referenced from:
      setupNextSubsession(RTSPClient*) in main.o
  "BasicTaskScheduler::createNew(unsigned int)", referenced from:
      _main in main.o
  "BasicUsageEnvironment::createNew(TaskScheduler&)", referenced from:
      _main in main.o
  "MediaSubsessionIterator::next()", referenced from:
      setupNextSubsession(RTSPClient*) in main.o
      shutdownStream(RTSPClient*, int) in main.o
      subsessionAfterPlaying(void*) in main.o
  "MediaSubsessionIterator::MediaSubsessionIterator(MediaSession const&)", referenced from:
      continueAfterDESCRIBE(RTSPClient*, int, char*) in main.o
      shutdownStream(RTSPClient*, int) in main.o
      subsessionAfterPlaying(void*) in main.o
  "MediaSubsessionIterator::~MediaSubsessionIterator()", referenced from:
      shutdownStream(RTSPClient*, int) in main.o
      subsessionAfterPlaying(void*) in main.o
  "Medium::close(Medium*)", referenced from:
      shutdownStream(RTSPClient*, int) in main.o
      subsessionAfterPlaying(void*) in main.o
      StreamClientState::~StreamClientState() in main.o
  "MediaSink::stopPlaying()", referenced from:
      vtable for DummySink in main.o
  "MediaSink::startPlaying(MediaSource&, void (*)(void*), void*)", referenced from:
      continueAfterSETUP(RTSPClient*, int, char*) in main.o
  "MediaSink::onSourceClosure(void*)", referenced from:
      DummySink::continuePlaying() in main.o
  "MediaSink::sourceIsCompatibleWithUs(MediaSource&)", referenced from:
      vtable for DummySink in main.o
  "MediaSink::MediaSink(UsageEnvironment&)", referenced from:
      DummySink::DummySink(UsageEnvironment&, MediaSubsession&, char const*) in main.o
  "MediaSink::~MediaSink()", referenced from:
      DummySink::DummySink(UsageEnvironment&, MediaSubsession&, char const*) in main.o
      DummySink::~DummySink() in main.o
  "RTSPClient::isRTSPClient() const", referenced from:
      vtable for ourRTSPClient in main.o
  "MediaSession::absEndTime() const", referenced from:
      setupNextSubsession(RTSPClient*) in main.o
  "MediaSession::absStartTime() const", referenced from:
      setupNextSubsession(RTSPClient*) in main.o
  "Medium::isRTSPClient() const", referenced from:
      vtable for DummySink in main.o
  "Medium::isRTSPServer() const", referenced from:
      vtable for ourRTSPClient in main.o
      vtable for DummySink in main.o
  "Medium::isMediaSession() const", referenced from:
      vtable for ourRTSPClient in main.o
      vtable for DummySink in main.o
  "Medium::isRTCPInstance() const", referenced from:
      vtable for ourRTSPClient in main.o
      vtable for DummySink in main.o
  "Medium::isServerMediaSession() const", referenced from:
      vtable for ourRTSPClient in main.o
      vtable for DummySink in main.o
  "Medium::isSink() const", referenced from:
      vtable for ourRTSPClient in main.o
  "Medium::isSource() const", referenced from:
      vtable for ourRTSPClient in main.o
      vtable for DummySink in main.o
  "MediaSink::isSink() const", referenced from:
      vtable for DummySink in main.o
  "MediaSink::isRTPSink() const", referenced from:
      vtable for DummySink in main.o
  "typeinfo for RTSPClient", referenced from:
      typeinfo for ourRTSPClient in main.o
  "typeinfo for MediaSink", referenced from:
      typeinfo for DummySink in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Davood Falahati,

Isfahan University of Technology.


_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Ignacio Barreto | 14 Apr 21:48 2016

Fwd: MP3 streaming problem

Hi, we're developing an audio streamer server from a live source.
The source audio is encoded by FFMpeg and its type is
AV_SAMPLE_FMT_S16P (planar audio 16 bits signed) and the codec is MP3.

We based our streamer server using testOnDemandRTSPServer.
We subclassed FramedSource (AudioFramedSource) and
OnDemandServerMediaSubsession (AudioServerMediaSubsession)

In this AudioServerMediaSubsession class we return
MPEG1or2AudioStreamFramer in createNewStreamSource method and
MPEG1or2AudioRTPSink in createNewRTPSink method

In order to test this implementation we used FFPlay and VLC as the
client, we connected to the audio stream and the result is similar to
what it is described in http://www.live555.com/rtp-mp3/

Is there some example of how to use MP3ADU from memory live source?
Or maybe it's another problem in the source code

Thanks,
Ignacio Barreto
Frederik De Ruyck | 14 Apr 11:11 2016
Picon

What are the consequences of increasing RTCP.cpp::maxRTCPPacketSize?

Hi,

I can fix the famous "RTCPInstance error: Hit limit when reading 
incoming packet over TCP. Increase "maxRTCPPacketSize"" error by setting 
maxRTCPPacketSize to INT16_MAX * 8.
I am not able to upgrade any camera firmware code and I'm running the 
latest 01 April 16 LiveMedia code on my PC.
The default value for maxRTCPPacketSize is 1456, what are the 
consequences of increasing this value besides more memory consumption?

Thank you in advance,
Frederik
Afzal Pasha | 13 Apr 14:39 2016
Picon

RTCP: Changing RR packets receptions interval.

Hello,

 

Is there any way, from the source side, to change the frequency of reception of the RR packets.

 

I know I can change the transmission interval for sending the SR packets ( although it's getting dynamically calculated based on bandwidth, packet size, number of participants etc.) in rtcp_interval().

 

Any help would be much appreciated.

 

 

Thanks in advance.

 

Regards,

Afzal Pasha
Elektronikentwicklung

 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

Gmane