From Jasleen at beesys.com Wed Oct 1 02:02:25 2014 From: Jasleen at beesys.com (Jasleen Kaur) Date: Wed, 1 Oct 2014 09:02:25 +0000 Subject: [Live-devel] Writing RTSP server In-Reply-To: <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com> References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com> Message-ID: From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com] Sent: Wednesday, October 01, 2014 11:42 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Writing RTSP server Our requirement is to using Live555 libraries to stream real time data ( data generated by our software) , using RTSP. Is it possible using Live555 libraries Yes, of course. See http://www.live555.com/liveMedia/faq.html#liveInput-unicast Thanks for the prompt reply. Just want to confirm the following: 1) We have to create our own source class derived from FramedSource 2) Another class derived from OnDemandServerMediaSubsession 3) We have to implement "createNewStreamSource()" and "createNewRTPSink()" methods in the custom mediasession class. In "createNewStreamSource()" we have create our own source. Do we have to create a custom sink class also for "createNewRTPSink()" Also what is the role of a sink ? Does Sink do the actual streaming ? Best Regards Jasleen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanluc.bonnet at barco.com Wed Oct 1 04:03:08 2014 From: jeanluc.bonnet at barco.com (Bonnet, Jean-Luc) Date: Wed, 1 Oct 2014 11:03:08 +0000 Subject: [Live-devel] Receive H264 packets from GStreamer In-Reply-To: <9C97C183-B278-402A-9379-68197CFA496B@live555.com> Message-ID: <75C4803536D10B4EB6FA0743F98B6A0A1ECE119B@KUUMEX10.barco.com> Thanks for the hint Ross, The Marker Bit seems to be set correctly by GStreamer. Regards Jean-Luc Bonnet ________________________________ De : live-devel [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : mardi 30 septembre 2014 17:09 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Receive H264 packets from GStreamer I want to receive H264 video frame over RTP from a GStreamer server. I use H264VideoRTPSource which works fine, I receive all RTP packets. But rtph264pay GStreamer's component which generate H264 payload send only One NAL Unit per RTP packet. Is there a way to rebuild the whole video frame at Live 555 side. It's the job of the decoder to figure out how to render the incoming NAL units - which includes deciding when one video frame (called an 'access unit' in H.264 parlance) ends, and the next one begins. However, as a hint, you can use the value of the RTP packet's 'M' (i.e., 'marker') bit, which is (supposed to be) set for the last RTP packet of an 'access unit' (i.e., video frame). I.e., you can call "RTPSource::curPacketMarkerBit()" to test this. Note, though, that this is only a hint, because this last RTP packet may have been lost (or the server might not have properly set the 'M' bit in the first place). Ross Finlayson Live Networks, Inc. http://www.live555.com/ This message is subject to the following terms and conditions: MAIL DISCLAIMER -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 1 06:41:47 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Oct 2014 06:41:47 -0700 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com> Message-ID: <93797F0D-500D-4BC8-B453-F007580A2452@live555.com> > Just want to confirm the following: > > 1) We have to create our own source class derived from FramedSource Yes, but only if your encoded video (or audio) stream is not accessible as a file in the file system (e.g., under /dev/). > 2) Another class derived from OnDemandServerMediaSubsession Yes, if you needed to define your own source class for your encoded data. > 3) We have to implement "createNewStreamSource()" and "createNewRTPSink()" methods in the > custom mediasession class. > In "createNewStreamSource()" we have create our own source. Yes. > Do we have to create a custom sink class also for "createNewRTPSink()" No; an existing "RTPSink" subclass should already be defined (use the one that's appropriate for the kind of media that you're streaming). > Also what is the role of a sink ? Does Sink do the actual streaming ? See http://www.live555.com/liveMedia/faq.html#control-flow Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 1 12:33:29 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Oct 2014 12:33:29 -0700 Subject: [Live-devel] Using QuickTimeFileSink in lib live555 In-Reply-To: References: Message-ID: <53C0C619-855C-4799-87AA-DA7488A060B8@live555.com> > I'm using openRTSP to receive data from camera over RTSP and write into a file .mp4. Stream data of camera has frame rate = 30, width = 800, height = 600, codec H264. Note that - because your stream has a non-default frame-rate, width, and height - you *must* specify these on the command line when you run "openRTSP". I.e., you must add the options -w 800 -h 600 -f 30 to the command line. See http://www.live555.com/openRTSP/#quicktime > Can you help me explain how to QuickTimeFileSink work with frame rate, width, height to record file and how to check timeout data when using QuickTimeFileSink? Remember, You Have Complete Source Code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 1 12:35:59 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Oct 2014 12:35:59 -0700 Subject: [Live-devel] Stream multiple files In-Reply-To: <1411981142.44264.YahooMailNeo@web172103.mail.ir2.yahoo.com> References: <1411725014.44676.YahooMailNeo@web172105.mail.ir2.yahoo.com> <1411981142.44264.YahooMailNeo@web172103.mail.ir2.yahoo.com> Message-ID: <6C1169AC-E0C0-421B-88C8-9E580A5D364C@live555.com> > Will files be played as if they are one file? I mean without interruptions at the end of each one? Yes. > And for mp3 files, where should I make the changes you suggested (which class) You'll need to define your own subclass of "OnDemandServerMediaSubsession" that creates a "ByteStreamMuultiFileSource" (in your implementation of the "createNewStreamSource()" virtual function; see http://www.live555.com/liveMedia/faq.html#liveInput-unicast Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppulliam at llnw.com Thu Oct 2 14:47:37 2014 From: ppulliam at llnw.com (Pete Pulliam) Date: Thu, 2 Oct 2014 14:47:37 -0700 Subject: [Live-devel] ubuntu live555 tuning issue Message-ID: More data points, more refined confusion, about an ubuntu live555 tuning problem. When serving from port 8554 (non-priveliged), we are getting 800 connections comfortably (Great!) When serving from port 554 (privileged), we are sucking at less than 100 connections, even with extreme tuning (Terrible!) No, we can't actually avoid using port 554. This is true for two different versions of Ubuntu linux, and has been tested on six different pieces of hardware in three different pops. I've looked for iptables rules. The test framework uses openRTSP with the last client started returning quality metrics, with one or more VLC clients also playing for visual confirmation. "My Code" refers to a live proxy implementation. Here is a simplified view of the test graph: *My Code* (based on April edition of live555) root, port 8554, udp -> GREAT! (tested at 800+ players) root, port 554, udp -> terrible root, port 554, rtsp over TCP -> GREAT! (tested at 1000+ players) root, port 554, udp, players all on localhost -> GREAT! (tested at 1000+ players) *Stock April live555 proxy* non-privileged, port 8554 -> GREAT! root, port 554 -> terrible *Stock September live555 proxy* non-privileged, port 8554 -> GREAT! root, port 554 -> terrible Comments will be greatly appreciated. Thanks, Pete -- The information in this message may be confidential. It is intended solely for the addressee(s). If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Thu Oct 2 17:44:58 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Thu, 2 Oct 2014 20:44:58 -0400 Subject: [Live-devel] ubuntu live555 tuning issue In-Reply-To: References: Message-ID: f i r e w a l l ??? Wireshark may help here. If it is a sea of red then that may indicate issues. Also check the measurements. Are all users getting the same? ie 1000 at 1 fps vs 800 @ 10fps ?? so check the bandwidth to account for loss to. On Thu, Oct 2, 2014 at 5:47 PM, Pete Pulliam wrote: > More data points, more refined confusion, about an ubuntu live555 tuning > problem. > > When serving from port 8554 (non-priveliged), we are getting 800 > connections comfortably (Great!) > > When serving from port 554 (privileged), we are sucking at less than 100 > connections, even with extreme tuning (Terrible!) > > No, we can't actually avoid using port 554. > > This is true for two different versions of Ubuntu linux, and has been > tested on six different pieces of hardware in three different pops. I've > looked for iptables rules. > > The test framework uses openRTSP with the last client started returning > quality metrics, with one or more VLC clients also playing for visual > confirmation. > > "My Code" refers to a live proxy implementation. > > Here is a simplified view of the test graph: > > *My Code* (based on April edition of live555) > > root, port 8554, udp -> GREAT! (tested at 800+ players) > > root, port 554, udp -> terrible > > root, port 554, rtsp over TCP -> GREAT! (tested at 1000+ players) > > root, port 554, udp, players all on localhost -> GREAT! (tested at 1000+ > players) > > > *Stock April live555 proxy* > non-privileged, port 8554 -> GREAT! > root, port 554 -> terrible > > *Stock September live555 proxy* > non-privileged, port 8554 -> GREAT! > root, port 554 -> terrible > > > Comments will be greatly appreciated. > > Thanks, > > > Pete > > > > The information in this message may be confidential. It is intended > solely for > the addressee(s). If you are not the intended recipient, any disclosure, > copying or distribution of the message, or any action or omission taken by > you > in reliance on it, is prohibited and may be unlawful. Please immediately > contact the sender if you have received this message in error. > > > _______________________________________________ > 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 dee.earley at icode.co.uk Fri Oct 3 01:53:34 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Fri, 3 Oct 2014 08:53:34 +0000 Subject: [Live-devel] Invalid timestamp generation in GroupsockHelper (with patch) Message-ID: Hello all. While investigating a crash when a camera sent multicast details in the SDP, I tracked down the problem to timestampString in GroupsockHelper which turned out to be an Invalid argument exception being raised inside ctime (actually _tctime64, calling _localtime64_s). When using Windows SDK 7.1, time_t is defined as a 64 bit value by default (__time64_t) and due to an invalid cast resulted in a massively out of range value. char const* ctimeResult = ctime((time_t*)&tvNow.tv_sec); The 32-bit seconds value (followed by the 32-bit microseconds value) is cast to a single 64-bit seconds value giving a unix time of 2816954497596031 instead of a far more reasonable 1412266623. Doing an implicit cast/assignment to a real time_t value and passing a pointer to that, resolves the crash. time_t tvNow_t = tvNow.tv_sec; char const* ctimeResult = ctime(&tvNow_t); Would you consider including the attached patch in the next release of liveMedia? Many thanks. -- Deanna Earley?|?Lead developer?|?icatchercctv w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338 Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325 -------------- next part -------------- A non-text attachment was scrubbed... Name: liveMedia GroupsockHelper timestampString invalidcast.patch Type: application/octet-stream Size: 533 bytes Desc: liveMedia GroupsockHelper timestampString invalidcast.patch URL: From finlayson at live555.com Fri Oct 3 06:18:53 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 3 Oct 2014 06:18:53 -0700 Subject: [Live-devel] Invalid timestamp generation in GroupsockHelper (with patch) In-Reply-To: References: Message-ID: <3C11EE16-F7E7-452E-8AE3-5602B8EE2EBA@live555.com> Deanna, Thanks for the report. I've just released a new version (2014.10.03) of the "LIVE555 Streaming Media" code that includes your fix. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Oct 5 00:39:46 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 5 Oct 2014 00:39:46 -0700 Subject: [Live-devel] ubuntu live555 tuning issue In-Reply-To: References: Message-ID: <056CE632-3570-4C62-9DA6-7936168E2FDC@live555.com> > My Code (based on April edition of live555) > You should upgrade to the latest version of the code. Old versions of the code are not supported. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jasleen at beesys.com Mon Oct 6 02:49:39 2014 From: Jasleen at beesys.com (Jasleen Kaur) Date: Mon, 6 Oct 2014 09:49:39 +0000 Subject: [Live-devel] Writing RTSP server In-Reply-To: <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com> References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com> Message-ID: From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com] Sent: Wednesday, October 01, 2014 11:42 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Writing RTSP server Our requirement is to using Live555 libraries to stream real time data ( data generated by our software) , using RTSP. Is it possible using Live555 libraries Yes, of course. See http://www.live555.com/liveMedia/faq.html#liveInput-unicast Ross Finlayson Live Networks, Inc. http://www.live555.com/ Hi Ross Finlayson As suggested in FAQs, I have made a class derived from OnDemandServerMediaSubsession and overridden "createNewStreamSource" and "createNewRTPSink" methods. Made another class (Source) derived from FramedSource. In the OnDemandServerMediaSubsession derived class , in the "createNewStreamSource" , created the instance of my custom source class. In the OnDemandServerMediaSubsession derived class , in the "createNewRTPSink" , created the instance of SimpleRTPSink. In the testOnDemandRTSPServer.cpp file I added the following code on the pattern of others. // A WASP stream: { char const* streamName = "WaspTest"; //char const* inputFileName = "test.wav"; ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); Boolean convertToULaw = False; sms->addSubsession(WaspVideoFileServerMediaSubsession::createNew(*env, reuseFirstSource)); rtspServer->addServerMediaSession(sms); announceStream(rtspServer, sms, streamName, ""); } wherein WaspVideoFileServerMediaSubsession is our custom OnDemandServerMediaSubsession derived class. Now my questions are : 1) When will createNewStreamSource and createNewRTPSink be called , and when will the streaming begin? 2) Do I have to write a custom Sink class also? 3) Our data is uncompressed ARGB data, I wish to compress it and then stream it using RTSP, what changes will I have to make ? Best Regards Jasleen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Martinovic at zenitel.com Mon Oct 6 06:33:30 2014 From: Alan.Martinovic at zenitel.com (Alan Martinovic) Date: Mon, 6 Oct 2014 13:33:30 +0000 Subject: [Live-devel] LIVE555TM Media Server takes input from a named pipe Message-ID: <916A03CCEB30DF44AD98D4CFDC7448D01D530249@nooslzsmx1.zenitelcss.com> Hi, I'm trying to get a minimal example for using a named pipe as a source of a stream for the LIVE555TM Media Server. As a proof of concept, I would like to get a working example of making a stream from a sample.264 file into a named pipe and use the named pipe with a .264 extension to have Media Server stream it. Working example (video plays in vlc) Files: rawh264_sample #The original slamtv60.264 just renamed periodic_read.py #A dummy application that creates a binary stream from the rawh264_sample stream.264 #The named pipe, created with "mkfifo stream.264" live555MediaServer #The server binary from mediaServer Steps: ./live555MediaServer Run vlc -> Ctrl+n (Open Network stream) -> rtsp://xx.xx.xx.xx:8554/stream.264 cat rawh264_sample >> stream.264 cat rawh264_sample >> stream.264 #It had to be called twice --------------------------------------------------------------------------------------------------------------------------------- The idea is to make a simple streamer that just chops the raw video file and periodically sends chops. The code the dummy streamer (periodic_read.py) is below everything. Example I didn't get to work (The video starts loading in vlc but breaks) Files: rawh264_sample #The original slamtv60.264 just renamed periodic_read.py #A dummy streamer that creates a binary stream from the rawh264_sample stream.264 #The named pipe, created with "mkfifo stream.264" live555MediaServer #The server binary from mediaServer Steps: ./periodic_read.py > stream.264 #Move the raw file to the pipe ./live555MediaServer Run vlc to get the stream What happens is that the vlc shows that the buffer is loading, but breaks after half. The video never starts to play. I get an error on the streamer side: Traceback (most recent call last): File "./periodic_read.py", line 14, in print chunk IOError: [Errno 32] Broken pipe Is it possible that the problem is in the sync between the streamers write speed and mediaServers read speed? Other comments are welcome :) ------------------------------------------------------------------ # periodic_read.py #!/usr/bin/python import time import sys file_path = "rawh264_sample" chunk_size = 1000 frequency = 200 f = open(file_path, "rb") while True: chunk=f.read(chunk_size) print chunk time.sleep(1/frequency) if chunk == '' : break ------------------------------------------------------------------ DISCLAIMER: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 6 07:57:15 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 6 Oct 2014 07:57:15 -0700 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com> Message-ID: <6E68A749-7739-4FB7-9AA4-3DFE5C8C00A1@live555.com> > 3) Our data is uncompressed ARGB data, I wish to compress it and then stream it using RTSP, what changes will I have to make ? That's the first thing you need to decide: What compressed video format (codec) you want to use. That will tell you what "RTPSink" subclass you use (note that it probably *won't* be "SimpleRTPSink"). Most people use their "FramedSource" subclass to generate compressed video frames (one at a time). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 6 08:08:06 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 6 Oct 2014 08:08:06 -0700 Subject: [Live-devel] LIVE555TM Media Server takes input from a named pipe In-Reply-To: <916A03CCEB30DF44AD98D4CFDC7448D01D530249@nooslzsmx1.zenitelcss.com> References: <916A03CCEB30DF44AD98D4CFDC7448D01D530249@nooslzsmx1.zenitelcss.com> Message-ID: <23AD4E4D-E53F-415C-B2AD-C80ACE4CB3AB@live555.com> > I?m trying to get a minimal example for using a named pipe as a source of a stream for the LIVE555TM Media Server. FYI, you should be using the "testOnDemandRTSPServer" demo application as a base here - *not* the "LIVE555 Media Server". (The "LIVE555 Media Server" is an 'off the shelf' application that looks up arbitrary file names, on demand, based on requests from client(s). That's not what you want to do here. Instead, you want to serve a single, special-purpose stream, that clients will access using just one name.) See also http://www.live555.com/liveMedia/faq.html#liveInput-unicast Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jasleen at beesys.com Mon Oct 6 23:48:43 2014 From: Jasleen at beesys.com (Jasleen Kaur) Date: Tue, 7 Oct 2014 06:48:43 +0000 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com>, Message-ID: From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Jasleen Kaur [Jasleen at beesys.com] Sent: Monday, October 06, 2014 3:19 PM To: LIVE555 Streaming Media - development & use Cc: Bishwaroop Chakravarty Subject: Re: [Live-devel] Writing RTSP server From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com] Sent: Wednesday, October 01, 2014 11:42 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Writing RTSP server Our requirement is to using Live555 libraries to stream real time data ( data generated by our software) , using RTSP. Is it possible using Live555 libraries Yes, of course. See http://www.live555.com/liveMedia/faq.html#liveInput-unicast Ross Finlayson Live Networks, Inc. http://www.live555.com/ Hi Ross Finlayson As suggested in FAQs, I have made a class derived from OnDemandServerMediaSubsession and overridden "createNewStreamSource" and "createNewRTPSink" methods. Made another class (Source) derived from FramedSource. In the OnDemandServerMediaSubsession derived class , in the "createNewStreamSource" , created the instance of my custom source class. In the OnDemandServerMediaSubsession derived class , in the "createNewRTPSink" , created the instance of SimpleRTPSink. In the testOnDemandRTSPServer.cpp file I added the following code on the pattern of others. // A WASP stream: { char const* streamName = "WaspTest"; //char const* inputFileName = "test.wav"; ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); Boolean convertToULaw = False; sms->addSubsession(WaspVideoFileServerMediaSubsession::createNew(*env, reuseFirstSource)); rtspServer->addServerMediaSession(sms); announceStream(rtspServer, sms, streamName, ""); } wherein WaspVideoFileServerMediaSubsession is our custom OnDemandServerMediaSubsession derived class. Now my questions are : 1) When will createNewStreamSource and createNewRTPSink be called , and when will the streaming begin? 2) Do I have to write a custom Sink class also? 3) Our data is uncompressed ARGB data, I wish to compress it and then stream it using RTSP, what changes will I have to make ? Best Regards Jasleen ------------------------------------------------------------------------------------------------------------------------------ Hello Ross When I tried the published url in VLC , I was able to get the createNewStreamSource and createNewRTPSink calls. I have started getting calls to doGetNextFrame of the source class. But in VLC there is an error "VLC is unable to open the MRL 'rtsp://192.168.1.164:8554/WaspTest'. Check the log for details" and in the server side , the doGetNextFrame calls continue. What can be the reason of this behaviour ? Is it something related to the sink class.I have created instance of SimpleRTPSink class in createNewRTPSink call. Your help would be really appreciated. Regards Jasleen ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 6 23:56:39 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 6 Oct 2014 23:56:39 -0700 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com>, Message-ID: <9295E28A-62EB-49BB-BFFB-2FA12243CBEF@live555.com> Please don't send the same question to the mailing list more than once! (This is basic 'netiquette', and is clearly explained in the FAQ that everyone is asked to read before posting to the mailing list.) Because of this, all future postings from you will be moderated. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at sparkalley.com Tue Oct 7 13:20:45 2014 From: eric at sparkalley.com (Eric Blanpied) Date: Tue, 7 Oct 2014 13:20:45 -0700 Subject: [Live-devel] Seeking Live555 Mac OS Consultant Message-ID: <83BF2E25-FB6B-469A-9C0C-F2CBB2F5B97A@sparkalley.com> Hello, First off, while this is not a technical question, my hope is that it?s OK to post this topic here, since it could directly lead to work for someone in the live555 ecosystem? Apologies if that?s an issue. I work for a small company that?s developing a Mac OS X application that among other things needs to capture RTSP streams from IP cameras, and we are hoping to find someone to help us integrate the live555 library into our project along with an objective-c api to the relevant portions. We?re based in Berkeley, CA, and are ready to consider any number of working arrangements if we could find someone with experience with this already. thanks very much, Eric Blanpied Spark Alley From Jasleen at beesys.com Wed Oct 8 00:16:27 2014 From: Jasleen at beesys.com (Jasleen Kaur) Date: Wed, 8 Oct 2014 07:16:27 +0000 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com>, Message-ID: ________________________________ From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Jasleen Kaur [Jasleen at beesys.com] Sent: Wednesday, October 01, 2014 2:32 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Writing RTSP server From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com] Sent: Wednesday, October 01, 2014 11:42 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Writing RTSP server Our requirement is to using Live555 libraries to stream real time data ( data generated by our software) , using RTSP. Is it possible using Live555 libraries Yes, of course. See http://www.live555.com/liveMedia/faq.html#liveInput-unicast Thanks for the prompt reply. Just want to confirm the following: 1) We have to create our own source class derived from FramedSource 2) Another class derived from OnDemandServerMediaSubsession 3) We have to implement "createNewStreamSource()" and "createNewRTPSink()" methods in the custom mediasession class. In "createNewStreamSource()" we have create our own source. Do we have to create a custom sink class also for "createNewRTPSink()" Also what is the role of a sink ? Does Sink do the actual streaming ? Best Regards Jasleen > Just want to confirm the following: > > 1) We have to create our own source class derived from FramedSource Yes, but only if your encoded video (or audio) stream is not accessible as a file in the file system (e.g., under /dev/). > 2) Another class derived from OnDemandServerMediaSubsession Yes, if you needed to define your own source class for your encoded data. > 3) We have to implement "createNewStreamSource()" and "createNewRTPSink()" methods in the > custom mediasession class. > In "createNewStreamSource()" we have create our own source. Yes. > Do we have to create a custom sink class also for "createNewRTPSink()" No; an existing "RTPSink" subclass should already be defined (use the one that's appropriate for the kind of media that you're streaming). > Also what is the role of a sink ? Does Sink do the actual streaming ? See http://www.live555.com/liveMedia/faq.html#control-flow Thanks Ross for the explanation. I tried testRTSPclient to receive the streamed data , instead of VLC player.What I could find out it that the response for 'DESCRIBE" request is not received at the client end. While debugging the server application I could see that, when my Subsession's getAuxSDPLine is called , it gets stuck in the last statement before return i.e at envir().taskScheduler().doEventLoop(&fDoneFlag); So it is not able to return from this method.What could be the reason for this? Also, Currently uncompressed ARGB data is given out from our custom source and following is the code written in createNewRTPSink of our MedisSubSession class.(which we wish to compress into H.264 and then stream ) OutPacketBuffer::maxSize = 720*576*4; // by default MultiFramedRTPSink* pSink = SimpleRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic, 90000, "video", "WASP", 1, True, False /*no 'M' bit*/); return pSink; I wonder what should be the payloadType, and payload frequency and rest of the paramaters for SimpleRTPSink::createNew. Regards Jasleen -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 8 00:48:49 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Oct 2014 00:48:49 -0700 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com>, Message-ID: <5A5FA567-8860-4991-8755-43E2F8226A69@live555.com> > Currently uncompressed ARGB data is given out from our custom source and following is the code written increateNewRTPSink of our MedisSubSession class.(which we wish to compress into H.264 and then stream ) > > OutPacketBuffer::maxSize = 720*576*4; // by default > MultiFramedRTPSink* pSink = SimpleRTPSink::createNew(envir(), rtpGroupsock, Because you're planning to stream H.264 video, you MUST use a "H264VideoRTPSink", not a "SimpleRTPSink". Also, we do not support streaming uncompressed video, so you must compress your video (to H.264) before streaming it. I suggest that you use the "testOnDemandRTSPServer" code as a model, noting in particular the "H264VideoFileServerMediaSubsession" class. You will use a similar class in your server. You should first familiarize yourself with how "testOnDemandRTSPServer" streams a H.264 video file (named "test.264"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandro.ferrari at vixionar.com Wed Oct 8 05:54:36 2014 From: alejandro.ferrari at vixionar.com (Alejandro Ferrari) Date: Wed, 8 Oct 2014 09:54:36 -0300 Subject: [Live-devel] TLS over RTSP Message-ID: Hi Guys, I'm reading about some way to protect RTSP streaming, we have a security cam, that stream over RTSP, but we need secure this traffic to avoid any man in the middle issue. Currently exist some way to encrypt RTSP traffic? I read something related to "rtsps" but I can't found nothing useful about this... really exist? Thank! Alejandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 8 08:33:42 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Oct 2014 08:33:42 -0700 Subject: [Live-devel] TLS over RTSP In-Reply-To: References: Message-ID: <10FCC7B4-FC4D-4E72-A5C4-EEE621383C2B@live555.com> 1/ I think you mean "RTSP over TLS", not "TLS over RTSP". 2/ The "rtsps" URL scheme was defined only for the proposed RTSP 2.0 protocol, which nobody (including us) implements. 3/ If it's only 'man-in-the-middle' attacks that you care about, then regular RTSP (digest) authentication should protect against that. (However, that does not provide any confidentiality of the RTSP or media traffic.) 4/ Note that even if you were to use encryption to provide confidentiality of the RTSP (TCP) traffic, that would nor provide any confidentiality of the media (RTP/RTCP, i.e., UDP) traffic, unless you are tunneling RTP/RTCP-over-TCP (which is something that we discourage, unless you have a firewall that blocks UDP packets. Nonetheless, if you are using the "LIVE555 Streaming Media" software to implement both the RTSP server and (all of) your RTSP clients, then you can implement RTSP over a TLS connection by setting up - at each end - a TLS connection, and then: - In each RTSP client, use the (otherwise optional) "socketNumToServer" parameter to "RTSPClient::createNew()" to specify the socket number of the TSL connection. - In your RTSP server, subclass "RTSPServer", and, in your subclass's constructor, pass the socket number of the TLS connection as the "ourSocket" parameter in your call to the "RTSPServer" constructor. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Wed Oct 8 08:49:14 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Wed, 8 Oct 2014 11:49:14 -0400 Subject: [Live-devel] TLS over RTSP In-Reply-To: References: Message-ID: set up a vpn tunnel Rtsp just happens to be the connection protocol on top of it then. On Wed, Oct 8, 2014 at 8:54 AM, Alejandro Ferrari < alejandro.ferrari at vixionar.com> wrote: > Hi Guys, > > I'm reading about some way to protect RTSP streaming, we have a security > cam, that stream over RTSP, but we need secure this traffic to avoid any > man in the middle issue. > > Currently exist some way to encrypt RTSP traffic? I read something related > to "rtsps" but I can't found nothing useful about this... really exist? > > Thank! > Alejandro > > _______________________________________________ > 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 alejandro.ferrari at vixionar.com Wed Oct 8 10:42:36 2014 From: alejandro.ferrari at vixionar.com (Alejandro Ferrari) Date: Wed, 8 Oct 2014 14:42:36 -0300 Subject: [Live-devel] TLS over RTSP In-Reply-To: <10FCC7B4-FC4D-4E72-A5C4-EEE621383C2B@live555.com> References: <10FCC7B4-FC4D-4E72-A5C4-EEE621383C2B@live555.com> Message-ID: Hi Ross, Thanks for your detailed response, let me check some points. * Why is not recommended use RTSP over TCP? * Our camera work inside of a home, and push to cloud servers, I think in this scenario, UDP will be not an issue, right? * Has live555 a library to push from Android? I read many post but not found nothing "official" * Can guide me to some documentation, about how to extend business logic with your server?, we need record all the incoming streams into mp4 to made this available later to watch as VOD. Thanks again! Alejandro 2014-10-08 12:33 GMT-03:00 Ross Finlayson : > 1/ I think you mean "RTSP over TLS", not "TLS over RTSP". > > 2/ The "rtsps" URL scheme was defined only for the proposed RTSP 2.0 > protocol, which nobody (including us) implements. > > 3/ If it's only 'man-in-the-middle' attacks that you care about, then > regular RTSP (digest) authentication should protect against that. > (However, that does not provide any confidentiality of the RTSP or media > traffic.) > > 4/ Note that even if you were to use encryption to provide confidentiality > of the RTSP (TCP) traffic, that would nor provide any confidentiality of > the media (RTP/RTCP, i.e., UDP) traffic, unless you are tunneling > RTP/RTCP-over-TCP (which is something that we discourage, unless you have a > firewall that blocks UDP packets. > > Nonetheless, if you are using the "LIVE555 Streaming Media" software to > implement both the RTSP server and (all of) your RTSP clients, then you can > implement RTSP over a TLS connection by setting up - at each end - a TLS > connection, and then: > - In each RTSP client, use the (otherwise optional) "socketNumToServer" > parameter to "RTSPClient::createNew()" to specify the socket number of the > TSL connection. > - In your RTSP server, subclass "RTSPServer", and, in your subclass's > constructor, pass the socket number of the TLS connection as the > "ourSocket" parameter in your call to the "RTSPServer" constructor. > > 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 Wed Oct 8 12:17:15 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Oct 2014 12:17:15 -0700 Subject: [Live-devel] TLS over RTSP In-Reply-To: References: <10FCC7B4-FC4D-4E72-A5C4-EEE621383C2B@live555.com> Message-ID: <87760634-BE83-4FBB-9A74-46921A57897B@live555.com> > * Why is not recommended use RTSP over TCP? Just to be clear, the RTSP protocol (the 'control protocol') is always over TCP. By default, however, the *media* packets (i.e., RTP/RTCP) are sent over UDP. It is possible, however, to also stream the media packets (RTP/RTCP) interleaved over the RTSP (i.e., TCP) connection. The basic reason why this is not recommended - unless you're behind a firewall that blocks UDP packets - is that the media (RTP/RTCP) packets are intended to be 'real time' data, and by carrying them over TCP, you're introducing often excessive (and usually unnecessary) delay, and also making the streaming less data efficient, > * Our camera work inside of a home, and push to cloud servers, I think in this scenario, UDP will be not an issue, right? Do you mean "UDP packets will not be able to pass between your clients and servers"? Perhaps they will; why not try it and check? > * Has live555 a library to push from Android? Are you asking it the "LIVE555 Streaming Media" code can run on 'Android'. Yes it can; remember that 'Android' is basically just Linux. So use one of the "config.linux*' configuration files when you build the software. > * Can guide me to some documentation, about how to extend business logic with your server? I'm not sure what you mean by "extend business logic" (that sounds like marketing talk :-), but remember that there's a limit as to how much advice/help I can dispense 'for free' on this mailing list. > we need record all the incoming streams into mp4 to made this available later to watch as VOD. I suggest that you start by looking at our "openRTSP" application - http://www.live555.com/openRTSP/ - and also reviewing the code for the "testRTSPClient" demo application. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandro.ferrari at vixionar.com Wed Oct 8 12:40:49 2014 From: alejandro.ferrari at vixionar.com (Alejandro Ferrari) Date: Wed, 8 Oct 2014 16:40:49 -0300 Subject: [Live-devel] TLS over RTSP In-Reply-To: <87760634-BE83-4FBB-9A74-46921A57897B@live555.com> References: <10FCC7B4-FC4D-4E72-A5C4-EEE621383C2B@live555.com> <87760634-BE83-4FBB-9A74-46921A57897B@live555.com> Message-ID: Ross, Yes sure! thanks for the help, really I'm evaluating replacement to our current media server, I like but just need some security features that I saw build-in into Live555 Streaming media. When I say Business Logic, I mean that we need be able to authenticate the user with our Rest Service, and can handle MP4 file names in base to the camera id, thinks like this... we are using Java media server with and API, my question is related to this part, if we can add custom handlers to capture some events, like login, and recordings. Sorry for my English, and regards from Argentine. Alejandro 2014-10-08 16:17 GMT-03:00 Ross Finlayson : > * Why is not recommended use RTSP over TCP? > > > Just to be clear, the RTSP protocol (the 'control protocol') is always > over TCP. By default, however, the *media* packets (i.e., RTP/RTCP) are > sent over UDP. It is possible, however, to also stream the media packets > (RTP/RTCP) interleaved over the RTSP (i.e., TCP) connection. The basic > reason why this is not recommended - unless you're behind a firewall that > blocks UDP packets - is that the media (RTP/RTCP) packets are intended to > be 'real time' data, and by carrying them over TCP, you're introducing > often excessive (and usually unnecessary) delay, and also making the > streaming less data efficient, > > > * Our camera work inside of a home, and push to cloud servers, I think in > this scenario, UDP will be not an issue, right? > > > Do you mean "UDP packets will not be able to pass between your clients and > servers"? Perhaps they will; why not try it and check? > > > * Has live555 a library to push from Android? > > > Are you asking it the "LIVE555 Streaming Media" code can run on > 'Android'. Yes it can; remember that 'Android' is basically just Linux. > So use one of the "config.linux*' configuration files when you build the > software. > > > * Can guide me to some documentation, about how to extend business logic > with your server? > > > I'm not sure what you mean by "extend business logic" (that sounds like > marketing talk :-), but remember that there's a limit as to how much > advice/help I can dispense 'for free' on this mailing list. > > > we need record all the incoming streams into mp4 to made this available > later to watch as VOD. > > > I suggest that you start by looking at our "openRTSP" application - > http://www.live555.com/openRTSP/ - and also reviewing the code for the > "testRTSPClient" demo application. > > > 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 kudr_e at mail.ru Tue Oct 7 09:57:06 2014 From: kudr_e at mail.ru (Kudryavtsev Evgeniy) Date: Tue, 07 Oct 2014 20:57:06 +0400 Subject: [Live-devel] Simple server example Message-ID: <54341B62.4020701@mail.ru> Hello! Could you share a simple example of server which generates frames every 1 second in memory (simple memset()) and sends it to the client. (Really need to send "uncompressed video".) This link (http://www.live555.com/liveMedia/faq.html#liveInput-unicast) I was reading the source code looked... And got confused in the Source, Sink, etc. :-( From pankaj.bansal.jiit at gmail.com Wed Oct 8 11:36:03 2014 From: pankaj.bansal.jiit at gmail.com (pankaj bansal) Date: Thu, 9 Oct 2014 00:06:03 +0530 Subject: [Live-devel] Using RTSP Stream for Real Time Interactive Applications Message-ID: I have an server client application. Server is Java application and client is an android client. I am streaming data using RTSP. I am using the Live555 server for streaming. I can see some constant 2-3 seconds of delay between server and client. Because of which when user gives some input by touch, its effect can be seen at server instantly but it takes 2-3 second for the effect to be visible on client. I have used VideoView Widget of Android to play the stream To make sure I am not using Live555 server in a wrong way, I used live555MediaServer.exe to stream data and vlc client on my android tab. I also used vlc server to stream data and vlc client on android. Still there is some lag of 2 seconds. PS: I have very good network bandwidth So I have 3 questions 1. Is RTSP meant to be used for interactive application where user given some event as input or its meant to stream videos, CCTV camera feeds where 2-3 seconds delay does not hurt ? 2. If RTSP can be used for interactive applications, is Live555 implementation good enough for that ? 3. Is RTSP supposed to have some minimum possible delay ? Regards Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Oct 9 07:48:12 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 9 Oct 2014 16:48:12 +0200 Subject: [Live-devel] openRTSP complain about mpeg4-generic mode Message-ID: <15847_1412866095_5436A02F_15847_1823_1_1BE8971B6CFF3A4F97AF4011882AA2550156588ACC43@THSONEA01CMS01P.one.grp> Hi Ross, Trying to get an audio stream with openRTSP reports the error MPEG4GenericRTPSource Warning: Unknown or unsupported "mode": AAC-hbr. I checked the code of MPEG4GenericRTPSource that check for "aac-hbr" : if (mode == NULL || strcmp(mode, "aac-hbr") != 0) { envir() << "MPEG4GenericRTPSource Warning: Unknown or unsupported \"mode\": " // Check for a "mode" that we don't yet support: //##### << mode << "\n"; } However in MPEG4GenericRTPSink, the mode is compared in lower case. In the RFC (https://www.ietf.org/rfc/rfc3640.txt) it seems to be AAC-hbr, but I did not find if the mode is supposed to be case sensitive or not ? This doesn't seems to have more impact that printing an error, but perhaps I miss something. Thanks for your support. Best Regards, Michel. P.S here after the complete openRTSP output : Opening connection to 186.20.60.243, port 554... ...remote connection opened Sending request: OPTIONS rtsp://186.20.60.243:554/s1.sdp RTSP/1.0 CSeq: 2 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.19) Received 106 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Public: DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN, SET_PARAMETER, GET_PARAMETER Sending request: DESCRIBE rtsp://186.20.60.243:554/s1.sdp RTSP/1.0 CSeq: 3 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.19) Accept: application/sdp Received 798 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Content-Base: rtsp://186.20.60.243:554/s1.sdp/ Content-Type: application/sdp Content-Length: 670 v=0 o=RTSP 1412783906 133347 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 96 b=AS:56 a=rtpmap:96 H264/90000 a=control:trackID=1 a=fmtp:96 packetization-mode=1;profile-level-id=64402a;sprop-parameter-sets=J2RAKqwsagHgCJ+WagoMCoAAAAMAgAAAHgI=,KO4G4sA= m=audio 0 RTP/AVP 97 a=control:trackID=2 a=rtpmap:97 mpeg4-generic/8000/0 a=fmtp:97 streamtype=5;profile-level-id=15;mode=AAC-hbr;config=1588;SizeLength=13;IndexLength=3;IndexDeltaLength=3;CTSDeltaLength=0;DTSDeltaLength=0 m=application 0 RTP/AVP 107 a=rtpmap:107 vnd.onvif.metadata/90000 a=control:trackID=3 Opened URL "rtsp://186.20.60.243:554/s1.sdp", returning a SDP description: v=0 o=RTSP 1412783906 133347 IN IP4 0.0.0.0 s=RTSP server c=IN IP4 0.0.0.0 t=0 0 a=charset:Shift_JIS a=range:npt=0- a=control:* a=etag:1234567890 m=video 0 RTP/AVP 96 b=AS:56 a=rtpmap:96 H264/90000 a=control:trackID=1 a=fmtp:96 packetization-mode=1;profile-level-id=64402a;sprop-parameter-sets=J2RAKqwsagHgCJ+WagoMCoAAAAMAgAAAHgI=,KO4G4sA= m=audio 0 RTP/AVP 97 a=control:trackID=2 a=rtpmap:97 mpeg4-generic/8000/0 a=fmtp:97 streamtype=5;profile-level-id=15;mode=AAC-hbr;config=1588;SizeLength=13;IndexLength=3;IndexDeltaLength=3;CTSDeltaLength=0;DTSDeltaLength=0 m=application 0 RTP/AVP 107 a=rtpmap:107 vnd.onvif.metadata/90000 a=control:trackID=3 Created receiver for "video/H264" subsession (client ports 51432-51433) MPEG4GenericRTPSource Warning: Unknown or unsupported "mode": AAC-hbr Created receiver for "audio/MPEG4-GENERIC" subsession (client ports 49614-49615) Created receiver for "application/VND.ONVIF.METADATA" subsession (client ports 58422-58423) Sending request: SETUP rtsp://186.20.60.243:554/s1.sdp/trackID=1 RTSP/1.0 CSeq: 4 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.19) Transport: RTP/AVP;unicast;client_port=51432-51433 Received 121 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Session: 12835717 Transport: RTP/AVP;unicast;client_port=51432-51433;server_port=8000-8001 Setup "video/H264" subsession (client ports 51432-51433) Sending request: SETUP rtsp://186.20.60.243:554/s1.sdp/trackID=2 RTSP/1.0 CSeq: 5 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.19) Transport: RTP/AVP;unicast;client_port=49614-49615 Session: 12835717 Received 121 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Session: 12835717 Transport: RTP/AVP;unicast;client_port=49614-49615;server_port=8002-8003 Setup "audio/MPEG4-GENERIC" subsession (client ports 49614-49615) Sending request: SETUP rtsp://186.20.60.243:554/s1.sdp/trackID=3 RTSP/1.0 CSeq: 6 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.19) Transport: RTP/AVP;unicast;client_port=58422-58423 Session: 12835717 Received 121 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 6 Session: 12835717 Transport: RTP/AVP;unicast;client_port=58422-58423;server_port=8004-8005 Setup "application/VND.ONVIF.METADATA" subsession (client ports 58422-58423) Created output file: "video-H264-1" Created output file: "audio-MPEG4-GENERIC-2" Created output file: "application-VND.ONVIF.METADATA-3" Sending request: PLAY rtsp://186.20.60.243:554/s1.sdp/ RTSP/1.0 CSeq: 7 User-Agent: openRTSP (LIVE555 Streaming Media v2014.02.19) Session: 12835717 Range: npt=0.000- Received 324 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 7 Session: 12835717 RTP-Info: url=rtsp://186.20.60.243:554/s1.sdp//trackID=1;seq=0;rtptime=0;ssrc=12835717,url=rtsp://186.20.60.243:554/s1.sdp//trackID=2;seq=0;rtptime=0;ssrc=12835717,url=rtsp://186.20.60.243:554/s1.sdp//trackID=3;seq=0;rtptime=0;ssrc=12835717 Range: npt=0- RTCP-Interval: 250 Started playing session Receiving streamed data (signal with "kill -HUP 18378" or "kill -USR1 18378" to terminate)... [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jasleen at beesys.com Wed Oct 8 22:53:58 2014 From: Jasleen at beesys.com (Jasleen Kaur) Date: Thu, 9 Oct 2014 05:53:58 +0000 Subject: [Live-devel] Writing RTSP server In-Reply-To: <5A5FA567-8860-4991-8755-43E2F8226A69@live555.com> References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com>, , <5A5FA567-8860-4991-8755-43E2F8226A69@live555.com> Message-ID: ________________________________ From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com] Sent: Wednesday, October 08, 2014 1:18 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Writing RTSP server Currently uncompressed ARGB data is given out from our custom source and following is the code written increateNewRTPSink of our MedisSubSession class.(which we wish to compress into H.264 and then stream ) OutPacketBuffer::maxSize = 720*576*4; // by default MultiFramedRTPSink* pSink = SimpleRTPSink::createNew(envir(), rtpGroupsock, Because you're planning to stream H.264 video, you MUST use a "H264VideoRTPSink", not a "SimpleRTPSink". Also, we do not support streaming uncompressed video, so you must compress your video (to H.264) before streaming it. I suggest that you use the "testOnDemandRTSPServer" code as a model, noting in particular the "H264VideoFileServerMediaSubsession" class. You will use a similar class in your server. You should first familiarize yourself with how "testOnDemandRTSPServer" streams a H.264 video file (named "test.264"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ Can we compress the data to H.264 using Live555 ? Any component ? Regards -Jasleen -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 9 08:06:42 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Oct 2014 08:06:42 -0700 Subject: [Live-devel] openRTSP complain about mpeg4-generic mode In-Reply-To: <15847_1412866095_5436A02F_15847_1823_1_1BE8971B6CFF3A4F97AF4011882AA2550156588ACC43@THSONEA01CMS01P.one.grp> References: <15847_1412866095_5436A02F_15847_1823_1_1BE8971B6CFF3A4F97AF4011882AA2550156588ACC43@THSONEA01CMS01P.one.grp> Message-ID: > Trying to get an audio stream with openRTSP reports the error MPEG4GenericRTPSource Warning: Unknown or unsupported "mode": AAC-hbr. Are you using the latest version of the software??? See "liveMedia/MediaSession.cpp", line 1291. When the "MPEG4GenericRTPSource" object is created, the 'mode' parameter is (should be) converted to lower case, using the function "attrVal_strToLower()" (as of version 2014.08.23). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 9 08:08:01 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Oct 2014 08:08:01 -0700 Subject: [Live-devel] Simple server example In-Reply-To: <54341B62.4020701@mail.ru> References: <54341B62.4020701@mail.ru> Message-ID: > Could you share a simple example of server which generates frames every 1 second in memory (simple memset()) and sends it to the client. (Really need to send "uncompressed video".) Sorry, but we don't support streaming uncompressed video. See "testOnDemandRTSPServer" for an example of a server that can stream from (several kinds of) compressed video file. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 9 08:21:48 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Oct 2014 08:21:48 -0700 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com>, , <5A5FA567-8860-4991-8755-43E2F8226A69@live555.com> Message-ID: > Can we compress the data to H.264 using Live555 ? No. The "LIVE555 Streaming Media" software does not include any 'codec' (media encoding or decoding) software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Oct 9 09:57:48 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 9 Oct 2014 18:57:48 +0200 Subject: [Live-devel] openRTSP complain about mpeg4-generic mode In-Reply-To: References: <15847_1412866095_5436A02F_15847_1823_1_1BE8971B6CFF3A4F97AF4011882AA2550156588ACC43@THSONEA01CMS01P.one.grp> Message-ID: <21541_1412873872_5436BE90_21541_5149_1_1BE8971B6CFF3A4F97AF4011882AA2550156588ACFD0@THSONEA01CMS01P.one.grp> Hi Ross, By now I am using release 2014.09.11 but an old release 2014.02.19 was in the PATH... Sorry for disturbing. Best Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : jeudi 9 octobre 2014 17:07 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] openRTSP complain about mpeg4-generic mode Trying to get an audio stream with openRTSP reports the error MPEG4GenericRTPSource Warning: Unknown or unsupported "mode": AAC-hbr. Are you using the latest version of the software??? See "liveMedia/MediaSession.cpp", line 1291. When the "MPEG4GenericRTPSource" object is created, the 'mode' parameter is (should be) converted to lower case, using the function "attrVal_strToLower()" (as of version 2014.08.23). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.heliker at gmail.com Thu Oct 9 20:45:09 2014 From: james.heliker at gmail.com (James Heliker) Date: Thu, 9 Oct 2014 20:45:09 -0700 Subject: [Live-devel] doGetNextFrame interval Message-ID: Hi Ross / All - In my AudioBufferSource (based on AudioInputDevice) the doGetNextFrame happens at an extremely fast interval - which is sometimes causing my PCM audio running at 44.1 kHz to get fragmented. For example, I am tuning my server and client software to work with 64 (pcm)frame chunks, however now and then a 20 frame chunk gets out the door as my ASIO device isn't done writing a chunk to my circular buffer. Is there any way to turn the doGetNextFrame interval down / slow it down? Would that have unintended side effects that I'm not considering? Any advice would be very much appreciated. I've got my latency where I need it to be, but it appears these fragmented chunks are causing the remaining audible glitches that I'm battling every few seconds. Thanks for your help!! - James -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 9 21:25:14 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Oct 2014 21:25:14 -0700 Subject: [Live-devel] doGetNextFrame interval In-Reply-To: References: Message-ID: <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com> > In my AudioBufferSource (based on AudioInputDevice) the doGetNextFrame happens at an extremely fast interval - which is sometimes causing my PCM audio running at 44.1 kHz to get fragmented. The frequency at which "doGetNextFrame()" gets called depends entirely on the value that you set for "fDurationInMicroseconds". If you set this appropriately i.e., fDurationInMicroseconds = (numSamplesDelivered*1000000)/samplesPerSecond then "doGetNextFrame()" will get called at the appropriate frequency. Alternatively, if you leave "fDurationInMicroseconds" at its default value of zero, then "doGetNextFrame()" will get called again immediately after you complete delivery of the previous frame, but that's OK, provided that you don't actually complete the delivery (i.e., call "FramedSource::afterGetting()") until you have accumulated however many samples you want to deliver each time. (Of course, you shouldn't 'block' or 'spin' waiting for this to happen.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippes1752 at gmail.com Fri Oct 10 07:17:46 2014 From: philippes1752 at gmail.com (Philippe Spat) Date: Fri, 10 Oct 2014 16:17:46 +0200 Subject: [Live-devel] Endless h264 streaming Message-ID: Hi, I am using live555 dynamic server to stream endlessly on rtp/rtsp port. My idea was to create my own classes which work exactly the same as the testProgs, but with instances of my created objects (rtsp server, sms, ...). It works wonderful just not for h264 elementaries. For h264: When I reboot (or boot) my pc and start my server, connect to it using VLC or MPlayer, it works perfeclty. But when I stop it and restart it, connect to it using VLC or MPlayer again, at the first loop I get "non-existing PPS referenced" errors (no video displayed) but it starts streaming perfectly (and endless) at the 2nd loop again. In other words, i have to reboot after each launch of the server to see my h264 streaming working fine... Note that this is a test application, I do not care if client gets disconnected, the server still streams endlessly till I stop it. Any idea without any source code? I was thinking about SPS and PPS units problems, but in this case I don't understand why it works one time and not many. Regards, Philippe -------------- next part -------------- An HTML attachment was scrubbed... URL: From pankaj.bansal.jiit at gmail.com Fri Oct 10 13:14:31 2014 From: pankaj.bansal.jiit at gmail.com (pankaj bansal) Date: Sat, 11 Oct 2014 01:44:31 +0530 Subject: [Live-devel] RTSP streaming to Android Client Message-ID: Hi I have an server client application. client is an android client. I am using the Live555 server for streaming. I have used VideoView Widget of Android to play the stream. I am having an latency of about 2-3 seconds in frames on server and client. Also the playback is not smooth, it bit jittery. Is this expected if using Live555 server or is it something to do with the Android client? I tried using some other FFMPEG based android clients also. There also I can see the latency but the playback is smoother than while using the android VideoView... PS: have very good network bandwidth. Regards Pankaj Bansal -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.heliker at gmail.com Fri Oct 10 14:26:20 2014 From: james.heliker at gmail.com (James Heliker) Date: Fri, 10 Oct 2014 14:26:20 -0700 Subject: [Live-devel] doGetNextFrame interval In-Reply-To: <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com> References: <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com> Message-ID: Hi Ross - Thanks so much for getting back to me! I see what you mean, and fDurationInMicroseconds is being calculated correctly. For my fragmentation issue, If I don't call afterGetting() then doGetNextFrame() is not ever re-invoked, so the server essentially stops on the first partial read. Is there a method or variable I should set to indicate to Live555 that I want to continue accumulating data? - James On Thu, Oct 9, 2014 at 9:25 PM, Ross Finlayson wrote: > In my AudioBufferSource (based on AudioInputDevice) the doGetNextFrame > happens at an extremely fast interval - which is sometimes causing my PCM > audio running at 44.1 kHz to get fragmented. > > > The frequency at which "doGetNextFrame()" gets called depends entirely on > the value that you set for "fDurationInMicroseconds". If you set this > appropriately > i.e., fDurationInMicroseconds = > (numSamplesDelivered*1000000)/samplesPerSecond > then "doGetNextFrame()" will get called at the appropriate frequency. > > Alternatively, if you leave "fDurationInMicroseconds" at its default value > of zero, then "doGetNextFrame()" will get called again immediately after > you complete delivery of the previous frame, but that's OK, provided that > you don't actually complete the delivery (i.e., call > "FramedSource::afterGetting()") until you have accumulated however many > samples you want to deliver each time. (Of course, you shouldn't 'block' > or 'spin' waiting for this to happen.) > > > 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 Sat Oct 11 07:48:21 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Oct 2014 07:48:21 -0700 Subject: [Live-devel] Endless h264 streaming In-Reply-To: References: Message-ID: > For h264: When I reboot (or boot) my pc and start my server, connect to it using VLC or MPlayer, it works perfeclty. But when I stop it and restart it, connect to it using VLC or MPlayer again, at the first loop I get "non-existing PPS referenced" errors (no video displayed) but it starts streaming perfectly (and endless) at the 2nd loop again. In other words, i have to reboot after each launch of the server to see my h264 streaming working fine... The problem here, I think, is that - in your H.264 video stream - SPS and PPS NAL units are occurring only at the start of the stream. Therefore, if a client tries to connect to the stream in some position other than the start, the server is having trouble finding the SPS and PPS NAL units. First, you should make sure that when your "OnDemandServerMediaSubsession" subclass's constructor calls the "OnDemandServerMediaSubsession" constructor, it sets the "reuseFirstSource" parameter to True. That way, if more than one client connects concurrently, the server won't try to read the stream again for the second (and other) clients. Second, in your implementation of the "createNewRTPSink()" virtual function, you may need to use one of the versions of "H264VideoRTPSink::createNew()" that specify the SPS and PPS NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Oct 11 07:53:14 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Oct 2014 07:53:14 -0700 Subject: [Live-devel] RTSP streaming to Android Client In-Reply-To: References: Message-ID: > I have an server client application. client is an android client. I am using the Live555 server for streaming. I have used VideoView Widget of Android to play the stream. I am having an latency of about 2-3 seconds in frames on server and client. Also the playback is not smooth, it bit jittery. > > Is this expected if using Live555 server or is it something to do with the Android client? > No, latency like this is almost always occurring in the client (when it buffers, decodes, and renders incoming media data). (The only exception is if you are streaming RTP-over-TCP over a very congested TCP connection, in which case some of the latency might be caused by network buffering inside the sender's OS (*not* the LIVE555 server code).) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Oct 11 08:14:17 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Oct 2014 08:14:17 -0700 Subject: [Live-devel] doGetNextFrame interval In-Reply-To: References: <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com> Message-ID: <74FB1AA3-2F32-46A6-BA71-EE629CD7042F@live555.com> > I see what you mean, and fDurationInMicroseconds is being calculated correctly. For my fragmentation issue, If I don't call afterGetting() then doGetNextFrame() is not ever re-invoked, so the server essentially stops on the first partial read. > > Is there a method or variable I should set to indicate to Live555 that I want to continue accumulating data? Your "doGetNextFrame()" implementation should call "FramedSource::afterGetting()" *only* when you have a complete frame that you want to deliver to the downstream object. If you don't yet have a complete frame, then simply return, without calling "FramedSource::afterGetting()". If you do that, then "doGetNextFrame()" won't get called again in the meantime. But, you're probably thinking, if "doGetNextFrame()" simply returns without completing delivery of a frame, and doesn't get called again, then how can I figure out when I later get enough data to deliver? Basically, that has to be an 'event' that gets handled within the event loop. One way to do this is by 'polling' - i.e., by scheduling a periodic delayed task (using "TaskScheduler::scheduleDelayedTask()") that checks whether you have enough data (and then calls "FramedSource::afterGetting()" when you do have enough data). Another way is to have a separate thread that's gathering data, and then have this thread use an 'event trigger' (by calling "TaskScheduler::triggerEvent()") to signal when data is ready to be delivered. For an example of this, see the 'DeviceSource' code in "liveMedia/DeviceSource.cpp". (Note that if you do this, then "TaskScheduler::triggerEvent()" is the *only* LIVE555 function that the separate 'data gathering' thread is allowed to call; see ). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From megaplace at hotmail.com Sat Oct 11 15:10:29 2014 From: megaplace at hotmail.com (Krishna Patel) Date: Sat, 11 Oct 2014 22:10:29 +0000 Subject: [Live-devel] Wowza Streaming Engine compatibility problem In-Reply-To: <74FB1AA3-2F32-46A6-BA71-EE629CD7042F@live555.com> References: , <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com>, , <74FB1AA3-2F32-46A6-BA71-EE629CD7042F@live555.com> Message-ID: Hi, Live555 client drops connection after 90 seconds of receiving RTSP stream from Wowza Streaming Server 4.0.6 over HTTP tunneling protocol. Socket operation fail with WSAECONNABORTED error (An established connection was aborted by the software in your host machine.) Receiving the stream over TCP works just fine. This behavior can be seen with openRTSP v2014.10.07: openRTSP -T 80 rtsp://q1604.dnsdojo.com:1935/live/sys1.stream Thanks, Krishna. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Oct 11 15:41:36 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Oct 2014 15:41:36 -0700 Subject: [Live-devel] Wowza Streaming Engine compatibility problem In-Reply-To: References: , <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com>, , <74FB1AA3-2F32-46A6-BA71-EE629CD7042F@live555.com> Message-ID: <9A66E194-978F-4FDE-8082-1DEDFAEB8941@live555.com> You'll need to contact 'Wowza' about this. The problem appears to be with their server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.heliker at gmail.com Sat Oct 11 19:10:51 2014 From: james.heliker at gmail.com (James Heliker) Date: Sat, 11 Oct 2014 19:10:51 -0700 Subject: [Live-devel] doGetNextFrame interval In-Reply-To: <74FB1AA3-2F32-46A6-BA71-EE629CD7042F@live555.com> References: <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com> <74FB1AA3-2F32-46A6-BA71-EE629CD7042F@live555.com> Message-ID: Hi Ross - Thanks again for your help here. I understand what you're saying with using an event trigger for when additional data is available, but I'm having no luck implementing as my C++ is fairly bad. Coming from C# and other higher-level languages is proving to be a bit of a learning curve for me! I have a very simple circular buffer in my code as RtAudio code (for ASIO input device) calls back my code, and the Live555 code also calls back my code, both at their own regular intervals. Below, I've posted my AudioBufferSource::doGetNextFrame(), in hopes you might be able to provide a more verbose suggestion... I understand if you don't have the time. Thanks again! - James void AudioBufferSource::doGetNextFrame() { signed availableFrames = fBufferManager->_writeCnt - fBufferManager->_readCnt; while (availableFrames < 64) { availableFrames = fBufferManager->_writeCnt - fBufferManager->_readCnt; } fFrameSize = 0; if (fLimitNumBytesToStream && fNumBytesToStream < fMaxSize) { fMaxSize = fNumBytesToStream; } if (fPreferredFrameSize < fMaxSize) { fMaxSize = fPreferredFrameSize; } unsigned bytesPerSample = (fNumChannels*fBitsPerSample) / 8; if (bytesPerSample == 0) bytesPerSample = 1; // because we can't read less than a byte at a time unsigned numberOfPCMFramesToGet = fMaxSize / bytesPerSample; unsigned pcmFramesGotten = fBufferManager->getFrames((int16_t*)fTo, numberOfPCMFramesToGet); unsigned numBytesRead = pcmFramesGotten * bytesPerSample; fFrameSize += numBytesRead; fTo += numBytesRead; fMaxSize -= numBytesRead; fNumBytesToStream -= numBytesRead; // Set the 'presentation time' and 'duration' of this RTP frame if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0) { // This is the first frame, so use the current time: gettimeofday(&fPresentationTime, NULL); } else { // Increment by the play time of the previous RTP frame unsigned uSeconds = fPresentationTime.tv_usec + fLastPlayTime; fPresentationTime.tv_sec += uSeconds / 1000000; fPresentationTime.tv_usec = uSeconds % 1000000; } // Remember the play time of this RTP frame fDurationInMicroseconds = fLastPlayTime = (unsigned)((fPlayTimePerSample*fFrameSize) / bytesPerSample); // Inform the reader that he has data: // To avoid possible infinite recursion, we need to return to the event loop to do this: nextTask() = envir().taskScheduler().scheduleDelayedTask(0, (TaskFunc*)FramedSource::afterGetting, this); } On Sat, Oct 11, 2014 at 8:14 AM, Ross Finlayson wrote: > I see what you mean, and fDurationInMicroseconds is being calculated > correctly. For my fragmentation issue, If I don't call afterGetting() then > doGetNextFrame() is not ever re-invoked, so the server essentially stops on > the first partial read. > > Is there a method or variable I should set to indicate to Live555 that I > want to continue accumulating data? > > > Your "doGetNextFrame()" implementation should call > "FramedSource::afterGetting()" *only* when you have a complete frame that > you want to deliver to the downstream object. If you don't yet have a > complete frame, then simply return, without > calling "FramedSource::afterGetting()". If you do that, then > "doGetNextFrame()" won't get called again in the meantime. > > But, you're probably thinking, if "doGetNextFrame()" simply returns > without completing delivery of a frame, and doesn't get called again, then > how can I figure out when I later get enough data to deliver? Basically, > that has to be an 'event' that gets handled within the event loop. One way > to do this is by 'polling' - i.e., by scheduling a periodic delayed task > (using "TaskScheduler::scheduleDelayedTask()") that checks whether you have > enough data (and then calls "FramedSource::afterGetting()" when you do have > enough data). Another way is to have a separate thread that's gathering > data, and then have this thread use an 'event trigger' (by calling > "TaskScheduler::triggerEvent()") to signal when data is ready to be > delivered. For an example of this, see the 'DeviceSource' code in > "liveMedia/DeviceSource.cpp". (Note that if you do this, then > "TaskScheduler::triggerEvent()" is the *only* LIVE555 function that the > separate 'data gathering' thread is allowed to call; see < > http://www.live555.com/liveMedia/faq.html#threads>). > > > 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 Sat Oct 11 21:54:44 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Oct 2014 21:54:44 -0700 Subject: [Live-devel] doGetNextFrame interval In-Reply-To: References: <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com> <74FB1AA3-2F32-46A6-BA71-EE629CD7042F@live555.com> Message-ID: <6140A813-2122-45F8-B446-CF265610206E@live555.com> > Below, I've posted my AudioBufferSource::doGetNextFrame(), in hopes you might be able to provide a more verbose suggestion... I understand if you don't have the time. Yes, unfortunately I'm limited in how much time I can spend providing assistance for free (especially for individual projects like this). But hopefully I've helped point you in the right direction. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dee.earley at icode.co.uk Mon Oct 13 01:09:09 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Mon, 13 Oct 2014 08:09:09 +0000 Subject: [Live-devel] Wowza Streaming Engine compatibility problem In-Reply-To: References: , <2F58B19D-84BD-48C1-91EB-8710E6CA4DC6@live555.com>, , <74FB1AA3-2F32-46A6-BA71-EE629CD7042F@live555.com> Message-ID: Look at a packet capture from Wireshark or similar. The server explicitly stopped the stream and closed the connection after 90 seconds. -- Deanna Earley | Lead developer | icatchercctv w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338 Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325 From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Krishna Patel Sent: 11 October 2014 23:10 To: LIVE555 Streaming Media - development & use Subject: [Live-devel] Wowza Streaming Engine compatibility problem Hi, Live555 client drops connection after 90 seconds of receiving RTSP stream from Wowza Streaming Server 4.0.6 over HTTP tunneling protocol. Socket operation fail with WSAECONNABORTED error (An established connection was aborted by the software in your host machine.) Receiving the stream over TCP works just fine. This behavior can be seen with openRTSP v2014.10.07: openRTSP -T 80 rtsp://q1604.dnsdojo.com:1935/live/sys1.stream Thanks, Krishna. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali at and-or.com Mon Oct 13 09:29:24 2014 From: ali at and-or.com (Muhammad Ali) Date: Mon, 13 Oct 2014 21:29:24 +0500 Subject: [Live-devel] Audio+Video streams OpenRTSP to FFMPEG Message-ID: My objective is to use OpenRTSP to receive audio + video stream from IP camera and pass it on to FFMPEG which can then stream it to an RTMP server. I've been using pipe to send stdout to ffmpeg (pipe input source) but that was only a video stream (OpenRTSP -v flag). Now the requirement has come to stream both the audio and video streams. So ofcourse I tried to replace -v with -4 and obviously it failed as they are two separate streams and not a single elementary stream. Am i correct ? So now, what will be the correct way to achieve my objective. I myself am a developer and am not shy to code but I prefer to use something that is already around (if there is). -- Muhammad Ali And Or Logic www.andorlogic.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at speed666.info Mon Oct 13 10:04:03 2014 From: marcin at speed666.info (Marcin) Date: Mon, 13 Oct 2014 19:04:03 +0200 Subject: [Live-devel] Audio+Video streams OpenRTSP to FFMPEG In-Reply-To: References: Message-ID: <543C0603.2020102@speed666.info> Hi, You cannot do this using pipe. You need to pass both streams to libavcodec libs as separate streams (synchornized). Then you can encode them and MUX them into FLV mux to pass it to RTMP server. Marcin W dniu 2014-10-13 18:29, Muhammad Ali pisze: > My objective is to use OpenRTSP to receive audio + video stream from > IP camera and pass it on to FFMPEG which can then stream it to an RTMP > server. > > I've been using pipe to send stdout to ffmpeg (pipe input source) but > that was only a video stream (OpenRTSP -v flag). Now the requirement > has come to stream both the audio and video streams. So ofcourse I > tried to replace -v with -4 and obviously it failed as they are two > separate streams and not a single elementary stream. Am i correct ? > > So now, what will be the correct way to achieve my objective. I myself > am a developer and am not shy to code but I prefer to use something > that is already around (if there is). > > -- > Muhammad Ali > And Or Logic > www.andorlogic.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 Oct 13 11:30:59 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 13 Oct 2014 11:30:59 -0700 Subject: [Live-devel] Audio+Video streams OpenRTSP to FFMPEG In-Reply-To: References: Message-ID: You will need to write your own RTSP client application to do this. I suggest using our "testRTSPClient" code as a model. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimondo at ismb.it Tue Oct 14 06:22:02 2014 From: raimondo at ismb.it (Nadir Raimondo) Date: Tue, 14 Oct 2014 15:22:02 +0200 Subject: [Live-devel] UDP packet loss Message-ID: <543D237A.6050703@ismb.it> Dear all, I'm trying to adapt testReplicator to restream a transport stream from a unicast address to a multicast one. It works correctly if the UDP packet size in the input stream is fixed to 1316 bytes. The problem occurs if the packets size is allowed to change freely assuming values which are not multiples of 188 bytes (e.g using ffmpeg as input encoder/streamer). In such a case I notice a random loss of entire burst of UDP packets and live555 does not log this anyhow. As a consequence of that artifacts are introduced in the output stream which loses the sequentiality of the ts-stream sync-byte. This loss seems not to be directly related to the packet size since packets of same dimensions can be either received or dropped. This cannot be due to fragmentation issues because packets size is anyway lower that the UDP max size of 1480 bytes and happens even if working in localhost. On the other side if I receive the stream directly from a socket without using live555 all the data arrive correctly (no packet loss). So some questions arise: 1) Should live555 be hable to handle input UDP stream with variable packet lengths? Or should the length be always multiple of 188? 2) Any advice about which class of live555 can be responsible for this loss? Thank you in advance, Yours, Nadir From finlayson at live555.com Tue Oct 14 06:35:36 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Oct 2014 06:35:36 -0700 Subject: [Live-devel] UDP packet loss In-Reply-To: <543D237A.6050703@ismb.it> References: <543D237A.6050703@ismb.it> Message-ID: <0B275485-DE2B-4145-AE5B-4C3773BD7536@live555.com> You haven't really described what kind of packets these are supposed to be - i.e., whether they are supposed to be "Transport Stream data in raw-UDP packets", or "Transport Stream data in RTP/UDP packets". You also haven't said what specifically you are doing to these packets - other than that you have 'adapted' testReplicator. What kind of data is supposed to be in these packets, and what specifically are you trying to do with them - i.e., what 'sink', 'source', and 'framer' objects are involved? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimondo at ismb.it Tue Oct 14 07:18:39 2014 From: raimondo at ismb.it (Nadir Raimondo) Date: Tue, 14 Oct 2014 16:18:39 +0200 Subject: [Live-devel] UDP packet loss In-Reply-To: <0B275485-DE2B-4145-AE5B-4C3773BD7536@live555.com> References: <543D237A.6050703@ismb.it> <0B275485-DE2B-4145-AE5B-4C3773BD7536@live555.com> Message-ID: <543D30BF.6080007@ismb.it> Hi Ross, sorry for the inaccuracy, I'll try to describe my architecture with more details. The application using live555 has a BasicUDPSource that is replicated through a StreamReplicator to feed a BasicUDPSink and two FileSink. We stream input for this application with ffmpeg: it is a transport stream containing a h.264 video and a second PES of metadata. Packets are then supposed to be Transport Stream data in raw-UDP packets. The loss occurs somewhere before the Groupsock::handleRead() call, since adding logging there to show all incoming packets I notice that the missing ones have already gone at this stage. Nadir On 10/14/2014 3:35 PM, Ross Finlayson wrote: > You haven't really described what kind of packets these are supposed > to be - i.e., whether they are supposed to be "Transport Stream data > in raw-UDP packets", or "Transport Stream data in RTP/UDP packets". > You also haven't said what specifically you are doing to these > packets - other than that you have 'adapted' testReplicator. > > What kind of data is supposed to be in these packets, and what > specifically are you trying to do with them - i.e., what 'sink', > 'source', and 'framer' objects are involved? > > 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 Oct 14 12:47:29 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Oct 2014 12:47:29 -0700 Subject: [Live-devel] UDP packet loss In-Reply-To: <543D30BF.6080007@ismb.it> References: <543D237A.6050703@ismb.it> <0B275485-DE2B-4145-AE5B-4C3773BD7536@live555.com> <543D30BF.6080007@ismb.it> Message-ID: <63C0C8AA-884C-4084-85D3-44115D08C04E@live555.com> > The application using live555 has a BasicUDPSource that is replicated through a StreamReplicator to feed a BasicUDPSink and two FileSink. I suspect that your problem is simply that the data rate of your input stream is too high for your system to handle. (If that's the case, then it has nothing to do with the LIVE555 code. Increasing the size of the "BasicUDPSource"s OS input socket buffer - using "increaseReceiveBufferTo()" - *might* alleviate the problem, but, if your input stream's data rate is too high, can never overcome it.) In particular, if the two "FileSink"s are for files that are on the same disk, then many OS's file systems may not handle concurrent high-speed writes to these two separate files well; you could end up with lots of disk 'seeking', which will reduce throughput substantially. You can test this by having both of your "FileSink"s use the special file "/dev/null" (which doesn't do any actual disk writing). If you do this, I suspect that you'll see a lot less packet loss. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Tue Oct 14 23:19:38 2014 From: kingaceck at 163.com (kingaceck) Date: Wed, 15 Oct 2014 14:19:38 +0800 Subject: [Live-devel] rtp over tcp Message-ID: <2014101514193685945212@163.com> When I transport rtp packets over tcp using live555 , I get many logs like below after playing many minutes. sendRTPorRTCPPacketOverTCP: failed! (errno 32) sendRTPorRTCPPacketOverTCP: failed! (errno 32) ... or sendRTPorRTCPPacketOverTCP: failed! (errno 9) sendRTPorRTCPPacketOverTCP: failed! (errno 9) ... then the vlc client can't receive any rtp packets. I reconnect to the live555 the question will come appear again. kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Oct 15 00:19:25 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Oct 2014 00:19:25 -0700 Subject: [Live-devel] rtp over tcp In-Reply-To: <2014101514193685945212@163.com> References: <2014101514193685945212@163.com> Message-ID: <06C76E0E-7A66-4384-9503-3B87334B03C3@live555.com> > When I transport rtp packets over tcp using live555 , I get many logs like below after playing many minutes. > sendRTPorRTCPPacketOverTCP: failed! (errno 32) > sendRTPorRTCPPacketOverTCP: failed! (errno 32) > ... > > or > > sendRTPorRTCPPacketOverTCP: failed! (errno 9) > sendRTPorRTCPPacketOverTCP: failed! (errno 9) > ... > > then the vlc client can't receive any rtp packets. - What OS are you running (for both your client (VLC) and server)? - Are you using the latest version of the "LIVE555 Streaming Media" code (the only version that we support) for your server? - Is your client running the latest version of VLC (2.1.5)? - What happens when you run "openRTSP -t" (again, using the latest version of the "LIVE555 Streaming Media" code) instead of VLC? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at svennergr.de Thu Oct 16 02:41:40 2014 From: live555 at svennergr.de (Sven Grossmann) Date: Thu, 16 Oct 2014 11:41:40 +0200 Subject: [Live-devel] RTSP stream of webm-file on windows machines Message-ID: <357274530c745f79527400d1cbf8df8c@svennergr.de> Hello folks, I try to stream a webm-file on a windows machine via the live555MediaServer, but unfortunately I can't get the RTSP stream played on both VLC and MediaPlayerClassic. VLC logs, that the audio and video codec is undefined. I am able to stream MPG files and play them via VLC, also I am able to stream and play the same webm-files on an ubuntu machine. Are there any known issues with streams to webm-files on windows machines? OS: Windows 7 SP1 latest Live555MediaServer latest VLC Player File: http://www.webmfiles.org/demo-files/ From finlayson at live555.com Thu Oct 16 02:53:58 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Oct 2014 02:53:58 -0700 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: <357274530c745f79527400d1cbf8df8c@svennergr.de> References: <357274530c745f79527400d1cbf8df8c@svennergr.de> Message-ID: <1FB79DB0-09F3-4262-9AE3-40FC9C1EF2EA@live555.com> > I try to stream a webm-file on a windows machine via the live555MediaServer, but unfortunately I can't get the RTSP stream played on both VLC and MediaPlayerClassic. > VLC logs, that the audio and video codec is undefined. http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Please put your ".webm" file on a publically-accessible web (or FTP) server, and post the URL, and I'll download and take a look at it, to see if I can figure out what's wrong. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at svennergr.de Thu Oct 16 03:46:08 2014 From: live555 at svennergr.de (Sven Grossmann) Date: Thu, 16 Oct 2014 12:46:08 +0200 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: <1FB79DB0-09F3-4262-9AE3-40FC9C1EF2EA@live555.com> References: <357274530c745f79527400d1cbf8df8c@svennergr.de> <1FB79DB0-09F3-4262-9AE3-40FC9C1EF2EA@live555.com> Message-ID: Am 2014-10-16 11:53, schrieb Ross Finlayson: >> I try to stream a webm-file on a windows machine via the >> live555MediaServer, but unfortunately I can't get the RTSP stream >> played on both VLC and MediaPlayerClassic. >> VLC logs, that the audio and video codec is undefined. > > http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work [1] > > Please put your ".webm" file on a publically-accessible web (or FTP) > server, and post the URL, and I'll download and take a look at it, to > see if I can figure out what's wrong. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > Links: > ------ > [1] http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel Thanks for your fast reply. I used files published at http://www.webmfiles.org/demo-files/ http://video.webmfiles.org/big-buck-bunny_trailer.webm http://video.webmfiles.org/elephants-dream.webm From finlayson at live555.com Thu Oct 16 08:33:49 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Oct 2014 08:33:49 -0700 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: References: <357274530c745f79527400d1cbf8df8c@svennergr.de> <1FB79DB0-09F3-4262-9AE3-40FC9C1EF2EA@live555.com> Message-ID: <6AC9EACC-BCEB-40C1-8073-0D66A9BD37F5@live555.com> > I used files published at http://www.webmfiles.org/demo-files/ > > http://video.webmfiles.org/big-buck-bunny_trailer.webm > http://video.webmfiles.org/elephants-dream.webm I have no problem streaming either of those file using the "LIVE555 Media Server", and playing the stream using the latest version (2.1.5) of VLC. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 16 09:09:52 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Oct 2014 09:09:52 -0700 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: <6AC9EACC-BCEB-40C1-8073-0D66A9BD37F5@live555.com> References: <357274530c745f79527400d1cbf8df8c@svennergr.de> <1FB79DB0-09F3-4262-9AE3-40FC9C1EF2EA@live555.com> <6AC9EACC-BCEB-40C1-8073-0D66A9BD37F5@live555.com> Message-ID: >> I used files published at http://www.webmfiles.org/demo-files/ >> >> http://video.webmfiles.org/big-buck-bunny_trailer.webm >> http://video.webmfiles.org/elephants-dream.webm > > I have no problem streaming either of those file using the "LIVE555 Media Server", and playing the stream using the latest version (2.1.5) of VLC. I should also note (because you were asking specifically about Windows) that I had no problem running the "LIVE555 Media Server" on Windows, and streaming either of those ".webm" files either locally (to VLC version 2.1.5 running on the same Windows computer), or remotely. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jasleen at beesys.com Thu Oct 16 05:13:21 2014 From: Jasleen at beesys.com (Jasleen Kaur) Date: Thu, 16 Oct 2014 12:13:21 +0000 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com>, , <5A5FA567-8860-4991-8755-43E2F8226A69@live555.com> , Message-ID: ________________________________ From: live-devel [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com] Sent: Thursday, October 09, 2014 8:51 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Writing RTSP server Can we compress the data to H.264 using Live555 ? No. The "LIVE555 Streaming Media" software does not include any 'codec' (media encoding or decoding) software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ Hi Ross I encoded the data using FFMPEG, and then sent using Live555.The codec used is H.264, and the hence the sink class. The problem is that VLC plays the stream , but the video is not visible i.e it is coming as black. Now the question is that , how does the VLC come to know about the size and format of the video being played, as it is not a video file with header information.Only the frames and encoded and sent. I am unable to understand the reason behind the blank output on VLC. Regards Jasleen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Oct 16 06:30:11 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 16 Oct 2014 15:30:11 +0200 Subject: [Live-devel] live555MediaServer segmentation violation when severals RTSP client access to the same stream. Message-ID: <3926_1413466214_543FC866_3926_411_1_1BE8971B6CFF3A4F97AF4011882AA255015658B2FD96@THSONEA01CMS01P.one.grp> Hi Ross, Since a couple of months live555MediaServer exit times to times with a segmentation violation when it is used by several client that ask for the same file. One of the back trace is : #0 ServerMediaSession::duration (this=0x131a500) at ServerMediaSession.cpp:177 #1 0x0000000000412615 in ServerMediaSession::generateSDPDescription (this=0x131a500) at ServerMediaSession.cpp:243 #2 0x00000000004074f6 in RTSPServer::RTSPClientConnection::handleCmd_DESCRIBE (this=0x130c460, urlPreSuffix=, urlSuffix=, fullRequestStr=0x130c48c "DESCRIBE rtsp://127.0.0.1:8554/video.264 RTSP/1.0\r\nCSeq: 3\r\nUser-Agent: RTSP client (LIVE555 Streaming Media v2013.02.11)\r\nAccept: application/sdp\r\n\r\n") at RTSPServer.cpp:526 #3 0x0000000000405a30 in RTSPServer::RTSPClientConnection::handleRequestBytes (this=0x130c460, newBytesRead=150) at RTSPServer.cpp:990 #4 0x00000000004063c0 in RTSPServer::RTSPClientConnection::incomingRequestHandler1 (this=) at RTSPServer.cpp:790 #5 0x00000000004063cf in RTSPServer::RTSPClientConnection::incomingRequestHandler (instance=) at RTSPServer.cpp:783 #6 0x000000000044a762 in BasicTaskScheduler::SingleStep (this=0x1199010, maxDelayTime=) at BasicTaskScheduler.cpp:171 #7 0x000000000044b8d5 in BasicTaskScheduler0::doEventLoop (this=0x1199010, watchVariable=0x0) at BasicTaskScheduler0.cpp:80 #8 0x00000000004020bb in main (argc=, argv=) at live555MediaServer.cpp:89 Others are similars accessing to a ServerMediaSession, sometimes processing SETUP. I tried to comment out in DynamicRTSPServer.cpp removing of existing sessions (because I suspect it destroy ServerMediaSession that are still used by others RTSP connections) } else { if (smsExists && isFirstLookupInSession) { // Remove the existing "ServerMediaSession" and create a new one, in case the underlying // file has changed in some way: // removeServerMediaSession(sms); // sms = NULL; } if (sms == NULL) { sms = createNewSMS(envir(), streamName, fid); addServerMediaSession(sms); } fclose(fid); return sms; } Obviously this change the behavior because it does not re-read the file, but with this modification it doesnot seems to crash anymore. Is there some restrictions to access several times to the same stream provided by live555MediaServer ? Thanks again for your support. Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.ekholm at d-pointer.com Thu Oct 16 12:19:45 2014 From: jan.ekholm at d-pointer.com (Jan Ekholm) Date: Thu, 16 Oct 2014 22:19:45 +0300 Subject: [Live-devel] Proper use of StreamReplicator Message-ID: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> Hi, I've use Live555 for some prototypes for a while now and it's working quite well so far. My use cases are to act as a cental video hub for a number of remote surveillance cameras as well as locally connected USB cameras and serve H264/MJPEG streams using unicast and multicast. Those scenarios more or less work ok. The code isn't too pretty but Live555 is quite hard to use. Now I need to save the streams to disk too. There is the handy StreamReplicator class that should allow me to save the streams to disk as well as stream them to clients, but I've not really understood how to use it correctly. From what I've understood I need to create one StreamReplicator for the source stream and then replicator->createNewStreamReplica() for the streaming as well as the saving. Well, this does not work at all so I'm doing something wrong. The class that handles a local USB camera and unicasts MJPEG is basically: class LocalMJpegUnicastServerMediaSubsession : public OnDemandServerMediaSubsession { ... protected: virtual FramedSource* createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate); virtual RTPSink* createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource); private: CameraParameters m_cameraParameters; StreamReplicator * m_replicator; FileSink * m_saveSink; }; FramedSource* LocalMJpegUnicastServerMediaSubsession::createNewStreamSource (unsigned clientSessionID, unsigned& estBitRate) { // create and initialize a source for the camera. This is a JPEGVideoSource subclass that captures, encodes and delivers JPEG frames // it works fine as long as do not try to use StreamReplicator MJpegFramedSource *source = MJpegFramedSource::createNew( envir() ); source->initialize( m_cameraParameters ); m_replicator = StreamReplicator::createNew( envir(), source, False ); return m_replicator->createStreamReplica(); } RTPSink* LocalMJpegUnicastServerMediaSubsession::createNewRTPSink (Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource) { return JPEGVideoRTPSink::createNew( envir(), rtpGroupsock ); } When I use this ServerMediaSubsession and connect a client the call sequence I see is: LocalMJpegUnicastServerMediaSubsession::createNewStreamSource() LocalMJpegUnicastServerMediaSubsession::createNewRTPSink() LocalMJpegUnicastServerMediaSubsession::createNewStreamSource() LocalMJpegUnicastServerMediaSubsession::createNewRTPSink() Nothing is however delivered to the network. As if the stream doesn't start. I never see a call to MJpegFramedSource::doGetNextFrame() which is the overridden method for, well, getting the next frame. No errors, no crashes and no data. If I now try to save the stream I do get something saved, but I have not analyzed the file yet. The amount of data looks correct though (a lot of data very fast). To start saving I use code like (simplified): void LocalMJpegUnicastServerMediaSubsession::startSavingStream (const std::string & filename) { FramedSource * source = m_replicator->createStreamReplica(); m_saveSink = FileSink::createNew( envir(), filename.c_str(), bufferSize ); m_saveSink->startPlaying( *source, 0, 0 ); } So I get no stream but a saved file. If I change my createNewStreamSource () back to the below it works fine for streaming: FramedSource* LocalMJpegUnicastServerMediaSubsession::createNewStreamSource (unsigned clientSessionID, unsigned& estBitRate) { MJpegFramedSource *source = MJpegFramedSource::createNew( envir() ); source->initialize( m_cameraParameters ); return source; } In this case there is no replicator at all and I can not save the stream. Trying to later add a replicator to the source and then use that with the FileSink leads to infinite recursion in doGetNextFrame(). But as I've understood I can not use a replicator like this the behavior is perhaps to be expected. In this case I get a stream but no save file. So, how would one properly use StreamReplicator here so that I get both a stream and a save file? Later I also need to be able to save streams that are local cameras multicasted as well as remote proxied cameras. -- Jan Ekholm jan.ekholm at d-pointer.com From finlayson at live555.com Thu Oct 16 15:16:18 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Oct 2014 15:16:18 -0700 Subject: [Live-devel] Writing RTSP server In-Reply-To: References: , <6BC06FE5-A6A9-43DD-B275-AF14369CE105@live555.com>, , <5A5FA567-8860-4991-8755-43E2F8226A69@live555.com> , Message-ID: > I encoded the data using FFMPEG, and then sent using Live555.The codec used is H.264, and the hence the sink class. > > The problem is that VLC plays the stream , but the video is not visible i.e it is coming as black. > Now the question is that , how does the VLC come to know about the size and format of the video being played, as it is not a video file with header information.Only the frames and encoded and sent. > > I am unable to understand the reason behind the blank output on VLC. First, note that VLC is not our software, so you should do your testing first using "openRTSP" as your RTSP client. Then, rename the resulting output file to have a ".h264" filename suffix, and then try playing the file (not the stream) using VLC. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 16 16:11:35 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Oct 2014 16:11:35 -0700 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: References: <357274530c745f79527400d1cbf8df8c@svennergr.de> <1FB79DB0-09F3-4262-9AE3-40FC9C1EF2EA@live555.com> <6AC9EACC-BCEB-40C1-8073-0D66A9BD37F5@live555.com> Message-ID: > I should also note (because you were asking specifically about Windows) that I had no problem running the "LIVE555 Media Server" on Windows, and streaming either of those ".webm" files either locally (to VLC version 2.1.5 running on the same Windows computer), or remotely. I did, however, have to allow "live555MediaServer.exe" to bypass Windows' firewall. (Windows prompted me about this.) You should make sure that you're doing this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 16 16:16:41 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Oct 2014 16:16:41 -0700 Subject: [Live-devel] live555MediaServer segmentation violation when severals RTSP client access to the same stream. In-Reply-To: <3926_1413466214_543FC866_3926_411_1_1BE8971B6CFF3A4F97AF4011882AA255015658B2FD96@THSONEA01CMS01P.one.grp> References: <3926_1413466214_543FC866_3926_411_1_1BE8971B6CFF3A4F97AF4011882AA255015658B2FD96@THSONEA01CMS01P.one.grp> Message-ID: Aha! You've run into a rare 'race condition'. Thanks for reporting this. I've just installed a new version (2014.10.16) of the "LIVE555 Streaming Media" software that should fix this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 16 18:34:58 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Oct 2014 18:34:58 -0700 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> Message-ID: <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> > I've use Live555 for some prototypes for a while now and it's working quite well so far. My use cases > are to act as a cental video hub for a number of remote surveillance cameras as well as locally connected > USB cameras and serve H264/MJPEG streams using unicast and multicast. Those scenarios more or > less work ok. The code isn't too pretty but Live555 is quite hard to use. Yes, it's hard to use, but that's mainly because it's used to build complex systems. It's also intended for experienced systems programmers; not for the 'faint of heart' :-) Finally, everyone should remember that Live Networks, Inc. is not a charity, and I make no money by helping people with the software 'for free' on this mailing list; it's just something that I do as a public service. > Now I need to save the streams to disk too. There is the handy StreamReplicator class that should allow > me to save the streams to disk as well as stream them to clients, but I've not really understood how to use > it correctly. From what I've understood I need to create one StreamReplicator for the source stream and > then replicator->createNewStreamReplica() for the streaming as well as the saving. Well, this does not work > at all so I'm doing something wrong. > > The class that handles a local USB camera and unicasts MJPEG is basically: > > class LocalMJpegUnicastServerMediaSubsession : public OnDemandServerMediaSubsession { First, because you're streaming from live sources (rather than prerecorded files), make sure that your "LocalMJpegUnicastServerMediaSubsession" constructor sets the "reuseFirstSource" parameter - in the "OnDemandServerMediaSubsession" constructor - to True. > FramedSource* LocalMJpegUnicastServerMediaSubsession::createNewStreamSource (unsigned clientSessionID, unsigned& estBitRate) { > // create and initialize a source for the camera. This is a JPEGVideoSource subclass that captures, encodes and delivers JPEG frames > // it works fine as long as do not try to use StreamReplicator > MJpegFramedSource *source = MJpegFramedSource::createNew( envir() ); > source->initialize( m_cameraParameters ); > > m_replicator = StreamReplicator::createNew( envir(), source, False ); I would replace this line with: if (m_replicator == NULL) { m_replicator = StreamReplicator::createNew( envir(), source, False ); startSavingStream(yourFileName); } and, of course, initialize "m_replicator" to NULL in your constructor. > > return m_replicator->createStreamReplica(); This is correct. > RTPSink* LocalMJpegUnicastServerMediaSubsession::createNewRTPSink (Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource) { > return JPEGVideoRTPSink::createNew( envir(), rtpGroupsock ); > } This is correct. > When I use this ServerMediaSubsession and connect a client the call sequence I see is: > > LocalMJpegUnicastServerMediaSubsession::createNewStreamSource() > LocalMJpegUnicastServerMediaSubsession::createNewRTPSink() FYI, at this point, you should also be seeing: ~JPEGVideoRTPSink() ~StreamReplica() > LocalMJpegUnicastServerMediaSubsession::createNewStreamSource() > LocalMJpegUnicastServerMediaSubsession::createNewRTPSink() The reason for this is that the first "createNewStreamSource()"/"createNewRTPSink()" calls are to create 'dummy' objects that the RTSP server uses to get the stream's SDP description (for the RTSP 'DESCRIBE" command). These two objects are then deleted (thus the "FYI" above). Then, 'real' source and sink objects are created. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at svennergr.de Thu Oct 16 22:48:46 2014 From: live555 at svennergr.de (Sven Grossmann) Date: Fri, 17 Oct 2014 07:48:46 +0200 Subject: [Live-devel] RTSP stream of webm-file on windows machines Message-ID: <1d7ce2868f36dda3a8b9b7edfdc075f9@svennergr.de> ---- Ross Finlayson schrieb ---- > I should also note (because you were asking specifically about Windows) that I had no problem running the "LIVE555 Media Server" on Windows, and streaming either of those ".webm" files either locally (to VLC version 2.1.5 running on the same Windows computer), or remotely. > > > I did, however, have to allow "live555MediaServer.exe" to bypass Windows' firewall. (Windows prompted me about this.) You should make sure that you're doing this. > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com [2]/ Hey Ross, I think that's the main issue here. I tried this on my private machine and got a firewall prompt emmediatly. Whereas there were no prompt at the machine at work. However, I tried to stream a MPG file aswell and this worked fine. Strange. ---- Ross Finlayson schrieb ---- > I should also note (because you were asking specifically about Windows) that I had no problem running the "LIVE555 Media Server" on Windows, and streaming either of those ".webm" files either locally (to VLC version 2.1.5 running on the same Windows computer), or remotely. I did, however, have to allow "live555MediaServer.exe" to bypass Windows' firewall. (Windows prompted me about this.) You should make sure that you're doing this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ [1] Hey Ross, I think that's the main issue here. I tried this on my private machine and got a firewall prompt emmediatly. Whereas there were no prompt at the machine at work. However, I tried to stream a MPG file aswell and this worked fine. Strange. Links: ------ [1] http://www.live555.com/ [2] http://www.live555.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.ekholm at d-pointer.com Fri Oct 17 02:16:38 2014 From: jan.ekholm at d-pointer.com (Jan Ekholm) Date: Fri, 17 Oct 2014 12:16:38 +0300 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> Message-ID: <37B64C02-213F-4E17-AA6B-C041C0D2FA5A@d-pointer.com> Ok, I think I've found the issue. The culprit here is the StreamReplica class which is a FrameSource, but it is not a JPEG video source, i.e. it does not return True for: virtual Boolean isJPEGVideoSource(); This is what is checked in: Boolean JPEGVideoRTPSink::sourceIsCompatibleWithUs(MediaSource& source) { return source.isJPEGVideoSource(); } which is checked from: Boolean MediaSink::startPlaying(MediaSource& source, afterPlayingFunc* afterFunc, void* afterClientData) { // Make sure we're not already being played: if (fSource != NULL) { envir().setResultMsg("This sink is already being played"); return False; } // HERE // Make sure our source is compatible: if (!sourceIsCompatibleWithUs(source)) { envir().setResultMsg("MediaSink::startPlaying(): source is not compatible!"); return False; } ... To me it seems as if StreamReplica should forward all the methods below to the replicated source? // Test for specific types of source: virtual Boolean isFramedSource() const; virtual Boolean isRTPSource() const; virtual Boolean isMPEG1or2VideoStreamFramer() const; virtual Boolean isMPEG4VideoStreamFramer() const; virtual Boolean isH264VideoStreamFramer() const; virtual Boolean isH265VideoStreamFramer() const; virtual Boolean isDVVideoStreamFramer() const; virtual Boolean isJPEGVideoSource() const; virtual Boolean isAMRAudioSource() const; But if I redefine that methods it all crashes later in: unsigned JPEGVideoRTPSink::specialHeaderSize() const { // Our source is known to be a JPEGVideoSource JPEGVideoSource* source = (JPEGVideoSource*)fSource; if (source == NULL) return 0; // sanity check ... Here the source is a StreamReplicator and not a JPEGVideoSource, so the cast will be bogus. Would perhaps be better to use dynamic_cast<> here, then the sanity check would work. As the StreamReplica class is internal to StreamReplicator specialHeaderSize() can not check for it when casting and do special handling for that case. So, for MJPEG there are a few issues. -- Jan Ekholm jan.ekholm at d-pointer.com From jan.ekholm at d-pointer.com Fri Oct 17 02:16:54 2014 From: jan.ekholm at d-pointer.com (Jan Ekholm) Date: Fri, 17 Oct 2014 12:16:54 +0300 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> Message-ID: <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> On 17 okt 2014, at 04:34, Ross Finlayson wrote: >> I've use Live555 for some prototypes for a while now and it's working quite well so far. My use cases >> are to act as a cental video hub for a number of remote surveillance cameras as well as locally connected >> USB cameras and serve H264/MJPEG streams using unicast and multicast. Those scenarios more or >> less work ok. The code isn't too pretty but Live555 is quite hard to use. > > Yes, it's hard to use, but that's mainly because it's used to build complex systems. It's also intended for experienced systems programmers; not for the 'faint of heart' :-) Finally, everyone should remember that Live Networks, Inc. is not a charity, and I make no money by helping people with the software 'for free' on this mailing list; it's just something that I do as a public service. Indeed. You should make it easier to support you, perhaps with a sponsorship program where you can pay some predefined amounts as appreciation for support and the software. Make it easy to just click a few buttons. Invoices etc are much more work for a customer and is what scared me off last spring when I queried how I could pay for the help you'd given me. I still don't mind paying, but we in the rest of the world are not really accustomed to US software consulting prices, so at least I can not pay for weeks of work (that's what I get in a whole year). > >> Now I need to save the streams to disk too. There is the handy StreamReplicator class that should allow >> me to save the streams to disk as well as stream them to clients, but I've not really understood how to use >> it correctly. From what I've understood I need to create one StreamReplicator for the source stream and >> then replicator->createNewStreamReplica() for the streaming as well as the saving. Well, this does not work >> at all so I'm doing something wrong. >> >> The class that handles a local USB camera and unicasts MJPEG is basically: >> >> class LocalMJpegUnicastServerMediaSubsession : public OnDemandServerMediaSubsession { > > First, because you're streaming from live sources (rather than prerecorded files), make sure that your "LocalMJpegUnicastServerMediaSubsession" constructor sets the "reuseFirstSource" parameter - in the "OnDemandServerMediaSubsession" constructor - to True. It does set it to true. >> FramedSource* LocalMJpegUnicastServerMediaSubsession::createNewStreamSource (unsigned clientSessionID, unsigned& estBitRate) { >> // create and initialize a source for the camera. This is a JPEGVideoSource subclass that captures, encodes and delivers JPEG frames >> // it works fine as long as do not try to use StreamReplicator >> MJpegFramedSource *source = MJpegFramedSource::createNew( envir() ); >> source->initialize( m_cameraParameters ); >> >> m_replicator = StreamReplicator::createNew( envir(), source, False ); > > I would replace this line with: > if (m_replicator == NULL) { > m_replicator = StreamReplicator::createNew( envir(), source, False ); > startSavingStream(yourFileName); > } > and, of course, initialize "m_replicator" to NULL in your constructor. Ok. I've never been really sure if the source should be created in createNewStreamSource() along with the replicator or if it is better to create both in the constructor and in createNewStreamSource() just return replicator->createStreamReplica()? If I create the source in the constructor and reuse it there really is no difference, it still does not work. I do think the replicator does not work in a more complex situation like this. > >> When I use this ServerMediaSubsession and connect a client the call sequence I see is: >> >> LocalMJpegUnicastServerMediaSubsession::createNewStreamSource() >> LocalMJpegUnicastServerMediaSubsession::createNewRTPSink() > > FYI, at this point, you should also be seeing: > ~JPEGVideoRTPSink() > ~StreamReplica() Yes, I see JPEGVideoRTPSink being destroyed three times as createNewStreamSource() is called three times. First with a clientSessionID=0 and the other times with valid large ids. No idea why three times, perhaps VLC which acts as the client does something interesting. Trying with testRTSPClient I only see two calls. Perhaps VLC retries something as there is no data. The output from testRTSPClient is: ./testProgs/testRTSPClient rtsp://192.168.1.12:8554/camera0 Opening connection to 192.168.1.12, port 8554... ...remote connection opened Sending request: DESCRIBE rtsp://192.168.1.12:8554/camera0 RTSP/1.0 CSeq: 2 User-Agent: ./testProgs/testRTSPClient (LIVE555 Streaming Media v2014.10.07) Accept: application/sdp Received 562 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Fri, Oct 17 2014 07:48:44 GMT Content-Base: rtsp://192.168.1.12:8554/camera0/ Content-Type: application/sdp Content-Length: 396 v=0 o=- 1413532111476134 1 IN IP4 192.168.1.12 s=Local unicast MJPEG camera i=Camera t=0 0 a=tool:LIVE555 Streaming Media v2014.10.07 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * 192.168.1.12 a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:Local unicast MJPEG camera a=x-qt-text-inf:Camera m=video 0 RTP/AVP 26 c=IN IP4 0.0.0.0 b=AS:200 a=control:track1 [URL:"rtsp://192.168.1.12:8554/camera0/"]: Got a SDP description: v=0 o=- 1413532111476134 1 IN IP4 192.168.1.12 s=Local unicast MJPEG camera i=Camera t=0 0 a=tool:LIVE555 Streaming Media v2014.10.07 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * 192.168.1.12 a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:Local unicast MJPEG camera a=x-qt-text-inf:Camera m=video 0 RTP/AVP 26 c=IN IP4 0.0.0.0 b=AS:200 a=control:track1 [URL:"rtsp://192.168.1.12:8554/camera0/"]: Initiated the "video/JPEG" subsession (client ports 56224-56225) Sending request: SETUP rtsp://192.168.1.12:8554/camera0/track1 RTSP/1.0 CSeq: 3 User-Agent: ./testProgs/testRTSPClient (LIVE555 Streaming Media v2014.10.07) Transport: RTP/AVP;unicast;client_port=56224-56225 Received 214 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Fri, Oct 17 2014 07:48:44 GMT Transport: RTP/AVP;unicast;destination=192.168.1.12;source=192.168.1.12;client_port=56224-56225;server_port=6970-6971 Session: 476829A6;timeout=65 [URL:"rtsp://192.168.1.12:8554/camera0/"]: Set up the "video/JPEG" subsession (client ports 56224-56225) [URL:"rtsp://192.168.1.12:8554/camera0/"]: Created a data sink for the "video/JPEG" subsession Sending request: PLAY rtsp://192.168.1.12:8554/camera0/ RTSP/1.0 CSeq: 4 User-Agent: ./testProgs/testRTSPClient (LIVE555 Streaming Media v2014.10.07) Session: 476829A6 Range: npt=0.000- Received 187 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Fri, Oct 17 2014 07:48:44 GMT Range: npt=0.000- Session: 476829A6 RTP-Info: url=rtsp://192.168.1.12:8554/camera0/track1;seq=52977;rtptime=2830850619 [URL:"rtsp://192.168.1.12:8554/camera0/"]: Started playing session... ^C >> LocalMJpegUnicastServerMediaSubsession::createNewStreamSource() >> LocalMJpegUnicastServerMediaSubsession::createNewRTPSink() > > The reason for this is that the first "createNewStreamSource()"/"createNewRTPSink()" calls are to create 'dummy' objects that the RTSP server uses to get the stream's SDP description (for the RTSP 'DESCRIBE" command). These two objects are then deleted (thus the "FYI" above). Then, 'real' source and sink objects are created. Yes, that seems to be normal behavior. So far there doesn't seem to be any error in what I'm trying to do, but the stream simply is not playing. Is there really a startPlaying() being called for the replicated stream too? -- Jan Ekholm jan.ekholm at d-pointer.com From Alan.Martinovic at zenitel.com Fri Oct 17 02:30:23 2014 From: Alan.Martinovic at zenitel.com (Alan Martinovic) Date: Fri, 17 Oct 2014 09:30:23 +0000 Subject: [Live-devel] Mechanism of passing data from source to sink Message-ID: <916A03CCEB30DF44AD98D4CFDC7448D01D530937@nooslzsmx1.zenitelcss.com> Hi, I've read how the control flow mechanism works (http://www.live555.com/liveMedia/faq.html#control-flow) and I'm trying to get the idea of how it works in practice by following the Elphel example (http://www.live555.com/Elphel/). I've traced the actual payload to the fTo variable #ElphelJPEGDeviceSource.cpp 95-96 // Then, the JPEG payload: fFrameSize = fread(fTo, 1, fMaxSize, fFid); But when grepping through all the *Sink* and *Session* files, I found no traces of fTo. Plus, the fTo is protected. At first, I was thinking that when triggered, the JPEGVideoRTPSink was getting the raw data by accessing the FramedSource.fTo and then adding the RTP headers to that data (which represent raw video). By which method (variable?) do sinks and sources actually share the raw video data? DISCLAIMER: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Martinovic at zenitel.com Fri Oct 17 02:37:36 2014 From: Alan.Martinovic at zenitel.com (Alan Martinovic) Date: Fri, 17 Oct 2014 09:37:36 +0000 Subject: [Live-devel] Mechanism of passing data from source to sink Message-ID: <916A03CCEB30DF44AD98D4CFDC7448D01D53094D@nooslzsmx1.zenitelcss.com> Hi, I've read how the control flow mechanism works (http://www.live555.com/liveMedia/faq.html#control-flow) and I'm trying to get the idea of how it works in practice by following the Elphel example (http://www.live555.com/Elphel/). I've traced the actual payload to the fTo variable #ElphelJPEGDeviceSource.cpp 95-96 // Then, the JPEG payload: fFrameSize = fread(fTo, 1, fMaxSize, fFid); But when grepping through all the *Sink* and *Session* files, I found no traces of fTo. Plus, the fTo is protected. At first, I was thinking that when triggered, the JPEGVideoRTPSink was getting the raw data by accessing the FramedSource.fTo and then adding the RTP headers to that data (which represent raw video). By which method (variable?) do sinks and sources actually share the raw video data? DISCLAIMER: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Martinovic at zenitel.com Fri Oct 17 03:53:48 2014 From: Alan.Martinovic at zenitel.com (Alan Martinovic) Date: Fri, 17 Oct 2014 10:53:48 +0000 Subject: [Live-devel] Mechanism of passing data from source to sink In-Reply-To: <916A03CCEB30DF44AD98D4CFDC7448D01D53094D@nooslzsmx1.zenitelcss.com> References: <916A03CCEB30DF44AD98D4CFDC7448D01D53094D@nooslzsmx1.zenitelcss.com> Message-ID: <916A03CCEB30DF44AD98D4CFDC7448D01D530969@nooslzsmx1.zenitelcss.com> Sorry for double posting, was a mistake. From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Alan Martinovic Sent: Friday, October 17, 2014 11:38 AM To: live-devel at lists.live555.com Subject: [Live-devel] Mechanism of passing data from source to sink Hi, I've read how the control flow mechanism works (http://www.live555.com/liveMedia/faq.html#control-flow) and I'm trying to get the idea of how it works in practice by following the Elphel example (http://www.live555.com/Elphel/). I've traced the actual payload to the fTo variable #ElphelJPEGDeviceSource.cpp 95-96 // Then, the JPEG payload: fFrameSize = fread(fTo, 1, fMaxSize, fFid); But when grepping through all the *Sink* and *Session* files, I found no traces of fTo. Plus, the fTo is protected. At first, I was thinking that when triggered, the JPEGVideoRTPSink was getting the raw data by accessing the FramedSource.fTo and then adding the RTP headers to that data (which represent raw video). By which method (variable?) do sinks and sources actually share the raw video data? DISCLAIMER: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. DISCLAIMER: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Fri Oct 17 03:47:26 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Fri, 17 Oct 2014 12:47:26 +0200 Subject: [Live-devel] live555MediaServer segmentation violation when severals RTSP client access to the same stream. In-Reply-To: References: <3926_1413466214_543FC866_3926_411_1_1BE8971B6CFF3A4F97AF4011882AA255015658B2FD96@THSONEA01CMS01P.one.grp> Message-ID: <3959_1413542848_5440F3C0_3959_25_1_1BE8971B6CFF3A4F97AF4011882AA255015658B83893@THSONEA01CMS01P.one.grp> Hi Ross, On one server, before your modification, it was crashing more than once per hour. With this new version it seems ok. Many Thanks, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : vendredi 17 octobre 2014 01:17 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] live555MediaServer segmentation violation when severals RTSP client access to the same stream. Aha! You've run into a rare 'race condition'. Thanks for reporting this. I've just installed a new version (2014.10.16) of the "LIVE555 Streaming Media" software that should fix this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Martinovic at zenitel.com Fri Oct 17 06:44:41 2014 From: Alan.Martinovic at zenitel.com (Alan Martinovic) Date: Fri, 17 Oct 2014 13:44:41 +0000 Subject: [Live-devel] video/JPEG streaming Message-ID: <916A03CCEB30DF44AD98D4CFDC7448D01D5309B9@nooslzsmx1.zenitelcss.com> Hi Michael, do you have a sample file "test.mjpeg" that works with your example? DISCLAIMER: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 17 06:48:13 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Oct 2014 06:48:13 -0700 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> Message-ID: <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> > Yes, I see JPEGVideoRTPSink being destroyed three times as createNewStreamSource() is called three times. > First with a clientSessionID=0 and the other times with valid large ids. No idea why three times, perhaps VLC which > acts as the client does something interesting. Trying with testRTSPClient I only see two calls. Perhaps VLC retries > something as there is no data. Yes, VLC first requests regular RTP/RTCP-over-UDP streaming, but then - if it receives no data within a certain period of time - tries again, this time requesting RTP/RTCP-over-TCP streaming. > So far there doesn't seem to be any error in what I'm trying to do, but the stream simply is not playing. Is there > really a startPlaying() being called for the replicated stream too? Yes, there should be - it?s done in the ?OnDemandServerMediaSubsession? code, when the server handles the RTSP ?PLAY? command. Unfortunately, I can?t figure out why it?s not working for you. You?re going to have to work through the ?StreamReplica? code, checking that "StreamReplica::doGetNextFrame()? gets called, as it should. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 17 06:53:09 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Oct 2014 06:53:09 -0700 Subject: [Live-devel] Mechanism of passing data from source to sink In-Reply-To: <916A03CCEB30DF44AD98D4CFDC7448D01D530969@nooslzsmx1.zenitelcss.com> References: <916A03CCEB30DF44AD98D4CFDC7448D01D53094D@nooslzsmx1.zenitelcss.com> <916A03CCEB30DF44AD98D4CFDC7448D01D530969@nooslzsmx1.zenitelcss.com> Message-ID: <1AF16C77-79D1-46FB-AFB1-601F6ED7A686@live555.com> > By which method (variable?) do sinks and sources actually share the raw video data? To help understand this, I suggest taking a look at the ?DeviceSource? model code (in ?liveMedia/DeviceSource.cpp?). Note, in particular, the comments on lines 102-121. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 17 06:55:44 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Oct 2014 06:55:44 -0700 Subject: [Live-devel] video/JPEG streaming In-Reply-To: <916A03CCEB30DF44AD98D4CFDC7448D01D5309B9@nooslzsmx1.zenitelcss.com> References: <916A03CCEB30DF44AD98D4CFDC7448D01D5309B9@nooslzsmx1.zenitelcss.com> Message-ID: > do you have a sample file ?test.mjpeg? that works with your example? No. Note, BTW, that JPEG video streaming is strongly discouraged; see http://www.live555.com/liveMedia/faq.html#jpeg-streaming Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.ekholm at d-pointer.com Fri Oct 17 08:02:53 2014 From: jan.ekholm at d-pointer.com (Jan Ekholm) Date: Fri, 17 Oct 2014 18:02:53 +0300 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> Message-ID: On 17 okt 2014, at 16:48, Ross Finlayson wrote: >> Yes, I see JPEGVideoRTPSink being destroyed three times as createNewStreamSource() is called three times. >> First with a clientSessionID=0 and the other times with valid large ids. No idea why three times, perhaps VLC which >> acts as the client does something interesting. Trying with testRTSPClient I only see two calls. Perhaps VLC retries >> something as there is no data. > > Yes, VLC first requests regular RTP/RTCP-over-UDP streaming, but then - if it receives no data within a certain period of time - tries again, this time requesting RTP/RTCP-over-TCP streaming. That explains it, as there definitely was no data being sent. >> So far there doesn't seem to be any error in what I'm trying to do, but the stream simply is not playing. Is there >> really a startPlaying() being called for the replicated stream too? > > Yes, there should be - it?s done in the ?OnDemandServerMediaSubsession? code, when the server handles the RTSP ?PLAY? command. > > Unfortunately, I can?t figure out why it?s not working for you. You?re going to have to work through the ?StreamReplica? code, checking that "StreamReplica::doGetNextFrame()? gets called, as it should. I found the culprit, did that mail not come through? I had some hassles with non responding email servers, so perhaps it never was sent properly. Below I've copied the message. --------------- Ok, I think I've found the issue. The culprit here is the StreamReplica class which is a FrameSource, but it is not a JPEG video source, i.e. it does not return True for: virtual Boolean isJPEGVideoSource(); This is what is checked in: Boolean JPEGVideoRTPSink::sourceIsCompatibleWithUs(MediaSource& source) { return source.isJPEGVideoSource(); } which is checked from: Boolean MediaSink::startPlaying(MediaSource& source, afterPlayingFunc* afterFunc, void* afterClientData) { // Make sure we're not already being played: if (fSource != NULL) { envir().setResultMsg("This sink is already being played"); return False; } // Make sure our source is compatible: if (!sourceIsCompatibleWithUs(source)) { envir().setResultMsg("MediaSink::startPlaying(): source is not compatible!"); return False; } ... To me it seems as if StreamReplica perhaps should forward all the methods below to the replicated source? // Test for specific types of source: virtual Boolean isFramedSource() const; virtual Boolean isRTPSource() const; virtual Boolean isMPEG1or2VideoStreamFramer() const; virtual Boolean isMPEG4VideoStreamFramer() const; virtual Boolean isH264VideoStreamFramer() const; virtual Boolean isH265VideoStreamFramer() const; virtual Boolean isDVVideoStreamFramer() const; virtual Boolean isJPEGVideoSource() const; virtual Boolean isAMRAudioSource() const; But if I redefine that methods it all crashes later in: unsigned JPEGVideoRTPSink::specialHeaderSize() const { // Our source is known to be a JPEGVideoSource JPEGVideoSource* source = (JPEGVideoSource*)fSource; if (source == NULL) return 0; // sanity check ... Here fSource is a StreamReplicator and not a JPEGVideoSource, so the cast will be bogus. Would perhaps be better to use dynamic_cast<> here, then the sanity check would work. As the StreamReplica class is internal to StreamReplicator specialHeaderSize() can not check for it when casting and do special handling for that case. So, for MJPEG there are a few issues. -- Jan Ekholm jan.ekholm at d-pointer.com From finlayson at live555.com Fri Oct 17 11:48:40 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Oct 2014 11:48:40 -0700 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> Message-ID: > Ok, I think I've found the issue. The culprit here is the StreamReplica class which is > a FrameSource, but it is not a JPEG video source, i.e. it does not return True for: > > virtual Boolean isJPEGVideoSource(); OK, so yes - that?s the problem. The data that you feed to ?JPEGVideoRTPSink? MUST BE a subclass of ?JPEGVideoSource?. It can?t just redefine ?isJPEGVideoSource()? to return True (or just do some type casting hack). The reason for this is that ?JPEGVideoRTPSink? needs to know the ?type?, ?qFactor?, ?width?, and ?height? of the frames that it receives (so it can pack these values into the appropriate fields of the outgoing RTP packet). So, you?ll need to define your own subclass of ?JPEGVideoSource? - e.g., called ?ReplicaJPEGVideoSource?. This must take as input another ?FramedSource? object (a ?StreamReplica?, in your case), and must implement the following (pure) virtual functions: ?doGetNextFrame()?, ?type()?, ?qFactor()?, ?width()?, ?height()?. Implementing ?doGetNextFrame()? is easy; just call ?getNextFrame()? on the input (?StreamReplica?) object. To implement the other virtual functions (?type()?, ?qFactor()?, ?width()?, ?height()?), you?ll need to have these four parameters added to each frame of data somehow. I.e., you?ll need to modify your original JPEG video source object - i.e., the one that you feed into the ?StreamReplicator? - to add a header at the start (or at the end) that contains these four values. These four values will presumably also be useful to the other replica - the one that you feed into a ?FileSink?. Your ?ReplicaJPEGVideoSource? class should also make sure that its destructor calls ?Medium::close()? on the input source (a ?StreamReplica?), and should also reimplement the ?doStopGettingFrames()? virtual function to call ?stopGettingFrames()? on the input source. (Note the implementation of ?FramedFilter?, which does the same thing. In fact, you *might* try having your ?ReplicaJPEGVideoSource? class inherit from both ?JPEGVideoSource? and ?FramedFilter?, but I?m not sure whether or not that will work. (I?m wary of multiple inheritance in C++, and haven?t used it at all in any of the LIVE555 code so far.)) Finally, you?ll need to modify your implementation of ?createNewStreamSource()? to not just return a new ?StreamReplica?, but instead to feed this ?StreamReplica? into a new ?ReplicaJPEGVideoSource? object, and then return a pointer to this new ?ReplicaJPEGVideoSource? object. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 17 15:09:45 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 17 Oct 2014 15:09:45 -0700 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> Message-ID: > In fact, you *might* try having your ?ReplicaJPEGVideoSource? class inherit from both ?JPEGVideoSource? and ?FramedFilter?, but I?m not sure whether or not that will work. (I?m wary of multiple inheritance in C++, and haven?t used it at all in any of the LIVE555 code so far.)) FYI, I looked into this, and unfortunately that hack (having your ?ReplicaJPEGVideoSource? class inherit from both ?JPEGVideoSource? and ?FramedFilter?) won?t work, because of the ?Diamond Problem?. Because both ?JPEGVideoSource? and ?FramedFilter? inherit (non-virtually) from ?FramedSource?, you can?t multiply-inherit from ?JPEGVideoSource? and ?FramedFilter?, otherwise you?d end up with two copies of ?FramedSource?, which would probably be bad. So, unfortunately you?re going to have to duplicate some of the existing functionality of ?FramedFilter? in your new ?ReplicaJPEGVideoSource? class. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.ekholm at d-pointer.com Sat Oct 18 02:12:40 2014 From: jan.ekholm at d-pointer.com (Jan Ekholm) Date: Sat, 18 Oct 2014 12:12:40 +0300 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> Message-ID: <69BD774D-98EC-4F48-BEE9-4CE3186DB2AF@d-pointer.com> On 18 okt 2014, at 01:09, Ross Finlayson wrote: >> In fact, you *might* try having your ?ReplicaJPEGVideoSource? class inherit from both ?JPEGVideoSource? and ?FramedFilter?, but I?m not sure whether or not that will work. (I?m wary of multiple inheritance in C++, and haven?t used it at all in any of the LIVE555 code so far.)) > > FYI, I looked into this, and unfortunately that hack (having your ?ReplicaJPEGVideoSource? class inherit from both ?JPEGVideoSource? and ?FramedFilter?) won?t work, because of the ?Diamond Problem?. Because both ?JPEGVideoSource? and ?FramedFilter? inherit (non-virtually) from ?FramedSource?, you can?t multiply-inherit from ?JPEGVideoSource? and ?FramedFilter?, otherwise you?d end up with two copies of ?FramedSource?, which would probably be bad. > > So, unfortunately you?re going to have to duplicate some of the existing functionality of ?FramedFilter? in your new ?ReplicaJPEGVideoSource? class. I tend to avoid multiple inheritance too, unless one class is a totally abstract interface base class. I ran into the same issue with replicating H264 too, as the StreamReplica does not fulfill isH264VideoStreamFramer(). I'll take a shot at making a proxy class for at least H264 and perhaps JPEG too. I have not found a working way to actually get the JPEG video replayed from disk, so I may end up having to discard to idea of saving JPEG video to disk for later streaming. Yes, I know JPEG video is far from ideal, but in this case it's a question of a demo that would prerecord some minutes of live camera footage and then replay said material over and over again. H264 tends to drop frames and have glitches even when run over localhost while JPEG video looks best. -- Jan Ekholm jan.ekholm at d-pointer.com From jan.ekholm at d-pointer.com Sat Oct 18 11:49:25 2014 From: jan.ekholm at d-pointer.com (Jan Ekholm) Date: Sat, 18 Oct 2014 21:49:25 +0300 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> Message-ID: <54DADFB2-A931-426D-BC7A-350B907D3E44@d-pointer.com> On 17 okt 2014, at 21:48, Ross Finlayson wrote: > The data that you feed to ?JPEGVideoRTPSink? MUST BE a subclass of ?JPEGVideoSource?. It can?t just redefine ?isJPEGVideoSource()? to return True (or just do some type casting hack). The reason for this is that ?JPEGVideoRTPSink? needs to know the ?type?, ?qFactor?, ?width?, and ?height? of the frames that it receives (so it can pack these values into the appropriate fields of the outgoing RTP packet). > > So, you?ll need to define your own subclass of ?JPEGVideoSource? - e.g., called ?ReplicaJPEGVideoSource?. This must take as input another ?FramedSource? object (a ?StreamReplica?, in your case), and must implement the following (pure) virtual functions: ?doGetNextFrame()?, ?type()?, ?qFactor()?, ?width()?, ?height()?. > > Implementing ?doGetNextFrame()? is easy; just call ?getNextFrame()? on the input (?StreamReplica?) object. > > To implement the other virtual functions (?type()?, ?qFactor()?, ?width()?, ?height()?), you?ll need to have these four parameters added to each frame of data somehow. I.e., you?ll need to modify your original JPEG video source object - i.e., the one that you feed into the ?StreamReplicator? - to add a header at the start (or at the end) that contains these four values. > > These four values will presumably also be useful to the other replica - the one that you feed into a ?FileSink?. > > Your ?ReplicaJPEGVideoSource? class should also make sure that its destructor calls ?Medium::close()? on the input source (a ?StreamReplica?), and should also reimplement the ?doStopGettingFrames()? virtual function to call ?stopGettingFrames()? on the input source. (Note the implementation of ?FramedFilter?, which does the same thing. In fact, you *might* try having your ?ReplicaJPEGVideoSource? class inherit from both ?JPEGVideoSource? and ?FramedFilter?, but I?m not sure whether or not that will work. (I?m wary of multiple inheritance in C++, and haven?t used it at all in any of the LIVE555 code so far.)) > > Finally, you?ll need to modify your implementation of ?createNewStreamSource()? to not just return a new ?StreamReplica?, but instead to feed this ?StreamReplica? into a new ?ReplicaJPEGVideoSource? object, and then return a pointer to this new ?ReplicaJPEGVideoSource? object. That approach could work, but there are some obstacles along the way. First let me paste the class I use, see discussion after the class: class ReplicaJPEGVideoSource : public JPEGVideoSource { public: ReplicaJPEGVideoSource (FramedSource * replica, MJpegFramedSource * source, UsageEnvironment& env) : JPEGVideoSource(env), m_replica(replica), m_source(source) { } virtual ~ReplicaJPEGVideoSource () { Medium::close( m_replica ); } virtual u_int8_t type () { return m_source->type(); } virtual u_int8_t qFactor () { return m_source->qFactor(); } virtual u_int8_t width () { return m_source->width(); } virtual u_int8_t height () { return m_source->height(); } virtual void doGetNextFrame () { //m_source->doGetNextFrame(); //m_replica->getNextFrame( fTo, fMaxSize, fAfterGettingFunc, fAfterGettingClientData, fOnCloseFunc, fOnCloseClientData ); } virtual void doStopGettingFrames() { // TODO: is this needed? JPEGVideoSource::doStopGettingFrames(); // TODO: should this be the source or the replica? m_source->stopGettingFrames(); } protected: FramedSource * m_replica; MJpegFramedSource * m_source; }; The problems here arise in doGetFrame(). You said to just getNextFrame() on the replica, ie. a FramedSource created based on this code: FramedSource* LocalMJpegUnicastServerMediaSubsession::createNewStreamSource (unsigned clientSessionID, unsigned& estBitRate) { // create and initialize a source for the camera MJpegFramedSource *source = MJpegFramedSource::createNew( envir() ); if ( ! source->initialize( m_cameraParameters ) ) { return 0; } if ( m_replicator == 0 ) { m_replicator = StreamReplicator::createNew( envir(), source, False ); } return new ReplicaJPEGVideoSource( m_replicator->createStreamReplica(), source, envir() ); } The replica is wrapped in the above class, as per instructions. However, doGetNextFrame() can not simply call getNextFrame() as that requires a set of parameters that are not accessible: m_replica->getNextFrame( fTo, fMaxSize, fAfterGettingFunc, fAfterGettingClientData, fOnCloseFunc, fOnCloseClientData ); The fAfterGettingClientData and fOnCloseClientData are private and not accessible to my wrapper. I can also not override getNextFrame() in my wrapper and save said data as that method is not virtual. Instead if I assume you made a typo and meant: m_replica->doGetNextFrame(); This will crash when my MJpegFramedSource delivers the frame by copying raw data to fTo, as it has not been set. It seems to be NULL or some random value. So apparently this extra proxying probably makes FramedSource::getNextFrame() get called for the wrong FramedSource and the data is saved in the wrong instance. As a test I did make the Live555 code work without any extra proxying layer, but the bad typecasts in the original code make it quite ugly. This was doable by lifting out StreamReplica and have it implement the suitable isXYZ() methods and go through all the places with hardcoded C style casts and fix them to use dynamic_cast<> and check for a StreamReplica. This does then not work for H264 streams, as isFramedSource() is a private member of FramedSource. Why has it been inherited as private? Anyway, currently stream replicating does not work at all and it does not seem to be easy to do. The StreamReplicator class works in trivial examples but breaks in real world code. -- Jan Ekholm jan.ekholm at d-pointer.com From kingaceck at 163.com Sat Oct 18 09:38:58 2014 From: kingaceck at 163.com (kingaceck) Date: Sun, 19 Oct 2014 00:38:58 +0800 Subject: [Live-devel] rtp over tcp Message-ID: <2014101900385712875332@163.com> -What OS are you running (for both your client (VLC) and server)? A:The server OS is centos6.5_x64,the client OS is WIN7 - Are you using the latest version of the "LIVE555 Streaming Media" code (the only version that we support) for your server? A:yes.The version of the "LIVE555 Streaming Media" is v2014.10.07 .The VLC version is 2.1.5 . - Is your client running the latest version of VLC (2.1.5)? A:yes.The VLC version is 2.1.5 . - What happens when you run "openRTSP -t" (again, using the latest version of the "LIVE555 Streaming Media" code) instead of VLC? A.At the first minutes the command window print some data .Then there is no data printed and the no any information shows.It very like VLC's state. 1)When I use centos's default value of net.core.rmem_max /net.core.wmem_max/net.core.wmem_default,the "LIVE555 Streaming Media" shows some information below and then openRTSP can't receive any data. sendDataOverTCP: resending 970 byte send (blocking) sendDataOverTCP: resending 300 byte send (blocking) ...... then "sendResult <0" and excute "removeStreamSocket(socketNum, 0xFF)" sendRTPorRTCPPacketOverTCP: failed! (errno 11) 2)When I setting the net.core.rmem_max /net.core.wmem_max/net.core.wmem_default all to 90000 in the server,the wireshark show the "TCP Window Full" at the server and "TCP ZeroWindow " at the clien before the client can't receiving data().After this information the VLC shows "no data received in 10s, eof ?" and then close the connection. The above phenomenon is in the WAN, the VLC and openRTSP can receive data only minutes. If all server and client in the LAN the VLC and openRTSP can receive data near 1 houre.But at last also cannot receive any data . >> When I transport rtp packets over tcp using live555 , I get many logs like below after playing many minutes. >> sendRTPorRTCPPacketOverTCP: failed! (errno 32) >> sendRTPorRTCPPacketOverTCP: failed! (errno 32) >> ... >> >> or >> >> sendRTPorRTCPPacketOverTCP: failed! (errno 9) >> sendRTPorRTCPPacketOverTCP: failed! (errno 9) >> ... >> >> then the vlc client can't receive any rtp packets. >What OS are you running (for both your client (VLC) and server)? > Are you using the latest version of the "LIVE555 Streaming Media" code (the only version that we support) for your server? > Is your client running the latest version of VLC (2.1.5)? > What happens when you run "openRTSP -t" (again, using the latest version of the "LIVE555 Streaming Media" code) instead of VLC? kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Oct 18 15:15:44 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 18 Oct 2014 15:15:44 -0700 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: <54DADFB2-A931-426D-BC7A-350B907D3E44@d-pointer.com> References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> <54DADFB2-A931-426D-BC7A-350B907D3E44@d-pointer.com> Message-ID: > The replica is wrapped in the above class, as per instructions. However, doGetNextFrame() can not simply call > getNextFrame() as that requires a set of parameters that are not accessible: > > m_replica->getNextFrame( fTo, fMaxSize, fAfterGettingFunc, fAfterGettingClientData, fOnCloseFunc, fOnCloseClientData ); > > The fAfterGettingClientData and fOnCloseClientData are private and not accessible to my wrapper. I can also not override getNextFrame() > in my wrapper and save said data as that method is not virtual. Instead if I assume you made a typo and meant: > > m_replica->doGetNextFrame(); No, I meant ?getNextFrame()? - i.e., the regular call that an object makes to get data from an upstream ?FramedSource?. You need to provide your own ?after getting? and ?on close? functions and data. There are numerous examples of this in the code. > Anyway, currently stream replicating does not work at all and it does not seem to be easy to do. The StreamReplicator class works in > trivial examples but breaks in real world code. No, it works just fine. It just needs to be used properly. In any case, I?ve pretty much used up all the free help I can give you on your project right now. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Oct 18 19:52:59 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 18 Oct 2014 19:52:59 -0700 Subject: [Live-devel] rtp over tcp In-Reply-To: <2014101900385712875332@163.com> References: <2014101900385712875332@163.com> Message-ID: > 1)When I use centos's default value of net.core.rmem_max /net.core.wmem_max/net.core.wmem_default,the "LIVE555 Streaming Media" shows some information below and then openRTSP can't receive any data. > sendDataOverTCP: resending 970 byte send (blocking) > sendDataOverTCP: resending 300 byte send (blocking) > ...... > then "sendResult <0" and excute "removeStreamSocket(socketNum, 0xFF)" > sendRTPorRTCPPacketOverTCP: failed! (errno 11) > > 2)When I setting the net.core.rmem_max /net.core.wmem_max/net.core.wmem_default all to 90000 in the server,the wireshark show the "TCP Window Full" at the server and This makes it clear that your problem is that the bitrate of your stream is exceeding the capacity of your network. Your ONLY solution to this is to either use a slower stream, or get a faster network. (And you should not be streaming over TCP (unless you have a firewall - between the server and client - that blocks UDP packets; streaming over TCP just makes the situation worse.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.ekholm at d-pointer.com Sun Oct 19 02:12:36 2014 From: jan.ekholm at d-pointer.com (Jan Ekholm) Date: Sun, 19 Oct 2014 12:12:36 +0300 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> <54DADFB2-A931-426D-BC7A-350B907D3E44@d-pointer.com> Message-ID: <34CB058E-B944-4F44-AD70-6615BFCA7C7A@d-pointer.com> On 19 okt 2014, at 01:15, Ross Finlayson wrote: >> The replica is wrapped in the above class, as per instructions. However, doGetNextFrame() can not simply call >> getNextFrame() as that requires a set of parameters that are not accessible: >> >> m_replica->getNextFrame( fTo, fMaxSize, fAfterGettingFunc, fAfterGettingClientData, fOnCloseFunc, fOnCloseClientData ); >> >> The fAfterGettingClientData and fOnCloseClientData are private and not accessible to my wrapper. I can also not override getNextFrame() >> in my wrapper and save said data as that method is not virtual. Instead if I assume you made a typo and meant: >> >> m_replica->doGetNextFrame(); > > No, I meant ?getNextFrame()? - i.e., the regular call that an object makes to get data from an upstream ?FramedSource?. You need to provide your own ?after getting? and ?on close? functions and data. There are numerous examples of this in the code. Yes, there are a lot of uses in the code, but none work like a proxy to a proxy. I have absolutely no idea what my class is supposed to do in this case. getNextFrame() is a central method and used in so many different ways across the entire library. > >> Anyway, currently stream replicating does not work at all and it does not seem to be easy to do. The StreamReplicator class works in >> trivial examples but breaks in real world code. > > No, it works just fine. It just needs to be used properly. Well, it's escalated quickly from "just use replicator->createStreamReplica()" to creating new components with intricate knowledge of the internal workings of Live555. > In any case, I?ve pretty much used up all the free help I can give you on your project right now. Understood. I thank you for all your help. -- Jan Ekholm jan.ekholm at d-pointer.com From finlayson at live555.com Sun Oct 19 12:09:50 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 19 Oct 2014 12:09:50 -0700 Subject: [Live-devel] Proper use of StreamReplicator In-Reply-To: <34CB058E-B944-4F44-AD70-6615BFCA7C7A@d-pointer.com> References: <06449FF0-BBE3-4ADA-BEA1-F15670AD4551@d-pointer.com> <4F063D59-F0BC-42A5-90B1-AFEF3B2F9CB1@live555.com> <2560025F-6AEC-4955-974C-7E962CB3B891@d-pointer.com> <104F5298-1B26-41F8-843C-1F23F4DC881A@live555.com> <54DADFB2-A931-426D-BC7A-350B907D3E44@d-pointer.com> <34CB058E-B944-4F44-AD70-6615BFCA7C7A@d-pointer.com> Message-ID: <1B0DBBCB-E690-4B1A-B5E9-49DD120F9C06@live555.com> >>> Anyway, currently stream replicating does not work at all and it does not seem to be easy to do. The StreamReplicator class works in >>> trivial examples but breaks in real world code. >> >> No, it works just fine. It just needs to be used properly. > > Well, it's escalated quickly from "just use replicator->createStreamReplica()" to creating new components with intricate > knowledge of the internal workings of Live555. Unfortunately the problem in this case was that although ?StreamReplicator? works well for replicating ?frames? (opaque chunks of data), your application (as we eventually discovered) is a bit more complex, because you need to replicate not just ?frames?, but ?frames-with-extra-parameters?. (The ?extra parameters? are needed to construct a ?JPEGVideoSource? or a ?H264VideoStreamFramer? object, both of which you?ll need in order to transmit MJPEG or H.264 video (respectively), because of the special nature of those video formats.) That?s what makes things more complex in your case. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imcs at telcoware.com Mon Oct 20 03:57:32 2014 From: imcs at telcoware.com (=?utf-8?B?7J6E7LCo7ISt?=) Date: Mon, 20 Oct 2014 19:57:32 +0900 Subject: [Live-devel] Problem MJEG stream with proxyserver Message-ID: <2.7ea449755871f0a0f51d@telcoware.com> An HTML attachment was scrubbed... URL: From live555 at svennergr.de Mon Oct 20 05:39:09 2014 From: live555 at svennergr.de (Sven Grossmann) Date: Mon, 20 Oct 2014 14:39:09 +0200 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: <1d7ce2868f36dda3a8b9b7edfdc075f9@svennergr.de> References: <1d7ce2868f36dda3a8b9b7edfdc075f9@svennergr.de> Message-ID: <6c58712d59a3401f95905ab7a1bc000e@svennergr.de> Am 2014-10-17 07:48, schrieb Sven Grossmann: > ---- Ross Finlayson schrieb ---- > >> I should also note (because you were asking specifically about > Windows) that I had no problem running the "LIVE555 Media Server" on > Windows, and streaming either of those ".webm" files either locally > (to VLC version 2.1.5 running on the same Windows computer), or > remotely. > > > > > > I did, however, have to allow "live555MediaServer.exe" to bypass > Windows' firewall. (Windows prompted me about this.) You should make > sure that you're doing this. > > > > Ross Finlayson > > Live Networks, Inc. > > http://www.live555.com [2]/ > > Hey Ross, > > I think that's the main issue here. I tried this on my private machine > and got a firewall prompt emmediatly. Whereas there were no prompt at > the machine at work. > > However, I tried to stream a MPG file aswell and this worked fine. > > Strange. > > ---- Ross Finlayson schrieb ---- > >> I should also note (because you were asking specifically about >> Windows) that I had no problem running the "LIVE555 Media Server" on >> Windows, and streaming either of those ".webm" files either locally >> (to VLC version 2.1.5 running on the same Windows computer), or >> remotely. I did, however, have to allow "live555MediaServer.exe" to >> bypass Windows' firewall. (Windows prompted me about this.) You >> should make sure that you're doing this. Ross Finlayson Live >> Networks, Inc. http://www.live555.com/ [1] > > Hey Ross, > > I think that's the main issue here. I tried this on my private machine > and got a firewall prompt emmediatly. Whereas there were no prompt at > the machine at work. > > However, I tried to stream a MPG file aswell and this worked fine. > > Strange. > > > > Links: > ------ > [1] http://www.live555.com/ > [2] http://www.live555.com > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel Hey Ross, the main issue was not a firewall problem. After upgrading VLC, I could view webm streamed files. BUT I still have a problem with 1080p webmfiles. These can not be streamed with the live555MediaServer and the testMKVStreamer. I uploaded both files, a working 480p file and a not working 1080p file to my server: https://cloud.svennergr.de/public.php?service=files&t=84ac60745a2662f7da7dd52a3a72cce2 (please don't worry about the SSL message, it's a self signed cert) Can you have a try streaming these files? Thanks, Sven Gro?mann From finlayson at live555.com Mon Oct 20 07:38:08 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Oct 2014 07:38:08 -0700 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: <6c58712d59a3401f95905ab7a1bc000e@svennergr.de> References: <1d7ce2868f36dda3a8b9b7edfdc075f9@svennergr.de> <6c58712d59a3401f95905ab7a1bc000e@svennergr.de> Message-ID: <5FBC636F-5C5C-4D16-91E0-ED29DEC6DEE7@live555.com> > BUT I still have a problem with 1080p webmfiles. These can not be streamed with the live555MediaServer and the testMKVStreamer. > I uploaded both files, a working 480p file and a not working 1080p file to my server: > https://cloud.svennergr.de/public.php?service=files&t=84ac60745a2662f7da7dd52a3a72cce2 > (please don't worry about the SSL message, it's a self signed cert) > > Can you have a try streaming these files? Sorry, but I couldn?t unpack your file. Please put online *only* the file that doesn?t work for you (I don?t care about files that work OK), and DO NOT ?zip? the file. (You shouldn?t ?zip? movie files, because they?re already compressed.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 20 07:43:29 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Oct 2014 07:43:29 -0700 Subject: [Live-devel] Problem MJEG stream with proxyserver In-Reply-To: <2.7ea449755871f0a0f51d@telcoware.com> References: <2.7ea449755871f0a0f51d@telcoware.com> Message-ID: <42329F26-C907-4454-9255-3CC2765EDF95@live555.com> > When I test h.264 via live555ProxyServer, It's works, but MJEG stream is broken(https://dl.dropboxusercontent.com/u/4188226/mjpeg_broken.png ). > > RTSP Client is VLC and back-end RTSP Server is IP-Camera. > > I am using lastest version. Including the latest version of VLC: 2.1.5 ? > please help me. > Sorry, but VLC is not our software. You should use our ?openRTSP? client application for your initial testing: http://live555 .com/openRTSP/ Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From live555 at svennergr.de Mon Oct 20 11:34:25 2014 From: live555 at svennergr.de (Sven Grossmann) Date: Mon, 20 Oct 2014 20:34:25 +0200 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: <5FBC636F-5C5C-4D16-91E0-ED29DEC6DEE7@live555.com> References: <1d7ce2868f36dda3a8b9b7edfdc075f9@svennergr.de> <6c58712d59a3401f95905ab7a1bc000e@svennergr.de> <5FBC636F-5C5C-4D16-91E0-ED29DEC6DEE7@live555.com> Message-ID: <401aefb780fd6c1598cfb61aed0067ca@svennergr.de> Am 2014-10-20 16:38, schrieb Ross Finlayson: >> BUT I still have a problem with 1080p webmfiles. These can not be >> streamed with the live555MediaServer and the testMKVStreamer. >> I uploaded both files, a working 480p file and a not working 1080p >> file to my server: >> > https://cloud.svennergr.de/public.php?service=files&t=84ac60745a2662f7da7dd52a3a72cce2 >> [1] >> (please don't worry about the SSL message, it's a self signed cert) >> >> Can you have a try streaming these files? > > Sorry, but I couldn?t unpack your file. Please put online *only* the > file that doesn?t work for you (I don?t care about files that work > OK), and DO NOT ?zip? the file. (You shouldn?t ?zip? movie > files, because they?re already compressed.) > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ [2] > > > Links: > ------ > [1] > https://cloud.svennergr.de/public.php?service=files&t=84ac60745a2662f7da7dd52a3a72cce2 > [2] http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel The not working file is available on: https://cloud.svennergr.de/public.php?service=files&t=3dba2a7de6025f9a367508791f1d9792 Thanks Ross. From finlayson at live555.com Mon Oct 20 13:47:12 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Oct 2014 13:47:12 -0700 Subject: [Live-devel] RTSP stream of webm-file on windows machines In-Reply-To: <401aefb780fd6c1598cfb61aed0067ca@svennergr.de> References: <1d7ce2868f36dda3a8b9b7edfdc075f9@svennergr.de> <6c58712d59a3401f95905ab7a1bc000e@svennergr.de> <5FBC636F-5C5C-4D16-91E0-ED29DEC6DEE7@live555.com> <401aefb780fd6c1598cfb61aed0067ca@svennergr.de> Message-ID: <8461A8D5-6971-4F5A-8561-6B7A78345090@live555.com> > The not working file is available on: https://cloud.svennergr.de/public.php?service=files&t=3dba2a7de6025f9a367508791f1d9792 The problem with this file is that its VP8 video configuration string was extremely large, and was hitting the RTSP server?s buffer limit. I?ve now installed a new version (2014.10.20) of the ?LIVE555 Streaming Media? software that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingaceck at 163.com Mon Oct 20 08:06:00 2014 From: kingaceck at 163.com (kingaceck) Date: Mon, 20 Oct 2014 23:06:00 +0800 Subject: [Live-devel] use same UDP port to send all data? Message-ID: <2014102023055834357818@163.com> I have a firewall - between the server and client .The firewall only can open a few port.So the server must use the same UDP port. I want to modify the "LIVE555 Streaming Media" source code like below.I do not know whether it is correct to do it in this way,please help me. all modification in OnDemandServerMediaSubsession::getStreamParameters() like below: 1)To allow reuse of socket numbers modify line 140:NoReuse dummy(envir()); to //NoReuse dummy(envir()); 2)To allow rtp and rtcp use the same port modify line 157:serverRTCPPort = ++serverPortNum; to serverRTCPPort = serverPortNum;(remove the ++ operation) I must use UDP to transport the data and must use a few port in all streams. I do not know whether it is correct to do it in this way,please help me.Thank you very much. kingaceck -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 20 16:10:48 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Oct 2014 16:10:48 -0700 Subject: [Live-devel] use same UDP port to send all data? In-Reply-To: <2014102023055834357818@163.com> References: <2014102023055834357818@163.com> Message-ID: <5D25CC7A-BE47-4A84-8E44-C06FDBB56EC3@live555.com> > I want to modify the "LIVE555 Streaming Media" source code Sorry, but once you've modified the supplied code, you can?t expect any support on this mailing list. > 2)To allow rtp and rtcp use the same port This has been supported (as an option) in the ?LIVE555 Streaming Media? code for more than 6 months now (without requiring any modification to the supplied code). See: http://lists.live555.com/pipermail/live-devel/2014-March/018179.html Ross. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imcs at telcoware.com Mon Oct 20 19:25:40 2014 From: imcs at telcoware.com (=?ks_c_5601-1987?B?wNPC97y3?=) Date: Tue, 21 Oct 2014 11:25:40 +0900 Subject: [Live-devel] Problem MJEG stream with proxyserver Message-ID: <000001cfecd7$42f267a0$c8d736e0$@telcoware.com> Hi. I tested openrtsp, but result is same. Jpg image is broken. Image file is created by ?-m? option of openrtsp. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 20 20:33:52 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Oct 2014 20:33:52 -0700 Subject: [Live-devel] Problem MJEG stream with proxyserver In-Reply-To: <000001cfecd7$42f267a0$c8d736e0$@telcoware.com> References: <000001cfecd7$42f267a0$c8d736e0$@telcoware.com> Message-ID: > I tested openrtsp, but result is same. Jpg image is broken. Congratulations! You?ve just discovered why MJPEG streaming - especially with very large frames - is a terrible idea. As I note in the FAQ: "You should be aware, though, that JPEG is a very poor codec for video streaming, because (unlike MPEG, H.264 or H.265 video) there is no inter-frame compression. Every video frame is a 'key' frame, and is sent in its entirety. Also, each frame is typically large (and so takes up many network packets). If any of these network packets gets lost, then the whole frame must be discarded. JPEG video streaming is strongly discouraged, and should be considered (if at all) only for high-bitrate local-area networks with very low packet loss.? What you?re seeing is packet loss. Because you have doubled the number of network interfaces in your system (in addition to the transmitter?s and the receiver?s interface, you now have the input and output interfaces of the proxy) you have at least doubled the packet loss rate, which *vastly* decreases the likelihood that a complete JPEG frame will be passed end-to-end. Your only real solution is to stop trying to stream MJPEG. Instead, transcode to H.264, and stream that. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imcs at telcoware.com Mon Oct 20 23:32:19 2014 From: imcs at telcoware.com (=?ks_c_5601-1987?B?wNPC97y3?=) Date: Tue, 21 Oct 2014 15:32:19 +0900 Subject: [Live-devel] Problem MJEG stream with proxyserver Message-ID: <000101cfecf8$c3ca3fd0$4b5ebf70$@telcoware.com> Hi. Thank you for reply. I found that fFrameSize is 1444 in PresentationTimeSubsessionNormalizer::afterGettingFrame (ProxyServerMediaSession.cpp). This value occurred fOutBuf->wouldOverflow because fMax of fOutFuf is 1448( rtp header(12) + 1444 > fMax(1448)). So I changed fMax value by calling setPacketSizes(1000, 1456) in MultiFramedRTPSink constructor. It is works fine. But I don?t know how to correct fix code in my case. Would you help me? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 21 01:16:24 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 21 Oct 2014 01:16:24 -0700 Subject: [Live-devel] Problem MJEG stream with proxyserver In-Reply-To: <000101cfecf8$c3ca3fd0$4b5ebf70$@telcoware.com> References: <000101cfecf8$c3ca3fd0$4b5ebf70$@telcoware.com> Message-ID: <20853F30-AAD0-4ADD-B54B-B7C346FC43D0@live555.com> Aha! Yes, you found the problem (which was different from what I had originally thought): Your input JPEG/RTP packets were unusually large (1456 bytes, plus IP, UDP headers). Because of the special way that we proxy JPEG/RTP packets, this turned out to be a problem for us. I?ve now installed a new version (2014.10.21) of the ?LIVE555 Streaming Media? code that increases the maximum output RTP packet size from 1448 to 1456 (as you did). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From K.Vikhorev at liverpool.ac.uk Thu Oct 23 04:25:43 2014 From: K.Vikhorev at liverpool.ac.uk (Vikhorev, Konstantin) Date: Thu, 23 Oct 2014 11:25:43 +0000 Subject: [Live-devel] Concurrent OnDemandServerMediaSubsession to stream MPEG Message-ID: <9C37CF9A21989A4BAB49C7BC56CF3E382D04D289@CHEXMBX1.livad.liv.ac.uk> Dear Live555 Team, I am using Live555 library to create simple rtsp server to stream several mpeg video feeds. For this purpose I've implemented subclasses of : 1. Framed source 2. OnDemandServerMediaSubsession In my OnDemandServerMediaSubsession subclass I have implemented both required function createNewStreamSource() (returns MPEG1or2VideoStreamDiscreteFramer*) and createNewRTPSink() (returns MPEG1or2VideoRTPSink*). Frame source threads communicate with the library only by calling 'event triggers'( as suggested in FAQ). Therefore for each video feed I am creating "ServerMediaSession", and ideally several clients that joined different sessions ("one client one session") should receive a video data concurrently. However, although one client(I used VLC player) can join any single media session and receive video data, two clients (VLC players) can't receive data from two separate video feeds simultaneously. A client that joined session earlier is being disconnected all the time. Also two or more clients can join one session and receive video data simultaneously. I attached code my media session: //// Subclass of OnDemandServerMediaSubsession/// AnalysingServerMediaSubsession* AnalysingServerMediaSubsession::createNew(UsageEnvironment& env,FFMPEG *Encoder, unsigned estimatedBitrate, Boolean iFramesOnly, double vshPeriod) { return new AnalysingServerMediaSubsession(env, Encoder, estimatedBitrate, iFramesOnly, vshPeriod); } AnalysingServerMediaSubsession ::AnalysingServerMediaSubsession(UsageEnvironment& env, FFMPEG *Encoder, unsigned estimatedBitrate, Boolean iFramesOnly, double vshPeriod) : OnDemandServerMediaSubsession(env, True), m_Encoder(Encoder), fIFramesOnly(iFramesOnly), fVSHPeriod(vshPeriod) { fEstimatedKbps = (estimatedBitrate + 500)/1000; } AnalysingServerMediaSubsession ::~AnalysingServerMediaSubsession() { } FramedSource* AnalysingServerMediaSubsession ::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = fEstimatedKbps; AnalyserSource* source = AnalyserSource::createNew(envir(),m_Encoder); return MPEG1or2VideoStreamDiscreteFramer::createNew(envir(),source,fIFramesOnly); } RTPSink* AnalysingServerMediaSubsession ::createNewRTPSink(Groupsock* rtpGroupsock, unsigned char /*rtpPayloadTypeIfDynamic*/, FramedSource* /*inputSource*/) { return MPEG1or2VideoRTPSink::createNew(envir(), rtpGroupsock); } and video source: ///// Video source /// AnalyserSource* AnalyserSource::createNew(UsageEnvironment& env, FFMPEG * E_Source) { return new AnalyserSource(env, E_Source); } EventTriggerId AnalyserSource::eventTriggerId = 0; unsigned AnalyserSource::referenceCount = 0; AnalyserSource::AnalyserSource(UsageEnvironment& env, FFMPEG * E_Source) : FramedSource(env), Encoding_Source(E_Source) { if (referenceCount == 0) { } ++referenceCount; Last_Sent_Frame_ID = 0; Encoding_Source->RegisterRTSP_Source(&(env.taskScheduler()), this); if (eventTriggerId == 0) { eventTriggerId = envir().taskScheduler().createEventTrigger(deliverFrame0); } } AnalyserSource::~AnalyserSource() { Encoding_Source->Un_RegisterRTSP_Source(this); --referenceCount; if (referenceCount == 0) { envir().taskScheduler().deleteEventTrigger(eventTriggerId); eventTriggerId = 0; } } unsigned AnalyserSource::GetRefCount() { return referenceCount; } void AnalyserSource::doGetNextFrame() { unsigned int FrameID = Encoding_Source->GetFrameID(); if (FrameID == 0){ handleClosure(this); return; } if (Last_Sent_Frame_ID != FrameID){ deliverFrame(); } } void AnalyserSource::deliverFrame0(void* clientData) { ((AnalyserSource*)clientData)->deliverFrame(); } void AnalyserSource::deliverFrame() { if (!isCurrentlyAwaitingData()){return } static u_int8_t* newFrameDataStart=NULL; static unsigned newFrameSize = 0; /* get the data frame from the Encoding thread.. */ if (Encoding_Source->GetFrame(&newFrameDataStart, &newFrameSize, &Last_Sent_Frame_ID)){ if (newFrameDataStart!=NULL) { /* This should never happen, but check anyway.. */ if (newFrameSize > fMaxSize) { fFrameSize = fMaxSize; fNumTruncatedBytes = newFrameSize - fMaxSize; } else { fFrameSize = newFrameSize; } gettimeofday(&fPresentationTime, NULL); memmove(fTo, newFrameDataStart, fFrameSize); Encoding_Source->ReleaseFrame(); } else { fFrameSize=0; fTo=NULL; handleClosure(this); } } else { handleClosure(this); } FramedSource::afterGetting(this); } Would you please help me here: Have I miss something in my implementation or am I doing something wrong completely wrong. -- Best Regards, Konstantin Vikhorev Dr Konstantin Vikhorev The Virtual Engineering Centre University of Liverpool Office: A41 STFC Daresbury Laboratory Daresbury Science and Innovation Campus Warrington, WA4 4AD United Kingdom -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 23 17:54:44 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 23 Oct 2014 17:54:44 -0700 Subject: [Live-devel] Concurrent OnDemandServerMediaSubsession to stream MPEG In-Reply-To: <9C37CF9A21989A4BAB49C7BC56CF3E382D04D289@CHEXMBX1.livad.liv.ac.uk> References: <9C37CF9A21989A4BAB49C7BC56CF3E382D04D289@CHEXMBX1.livad.liv.ac.uk> Message-ID: <1107BDA2-D6CF-46C9-A6EC-8426C87C858E@live555.com> I don?t see anything obviously wrong with your code. However, I suggest using ?openRTSP? or ?testRTSPClient? - rather than VLC - as RTSP clients to test your server. With VLC, it?s hard to tell what?s going on. Also, people often have trouble running more than one copy of VLC (for different streams) on the same computer; the decoding/rendering overhead of VLC is often the problem, rather than any problem with RTSP/RTP or our server code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Lince at datapath.co.uk Fri Oct 24 09:37:43 2014 From: Richard.Lince at datapath.co.uk (Richard Lince) Date: Fri, 24 Oct 2014 16:37:43 +0000 Subject: [Live-devel] H264or5VideoStreamParser::parse() from a FramedSource Message-ID: Hi, It would seem that my live h264 stream format I am delivering into H264or5VideoStreamParser::parse() is incorrect. I correctly parse the SPS, then PPS from the algorithm but from then on its a bit hit and miss. I know that the source stream is good (I have emulated the live input using an embedded .264 file). The NAL format is 00000001 proceeding each frame. The final four bytes of the frame do not have a NAL. I've been stepping through H264or5VideoStreamParser::parse() for most of the week and can only manage to stream a poor picture as half the NALs are not recognized. Any obvious ideas? After creating my own class's * class myRTSPSinkOndemandMediaSubsession : public OnDemandServerMediaSubsession * class myFrameSource : public FramedSource myFrameSource *pFrameSource = NULL; ServerMediaSession *sms = ServerMediaSession::createNew(*_env, "myFirstStream", 0, "Session from /dev/video1"); sms->addSubsession ( myRTSPSinkOndemandMediaSubsession::createNew(*_env, pFrameSource)); rtspServer->addServerMediaSession(sms); Usual FramedSource if (size > fMaxSize) { fNumTruncatedBytes = size - fMaxSize; fFrameSize = fMaxSize; } else { fFrameSize = size; fNumTruncatedBytes = 0; } memcpy(fTo, pFrame->PStart, fFrameSize ); Best Regards, Richard Lince ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 24 10:36:24 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 24 Oct 2014 10:36:24 -0700 Subject: [Live-devel] H264or5VideoStreamParser::parse() from a FramedSource In-Reply-To: References: Message-ID: <3B9A0F54-245D-4832-9E5D-D06925BE95CA@live555.com> > After creating my own class's > ? class myRTSPSinkOndemandMediaSubsession : public OnDemandServerMediaSubsession > ? class myFrameSource : public FramedSource If your ?myFrameSource? class delivers discrete H.264 NAL units (i.e., one at a time), rather than an unstructured byte stream, then you MUST feed this into a ?H264VideoStreamDiscreteFramer?, NOT a ?H264VideoStreamFramer?. In particular, your ?myRTSPSinkOndemandMediaSubsession? class?s implementation of the "createNewStreamSource()? virtual function should look something like this: ////////// FramedSource* myRTSPSinkOndemandMediaSubsession::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 500; // in kbps; set this to an appropriate estimate of your stream?s bitrate // Create the video source: FramedSource* videoSource = myFrameSource::createNew(envir(), params); // Create a framer for the video stream: return H264VideoStreamDiscreteFramer::createNew(envir(), videoSource); } ////////// Note also that - because you?re feeding into a ?H264VideoStreamDiscreteFramer? - each H.264 NAL unit delivered by your ?myFrameSource? object MUST NOT begin with a ?start code? (0x00 0x00 0x00 0x01). Also, if your encoder doesn?t automatically do so, then you should arrange for the first two NAL units delivered by your ?myFrameSource? object to be a SPS and a PPS NAL unit. (Alternatively, in your implementation of the ?createNewRTPSink()? virtual function, you can use one of the forms of ?H264VideoRTPSink::createNew()? that takes SPS and PPS NAL unit information as parameters.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From K.Vikhorev at liverpool.ac.uk Mon Oct 27 09:43:28 2014 From: K.Vikhorev at liverpool.ac.uk (Vikhorev, Konstantin) Date: Mon, 27 Oct 2014 16:43:28 +0000 Subject: [Live-devel] Concurrent OnDemandServerMediaSubsession to stream MPEG In-Reply-To: <1107BDA2-D6CF-46C9-A6EC-8426C87C858E@live555.com> References: <9C37CF9A21989A4BAB49C7BC56CF3E382D04D289@CHEXMBX1.livad.liv.ac.uk> <1107BDA2-D6CF-46C9-A6EC-8426C87C858E@live555.com> Message-ID: <9C37CF9A21989A4BAB49C7BC56CF3E382D04FCB5@CHEXMBX1.livad.liv.ac.uk> Dear Ross Finlayson, Thanks for your quick reply. I tried your suggestion today and result is the same. I can only stream data to one session at the time. Could it be some pre-processor definition that I am missing? Also some times when I try to play to streams at the same time I get following exception: ?RTCPInstance:: RTCPInstance error: totSessionBW parameter should not be zero!? -- Best Regards, Konstantin Vikhorev Dr Konstantin Vikhorev The Virtual Engineering Centre University of Liverpool Office: A41 STFC Daresbury Laboratory Daresbury Science and Innovation Campus Warrington, WA4 4AD United Kingdom From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Friday, October 24, 2014 1:55 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Concurrent OnDemandServerMediaSubsession to stream MPEG I don?t see anything obviously wrong with your code. However, I suggest using ?openRTSP? or ?testRTSPClient? - rather than VLC - as RTSP clients to test your server. With VLC, it?s hard to tell what?s going on. Also, people often have trouble running more than one copy of VLC (for different streams) on the same computer; the decoding/rendering overhead of VLC is often the problem, rather than any problem with RTSP/RTP or our server code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Oct 27 15:19:35 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 27 Oct 2014 15:19:35 -0700 Subject: [Live-devel] Concurrent OnDemandServerMediaSubsession to stream MPEG In-Reply-To: <9C37CF9A21989A4BAB49C7BC56CF3E382D04FCB5@CHEXMBX1.livad.liv.ac.uk> References: <9C37CF9A21989A4BAB49C7BC56CF3E382D04D289@CHEXMBX1.livad.liv.ac.uk> <1107BDA2-D6CF-46C9-A6EC-8426C87C858E@live555.com> <9C37CF9A21989A4BAB49C7BC56CF3E382D04FCB5@CHEXMBX1.livad.liv.ac.uk> Message-ID: <77B97C90-7449-4559-A27E-1F189C9E2FDA@live555.com> > I tried your suggestion today and result is the same. I can only stream data to one session at the time. > > Could it be some pre-processor definition that I am missing? > > Also some times when I try to play to streams at the same time I get following exception: > ?RTCPInstance:: RTCPInstance error: totSessionBW parameter should not be zero!? This suggests that, somehow, ?fEstimatedKbps? is getting set to zero. You might try running a debugger (such as ?gdb?) to test whether that member variable ever gets overwritten. You might have a ?memory smash? (e.g., buffer overflow bug) somewhere in your code that?s causing this to happen. Also, you should make sure that you never have more than one thread calling LIVE555 library code (except for the thread that calls ?triggerEvent()? - the only LIVE555 function that you may call from a separate thread). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richard.Lince at datapath.co.uk Tue Oct 28 10:35:06 2014 From: Richard.Lince at datapath.co.uk (Richard Lince) Date: Tue, 28 Oct 2014 17:35:06 +0000 Subject: [Live-devel] H264or5VideoStreamParser::parse() from a FramedSource In-Reply-To: <3B9A0F54-245D-4832-9E5D-D06925BE95CA@live555.com> References: <3B9A0F54-245D-4832-9E5D-D06925BE95CA@live555.com> Message-ID: Thanks Ross, that has worked well. Richard. From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 24 October 2014 18:36 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] H264or5VideoStreamParser::parse() from a FramedSource After creating my own class's ? class myRTSPSinkOndemandMediaSubsession : public OnDemandServerMediaSubsession ? class myFrameSource : public FramedSource If your ?myFrameSource? class delivers discrete H.264 NAL units (i.e., one at a time), rather than an unstructured byte stream, then you MUST feed this into a ?H264VideoStreamDiscreteFramer?, NOT a ?H264VideoStreamFramer?. In particular, your ?myRTSPSinkOndemandMediaSubsession? class?s implementation of the "createNewStreamSource()? virtual function should look something like this: ////////// FramedSource* myRTSPSinkOndemandMediaSubsession::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 500; // in kbps; set this to an appropriate estimate of your stream?s bitrate // Create the video source: FramedSource* videoSource = myFrameSource::createNew(envir(), params); // Create a framer for the video stream: return H264VideoStreamDiscreteFramer::createNew(envir(), videoSource); } ////////// Note also that - because you?re feeding into a ?H264VideoStreamDiscreteFramer? - each H.264 NAL unit delivered by your ?myFrameSource? object MUST NOT begin with a ?start code? (0x00 0x00 0x00 0x01). Also, if your encoder doesn?t automatically do so, then you should arrange for the first two NAL units delivered by your ?myFrameSource? object to be a SPS and a PPS NAL unit. (Alternatively, in your implementation of the ?createNewRTPSink()? virtual function, you can use one of the forms of ?H264VideoRTPSink::createNew()? that takes SPS and PPS NAL unit information as parameters.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clark.anthony.g at gmail.com Tue Oct 28 09:00:48 2014 From: clark.anthony.g at gmail.com (Anthony Clark) Date: Tue, 28 Oct 2014 12:00:48 -0400 Subject: [Live-devel] Multicast Interface Message-ID: Hey all, First off, I'm using the newest live555 and focusing only on linux. So, I'm interested in forcing Groupsock to send multicast from a specific interface via `struct ip_mreqn`. It's fairly simple to do this when you know the interface name and interface IP ahead of time. See `man 7 ip` . I need this since I don't want to rely on the kernel to figure out how to route multicast and I will not have access to other means of routing tables. I can patch `Groupsock` constructors to take some extra arguments, but I quickly realized that this in-turn effects almost everything else. Any other better means of providing this advice would probably be better. I'd love to hear how others would solve this. Thanks! -Anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Oct 28 22:26:37 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 28 Oct 2014 22:26:37 -0700 Subject: [Live-devel] Multicast Interface In-Reply-To: References: Message-ID: > First off, I'm using the newest live555 and focusing only on linux. So, I'm interested in forcing Groupsock to send multicast from a specific interface The easiest (and most reliable) way to do this is to arrange for this interface to be the one that?s used for IP multicast routing - i.e., has a route for 224.0.0.0/4 . You should be able to do this using the ?route? command (type ?man route?). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clark.anthony.g at gmail.com Wed Oct 29 08:20:45 2014 From: clark.anthony.g at gmail.com (Anthony Clark) Date: Wed, 29 Oct 2014 11:20:45 -0400 Subject: [Live-devel] Multicast Interface In-Reply-To: References: Message-ID: Ross, Thanks for the reply. I know how routing works ;). Just to avoid the back-and-forth. I have one single interface in AP mode and the kernel will *never* choose it for mcast routing even though a route is present, mcast is enabled, etc. I could use a tun/tap in theory, but I think that just makes it more complicated. Being able to explicitly choose the mcast interface avoids a lot of environment variation. If you think forcing an interface is to be avoided, then I'll make the best and most practical changes I can to live555/Groupsock and send in a patch just so you can see. I appreciate the help, and live555 - it's great. On Wed, Oct 29, 2014 at 1:26 AM, Ross Finlayson wrote: > First off, I'm using the newest live555 and focusing only on linux. So, > I'm interested in forcing Groupsock to send multicast from a specific > interface > > > The easiest (and most reliable) way to do this is to arrange for this > interface to be the one that?s used for IP multicast routing - i.e., has a > route for 224.0.0.0/4 . You should be able to do this using the ?route? > command (type ?man route?). > > > 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 Wed Oct 29 11:02:35 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 Oct 2014 11:02:35 -0700 Subject: [Live-devel] Multicast Interface In-Reply-To: References: Message-ID: <91EC0F44-C311-4D77-B484-3433D8D1B0D5@live555.com> > Thanks for the reply. I know how routing works ;) Well, your use of a ?@gmail.com ? email address announces to the world that you don?t know much of anything (and it?s why your email to the list is moderated). Just saying :-) > I have one single interface in AP mode and the kernel will *never* choose it for mcast routing even though a route is present, mcast is enabled, etc. If you have a single interface on which IP multicast routing is enabled, but IP multicast doesn?t work, then that sounds like a bug in your system somewhere (perhaps a device driver). Even a WiFi interface in Access Point mode (assuming that that?s what you meant by ?AP mode?) should be able to send/receive IP multicast. As I said before, setting one of your interfaces (but no other) to have a route for 224/8 is usually the most reliable way to have it chosen for IP multicast. But if that doesn?t work, you can try setting the global variables ?SendingInterfaceAddr? and ?ReceivingInterfaceAddr? to explicitly set the interface that you want to use. (But that?s definitely not 100% reliable either.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clark.anthony.g at gmail.com Wed Oct 29 11:44:32 2014 From: clark.anthony.g at gmail.com (Anthony Clark) Date: Wed, 29 Oct 2014 14:44:32 -0400 Subject: [Live-devel] Multicast Interface In-Reply-To: <91EC0F44-C311-4D77-B484-3433D8D1B0D5@live555.com> References: <91EC0F44-C311-4D77-B484-3433D8D1B0D5@live555.com> Message-ID: On Wed, Oct 29, 2014 at 2:02 PM, Ross Finlayson wrote: > Thanks for the reply. I know how routing works ;) > > > Well, your use of a ?@gmail.com? email address announces to the world > that you don?t know much of anything (and it?s why your email to the list > is moderated). Just saying :-) > > Haha! There are issues with gmail now? Sigh .. I figured I'd get less help supplying my workplace address and not all of us have personal domains ;). I'll do that from now on. > > I have one single interface in AP mode and the kernel will *never* choose > it for mcast routing even though a route is present, mcast is enabled, etc. > > > If you have a single interface on which IP multicast routing is enabled, > but IP multicast doesn?t work, then that sounds like a bug in your system > somewhere (perhaps a device driver). > It was an issue with kernel 3.13 ... updated to 3.15 and an opensource driver. It's fixed for now. It's no longer a live555 issue. > Even a WiFi interface in Access Point mode (assuming that that?s what you > meant by ?AP mode?) should be able to send/receive IP multicast. > I had to stop assuming this sort of thing for 802.11 devices... especially where only closed-sourced drivers exist. > > As I said before, setting one of your interfaces (but no other) to have a > route for 224/8 is usually the most reliable way to have it chosen for IP > multicast. But if that doesn?t work, you can try setting the global > variables ?SendingInterfaceAddr? and ?ReceivingInterfaceAddr? to explicitly > set the interface that you want to use. (But that?s definitely not 100% > reliable either.) > As an aside - From a networked library writers perspective, I wonder when it's appropriate to allow forcing an interface (ie - ignoring routing) ... anyways. Thanks. This issue is closed. > > 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 Wed Oct 29 12:37:26 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 Oct 2014 12:37:26 -0700 Subject: [Live-devel] Multicast Interface In-Reply-To: References: <91EC0F44-C311-4D77-B484-3433D8D1B0D5@live555.com> Message-ID: <353B0050-524D-4287-AFD5-A39AFBAB0427@live555.com> > Haha! There are issues with gmail now? Not ?now?. The stigma against unprofessional email addresses has existed for years (since people started using ?@aol.com ? addresses). It?s clearly explained in the FAQ (that everyone is asked to read before posting to the mailing list). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Oct 30 17:23:13 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Oct 2014 17:23:13 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? Message-ID: I?m trying to connect (using LIVE555 RTSP client software, of course) to a ?Swann SWNHD-806CAM? 720p network camera, but I?m having trouble figuring out the stream name to use. I?ve tried rtsp://admin:12345 at IP-address/ plus rtsp://admin:12345 at IP-address/ for various values of , including (various suggestions that I?ve seen on the Internet): h264 Streaming/Channels/1 Channel 720p but in each case I get a "RTSP/1.0 404 Stream Not Found? response to the ?DESCRIBE? command. Does anyone know the RTSP URL format that will work with this particular network camera? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Thu Oct 30 18:47:02 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Thu, 30 Oct 2014 21:47:02 -0400 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: Message-ID: Not off the top of my head but start wireshark and use whatever software they provide.You may be able to filter the traffic for tcp.dstport == 554 and then follow the stream. On Thu, Oct 30, 2014 at 8:23 PM, Ross Finlayson wrote: > I?m trying to connect (using LIVE555 RTSP client software, of course) to a > ?Swann SWNHD-806CAM? 720p network camera, but I?m having trouble figuring > out the stream name to use. I?ve tried > rtsp://admin:12345 at IP-address/ > plus > rtsp://admin:12345 at IP-address/ > for various values of , including (various suggestions that > I?ve seen on the Internet): > h264 > Streaming/Channels/1 > Channel > 720p > but in each case I get a "RTSP/1.0 404 Stream Not Found? response to the > ?DESCRIBE? command. > > Does anyone know the RTSP URL format that will work with this particular > network camera? > > > 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 Thu Oct 30 19:05:06 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Oct 2014 19:05:06 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: Message-ID: <610FD991-90F5-4486-9996-65D7DBF7B8BD@live555.com> > Not off the top of my head but start wireshark and use whatever software they provide. That?s the thing. The manufacturer wants you to also buy one of their DVRs, and hook the camera up to this. The ?software they provide? seems to work only by accessing the DVR. But I don?t want to buy their DVR (because I have my own client/recording software :-). Instead, I want to access the network camera directly. I was hoping that someone on this mailing list might already be using this network camera for similar purposes :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Thu Oct 30 19:25:33 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Thu, 30 Oct 2014 22:25:33 -0400 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <610FD991-90F5-4486-9996-65D7DBF7B8BD@live555.com> References: <610FD991-90F5-4486-9996-65D7DBF7B8BD@live555.com> Message-ID: I have veen wanting to get one of these . I will look tomarrow at work to see if we have it docunented anywhere On Oct 30, 2014 10:14 PM, "Ross Finlayson" wrote: > Not off the top of my head but start wireshark and use whatever software > they provide. > > > That?s the thing. The manufacturer wants you to also buy one of their > DVRs, and hook the camera up to this. The ?software they provide? seems to > work only by accessing the DVR. > > But I don?t want to buy their DVR (because I have my own client/recording > software :-). Instead, I want to access the network camera directly. > > I was hoping that someone on this mailing list might already be using this > network camera for similar purposes :-) > > 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 francisco at eyelynx.com Thu Oct 30 23:43:31 2014 From: francisco at eyelynx.com (EyeLynx) Date: Fri, 31 Oct 2014 07:43:31 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: <610FD991-90F5-4486-9996-65D7DBF7B8BD@live555.com> Message-ID: <9602D494-44CB-41FB-B983-9AE5C8967071@eyelynx.com> Maybe one of these links? I haven't tried http://www.ispyconnect.com/man.aspx?n=Swann Best Regards Francisco Feijoo > El 31/10/2014, a las 3:25, Jeff Shanab escribi?: > > I have veen wanting to get one of these . I will look tomarrow at work to see if we have it docunented anywhere > On Oct 30, 2014 10:14 PM, "Ross Finlayson" wrote: >>> Not off the top of my head but start wireshark and use whatever software they provide. >> >> That?s the thing. The manufacturer wants you to also buy one of their DVRs, and hook the camera up to this. The ?software they provide? seems to work only by accessing the DVR. >> >> But I don?t want to buy their DVR (because I have my own client/recording software :-). Instead, I want to access the network camera directly. >> >> I was hoping that someone on this mailing list might already be using this network camera for similar purposes :-) >> >> 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 > _______________________________________________ > 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 Thu Oct 30 23:50:46 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Oct 2014 23:50:46 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <9602D494-44CB-41FB-B983-9AE5C8967071@eyelynx.com> References: <610FD991-90F5-4486-9996-65D7DBF7B8BD@live555.com> <9602D494-44CB-41FB-B983-9AE5C8967071@eyelynx.com> Message-ID: <34022722-929D-4225-B9BC-C815BCC3ACC3@live555.com> > Maybe one of these links? I haven't tried > > http://www.ispyconnect.com/man.aspx?n=Swann Yes, I tried all of the ?rtsp://? URLs listed there. No luck :-( Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From francisco at eyelynx.com Fri Oct 31 01:07:23 2014 From: francisco at eyelynx.com (Francisco Feijoo) Date: Fri, 31 Oct 2014 09:07:23 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <34022722-929D-4225-B9BC-C815BCC3ACC3@live555.com> References: <610FD991-90F5-4486-9996-65D7DBF7B8BD@live555.com> <9602D494-44CB-41FB-B983-9AE5C8967071@eyelynx.com> <34022722-929D-4225-B9BC-C815BCC3ACC3@live555.com> Message-ID: Looks like it's a rebranded Hikvision camera so it should be: rtsp://admin:12345 at IP-address/Streaming/Channels/1 This guy plays with it in this video https://www.youtube.com/watch?v=6N3DrHFBO50#t=1083 He seems to enjoy it ... Good luck! 2014-10-31 7:50 GMT+01:00 Ross Finlayson : > Maybe one of these links? I haven't tried > > http://www.ispyconnect.com/man.aspx?n=Swann > > > Yes, I tried all of the ?rtsp://? URLs listed there. No luck :-( > > > 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 > > -- *Francisco Feijoo - MSc (Eng)* Chief Technical Officer EyeLynx a subsidiary of Zaun Limited +44 020 8133 9388 | www.eyelynx.com | @EyeLynxLtd | Youtube EyeLynx Limited, the creators of SharpView are defining Video Intelligence, full HD and Megapixel CCTV to provide state-of-the-art electronic security solutions for critical needs. EyeLynx, develops and manufactures total perimeter protection solutions using RADAR, Video Analytics, PIDs, Thermal Imaging and PIRs which fully integrate into fencing and barrier systems using SharpView. For more information, contact us via sales at eyelynx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 31 01:23:41 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 01:23:41 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: <610FD991-90F5-4486-9996-65D7DBF7B8BD@live555.com> <9602D494-44CB-41FB-B983-9AE5C8967071@eyelynx.com> <34022722-929D-4225-B9BC-C815BCC3ACC3@live555.com> Message-ID: > Looks like it's a rebranded Hikvision camera so it should be: > > rtsp://admin:12345 at IP-address/ <>Streaming/Channels/1 > > This guy plays with it in this video https://www.youtube.com/watch?v=6N3DrHFBO50#t=1083 No, unfortunately that URL doesn?t work for the Swann model 806 (720p) network camera that I have. It seems to work only with the model 820 (1080p); the model shown in that YouTube video. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dee.earley at icode.co.uk Fri Oct 31 01:44:07 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Fri, 31 Oct 2014 08:44:07 +0000 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: Message-ID: Sorry, the only details we have for Swann are over HTTP. The models we?ve seen are also rebranded from various other manufacturers. Maybe they?ve gone the same way as Ubiquiti and removed any standard streaming support in favour of their own DVR :| -- Deanna Earley | Lead developer | icatchercctv w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338 Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325 From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 31 October 2014 00:23 To: LIVE555 Streaming Media - development & use Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? I?m trying to connect (using LIVE555 RTSP client software, of course) to a ?Swann SWNHD-806CAM? 720p network camera, but I?m having trouble figuring out the stream name to use. I?ve tried rtsp://admin:12345 at IP-address/ plus rtsp://admin:12345 at IP-address/ for various values of , including (various suggestions that I?ve seen on the Internet): h264 Streaming/Channels/1 Channel 720p but in each case I get a "RTSP/1.0 404 Stream Not Found? response to the ?DESCRIBE? command. Does anyone know the RTSP URL format that will work with this particular network camera? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 31 01:50:25 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 01:50:25 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: Message-ID: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> > Maybe they?ve gone the same way as Ubiquiti and removed any standard streaming support in favour of their own DVR K I suppose that?s possible, but I doubt it in this case - because it appears to handle the RTSP protocol just fine. Unfortunately, though, I get a RTSP/1.0 404 Stream Not Found response for every URL that I?ve tried so far. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 31 02:06:45 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 02:06:45 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> Message-ID: <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> > On Oct 31, 2014, at 1:50 AM, Ross Finlayson wrote: > >> Maybe they?ve gone the same way as Ubiquiti and removed any standard streaming support in favour of their own DVR K > > I suppose that?s possible, but I doubt it in this case - because it appears to handle the RTSP protocol just fine. Unfortunately, though, I get a > > RTSP/1.0 404 Stream Not Found > response for every URL that I?ve tried so far. For example: %openRTSP -n rtsp://admin:12345 at 50.0.150.53/Streaming/Channels/1 Opening connection to 50.0.150.53, port 554... ...remote connection opened Sending request: OPTIONS rtsp://admin:12345 at 50.0.150.53/Streaming/Channels/1 RTSP/1.0 CSeq: 2 User-Agent: openRTSP (LIVE555 Streaming Media v2014.10.28) Received 152 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Sat, Jan 01 2011 09:48:09 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Sending request: DESCRIBE rtsp://admin:12345 at 50.0.150.53/Streaming/Channels/1 RTSP/1.0 CSeq: 3 User-Agent: openRTSP (LIVE555 Streaming Media v2014.10.28) Accept: application/sdp Received 79 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 404 Stream Not Found CSeq: 3 Date: Sat, Jan 01 2011 09:48:09 GMT If anyone out there has an idea, feel free to try to access: rtsp://admin:12345 at 50.0.150.53/ (It?s getting late; I need to get to bed :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dee.earley at icode.co.uk Fri Oct 31 02:21:38 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Fri, 31 Oct 2014 09:21:38 +0000 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> Message-ID: <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> If anyone out there has an idea, feel free to try to access: rtsp://admin:12345 at 50.0.150.53/ Any Chance of HTTP forwarded too? -- Deanna Earley | Lead developer | icatchercctv w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338 Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at speed666.info Fri Oct 31 03:51:29 2014 From: marcin at speed666.info (Marcin) Date: Fri, 31 Oct 2014 11:51:29 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> Message-ID: <545369B1.2040407@speed666.info> Not working - gimme also http access to this cam. Marcin W dniu 2014-10-31 10:21, Deanna Earley pisze: > > If anyone out there has an idea, feel free to try to access: > > rtsp://admin:12345 at 50.0.150.53/ > > > Any Chance of HTTP forwarded too? > > -- > > *Deanna Earley |* Lead developer *| **icatcher**cctv* > > ** > > w: _www.icode.co.uk/icatcher _| t: > 01329 835335 | f: 01329 835338 > > Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : > 03428325 > > > > _______________________________________________ > 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 dnyanesh.gate at intelli-vision.com Fri Oct 31 04:23:36 2014 From: dnyanesh.gate at intelli-vision.com (Dnyanesh Gate) Date: Fri, 31 Oct 2014 16:53:36 +0530 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera Message-ID: Hi, We do use some swann network cameras for our products. Did you tried this url rtsp://admin:12345 at ip_address/stream1? We use this url in our player. -- Thanks & Regards, DnyaneshG. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Fri Oct 31 03:10:12 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Fri, 31 Oct 2014 06:10:12 -0400 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: <610FD991-90F5-4486-9996-65D7DBF7B8BD@live555.com> <9602D494-44CB-41FB-B983-9AE5C8967071@eyelynx.com> <34022722-929D-4225-B9BC-C815BCC3ACC3@live555.com> Message-ID: Cool. Seeing as i just spent the last week working on our hikvision plugin i am actuallycquite familiarcwith their api. LOL Hikvision oem a lot Interlogix for one my previous employer and now my current employer. There is actuallyva lot of that in the industry, companies like UDP and Sercomm. Etc. On Oct 31, 2014 4:15 AM, "Francisco Feijoo" wrote: > Looks like it's a rebranded Hikvision camera so it should be: > > rtsp://admin:12345 at IP-address/Streaming/Channels/1 > > This guy plays with it in this video > https://www.youtube.com/watch?v=6N3DrHFBO50#t=1083 > > He seems to enjoy it ... > > Good luck! > > 2014-10-31 7:50 GMT+01:00 Ross Finlayson : > >> Maybe one of these links? I haven't tried >> >> http://www.ispyconnect.com/man.aspx?n=Swann >> >> >> Yes, I tried all of the ?rtsp://? URLs listed there. No luck :-( >> >> >> 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 >> >> > > > -- > *Francisco Feijoo - MSc (Eng)* > Chief Technical Officer > EyeLynx a subsidiary of Zaun Limited > > +44 020 8133 9388 | www.eyelynx.com | @EyeLynxLtd > | Youtube > > > > EyeLynx Limited, the creators of SharpView are defining Video > Intelligence, full HD and > Megapixel CCTV to provide state-of-the-art electronic security solutions > for critical needs. > EyeLynx, develops and manufactures total perimeter protection solutions > using RADAR, > Video Analytics, PIDs, Thermal Imaging and PIRs which fully integrate into > fencing and > barrier systems using SharpView. For more information, contact us via > sales at eyelynx.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 jshanab at jfs-tech.com Fri Oct 31 04:54:15 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Fri, 31 Oct 2014 07:54:15 -0400 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: References: Message-ID: I think someone mentioned this camera is ONVIF. if so the URI is in the XML. Maybe an opensource tool like DeviceManager can extract it for you. On Fri, Oct 31, 2014 at 7:23 AM, Dnyanesh Gate < dnyanesh.gate at intelli-vision.com> wrote: > Hi, > > We do use some swann network cameras for our products. > Did you tried this url rtsp://admin:12345 at ip_address/stream1? > We use this url in our player. > > -- > Thanks & Regards, > DnyaneshG. > > _______________________________________________ > 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 Oct 31 06:13:04 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 06:13:04 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <545369B1.2040407@speed666.info> References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> <545369B1.2040407@speed666.info> Message-ID: > On Oct 31, 2014, at 3:51 AM, Marcin wrote: > > Not working - gimme also http access to this cam. > Marcin > > W dniu 2014-10-31 10:21, Deanna Earley pisze: >> If anyone out there has an idea, feel free to try to access: >> rtsp://admin:12345 at 50.0.150.53/ >> >> >> Any Chance of HTTP forwarded too? No, the camera rejects HTTP access (at least, on the standard ports): %telnet 50.0.150.53 80 Trying 50.0.150.53... telnet: connect to address 50.0.150.53: Connection refused telnet: Unable to connect to remote host %telnet 50.0.150.53 443 Trying 50.0.150.53... telnet: connect to address 50.0.150.53: Connection refused telnet: Unable to connect to remote host And there?s no firewall anywhere in front of the camera. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 31 06:16:06 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 06:16:06 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: References: Message-ID: > We do use some swann network cameras for our products. > Did you tried this url rtsp://admin:12345 at ip_address/stream1? No, that doesn?t work either: %openRTSP -n rtsp://admin:12345 at 50.0.150.53/stream1 Opening connection to 50.0.150.53, port 554... ...remote connection opened Sending request: OPTIONS rtsp://admin:12345 at 50.0.150.53/stream1 RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2012.04.04) Received 152 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Sat, Jan 01 2011 13:58:26 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Sending request: DESCRIBE rtsp://admin:12345 at 50.0.150.53/stream1 RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2012.04.04) Accept: application/sdp Received 79 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 404 Stream Not Found CSeq: 3 Date: Sat, Jan 01 2011 13:58:26 GMT Note that you can try this yourself, using whatever URL suffix you want. Just run: openRTSP rtsp://admin:12345 at 50.0.150.53/ Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 31 07:16:15 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 07:16:15 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> <545369B1.2040407@speed666.info> Message-ID: <7F7D7AB8-5524-4D4A-85FE-905F763F0081@live555.com> >>> Any Chance of HTTP forwarded too? > > No, the camera rejects HTTP access (at least, on the standard ports) I?ve checked all possible ports. The camera rejects TCP access to all ports except: 23 (telnet). If I telnet to the camera, it gives me a login prompt, but the username-password ?admin? ?12345? doesn?t work. 554 (RTSP). HTTP commands are not accepted; only RTSP 6001 (???). HTTP commands are not accepted. 9000 (???). HTTP commands are not accepted. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 31 07:17:06 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 07:17:06 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: References: Message-ID: <91263BAF-4718-4D56-9238-D9651BB5EC0D@live555.com> > I think someone mentioned this camera is ONVIF. if so the URI is in the XML. No HTTP => No XML Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From francisco at eyelynx.com Fri Oct 31 07:27:24 2014 From: francisco at eyelynx.com (EyeLynx) Date: Fri, 31 Oct 2014 15:27:24 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <7F7D7AB8-5524-4D4A-85FE-905F763F0081@live555.com> References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> <545369B1.2040407@speed666.info> <7F7D7AB8-5524-4D4A-85FE-905F763F0081@live555.com> Message-ID: http://admin:12345 at 50.0.150.53:8000 returns some onvif xml. No idea if that helps Best Regards Francisco Feijoo > El 31/10/2014, a las 15:16, Ross Finlayson escribi?: > >>>> Any Chance of HTTP forwarded too? >> >> No, the camera rejects HTTP access (at least, on the standard ports) > > I?ve checked all possible ports. The camera rejects TCP access to all ports except: > 23 (telnet). If I telnet to the camera, it gives me a login prompt, but the username-password ?admin? ?12345? doesn?t work. > 554 (RTSP). HTTP commands are not accepted; only RTSP > 6001 (???). HTTP commands are not accepted. > 9000 (???). HTTP commands are not accepted. > > 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 francisco at eyelynx.com Fri Oct 31 07:36:05 2014 From: francisco at eyelynx.com (EyeLynx) Date: Fri, 31 Oct 2014 15:36:05 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: <7F7D7AB8-5524-4D4A-85FE-905F763F0081@live555.com> References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> <545369B1.2040407@speed666.info> <7F7D7AB8-5524-4D4A-85FE-905F763F0081@live555.com> Message-ID: Check the answer from 'swann tech' in this forum http://www.cctvforum.com/viewtopic.php?f=19&t=41454 Maybe you can use that software .. Best Regards Francisco Feijoo > El 31/10/2014, a las 15:16, Ross Finlayson escribi?: > >>>> Any Chance of HTTP forwarded too? >> >> No, the camera rejects HTTP access (at least, on the standard ports) > > I?ve checked all possible ports. The camera rejects TCP access to all ports except: > 23 (telnet). If I telnet to the camera, it gives me a login prompt, but the username-password ?admin? ?12345? doesn?t work. > 554 (RTSP). HTTP commands are not accepted; only RTSP > 6001 (???). HTTP commands are not accepted. > 9000 (???). HTTP commands are not accepted. > > 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 marcin at speed666.info Fri Oct 31 07:46:53 2014 From: marcin at speed666.info (Marcin) Date: Fri, 31 Oct 2014 15:46:53 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: <91263BAF-4718-4D56-9238-D9651BB5EC0D@live555.com> References: <91263BAF-4718-4D56-9238-D9651BB5EC0D@live555.com> Message-ID: <5453A0DD.3060800@speed666.info> # Welcome to HiLinux. -sh: Welcome: not found # None of nfsroot found in cmdline. -sh: None: not found # # # # # lsusb -sh: lsusb: not found # ifconfig eth0 Link encap:Ethernet HWaddr EC:71:DB:2F:23:E6 inet addr:50.0.150.53 Bcast:50.0.150.255 Mask:255.255.255.0 inet6 addr: 2001:470:82e9:1:ee71:dbff:fe2f:23e6/64 Scope:Global inet6 addr: 2001:470:82e9:0:ee71:dbff:fe2f:23e6/64 Scope:Global inet6 addr: fe80::200:23ff:fe34:4566/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:80844 errors:0 dropped:0 overruns:0 frame:0 TX packets:96361 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5525623 (5.2 MiB) TX bytes:7345725 (7.0 MiB) Interrupt:12 Give some time - i will figure this out :) Marcin W dniu 2014-10-31 15:17, Ross Finlayson pisze: >> I think someone mentioned this camera is ONVIF. if so the URI is in >> the XML. > > No HTTP => No XML > > 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 marcin at speed666.info Fri Oct 31 07:49:49 2014 From: marcin at speed666.info (Marcin) Date: Fri, 31 Oct 2014 15:49:49 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: <91263BAF-4718-4D56-9238-D9651BB5EC0D@live555.com> References: <91263BAF-4718-4D56-9238-D9651BB5EC0D@live555.com> Message-ID: <5453A18D.3000408@speed666.info> You owe me this time: Main: rtsp://admin:12345 at 50.0.150.53/h264Preview_01_main Sub: rtsp://admin:12345 at 50.0.150.53/h264Preview_01_sub Mobile: rtsp://admin:12345 at 50.0.150.53/h264Preview_01_mobile Marcin WebCamera.pl W dniu 2014-10-31 15:17, Ross Finlayson pisze: >> I think someone mentioned this camera is ONVIF. if so the URI is in >> the XML. > > No HTTP => No XML > > 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 dee.earley at icode.co.uk Fri Oct 31 07:53:16 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Fri, 31 Oct 2014 14:53:16 +0000 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: References: Message-ID: <05c3537c697240169ebccb8efd985cd4@SRV-EXCHANGE-2.icode.co.uk> Note that you can try this yourself, using whatever URL suffix you want. Just run: openRTSP rtsp://admin:12345 at 50.0.150.53/ Sorry, but 404 to the 51 camera RTSP URLs known to us. -- Deanna Earley | Lead developer | icatchercctv w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338 Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dee.earley at icode.co.uk Fri Oct 31 07:55:52 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Fri, 31 Oct 2014 14:55:52 +0000 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> <545369B1.2040407@speed666.info> <7F7D7AB8-5524-4D4A-85FE-905F763F0081@live555.com> Message-ID: Bingo, ONVIF returns /h264Preview_01_main and /h264Preview_01_sub. -- Deanna Earley | Lead developer | icatchercctv w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338 Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325 From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of EyeLynx Sent: 31 October 2014 14:27 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] RTSP URL format for a Swann 806 network camera? http://admin:12345 at 50.0.150.53:8000 returns some onvif xml. No idea if that helps Best Regards Francisco Feijoo El 31/10/2014, a las 15:16, Ross Finlayson > escribi?: Any Chance of HTTP forwarded too? No, the camera rejects HTTP access (at least, on the standard ports) I?ve checked all possible ports. The camera rejects TCP access to all ports except: 23 (telnet). If I telnet to the camera, it gives me a login prompt, but the username-password ?admin? ?12345? doesn?t work. 554 (RTSP). HTTP commands are not accepted; only RTSP 6001 (???). HTTP commands are not accepted. 9000 (???). HTTP commands are not accepted. 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 Oct 31 07:56:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 07:56:38 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera? In-Reply-To: References: <5CD70D1E-6DDB-408F-B0AF-ABA78458D624@live555.com> <3C29AA85-BD09-4E31-BFAC-E2780DB6E858@live555.com> <66f6176f43e244b0842b00fc2fd7a8eb@SRV-EXCHANGE-2.icode.co.uk> <545369B1.2040407@speed666.info> <7F7D7AB8-5524-4D4A-85FE-905F763F0081@live555.com> Message-ID: <3462FB56-9D29-4C6C-A46D-07F8E5505F86@live555.com> I finally got it! rtsp:///h264Preview_01_main works. Thanks to everyone for your help. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 31 08:21:19 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 08:21:19 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: <5453A0DD.3060800@speed666.info> References: <91263BAF-4718-4D56-9238-D9651BB5EC0D@live555.com> <5453A0DD.3060800@speed666.info> Message-ID: <9AC0C861-F66B-49B0-9251-C3AF2F0A7B71@live555.com> > # ifconfig > eth0 Link encap:Ethernet HWaddr EC:71:DB:2F:23:E6 > inet addr:50.0.150.53 Bcast:50.0.150.255 Mask:255.255.255.0 > inet6 addr: 2001:470:82e9:1:ee71:dbff:fe2f:23e6/64 Scope:Global > inet6 addr: 2001:470:82e9:0:ee71:dbff:fe2f:23e6/64 Scope:Global > inet6 addr: fe80::200:23ff:fe34:4566/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:80844 errors:0 dropped:0 overruns:0 frame:0 > TX packets:96361 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:5525623 (5.2 MiB) TX bytes:7345725 (7.0 MiB) > Interrupt:12 Nice. How were you able to get shell access? In any case (as I noted in my last email), I was able to find a working URL: rtsp:///h264Preview_01_main Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Oct 31 08:49:07 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 31 Oct 2014 08:49:07 -0700 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: <05c3537c697240169ebccb8efd985cd4@SRV-EXCHANGE-2.icode.co.uk> References: <05c3537c697240169ebccb8efd985cd4@SRV-EXCHANGE-2.icode.co.uk> Message-ID: <19256A37-7E34-4513-8A42-244FDF58BFAD@live555.com> > Sorry, but 404 to the 51 camera RTSP URLs known to us. Please, everybody - read all of the emails on a thread before responding :-) You can now add two more URLs (suffixes) to your list: h264Preview_01_main h264Preview_01_sub It turns out that these both work for the Swann 806 network camera. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From francisco at eyelynx.com Fri Oct 31 09:57:50 2014 From: francisco at eyelynx.com (Francisco Feijoo) Date: Fri, 31 Oct 2014 17:57:50 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: <9AC0C861-F66B-49B0-9251-C3AF2F0A7B71@live555.com> References: <91263BAF-4718-4D56-9238-D9651BB5EC0D@live555.com> <5453A0DD.3060800@speed666.info> <9AC0C861-F66B-49B0-9251-C3AF2F0A7B71@live555.com> Message-ID: telnet 50.0.150.53 user: root pass: And they hide RTSP streams ... 2014-10-31 16:21 GMT+01:00 Ross Finlayson : > # ifconfig > eth0 Link encap:Ethernet HWaddr EC:71:DB:2F:23:E6 > inet addr:50.0.150.53 Bcast:50.0.150.255 Mask:255.255.255.0 > inet6 addr: 2001:470:82e9:1:ee71:dbff:fe2f:23e6/64 Scope:Global > inet6 addr: 2001:470:82e9:0:ee71:dbff:fe2f:23e6/64 Scope:Global > inet6 addr: fe80::200:23ff:fe34:4566/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:80844 errors:0 dropped:0 overruns:0 frame:0 > TX packets:96361 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:5525623 (5.2 MiB) TX bytes:7345725 (7.0 MiB) > Interrupt:12 > > > Nice. How were you able to get shell access? > > In any case (as I noted in my last email), I was able to find a working > URL: > rtsp:///h264Preview_01_main > > > 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 > > -- *Francisco Feijoo - MSc (Eng)* Chief Technical Officer EyeLynx a subsidiary of Zaun Limited +44 020 8133 9388 | www.eyelynx.com | @EyeLynxLtd | Youtube EyeLynx Limited, the creators of SharpView are defining Video Intelligence, full HD and Megapixel CCTV to provide state-of-the-art electronic security solutions for critical needs. EyeLynx, develops and manufactures total perimeter protection solutions using RADAR, Video Analytics, PIDs, Thermal Imaging and PIRs which fully integrate into fencing and barrier systems using SharpView. For more information, contact us via sales at eyelynx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at speed666.info Fri Oct 31 10:59:18 2014 From: marcin at speed666.info (Marcin) Date: Fri, 31 Oct 2014 18:59:18 +0100 Subject: [Live-devel] RTSP URL format for a Swann 806 network camera In-Reply-To: <9AC0C861-F66B-49B0-9251-C3AF2F0A7B71@live555.com> References: <91263BAF-4718-4D56-9238-D9651BB5EC0D@live555.com> <5453A0DD.3060800@speed666.info> <9AC0C861-F66B-49B0-9251-C3AF2F0A7B71@live555.com> Message-ID: <5453CDF6.1010406@speed666.info> Hi Ross, I have a lot of fun in reverse engineer IPCams - i have telnet access passwords to many of them. If you need some - just ask. Marcin W dniu 2014-10-31 16:21, Ross Finlayson pisze: >> # ifconfig >> eth0 Link encap:Ethernet HWaddr EC:71:DB:2F:23:E6 >> inet addr:50.0.150.53 Bcast:50.0.150.255 Mask:255.255.255.0 >> inet6 addr: 2001:470:82e9:1:ee71:dbff:fe2f:23e6/64 Scope:Global >> inet6 addr: 2001:470:82e9:0:ee71:dbff:fe2f:23e6/64 Scope:Global >> inet6 addr: fe80::200:23ff:fe34:4566/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:80844 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:96361 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:5525623 (5.2 MiB) TX bytes:7345725 (7.0 MiB) >> Interrupt:12 > > Nice. How were you able to get shell access? > > In any case (as I noted in my last email), I was able to find a > working URL: > rtsp:///h264Preview_01_main > > > 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 yhwanhee at naver.com Fri Oct 31 23:35:50 2014 From: yhwanhee at naver.com (=?UTF-8?B?7Jyg7ZmY7Z2s?=) Date: Sat, 1 Nov 2014 15:35:50 +0900 (KST) Subject: [Live-devel] =?utf-8?q?please_help_=2C=2C_openrtsp_recording_audi?= =?utf-8?q?o/video_sync_problem?= Message-ID: <916e3b57ad1a304326f5eb747e5d67b@cweb12.nm.nhnsystem.com> I recorded a stream from camera by using openrtsp like this openrtsp -4 -F test -P 120 rtsp://admin:4321 at 192.168.1.121/profile2/media.smp then test-00000-00120.mp4 file is created . i expected the play time would be 120 seconds but was 136 seconds . Is this the problem of audio/video sync ? i used -y option like this : penrtsp -4 -F test -P 120 -y rtsp://admin:4321 at 192.168.1.121/profile2/media.smp but this time mp4 file was nor created correctly it's size was about 120kb. Please tell me how to record the stream into mp4 file with audio/video sync (or how to modify source code of live555 library ) Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: