Marc Palau | 24 Mar 12:13 2015
Picon

Add project to live555 third-party applications list

Dear Ross,

I'm Marc Palau, developer and project engineer of the audiovisual unit at i2CAT Foundation. Our team is developing a cloud media processing and streaming framework, called LiveMediaStreamer (LMS), and we are using Live555 as the network library. 

LMS framework is based on a modular architecture that lets configure different scenarios such as AV Mixer (the default implemented by the web GUI) among others (e.g.: videoconferencing, security management, transcoding,...) by following a properly scenario configuration.

In that sense, we are contacting you because we would like to be listed in your third party applications list.

Looking forward to hearing from you soon,

Kind regards,
On behalf of i2CAT Audiovisual Unit technical team

----
Marc Palau Erena
i2CAT Audiovisual Unit
_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Massimo Guarino | 20 Mar 12:00 2015
Picon

lookupServerMediaSession on live555MediaServer

I am trying to implement a media server to stream also live sessions constructed 'on the fly'.
Analyzing the behaviour of DynamicRTSPServer contained in live555MediaServer, I noted that when a client demand a stream to the server (i.e a 264 stream file),  lookupServerMediaSession is called twice, both with isFirstLookupInSession = true.
What is the meaning of this double call? Is there a way to distinguish first and second call?
Thank You for your help.
Massimo Guarino

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Deanna Earley | 19 Mar 12:09 2015
Picon

Digest authentication and stale nonces

Hello Ross.

I've just noticed an oddity in the authentication handling.
Some servers record a timestamp with the nonce allowing them to reject a digest response that's too old.
While this is fine during initialisation, commands that are sent after a few minutes trigger an auth fail
response with the stale flag.

PLAY
rtsp://10.1.3.47/onvif-media/media.amp?profile=icana_0&sessiontimeout=60&streamtype=unicast RTSP/1.0
CSeq: 5
Authorization: Digest username="onvif", realm="AXIS_WS_00408CC17E5B",
nonce="001b8708Y551373d6957b62f930e97d5284620c7981138",
uri="rtsp://10.1.3.47/onvif-media/media.amp/", response="b409ff200a58303875e0198ff4f5fb4e"
User-Agent: iCatcher RTSP Client (LIVE555 Streaming Media v2015.03.16)
Session: 00E88F6A
Range: npt=0.000-

RTSP/1.0 200 OK
CSeq: 5
Session: 00E88F6A
Range: npt=0-
RTP-Info: url=rtsp://10.1.3.47/onvif-media/media.amp/trackID=1?profile=icana_0&sessiontimeout=60&streamtype=unicast;seq=33123;rtptime=438949229
Date: Thu, 19 Mar 2015 10:43:07 GMT

GET_PARAMETER
rtsp://10.1.3.47/onvif-media/media.amp?profile=icana_0&sessiontimeout=60&streamtype=unicast RTSP/1.0
CSeq: 6
Authorization: Digest username="onvif", realm="AXIS_WS_00408CC17E5B",
nonce="001b8708Y551373d6957b62f930e97d5284620c7981138",
uri="rtsp://10.1.3.47/onvif-media/media.amp/", response="acbacc6cf34d3e20cbb90ba7f1277f30"
User-Agent: iCatcher RTSP Client (LIVE555 Streaming Media v2015.03.16)
Session: 00E88F6A

RTSP/1.0 200 OK
CSeq: 6
Session: 00E88F6A
Date: Thu, 19 Mar 2015 10:44:02 GMT

GET_PARAMETER
rtsp://10.1.3.47/onvif-media/media.amp?profile=icana_0&sessiontimeout=60&streamtype=unicast RTSP/1.0
CSeq: 7
Authorization: Digest username="onvif", realm="AXIS_WS_00408CC17E5B",
nonce="001b8708Y551373d6957b62f930e97d5284620c7981138",
uri="rtsp://10.1.3.47/onvif-media/media.amp/", response="acbacc6cf34d3e20cbb90ba7f1277f30"
User-Agent: iCatcher RTSP Client (LIVE555 Streaming Media v2015.03.16)
Session: 00E88F6A

RTSP/1.0 200 OK
CSeq: 7
Session: 00E88F6A
Date: Thu, 19 Mar 2015 10:44:58 GMT

GET_PARAMETER
rtsp://10.1.3.47/onvif-media/media.amp?profile=icana_0&sessiontimeout=60&streamtype=unicast RTSP/1.0
CSeq: 8
Authorization: Digest username="onvif", realm="AXIS_WS_00408CC17E5B",
nonce="001b8708Y551373d6957b62f930e97d5284620c7981138",
uri="rtsp://10.1.3.47/onvif-media/media.amp/", response="acbacc6cf34d3e20cbb90ba7f1277f30"
User-Agent: iCatcher RTSP Client (LIVE555 Streaming Media v2015.03.16)
Session: 00E88F6A

RTSP/1.0 401 Unauthorized
CSeq: 8
Session: 00E88F6A
WWW-Authenticate: Digest realm="AXIS_WS_00408CC17E5B",
nonce="001b87aeY0895241e8c6fcca2822797d4ad2ef6ffa294b", stale=TRUE
Date: Thu, 19 Mar 2015 10:45:53 GMT

GET_PARAMETER
rtsp://10.1.3.47/onvif-media/media.amp?profile=icana_0&sessiontimeout=60&streamtype=unicast RTSP/1.0
CSeq: 9
Authorization: Digest username="onvif", realm="AXIS_WS_00408CC17E5B",
nonce="001b87aeY0895241e8c6fcca2822797d4ad2ef6ffa294b",
uri="rtsp://10.1.3.47/onvif-media/media.amp/", response="025baa1409cd60448726eb4b582e1fa3"
User-Agent: iCatcher RTSP Client (LIVE555 Streaming Media v2015.03.16)
Session: 00E88F6A

RTSP/1.0 200 OK
CSeq: 9
Session: 00E88F6A
Date: Thu, 19 Mar 2015 10:46:48 GMT

The auth fail does trigger it to discard the authentication and reauthenticate next time, but doesn't seem
to trigger a resend (RTSPClient.cpp:1263 ?).

Can the stale response in the WWW-Authenticate header be honoured to trigger a resend?

In our case, this isn't a huge issue as it's only a periodic GET_PARAMETER request, but it will affect
TEARDOWN request as well as anyone that uses PAUSE and PLAY requests.
(Worst case with the TEARDOWN is that the server will carry on streaming UDP for the timeout period (another
60s here)

What are your thoughts on this?

Thanks

--

-- 
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
Robert Smith | 16 Mar 10:40 2015

triggerEvent() race condition

I have been diagnosing an issue on a client's system which is streaming 
six live encoded H264 streams vis multicast RTP and I think the problem 
lies in the triggerEvent() method.

The problem is that some of the streams just stop after a while. I added 
extensive tracing to our code and identified that the last call to the 
library is triggerEvent() to notify the library of a new frame but 
deliverFrame() is never called after this.

I guess the problem is that triggerEvent() is not thread safe. My 
solution is to derive BasicTaskScheduler and wrap the triggerEvent() 
call with a mutex. I have yet to test that this fixes the problem.

I'm a bit confused though because I had thought that triggerEvent() was 
thread safe. e.g, based on the content of this thread:

http://lists.live555.com/pipermail/live-devel/2012-June/015296.html

But I can't see how the implementation of triggerEvent() can be thread 
safe, e.g, the last line:

fTriggersAwaitingHandling |= eventTriggerId;

must load, modify and store the value at fTriggersAwaitingHandling and 
this won't be atomic.

Regards,

Robert Smith.
terry | 13 Mar 09:44 2015

display issue about "totSessionBW parameter should not be zero!"

I found an uninitialized local variable is as follow:

Index: liveMedia/OnDemandServerMediaSubsession.cpp
===================================================================
--- liveMedia/OnDemandServerMediaSubsession.cpp
+++ liveMedia/OnDemandServerMediaSubsession.cpp
 <at>  <at>  -109,7 +109,7  <at>  <at> 
     streamToken = fLastStreamToken;
   } else {
     // Normal case: Create a new media source:
-    unsigned streamBitrate;
+    unsigned streamBitrate = 0;
     FramedSource* mediaSource
       = createNewStreamSource(clientSessionId, streamBitrate);

This make the following prompt often disappeared.
  if (fTotSessionBW == 0) { // not allowed!
    env << "RTCPInstance::RTCPInstance error: totSessionBW parameter
should not be zero!\n";
    fTotSessionBW = 1;
  }

************************************************************

本邮件(包括所附附件)所含信息为保密信息,且仅为特定收件人之用。如果您不是特定收件人,切勿披露、复制、打印、转发或分发本邮件或其任何内容,亦请切勿依本邮件之任何内容而采取任何行动。如果本邮件误发送给您,请立即通知发件人并删除此邮件。谢谢!

This e-mail and any files transmitted herewith are confidential and may contain legally privileged
information.  It is intended solely for the use of the addressee(s). If you are not the intended recipient,
you are hereby notified that any use, disclosure, copying, printing, forwarding or dissemination of
this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately
contact the sender and delete it from your system. Thank you!

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Robert Smith | 12 Mar 11:22 2015

Windows build - undefined symbols

The following files need to include the <stdlib.h> or <cstdlib> header:

UsageEnvironment/UsageEnvironment.cpp
liveMedia/RTSPCommon.cpp
testProgs/testMP3Streamer.cpp

Otherwise building with VC++ complains about undefined symbols.
夏江龙 | 10 Mar 14:32 2015

how to get rtspClient object

HI,

I am using testRTSPClient demo to receive h264 data on function void
DummySink::afterGettingFrame(unsigned frameSize, unsigned numTruncatedBytes, struct timeval
presentationTime, unsigned /*durationInMicroseconds*/)  , Now i want to get  the current RTSPClient
object in this function. I use RTSPClient* rtspClient=(RTSPClient*)fSubsession.miscPtr to do this ,
is that right ?

thanks.

aalizzwell
xiajl <at> inspur.com
Robert Smith | 9 Mar 12:12 2015

H264VideoFramer truncating frames

I am using Live555 to stream H264 video via RTP from an embedded system.

The system is designed to be used on local area network's with 
relatively high bandwidth video, hence we have some large frames 
delivered from the encoder.

The encoder unfortunately only supplies frames in Annex B byte stream 
format requiring the frames to be parsed. Previously I was using my own 
class to identify the NAL unit's in conjunction with the 
H264VideoDiscreteFramer which worked fine but it's heavy on the CPU. So 
I've been trying to use the H264VideoFramer and just pass the full 
frames in which works ok and is faster than my solution except that I'm 
seeing a lot of truncated frames.

Having looked into the code it appears to be caused by the behaviour of 
the StreamParser class; specifically the ensureValidBytes1() method 
which calls getNextFrame() on my source with maxSize = BANK_SIZE - 
fTotNumValidBytes. The method switches banks to ensure that the larger 
of numBytesNeeded or the input sources maxFrameSize() will fit.

I can 'fix' the problem by increasing BANK_SIZE and implementing 
maxFrameSize() on my source but I'm not totally happy with this solution 
because I would prefer not to modify the library source and I'm just 
guessing for the maxFrameSize() value.

I was wondering whether it's possible to return a partial frame from my 
video source? I'm guessing it's not a good idea though.

Is there a recommended solution to my problem?

As a side note: it would be great if I could stream the video without 
having to parse the frames but I guess this just isn't possible with 
RTP/H264.

Also, I think any input source that uses the default maxFrameSize() 
implementation returning zero will truncate frames with the 
H264VideoFramer because in this case the StreamParser is always able to 
ask for numBytesNeeded which could be much less than the actual frame 
size, It doesn't take into account that zero means unlimited.

Thanks,

Robert Smith.
Shaan Nobee | 8 Mar 10:59 2015

100% cpu usage when 1 or more client connects to RTSP server

Hello everyone!

I would be very grateful if someone could help me out with the issue below, I'm new to live555.

I've got nine audio streams that I'm pulling in via ffmpeg and then re-encoding them to AAC-LC and pushing to udp://127.0.0.1:port_num?pkt_size=1316 (where port_num is replaced by respective port number) The first stream is being pushed to port 10000, the second one to 10001, third one to 10002, etc.

Example for first stream:
ffmpeg -i remotestream [...codec options...] -f mpegts udp://127.0.0.1:10000?pkt_size=1316

I've modified testOnDemandRTSPServer.cpp as shown below. (taken from live555-latest.tar.gz downloaded today - 8 March 2015)
I launch my ffmpeg instances & the rtsp server and connect to it via VLC/another rtsp client.

It works, I do hear the audio stream, however the issue is that as soon as one client connects, the RTSP server uses 100% of the CPU.
As soon as the client disconnects, the CPU usage falls back to normal. Any idea of what could be wrong?

#include "liveMedia.hh"
#include "BasicUsageEnvironment.hh"

UsageEnvironment* env;
Boolean reuseFirstSource = False;
Boolean iFramesOnly = False;

int main(int argc, char** argv) {
  TaskScheduler* scheduler = BasicTaskScheduler::createNew();
  env = BasicUsageEnvironment::createNew(*scheduler);

  RTSPServer* rtspServer = RTSPServer::createNew(*env, 8554, NULL);
  if (rtspServer == NULL) {
    *env << "Failed to create RTSP server: " << env->getResultMsg() << "\n";
    exit(1);
  }

  char const* descriptionString
    = "Session streamed by \"MyRTSPServer\"";

   int NUM_STREAMS = 9;
   char const* streams[] = {"stream1","stream2","stream3","stream4","stream5","stream6","stream7","stream8","stream9"};
   int port = 10000;
 
  for(int i=0;i<NUM_STREAMS;i++)
  {
    const char* streamName = streams[i];
    const char* inputAddressStr = "127.0.0.1";
    portNumBits inputPortNum = port; port++;
    Boolean const inputStreamIsRawUDP = True;
    ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName,descriptionString);
    sms->addSubsession(MPEG2TransportUDPServerMediaSubsession::createNew(*env, inputAddressStr, inputPortNum, inputStreamIsRawUDP));
    rtspServer->addServerMediaSession(sms);

    char* url = rtspServer->rtspURL(sms);
    *env << "\n\"" << streamName << "\" stream, from a UDP Transport Stream input source \n\t(";
    if (inputAddressStr != NULL) {
      *env << "IP multicast address " << inputAddressStr << ",";
    } else {
      *env << "unicast;";
    }
    *env << " port " << inputPortNum << ")\n";
    *env << "Play this stream using the URL \"" << url << "\"\n";
    delete[] url;
  }

  env->taskScheduler().doEventLoop(); // does not return

  return 0; // only to prevent compiler warning
}


