http://permalink.gmane.org/gmane.comp.video.livedotcom.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15179 <pre> OK, thanks for the quick response. Mike http://blog.mikemccandless.com _______________________________________________ live-devel mailing list live-devel&lt; at &gt;lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel </pre> Michael McCandless 2013-05-18T22:20:21 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15178 <pre> On May 18, 2013, at 2:42 PM, Michael McCandless &lt;mail&lt; at &gt;mikemccandless.com&gt; 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&lt; at &gt;lists.live555.com http://lists.live555.com/mailman/listinfo/live-</pre> Ross Finlayson 2013-05-18T22:09:35 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15177 <pre>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</pre> Michael McCandless 2013-05-18T21:42:34 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15176 <pre>thanks for your response, my further comments interwoven with your below: -------------------------------------------------- From: "Ross Finlayson" &lt;finlayson&lt; at &gt;live555.com&gt; Sent: Saturday, May 18, 2013 6:22 AM To: "LIVE555 Streaming Media - development &amp; use" &lt;live-devel&lt; at &gt;ns.live555.com 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 I have tried a couple. Can you recommend a program </pre> Anthony Griffiths 2013-05-18T08:26:04 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15175 <pre> 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&lt; at &gt;lists.l</pre> Ross Finlayson 2013-05-18T05:22:57 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15174 <pre> The code scans all lines in the SDP description, but never checks the 'version number' of the first ("v=&lt;version&gt;") 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&lt; at &gt;lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel </pre> Ross Finlayson 2013-05-17T13:59:18 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15173 <pre> 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 &amp; 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 &lt; at &gt;&lt; at &gt; -102,25 +102,23 &lt; at &gt;&lt; at &gt; if (sdpDescription == NULL) return False; // Begin by processing all SDP lines until we see th</pre> Eric HEURTEL 2013-05-17T11:19:11 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15172 <pre>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://&lt;user:password&gt;&lt; at &gt;&lt;cam-ip-afddr&gt;/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&lt; at &gt;lists.live5</pre> Anthony Griffiths 2013-05-16T19:41:35 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15171 <pre>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/ _________________________________</pre> Ross Finlayson 2013-05-16T19:54:46 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15170 <pre>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</pre> Terrance Medina 2013-05-16T17:51:52 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15169 <pre> 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&lt; at &gt;lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel </pre> Ross Finlayson 2013-05-16T18:56:08 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15168 <pre>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&lt; at &gt;lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel </pre> Eric HEURTEL 2013-05-16T15:06:14 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15167 <pre> 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/ _________________________</pre> Ross Finlayson 2013-05-16T14:08:43 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15166 <pre>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&lt; at &gt;ns.live555.com [mailto:live-devel-bounces&lt; at &gt;ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, May 13, 2013 11:41 AM To: LIVE555 Streaming Media - development &amp; 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 uses our software for its RTSP client implementation)</pre> Alex Shihmanter 2013-05-16T12:56:29 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15165 <pre>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 &lt;finlayson&lt; at &gt;live555.com&gt;wrote: </pre> Cyberman Wu 2013-05-13T09:29:41 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15164 <pre> 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&lt; at &gt;lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel </pre> Ross Finlayson 2013-05-13T08:41:15 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15163 <pre>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&lt; at &gt;ns.live555.com [mailto:live-devel-bounces&lt; at &gt;ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, May 13, 2013 10:50 AM To: LIVE555 Streaming Media - development &amp; 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) automatically; you won't need to create a SDP file yoursel</pre> Alex Shihmanter 2013-05-13T08:35:59 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15162 <pre> 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) automatically; you won't need to create a SDP file yourself. (Generally speaking, SDP files are recommended only for use with multicast streams.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel&lt; at &gt;lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel </pre> Ross Finlayson 2013-05-13T07:50:00 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15161 <pre>Hi, I'm streaming an H264 movie using live555. I figured out you need an SDP file in order to play the stream in VLC, so I built one and was able to play my stream. The problem is, after I upgraded my VLC to 2.0.5, the VLC won't play my stream. The SDP file I use is: v=0 o=- 1277647151953158 1 IN IP4 190.40.14.100 s=Session streamed by "testH264VideoAudioStreamer" i=test-h264-mux.mpg t=0 0 a=tool:LIVE555 Streaming Media v2007.05.24 a=recvonly a=type:broadcast a=charset:UTF-8 a=source-filter: incl IN IP4 * 190.40.14.100 m=video 8554 RTP/AVP 96 c=IN IP4 190.40.15.10/7 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1; profile-level-id=64001f;sprop-parameter-sets=Z2QAH6zZQLQ9sBEAAAMD6QAB1MCPGDG W,aOvjyyLA; I know it's not a networking problem. Somehow, the VLC 2.0.5 won't play my SDP file, even though the 1.1.11 version of VLC can play it. The VLC 2.0.5 says: "live555 error: no data received in 10s, aborting" This could possibly be a problem in VLC as if I stream the m</pre> Alex Shihmanter 2013-05-13T05:38:10 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15160 <pre>Make sure also that you're setting "fPresentationTime" correctly. It should be the time at which the first sample in the delivered buffer was captured. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel&lt; at &gt;lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel </pre> Ross Finlayson 2013-05-10T22:17:44 http://permalink.gmane.org/gmane.comp.video.livedotcom.devel/15159 <pre>Greetings, Thank you Ross for your response mid-week. I believe I've correctly implemented your suggestion, but I'm still experiencing the same issue. Recap: I'm trying to send mu-law audio over RTP. The audio comes from the microphone on an ios device, via AudioQueue. I'm following testWaveAudioStreamer. I've subclassed FramedSource and pass the audio through uLawFromPCMAudioSource after it's stored in a circular FIFO buffer (after being returned from the ios AudioQueue callback after mic capture). Issue: I get "skipping" ~ 0.5 sec audio, then ~ 0.5 sec silence. The buffer is still under running (causing a sleep in deliverFrame() which I believe should never be happening once I have this correctly implemented). As per Ross' excellent suggestion I've set fDurationInMicroseconds like this: int fNumChannels =1; int fBitsPerSample = 16; int fSamplingFrequency = 8000; unsigned fPlayTimePerSample = 1e6/(double)fSamplingFrequency; unsigned bytesPerSample = (fNumChannels*fBitsPerSam</pre> Braden Ackerman 2013-05-10T17:50:38 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.livedotcom.devel