adunaevsky | 1 Jul 17:52 2015
Picon

RTSPServer fails to stream when the number of ServerMediaSessions is more than 10

Hello, Ross Finlayson and LIVE555 support,

there's another issue I have to tell about.
The RTSPServer works flawlessly while dealing with 10 ServerMediaSessions,
but it's hard to explain what happens when I create, say, 11 ServerMediaSession objects.

So I create RTSPServer with 11 sessions and 1 subsession per each session, then check every stream using
vlc. 
It might work at the beginning, but not for too long. Then vlc just stops reading any of the RTSP streams and I
am not able to read H.264 anymore. 
It looks like the server is still functioning, but the streaming appears to be completely broken. 

Here is what openRTSP shows:
--------------------------------------------------------------------------------------------
$ openRTSP rtsp://10.0.11.2:8554/66
Opening connection to 10.0.11.2, port 8554...
...remote connection opened
Sending request: OPTIONS rtsp://10.0.11.2:8554/66 RTSP/1.0
CSeq: 2
User-Agent: openRTSP (LIVE555 Streaming Media v2015.06.21)

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

... and this is all what I am able to see from openRTSP.  
The RTSPServer refuses to give any responses. 

How to deal with this problem? What can be the reason of it?

Best regards,
Alexander Dunaevsky
(Continue reading)

Bommes, Michael | 29 Jun 17:23 2015
Picon
Picon

Can't receive packets from live555 server on ARM board (testH264VideoStreamer binary)

Hi,

I'm working on an embedded Live streaming platform.

I've cross-compiled live555 with a SoC toolchain, using -DLOCALE_NOT_USED and adjusting compiler name (these are the only changes I made).

Now I tried to run testH264VideoStreamer with a test.264 file and using openRTSP tool to receive the stream.


./openRTSP rtsp://192.168.31.102:8554/testStream

results in:

Opening connection to 192.168.31.102, port 8554...
...remote connection opened
Sending request: OPTIONS rtsp://192.168.31.102:8554/testStream RTSP/1.0
CSeq: 2
User-Agent: ./openRTSP (LIVE555 Streaming Media v2015.06.11)


followed by some received bytes and requests and finally


Received 192 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 5
Date: Mon, Jun 29 2015 17:11:31 GMT
Range: npt=0.000-
Session: 6C315064
RTP-Info: url=rtsp://192.168.31.102:8554/testStream/track1;seq=46799;rtptime=3977882759


Started playing session

but the created openRTSP output file is empty.


Using testOnDemandRTSPServer, openRTSP does receive packets, so I guess it's not a problem of firewall settings?


What are possible reasons for this behaviour?
What are the essential differences between testOnDemandRTSPServer and testH264VideoStreamer regarding the sending and receiving part?
What might be system or platform depending factors? (all the streaming samples worked for my typical pc platforms where I already coded a working live image streaming based on testH264VideoStreamer sample server settings)


Thanks in advance

Michael

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
adunaevsky | 27 Jun 17:45 2015
Picon

Destroying RTSPServer object crashes the whole application with SIGSEGV error

Hello, Ross Finlayson and LIVE555 support!

First of all, thanks for such a great library. I am developing an application for streaming cv::Mat over RTSP

I have a problem using Medium::close() in my destructor when deleting an RTSPServer object after I have
already deleted ServerMediaSession* objects vector (of course, using Medium::close() too). 
The app crashes with SIGSEGV error. 

On the other side, destroying RTSPServer object will succeed if I put it right before destroying
ServerMediaSession* objects vector, but this time Medium::close() for ServerMediaSession* will
crash my app again with SIGSEGV error. 
What's more interesting: in this case I am still able to use ServerMediaSession* object even after
destroying the RTSPServer using Medium::close(), for example, calling the mSms[i] object by method
like this: 
  mSms[0]->deleteAllSubsessions() will not cause the crash. 
