From glqg8 at 126.com Thu Sep 1 01:11:09 2011 From: glqg8 at 126.com (glqg8) Date: Thu, 1 Sep 2011 16:11:09 +0800 (CST) Subject: [Live-devel] When I use the openrtsp player (rtp over tcp) to play live555MediaServer server 264 file, it can not play, what is the problem? Message-ID: <270627cd.300.132240aa202.Coremail.glqg8@126.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yangwudi3110 at gmail.com Thu Sep 1 01:49:01 2011 From: yangwudi3110 at gmail.com (=?GB2312?B?0e6zrA==?=) Date: Thu, 1 Sep 2011 16:49:01 +0800 Subject: [Live-devel] how to stream TS file to STB via Raw UDP Message-ID: >>Thanks for your reply. Now I'm trying to do a simple Streaming Server to stream TS stream to client(mostly STB). I decided to use testOnDemandRTSPServer as model.And I have a "raw" rule about RTSP Request/Reply between Clien&Server, so I can ensure the server can 'understand' the request from client to let it stream via UDP only. So the important things now I have to do is two: 1:change the transfer way from multicast to unicast. I notice that the similar file testMPEG2TransportStreamer.cpp can easily do such change, and I got the right result after change the IP address("239.255.42.42"------> "192.168.10.152"). So I want to ask is testOnDemandRTSPServer can do so too? And what should I do if not? 2: You told me when not use RTSP-over-HTTP tunneling, it use RTP/RTCP packets all carried in UDP. Now I want to use raw UDP. I just want to put PURE 7 Ts packets on UDP. Do I still need to modify your original function in files( I mean the code about puting packets on RTP , do I need to replace them with my new code to put ts packets on UDP only) ? Sorry for my ugly English.... > Message: 3 > Date: Tue, 30 Aug 2011 02:07:18 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] how to stream TS file to STB via Raw UDP > Message-ID: <63B2EA89-B051-46C5-A229-73544FBCE118 at live555.com> > Content-Type: text/plain; charset="us-ascii" > > If you use "RTSP-over-HTTP" tunneling, then RTSP commands and responses, and > RTP packets, and RTCP packets, are *all* carried over HTTP (and thus TCP), > not UDP. > > If you don't use "RTSP-over-HTTP" tunneling, then RTSP commands and > responses are carried over HTTP (and thus TCP), but RTP packets and RTCP > packets are carried over UDP. This is the default behavior. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > From tech at digiton.ru Fri Sep 2 00:14:11 2011 From: tech at digiton.ru (Dmitriy Vasil'ev) Date: Fri, 2 Sep 2011 11:14:11 +0400 Subject: [Live-devel] building live555 in VS 2010 In-Reply-To: References: Message-ID: I can send to you my VC10 project, if need. From: Jasleen Kaur Sent: Tuesday, August 30, 2011 9:16 AM To: mailto:live-devel at ns.live555.com Subject: [Live-devel] building live555 in VS 2010 I have been trying to build the make files using Visual Studio 10. I am facing problems while running the nmake for the mak files. I have attached the screenshot of the problem seen. It says 'Fatal Error U1073: dont know how to make 'include/livemedia_version.hh' on building livemedia.mak Pls guide. Best Regards Jasleen Kaur -------------------------------------------------------------------------------- _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tech at digiton.ru Fri Sep 2 00:23:20 2011 From: tech at digiton.ru (Dmitriy Vasil'ev) Date: Fri, 2 Sep 2011 11:23:20 +0400 Subject: [Live-devel] bug in the mp3 receiver In-Reply-To: <0F8258F0-E68C-451C-9ED9-0D5D93A26B80@live555.com> References: <9EA36DA1B13E4BA3B1F7740A18FCA6BC@tech><688F18DD-9664-467A-B454-16771EA425CE@live555.com><74016DB8091B4F6DBC5A9845892F7F40@tech> <0F8258F0-E68C-451C-9ED9-0D5D93A26B80@live555.com> Message-ID: Transmitter may be restarted, this is normal work situation. If this is not a bug, how I can receive stream? From: Ross Finlayson Sent: Monday, August 29, 2011 10:17 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] bug in the mp3 receiver OK, the problem is that the receiver is expecting a single, continuous RTP stream. When you stop, then restart the streamer, there's a 50% chance that the next RTP sequence numbers (which start out at a randomly-chosen value) will be less than the previous ones. If that happens, the new incoming RTP packets will be rejected. This is not a bug. You are simply not using the applications in the way that they were intended. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 2 01:33:50 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Sep 2011 01:33:50 -0700 Subject: [Live-devel] bug in the mp3 receiver In-Reply-To: References: <9EA36DA1B13E4BA3B1F7740A18FCA6BC@tech><688F18DD-9664-467A-B454-16771EA425CE@live555.com><74016DB8091B4F6DBC5A9845892F7F40@tech> <0F8258F0-E68C-451C-9ED9-0D5D93A26B80@live555.com> Message-ID: > Transmitter may be restarted, this is normal work situation. > If this is not a bug, how I can receive stream? Whenever you stop/restart the transmitter, you can also stop/restart the receiver "testMP3Receiver". But when you restart it, append its output to the original received data file. I.e., use ">>" instead of ">". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tech at digiton.ru Fri Sep 2 01:55:04 2011 From: tech at digiton.ru (Dmitriy Vasil'ev) Date: Fri, 2 Sep 2011 12:55:04 +0400 Subject: [Live-devel] bug in the mp3 receiver In-Reply-To: References: <9EA36DA1B13E4BA3B1F7740A18FCA6BC@tech><688F18DD-9664-467A-B454-16771EA425CE@live555.com><74016DB8091B4F6DBC5A9845892F7F40@tech><0F8258F0-E68C-451C-9ED9-0D5D93A26B80@live555.com>

Message-ID: <59C0876C2F4B443F81D5AF4EB8919048@tech> yes, I understand, in current situation I must restart receiver. But if I have remote receiver, it can not be restarted. How I must change the code of the transmitter or receiver to receive stream if the transmitter was restarted? From: Ross Finlayson Sent: Friday, September 02, 2011 12:33 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] bug in the mp3 receiver Transmitter may be restarted, this is normal work situation. If this is not a bug, how I can receive stream? Whenever you stop/restart the transmitter, you can also stop/restart the receiver "testMP3Receiver". But when you restart it, append its output to the original received data file. I.e., use ">>" instead of ">". 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 2 13:59:09 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Sep 2011 13:59:09 -0700 Subject: [Live-devel] bug in the mp3 receiver In-Reply-To: References: <9EA36DA1B13E4BA3B1F7740A18FCA6BC@tech><688F18DD-9664-467A-B454-16771EA425CE@live555.com><74016DB8091B4F6DBC5A9845892F7F40@tech> <0F8258F0-E68C-451C-9ED9-0D5D93A26B80@live555.com> Message-ID: <717522F4-772C-4A5A-AB45-E7ABBECAD047@live555.com> > Transmitter may be restarted, this is normal work situation. > If this is not a bug, how I can receive stream? Thinking about this some more, I realized that there is something that we can do. When the transmitter restarts, the RTP SSRC will (almost always) change. The receiver can notice this change, and avoid the usual sequence number check in this case. I have now installed a new version (2011.09.02) of the "LIVE555 Streaming Media" code that includes this change. This should work for you now. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.mal at xl.wp.pl Fri Sep 2 04:20:23 2011 From: simon.mal at xl.wp.pl (Szymon Malewski) Date: Fri, 02 Sep 2011 13:20:23 +0200 Subject: [Live-devel] Server moved to 64bit - packet loss In-Reply-To: References: Message-ID: <4e60bbf716b171.47044840@wp.pl> Sat, 27 Aug 2011 22:52:11, Ross Finlayson wrote: > > Then I moved server to another machine and I'm experiencing severe packet loss (60-70%) at client side. > > I'm not familiar with statistics in Live555, for quick check I've added packets counters in GroupsockHelper.cpp in writeSocket and readSocket. Client receives about 1/3 of sent packets. Lowering framerate didn't help much. > > On the other hand tcpstat shows correct traffic network on both sides. > > Well, if the *only* difference between the two setups is that the server is running on a different machine, then it should be easy to see - by looking at the network traffic - what's different about the new server's packets that's causing packet loss at the client. I checked packets in wireshark and on the server side they are correct (the same as in working configuration), but on the client side some packets are not captured by wireshark. > I suspect, however, that this is not the only difference between the two setups. Are you sure that the new server is not running on a different LAN, or that it's not behind a firewall or a different router? I am sure. Streaming works in one direction but doesn't work in another. The are no firewalls. I have tested it on several different computers, running Ubuntu Live CD - with default settings, just increased UDP buffer size. On 32bit computers it works fine. On 64bit computers with 64bit system I doesn't work On 64bit computers with 32bit system it works fine. I guess it might be problem with network card drivers or sth like that. Now I am using server on virtual machine with 32bit system and for some time it is enough. Szymon From tech at digiton.ru Mon Sep 5 03:23:51 2011 From: tech at digiton.ru (Dmitriy Vasil'ev) Date: Mon, 5 Sep 2011 14:23:51 +0400 Subject: [Live-devel] bug in the mp3 receiver In-Reply-To: <717522F4-772C-4A5A-AB45-E7ABBECAD047@live555.com> References: <9EA36DA1B13E4BA3B1F7740A18FCA6BC@tech><688F18DD-9664-467A-B454-16771EA425CE@live555.com><74016DB8091B4F6DBC5A9845892F7F40@tech><0F8258F0-E68C-451C-9ED9-0D5D93A26B80@live555.com> <717522F4-772C-4A5A-AB45-E7ABBECAD047@live555.com> Message-ID: <99EC3556E9CC45FFAE58DF054B3D5CA4@tech> Thank you! Now need not restarting of the receiver. All work correctly, if I do restart of the transmitter. Best regards, Dmitriy From: Ross Finlayson Sent: Saturday, September 03, 2011 12:59 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] bug in the mp3 receiver Transmitter may be restarted, this is normal work situation. If this is not a bug, how I can receive stream? Thinking about this some more, I realized that there is something that we can do. When the transmitter restarts, the RTP SSRC will (almost always) change. The receiver can notice this change, and avoid the usual sequence number check in this case. I have now installed a new version (2011.09.02) of the "LIVE555 Streaming Media" code that includes this change. This should work for you now. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hallakstamler at gmail.com Sun Sep 4 21:48:10 2011 From: michael.hallakstamler at gmail.com (Michael Hallak-Stamler) Date: Mon, 5 Sep 2011 07:48:10 +0300 Subject: [Live-devel] Transport Stream Message-ID: Hi, I am working on getting LIVE555 to generate a stable transport stream from a H.264 source with high VBR. Our CODEC generates P frames much smaller and with high variance compared to I frames. The problems I have are as follows: 1. I am using testH264VideoToTransportStream to generate the TS 2. I notice that the code generates PTS only but not DTS. I discovered that the difference between these are used to define the decode buffer at the client. Why is it not included here? 3. The PCR is generated from the presentation time stamp, OK. However, how do you keep the PCR within the stringent requirements of +/- 500 ns from 27MHZ? 4. Also: Doesn't the client expected a CBR on the line between PCR occurences? These issues are particularly important for clients that use a hardware PLL to compute its PCR. This is the problem I am facing. When I use a software client, say VLC, then all works flawlessly. Comments? Thanks for your great work on LIVE555 Michael Stamler, CEO Xicore Video Technologies www.xicore.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From sampreeth at gmail.com Mon Sep 5 02:01:57 2011 From: sampreeth at gmail.com (sampreeth ramavana) Date: Mon, 5 Sep 2011 14:31:57 +0530 Subject: [Live-devel] SRTP support Message-ID: Hi, Does live555 support SRTP or is it planned in the near future? Regards, Sampreeth From finlayson at live555.com Mon Sep 5 15:37:35 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Sep 2011 15:37:35 -0700 Subject: [Live-devel] SRTP support In-Reply-To: References: Message-ID: <34F77189-116A-4B47-B4E9-A72711389307@live555.com> > Does live555 support SRTP No. > or is it planned in the near future? The future, yes - but not the 'near future'. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 5 17:14:50 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Sep 2011 17:14:50 -0700 Subject: [Live-devel] Transport Stream In-Reply-To: References: Message-ID: <1E552877-83F8-4AC0-A7CC-A5705AB138F1@live555.com> Michael, Thanks for the note. The main goal in writing this code was to produce Transport Streams that could be played OK by software media players (for example, VLC). It would not be surprising, therefore, if the resulting Transport Streams did not conform to the strict timing requirements required for some hardware decoders. We use presentation times as input to the Transport Stream generation code ("MPEG2TransportStreamFromESSource") because these are - in general - the only timestamps that we have available to us, and the only timestamps that we use when we're sending or receiving RTP. (The "LIVE555 Streaming Media" code is intended primarily for sending/receiving RTP, even though it can be used for other purposes (such as, in this case, converting a local H.264 stream into a Transport Stream).) Nonetheless, any (general purpose) improvements to the "MPEG2TransportStreamFromESSource" and/or "H264VideoStreamFramer" code are always appreciated. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at kanargh.force9.co.uk Wed Sep 14 12:32:42 2011 From: john at kanargh.force9.co.uk (John Sullivan) Date: Wed, 14 Sep 2011 20:32:42 +0100 Subject: [Live-devel] live555 (via vlc) and WMS Message-ID: <736013304.20110914203242@kanargh.force9.co.uk> I just hit an upgrade from live555-0-0.27.2010.04.09.fc14 to live555-0-0.30.2011.01.24.fc15 (rpmfusion builds for Fedora) which broke a local hack I was using - I was meaning to push it at some point and now seems like a good opportunity to try and get a proper supported fix in. I was doing: --- live.orig/liveMedia/RTSPClient.cpp.jsorig 2011-08-18 18:29:38.981817871 +0100 +++ live/liveMedia/RTSPClient.cpp 2011-08-18 18:32:56.390261409 +0100 @@ -981,7 +981,7 @@ "%s" "\r\n"; - char const* sessURL = sessionURL(session); + char const* sessURL = fServerIsMicrosoft ? fBaseURL : sessionURL(session); unsigned cmdSize = strlen(cmdFmt) + strlen(sessURL) + 20 /* max int len */ But I now see that fServerIsMicrosoft is missing and the Server header isn't parsed with the code comment: // For now, omit parsing the "Server:" header (unless someone // convinces us that we still need to treat Windows Media Server // especially Hopefully I can do that! The issue is (as you can tell from the patch) URL generation under some circumstances. For normal RTSP to WMS, using vlc (which uses live555): URL = rtsp://server/filename.wmv SDP session control = rtsp://server/filename.wmv/ SDP subsession control = video SETUP rtsp://server/filename.wmv/video PLAY rtsp://server/filename.wmv/ This works. If however we try and pass a query string: URL = rtsp://server/filename.wmv?param=56565 SDP session control = rtsp://server/filename.wmv?param=56565/ SDP subsession control = rtsp://server/filename.wmv/video SETUP rtsp://server/filename.wmv/video PLAY rtsp://server/filename.wmv?param=56565/ <--- 400 Bad Request WMS generates a session control attribute it itself can't understand. It appears to realise this partially and fixes up the subsession URL so that SETUP still works, but will not accept the session URL in the PLAY command. WMP appears to use the SDP session and subsession URLs for SETUP, but ignores the SDP for PLAY and other aggregate level commands such as TEARDOWN etc. and simply uses the original base URL. This may be non-standard, but WMP and WMS appear to rely on this, in this case. (For clarity: WMP ignores the SDP control even in the former case and always generates a PLAY without the terminal slash. vlc works too in this case because WMS doesn't appear to care whether a URL without a query string ends in a slash or not. But with the query string, using the original URL is critical.) John -- Dead stars still burn From finlayson at live555.com Thu Sep 15 18:50:59 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Sep 2011 18:50:59 -0700 Subject: [Live-devel] live555 (via vlc) and WMS In-Reply-To: <736013304.20110914203242@kanargh.force9.co.uk> References: <736013304.20110914203242@kanargh.force9.co.uk> Message-ID: <43766E87-B013-4C5C-A212-22193D8ABA2F@live555.com> > I just hit an upgrade from live555-0-0.27.2010.04.09.fc14 to > live555-0-0.30.2011.01.24.fc15 (rpmfusion builds for Fedora) BTW, this might not be the latest version of the code (which is the only version that we support). For information on how to check this, see http://www.live555.com/liveMedia/faq.html#latest-version In any case, I'm sorry to tell you that we no longer add special-case client code - based on the "Server:" header string - to handle bugs and non-standard behavior in specific servers. (We stopped doing this about a year and a half ago.) We had done this for several years, but it because it provided absolutely no incentive for the server manufacturers to fix their code, it just ended up leaving our code cluttered up with ugly hacks that never went away. So, when I did a major cleanup/rewrite of the RTSP client code (about a year and a half ago), I removed the special-case hacks, and do not plan to reintroduce them. Instead, when people discover bugs in servers, they need to report them to the server manufacturers (in this case Microsoft). That's the best way to improve interoperability with other standard clients (i.e., not just ours). Our code now has a sufficiently large installed base to help pressure server manufacturers to better conform to standards. Alternatively, of course, there's always the possibility of switching to use a different server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nunzianteantonio at gmail.com Fri Sep 16 02:05:14 2011 From: nunzianteantonio at gmail.com (antonio nunziante) Date: Fri, 16 Sep 2011 11:05:14 +0200 Subject: [Live-devel] Onvif Metadata Message-ID: Hi all, has anyone experience on reproducing Onvif stream with Live555? In particular I need some information on how read analytics metadata in the Onvif stream and use them to draw on my player. Thanks -- * Antonio Nunziante * -------------- next part -------------- An HTML attachment was scrubbed... URL: From lex_87 at mail.ru Fri Sep 16 05:46:38 2011 From: lex_87 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzQuNGF0LDQudC70L7Qsg==?=) Date: Fri, 16 Sep 2011 16:46:38 +0400 Subject: [Live-devel] =?utf-8?q?How_to_stream_bit_map_over_RTSP=3F?= Message-ID: Hello Sorry my bad english, i'm from Russia.? How i can stream over RTSP just JPEG file or a user-defined bitmap object? I need whole application example or example code for creation a server and sending to doEventLoop() I would not take much time,? so I want to ask links to forum threads or more info.? Help me please.? My regards. Great thanx for beatiful code.???? -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.marks at outstanding-solutions.de Mon Sep 19 02:28:04 2011 From: volker.marks at outstanding-solutions.de (Volker Marks) Date: Mon, 19 Sep 2011 11:28:04 +0200 Subject: [Live-devel] Liveness and PassiveServerMediaSubsession Message-ID: <000001cc76ae$6efe7a20$4cfb6e60$@outstanding-solutions.de> Hi all! We are sending several H.264- and AAC-Streams using custom frame sources and PassiveServerMediaSubsession objects. When using VLC as a client the server keeps the connection (I guess because VLC periodically calls "GET_PARAMETER"). But when using an openRTSP based client the RTSPServer removes the client session in "livenessTimeoutTask". As documented in "PassiveServerMediaSubsession::startStream" no RRHandler is being installed. I guess that we have to set one on our own, but I'm not sure where to call "setRRHandler" or "setSpecificRRHandler" or whether there is a different approach making more sense. BTW: Setting "reclamationTestSeconds" to zero is not really an option as we need to whether (and which) clients are connected. How do we keep the connection alive? Thanks in advance Volker From finlayson at live555.com Mon Sep 19 15:26:53 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Sep 2011 15:26:53 -0700 Subject: [Live-devel] Liveness and PassiveServerMediaSubsession In-Reply-To: <000001cc76ae$6efe7a20$4cfb6e60$@outstanding-solutions.de> References: <000001cc76ae$6efe7a20$4cfb6e60$@outstanding-solutions.de> Message-ID: > As documented in "PassiveServerMediaSubsession::startStream" no RRHandler is > being installed. This was necessary - at the time - due to a limitation in our software. I've now fixed this, and installed a new version (2011.09.19) of the software that does RTCP "RR" handling even for "PassiveServerMediaSubsession"s. This should fix your problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 19 22:28:50 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Sep 2011 22:28:50 -0700 Subject: [Live-devel] How to stream bit map over RTSP? In-Reply-To: References: Message-ID: <656AE5D0-98D4-45F2-AD1C-BD8E765B5006@live555.com> > How i can stream over RTSP just JPEG file or a user-defined bitmap object? You don't 'stream' a single object (e.g., a file). Instead, you stream a time-based sequence of objects - e.g., a sequence of video or audio frames. If you want to transfer a single file object, then you don't use our software; instead, you can just use HTTP. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 19 22:29:25 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Sep 2011 22:29:25 -0700 Subject: [Live-devel] Onvif Metadata In-Reply-To: References: Message-ID: <50A9A285-C712-4B6D-ADC5-6B1912311F4F@live555.com> > has anyone experience on reproducing Onvif stream with Live555? In particular I need some information on how read analytics metadata in the Onvif stream and use them to draw on my player. What RTP payload format does this streamed 'metadata' use? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.glaude at gmail.com Sun Sep 18 02:27:50 2011 From: david.glaude at gmail.com (David Glaude) Date: Sun, 18 Sep 2011 11:27:50 +0200 Subject: [Live-devel] live555 (via vlc) and WMS In-Reply-To: <43766E87-B013-4C5C-A212-22193D8ABA2F@live555.com> References: <736013304.20110914203242@kanargh.force9.co.uk> <43766E87-B013-4C5C-A212-22193D8ABA2F@live555.com> Message-ID: I can fully understand the logic of making it not working to force the vendor to respect the standard... However this is likely to fail in the present case, for Microsoft and Windows Media Streaming Server. This is legacy technology for Microsoft, they only focus on Smooth Streaming and accessing it with Silverlight so they are unlikely to fix it. As far as I know, only a Windows Media Streaming Server can stream an ASF (*.wmv) file and there is no alternative. Even if user could switch to another Streaming Server, this will not change the kind of Streaming Server that CDNs capable of streaming WMV all over the world. What is really odd here is the timing. How come that decision from a year and a half ago has consequence only now? Is this due to wich version of Live555 VLC is or was using? David Glaude 2011/9/16 Ross Finlayson > I just hit an upgrade from live555-0-0.27.2010.04.09.fc14 to > live555-0-0.30.2011.01.24.fc15 (rpmfusion builds for Fedora) > > > BTW, this might not be the latest version of the code (which is the only > version that we support). For information on how to check this, see > http://www.live555.com/liveMedia/faq.html#latest-version > > In any case, I'm sorry to tell you that we no longer add special-case > client code - based on the "Server:" header string - to handle bugs and > non-standard behavior in specific servers. (We stopped doing this about a > year and a half ago.) We had done this for several years, but it because it > provided absolutely no incentive for the server manufacturers to fix their > code, it just ended up leaving our code cluttered up with ugly hacks that > never went away. So, when I did a major cleanup/rewrite of the RTSP client > code (about a year and a half ago), I removed the special-case hacks, and do > not plan to reintroduce them. > > Instead, when people discover bugs in servers, they need to report them to > the server manufacturers (in this case Microsoft). That's the best way to > improve interoperability with other standard clients (i.e., not just ours). > Our code now has a sufficiently large installed base to help pressure > server manufacturers to better conform to standards. > > Alternatively, of course, there's always the possibility of switching to > use a different server. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Sep 19 22:58:52 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Sep 2011 22:58:52 -0700 Subject: [Live-devel] live555 (via vlc) and WMS In-Reply-To: References: <736013304.20110914203242@kanargh.force9.co.uk> <43766E87-B013-4C5C-A212-22193D8ABA2F@live555.com> Message-ID: > What is really odd here is the timing. How come that decision from a year and a half ago has consequence only now? > Is this due to wich version of Live555 VLC is or was using? Yes, although most VLC users are using a version of LIVE555 that's even more recent than yours. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nunzianteantonio at gmail.com Mon Sep 19 23:57:19 2011 From: nunzianteantonio at gmail.com (antonio nunziante) Date: Tue, 20 Sep 2011 08:57:19 +0200 Subject: [Live-devel] Onvif Metadata In-Reply-To: <50A9A285-C712-4B6D-ADC5-6B1912311F4F@live555.com> References: <50A9A285-C712-4B6D-ADC5-6B1912311F4F@live555.com> Message-ID: The metadata stream should follow the ONVIF core specifications: http://www.onvif.org/imwp/download.asp?ContentID=16154 In few days I'll receive an Axis camera that produces a stream like this and I need to implement an application that reproduces video and draws overlay according metadata stream. Could you show me such examples of works with Live555 + Onvif? Thank you so much! -Antonio 2011/9/20 Ross Finlayson > has anyone experience on reproducing Onvif stream with Live555? In > particular I need some information on how read analytics metadata in the > Onvif stream and use them to draw on my player. > > > What RTP payload format does this streamed 'metadata' use? > > > 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 > > -- * Antonio Nunziante * -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 20 00:09:45 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Sep 2011 00:09:45 -0700 Subject: [Live-devel] Onvif Metadata In-Reply-To: References: <50A9A285-C712-4B6D-ADC5-6B1912311F4F@live555.com> Message-ID: > Could you show me such examples of works with Live555 + Onvif? No I can't. However, if *you* can show *me* an example of a publically-accessible "rtsp://" URL for the type of stream that you're interested in receiving, then I might be able to tell you whether our software can support it (or, if it can't, then perhaps whether if might be able to support it sometime in the future). If, however, you can't do this, then I'm not going to be able help you. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nunzianteantonio at gmail.com Tue Sep 20 00:28:05 2011 From: nunzianteantonio at gmail.com (antonio nunziante) Date: Tue, 20 Sep 2011 09:28:05 +0200 Subject: [Live-devel] Onvif Metadata In-Reply-To: References: <50A9A285-C712-4B6D-ADC5-6B1912311F4F@live555.com>

Message-ID: Thank you Ross, but at the moment I'm not able to public any rtsp url. I found this project on source forge that utilizes Live55: http://sourceforge.net/projects/onvifdm/ 2011/9/20 Ross Finlayson > Could you show me such examples of works with Live555 + Onvif? > > > No I can't. > > However, if *you* can show *me* an example of a publically-accessible > "rtsp://" URL for the type of stream that you're interested in receiving, > then I might be able to tell you whether our software can support it (or, if > it can't, then perhaps whether if might be able to support it sometime in > the future). > > If, however, you can't do this, then I'm not going to be able help you. > Sorry. > > > 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 > > -- * Antonio Nunziante * -------------- next part -------------- An HTML attachment was scrubbed... URL: From lex_87 at mail.ru Tue Sep 20 02:57:37 2011 From: lex_87 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzQuNGF0LDQudC70L7Qsg==?=) Date: Tue, 20 Sep 2011 13:57:37 +0400 Subject: [Live-devel] =?utf-8?q?How_to_stream_bit_map_over_RTSP=3F?= In-Reply-To: <656AE5D0-98D4-45F2-AD1C-BD8E765B5006@live555.com> References: <656AE5D0-98D4-45F2-AD1C-BD8E765B5006@live555.com> Message-ID: Thank you for your response. I need stream uncompressed video frames, e.g. bitmap or user-defined bitmap.? How i can send readable time-based video frame sequence to stream.? Is it possible? If possible how to do this?? Thanx in advance =) 20 ???????? 2011, 09:39 ?? Ross Finlayson : How i can stream over RTSP just JPEG file or a user-defined bitmap object? You don't 'stream' a single object (e.g., a file). ?Instead, you stream a time-based sequence of objects - e.g., a sequence of video or audio frames. If you want to transfer a single file object, then you don't use our software; instead, you can just use HTTP. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Sep 20 07:37:12 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Sep 2011 07:37:12 -0700 Subject: [Live-devel] How to stream bit map over RTSP? In-Reply-To: References: <656AE5D0-98D4-45F2-AD1C-BD8E765B5006@live555.com> Message-ID: <8C9E7C6E-355E-41ED-A89C-32AD1538EE7A@live555.com> > I need stream uncompressed video frames, e.g. bitmap or user-defined bitmap. > How i can send readable time-based video frame sequence to stream. > Is it possible? If possible how to do this? Sorry, but we don't currently support the RTP payload format for uncompressed video (sending or receiving). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tech at digiton.ru Wed Sep 21 01:06:17 2011 From: tech at digiton.ru (Dmitriy Vasil'ev) Date: Wed, 21 Sep 2011 12:06:17 +0400 Subject: [Live-devel] SIPClient Message-ID: <16207EF0A57C456E8FE0419A30B897E8@tech> Hello, SIPClient.cpp, line 500 if (sscanf(lineStart, "Content-Length: %d", &contentLength) == 1 || sscanf(lineStart, "Content-Length: %d", &contentLength) == 1) { Is this bug? May be: if (sscanf(lineStart, "Content-Length: %d", &contentLength) == 1 || sscanf(lineStart, "Content-Length:%d", &contentLength) == 1) { ? Best regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 21 01:16:14 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 21 Sep 2011 01:16:14 -0700 Subject: [Live-devel] SIPClient In-Reply-To: <16207EF0A57C456E8FE0419A30B897E8@tech> References: <16207EF0A57C456E8FE0419A30B897E8@tech> Message-ID: <032A67EF-CD43-4EC6-B080-396D11247F70@live555.com> Yes, it was a bug, but the code was actually supposed to be: if (sscanf(lineStart, "Content-Length: %d", &contentLength) == 1 || sscanf(lineStart, "Content-length: %d", &contentLength) == 1) { (Whitespace in the "sscanf()" format string matches any amount of whitespace, including none.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From htgirish at gmail.com Wed Sep 21 09:34:23 2011 From: htgirish at gmail.com (Girish H T) Date: Wed, 21 Sep 2011 22:04:23 +0530 Subject: [Live-devel] Live555 android port Message-ID: Hi all, Is there any live555 port available on android platform ? I want to use live555 on android for live camera multicasting. Give some pointers. Regards Girish -------------- next part -------------- An HTML attachment was scrubbed... URL: From nandan.amar at gmail.com Wed Sep 21 11:29:26 2011 From: nandan.amar at gmail.com (nandan amar) Date: Wed, 21 Sep 2011 23:59:26 +0530 Subject: [Live-devel] video packetizatin for RTP payload Message-ID: I have a basic query regarding how video is packetized for transmission (over UDP) by liveMedia. -- Amar -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 22 16:00:49 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Sep 2011 16:00:49 -0700 Subject: [Live-devel] video packetizatin for RTP payload In-Reply-To: References: Message-ID: > I have a basic query regarding how video is packetized for transmission (over > UDP) by liveMedia. It uses the IETF standard "RTP/RTCP" protocol; see http://www.live555.com/liveMedia/faq.html#general-rtp-question Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nandan.amar at gmail.com Thu Sep 22 23:28:54 2011 From: nandan.amar at gmail.com (nandan amar) Date: Fri, 23 Sep 2011 11:58:54 +0530 Subject: [Live-devel] video packetizatin for RTP payload In-Reply-To: References:

Message-ID: Thanks a lot Ross, I went through the RFC 3984 (RTP Payload Format for H.264 Video) also. There are multiple option for Structure of the RTP Payload Format( i.e. Single NAL Unit Packet mode, Aggregation packet mode and Fragmentation unit mode). These can be used in various combination. I wanted to know that how it is implemented for live555 server. Regards, On Fri, Sep 23, 2011 at 4:30 AM, Ross Finlayson wrote: > I have a basic query regarding how video is packetized for transmission > (over > UDP) by liveMedia. > > http://lists.live555.com/mailman/listinfo/live-devel > It uses the IETF standard "RTP/RTCP" protocol; see > http://www.live555.com/liveMedia/faq.html#general-rtp-question > > > 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 > > -- Amar Kumar Nandan Karnataka, India, 560100 ?:+91-9019054471 ?:nandan.amar at gmail.com http://aknandan.co.nr -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 23 02:46:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 23 Sep 2011 02:46:20 -0700 Subject: [Live-devel] video packetizatin for RTP payload In-Reply-To: References:

Message-ID: > I went through the RFC 3984 (RTP Payload Format for H.264 Video) also. > There are multiple option for Structure of the RTP Payload Format( i.e. Single NAL Unit Packet mode, Aggregation packet mode and Fragmentation unit mode). These can be used in various combination. > I wanted to know that how it is implemented for live555 server. When receiving H.264 RTP packets, we support any of these modes (i.e., we handle whatever is sent to us). When sending H.264 RTP packets (e.g., from a server), we do so using either Single NALU packet mode, or Fragmentation Unit mode (using FU-A). (When sending, we currently don't ever aggregate more than one NALU into a single RTP packet (although we can receive such packets OK).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From braden.ackerman at gmail.com Fri Sep 23 04:40:10 2011 From: braden.ackerman at gmail.com (Braden Ackerman) Date: Fri, 23 Sep 2011 07:40:10 -0400 Subject: [Live-devel] RTP cutting out at @ 1min 7sec for a RTSP(TCP) RTP(UDP) steaming mpeg ts.. Message-ID: I am spoofing a VOD RTSP server and a client so that I can disconnect the two. In order to do something in the middle that is quite useful, nothing malicious (will only be used on my networks unless others want it). I store some requests and responses (obviously editing values on the fly), and generate others from scratch (RTCP receiver reports for instance). Everything works fine, until VLC (I have tried with Live555, same symptom (although I know they're roughly the same code)) stops sending out RTP at about 1min 6.5 or 7s every time. I know this is some kind of timeout. My first thought was RTCP RRs and I reworked it several times, it seems perfect (can send wiresharked packets if necessary). Do you know what happens at 1 min 6.5 or 7 of a stream (timeout wise I believe)? I am streaming a mpeg transport stream (.ts) that is interlaced (I believe is the correct term... 1 stream for A and V). Thanks very much! Braden -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 23 08:46:41 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 23 Sep 2011 08:46:41 -0700 Subject: [Live-devel] RTP cutting out at @ 1min 7sec for a RTSP(TCP) RTP(UDP) steaming mpeg ts.. In-Reply-To: References: Message-ID: <060A92EF-E0D4-4AF4-9624-A5D63C5FF3E9@live555.com> It wasn't clear from your message whether your server, your client, or both are using our software. (We can only help developers who are using our software - ideally, using our original, unmodified demo applications as a baseline.) So, I suggest that you start by using the "LIVE555 Media Server" (i.e., "live555MediaServer") as your server, and the "openRTSP" command-line application as your client. Make sure that those two work together for you (to rule out possible networking problems). Then try using "openRTSP" with your server, and then the "LIVE555 Media Server" with your client. That should tell you what the problem is. I suggest also enabling debugging output in the "LIVE555 Media Server" (by adding #define DEBUG 1 to the start of "liveMedia/RTSPServer.cpp", and recompiling). The problem that you describe does, indeed, look like a problem with RTCP "RR" packets not being received by the server but, by using our (unmodified) server and client for testing, you should be able to tell for sure. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Wed Sep 28 09:43:03 2011 From: warren at etr-usa.com (Warren Young) Date: Wed, 28 Sep 2011 10:43:03 -0600 Subject: [Live-devel] Get current playback position Message-ID: <4E834E97.6040104@etr-usa.com> We tried to find a way to get the current playback position in our live555MediaServer variant, but it looks like that's entirely internal to the library, not something we can access from the public class interface. Basically we want to be able to call MPEG2TransportFileServerMediaSubsession::seekStream() from outside the library, and for that, we need an NPT value. As I understand it, the only safe place to get one is from the index file, which is owned by the internal ClientTrickPlayState class, and there is no public call that can give us its fNPT member. Could we get this added to a future version of Live555, please? From bob at bigleafdesigns.com Wed Sep 28 13:26:48 2011 From: bob at bigleafdesigns.com (Bob Brown) Date: Wed, 28 Sep 2011 13:26:48 -0700 Subject: [Live-devel] How do I compile a 32-bit version of Live555 Streaming Media on OS X? Message-ID: The default compile of Live555 Streaming Media on OSX is x86_64. How can I configure the build system to create 32-bit versions of the static libraries? I am using the instructions at live555.com/liveMedia/#config-unix I first call ./genMakefiles macosx Then call make When using lipo -info, the library shows it is x86_64. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Sep 28 14:42:17 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Sep 2011 14:42:17 -0700 Subject: [Live-devel] How do I compile a 32-bit version of Live555 Streaming Media on OS X? In-Reply-To: References: Message-ID: <7BB9688E-F2E8-44B2-8D09-F857D8D33F5F@live555.com> > The default compile of Live555 Streaming Media on OSX is x86_64. > > How can I configure the build system to create 32-bit versions of the static libraries? I'm not sure, but one thing you could try is run ./genMakefiles macosx-before-version-10.4 (even if you are using a version of Mac OS X >= 10.4) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Sep 29 02:45:53 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Sep 2011 02:45:53 -0700 Subject: [Live-devel] Get current playback position In-Reply-To: <4E834E97.6040104@etr-usa.com> References: <4E834E97.6040104@etr-usa.com> Message-ID: <8D19BE3F-BD58-4757-BCFE-D37D8CC0C80E@live555.com> > We tried to find a way to get the current playback position in our live555MediaServer variant, but it looks like that's entirely internal to the library, not something we can access from the public class interface. Basically we want to be able to call > > MPEG2TransportFileServerMediaSubsession::seekStream() > > from outside the library, and for that, we need an NPT value. As I understand it, the only safe place to get one is from the index file, which is owned by the internal ClientTrickPlayState class, and there is no public call that can give us its fNPT member. > > Could we get this added to a future version of Live555, please? I want to first step back and try to get a better understanding of what it is you're wanting to do. You talk about wanting to "get the current playback position", but then you talk about basically wanting to call "seekStream()" - but that function *sets* the playback position, not gets it. So I'm a bit confused. So, can you say a bit more about what you're wanting to do (without necessarily trying to describe how you think it might be done)? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Thu Sep 29 06:57:45 2011 From: warren at etr-usa.com (Warren Young) Date: Thu, 29 Sep 2011 07:57:45 -0600 Subject: [Live-devel] Get current playback position In-Reply-To: <8D19BE3F-BD58-4757-BCFE-D37D8CC0C80E@live555.com> References: <4E834E97.6040104@etr-usa.com> <8D19BE3F-BD58-4757-BCFE-D37D8CC0C80E@live555.com> Message-ID: <4E847959.9030902@etr-usa.com> On 9/29/2011 3:45 AM, Ross Finlayson wrote: > > You talk about wanting to "get the current > playback position", but then you talk about basically wanting to call > "seekStream()" - but that function *sets* the playback position, not > gets it. So I'm a bit confused. We want to implement bookmarking: a) find out where the server is playing from right now; b) save that somewhere external to the server; c) at a later time, restart playback; and d) jump to the previous playback position. This is simplified. There could be any number of bookmarks, and the jump doesn't always immediately follow playback restart. It's a form of trick play external to the RTSP conversation. > So, can you say a bit more about what you're wanting to do (without > necessarily trying to describe how you think it might be done)? We asked for this feature in terms of NPT, since seekStream(NPT) already exists and is public. We could modify the library to surface the fNPT member we found, but of course that isn't kosher, so we ask here instead. For step a), I haven't yet studied whether the other parameters are easy to obtain as a client of the library. If not, we'll need a way to find it/them, too. From warren at etr-usa.com Thu Sep 29 07:36:29 2011 From: warren at etr-usa.com (Warren Young) Date: Thu, 29 Sep 2011 08:36:29 -0600 Subject: [Live-devel] How do I compile a 32-bit version of Live555 Streaming Media on OS X? In-Reply-To: <7BB9688E-F2E8-44B2-8D09-F857D8D33F5F@live555.com> References: <7BB9688E-F2E8-44B2-8D09-F857D8D33F5F@live555.com> Message-ID: <4E84826D.1000008@etr-usa.com> On 9/28/2011 3:42 PM, Ross Finlayson wrote: >> The default compile of Live555 Streaming Media on OSX is x86_64. >> >> How can I configure the build system to create 32-bit versions of the >> static libraries? > > I'm not sure There are two common ways: - Use gcc4.0 and g++4.0 instead of "gcc" and "g++", which are symlinks to the 64-bit-by-default GCC 4.2 compilers. The GCC 4.0 compilers are the 32-bits-by-default Leopard ones, provided for backwards compatibility in Snow Leopard and Lion. - Pass -m32 to the compiler and linker. The necessary changes to config.macosx should be obvious. From mail2ashi.86 at gmail.com Wed Sep 28 23:14:04 2011 From: mail2ashi.86 at gmail.com (Ashish Mathur) Date: Thu, 29 Sep 2011 11:44:04 +0530 Subject: [Live-devel] Understanding live555 flow for RTSP client implementation Message-ID: Hi, I am trying to implement a RTSP client application for STB. All i want is streamed RTSP over RTP data to be available for my STB(which will then decode it). I want to put the data packet by packet inside a buffer that can be read by a thread continuously in my STB application. This buffer must be filled packet by packet by RTSP client application. For this i create a BufferSink class object(derived from MediaSink class). This class contains the buffer from where my STB application wants to read the data. I wanted to confirm if i understand the following correct: I understand that data from network sockets is read to RTPSource by live555 code. So, the next thing after instantiating the Buffersink class will be to tranfer data from RTPSource to BufferSink's buffer. And i want this to happen packet by packet. 1) For the above requirement shall i call mediasubsession->sink->startPlaying(mediasubsession->readSource()..) which maps to MediaSink->startPlaying() and then calls continueplay() which is implemented in BufferSink class? Inside continueplay() i can call getNextFrame() with the help of fsource object to get the next packet? The STB application thread which will be reading from BufferSink's buffer shall be responsible for calling mediasubsession->sink->startPlaying() whenever new data is required. 2) Also it will be helpful if you can clarify that when data is avaliable to RTPSource from the network sockets? Is it when doGetNextFrame() is called by getNextFrame() ?? Please correct me if i am wrong. Regards, Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Sep 30 15:12:30 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 30 Sep 2011 15:12:30 -0700 Subject: [Live-devel] Get current playback position In-Reply-To: <4E847959.9030902@etr-usa.com> References: <4E834E97.6040104@etr-usa.com> <8D19BE3F-BD58-4757-BCFE-D37D8CC0C80E@live555.com> <4E847959.9030902@etr-usa.com> Message-ID: <731551FB-652B-4415-90F6-AD8DBA13E57B@live555.com> > We want to implement bookmarking: > > a) find out where the server is playing from right now; Would the following work for you? A new member function to "ServerMediaSubsession": float currentNPT(unsigned clientSessionId) const; That returns (based on the most recently-sent data) the current 'normal play time' (NPT) for the specified client (on this 'subsession'). (Note that the function has to be on "ServerMediaSubsession" rather than "ServerMediaSession" because (in general, even though not for Transport Streams) there can be more than one RTP stream for each client session, and these could be paused/played independently.) > For step a), I haven't yet studied whether the other parameters are easy to obtain as a client of the library. Yes, at the client end, there's a function: double MediaSession::getNormalPlayTime(struct timeval const& presentationTime); that you can call to get the 'NPT' (based on a recently-received presentation time). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Fri Sep 30 18:37:59 2011 From: warren at etr-usa.com (Warren Young) Date: Fri, 30 Sep 2011 19:37:59 -0600 Subject: [Live-devel] Get current playback position In-Reply-To: <731551FB-652B-4415-90F6-AD8DBA13E57B@live555.com> References: <4E834E97.6040104@etr-usa.com> <8D19BE3F-BD58-4757-BCFE-D37D8CC0C80E@live555.com> <4E847959.9030902@etr-usa.com> <731551FB-652B-4415-90F6-AD8DBA13E57B@live555.com> Message-ID: <4E866EF7.1090900@etr-usa.com> On 9/30/2011 4:12 PM, Ross Finlayson wrote: >> For step a), I haven't yet studied whether the other parameters are >> easy to obtain as a client of the library. > > Yes, at the client end, there's a function: > double MediaSession::getNormalPlayTime(struct timeval const& > presentationTime); We want to do this stream seeking from the RTSP server side, in a program that, like live555MediaServer, does little more than just wrap the RTSP server implementation in liblivemedia. By "client", we mean "a client of liblivemedia.so", not "the RTSP protocol client". In addition to the NPT, ServerMediaSubsession::seekStream() also takes a clientId, a streamToken, and a streamDuration. I was saying that I hadn't looked into whether these other values are actually available to clients of liblivemedia, or whether we'd need more accessors to dig these other values out of the library, too. I just looked into it, and it appears that at least some of these other values belong to RTSPClientSession, which is buried inside RTSPServer. I haven't looked deeper than that, but I'm getting the sense that we need more than this proposed currentNPT() call to call seekStream() from outside liblivemedia. If I'd realized there was that much work involved, I'd have provided a patch instead of shooting off a request for a simple accessor function. You're welcome to do the work if you want, but it is our itch. This is also experimental. We don't yet know how the various RTSP clients will cope with the stream changing out from under them like that. We're streaming MPEG-2 TS, so we *assume* they'll treat it like packet loss and quickly re-sync. If we have to do something like wait for an I frame to do the switch, it'll be a significant amount of work. From tuan.dn at anlab.vn Fri Sep 30 21:28:32 2011 From: tuan.dn at anlab.vn (Tuan DN) Date: Sat, 1 Oct 2011 11:28:32 +0700 Subject: [Live-devel] Save video stream to MP4 file, audio play normal, video play slow Message-ID: Hi everyone, I am a newbie with live555, I would like to ask a question. I use live555 to record a mediastream by following command: *testProgs/openRTSP.exe -d 10 -4 rtsp://192.168.1.174:5544 >live555.mp4* But when mp4 file is created, the video is much more slow than audio, please see the attached file. Below is the log when I run live555: ===================== o=- -8959207471341189980 -8959207471340249383 IN IP4 192.168.1.174:55rtsp:// 192.168.1.174:5544 c=IN IP4 0.0.0.0 a=tool: Visualink HD a=range:npt=0- m=audio 62004 RTP/AVP 98 a=rtpmap:98 mpeg4-generic/48000/2 a=fmtp:98 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190; SizeLength=13;IndexLength=3; IndexDeltaLength=3; Profile=1; a=control:rtsp://192.168.1.174:5544/trackID=0 m=video 62002 RTP/AVP 96 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=0;profile- level-id=42001e;sprop-parameter-sets=Z2QAH62wpDBSAgFxQWKQPQRWFIYKQEAuKCxSB6CKwpDBSAgFxQWKQPQRTDoUKQNC4oJHMGIemHQoUgaFxQSOYMQ9MOhQpA0LigkcwYh6xEQmIVilsQRWUURJsogxOU4QITKUIEVlCCTYQVhBMJQhMIjGggWQJFaIGBJZBAaEnaMIDwsSWQQKCwsrRBQYOWQweO0YEBZASNAogszlAtHt/4AEAASIAABd2AAV+QcAAAMAIWDoAABCwdn//xgAAAMBCwdAAAIWDs//+FA=,aP48sA==; a=control:rtsp://192.168.1.174:5544/trackID=1 =========================== Could someone give me some advice on how to improve the quality of the video. Forgive my English. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: live555.mp4 Type: video/mp4 Size: 2351478 bytes Desc: not available URL: