gmane.comp.multimedia.live555.devel

Re: setRTSPResponse accessibility issue

Scott Taylor — 2013-05-21T04:29:40

Thanks Ross! I just realised it might be neater to provide forwarding 
functions in RTSPClientSession, eg:

protected:
     void setRTSPResponse(RTSPServer::RTSPClientConnection* 
ourClientConnection, char const* responseStr) { 
ourClientConnection->setRTSPResponse(responseStr); }
     // Repeat for the other three variants

That way, RTSPClientSession-derived classes can utilise the friend 
access to RTSPClientConnection. Still not ideal, but better than making 
them public?

Regards,
Scott


_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >public.gmane.org
http://lists.live555.com/mailman/listinfo/live-devel

Best way to get video width and height?

Erlandsson, Claes P (CERLANDS — 2013-05-20T18:41:58

 

I receive a mjpeg stream from a Cisco server. In the SDP I see this line:

 

a=fmtp:26 width=704;height=480;4CIF=1

 

When looking at fVideoWidth & fVideoHeight in MediaSubsession they are
always 0 and it looks like they're only populated if "a=x-dimensions:%d,%d"
is found in the SDP.

 

 

Is there another reliable way to grab the video resolution or would you need
to "manually" parse the SDP line above?

 

 

/Claes

_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >public.gmane.org
http://lists.live555.com/mailman/listinfo/live-devel

Re: setRTSPResponse accessibility issue

Ross Finlayson — 2013-05-20T06:46:37

Making the (4) "setRTSPResponse()" functions public wouldn't be ideal (because we don't want *anyone* to be able to call these functions), but because it solves your problem, it's probably a reasonable hack to make in the code.  (It'll be included in the next release of the software.)

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

_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >public.gmane.org
http://lists.live555.com/mailman/listinfo/live-devel

setRTSPResponse accessibility issue

Scott Taylor — 2013-05-20T06:29:33

Hi,

I'm following the instructions in 
RTSPClientSession::handleCmd_GET_PARAMETER() in order to handle RTSP 
GET_PARAMETER properly (using latest 2013.04.30).

I've derived from RTSPClientSession and reimplemented 
handleCmd_GET_PARAMETER(), now I'd like to call 
RTSPClientConnection::setRTSPResponse() like the default implementation 
does (RTSPServer.cpp ln 1806). Unfortunately RTSPClientConnection is a 
separate object and setRTSPResponse() is protected; the default 
implementation in RTSPClientSession has friend access to call it, but my 
derived class doesn't inherit the friendship.

What's the correct way for my derived class to write a response? 
Currently the only solution I can see is to also derive from 
RTSPClientConnection and add a new function that forwards to 
setRTSPResponse (it's not virtual, so I can't just override it). However 
it seems like setRTSPResponse() should simply be public. What say you?

Thanks,
Scott

Re: No data from the VND.ONVIF.METADATA subsession

Michael McCandless — 2013-05-18T22:20:21


OK, thanks for the quick response.

Mike

http://blog.mikemccandless.com
_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >public.gmane.org
http://lists.live555.com/mailman/listinfo/live-devel

Re: No data from the VND.ONVIF.METADATA subsession

Ross Finlayson — 2013-05-18T22:09:35

On May 18, 2013, at 2:42 PM, Michael McCandless <mail-3HZxiW/2Vq53wV+5G2fjvdBPR1lH4CV8< at >public.gmane.org> wrote:


No.  It means that either
- The server camera is not sending any "VND.ONVIF.METADATA" packets, or
- The server is sending "VND.ONVIF.METADATA" packets, but none of them have the RTP "M" bit set.  (The "VND.ONVIF.METADATA" RTP payload format uses the RTP "M" bit to mark the last packet of a 'metadata' (XML) document.  Our client code does not deliver any received metadata until it knows that the whole document has been received.)

In either case, the problem appears to be with your server (camera).


No.  As long as the client sends a RTSP "SETUP" command for that track - which it should - then the server is supposed to send this data (along with the H.264 video data) after the client then sends the RTSP "PLAY" command.


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

_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >p

No data from the VND.ONVIF.METADATA subsession

Michael McCandless — 2013-05-18T21:42:34

I'm using testRTSPClient to pull an RTSP stream, and I noticed the
camera provides two subsessions:

  [URL:"..."]: Initiated the "video/H264" subsession (client ports
56266-56267)
  [URL:"..."]: Set up the "video/H264" subsession (client ports 56266-56267)
  [URL:"..."]: Created a data sink for the "video/H264" subsession
  [URL:"..."]: Initiated the "application/VND.ONVIF.METADATA" subsession