It means that mSms[0] object still exists after Medium::close(mRTSPServer), but
Medium::close(mSms[0]) is not able to destroy it properly, without SIGSEGV errors.

It appears that I have to use Medium::close() either RTSPServer object or a ServerMediaSession* objects
vector. Why? Is this a bug or am I doing something wrong?  

Here is my destructor code:
-------------------------------------------------------------------------------------------------------------------------------
RTSPServerH264::~RTSPServerH264()
{
    LOG(INFO) << "RTSP server close: destroying objects";

    if (mSms.size() > 0)
    {
        LOG(INFO) << "destroying: Server Media Subsession vector";
        for (ServerMediaSession* s : mSms)
        {
            s->deleteAllSubsessions();
            Medium::close(s);
        }
        mSms.clear();
        mLiveSubsession.clear();
    }

    if (mRTSPServer)
    {
        LOG(INFO) << "destroying: RTSPServer";
        // BUG: Destroying RTSPServer object crashes the whole application!
        Medium::close(mRTSPServer);
    }

    if (mUsageEnvironment)
    {
        LOG(INFO) << "destroying: Usage Environment";
        mUsageEnvironment->reclaim();
    }

    if (mTaskScheduler)
    {
        LOG(INFO) << "destroying: Task Scheduler";
        delete mTaskScheduler;
    }
}
-------------------------------------------------------------------------------------------------------------------------------

Earlier, I published this issue on stackoverflow but wasn't lucky to get any response:
http://stackoverflow.com/questions/31006804/live555-rtspserver-object-destroyed-improperly-or-the-library-bug
I've read about the RTSPServer bug from the changelog.txt before, that's why I've tested using the latest
version of LIVE555 (on Ubuntu 14.04).

-------------------------------------------------------------------------------------------------------------------------------
2015.05.12:
- Updated the previous revision to change the order in which fields are deleted in the
  "RTSPServer" destructor, to avoid a possible crash if "RTSPServer" objects are deleted.
  (Thanks to ChaSeop Im for noting the problem.)
-------------------------------------------------------------------------------------------------------------------------------

Best Regards,
Alexander Dunaevsky
Frank van Eijkelenburg | 26 Jun 15:17 2015
Picon

Measuring delay

Hi all,

We are using the proxy server implementation of live555. We have a requirement for the proxy server to have a delay between incoming and outgoing streams of less than 100 ms. My question is, how can I verify this in a simple way?

I was thinking of sending a frame with a timestamp in the payload data and verify this in a client (which is receiving the stream through the proxy server). If I run these programs on the same machine, we don't have the delay of a network, but only an extra delay of the send and receive program perhaps. Is that correct?

--

Met vriendelijke groeten / With kind regards,

Frank van Eijkelenburg  Lead Designer

A Burgemeester Jamessingel 1, P.O. Box 2013, 2800 BD Gouda, The Netherlands | W technolution.com

This e-mail is intended exclusively for the addressee(s), and may not be passed on to, or made available for use by any person other than the addressee(s). Technolution B.V. rules out any and every liability resulting from any electronic transmission.
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Samer Al Hakim | 25 Jun 10:27 2015

Stream and Receive H264 video using the same UDP Groupsock

Hello,

Using the example "testH264VideoStreamer.cpp" provided by the live library, I would like to create one UDP Groupsock that streams and receives H264 RTP data in parallel.

I would like to know if this target is doable in principle using the live libraries. When looking at the provided examples, I found sole streamers or receivers, but can a streamer and receiver be combined using one Groupsock?

Thanks for your help in advance,
Samer

---
SIGOS
testing is our competence

Klingenhofstrasse 50d
D-90411 Nuernberg
Fon +49 911 95168-0
www.keynote-sigos.com

Follow us on: linked.in | xing.com | twitter.com | facebook.com

HRB 9323 Nuernberg
Gerichtsstand: Nuernberg
Geschaeftsfuehrer: Adil Kaya, Jennifer Tejada, David Peterson

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Ross Finlayson | 25 Jun 02:30 2015