Thanks!
Shaan

 

Shaan Nobee

- Corporate Office
Tel: +2302037117  |  Mob: +23052518816  |  Fax: +2302116996
shaan.nobee <at> mauritiustelecom.com
www.mauritiustelecom.com     |     www.orange.mu     |          |    

          
This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Mauritius Telecom - Orange is not liable for messages that have been modified, changed or falsified.

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Daniel Casale | 6 Mar 15:56 2015

delay processing PLAY scale - RTSPServer - live555MediaServer

Hello,

I have a problem when using live555MediaServer. I need to do some work 
when a request arrive and I am just looking at RTSPServer.cpp.

I can stream h264 video perfectly, but when the client send me a PLAY 
scale= 2, the RTSPServer does not see it until about 30 seconds later, 
and after that, all PLAY scale=4 are never seen until a TEARDOWN 
arrives. I captured RTSP packets with wireshark, and the client seems to 
send the request properly. ¿Someone know what is happening?

Thanks,
Daniel Casale

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Deanna Earley | 5 Mar 11:29 2015
Picon

RTSP authentication with special characters

Hello Ross.

The current liveMedia has a bug where it doesn't correctly handle "special" characters in the username and
password strings when passed in the URL.

RFC 3986 (and predecessors) say that anything outside the "reserved" range can be percent encoded, but
liveMedia isn't currently decoding these back to a normalised string.

Resending...
Sending request: DESCRIBE
rtsp://root:ab%40cd <at> 10.1.20.1/axis-media/media.amp?videocodec=h264&streamprofile=Quality RTSP/1.0
CSeq: 4
Authorization: Basic cm9vdDphYiU0MGNk
User-Agent: openRTSP (LIVE555 Streaming Media v2015.03.01)
Accept: application/sdp

The authorisation string decodes to root:ab%40cd where it should decode to root:ab <at> cd (cm9vdDphYkBjZA==)

What are your thoughts on this?
Is there a URL decoder function somewhere in the library that can be dropped in here?

Thanks

--

-- 
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

Gmane