(client ports 49032-49033)
  [URL:"..."]: Set up the "application/VND.ONVIF.METADATA" subsession
(client ports 49032-49033)
  [URL:"..."]: Created a data sink for the "application/VND.ONVIF.METADATA"
subsession
  [URL:"..."]: Started playing session...

And then I proceed to get many frames, but only for the video/H264
subsession.  I never see any data sent to the afterGettingFrame for
the application/VND.ONVIF.METADATA subsession ... is this expected?

I thought this subsession might provide details from the camera like
maybe motion detection events or something (just a guess)...

Or is there something different I ne

Re: newbie: several questions about openrtsp

Anthony Griffiths — 2013-05-18T08:26:04

thanks for your response, my further comments interwoven with your below:

--------------------------------------------------
From: "Ross Finlayson" <finlayson-C8PbJppqpsxBDgjK7y7TUQ< at >public.gmane.org>
Sent: Saturday, May 18, 2013 6:22 AM
To: "LIVE555 Streaming Media - development & use" <live-devel-m22LxytlYjp4ccXRSk2lxg< at >public.gmane.org
Subject: Re: [Live-devel] newbie: several questions about openrtsp

without too much hassle but did throw up a couple of problems.
"LIVE555 Streaming Media" code:

yeah that's the version I got,,
/usr/local/include/liveMedia/liveMedia_version.hh shows:
#define LIVEMEDIA_LIBRARY_VERSION_STRING        "2013.04.30"


to play by copying it to another location and adding .mp4 to the copy.
is *not* a 'mp4'-format file - so you're lucky that you were able to play
the file by adding '.mp4' to the filename :-)

ok, then I suppose the next job is to convert this raw file into a usable
file that players can recognize and play but so far I haven't found a
program designed to do this and

Re: newbie: several questions about openrtsp

Ross Finlayson — 2013-05-18T05:22:57

First, you should make sure that you have the latest version of the "LIVE555 Streaming Media" code:
http://www.live555.com/liveMedia/faq.html#latest-version



The video file is a 'raw' (elementary stream) video file, and therefore is *not* a 'mp4'-format file - so you're lucky that you were able to play the file by adding '.mp4' to the filename :-)



Unfortunately unless you can find a way for us to reproduce this ourselves, you're going to track down this problem yourself.



This, then is apparently a bug in these media player applications, so you'd need to report this to the organizations that develop those applications.



No.



The audio file (like the video file) will be a 'raw' (elementary stream) file, so it's not surprising that media players can't handle it.  You can deduce the type of audio from the file name (whatever it is; you didn't say).


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

_______________________________________________
live-devel mailing list
live-devel-cunTk1M

Re: Patch : Modification of Client MediaSession &Subsession to extend SDP attributes in derived class.

Ross Finlayson — 2013-05-17T13:59:18

The code scans all lines in the SDP description, but never checks the 'version number' of the first ("v=<version>") line.  (E.g., the first line could be "v=mumble\r", and the code would still accept it.)  In this respect, the code is being 'liberal in what it accepts'.

(BTW, the comment in the code about not checking for
// - "a=control:" attributes (to set the URL for aggregate control)
 was incorrect, and should be removed, because we *do* check for that.)



What attributes are these, and which IETF RFC (or Internet-Draft) defines them?  (I'm not going to add anything to the supplied code that encourages people to develop servers that generate non-standard SDP lines.)



Anything that allows users of your product to apply the same changes to their own version of the LIVE555 code...

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

_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >public.gmane.org
http://lists.live555.com/mail

Patch : Modification of Client MediaSession & Subsession to extend SDP attributes in derived class.

Eric HEURTEL — 2013-05-17T11:19:11


Perhaps I miss something, but the following spy shows that first SDP 
line is not analyzed.

      //##### We should really check for:
      // - "a=control:" attributes (to set the URL for aggregate control)
      // - the correct SDP version (v=0)
      if (sdpLine[0] == 'm') break;
+fprintf( stderr, "Parsing %.3s\n", sdpLine );

      // Check for various special SDP lines that we understand:

Anyway, I had to modify Client MediaSession & MediaSubsession classes in 
order to be able to extend SDP attributes in derived class (as I exposed 
you some weeks ago).
Here is the patch, including previous correction (is there a preferred 
way to publish code changes to fulfill the LGPL ?).

diff -r 586a4d995691 -r 9b2ceb7000ee liveMedia/MediaSession.cpp
--- a/liveMedia/MediaSession.cpp    mer. sept. 12 13:13:54 2012 +0200
+++ b/liveMedia/MediaSession.cpp    ven. mai 17 12:27:20 2013 +0200
< at >< at > -102,25 +102,23 < at >< at >
    if (sdpDescription == NULL) return False;

    // Begin by processing all SDP lines until we see th

newbie: several questions about openrtsp

Anthony Griffiths — 2013-05-16T19:41:35

I'm running centos 5 server - command line only
hi all, newbie here, firstly to my surprise openRTSP actually worked
without too much hassle but did throw up a couple of problems.
This is the command that works with my axis 207MW network camera:
openRTSP -d 20 rtsp://<user:password>< at ><cam-ip-afddr>/mpeg4/media.amp
The 20-second video file created has no extension but I can get the file to
play by copying it to another location and adding .mp4 to the copy.
However if I use -4 in the command the program throws back "mdatFloating
point exception" and terminates. I did the google on this but there are no
clear answers. If I add -i the program does create an avi but the resultant
file crashes all my players.  Am I missing some component?
Also the audio file is silent. I don't know what kind of audio file rtsp is
generating because the filename has no extension and none of my players
will play it. Thanks for any pointers.
_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/

Re: SDP - trouble separating audio/video tracks

Ross Finlayson — 2013-05-16T19:54:46

As a RTSP client, you can ask to stream just a single track, but *not* by specifying the track in the URL that you give to the RTSP "DESCRIBE" command.    (That URL must be one that represents the entire stream - i.e., in your example: "rtsp://192.168.1.123/mpeg4" )

Instead, the way you specify which track(s) you want is in the URL that you give to the RTSP "SETUP" command.  (The RTSP client will issue one "SETUP" command for each track that it wants.)  The RTSP "SETUP" command will use an URL that specifies each track that you want - i.e., in your example: "rtsp://192.168.1.123/mpeg4/track1"

This will be done automatically by your RTSP client application, if (and only if) it allows you to choose which track(s) you want.  Our "openRTSP" application does this (using the "-a" and/or "-v" options).  VLC (although it's not our application) apparently does as well, as you noted.



As I noted above, you can't do that.

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

_________________________________

SDP - trouble separating audio/video tracks

Terrance Medina — 2013-05-16T17:51:52

I'm streaming audio/video from an IP camera through VLC as the client. I have no documentation on the camera. I need to use rtsp to stream the audio and video channels separately, but I can't seem to get it to work here. Also, from the SDP message it appears to use Live555 v2009.09.28 as its rtsp server. On other cameras I've been able to use something like rtsp://ip:port/control, but it's not working for me here. Below is the sdp message:

Sending request: DESCRIBE rtsp://192.168.1.123/mpeg4 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
Accept: application/sdp


Received 1308 new bytes of response data.
Received a complete DESCRIBE response:
RTSP/1.0 200 OK
CSeq: 3
Date: Sun, Jan 02 2000 23:48:34 GMT
Content-Base: rtsp://192.168.1.123/mpeg4/
Content-Type: application/sdp
Content-Length: 1147

v=0
o=- 946855189887438 1 IN IP4 192.168.1.123
s=RTSP/RTP stream from Network Video Server
i=mpeg4
t=0 0
a=tool:LIVE555 Streaming Media v2009.09.28
a=type:broadcast
a=control:*
a=range

Re: SDP first line is skipped

Ross Finlayson — 2013-05-16T18:56:08

No, that is incorrect.  The existing code works correctly, parsing all SDP lines.  You're on a 'wild goose chase'.


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

_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >public.gmane.org
http://lists.live555.com/mailman/listinfo/live-devel

SDP first line is skipped

Eric HEURTEL — 2013-05-16T15:06:14

Hi,

I think MediaSession::initializeWithSDP() is not parsing first SDP line 
(which is usually v=0, though unused).
I've corrected it as follow:

   // Begin by processing all SDP lines until we see the first "m="
   char const* sdpLine;
   char const* nextSDPLine = sdpDescription;
   while (1) {
     sdpLine = nextSDPLine;
     if (sdpLine == NULL) break; // there are no m= lines at all
     if (!parseSDPLine(sdpLine, nextSDPLine)) return False;

     //##### We should really check for:
     // - "a=control:" attributes (to set the URL for aggregate control)
     // - the correct SDP version (v=0)
     if (sdpLine[0] == 'm') break;

     // Check for various special SDP lines that we understand:
     if (parseSDPLine_s(sdpLine)) continue;
     ...
   }

Eric
_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >public.gmane.org
http://lists.live555.com/mailman/listinfo/live-devel

Re: Streaming H.264 Movie via RTP

Ross Finlayson — 2013-05-16T14:08:43

You are streaming "RTP" no matter what.  "RTSP" is just the control protocol that's used to set up the parameters for the RTP stream.  If you are streaming via RTP unicast - as you are doing - then you will need a RTSP server (embedded in your transmitting application) to control it.  This is easy to do, however - you can just use "testOnDemandRTSPServer" as a model, and just use the handful of lines of code that set up the "h264ESVideoTest" stream.

(If you are streaming via RTP *multicast*, then you *may* omit using RTSP as a control protocol, and instead pass just a SDP description to each of your receiving multicast client players.  I don't recommend this, though, especially for streaming H.264 video, because the SDP description contains a configuration parameter that depends on the particular characteristic of the H.264 stream.  It's better to just use our RTSP server code to figure out this parameter automatically.)

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

_________________________

Re: Streaming H.264 Movie via RTP

Alex Shihmanter — 2013-05-16T12:56:29

Sorry about that J

When I run the testOnDemandRTSPServer and run the play RTSP url of the H.264
video in vlc 2.0.5 it works just fine (unsurprisingly). But for my
application I need to use RTP, not RTSP.

What do I need to do in order for the live to stream RTP? 

 

From: live-devel-bounces-m22LxytlYjp4ccXRSk2lxg< at >public.gmane.org
[mailto:live-devel-bounces-m22LxytlYjp4ccXRSk2lxg< at >public.gmane.org] On Behalf Of Ross Finlayson
Sent: Monday, May 13, 2013 11:41 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Streaming H.264 Movie via RTP

 

The problem with this construction is that even if I run the
testH264RTSPVideoAudioStreamer

 

I don't know what "testH264RTSPVideoAudioStreamer" is; it's not one of our
applications :-)

 





, I can play the stream (using the URL "rtsp://.") in VLC 1.11 (and 0.8.6
for that matter) but not in VLC 2.0.5. What could be the problem, and how
can I fix that?

 

I'm not sure what the problem is (because VLC is not our software, even
though it use

Re: Can I use single BasicUsageEnvironment to handle multiple RTSP connections?

Cyberman Wu — 2013-05-13T09:29:41

Thanks, it really works. But I encounter another problem: the performance
is even bad that what we did former.

From the profiling result, it's because BasicTaskScheduler::SingleStep()
process at most one socket after select() returned,
If we add all the socket into on scheduler, we call select() the same times
with more fds in fdset, and time used by select()
is almost linear with files in fdset.

I've tried to select one time, and re-select() again only if we checked all
fds ready, and got better performance than what we
did early. But the design is ugly, and I'm not sure if it will works well
under all the situation.

We BasicTaskScheduler choose a design like that? Is there any way to make
live555 suitable for cope with multiple RTSP
streams?



On Thu, Mar 21, 2013 at 12:44 PM, Ross Finlayson <finlayson-C8PbJppqpsxBDgjK7y7TUQ< at >public.gmane.org>wrote:

Re: Streaming H.264 Movie via RTP

Ross Finlayson — 2013-05-13T08:41:15

I don't know what "testH264RTSPVideoAudioStreamer" is; it's not one of our applications :-)



I'm not sure what the problem is (because VLC is not our software, even though it uses our software for its RTSP client implementation).  However, I suggest running our "testRTSPClient" (and then "openRTSP") demo application, to see if it connects to and receives data from your server OK.

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

_______________________________________________
live-devel mailing list
live-devel-cunTk1MwBs/NLCcxxxaBvgC/G2K4zDHf< at >public.gmane.org
http://lists.live555.com/mailman/listinfo/live-devel

Re: Streaming H.264 Movie via RTP

Alex Shihmanter — 2013-05-13T08:35:59

Thanks for the quick answer. 

The problem with this construction is that even if I run the
testH264RTSPVideoAudioStreamer, I can play the stream (using the URL
"rtsp://.") in VLC 1.11 (and 0.8.6 for that matter) but not in VLC 2.0.5.
What could be the problem, and how can I fix that?

 

Thanks, 

Guy.

 

 

 

From: live-devel-bounces-m22LxytlYjp4ccXRSk2lxg< at >public.gmane.org
[mailto:live-devel-bounces-m22LxytlYjp4ccXRSk2lxg< at >public.gmane.org] On Behalf Of Ross Finlayson
Sent: Monday, May 13, 2013 10:50 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Streaming H.264 Movie via RTP

 

I'm streaming an H264 movie using live555. 

 

That's rather vague.  It would help to know specifically how you're doing
the streaming.  In any case, though, it's best if you use RTSP - i.e., your
streaming application should contain a RTSP server.  By using RTSP (i.e., by
giving VLC a "rtsp://" URL), the SDP description for the stream will be
constructed and transferred to the client (VLC) automati