A reminder: LIVE555-based products and the LGPL

Just a quick reminder that if you distribute a product (whether hardware or software; whether for pay or for free) that uses the open source “LIVE555 Streaming Media” software, you must abide by the conditions of the LGPL license.  See

If you have any additional questions about your products’ compliance with the LGPL, please consult your copyright attorney.  (This mailing list is for engineers, not lawyers :-)


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

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Paul Clark | 24 Jun 15:12 2015

[PATCH] Fix buffering of multiple GET_PARAMETER responses

Abstruse case triggered by a VLC live555 module bug, in which
doEventLoop() is not called during PAUSE, causing GET_PARAMETER
responses to get stacked up.  When PLAY starts again the parsing
of these responses then fails because handleGET_PARAMETERResponse()
trims the entire buffer rather than just the response being
parsed, leading to the PLAY response being lost.

This patch delimits the buffer to the end of the response before
passing to handleGET_PARAMETERResponse so that the trimming
happens in the response in question, not at the end of the response
buffer
---
  liveMedia/RTSPClient.cpp | 4 ++++
  1 file changed, 4 insertions(+)

diff --git a/liveMedia/RTSPClient.cpp b/liveMedia/RTSPClient.cpp
index e49afbe..de0416f 100644
--- a/liveMedia/RTSPClient.cpp
+++ b/liveMedia/RTSPClient.cpp
 <at>  <at>  -1778,7 +1778,11  <at>  <at>  void RTSPClient::handleResponseBytes(int 
newBytesRead) {
        } else if (strcmp(foundRequest->commandName(), "TEARDOWN") == 0) {
          if (!handleTEARDOWNResponse(*foundRequest->session(), 
*foundRequest->subsession())) break;
        } else if (strcmp(foundRequest->commandName(), "GET_PARAMETER") 
== 0) {
+            // Protect any further buffered responses from trimming
+            char saved = *responseEnd;
+            *responseEnd = '\0';
          if (!handleGET_PARAMETERResponse(foundRequest->contentStr(), 
bodyStart)) break;
+        *responseEnd = saved;
        }
      } else if (responseCode == 401 && 
handleAuthenticationFailure(wwwAuthenticateParamsStr)) {
        // We need to resend the command, with an "Authorization:" header:
--

-- 
2.1.4
BENNE Christophe | 24 Jun 11:38 2015

New version of the "LIVE555 Streaming Media" code - restructures the "RTPServer" class

Hi Ross,

 

I would like to report a problem since I upgraded to live 2015.06.11 and higher. I experienced crashes when releasing a RTSPServer which has client connections. It happens in the GenericMediaServer destructor, connections destructor invokes RTSPServer code but this part of the object is already destroyed, see stack below.

 

I was able to reproduce the problem with a slightly modified live555MediaServer (live555MediaServer.cpp patch attached) : code added to stop main loop when SIGINT is received and release RTSPServer using Media::close method. If Ctrl-C is hit while live555MediaServer is streaming a file, the crash occurs.

 

GNU gdb (GDB) 7.4.1-debian

Copyright (C) 2012 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>...

Reading symbols from /home/xophe/dev/picata/live-testcase/live/mediaServer/live555MediaServer...done.

 

warning: core file may not match specified executable file.

[New LWP 4699]

 

warning: Can't read pathname for load map: Input/output error.

Core was generated by `./live555MediaServer'.

Program terminated with signal 11, Segmentation fault.

#0  0x0000000000000000 in ?? ()

(gdb) thread apply all where

 

Thread 1 (LWP 4699):

#0  0x0000000000000000 in ?? ()

#1  0x00007f56460a1a1d in RTSPServer::stopTCPStreamingOnSocket (this=0x24c28e0, socketNum=6) at RTSPServer.cpp:345

#2  0x00007f56460a1aa6 in RTSPServer::RTSPClientConnection::closeSocketsRTSP (this=0x24c2cb0) at RTSPServer.cpp:706

#3  0x00007f56460a1b3d in RTSPServer::RTSPClientConnection::~RTSPClientConnection (this=0x24c2cb0, __in_chrg=<optimized out>) at RTSPServer.cpp:383

#4  0x00007f56460a9ce9 in RTSPServerSupportingHTTPStreaming::RTSPClientConnectionSupportingHTTPStreaming::~RTSPClientConnectionSupportingHTTPStreaming (this=0x24c2cb0, __in_chrg=<optimized out>)

    at RTSPServerSupportingHTTPStreaming.cpp:61

#5  0x00007f564609d369 in GenericMediaServer::~GenericMediaServer (this=0x24c28e0, __in_chrg=<optimized out>) at GenericMediaServer.cpp:115

#6  0x0000000000402b49 in DynamicRTSPServer::~DynamicRTSPServer (this=0x24c28e0, __in_chrg=<optimized out>) at DynamicRTSPServer.cpp:42

#7  0x0000000000402886 in main (argc=<optimized out>, argv=<optimized out>) at live555MediaServer.cpp:113

(gdb)

 

 

Best regards.

 

Christophe BENNE

 

 

// --

 

Christophe BENNE

 

Thales Communication & Security

20-22 rue Grange Dame Rose
CS 90519
78141 VELIZY Cedex

FRANCE

Attachment (live555MediaServer.cpp.patch): application/octet-stream, 1966 bytes
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Janus, Karl | 23 Jun 19:35 2015
Picon

Re: multi-threaded connect() and EBADF (Ross Finlayson)

I setup a test outside of my usage of Live555 and have yet to reproduce the EBADF issue. This test led me to more
closely examine my derived UsageEnvironment::getErrno() method.  I noticed I might have been
over-eager in my error checking and was evaluating both 'errno' as well as WSAGetLastError().  Now that my
derived UsageEnvironment::getErrno() returns only WSAGetLastError(), the issue is completely gone
in all of my regression tests.  With this change I no longer need to override the
RTSPClient::connectToServer() method.  In any case, thank you for pointing me in the right direction and
I apologize for any 'API Change Request' abuse I may have incurred.

-karl

> > I can 'remedy' this problem by making RTSPClient::connectToServer()
> > virtual and using makeSocketBlocking() with an arbitrary timeout and
> > then makeSocketNonBlocking() after successful return from
> > RTSPClient::connectToServer().  I understand that this probably
> > violates the license agreement
>
> No, modifying the supplied code does not violate the LGPL license,
> *provided that* you distribute your modifications along with your
> product (and, of course, comply with the other terms of the LGPL); see
>       http://live555.com/liveMedia/faq.html#copyright-and-license
> <http://live555.com/liveMedia/faq.html#copyright-and-license>
>
> However?
>
> > I ask: Is there a way that live555 could be modified by making
> RTSPClient::connectToServer a virtual method?
>
> OK, in the current (just released) version of the ?LIVE555 Streaming
> Media? code (version 2015.06.21), I have changed this member function
> to be virtual.
>
> I encourage you, however, to first try to track down the actual cause
> of this bug, rather than simply trying to ?work around? it.  The bug
> may well end up being something other than a bug in your Windows
> libraries, and/or may be masking a more serious problem somewhere.
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>

This message and any attachments are solely for the use of intended recipients. The information contained
herein may include trade secrets, protected health or personal information, privileged or otherwise
confidential information. Unauthorized review, forwarding, printing, copying, distributing, or
using such information is strictly prohibited and may be unlawful. If you are not an intended recipient,
you are hereby notified that you received this email in error, and that any review, dissemination,
distribution or copying of this email and any attachment is strictly prohibited. If you have received
this email in error, please contact the sender and delete the message and any attachment from your system.
Thank you for your cooperation
Janus, Karl | 18 Jun 22:45 2015
Picon

multi-threaded connect() and EBADF

Hello!

I work on a win32-based project that consumes live555 (client-side only) and recently upgraded from an
older synchronous API revision of live555 to the latest (2015-06-11 at the time of this writing).  Also,
possibly of note, this project is multi-threaded and consumes multiple instances of RTSPClient (with
separate UsageEnvironment(s), MediaSink(s), and MediaSession(s) per derived RTSPClient instance).

My main concern is that the timeout parameter is missing from the calls and I was previously using the
timeout parameter to solve a silly win32 bug (as far as I know it's win32-only).  After the first connect(),
subsequent calls to connect() with a non-blocking socket will fail most of the time with EBADF (-9) in a
multi-threaded environment (e.g., in a thread-pool environment).  To combat this in the older API I
specified a -1 on the first call (e.g., sendOptionsCmd) so that the initial socket would be in blocking
mode upon first connect().  The socket could then be made non-blocking after that point.

I can 'remedy' this problem by making RTSPClient::connectToServer() virtual and using
makeSocketBlocking() with an arbitrary timeout and then makeSocketNonBlocking() after successful
return from RTSPClient::connectToServer().  I understand that this probably violates the license
agreement and in order to comply with the license, I ask: Is there a way that live555 could be modified by
making RTSPClient::connectToServer a virtual method?  Another way could be to allow a timeout per
request, but at the expense of more code and possibly more API changes.

My end-goal is that the connect() method can be called with a blocking socket and a specifiable timeout. 
Simple example assuming the method was virtual and MyRtspClient derives from RTSPClient:

<code>
int MyRtspClient::connectToServer(int socketNum, portNumBits remotePortNum) {
        ...
        makeSocketBlocking(socketNum, myOwnTimeoutValue);
        ...
        int result = RTSPClient::connectToServer(socketNum, remotePortNum);
        ...
        if(result >=0){
                makeSocketNonBlocking(socketNum);
        }
        ...
        return result;
}
</code>

Side note: this is one of the few instances of this issue outside of Live555 that I could find while
researching:  http://acsutoday.blogspot.com/2009/02/connect-returns-ebadf-when-run-in.html

Thanks for the great RTSP library and thanks in advance for your time.
-karl

This message and any attachments are solely for the use of intended recipients. The information contained
herein may include trade secrets, protected health or personal information, privileged or otherwise
confidential information. Unauthorized review, forwarding, printing, copying, distributing, or
using such information is strictly prohibited and may be unlawful. If you are not an intended recipient,
you are hereby notified that you received this email in error, and that any review, dissemination,
distribution or copying of this email and any attachment is strictly prohibited. If you have received
this email in error, please contact the sender and delete the message and any attachment from your system.
Thank you for your cooperation
Eric Blanpied | 18 Jun 19:24 2015

QuickTimeFileSink creating files unreadable by QuickTime

Hello,

Our Mac OS X app uses the QuickTimeFileSink to record RTSP streams to local storage, and then uses Apples AVFoundation classes for playback. In testing we have now had multiple instances where the resulting files are treated as unplayable due to an incorrect syncSampleTable entry, either in our app, or in any QuickTime-based player. VLC will open the files, so they’re obviously close to correct, but we need it to work in our app, every time.

A typical error message is shown below, and media which exhibits the problem can be found here: https://dl.dropboxusercontent.com/u/16009858/AXISCamera2-20150617-123230.mov

[11:21:23.991] CheckSyncSampleAtom signalled err=-12848 (kFigFormatReaderError_ParsingFailure) (syncSampleTable has an entry which is out of the range of 1 to numSamples, inclusive) at /SourceCache/CoreMedia/CoreMedia-1562.235/Prototypes/FormatHandlers/Movie/MovieAtomParsing.c line 1697
<<< FFR_Movie >>> ParseTrackAtom: Omitting a track that encountered error -12848 during atom parsing

I’m interested in advice to either prevent the problem in the future, or possibly to correct the issue in files that have it.

-e

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

Gmane