From Anthony.Desmarais at altech-multimedia.com Mon Dec 1 00:56:17 2014 From: Anthony.Desmarais at altech-multimedia.com (Anthony Desmarais) Date: Mon, 1 Dec 2014 08:56:17 +0000 Subject: [Live-devel] Breakup with mips port Message-ID: <4FDE12B084FA334AB4A6B9E681B4FAB414749244@amizaex01.uectech.net> Hi can I possibly get some advice from the experts here. We are porting the live555 server to one of our embedded devices (set top box) with the intention to be able to multicast a service received via DVB-T to clients on the wifi network using rtp. The target server is a Broadcom based system running linux 3.3.8 kernel. The first step is to cross compile the test programs and verify functionality streaming a file from the devices hard drive over the wifi network. Porting to mips was straight forward thanks to a well thought out configuration option on your teams side. The only change required to compile was to add -DLOCALE_NOT_USED to the configuration file. I used the config.armlinux as a base to create a config.mips with the ony change required being to change the compiler to CROSS_COMPILE?= mipsel-linux- Using the test transport stream from the live555 website "bipbop-gear1-all.ts" I ran the program testMPEG2TransportStreamer Using a windows VLC client I could not play the file back however when I switched to an android client on a tablet (Media Plaver by video experts group) I managed to receive the stream. Problem is that with this stream I get a significant amount of video breakup, if I switch to a higher bitrate stream I get enough breakup to no be able to run video at all. Using a PC I did a tcpdump of the multicast and playing back this dump with a windows player I get the same breakup, so this then rules out the android client. I am now working on getting a wired ethernet port to run on this platform so that I may rule out packet loss from the wifi side. If this proves to be the same then I need to look at what is happening in the live555 side. Can I ask for any pointers in where may be a good place to look? Does the framework try to perform any sort of transcoding or repacking of the stream, and if so where about can I look at that? Today I modified the code in groupsock.cpp to write output to the disk rather than to the network. When I attempt to playback this written file I get the same picture breakup so I am now confident that the losses are somewhere in the live555 framework, but I am not sure where else to look. Thanks in advance Anthony Anthony Desmarais, Team Leader: Software Platforms Altech Multimedia International (Pty) Ltd, Registration 1984/003805/07 PO Box 54, Mount Edgecombe, 4300, South Africa UEC House, 1 Montgomery Drive, Mount Edgecombe, South Africa +27 (0) 31 508 2710 (direct) +27 (0) 31 539 5258 (fax) +27 (0) 83 390 1706 (mobile) anthony.desmarais at altech-multimedia.com www.altech-multimedia.com [SA Technology Top 100] ________________________________ E-Mail Disclaimer: www.altron.co.za/email.asp Should you have any questions regarding this e-mail legal notice please contact us on 1. Telephone number : +27315082800 2. Fax number : +2731539 3370 3. E-mail address: info at altech-multimedia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 1 03:57:48 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Dec 2014 19:57:48 +0800 Subject: [Live-devel] Breakup with mips port In-Reply-To: <4FDE12B084FA334AB4A6B9E681B4FAB414749244@amizaex01.uectech.net> References: <4FDE12B084FA334AB4A6B9E681B4FAB414749244@amizaex01.uectech.net> Message-ID: <542847B7-B38E-431B-B906-381D60909646@live555.com> > Using the test transport stream from the live555 website ?bipbop-gear1-all.ts? I ran the program testMPEG2TransportStreamer > Using a windows VLC client I could not play the file back I presume you mean "could not play the *stream* back". That's odd. Are you using a recent version of VLC? Do you have IP multicast connectivity between the server and the client (VLC) computer? Could your Windows firewall be blocking the multicast packets?? > I get the same picture breakup so I am now confident that the losses are somewhere in the live555 framework No. See , and note, in particular, the last paragraph. Packet loss is usually seen in LIVE555-based *receivers* (and, as noted in the FAQ entry, is usually caused by insufficient buffering in the receiver's OS). It's unusual to see systematic packet loss (independent of the receiver(s)) occurring with LIVE555-based *servers*, unless the output stream is exceeding the capacity of your network. But because "bipbop-gear1-all.ts" is such a low-bitrate stream, it's unlikely that network capacity is the problem here. I suspect either: 1/ A systematic problem with your server (OS)'s network interface and/or multicast implementation that is causing this packet loss, or 2/ If you have a router sitting between your server and client(s), a systematic problem with how it implements multicast forwarding, or 3/ Some weird MIPS-related problem in how your server is running our code. I would try the following: - Run the same server application ("testMPEG2TransportStreamer") using the same file(s), but running on some other architecture (e.g., Linux/Intel, or Mac OS). - Run the "LIVE555 Media Server" or "testOnDemandRTSPServer" demo application, which streams via unicast, rather than multicast. Both of these should help you narrow down the problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.Desmarais at altech-multimedia.com Mon Dec 1 04:10:09 2014 From: Anthony.Desmarais at altech-multimedia.com (Anthony Desmarais) Date: Mon, 1 Dec 2014 12:10:09 +0000 Subject: [Live-devel] Breakup with mips port In-Reply-To: <542847B7-B38E-431B-B906-381D60909646@live555.com> References: <4FDE12B084FA334AB4A6B9E681B4FAB414749244@amizaex01.uectech.net> <542847B7-B38E-431B-B906-381D60909646@live555.com> Message-ID: <4FDE12B084FA334AB4A6B9E681B4FAB4147494A2@amizaex01.uectech.net> Thanks for the feedback Ross, Sorry it it came across that I may be blaming the server for packet loss, this was not my intention, rather I was thinking that somewhere in the cross compilation there is packet corruption rather than packet loss. In my original request I said that I redirected the output from the network to the disk, this was on the server side and was done in OutputSocket::write function so that the exact data that was being sent to the network was being spooled to the disk, in the resulting file I still get video breakup however after reviewing this I suspect that the write function?s receive pointer will include rtp headers which means the resulting file is not a ts file, I would need to perform this test higher up the chain I suspect. With regard to VLC, I now am receiving the rtp stream via VLC ? I was using my development PC which has multiple network interfaces on it and I think VLC was listening on the incorrect IF. I got a dedicated PC with a single network IF and this is receiving the files but with the same video loss. Also with regard to our embedded systems network subsystem, we have DLNA deployed so the network is functional but I may have issues with multicast, I guess my next test is to try a unicast transmission. Thanks Anthony From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 01 December 2014 01:58 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Breakup with mips port Using the test transport stream from the live555 website ?bipbop-gear1-all.ts? I ran the program testMPEG2TransportStreamer Using a windows VLC client I could not play the file back I presume you mean "could not play the *stream* back". That's odd. Are you using a recent version of VLC? Do you have IP multicast connectivity between the server and the client (VLC) computer? Could your Windows firewall be blocking the multicast packets?? I get the same picture breakup so I am now confident that the losses are somewhere in the live555 framework No. See , and note, in particular, the last paragraph. Packet loss is usually seen in LIVE555-based *receivers* (and, as noted in the FAQ entry, is usually caused by insufficient buffering in the receiver's OS). It's unusual to see systematic packet loss (independent of the receiver(s)) occurring with LIVE555-based *servers*, unless the output stream is exceeding the capacity of your network. But because "bipbop-gear1-all.ts" is such a low-bitrate stream, it's unlikely that network capacity is the problem here. I suspect either: 1/ A systematic problem with your server (OS)'s network interface and/or multicast implementation that is causing this packet loss, or 2/ If you have a router sitting between your server and client(s), a systematic problem with how it implements multicast forwarding, or 3/ Some weird MIPS-related problem in how your server is running our code. I would try the following: - Run the same server application ("testMPEG2TransportStreamer") using the same file(s), but running on some other architecture (e.g., Linux/Intel, or Mac OS). - Run the "LIVE555 Media Server" or "testOnDemandRTSPServer" demo application, which streams via unicast, rather than multicast. Both of these should help you narrow down the problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.Desmarais at altech-multimedia.com Mon Dec 1 04:37:16 2014 From: Anthony.Desmarais at altech-multimedia.com (Anthony Desmarais) Date: Mon, 1 Dec 2014 12:37:16 +0000 Subject: [Live-devel] Breakup with mips port In-Reply-To: <542847B7-B38E-431B-B906-381D60909646@live555.com> References: <4FDE12B084FA334AB4A6B9E681B4FAB414749244@amizaex01.uectech.net> <542847B7-B38E-431B-B906-381D60909646@live555.com> Message-ID: <4FDE12B084FA334AB4A6B9E681B4FAB414749577@amizaex01.uectech.net> Ross, On our system I ran the testOnDemandRTSPServer and then pointed VLC to rtsp://10.0.0.5:8554/mpeg2TransportStreamTest ? this worked flawlessly even with the high bitrate video file. In your experience does this point to the Live555 framework working 100%? From what I see this pretty much follows the exact same software flow as multicast would with the expection being that the address is not a multicast address. DO you agree with this statement? If so then I think I need to look at my kernel perhaps something here is not correct. Thanks Anthony From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 01 December 2014 01:58 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Breakup with mips port Using the test transport stream from the live555 website ?bipbop-gear1-all.ts? I ran the program testMPEG2TransportStreamer Using a windows VLC client I could not play the file back I presume you mean "could not play the *stream* back". That's odd. Are you using a recent version of VLC? Do you have IP multicast connectivity between the server and the client (VLC) computer? Could your Windows firewall be blocking the multicast packets?? I get the same picture breakup so I am now confident that the losses are somewhere in the live555 framework No. See , and note, in particular, the last paragraph. Packet loss is usually seen in LIVE555-based *receivers* (and, as noted in the FAQ entry, is usually caused by insufficient buffering in the receiver's OS). It's unusual to see systematic packet loss (independent of the receiver(s)) occurring with LIVE555-based *servers*, unless the output stream is exceeding the capacity of your network. But because "bipbop-gear1-all.ts" is such a low-bitrate stream, it's unlikely that network capacity is the problem here. I suspect either: 1/ A systematic problem with your server (OS)'s network interface and/or multicast implementation that is causing this packet loss, or 2/ If you have a router sitting between your server and client(s), a systematic problem with how it implements multicast forwarding, or 3/ Some weird MIPS-related problem in how your server is running our code. I would try the following: - Run the same server application ("testMPEG2TransportStreamer") using the same file(s), but running on some other architecture (e.g., Linux/Intel, or Mac OS). - Run the "LIVE555 Media Server" or "testOnDemandRTSPServer" demo application, which streams via unicast, rather than multicast. Both of these should help you narrow down the problem. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 1 10:58:37 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Dec 2014 02:58:37 +0800 Subject: [Live-devel] Breakup with mips port In-Reply-To: <4FDE12B084FA334AB4A6B9E681B4FAB414749577@amizaex01.uectech.net> References: <4FDE12B084FA334AB4A6B9E681B4FAB414749244@amizaex01.uectech.net> <542847B7-B38E-431B-B906-381D60909646@live555.com> <4FDE12B084FA334AB4A6B9E681B4FAB414749577@amizaex01.uectech.net> Message-ID: <86236191-DD23-4823-8F20-096C02B291A2@live555.com> > On our system I ran the testOnDemandRTSPServer and then pointed VLC to rtsp://10.0.0.5:8554/mpeg2TransportStreamTest ? this worked flawlessly even with the high bitrate video file. > > In your experience does this point to the Live555 framework working 100%? Yes. > From what I see this pretty much follows the exact same software flow as multicast would with the expection being that the address is not a multicast address. DO you agree with this statement? Yes. > If so then I think I need to look at my kernel perhaps something here is not correct. Yes, you seem to have a problem with multicast on this system. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From markb at virtualguard.com Mon Dec 1 10:06:12 2014 From: markb at virtualguard.com (Mark Bondurant) Date: Mon, 1 Dec 2014 18:06:12 +0000 Subject: [Live-devel] Playback Speed In-Reply-To: References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> Message-ID: <511dae4b019346639abdc1fa26dfcf15@VGI-EX1.vg.local> Back from Thanksgiving. I'm playing them VLC Player. I notice that when I play them, it doesn't fill in the little length numbers on the right. I should also note that I'm using the extension ".h264", which VLC seems to recognize. I updated VLC, but it didn't help. From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeff Shanab Sent: Wednesday, November 26, 2014 5:57 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Playback Speed How are you playing the file? The container format you use is in charge of maintaining the timing information and the player you use or write uses the stored timestamps to gate out the frames. Double speed is ominous though. Could it be that you have interleaved frames? If it is AVI, then the creation code was passed the wrong numerator? or denominator? On Tue, Nov 25, 2014 at 12:22 PM, Mark Bondurant > wrote: I'm encountering a curious problem with payback speed. I'm pulling an RTSP play stream from my cameras, copying the NAL's, prepending them with the start code, as contiguous GOP units straight to disk, headers and all. And they play fine. Just at double speed. The camera is set to NTSC/H264/CIF/12 fps/Constant Bit Rate/0.125 Mbps. Any ideas what I'm doing wrong? _______________________________________________ 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 markb at virtualguard.com Mon Dec 1 10:10:31 2014 From: markb at virtualguard.com (Mark Bondurant) Date: Mon, 1 Dec 2014 18:10:31 +0000 Subject: [Live-devel] Playback Speed In-Reply-To: <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> Message-ID: Oh. I didn't know that. I assumed it had to be part of the h264 headers (one or the other). Is there any way, that's comprehensible to my newb video skillset, to add that to my filesink, as in perhaps an example in one of the test programs? From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Deanna Earley Sent: Thursday, November 27, 2014 1:07 AM To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Playback Speed Play in what? Raw H.264 streams have no ?speed? encoded with them, so you?d need to find a way to specify that in your player, or use a container (like AVI, mp4, etc) that stores the extra metadata. The player is probably assuming a 25fps. -- 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 Mark Bondurant Sent: 25 November 2014 17:23 To: 'LIVE555 Streaming Media - development & use' Subject: [Live-devel] Playback Speed I'm encountering a curious problem with payback speed. I'm pulling an RTSP play stream from my cameras, copying the NAL's, prepending them with the start code, as contiguous GOP units straight to disk, headers and all. And they play fine. Just at double speed. The camera is set to NTSC/H264/CIF/12 fps/Constant Bit Rate/0.125 Mbps. Any ideas what I'm doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 1 11:25:20 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Dec 2014 03:25:20 +0800 Subject: [Live-devel] Playback Speed In-Reply-To: <511dae4b019346639abdc1fa26dfcf15@VGI-EX1.vg.local> References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <511dae4b019346639abdc1fa26dfcf15@VGI-EX1.vg.local> Message-ID: <06B67635-6B5A-4C54-B193-487EADDFC336@live555.com> > I'm playing them VLC Player. I notice that when I play them, it doesn't fill in the little length numbers on the right. I should also note that I'm using the extension ".h264", which VLC seems to recognize. I updated VLC, but it didn't help. This has nothing to do with our software! Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anthony.Desmarais at altech-multimedia.com Mon Dec 1 22:48:34 2014 From: Anthony.Desmarais at altech-multimedia.com (Anthony Desmarais) Date: Tue, 2 Dec 2014 06:48:34 +0000 Subject: [Live-devel] Breakup with mips port In-Reply-To: <86236191-DD23-4823-8F20-096C02B291A2@live555.com> References: <4FDE12B084FA334AB4A6B9E681B4FAB414749244@amizaex01.uectech.net> <542847B7-B38E-431B-B906-381D60909646@live555.com> <4FDE12B084FA334AB4A6B9E681B4FAB414749577@amizaex01.uectech.net> <86236191-DD23-4823-8F20-096C02B291A2@live555.com> Message-ID: <4FDE12B084FA334AB4A6B9E681B4FAB414749DB8@amizaex01.uectech.net> Thanks for the help Ross. From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: 01 December 2014 08:59 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Breakup with mips port On our system I ran the testOnDemandRTSPServer and then pointed VLC to rtsp://10.0.0.5:8554/mpeg2TransportStreamTest ? this worked flawlessly even with the high bitrate video file. In your experience does this point to the Live555 framework working 100%? Yes. From what I see this pretty much follows the exact same software flow as multicast would with the expection being that the address is not a multicast address. DO you agree with this statement? Yes. If so then I think I need to look at my kernel perhaps something here is not correct. Yes, you seem to have a problem with multicast on this system. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dee.earley at icode.co.uk Tue Dec 2 01:13:51 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Tue, 2 Dec 2014 09:13:51 +0000 Subject: [Live-devel] Playback Speed In-Reply-To: References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> Message-ID: <3b1498a0681a4427b411d3d5817318f7@SRV-EXCHANGE-2.icode.co.uk> H.264 is a video frame encoding format. It has no concept of time. You need to write out as one of the standard file containers to make a standard file. I think LiveMedia has sinks for various types like Matroska and MP4. This will give you the metadata like format, length, framerate, resolution, etc. -- 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 Mark Bondurant Sent: 01 December 2014 18:11 To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Playback Speed Oh. I didn't know that. I assumed it had to be part of the h264 headers (one or the other). Is there any way, that's comprehensible to my newb video skillset, to add that to my filesink, as in perhaps an example in one of the test programs? From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Deanna Earley Sent: Thursday, November 27, 2014 1:07 AM To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Playback Speed Play in what? Raw H.264 streams have no ?speed? encoded with them, so you?d need to find a way to specify that in your player, or use a container (like AVI, mp4, etc) that stores the extra metadata. The player is probably assuming a 25fps. -- 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 Mark Bondurant Sent: 25 November 2014 17:23 To: 'LIVE555 Streaming Media - development & use' Subject: [Live-devel] Playback Speed I'm encountering a curious problem with payback speed. I'm pulling an RTSP play stream from my cameras, copying the NAL's, prepending them with the start code, as contiguous GOP units straight to disk, headers and all. And they play fine. Just at double speed. The camera is set to NTSC/H264/CIF/12 fps/Constant Bit Rate/0.125 Mbps. Any ideas what I'm doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Thu Dec 4 11:04:29 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Thu, 4 Dec 2014 20:04:29 +0100 Subject: [Live-devel] Playback Speed In-Reply-To: <3b1498a0681a4427b411d3d5817318f7@SRV-EXCHANGE-2.icode.co.uk> References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> <3b1498a0681a4427b411d3d5817318f7@SRV-EXCHANGE-2.icode.co.uk> Message-ID: <28883_1417719874_5480B041_28883_13094_1_1BE8971B6CFF3A4F97AF4011882AA25501565C1709B9@THSONEA01CMS01P.one.grp> In an H264 elementary stream, the framerate could be defined in the SPS, but this is an optional field (see ISO 14496-10). Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel [mailto:live-devel-bounces at ns.live555.com] De la part de Deanna Earley Envoy? : mardi 2 d?cembre 2014 10:14 ? : 'LIVE555 Streaming Media - development & use' Objet : Re: [Live-devel] Playback Speed H.264 is a video frame encoding format. It has no concept of time. You need to write out as one of the standard file containers to make a standard file. I think LiveMedia has sinks for various types like Matroska and MP4. This will give you the metadata like format, length, framerate, resolution, etc. -- 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 Mark Bondurant Sent: 01 December 2014 18:11 To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Playback Speed Oh. I didn't know that. I assumed it had to be part of the h264 headers (one or the other). Is there any way, that's comprehensible to my newb video skillset, to add that to my filesink, as in perhaps an example in one of the test programs? From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Deanna Earley Sent: Thursday, November 27, 2014 1:07 AM To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Playback Speed Play in what? Raw H.264 streams have no ?speed? encoded with them, so you?d need to find a way to specify that in your player, or use a container (like AVI, mp4, etc) that stores the extra metadata. The player is probably assuming a 25fps. -- 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 Mark Bondurant Sent: 25 November 2014 17:23 To: 'LIVE555 Streaming Media - development & use' Subject: [Live-devel] Playback Speed I'm encountering a curious problem with payback speed. I'm pulling an RTSP play stream from my cameras, copying the NAL's, prepending them with the start code, as contiguous GOP units straight to disk, headers and all. And they play fine. Just at double speed. The camera is set to NTSC/H264/CIF/12 fps/Constant Bit Rate/0.125 Mbps. Any ideas what I'm doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From markb at virtualguard.com Thu Dec 4 13:12:28 2014 From: markb at virtualguard.com (Mark Bondurant) Date: Thu, 4 Dec 2014 21:12:28 +0000 Subject: [Live-devel] Playback Speed In-Reply-To: <28883_1417719874_5480B041_28883_13094_1_1BE8971B6CFF3A4F97AF4011882AA25501565C1709B9@THSONEA01CMS01P.one.grp> References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> <3b1498a0681a4427b411d3d5817318f7@SRV-EXCHANGE-2.icode.co.uk> <28883_1417719874_5480B041_28883_13094_1_1BE8971B6CFF3A4F97AF4011882AA25501565C1709B9@THSONEA01CMS01P.one.grp> Message-ID: <90921a3d59f94102b21b47fdb397d5ba@VGI-EX1.vg.local> I suppose I could intercept the SPS headers and substitute my own, but looking in the spec, I see no field specifying fps. It doesn't seem to me to be in the spirit of the thing being as everything is so variable. GOP's can cover two seconds or half a second. Slices are very arbitrary. I discovered that the frame rate doesn't seem to really matter to the size of the clips I produce, which makes sense. The reference frame is the big space hog. I set the camera to 30fps, it's max with H264, and VLC Player seemed happy with that. It makes for nice smooth playbacks. From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of PROMONET Michel Sent: Thursday, December 04, 2014 11:04 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Playback Speed In an H264 elementary stream, the framerate could be defined in the SPS, but this is an optional field (see ISO 14496-10). Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel [mailto:live-devel-bounces at ns.live555.com] De la part de Deanna Earley Envoy? : mardi 2 d?cembre 2014 10:14 ? : 'LIVE555 Streaming Media - development & use' Objet : Re: [Live-devel] Playback Speed H.264 is a video frame encoding format. It has no concept of time. You need to write out as one of the standard file containers to make a standard file. I think LiveMedia has sinks for various types like Matroska and MP4. This will give you the metadata like format, length, framerate, resolution, etc. -- 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 Mark Bondurant Sent: 01 December 2014 18:11 To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Playback Speed Oh. I didn't know that. I assumed it had to be part of the h264 headers (one or the other). Is there any way, that's comprehensible to my newb video skillset, to add that to my filesink, as in perhaps an example in one of the test programs? From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Deanna Earley Sent: Thursday, November 27, 2014 1:07 AM To: 'LIVE555 Streaming Media - development & use' Subject: Re: [Live-devel] Playback Speed Play in what? Raw H.264 streams have no ?speed? encoded with them, so you?d need to find a way to specify that in your player, or use a container (like AVI, mp4, etc) that stores the extra metadata. The player is probably assuming a 25fps. -- 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 Mark Bondurant Sent: 25 November 2014 17:23 To: 'LIVE555 Streaming Media - development & use' Subject: [Live-devel] Playback Speed I'm encountering a curious problem with payback speed. I'm pulling an RTSP play stream from my cameras, copying the NAL's, prepending them with the start code, as contiguous GOP units straight to disk, headers and all. And they play fine. Just at double speed. The camera is set to NTSC/H264/CIF/12 fps/Constant Bit Rate/0.125 Mbps. Any ideas what I'm doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at gotowti.com Thu Dec 4 15:28:49 2014 From: chris at gotowti.com (Chris Richardson (WTI)) Date: Thu, 4 Dec 2014 15:28:49 -0800 Subject: [Live-devel] Playback Speed In-Reply-To: <90921a3d59f94102b21b47fdb397d5ba@VGI-EX1.vg.local> References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> <3b1498a0681a4427b411d3d5817318f7@SRV-EXCHANGE-2.icode.co.uk> <28883_1417719874_5480B041_28883_13094_1_1BE8971B6CFF3A4F97AF4011882AA25501565C1709B9@THSONEA01CMS01P.one.grp> <90921a3d59f94102b21b47fdb397d5ba@VGI-EX1.vg.local> Message-ID: <001701d0101a$0fe78690$2fb693b0$@com> Hi, From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Mark Bondurant >I suppose I could intercept the SPS headers and substitute my own, but looking in the spec, >I see no field specifying fps. It doesn't seem to me to be in the spirit of the thing being >as everything is so variable. GOP's can cover two seconds or half a second. Slices are very >arbitrary. Just FYI, the timing parameters Michel mentioned are in the VUI data inside the SPS. Section E.1.1 VUI parameters syntax: timing_info_present_flag 0 u(1) if( timing_info_present_flag ) { num_units_in_tick 0 u(32) time_scale 0 u(32) fixed_frame_rate_flag 0 u(1) } Chris Richardson WTI From finlayson at live555.com Thu Dec 4 15:32:40 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Dec 2014 07:32:40 +0800 Subject: [Live-devel] Playback Speed In-Reply-To: <90921a3d59f94102b21b47fdb397d5ba@VGI-EX1.vg.local> References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> <3b1498a0681a4427b411d3d5817318f7@SRV-EXCHANGE-2.icode.co.uk> <28883_1417719874_5480B041_28883_13094_1_1BE8971B6CFF3A4F97AF4011882AA25501565C1709B9@THSONEA01CMS01P.one.grp> <90921a3d59f94102b21b47fdb397d5ba@VGI-EX1.vg.local> Message-ID: <24A0A017-8E7F-417E-90CA-4A88DB8F9E1E@live555.com> > I suppose I could intercept the SPS headers and substitute my own, but looking in the spec, I see no field specifying fps. The SPS (optionally) contains "time_scale" and "num_units_in_tick" fields, from which a frame rate can be inferred: frame_rate = time_scale/(2.0*num_units_in_tick) FWIW, the LIVE555 code uses this information when it streams (i.e., transmits) H.264 video files. It parses the SPS, trying to find these two fields (and thus the frame rate). If these fields are not present, then our code assumes a frame rate of 25 fps. (If you're interested, you can see this in "liveMedia/H264or5VideoStreamFramer.cpp".) VLC presumably does something similar when it tries to play such a file (if it has filename suffix ".h264"). (But this is not a VLC mailing list, so questions about VLC belong elsewhere.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Fri Dec 5 00:07:40 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Fri, 5 Dec 2014 09:07:40 +0100 Subject: [Live-devel] Playback Speed In-Reply-To: <24A0A017-8E7F-417E-90CA-4A88DB8F9E1E@live555.com> References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> <3b1498a0681a4427b411d3d5817318f7@SRV-EXCHANGE-2.icode.co.uk> <28883_1417719874_5480B041_28883_13094_1_1BE8971B6CFF3A4F97AF4011882AA25501565C1709B9@THSONEA01CMS01P.one.grp> <90921a3d59f94102b21b47fdb397d5ba@VGI-EX1.vg.local> <24A0A017-8E7F-417E-90CA-4A88DB8F9E1E@live555.com> Message-ID: <22047_1417766862_548167CD_22047_57_2_1BE8971B6CFF3A4F97AF4011882AA25501565C1E6476@THSONEA01CMS01P.one.grp> Hi Ross, I am afraid that the computation is a bit more complex in the ISO (see http://www.staroceans.org.s3-website-us-east-1.amazonaws.com/e-book/ISO-14496-10.pdf) Divisor is not always 2, it could be 1, 2, 3,4 or 6. For instance, when divisor is 1 live555MediaServer playback a recorded stream twice slower. Just to give a quick answer about VLC, the last time I tried, it still use an default framerate of 25fps and this could be override using -h264-fps argument. Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : vendredi 5 d?cembre 2014 00:33 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Playback Speed I suppose I could intercept the SPS headers and substitute my own, but looking in the spec, I see no field specifying fps. The SPS (optionally) contains "time_scale" and "num_units_in_tick" fields, from which a frame rate can be inferred: frame_rate = time_scale/(2.0*num_units_in_tick) FWIW, the LIVE555 code uses this information when it streams (i.e., transmits) H.264 video files. It parses the SPS, trying to find these two fields (and thus the frame rate). If these fields are not present, then our code assumes a frame rate of 25 fps. (If you're interested, you can see this in "liveMedia/H264or5VideoStreamFramer.cpp".) VLC presumably does something similar when it tries to play such a file (if it has filename suffix ".h264"). (But this is not a VLC mailing list, so questions about VLC belong elsewhere.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shubham.argie at gmail.com Sun Dec 7 20:15:27 2014 From: shubham.argie at gmail.com (Shubham Goyal) Date: Mon, 8 Dec 2014 12:15:27 +0800 Subject: [Live-devel] H264 live streaming Message-ID: Hi all I am currently working with testOnDemandRTSPServer to stream a H264 file. I would like to instead create a server that will continuously stream a live input, instead of streaming a file. Please suggest on how should I proceed as I feel very clueless at this point. My input would be a buffer of H264 encoded screen grabs captured using the Nvidia GRID SDK. Thanks, Shubham From kenchow.cn at gmail.com Mon Dec 8 03:04:12 2014 From: kenchow.cn at gmail.com (ken chow) Date: Mon, 8 Dec 2014 19:04:12 +0800 Subject: [Live-devel] hi all, I found a bug in mediaServer source code. Message-ID: sorry, I don't know how to report a bug in a proper way, but I saw the only one mailing list can communicate with authors. here is the thing. >From my client PLAY request like this: 
PLAY rtsp://
192.168.1.201:556/20141208-064059100-Talon0001-192.168.1.201-Cam0.avi
RTSP/1.0
Authorization: Digest username="admin", realm="LIVE555 Streaming Media",
nonce="fc0667548cd2dff1882b8a9550854fad", uri="/rtsp://
192.168.1.201:556/20141208-064059100-Talon0001-192.168.1.201-Cam0.avi",
response="b203600cffa9ec487011edc4a92b1ce5"
CSeq: 6
User-Agent: ORCI RTSP Client 1.0
Rate-Control: yes
Range: clock=20141208T064100.000Z-
Session: 81A6879B
I met the problem that is *Range* field, my client didn't fill end time, which means playing from 20141208T064100.000Z to end of file. This is implementing in file: RTSPCommon.cpp line: 248 code: 
  } else if (sscanf(paramStr, "clock = %n", &numCharsMatched3) == 0 &&
numCharsMatched3 > 0) {
    rangeStart = rangeEnd = 0.0;

    char const* utcTimes = ¶mStr[numCharsMatched3];
    size_t len = strlen(utcTimes) + 1;
    char* as = new char[len];
    char* ae = new char[len];
    int sscanfResult = sscanf(utcTimes, "%[^-]-%s", as, ae);
/*********************line248*********************************/
    if (sscanfResult == 2) {
      absStartTime = as;
      absEndTime = ae;
    } else if (sscanfResult == 1) {
      absStartTime = as;
      delete[] ae;
    } else {
      delete[] as; delete[] ae;
      return False;
    }
  } else if (sscanf(paramStr, "smtpe = %n", &numCharsMatched4) == 0 &&
numCharsMatched4 > 0) {
?
? If the range like the above that I'v offered, the sscanf(utcTimes, "%[^-]-%s", as, ae) will have a problem. Another thing: file: RTSPServer.cpp line: 2002 code: 
  for (i = 0; i < fNumStreamStates; ++i) {
    if (subsession == NULL /* means: aggregated operation */ ||
fNumStreamStates == 1) {
      if (fStreamStates[i].subsession != NULL) {
if (sawScaleHeader) {
  fStreamStates[i].subsession->setStreamScale(fOurSessionId,
fStreamStates[i].streamToken, scale);
}
if (absStart != NULL) {  /******************line
2002***************************************************/
  // Special case handling for seeking by 'absolute' time:
  fStreamStates[i].subsession->seekStream(fOurSessionId,
fStreamStates[i].streamToken, absStart, absEnd);
} else {
  // Seeking by relative (NPT) time:

  u_int64_t numBytes;
  if (!sawRangeHeader || startTimeIsNow) {
    // We're resuming streaming without seeking, so we just do a 'null' seek
    // (to get our NPT, and to specify when to end streaming):
    fStreamStates[i].subsession->nullSeekStream(fOurSessionId,
fStreamStates[i].streamToken,
rangeEnd, numBytes);
  } else {
    // We do a real 'seek':
    double streamDuration = 0.0; // by default; means: stream until the end
of the media
    if (rangeEnd > 0.0 && (rangeEnd+0.001) < duration) {
      // the 0.001 is because we limited the values to 3 decimal places
      // We want the stream to end early.  Set the duration we want:
      streamDuration = rangeEnd - rangeStart;
      if (streamDuration < 0.0) streamDuration = -streamDuration;
          // should happen only if scale < 0.0
    }
    fStreamStates[i].subsession->seekStream(fOurSessionId,
fStreamStates[i].streamToken,
    rangeStart, streamDuration, numBytes);
  }
}
That if condition should have included NULL != absEnd. Then, my client works well with mediaServer, Please see the attachment that I modified two files, if the modifying inappropriate, I wish someone would tell me. Thank you. Ken Chow about.me/kenchowcn [image: Ken Chow on about.me] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTSPServer.cpp Type: text/x-c++src Size: 97227 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RTSPCommon.cpp Type: text/x-c++src Size: 13483 bytes Desc: not available URL: From dee.earley at icode.co.uk Mon Dec 8 05:16:41 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Mon, 8 Dec 2014 13:16:41 +0000 Subject: [Live-devel] H264 live streaming In-Reply-To: References: Message-ID: > I am currently working with testOnDemandRTSPServer to stream a H264 file. > I would like to instead create a server that will continuously stream a > live input, instead of streaming a file. Please suggest on how should I > proceed as I feel very clueless at this point. My input would be a buffer > of H264 encoded screen grabs captured using the Nvidia GRID SDK. "The "test*Streamer" test programs read from a file. Can I modify them so that they take input from a H.264, H.265, or MPEG encoder instead, so I can stream live (rather than prerecorded) video and/or audio?" http://www.live555.com/liveMedia/faq.html#liveInput -- 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 finlayson at live555.com Mon Dec 8 05:20:37 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Dec 2014 02:20:37 +1300 Subject: [Live-devel] H264 live streaming In-Reply-To: References: Message-ID: > I am currently working with testOnDemandRTSPServer to stream a H264 file. I would like to instead create a server that will continuously stream a live input, instead of streaming a file. Please suggest on how should I proceed This is all explained in the FAQ that everyone is asked to read before posting to this mailing list. Specifically: http://www.live555.com/liveMedia/faq.html#liveInput and 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 finlayson at live555.com Mon Dec 8 06:19:13 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Dec 2014 03:19:13 +1300 Subject: [Live-devel] hi all, I found a bug in mediaServer source code. In-Reply-To: References: Message-ID: <79F26890-64A0-407F-A859-5B5EFA6573E2@live555.com> > Please see the attachment that I modified two files I?m puzzled that in both of the files that you attached, the copyright notice says Copyright (c) 1996-2011 yet support for seeking by absolute time was added in 2012. This suggests that you are using modified source files, rather than the unmodified, latest source files from http://www.live555.com/liveMedia/public - the only version of the code that we support. > From my client PLAY request like this: [?] > If the range like the above that I'v offered, the sscanf(utcTimes, "%[^-]-%s", as, ae) will have a problem. No it won?t have a problem. In this case, the ?sscanf()? call will return 1, which means that the code will set the variable ?absStartTime?, but not the variable ?absEndTime?, which means that ?absEndTime? will be left at its default value of NULL - which means: No end time. Note that your implementation of the seekStreamSource(FramedSource* inputSource, char*& absStart, char*& absEnd) virtual function (in your subclass of ?OnDemandServerMediaSubsession?) needs to allow for the possibility of the ?absEnd? parameter being NULL. > Another thing: > > file: RTSPServer.cpp line: 2002 code: [?] > if (absStart != NULL) { /******************line 2002***************************************************/ No, that should be line 1951, not line 2002. You are using an old (or modified) version of the code. We do not support this! > That if condition should have included NULL != absEnd. No, the existing condition is correct. Once again, your implementation of the ?seekStreamSource()? virtual function needs to allow for the possibility of the ?absEnd? parameter being NULL. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenchow.cn at gmail.com Mon Dec 8 07:38:17 2014 From: kenchow.cn at gmail.com (ken chow) Date: Mon, 8 Dec 2014 23:38:17 +0800 Subject: [Live-devel] hi all, I found a bug in mediaServer source code. In-Reply-To: <79F26890-64A0-407F-A859-5B5EFA6573E2@live555.com> References: <79F26890-64A0-407F-A859-5B5EFA6573E2@live555.com> Message-ID: sorry about that copyright time, we should have updated. but my point is if utcTimes is "20141208T064100.000Z-\r\nSession: 81A6879B\r\n", then the sscanf will parse that not we want, please see the sample at the below. if you're pretty sure that live555-latest.tar.gz is right, then I'm so sorry for bothering you. Range: clock=20141208T064100.000Z- Session: 81A6879B In this case: int sscanfResult = sscanf(utcTimes, "%[^-]-%s", as, ae); when I printf sscanfResult which is actually "2" when I printf as which is "20141208T064100.000Z" when I printf ae which is actually "Session:" 
kenchow at ubuntu:~/Documents$ cat sscanf.c
#include
#include

int main()
{
char *utcTimes = "20141208T064100.000Z-\r\nSession: 81A6879B";
char as[50]={0}, ae[50]={0};
int sscanfResult = sscanf(utcTimes, "%[^-]-%s", as, ae);

printf("%d\n", sscanfResult);
printf("%s\n", as);
printf("%s\n", ae);

return 0;
}

kenchow at ubuntu:~/Documents$ ./sscanf
2
20141208T064100.000Z
Session:
kenchow at ubuntu:~/Documents$
Ken Chow about.me/kenchowcn [image: Ken Chow on about.me] On Mon, Dec 8, 2014 at 10:19 PM, Ross Finlayson wrote: > > Please see the attachment that I modified two files > > > I?m puzzled that in both of the files that you attached, the copyright > notice says > Copyright (c) 1996-2011 > yet support for seeking by absolute time was added in 2012. This suggests > that you are using modified source files, rather than the unmodified, > latest source files from http://www.live555.com/liveMedia/public - the > only version of the code that we support. > > > From my client PLAY request like this: > > [?] > > If the range like the above that I'v offered, the sscanf(utcTimes, > "%[^-]-%s", as, ae) will have a problem. > > > No it won?t have a problem. In this case, the ?sscanf()? call will return > 1, which means that the code will set the variable ?absStartTime?, but not > the variable ?absEndTime?, which means that ?absEndTime? will be left at > its default value of NULL - which means: No end time. > > Note that your implementation of the > seekStreamSource(FramedSource* inputSource, char*& absStart, char*& absEnd) > virtual function (in your subclass of ?OnDemandServerMediaSubsession?) > needs to allow for the possibility of the ?absEnd? parameter being NULL. > > > Another thing: > > file: RTSPServer.cpp line: 2002 code: > > [?] > > if (absStart != NULL) { /******************line > 2002***************************************************/ > > > No, that should be line 1951, not line 2002. You are using an old (or > modified) version of the code. We do not support this! > > > That if condition should have included NULL != absEnd. > > > No, the existing condition is correct. Once again, your implementation of > the ?seekStreamSource()? virtual function needs to allow for the > possibility of the ?absEnd? parameter being NULL. > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 8 08:50:49 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Dec 2014 05:50:49 +1300 Subject: [Live-devel] hi all, I found a bug in mediaServer source code. In-Reply-To: References: <79F26890-64A0-407F-A859-5B5EFA6573E2@live555.com> Message-ID: > my point is if utcTimes is "20141208T064100.000Z-\r\nSession: 81A6879B\r\n", then the sscanf will parse that not we want Yes, you?re right - this was a bug. I?ve just installed a new version - 2014.12.08 - of the ?LIVE555 Streaming Media? code that should fix this. Thanks for the report. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 8 18:17:54 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Dec 2014 15:17:54 +1300 Subject: [Live-devel] Playback Speed In-Reply-To: <22047_1417766862_548167CD_22047_57_2_1BE8971B6CFF3A4F97AF4011882AA25501565C1E6476@THSONEA01CMS01P.one.grp> References: <6555ad5ce84f48d189928894094ae3e1@VGI-EX1.vg.local> <708eef3d62f641b7ac0cbbbd8a3a74b6@VGI-EX1.vg.local> <782e1b3f8cbe4209ae3831669d1f7fe5@VGI-EX1.vg.local> <1bb41c8a63c14a2d968f0c98e74f0519@VGI-EX1.vg.local> <00115A6A-D5E6-43BB-94B4-1523AD4046D1@live555.com> <0ad348a0997b4056a2b3ee87a9c12656@VGI-EX1.vg.local> <1b073030c41c429d82d55d79cd3864b7@SRV-EXCHANGE-2.icode.co.uk> <3b1498a0681a4427b411d3d5817318f7@SRV-EXCHANGE-2.icode.co.uk> <28883_1417719874_5480B041_28883_13094_1_1BE8971B6CFF3A4F97AF4011882AA25501565C1709B9@THSONEA01CMS01P.one.grp> <90921a3d59f94102b21b47fdb397d5ba@VGI-EX1.vg.local> <24A0A017-8E7F-417E-90CA-4A88DB8F9E1E@live555.com> <22047_1417766862_548167CD_22047_57_2_1BE8971B6CFF3A4F97AF4011882AA25501565C1E6476@THSONEA01CMS01P.one.grp> Message-ID: <396AB673-2A9F-44C9-979A-178EACCC6DFC@live555.com> > I am afraid that the computation is a bit more complex in the ISO (see http://www.staroceans.org.s3-website-us-east-1.amazonaws.com/e-book/ISO-14496-10.pdf ) > Divisor is not always 2, it could be 1, 2, 3,4 or 6. Is this the ?DeltaTfiDivisor? defined in the table on page 263 of that specification? I find that rather hard to follow, considering (for example) that the variable ?tfi,dpb( n ) seems to be defined in two separate ways, just sentences apart: When fixed_frame_rate_flag is equal to 1, for all n where n indicates the n-th picture in output order and picture n is not the last picture in the bitstream in output order, the value of ?tfi,dpb( n ) is specified by ?tfi,dpb( n ) = ?to,dpb( n ) ? DeltaTfiDivisor and When fixed_frame_rate_flag is equal to 1, the value computed for ?tfi,dpb( n ) shall be the same for all n > 0 and shall be equal to num_units_in_tick ? time_scale. (with no mention of a divisor). Ahh, the joys of dealing with a codec that?s designed by a committee :-) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at Honeywell.com Tue Dec 9 21:00:40 2014 From: Giridhara.Kalkere at Honeywell.com (Kalkere, Giridhara) Date: Wed, 10 Dec 2014 05:00:40 +0000 Subject: [Live-devel] HTTP Live streaming Message-ID: <955512E27CA4E9478883ACDCA9CA40C601933437@IE1AEX3007.global.ds.honeywell.com> Dear Ross, I am experimenting with the IP camera streaming. I have couple of questions. It would be great if you can take few minutes to answer them. 1. Can I use the LIVE555 to transcode the incoming h264 video stream into mpeg-ts? If so is there any example? 2. Can I use the LIVE555 on android platforms? Thanks and Regards, Giri -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Dec 9 23:31:31 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Dec 2014 20:31:31 +1300 Subject: [Live-devel] HTTP Live streaming In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C601933437@IE1AEX3007.global.ds.honeywell.com> References: <955512E27CA4E9478883ACDCA9CA40C601933437@IE1AEX3007.global.ds.honeywell.com> Message-ID: <7C3F73FF-C4F6-4B4E-8CF6-234FC8BB3C27@live555.com> > 1. Can I use the LIVE555 to transcode the incoming h264 video stream into mpeg-ts? What you?re describing isn?t really ?transcoding? (because the MPEG Transport Stream format isn?t a codec (like H.264), but instead just a packaging format). But the answer is Yes: You can pack an incoming H.264 Video stream into a MPEG Transport Stream file. > If so is there any example? Yes, the ?testH264VideoToTransportStream? demo application (in the ?testProgs? directory). > 2. Can I use the LIVE555 on android platforms? Yes, of course. ?Android? is just a form of Linux, so one of the ?config.*linux*? files should work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at Honeywell.com Tue Dec 9 23:43:54 2014 From: Giridhara.Kalkere at Honeywell.com (Kalkere, Giridhara) Date: Wed, 10 Dec 2014 07:43:54 +0000 Subject: [Live-devel] HTTP Live streaming In-Reply-To: <7C3F73FF-C4F6-4B4E-8CF6-234FC8BB3C27@live555.com> References: <955512E27CA4E9478883ACDCA9CA40C601933437@IE1AEX3007.global.ds.honeywell.com> <7C3F73FF-C4F6-4B4E-8CF6-234FC8BB3C27@live555.com> Message-ID: <955512E27CA4E9478883ACDCA9CA40C6019334C5@IE1AEX3007.global.ds.honeywell.com> Dear Ross, Thanks for the response. Yes now understand mpeg-ts its packaging format. I tried testH264VideoToTransportStream. I could able to do only the stored .mp4 files into transport stream files. How to do incoming h264 video stream from a IP camera into multiple transport streams. Please advice on this. On android I should be running the application below the JVM layer. Not sure I can run this in JVM context or not? any documentation on running it on android. Thanks and Regards, Giri From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, December 10, 2014 1:02 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] HTTP Live streaming 1. Can I use the LIVE555 to transcode the incoming h264 video stream into mpeg-ts? What you?re describing isn?t really ?transcoding? (because the MPEG Transport Stream format isn?t a codec (like H.264), but instead just a packaging format). But the answer is Yes: You can pack an incoming H.264 Video stream into a MPEG Transport Stream file. If so is there any example? Yes, the ?testH264VideoToTransportStream? demo application (in the ?testProgs? directory). 2. Can I use the LIVE555 on android platforms? Yes, of course. ?Android? is just a form of Linux, so one of the ?config.*linux*? files should work. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Dec 9 23:56:47 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Dec 2014 20:56:47 +1300 Subject: [Live-devel] HTTP Live streaming In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C6019334C5@IE1AEX3007.global.ds.honeywell.com> References: <955512E27CA4E9478883ACDCA9CA40C601933437@IE1AEX3007.global.ds.honeywell.com> <7C3F73FF-C4F6-4B4E-8CF6-234FC8BB3C27@live555.com> <955512E27CA4E9478883ACDCA9CA40C6019334C5@IE1AEX3007.global.ds.honeywell.com> Message-ID: <342040E3-979C-422A-AA0C-6C4A808E4DF1@live555.com> > Yes now understand mpeg-ts its packaging format. > I tried testH264VideoToTransportStream. I could able to do only the stored .mp4 files into transport stream files. How to do incoming h264 video stream from a IP camera into multiple transport streams. Instead of using a ?ByteStreamFileSource? + ?H264VideoStreamFramer? as your input source, just use your ?RTPSource? (which, for H.264 video, will be a ?H264VideoRTPSource?). The rest of the code (to feed the source into a ?MPEG2TransportStreamFromESSource?, and from there into a ?FileSink?) can be the same as in ?testH264VideoToTransportStream?. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From zustchf at 163.com Tue Dec 9 23:29:45 2014 From: zustchf at 163.com (zustchf) Date: Wed, 10 Dec 2014 15:29:45 +0800 Subject: [Live-devel] About live555 convert H264 stream to MPEG2 transport stream Message-ID: <69b9e172.3b50.14a331ae421.Coremail.zustchf@163.com> Hello, dear friend: I have use the test application "testH264VideoToTransportStream" to change the H264 stream to transport stream, after this step I get a out.ts file, then I use "MPEG2TransportStreamIndexer" to create an index file out.txs for the out.ts file, after those two steps, I use Safari browser to request the transport stream but failed. what is wrong with those? I have also downloaded the bipbop-gear1-all.ts, and use "MPEG2TransportStreamIndexer" to create the index file, this process is succeed, do this means the "MPEG2TransportStreamIndexer" is correct, but there is something wrong with the H264VideoToTransportStream process? How can I convert the H264 stream to ts successfully? I really need your help, and please response this email as soon as possible! Thanks very much! 2014-12-10 zustchf -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 10 00:42:12 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Dec 2014 21:42:12 +1300 Subject: [Live-devel] About live555 convert H264 stream to MPEG2 transport stream In-Reply-To: <69b9e172.3b50.14a331ae421.Coremail.zustchf@163.com> References: <69b9e172.3b50.14a331ae421.Coremail.zustchf@163.com> Message-ID: <897211AB-7B21-48A5-BE36-8534B9D02BD2@live555.com> > I have use the test application "testH264VideoToTransportStream" to change the H264 stream to transport stream, after this step I get a out.ts file, then I use "MPEG2TransportStreamIndexer" to create an index file out.txs for the out.ts file, after those two steps, I use Safari browser to request the transport stream but failed. > what is wrong with those? > I have also downloaded the bipbop-gear1-all.ts, and use "MPEG2TransportStreamIndexer" to create the index file, this process is succeed, do this means the "MPEG2TransportStreamIndexer" is correct, but there is something wrong with the H264VideoToTransportStream process? Probably not. It?s unlikely that there is anything ?wrong? with the ?H264VideoToTransportStream? mechanism, although it?s possible that (for some unknown reason) the type of Transport Stream that it produces does not satisfy Safari. It is also possible that the problem is that the H.264 ?profile? that your stream uses does not match the profile that Safari requires. See https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html Unfortunately this is not something that we can help you with. You will need to figure out (with Apple, using some appropriate Apple-specific mailing list; not this one) exactly what is wrong with your Transport Stream. > I really need your help, and please response this email as soon as possible! Sorry, but requests posted to this free mailing list are never considered ?urgent?. Only paying consulting clients get priority support. (Live Networks, Inc. is not a charity.) Also (as clearly stated in the FAQ that everyone is asked to read before posting to this mailing list), messages sent using unprofessional email addresses (like ?@163.c om?) are considered very low priority, and might not get answered at all. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at Honeywell.com Wed Dec 10 00:42:36 2014 From: Giridhara.Kalkere at Honeywell.com (Kalkere, Giridhara) Date: Wed, 10 Dec 2014 08:42:36 +0000 Subject: [Live-devel] HTTP Live streaming In-Reply-To: <342040E3-979C-422A-AA0C-6C4A808E4DF1@live555.com> References: <955512E27CA4E9478883ACDCA9CA40C601933437@IE1AEX3007.global.ds.honeywell.com> <7C3F73FF-C4F6-4B4E-8CF6-234FC8BB3C27@live555.com> <955512E27CA4E9478883ACDCA9CA40C6019334C5@IE1AEX3007.global.ds.honeywell.com> <342040E3-979C-422A-AA0C-6C4A808E4DF1@live555.com> Message-ID: <955512E27CA4E9478883ACDCA9CA40C60193350E@IE1AEX3007.global.ds.honeywell.com> OK Thank you very much From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, December 10, 2014 1:27 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] HTTP Live streaming Yes now understand mpeg-ts its packaging format. I tried testH264VideoToTransportStream. I could able to do only the stored .mp4 files into transport stream files. How to do incoming h264 video stream from a IP camera into multiple transport streams. Instead of using a ?ByteStreamFileSource? + ?H264VideoStreamFramer? as your input source, just use your ?RTPSource? (which, for H.264 video, will be a ?H264VideoRTPSource?). The rest of the code (to feed the source into a ?MPEG2TransportStreamFromESSource?, and from there into a ?FileSink?) can be the same as in ?testH264VideoToTransportStream?. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenchow.cn at gmail.com Wed Dec 10 01:05:14 2014 From: kenchow.cn at gmail.com (ken chow) Date: Wed, 10 Dec 2014 17:05:14 +0800 Subject: [Live-devel] hi all, I found a bug in mediaServer source code. In-Reply-To: References: <79F26890-64A0-407F-A859-5B5EFA6573E2@live555.com> Message-ID: I met another bug about dealing with range time. Version: live.2014.12.09.tar.gz File: RTSPServer.cpp line: 1954 code: fStreamStates[i].subsession->seekStream(fOurSessionId, fStreamStates[i].streamToken, absStart, absEnd); the absStart and absEnd will be freed(deleted) in File: OnDemandServerMediaSubsession.cpp line: 361 but, later in File: RTSPServer.cpp line: 1984 the absStart and absEnd will be used to fill the rangeHeader, so each PLAY response were receiving range start from 0 to 0. another thing, I wish someone would help me. I'm recently doing the range play, I still don't know how to make it right, actually, I'm not familiar with C++, the problem that I met is if I give the range start time, don't give end time, usually the file will play from start time that I gave to the end of file, the reality is liveMedia played from whole file start to the end, just like no rang time. Thank you. Ken Chow about.me/kenchowcn [image: Ken Chow on about.me] On Tue, Dec 9, 2014 at 12:50 AM, Ross Finlayson wrote: > > my point is if utcTimes is "20141208T064100.000Z-\r\nSession: > 81A6879B\r\n", then the sscanf will parse that not we want > > > Yes, you?re right - this was a bug. > > I?ve just installed a new version - 2014.12.08 - of the ?LIVE555 Streaming > Media? code that should fix this. Thanks for the report. > > 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 jshanab at jfs-tech.com Wed Dec 10 03:32:25 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Wed, 10 Dec 2014 06:32:25 -0500 Subject: [Live-devel] About live555 convert H264 stream to MPEG2 transport stream In-Reply-To: <897211AB-7B21-48A5-BE36-8534B9D02BD2@live555.com> References: <69b9e172.3b50.14a331ae421.Coremail.zustchf@163.com> <897211AB-7B21-48A5-BE36-8534B9D02BD2@live555.com> Message-ID: Safari or apple in general is very picky about the segment length and what is in them. I did get this to work but had to modify one of the live 555 classes. It was a few years ago but I did send it to this list as a suggestion, so it is in the history somewhere. While the standard allows you to not start a segment on a keyframe if already going, the previous segment MUST have decoded and played. If the browser drops the ball it gets lost. So the solution I chose was to make every segment start on a keyframe. HTTP live streaming requires the stream to be broken into segments of equal segment lengths. 10 second is the default, I have used 5 and 2. The index file claims the segment length and the segments cannot very much at all. In order for this to work reliably with H264 video you need to start each segment on a keyframe. Currently the part of the code for transport stream inserts the PES** frames at a timed interval that is not tied to the keyframe interval. I changed the attached classes and had them working before we abandoned this for an app using live555 and rtsp on the device themselfs. HTTP live streaming imparts a delay on live video that was unacceptable for security camera video in our use case. I was doing my own segmenting and index creation on the fly because I was trying to use it for live video to the ipad,iphone, android. Safari was my desktop test. It became trivial once I knew I had a gop size of 10 @ 10fps to start a segment on a keyframe and to start a new one on the segment length * gop size +1 PTS/DTS/keyframe packet was encountered. Essentially payed it forward. Stick in the PTS at index friendly intervals then the downstream indexer just worked. ** sorry this is off the top of my head, PTS? I can dig deeper if necessary after work. I see the files in an old directory and am attaching them. Please note this was years ago, Ross may have already changed this code. I have not followed as I have dropped interest in HTTP live streaming. There is a new tech, extremely similar to HTTP live streaming without the index file and latency issues that mirrors my own solution already out there VP8 + HTML5, so I am a bit surprized to see a question about HLS. On Wed, Dec 10, 2014 at 3:42 AM, Ross Finlayson wrote: > I have use the test application "testH264VideoToTransportStream" to change > the H264 stream to transport stream, after this step I get a out.ts file, > then I use "MPEG2TransportStreamIndexer" to create an index file out.txs > for the out.ts file, after those two steps, I use Safari browser to request > the transport stream but failed. > what is wrong with those? > I have also downloaded the bipbop-gear1-all.ts, and use > "MPEG2TransportStreamIndexer" to create the index file, this process is > succeed, do this means the "MPEG2TransportStreamIndexer" is correct, but > there is something wrong with the H264VideoToTransportStream process? > > > Probably not. It?s unlikely that there is anything ?wrong? with the > ?H264VideoToTransportStream? mechanism, although it?s possible that (for > some unknown reason) the type of Transport Stream that it produces does not > satisfy Safari. It is also possible that the problem is that the H.264 > ?profile? that your stream uses does not match the profile that Safari > requires. See > > https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html > Unfortunately this is not something that we can help you with. You will > need to figure out (with Apple, using some appropriate Apple-specific > mailing list; not this one) exactly what is wrong with your Transport > Stream. > > > I really need your help, and please response this email as soon as > possible! > > > Sorry, but requests posted to this free mailing list are never considered > ?urgent?. Only paying consulting clients get priority support. (Live > Networks, Inc. is not a charity.) > > Also (as clearly stated in the FAQ that everyone is asked to read before > posting to this mailing list), messages sent using unprofessional email > addresses (like ?@163.c om?) are considered very low > priority, and might not get answered at all. > > > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2TransportStreamFromESSource4iOS.cpp Type: text/x-c++src Size: 10569 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2TransportStreamFromESSource4iOS.hh Type: application/octet-stream Size: 2294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2TransportStreamMultiplexor4iOS.cpp Type: text/x-c++src Size: 20965 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2TransportStreamMultiplexor4iOS.hh Type: application/octet-stream Size: 3553 bytes Desc: not available URL: From michel.promonet at thalesgroup.com Wed Dec 10 04:24:34 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Wed, 10 Dec 2014 13:24:34 +0100 Subject: [Live-devel] Problem using live555MediaServer with more than 250 clients Message-ID: <26361_1418214276_54883B84_26361_1585_1_1BE8971B6CFF3A4F97AF4011882AA25501565C4280F0@THSONEA01CMS01P.one.grp> Hi Ross, I am connecting quite a lot of RTSP client to live555MediaServer. But when the filedescriptor number is over 1024 (which is the FD_SETSIZE of the operating system), the process abort in the well know internalError abort. BasicTaskScheduler::SingleStep(): select() fails: Bad file descriptor socket numbers used in the select() call: ...... 1113(e) 1115(e) 1119(e) 1121(e) 1123(e) 1125(e) 1129(e) 1131(e) ... As each RTSP client needs about 4 filedescriptors (RTSP,RTP,RTCP, file), the 1024 limits is reached with about 250 clients. I guess this occurs because BasicTaskScheduler::SingleStep read after the end of the fd_set structures. In order to avoid to reach the abort, I try an extra sanity check inside BasicTaskScheduler::setBackgroundHandling void BasicTaskScheduler::setBackgroundHandling(int socketNum, int conditionSet, BackgroundHandlerProc* handlerrProc, void * clientData) { if ( (socketNum <0) || (socketNum >= FD_SETSIZE) ) return; ... Doing like this, avoid abort, but it doesnot inform the RTSPClient that its socket was refused. Such a thing need a feedback from setBackgroundHandling. Thanks again for your support, Michel. [@@ THALES GROUP INTERNAL @@] -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 10 05:50:58 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Dec 2014 02:50:58 +1300 Subject: [Live-devel] hi all, I found a bug in mediaServer source code. In-Reply-To: References: <79F26890-64A0-407F-A859-5B5EFA6573E2@live555.com> Message-ID: <6AB24404-4706-46EC-969A-CFD73D7FD37C@live555.com> > I met another bug about dealing with range time. > Version: live.2014.12.09.tar.gz > File: RTSPServer.cpp line: 1954 code: > fStreamStates[i].subsession->seekStream(fOurSessionId, fStreamStates[i].streamToken, absStart, absEnd); > > the absStart and absEnd will be freed(deleted) in File: OnDemandServerMediaSubsession.cpp line: 361 You?re misunderstanding the code. This is the *default version* of the ?seekStreamSource()? virtual function - i.e., the version that gets called if you don?t explicitly implement seeking in your own subclass of ?OnDemandServerMediaSubsession?. If you don?t override (i.e., implement your own version of) the ?seekStreamSource()? virtual function (note, BTW, that there are two forms of this function - one for seeking by NPT (?normal play time?); another for seeking by absolute time), then this default version of the function will get called, and the RTSP response will have a ?range: 0-0? header, to show that the server (by default) does not implement seeking. Therefore, to implement seeking by absolute time, your subclass of ?OnDemandServerMediaSubsession? must reimplement the ?seekStreamSource()? virtual function (the second version - the version that supports seeking by absolute time - if that?s what you want to do). See http://live555.com/liveMedia/faq.html#trick-mode (although that web page mentions only the first (NPT, i.e., ?normal play time?) version of ?seekStreamSource()?, because most developers want to implement only seeking by NPT). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 10 06:19:58 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Dec 2014 03:19:58 +1300 Subject: [Live-devel] Problem using live555MediaServer with more than 250 clients In-Reply-To: <26361_1418214276_54883B84_26361_1585_1_1BE8971B6CFF3A4F97AF4011882AA25501565C4280F0@THSONEA01CMS01P.one.grp> References: <26361_1418214276_54883B84_26361_1585_1_1BE8971B6CFF3A4F97AF4011882AA25501565C4280F0@THSONEA01CMS01P.one.grp> Message-ID: > In order to avoid to reach the abort, I try an extra sanity check inside BasicTaskScheduler::setBackgroundHandling > void BasicTaskScheduler::setBackgroundHandling(int socketNum, int conditionSet, BackgroundHandlerProc* handlerrProc, void * clientData) { > if ( (socketNum <0) || (socketNum >= FD_SETSIZE) ) return; > ? Maybe, but I?m not convinced that this would really be useful, as the current code should already make sure (at a higher level) that ?setBackgroundHandling()? (or ?turnOnBackgroundReadHandling()?, which calls ?setBackgroundHandling()?) does not get called with a socket number <0. Also, it should never get called with a socket number >= FD_SETSIZE, because socket numbers this large should never have been given out (i.e., returned as a result of a ?socket()? call) in the first place! Also, let me remind people once again that the number of sockets used by each stream can be reduced from 2 (RTP,RTCP) to 1 (RTP-muxed-with-RTCP) if both the server and client support this; see http://lists.live555.com/pipermail/live-devel/2014-March/018179.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachit81 at gmail.com Wed Dec 10 06:34:22 2014 From: rachit81 at gmail.com (Rachit shah) Date: Wed, 10 Dec 2014 06:34:22 -0800 Subject: [Live-devel] difference between test*Streamer and testOnDemandRTSPServer model Message-ID: Hi, I have following queries.. 1.what is main difference between two model "test*streamer" (like testH264VideoStream) and "testOnDemandRTSPServer" ? 2. As per FAQ both models can be used to stream live data, which model is used for what different type of use case ? 3. which model is better to use if it is required to stream encoded frame (H.265/H.264/MPEG-4) from live source ? Regards, Rachit -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 10 08:03:36 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Dec 2014 05:03:36 +1300 Subject: [Live-devel] difference between test*Streamer and testOnDemandRTSPServer model In-Reply-To: References: Message-ID: <70F096B8-1CC9-4FEA-B60B-E0A6E96ABEFE@live555.com> > 1.what is main difference between two model "test*streamer" (like testH264VideoStream) and "testOnDemandRTSPServer? ? The ?*Streamer? demo applications stream via IP multicast - and therefore should be used only if you have IP multicast connectivity between the server and client(s). The ?testOnDemandRTSPServer? RTSP server (and the ?LIVE555 Media Server? product) stream via unicast - separately to each client. > 3. which model is better to use if it is required to stream encoded frame (H.265/H.264/MPEG-4) from live source ? For casual hobbyists like you, I suggest using ?testOnDemandRTSPServer? as a model (and of course the FAQ). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.promonet at thalesgroup.com Wed Dec 10 09:11:34 2014 From: michel.promonet at thalesgroup.com (PROMONET Michel) Date: Wed, 10 Dec 2014 18:11:34 +0100 Subject: [Live-devel] Problem using live555MediaServer with more than 250 clients In-Reply-To: References: <26361_1418214276_54883B84_26361_1585_1_1BE8971B6CFF3A4F97AF4011882AA25501565C4280F0@THSONEA01CMS01P.one.grp> Message-ID: <26359_1418231496_54887EC8_26359_2512_1_1BE8971B6CFF3A4F97AF4011882AA25501565C428A26@THSONEA01CMS01P.one.grp> Hi Ross, Thanks for your answer. Sorry for asking for some additional explanations, but there is something I do not understand in your answer. socket() can give a number above FD_SETSIZE (FD_SETSIZE is a limit for fd_set used by select(), but is not related to socket()). This can be easily verified with a piece of code like this : for (int i=0; i<2048; i++) printf(?%d\n?, socket(AF_INET,SOCK_DGRAM,0)); Increasing ?ulimit ?n 4096? will allow to sockets with number up to 2051 (stdin, stdout, stderr + 2048 sockets) What I missed ? Thanks & Regards, Michel. [@@ THALES GROUP INTERNAL @@] De : live-devel [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : mercredi 10 d?cembre 2014 15:20 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] Problem using live555MediaServer with more than 250 clients In order to avoid to reach the abort, I try an extra sanity check inside BasicTaskScheduler::setBackgroundHandling void BasicTaskScheduler::setBackgroundHandling(int socketNum, int conditionSet, BackgroundHandlerProc* handlerrProc, void * clientData) { if ( (socketNum <0) || (socketNum >= FD_SETSIZE) ) return; ? Maybe, but I?m not convinced that this would really be useful, as the current code should already make sure (at a higher level) that ?setBackgroundHandling()? (or ?turnOnBackgroundReadHandling()?, which calls ?setBackgroundHandling()?) does not get called with a socket number <0. Also, it should never get called with a socket number >= FD_SETSIZE, because socket numbers this large should never have been given out (i.e., returned as a result of a ?socket()? call) in the first place! Also, let me remind people once again that the number of sockets used by each stream can be reduced from 2 (RTP,RTCP) to 1 (RTP-muxed-with-RTCP) if both the server and client support this; see http://lists.live555.com/pipermail/live-devel/2014-March/018179.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 10 12:27:04 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Dec 2014 09:27:04 +1300 Subject: [Live-devel] Problem using live555MediaServer with more than 250 clients In-Reply-To: <26359_1418231496_54887EC8_26359_2512_1_1BE8971B6CFF3A4F97AF4011882AA25501565C428A26@THSONEA01CMS01P.one.grp> References: <26361_1418214276_54883B84_26361_1585_1_1BE8971B6CFF3A4F97AF4011882AA25501565C4280F0@THSONEA01CMS01P.one.grp> <26359_1418231496_54887EC8_26359_2512_1_1BE8971B6CFF3A4F97AF4011882AA25501565C428A26@THSONEA01CMS01P.one.grp> Message-ID: > socket() can give a number above FD_SETSIZE (FD_SETSIZE is a limit for fd_set used by select(), but is not related to socket()). Yes, you?re right; my mistake. Yes, I suppose I could add a test for ?socketNum >= FD_SETSIZE? to ?BasicTaskScheduler::setBackgroundHandling()? (note that there?s already a test for ?socketNum < 0?). I would have thought/hoped that FD_SET() would have already tested for this, but perhaps not... This is all assuming that it?s better to have the code just silently fail to handle events on any sockets with number > FD_SETSIZE, than to fail with an ?internalError()? call in this case (due to ?select()? having returned <0). (Note, BTW, that you can - if you wish - subclass ?(Basic)UsageEnvironment? and redefine the ?internalError()? virtual function to do whatever you want.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 10 18:22:07 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Dec 2014 15:22:07 +1300 Subject: [Live-devel] Problem using live555MediaServer with more than 250 clients In-Reply-To: References: <26361_1418214276_54883B84_26361_1585_1_1BE8971B6CFF3A4F97AF4011882AA25501565C4280F0@THSONEA01CMS01P.one.grp> <26359_1418231496_54887EC8_26359_2512_1_1BE8971B6CFF3A4F97AF4011882AA25501565C428A26@THSONEA01CMS01P.one.grp> Message-ID: <03D0EB86-F67C-4797-9D97-BBD927F04E5E@live555.com> > Yes, I suppose I could add a test for ?socketNum >= FD_SETSIZE? to ?BasicTaskScheduler::setBackgroundHandling()? (note that there?s already a test for ?socketNum < 0?). I would have thought/hoped that FD_SET() would have already tested for this, but perhaps not... > > This is all assuming that it?s better to have the code just silently fail to handle events on any sockets with number > FD_SETSIZE, than to fail with an ?internalError()? call in this case (due to ?select()? having returned <0). Actually, thinking about this some more - this is the reason why I *won?t* be adding this test. It really is an ?internal error?, so the code should report it as such - rather than ?failing silently?. (As I noted before, people can redefine the ?internalError()? function to do whatever they want, if they don?t like the ?abort()?.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Dec 11 02:49:47 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Dec 2014 23:49:47 +1300 Subject: [Live-devel] Problem using live555MediaServer with more than 250 clients In-Reply-To: References: <26361_1418214276_54883B84_26361_1585_1_1BE8971B6CFF3A4F97AF4011882AA25501565C4280F0@THSONEA01CMS01P.one.grp> <26359_1418231496_54887EC8_26359_2512_1_1BE8971B6CFF3A4F97AF4011882AA25501565C428A26@THSONEA01CMS01P.one.grp> Message-ID: <403173EB-D1BB-44C5-91F9-6A06027AD4B6@live555.com> When this thread began, I initially assumed that the system header file would implement FD_SET (etc.) by either checking itself whether the socket number was in the range [0,FD_SETSIZE), or else by ensuring that it would use a bitmap large enough for all possible socket numbers (regardless of FD_SETSIZE). To my astonishment, when I looked at the implementation (in the system header file ), in every implementation I looked at, the bitmap was only large enough for FD_SETSIZE, and there was no checking against this - so buffer overflow occurs if you use a socket number >= FD_SETSIZE! This is (IMHO) a serious bug in the system header file (in most, if not all, Unix systems out there). So I?ve changed my mind yet again and decided to adopt Michel Promonet?s suggestion of testing for this myself in our implementation of ?BasicUsageEnvironment::setBackgroundHandling()? and ?BasicUsageEnvironment::moveBackgroundHandling()?. A new version (2014.12.11) of the ?LIVE555 Streaming Media? code has now been installed. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From backerman at icontrol.com Thu Dec 11 14:55:14 2014 From: backerman at icontrol.com (Braden Ackerman) Date: Thu, 11 Dec 2014 22:55:14 +0000 Subject: [Live-devel] Updated iOS config for genMakeFiles Message-ID: Ross, You're kind enough to spend time answering the plentiful (and often dumb) questions on this mailing list so I'll contribute to Live555 in anyway I can. I've got a few subclasses I'm thinking about contributing after they're cleaned up. For now: I needed Live555 for iOS 8.* built with Xcode 6, so I modified the config.iphoneos file to make it work. Perhaps this can be added as config.iphoneosclang. What broke the old config.iphoneos was Apple moving to clang compiler for new Xcode versions (no more g++). Hope this helps someone. Braden # Change the following version number, if necessary, before running "genMakefiles iphoneos" IOS_VERSION = 8.1 DEVELOPER_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer TOOL_PATH = $(DEVELOPER_PATH)/usr/bin SDK_PATH = $(DEVELOPER_PATH)/SDKs SDK = $(SDK_PATH)/iPhoneOS$(IOS_VERSION).sdk COMPILE_OPTS = $(INCLUDES) -I. $(EXTRA_LDFLAGS) -DBSD=1 -O2 -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -arch armv7 --sysroot=$(SDK) C = c C_COMPILER = /usr/bin/xcrun clang C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = /usr/bin/xcrun clang CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = /usr/bin/xcrun clang -o LINK_OPTS = -L. -arch armv7 --sysroot=$(SDK) -L$(SDK)/usr/lib/system CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = libtool -s -o LIBRARY_LINK_OPTS = LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = LIBS_FOR_GUI_APPLICATION = EXE =? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Dec 11 15:21:56 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Dec 2014 12:21:56 +1300 Subject: [Live-devel] Updated iOS config for genMakeFiles In-Reply-To: References: Message-ID: <7DF9839E-660A-4FC6-9D11-5E147FFBE3EB@live555.com> > I needed Live555 for iOS 8.* built with Xcode 6, so I modified the config.iphoneos file to make it work. > Perhaps this can be added as config.iphoneosclang. No, I?ll just replace the existing ?config.iphoneos? (in the next release of the software). Most people building for iOS will be using the new Xcode. One correction to your file: I presume that /usr/bin/xcrun (3 occurrences) should be replaced with $(TOOL_PATH)/xcrun 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 Dec 12 00:47:53 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Fri, 12 Dec 2014 08:47:53 +0000 Subject: [Live-devel] Sony cameras and interleaved RTSP Message-ID: Morning all. We've spent the last few weeks tracking down a couple of issues when using Sony G6 cameras and interleaved RTSP. Several times here (and many times at a customer's), we've seen the camera randomly spit out an RTSP response followed by an RTCP BYE and stopping the stream. RTSP/1.0 505 RTSP Version not supported Server: Linux/2.6.35.14_nl-xarina Ze-PRO This can take anywhere from 30 minutes to 5 hours so isn't a fixed timeout. We are still using 2009-02-23 (legacy reasons I'm trying to work around and remove) and the error is happening with the compiled openRTSP.exe and our code so I was ready to point the finger at the camera misparsing the interleaved data. We also tested with VLC (in interleaved mode) and 2014-12-09 and we have not yet seen this issue after 24 hours. Is this likely to be have been triggered by something in liveMedia that has since been fixed, or should I still chase this up with Sony themselves? 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 From finlayson at live555.com Fri Dec 12 02:37:10 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Dec 2014 23:37:10 +1300 Subject: [Live-devel] Sony cameras and interleaved RTSP In-Reply-To: References: Message-ID: > We are still using 2009-02-23 (legacy reasons I'm trying to work around and remove) and the error is happening with the compiled openRTSP.exe and our code so I was ready to point the finger at the camera misparsing the interleaved data. > We also tested with VLC (in interleaved mode) and 2014-12-09 and we have not yet seen this issue after 24 hours. I have absolutely no interest in whether or not old versions of our software work OK, because old versions are not supported. Just to clarify: Does "openRTSP" - using the latest version of our software - work OK with this server (camera)? If so, then there is no issue. If, however, "openRTSP" - using the latest version of our software - has a problem with this server, then please post the complete RTSP diagnostic output (printed by "openRTSP" to stderr) to this mailing list, and I'll take a look at it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at speed666.info Fri Dec 12 03:02:14 2014 From: marcin at speed666.info (Marcin) Date: Fri, 12 Dec 2014 12:02:14 +0100 Subject: [Live-devel] Sony cameras and interleaved RTSP In-Reply-To: References: Message-ID: <548ACB36.70402@speed666.info> Hi, Also to mention - G6 has a "backdoor" - there is no way that you can password-protect RTSP stream from those cameras. So good point is to firewall 554 port to only Allowed IP Range when camera is public accessible. Marcin W dniu 2014-12-12 11:37, Ross Finlayson pisze: >> We are still using 2009-02-23 (legacy reasons I'm trying to work >> around and remove) and the error is happening with the compiled >> openRTSP.exe and our code so I was ready to point the finger at the >> camera misparsing the interleaved data. >> We also tested with VLC (in interleaved mode) and 2014-12-09 and we >> have not yet seen this issue after 24 hours. > > I have absolutely no interest in whether or not old versions of our > software work OK, because old versions are not supported. > > Just to clarify: Does "openRTSP" - using the latest version of our > software - work OK with this server (camera)? If so, then there is no > issue. > > If, however, "openRTSP" - using the latest version of our software - > has a problem with this server, then please post the complete RTSP > diagnostic output (printed by "openRTSP" to stderr) to this mailing > list, and I'll take a look at it. > > 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 Dec 12 03:01:04 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Fri, 12 Dec 2014 11:01:04 +0000 Subject: [Live-devel] Sony cameras and interleaved RTSP In-Reply-To: References: Message-ID: <324b447401fd471bbae2f24783fcba1a@SRV-EXCHANGE-2.icode.co.uk> I fully accept that old versions are not supported, but that wasn't what I was asking. As this is a random occurrence, it's not falsifiable. All I can see is that "it has broken" or "it hasn't broken YET". I was asking if there is likely to have been any change to the interleaved RTSP handling that may well have affected this before we blame Sony (it wouldn't be the first time) If it DOES break then I will have diagnostic information, but all openRTSP (2009) picked up on was: Data packets have begun arriving [865902120] Received RTCP "BYE" on "video/H264" subsession (after 8782 seconds) As it is, I've been allowed to upgrade liveMedia now anyway :) -- 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: 12 December 2014 10:37 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Sony cameras and interleaved RTSP We are still using 2009-02-23 (legacy reasons I'm trying to work around and remove) and the error is happening with the compiled openRTSP.exe and our code so I was ready to point the finger at the camera misparsing the interleaved data. We also tested with VLC (in interleaved mode) and 2014-12-09 and we have not yet seen this issue after 24 hours. I have absolutely no interest in whether or not old versions of our software work OK, because old versions are not supported. Just to clarify: Does "openRTSP" - using the latest version of our software - work OK with this server (camera)? If so, then there is no issue. If, however, "openRTSP" - using the latest version of our software - has a problem with this server, then please post the complete RTSP diagnostic output (printed by "openRTSP" to stderr) to this mailing list, and I'll take a look at it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 12 03:32:10 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 13 Dec 2014 00:32:10 +1300 Subject: [Live-devel] Sony cameras and interleaved RTSP In-Reply-To: <324b447401fd471bbae2f24783fcba1a@SRV-EXCHANGE-2.icode.co.uk> References: <324b447401fd471bbae2f24783fcba1a@SRV-EXCHANGE-2.icode.co.uk> Message-ID: <3283FAD9-B2FF-4525-BB4D-309C7170AC70@live555.com> > I was asking if there is likely to have been any change to the interleaved RTSP handling There have been *many* changes (bug fixes) to RTP/RTCP-over-RTSP (i.e., "interleaved RTSP handling?) - and many other things - in the last few years. (Handling RTP/RTCP-over-RTSP turned out to be an extremely complex part of the code.) That?s why you should upgrade your client(s), and it?s why we do not support old versions of the code. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chieppa at elmaxsrl.it Fri Dec 12 08:17:40 2014 From: chieppa at elmaxsrl.it (chieppa at elmaxsrl.it) Date: Fri, 12 Dec 2014 17:17:40 +0100 Subject: [Live-devel] Struggling with a stange behavior Message-ID: ?Dear Ross, I solved the problem. The behaviour happened when I set the tunneling over TCP. When an IP camera went down, closing the streaming, I invoked the shutdown function (as the testRTSPClient) on the ?delayed event. When the camera turned on and ?my sw started a new RTSP connection (client) at the end of the program Valgrind said me that I lost 60 byte in a past?H264BufferdPackedFactory::createNewPacket. Changing #define REQUEST_STREAMING_OVER_TCP false I found out the this problem is solved. Unfortunately I don't have a technical answer to this behaviour, but I ran so many time Valgrind using this configuration and the answer is always the same: 0 byte lost, no leaks. Regards Cristiano -------------- next part -------------- An HTML attachment was scrubbed... URL: From backerman at icontrol.com Fri Dec 12 10:18:12 2014 From: backerman at icontrol.com (Braden Ackerman) Date: Fri, 12 Dec 2014 18:18:12 +0000 Subject: [Live-devel] Updated iOS config for genMakeFiles Message-ID: <1418408292243.14900@icontrol.com> Ross, > One correction to your file: I presume that > /usr/bin/xcrun (3 occurrences) > should be replaced with > $(TOOL_PATH)/xcrun xcrun is actually located in /usr/bin. I should have added a note to the build script that "Command line tools (OSX *.*) for Xcode - Xcode *.*" has to be installed as it includes xcrun. There may be a way to get this script working without xcrun, but I haven't found it. The vast majority of iOS developers will have that set of tools installed. Also: I forgot I was building without testProgs. When I downloaded the live555 source to test the build script I posted yesterday it failed on testMP3Streamer as the std c++ library wasn't being linked. I've updated the script to include a note about the command line tools and added a linker option for the missing library. I downloaded a fresh copy of the live555 source and the following script builds the static libraries successfully: # **Note: you must install the relevant "Command line tools (OSX *.*) for Xcode - Xcode *.*" for this script to work. # Available from: https://developer.apple.com/downloads/index.action # Change the following version number, if necessary, before running "genMakefiles iphoneos" IOS_VERSION = 8.1 DEVELOPER_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer TOOL_PATH = $(DEVELOPER_PATH)/usr/bin SDK_PATH = $(DEVELOPER_PATH)/SDKs SDK = $(SDK_PATH)/iPhoneOS$(IOS_VERSION).sdk COMPILE_OPTS = $(INCLUDES) -I. $(EXTRA_LDFLAGS) -DBSD=1 -O2 -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -arch armv7 --sysroot=$(SDK) C = c C_COMPILER = /usr/bin/xcrun clang C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = /usr/bin/xcrun clang CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = /usr/bin/xcrun clang -o LINK_OPTS = -v -L. -arch armv7 --sysroot=$(SDK) -L$(SDK)/usr/lib/system /usr/lib/libc++.dylib CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = libtool -s -o LIBRARY_LINK_OPTS = LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = LIBS_FOR_GUI_APPLICATION = EXE = ? Best regards, Braden Ackerman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rachit81 at gmail.com Fri Dec 12 06:22:54 2014 From: rachit81 at gmail.com (Rachit shah) Date: Fri, 12 Dec 2014 06:22:54 -0800 Subject: [Live-devel] difference between test*Streamer and testOnDemandRTSPServer model In-Reply-To: <70F096B8-1CC9-4FEA-B60B-E0A6E96ABEFE@live555.com> References: <70F096B8-1CC9-4FEA-B60B-E0A6E96ABEFE@live555.com> Message-ID: Hi Ross, Thanks for your inputs. We are looking use Live555 streaming media library on Android and Linux Platform. Product should support unicast as well multicast so in that case which model is better to follow ? Thanks, Rachit On Wed, Dec 10, 2014 at 8:03 AM, Ross Finlayson wrote: > > 1.what is main difference between two model "test*streamer" (like > testH264VideoStream) and "testOnDemandRTSPServer? ? > > > The ?*Streamer? demo applications stream via IP multicast - and therefore > should be used only if you have IP multicast connectivity between the > server and client(s). > > The ?testOnDemandRTSPServer? RTSP server (and the ?LIVE555 Media Server? > product) stream via unicast - separately to each client. > > > 3. which model is better to use if it is required to stream encoded frame > (H.265/H.264/MPEG-4) from live source ? > > > For casual hobbyists like you, I suggest using ?testOnDemandRTSPServer? as > a model (and of course the FAQ). > > 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 Dec 13 03:51:02 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 14 Dec 2014 00:51:02 +1300 Subject: [Live-devel] Updated iOS config for genMakeFiles In-Reply-To: <1418408292243.14900@icontrol.com> References: <1418408292243.14900@icontrol.com> Message-ID: Braden, Thanks for the update. FYI, I have just installed a new version (2014.12.13) of the ?LIVE555 Streaming Media? code that includes an updated ?config.iphoneos? file. Please double-check this to make sure it works OK for you. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Dec 13 18:46:42 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 14 Dec 2014 15:46:42 +1300 Subject: [Live-devel] difference between test*Streamer and testOnDemandRTSPServer model In-Reply-To: References: <70F096B8-1CC9-4FEA-B60B-E0A6E96ABEFE@live555.com> Message-ID: <8C998B4E-1D6C-42A5-9AB8-F3D1C6C0BF7A@live555.com> > On Dec 13, 2014, at 3:22 AM, Rachit shah wrote: > > We are looking use Live555 streaming media library on Android and Linux Platform. Do ?we? not have our own domain name? :-) > Product should support unicast as well multicast so in that case which model is better to follow ? I presume (although you haven?t stated explicitly) that you want a server that will deliver the stream via multicast to multicast-reachable clients (i.e., those on the same LAN), and via unicast to other clients. To do this, you would create a RTSP server, and add two "ServerMediaSession?s to it: One for multicast delivery; the other for multi-unicast delivery. To the first ?ServerMediaSession?, you?d add a ?PassiveServerMediaSubsession? (for multicast). To the second ?ServerMediaSession?, you?d add your own ?OnDemandServerMediaSubsession? subclass, with the ?reuseFirstSource? parameter set to ?True?. (This is explained in the FAQ.) You will probably also need to replicate your input stream, feeding one replica to the multicast stream, and the other replica to your ?OnDemandServerMediaSubsession? subclass (in your ?createNewStreamSource()? implementation). You can do this using the ?StreamReplica? class. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From backerman at icontrol.com Sun Dec 14 21:58:07 2014 From: backerman at icontrol.com (Braden Ackerman) Date: Mon, 15 Dec 2014 05:58:07 +0000 Subject: [Live-devel] Updated iOS config for genMakeFiles Message-ID: <1418623104375.90336@icontrol.com> Ross, I downloaded 2014.12.13 on a fresh Mac (outside my daily dev environment) and could build the libraries, so I think the updated build script is working well. I try to read every digest from this mailing list, but if I happen to miss anyone having issues using that script feel free to email me. Thanks very much for accepting those changes, I hope it helps some of my fellow iOS devs use the great resource that is live555. Stay tuned, I'll try to contribute some of the subclasses I wrote after I find time to clean them up. One facilitates aLaw from memory buffers as a source and RTP as a sink. Another takes advantage of the new VTDecompressionSession Apple added for iOS8.0 to hardware decode h264 from an RTSP session. Live555 doesn't really have anything to do with decoding, so maybe the later isn't an appropriate contribution. I'll let you decide later. Best regards, Braden Ackerman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rglobisch at csir.co.za Mon Dec 15 10:40:00 2014 From: rglobisch at csir.co.za (Ralf Globisch) Date: Mon, 15 Dec 2014 20:40:00 +0200 Subject: [Live-devel] ServerMediaSubsession::getStreamParameters parameter change request Message-ID: <548F47200200004D000B9C11@pta-emo.csir.co.za> Hi Ross, Would you be willing to add the "fullRequestStr" parameter of RTSPServer::RTSPClientSession::handleCmd_SETUP as an additional parameter to the ServerMediaSubsession::getStreamParameters method? We had previously overridden ServerMediaSubsession::getStreamParameters in one of our subclasses for the purpose of client connection management and now to add DRM-related functionality we also need to associate "fOurSessionId" with the user name which can be parsed out of the Authorization header in "fullRequestStr". If you agree to add the parameter we would of course supply a patch. Otherwise, we would be grateful if you have an alternative suggestion to associate the live555 session id with the user name from the context of a ServerMediaSubsession subclass. We have thought of duplicating and adapting the code of RTSPServer::RTSPClientSession::handleCmd_SETUP in our subclass of RTSPServer::RTSPClientSession but that does not seem like a good solution to me. Thanks for your time, Ralf -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. From finlayson at live555.com Tue Dec 16 02:51:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Dec 2014 23:51:38 +1300 Subject: [Live-devel] ServerMediaSubsession::getStreamParameters parameter change request In-Reply-To: <548F47200200004D000B9C11@pta-emo.csir.co.za> References: <548F47200200004D000B9C11@pta-emo.csir.co.za> Message-ID: > Would you be willing to add the "fullRequestStr" parameter of RTSPServer::RTSPClientSession::handleCmd_SETUP as an additional parameter to the ServerMediaSubsession::getStreamParameters method? Probably not, because I don?t see the need for it. The signature for "ServerMediaSubsession::getStreamParameters()? is already complex, has remained unchanged for several years, and it?s used only (by RTSP servers) to implement the ?SETUP? command, using a ?RTSPClientSession? object, which identifies the client. At this point, the client has already been authenticated, so the server should no longer need the user name. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick.ogden at usa.g4s.com Tue Dec 16 06:13:13 2014 From: nick.ogden at usa.g4s.com (Ogden, Nick) Date: Tue, 16 Dec 2014 14:13:13 +0000 Subject: [Live-devel] RTCP APP packet handling Message-ID: Hi Ross. We have a need to handle RTCP APP packets in our application. I notice from the Live555 RTCPInstance code that they are currently ignored. If we were to implement a way for a subclass of OnDemandMediaSubsession to provide a custom handler for APP packets, in a similar way that handlers are provided for the SR and RR packets, would you be likely to accept this as a patch? Kind Regards -- Nick Ogden G4S Technology Tel: +44 (0) 1684 857299 nick.ogden at usa.g4s.com www.g4stechnology.com Challenge House, International Drive, Tewkesbury, Gloucestershire, GL20 8UQ, UK P Please consider the environment before printing this email ________________________________ The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338. This communication may contain information which is confidential, personal and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, forwarding, copying or use of this communication or the information in it is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sender and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dee.earley at icode.co.uk Tue Dec 16 07:29:45 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Tue, 16 Dec 2014 15:29:45 +0000 Subject: [Live-devel] liveMedia not sending any data on Windows with liveMedia 2014.12.13 Message-ID: <2a0938b7555543f19dcb474d9a6eff1e@SRV-EXCHANGE-2.icode.co.uk> Hi Ross. I've just updating our app to use liveMedia 2014.12.13 and have come across a problem with the recent changes for FD_SET in 2014.12.11. createSocket()/socket() on Windows are returning socket descriptors with values up on the high hundreds (880, 892, etc). This value gets passed to connect() which currently returns EWOULDBLOCK, and so is passed to setBackgroundHandling(). At this point, it hits the new FD_SETSIZE check: if (socketNum >= (int)(FD_SETSIZE)) return; (FD_SETSIZE is 64) This results in the background handling not being added and the connection not progressing any further. If I comment out that check then it connects as expected. I'm not sure on the BSD implementation, but isn't the actual limit (specified with FD_SETSIZE) a number of descriptors, not their absolute values? Also, on Windows, this limit can be redefined and increased so is not a hard limit in the API. http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141(v=vs.85).aspx What are your thoughts on this? Thanks -- Deanna Earley?|?Lead developer?|?icatchercctv w: www.icode.co.uk/icatcher | t: 01329 835335 | f: 01329 835338 Registered Office : 71 The Hundred, Romsey, SO51 8BZ. Company Number : 03428325 From finlayson at live555.com Tue Dec 16 09:48:34 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Dec 2014 06:48:34 +1300 Subject: [Live-devel] liveMedia not sending any data on Windows with liveMedia 2014.12.13 In-Reply-To: <2a0938b7555543f19dcb474d9a6eff1e@SRV-EXCHANGE-2.icode.co.uk> References: <2a0938b7555543f19dcb474d9a6eff1e@SRV-EXCHANGE-2.icode.co.uk> Message-ID: > I'm not sure on the BSD implementation, but isn't the actual limit (specified with FD_SETSIZE) a number of descriptors, not their absolute values? That?s a Windows-specific usage - so I?ve just released a new version (2014.12.16) that does not perform this check on Windows systems. Thanks for the report. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Dec 16 09:52:06 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Dec 2014 06:52:06 +1300 Subject: [Live-devel] RTCP APP packet handling In-Reply-To: References: Message-ID: > If we were to implement a way for a subclass of OnDemandMediaSubsession to provide a custom handler for APP packets, in a similar way that handlers are provided for the SR and RR packets, would you be likely to accept this as a patch? Yes. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak at relysys.co.in Tue Dec 16 05:00:59 2014 From: deepak at relysys.co.in (Deepak Agasibagil) Date: Tue, 16 Dec 2014 18:30:59 +0530 Subject: [Live-devel] openRTSP frame loss Message-ID: Hello, I am using 'ip-camera' to stream the video(output of ip-camera is in H.264 format) and i am using the openRTSP client capture the stream to a file in mp4 format. However, when i play the captured video i notice that first few seconds(1-2 sec) of video is not clear and while playing video it seems to be stopped and played again for evary 4-5 seconds gap. The command used to capture the video stream: openRTSP -d 20 -4 -b 5120000 -B 5120000 -f 15 -w 704 -h 576 \ "rtsp://admin:admin at 192.168.1.108:554/cam/realmonitor?channel=1&subtype=1" > open-rtsp-video.mp4 what is the correct way to capture the stream without loosing any frames. i had also altered the buffer size, but the problem is still present. -------------- next part -------------- An HTML attachment was scrubbed... URL: From u8818test at gmail.com Mon Dec 15 22:51:29 2014 From: u8818test at gmail.com (u8818test) Date: Tue, 16 Dec 2014 14:51:29 +0800 Subject: [Live-devel] About live555 support real time HLS Message-ID: <548FD66A.2080505@gmail.com> Hello, dear friend: I want to implement real time HLS by using live555, and I want to known that: 1.How does the index file(.m3u8 file) shoud be? 2.How to get source stream, the original stream source is H264 from camera or IPC, can I use the original stream source as the MPEG2 ts stream? 3.As the testH264VideoToTransportStream tool has something wrong with change H264 stream to ts stream when use the safari browser as the client, can you help me solve the problem? Really need your help, wait for your response, thans very much! 2014-12-16 u8818test -------------- next part -------------- An HTML attachment was scrubbed... URL: From isudox at gmail.com Tue Dec 16 19:15:04 2014 From: isudox at gmail.com (Jian Zhang) Date: Wed, 17 Dec 2014 11:15:04 +0800 Subject: [Live-devel] How to import live555 source code into eclipse project? Message-ID: Hi developers, I don't know how to import the source code into an eclipse project, give me some advises please. -------------- next part -------------- An HTML attachment was scrubbed... URL: From u8818test at gmail.com Wed Dec 17 00:46:34 2014 From: u8818test at gmail.com (u8818test) Date: Wed, 17 Dec 2014 16:46:34 +0800 Subject: [Live-devel] there is a bug when play HLS stream Message-ID: <549142E2.70502@gmail.com> When I use safari connect to live555 and request treansport stream, at each time of "getStreamParameters", like the following: ++fClientSessionId; Port clientRTPPort(0), clientRTCPPort(0), serverRTPPort(0), serverRTCPPort(0); netAddressBits destinationAddress = 0; u_int8_t destinationTTL = 0; Boolean isMulticast = False; void* streamToken; subsession->getStreamParameters(fClientSessionId, 0, clientRTPPort,clientRTCPPort, -1,0,0, \ destinationAddress,destinationTTL, isMulticast, serverRTPPort,serverRTCPPort, streamToken); it will do the proces: FramedSource* MPEG2TransportFileServerMediaSubsession ::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate) but the privious FramedSource create by createNewStreamSource have not been destroyed, and I have played the opened file point: ByteStreamFileSource *ByteStreamFileSource::createNew(UsageEnvironment& env, char const* fileName, unsigned preferredFrameSize, unsigned playTimePerFrame) { FILE* fid = OpenInputFile(env, fileName); if (fid == NULL) return NULL; printf("==========================fid is %p\n", fid); ByteStreamFileSource* newSource = new ByteStreamFileSource(env, fid, preferredFrameSize, playTimePerFrame); newSource->fFileSize = GetFileSize(fileName, fid); return newSource; } the output result is different with each other, I think this is a bug, as time go long, it will occupy all the fd, isn't it? 2014-12-17 u8818test -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 17 07:45:26 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Dec 2014 04:45:26 +1300 Subject: [Live-devel] there is a bug when play HLS stream In-Reply-To: <549142E2.70502@gmail.com> References: <549142E2.70502@gmail.com> Message-ID: Thanks for the note. Yes, you?re correct - this is a bug. I have just released a new version - 2014.12.17 - of the ?LIVE555 Streaming Media? code that fixes this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerith00 at yahoo.it Wed Dec 17 09:19:45 2014 From: aerith00 at yahoo.it (Barbara Pacella) Date: Wed, 17 Dec 2014 17:19:45 +0000 (UTC) Subject: [Live-devel] Discontinuous rtp stream using testOnDemandRtspServer with h264 mkv input files Message-ID: <1822689577.411485.1418836785014.JavaMail.yahoo@jws11160.mail.ir2.yahoo.com> Hi live555 staff. I'm trying to stream some .mkv files using testOnDemandRtspServer. Files are captured from an Axis IP Camera, transcoded using x264 and libavcodec API and muxed in mkv format using libavformat API, and contain a single video track. When i play the files locally using vlc or ffplay the files play well, but if I try to stream them using testonDemandRtspServer, the rtp stream is often discontinuous and both ffplay and vlc disconnect. I'm using the 20-11-2014 live555 tarball, built and run on Linux CentOS 5 32bit. I tried to stream the same files using the rtsp server provided by ffserver tool, and the output stream play well. You can download a sample .mkv file on https://dl.dropboxusercontent.com/u/35983566/test.mkv (is it ok to use links on this mailing list? I checked the FAQ and didn't find anything, I'm sorry if it isn't ok ) Please let me know if there is any incompatibility between the live555 server and the way the file is encoded/muxed (I could change x264 encoding parameters) or if this is a bug in the live555 lib. Kind Regards,Barbara ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Dec 17 17:26:26 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Dec 2014 14:26:26 +1300 Subject: [Live-devel] Discontinuous rtp stream using testOnDemandRtspServer with h264 mkv input files In-Reply-To: <1822689577.411485.1418836785014.JavaMail.yahoo@jws11160.mail.ir2.yahoo.com> References: <1822689577.411485.1418836785014.JavaMail.yahoo@jws11160.mail.ir2.yahoo.com> Message-ID: <92BED07C-1C22-4483-A42A-2B8787BDEC2E@live555.com> > You can download a sample .mkv file on https://dl.dropboxusercontent.com/u/35983566/test.mkv (is it ok to use links on this mailing list? Yes, of course - in fact, it?s far better to include a link to a large file than to try to include it in the email message. (On the other hand, it?s unprofessional email addresses - like ?@yahoo.? - that are discouraged on this mailing list :-) > Please let me know if there is any incompatibility between the live555 server and the way the file is encoded/muxed The problem with this file is that although frames appear in the file 40ms apart (i.e., indicating a frame rate of 25 frames-per-second), the SPS NAL unit (which appears in the file?s header) uses a time_scale of 300, which indicates 150 frames-per-second. (From what I can tell, our server is actually streaming the file properly - at 25 frames-per-second; however, it?s VLC that?s getting confused by the inconsistent time-scale that?s in the SPS NAL unit, so it thinks that the frame rate should be 150 frames-per-second.) So, there is a problem (inconsistency) in the way in which you encoded and/or recorded the frame rate, which you need to fix. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From imtmbest at nate.com Thu Dec 18 00:10:17 2014 From: imtmbest at nate.com (=?UTF-8?B?7KCV66qF7IiY?=) Date: Thu, 18 Dec 2014 17:10:17 +0900 Subject: [Live-devel] =?utf-8?q?Could_you_give_me_guide_how_to_stream_RTP_?= =?utf-8?q?live_source_to_RTSP_server=3F?= Message-ID: <0a68aba9204a40763835994c55d32c2e$23a7d99e@mail3.nate.com> An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Dec 18 01:54:29 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Dec 2014 22:54:29 +1300 Subject: [Live-devel] Could you give me guide how to stream RTP live source to RTSP server? In-Reply-To: <0a68aba9204a40763835994c55d32c2e$23a7d99e@mail3.nate.com> References: <0a68aba9204a40763835994c55d32c2e$23a7d99e@mail3.nate.com> Message-ID: <244FB4B7-2024-4D49-AC97-90BD99E7C011@live555.com> > On Dec 18, 2014, at 9:10 PM, ??? wrote: > > Hi. live555 list members. > I'm using your live555 libraries for my application. > I wanna set RTSP relay server with RTP source stream which contain H.264. Is your ?RTP source stream? accessible via RTSP? If so, you should use the ?LIVE555 Proxy Server?, which will require no additional programming: http://live555.com/proxyServer/ Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharmi.chatterjee at gmail.com Thu Dec 18 07:14:19 2014 From: sharmi.chatterjee at gmail.com (Sharmistha Chatterjee) Date: Thu, 18 Dec 2014 20:44:19 +0530 Subject: [Live-devel] SingleStep(): select() fails: Bad file descriptor Message-ID: Hi All, I am using live555ProxyServer in my multi-threaded application..The application will only use a single instance of proxyServer from only one of its thread. (no multi-thread handling of live555) I ran the proxyServer provided in the example, and was able to stream successfully from a VLC client. Then I changed the live555ProxyServer.cpp to start the event-loop from a pthread. The arvg argument of main was passed to the thread as void * and casted back inside the threadFunc. argv variables are coming correctly inside threadfunc . Also the TaskScheduler and BasicUsage environment variable was created inside the pthread. In other words, all the code from main function has been moved to a pthread. The event loop crashes inside BasicTaskScheduler:SingleStep. Can anyone please help with this problem, why it happens when I call eventloop from pthread func int main(int argc, char** argv) { pthread_t tid; void *status; pthread_create(&tid, NULL, threadfun, (void *)argv); printf("Created Pthread %d\n",*(int*)status); } Regards, sharmistha -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1273653716 at qq.com Thu Dec 18 19:24:12 2014 From: 1273653716 at qq.com (=?gb18030?B?U2ltb24=?=) Date: Fri, 19 Dec 2014 11:24:12 +0800 Subject: [Live-devel] Developed a Server, choose "RTSP-over-UDP" was ok, but choose "RTSP-over-TCP" was error Message-ID: Hi ALL. I developed a program modeled "testOnDemandRTSPServer" capture screen in real time, and then compressed into h264 and released. In the beginning the test, the client uses UDP to transmit data, the server is working properly. Then I want to test TCP mode, let the client choose RTSP over tcp, server performance is not normal, probably sent a few minutes after stop sending packets (using Wireshark capture). In debug mode, the server is still report "sending report, sending packet??". Until 65 seconds (default timeout) after the service side display "time out". Then I tried a variety of approaches to debug, still does not solve the problem. So to see the "live555MediaServer" source code and use it as a server test, the results "live555MediaServer" also have this problem, and greater the resolution of the video, there is a problem of time sooner. Remarks: 1. the server (live555 libraries and MediaServer): Version Dec 09 2014 2. the client has three: testRTSPClient, VLC (2.1.5), FFMpeg (N-67100, oct 22 2014). 3. if the server has consol window and enable DEBUG_SEND, then the server is working properly. Redirect "stderr" to file, the information: Play using the URL "rtsp://192.168.10.117/live" (We use port 80 for optional RTSP-over-HTTP tunneling.) accept()ed connection from 192.168.10.117 RTSPClientConnection[006B12E8]::handleRequestBytes() read 87 new bytes:OPTIONS rtsp://192.168.10.117:554/live RTSP/1.0 CSeq: 1 User-Agent: Lavf56.10.100 parseRTSPRequestString() succeeded, returning cmdName "OPTIONS", urlPreSuffix "", urlSuffix "live", CSeq "1", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 1 Date: Fri, Dec 19 2014 02:48:44 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER RTSPClientConnection[006B12E8]::handleRequestBytes() read 113 new bytes:DESCRIBE rtsp://192.168.10.117:554/live RTSP/1.0 Accept: application/sdp CSeq: 2 User-Agent: Lavf56.10.100 parseRTSPRequestString() succeeded, returning cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "live", CSeq "2", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 2 Date: Fri, Dec 19 2014 02:48:44 GMT Content-Base: rtsp://192.168.10.117/live/ Content-Type: application/sdp Content-Length: 503 v=0 o=- 1418957320293789 1 IN IP4 192.168.10.117 s=Session streamed by "testOnDemandRTSPServer" i=live t=0 0 a=tool:LIVE555 Streaming Media v2014.12.17 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer" a=x-qt-text-inf:live m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:96 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=64001F;sprop-parameter-sets=Z2QAH6zZQMgTflw4QAAAAwBAAAAMg8YMZYA=,aOvjyyLA a=control:track1 RTSPClientConnection[006B12E8]::handleRequestBytes() read 136 new bytes:SETUP rtsp://192.168.10.117/live/track1 RTSP/1.0 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 CSeq: 3 User-Agent: Lavf56.10.100 parseRTSPRequestString() succeeded, returning cmdName "SETUP", urlPreSuffix "live", urlSuffix "track1", CSeq "3", Content-Length 0, with 0 bytes following the message. sending response: RTSP/1.0 200 OK CSeq: 3 Date: Fri, Dec 19 2014 02:48:44 GMT Transport: RTP/AVP/TCP;unicast;destination=192.168.10.117;source=192.168.10.117;interleaved=0-1 Session: 866DBD85;timeout=65 RTSPClientConnection[006B12E8]::handleRequestBytes() read 119 new bytes:PLAY rtsp://192.168.10.117/live/ RTSP/1.0 Range: npt=0.000- CSeq: 4 User-Agent: Lavf56.10.100 Session: 866DBD85 parseRTSPRequestString() succeeded, returning cmdName "PLAY", urlPreSuffix "live", urlSuffix "", CSeq "4", Content-Length 0, with 0 bytes following the message. RTCPInstance[0074CAE8]::RTCPInstance() schedule(1.778641->1418957326.302863) SocketDescriptor(socket 528)::registerRTPInterface(channel 0): isFirstRegistration 1 SocketDescriptor(socket 528)::registerRTPInterface(channel 1): isFirstRegistration 0 SocketDescriptor(socket 528)::registerRTPInterface(channel 1): isFirstRegistration 0 sending REPORT sending RTCP packet 80c80006 efcaaa68 d83e108c 8634eb9a ee023e83 00000000 00000000 81ca0005 efcaaa68 010d5869 654d696e 677a616e 2d706300 sendRTPorRTCPPacketOverTCP: 52 bytes over channel 1 (socket 528) sendRTPorRTCPPacketOverTCP: completed sendRTPorRTCPPacketOverTCP: 492 bytes over channel 0 (socket 528) sendRTPorRTCPPacketOverTCP: completed sending response: RTSP/1.0 200 OK CSeq: 4 Date: Fri, Dec 19 2014 02:48:44 GMT Range: npt=0.000- Session: 866DBD85 RTP-Info: url=rtsp://192.168.10.117/live/track1;seq=59383;rtptime=3993136724 sendRTPorRTCPPacketOverTCP: 42 bytes over channel 0 (socket 528) sendRTPorRTCPPacketOverTCP: completed sendRTPorRTCPPacketOverTCP: 20 bytes over channel 0 (socket 528) sendRTPorRTCPPacketOverTCP: completed sendRTPorRTCPPacketOverTCP: 1456 bytes over channel 0 (socket 528) sendRTPorRTCPPacketOverTCP: completed sendRTPorRTCPPacketOverTCP: 1456 bytes over channel 0 (socket 528) sendRTPorRTCPPacketOverTCP: completed ...... ...... ...... sendRTPorRTCPPacketOverTCP: completed sendRTPorRTCPPacketOverTCP: 1456 bytes over channel 0 (socket 528) SocketDescriptor(socket 528)::deregisterRTPInterface(channel 255) sendRTPorRTCPPacketOverTCP: failed! (errno 10035) sending REPORT sending RTCP packet 80c80006 efcaaa68 d83e1097 b6290eed ee119b9d 000007c9 002b16e4 81ca0005 efcaaa68 010d5869 654d696e 677a616e 2d706300 schedule(3.052983->1418957338.764567) schedule(1.448056->1418957340.220447) sending REPORT ...... ...... ...... sending REPORT sending RTCP packet 80c80006 efcaaa68 d83e10c9 04cc4695 ee55522b 00000c7f 003f286f 81ca0005 efcaaa68 010d5869 654d696e 677a616e 2d706300 schedule(4.098311->1418957389.117072) sending REPORT sending RTCP packet 80c80006 efcaaa68 d83e10cd 329e6eeb ee5b0f58 00000de7 00467069 81ca0005 efcaaa68 010d5869 654d696e 677a616e 2d706300 schedule(5.901020->1418957395.098769) RTSP client session (id "866DBD85", stream name "live") has timed out (due to inactivity) RTCPInstance[0074CAE8]::~RTCPInstance() sending BYE sending RTCP packet 80c80006 efcaaa68 d83e10cd 89e1198b ee5b872d 00000ded 004687c5 81cb0001 efcaaa68 RTSPClientConnection[006B12E8]::handleRequestBytes() read -1 new bytes (of 20000); terminating connection! Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From backerman at icontrol.com Fri Dec 19 12:21:54 2014 From: backerman at icontrol.com (Braden Ackerman) Date: Fri, 19 Dec 2014 20:21:54 +0000 Subject: [Live-devel] iOS Simulator config update Message-ID: <1419020513800.20442@icontrol.com> Live555ers,? I ran into a situation where I needed to run my project on the iOS simulator, so I fixed up the config.iphone-simulator so that it's compatible with the latest version of Xcode and the iOS SDK. # **Note: You must install the relevant "Command line tools (OSX *.*) for Xcode - Xcode *.*" # for this configuration file to work. # Change the following version number, if necessary, before running "genMakefiles iphoneos" IOS_VERSION = 8.1 MIN_IOS_VERSION = 7.0 DEVELOPER_PATH = /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer TOOL_PATH = $(DEVELOPER_PATH)/usr/bin SDK_PATH = $(DEVELOPER_PATH)/SDKs SDK = $(SDK_PATH)/iPhoneSimulator$(IOS_VERSION).sdk COMPILE_OPTS = $(INCLUDES) -I. $(EXTRA_LDFLAGS) -DBSD=1 -O2 -DSOCKLEN_T=socklen_t -DHAVE_SOCKADDR_LEN=1 -miphoneos-version-min=$(MIN_IOS_VERSION) -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 -fPIC -arch i386 --sysroot=$(SDK) -isysroot $(SDK) C = c C_COMPILER = /usr/bin/xcrun clang C_FLAGS = $(COMPILE_OPTS) CPP = cpp CPLUSPLUS_COMPILER = /usr/bin/xcrun clang CPLUSPLUS_FLAGS = $(COMPILE_OPTS) -Wall OBJ = o LINK = /usr/bin/xcrun clang -o LINK_OPTS = -L. -arch i386 -miphoneos-version-min=$(MIN_IOS_VERSION) --sysroot=$(SDK) -isysroot $(SDK) -L$(SDK)/usr/lib/system -I$(SDK)/usr/lib /usr/lib/libc++.dylib CONSOLE_LINK_OPTS = $(LINK_OPTS) LIBRARY_LINK = libtool -s -o LIBRARY_LINK_OPTS = LIB_SUFFIX = a LIBS_FOR_CONSOLE_APPLICATION = LIBS_FOR_GUI_APPLICATION = EXE = Also, as Apple requires all apps to have arm64 support by February, I wrote a bash script to compile live555 for arm7, arm7s, arm64, i386, x86_64. It downloads live555-latest.tar.gz and uses it. However, it depends on the updated config.iphone-simulator to work. For now, the script points to a copy of live555-latest with config.iphone-simulator replaced hosted on my website. When/if config.iphone-simulator is replaced on the live555.com hosted tar the url in the bash script can be changed away from bradenackerman.com Ross: Not sure if you want to distribute this with releases. It's here for anyone who reads the mailing list to use anywho :) (Script follows) Best regards, Braden Ackerman ##### --> live555 universal library for iOS build script by Braden Ackerman (braden.ackerman+l555 at gmail.com) <-- ##### # **NOTE: 'Command Line Tools' (appropriate for iOS SDK version and MacOSX version) must be installed for this script to work. # When this script completes, you should be left with a folder 'fat' which contains universal libs for the archs in PHONEARCHS + PCARCHS LIVEFILE=live555-latest.tar.gz PHONEARCHS=( armv7 armv7s arm64 ) LIBNAMES=( libliveMedia.a libgroupsock.a libUsageEnvironment.a libBasicUsageEnvironment.a ) PCARCHS=( i386 x86_64 ) ROOTDIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd ) ####### -- First, we'll download the live555 source and extract it to the current directory #curl http://www.live555.com/liveMedia/public/$LIVEFILE > $LIVEFILE curl http://www.bradenackerman.com/$LIVEFILE > $LIVEFILE ####### --- Second, make some arm libs rm -r -f arms mkdir $ROOTDIR/arms for i in ${PHONEARCHS[@]} do rm -r -f live tar -zxvf $LIVEFILE chmod -R u+rwX,a+rX live echo $i sed -i.bak 's/armv7/'$i'/g' live/config.iphoneos cd live ./genMakeFiles iphoneos make cd liveMedia mkdir $ROOTDIR/arms/$i cp libliveMedia.a $ROOTDIR/arms/$i cd .. cd groupsock mkdir $ROOTDIR/arms/$i cp libgroupsock.a $ROOTDIR/arms/$i cd .. cd UsageEnvironment mkdir $ROOTDIR/arms/$i cp libUsageEnvironment.a $ROOTDIR/arms/$i cd .. cd BasicUsageEnvironment mkdir $ROOTDIR/arms/$i cp libBasicUsageEnvironment.a $ROOTDIR/arms/$i cd .. cd .. done ####### --- Third, make some PC libs rm -r -f $ROOTDIR/pc mkdir $ROOTDIR/pc for i in ${PCARCHS[@]} do rm -r -f live tar -zxvf $LIVEFILE chmod -R u+rwX,a+rX live echo $i sed -i.bak 's/i386/'$i'/g' live/config.iphone-simulator cd live ./genMakeFiles iphone-simulator make cd liveMedia mkdir $ROOTDIR/pc/$i cp libliveMedia.a $ROOTDIR/pc/$i cd .. cd groupsock mkdir $ROOTDIR/pc/$i cp libgroupsock.a $ROOTDIR/pc/$i cd .. cd UsageEnvironment mkdir $ROOTDIR/pc/$i cp libUsageEnvironment.a $ROOTDIR/pc/$i cd .. cd BasicUsageEnvironment mkdir $ROOTDIR/pc/$i cp libBasicUsageEnvironment.a $ROOTDIR/pc/$i cd .. cd .. done ###### Fourth, we'll LIPO together all of our libraries mkdir $ROOTDIR/fat for i in ${LIBNAMES[@]} do lipo -output $ROOTDIR/fat/$i -create \ -arch armv7 $ROOTDIR/arms/armv7/$i \ -arch armv7s $ROOTDIR/arms/armv7s/$i \ -arch arm64 $ROOTDIR/arms/arm64/$i \ -arch i386 $ROOTDIR/pc/i386/$i \ -arch x86_64 $ROOTDIR/pc/x86_64/$i done ##### Fifth, clean up our mess rm -r -f $ROOTDIR/arms rm -r -f $ROOTDIR/pc rm -r -f $ROOTDIR/live -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 19 14:14:12 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 20 Dec 2014 11:14:12 +1300 Subject: [Live-devel] Developed a Server, choose "RTSP-over-UDP" was ok, but choose "RTSP-over-TCP" was error In-Reply-To: References: Message-ID: <9E341F6B-D632-4A09-87D4-FC750ADF8B8E@live555.com> Your debugging trace doesn?t show any RTCP packets received by the server (and sent by the client). RTCP packets are how the client tells the server that it is still alive. However, I have just tested our latest client software (?openRTSP -t?) with our latest server software (?testOnDemandRTSPServer?), and have confirmed that the client does (still) send RTCP packets (when streaming over UDP or TCP), and the server (still) does receive them (and use them to indicate client liveness). I conclude, therefore, that you have modified the supplied software in some way, and therefore I can?t help you. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Dec 19 18:28:39 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 20 Dec 2014 15:28:39 +1300 Subject: [Live-devel] iOS Simulator config update In-Reply-To: <1419020513800.20442@icontrol.com> References: <1419020513800.20442@icontrol.com> Message-ID: <2D75F876-2FE5-4B31-89CC-1EB8E4B41CEB@live555.com> > I ran into a situation where I needed to run my project on the iOS simulator, so I fixed up the config.iphone-simulator so that it's compatible with the latest version of Xcode and the iOS SDK. Thanks. This will be included in the next release of the software. > Also, as Apple requires all apps to have arm64 support by February, I wrote a bash script to compile live555 for arm7, arm7s, arm64, i386, x86_64. > It downloads live555-latest.tar.gz and uses it. However, it depends on the updated config.iphone-simulator to work. > For now, the script points to a copy of live555-latest with config.iphone-simulator replaced hosted on my website. > When/if config.iphone-simulator is replaced on the live555.com hosted tar the url in the bash script can be changed away from bradenackerman.com > > Ross: Not sure if you want to distribute this with releases. It's here for anyone who reads the mailing list to use anywho :) Because you?re the person right now who?s maintaining this, I?ll probably just let you host the script on your web site, and I?ll add a link to it (from >). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1273653716 at qq.com Fri Dec 19 19:31:41 2014 From: 1273653716 at qq.com (=?gb18030?B?U2ltb24=?=) Date: Sat, 20 Dec 2014 11:31:41 +0800 Subject: [Live-devel] =?gb18030?b?u9i4tKO6ICBEZXZlbG9wZWQgYSBTZXJ2ZXIsIGNo?= =?gb18030?q?oose_=22RTSP-over-UDP=22_was_ok=2Cbut__choose_=22RTSP-over-TC?= =?gb18030?q?P=22_was_error?= In-Reply-To: <9E341F6B-D632-4A09-87D4-FC750ADF8B8E@live555.com> References: <9E341F6B-D632-4A09-87D4-FC750ADF8B8E@live555.com> Message-ID: thank you. this question was resolve. modify RTPInterface.cpp::line 328. before: if (!sendDataOverTCP(socketNum, framingHeader, 4, False)) break; after: if (!sendDataOverTCP(socketNum, framingHeader, 4, True)) break; Simon 1273653716 at qq.com ------------------ ???? ------------------ ???: "Ross Finlayson";; ????: 2014?12?20?(???) ??6:14 ???: "LIVE555 Streaming Media - development & use"; ??: Re: [Live-devel] Developed a Server, choose "RTSP-over-UDP" was ok,but choose "RTSP-over-TCP" was error Your debugging trace doesn?t show any RTCP packets received by the server (and sent by the client). RTCP packets are how the client tells the server that it is still alive. However, I have just tested our latest client software (?openRTSP -t?) with our latest server software (?testOnDemandRTSPServer?), and have confirmed that the client does (still) send RTCP packets (when streaming over UDP or TCP), and the server (still) does receive them (and use them to indicate client liveness). I conclude, therefore, that you have modified the supplied software in some way, and therefore I can?t help you. Sorry. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From u8818test at gmail.com Sat Dec 20 01:42:33 2014 From: u8818test at gmail.com (u8818test) Date: Sat, 20 Dec 2014 17:42:33 +0800 Subject: [Live-devel] About removeServerMediaSession process Message-ID: <549544ac.0476460a.7279.147a@mx.google.com> Hello, dear friend: when I usr tests my hls process, the first time request the stream , faild, and the request the stream again, at the second time of request when the DynamicRTSPServer::lookupServerMediaSession to deal removeServerMediaSession process,: 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; } gets a segment fault error, I follow the running process, it failed at the step of Medium::close: void RTSPServer::removeServerMediaSession(ServerMediaSession* serverMediaSession) { if (serverMediaSession == NULL) return; fServerMediaSessions->Remove(serverMediaSession->streamName()); if (serverMediaSession->referenceCount() == 0) { printf("Medium::close(serverMediaSession);\n"); Medium::close(serverMediaSession); } else { serverMediaSession->deleteWhenUnreferenced() = True; } printf("out removeServerMediaSession(ServerMediaSession* serverMediaSession)\n"); } the attachment is the http message, before the segment fault, it output the message "Medium::close(serverMediaSession);", what may cause the problem, can you help me? 2014-12-20 u8818test -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: http message.txt Type: application/octet-stream Size: 986 bytes Desc: not available URL: From finlayson at live555.com Sun Dec 21 17:17:23 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Dec 2014 14:17:23 +1300 Subject: [Live-devel] Developed a Server, choose "RTSP-over-UDP" was ok, but choose "RTSP-over-TCP" was error In-Reply-To: References: <9E341F6B-D632-4A09-87D4-FC750ADF8B8E@live555.com> Message-ID: Sorry, but the original code is correct. The ?False? parameter tells the code not to block when writing the framing header for a RTP(or RTCP)-over-TCP packet. This is appropriate, because these packets - although being sent over a TCP connection - are still ?datagrams?, and are not all delivered reliably. Blocking while writing these packets is not appropriate, because it will starve other events from happening. If you find that *no* RTCP packets from the client are being transmitted over the TCP connection (without changing the code to block while doing so), then this tells you that your TCP connection is badly congested, and you should not be using RTP/RTCP-over-TCP. (Because you have modified the supplied code (and because you use an unprofessional email address), you can expect no further support on this mailing list.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 22 00:55:57 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Dec 2014 21:55:57 +1300 Subject: [Live-devel] About removeServerMediaSession process In-Reply-To: <549544ac.0476460a.7279.147a@mx.google.com> References: <549544ac.0476460a.7279.147a@mx.google.com> Message-ID: <005EBD8B-47B6-44C9-B6FC-380DDA5DC7E1@live555.com> The ?DynamicRTSPServer? class was intended to be used only for streaming from files - not arbitrary streams - and was intended for the ?LIVE555 Media Server? product only. If you want to (try to) support 'HTTP Live Streaming? in your own server, then you should use the ?RTSPServerSupportingHTTPStreaming? class; not the "DynamicRTSPServer? class that derives from it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Admin at sorinetgroup.net Mon Dec 22 02:06:04 2014 From: Admin at sorinetgroup.net (Administrator) Date: Mon, 22 Dec 2014 13:36:04 +0330 Subject: [Live-devel] current position, time problem Message-ID: <755678187-5068@mail.sorinetgroup.net> Dear Ross: With all respects , i was wondering (and i appreciate) if it's possible for you , then i can make a contribution to this great project , so that may be you can at least , only one time , make the code witch support of Amino Get_Parameter . i followed the link you said about , i added that patch to the source , now the time is showing , but when we use trick_play (Fast forward or rewind) then again the time shows wrong values , and fixing it is far beyond my knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 22 02:44:38 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Dec 2014 23:44:38 +1300 Subject: [Live-devel] current position, time problem In-Reply-To: <755678187-5068@mail.sorinetgroup.net> References: <755678187-5068@mail.sorinetgroup.net> Message-ID: <1DBA125D-C093-47D4-8D4A-512F69B245E0@live555.com> No. See http://lists.live555.com/pipermail/live-devel/2013-October/017626.html Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Admin at sorinetgroup.net Mon Dec 22 03:11:22 2014 From: Admin at sorinetgroup.net (Administrator) Date: Mon, 22 Dec 2014 14:41:22 +0330 Subject: [Live-devel] current position, time problem Message-ID: <759937888-5560@mail.sorinetgroup.net> Thank you very much. I've? contacted them in the past , but they think their devices are standard :))))) Here is their answer to me: " Our boxes are standards compliant so should work with most media servers."? Anyway , these devices were here before i got here. So i have to find a way to make them work. But in the future, i will buy only standard devices :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 22 03:17:45 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Dec 2014 00:17:45 +1300 Subject: [Live-devel] current position, time problem In-Reply-To: <759937888-5560@mail.sorinetgroup.net> References: <759937888-5560@mail.sorinetgroup.net> Message-ID: > I've contacted them in the past , but they think their devices are standard :))))) > Here is their answer to me: " Our boxes are standards compliant so should work with most media servers.? Tell them to get in touch with me. I?d be happy to set them straight :-) > But in the future, i will buy only standard devices :-) Yes, please do. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From backerman at icontrol.com Mon Dec 22 15:48:46 2014 From: backerman at icontrol.com (Braden Ackerman) Date: Mon, 22 Dec 2014 23:48:46 +0000 Subject: [Live-devel] iOS Simulator config update (Ross Finlayson) Message-ID: <1419292126073.20363@icontrol.com> Ross, The script I mentioned last week is now available at: http://www.bradenackerman.com/live555_multiArch.sh It will start working once the next version of live555 is available on live555.com as it depends on the updated config.iphoneos-simulator Best regards, Braden Ackerman -------------- next part -------------- An HTML attachment was scrubbed... URL: From dee.earley at icode.co.uk Tue Dec 23 03:41:22 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Tue, 23 Dec 2014 11:41:22 +0000 Subject: [Live-devel] Ignoring an unwanted track Message-ID: <6571c13df13f43dda864ab3471b47596@SRV-EXCHANGE-2.icode.co.uk> Hello Ross. We have some situations where we're not interested in a particular track. Currently we create and assign a "null sink" that does nothing in afterGettingFrame() except call continuePlaying(). Is there a safe way to drop this track and not try and set it up and receive it in the first place? It looks like I can set no sink, and in turn not call startPlaying(), but is there anything I need to do instead? 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 From finlayson at live555.com Tue Dec 23 08:03:31 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Dec 2014 05:03:31 +1300 Subject: [Live-devel] Ignoring an unwanted track In-Reply-To: <6571c13df13f43dda864ab3471b47596@SRV-EXCHANGE-2.icode.co.uk> References: <6571c13df13f43dda864ab3471b47596@SRV-EXCHANGE-2.icode.co.uk> Message-ID: > We have some situations where we're not interested in a particular track. > Currently we create and assign a "null sink" that does nothing in afterGettingFrame() except call continuePlaying(). > > Is there a safe way to drop this track and not try and set it up and receive it in the first place? I assume (from the context of your email) that you?re talking about a RTSP client. The best way to ignore a particular track (?MediaSubsession?) is to: 1/ not call ?MediaSubsession::initiate()? on it, and then 2/ not send ?RTSPClient::sendSetupCommand()? on it. Note that you can call "subsession->readSource()->MIMEtype()? to get the media type of each track (e.g., ?video/H264?), if you wan to check that. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dee.earley at icode.co.uk Tue Dec 23 08:08:09 2014 From: dee.earley at icode.co.uk (Deanna Earley) Date: Tue, 23 Dec 2014 16:08:09 +0000 Subject: [Live-devel] Ignoring an unwanted track In-Reply-To: <6571c13df13f43dda864ab3471b47596@SRV-EXCHANGE-2.icode.co.uk> References: <6571c13df13f43dda864ab3471b47596@SRV-EXCHANGE-2.icode.co.uk> Message-ID: <3249eb3809264549a5852f660a659e52@SRV-EXCHANGE-2.icode.co.uk> Looking further up the code, I've found the code that enumerates all subsessions and passes them to RTSPClient::sendSetupCommand(). Skipping them here (along with MediaSubsession::initiate()) leaves them untouched and won't be requested. Have a good Christmas :) -- 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 > -----Original Message----- > From: live-devel [mailto:live-devel-bounces at ns.live555.com] On Behalf Of > Deanna Earley > Sent: 23 December 2014 11:41 > To: 'live-devel at lists.live555.com' > Subject: [Live-devel] Ignoring an unwanted track > > Hello Ross. > > We have some situations where we're not interested in a particular track. > Currently we create and assign a "null sink" that does nothing in > afterGettingFrame() except call continuePlaying(). > > Is there a safe way to drop this track and not try and set it up and > receive it in the first place? > > It looks like I can set no sink, and in turn not call startPlaying(), but > is there anything I need to do instead? > > 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 > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From Devaprasad.ChandranM at Honeywell.com Tue Dec 23 01:35:19 2014 From: Devaprasad.ChandranM at Honeywell.com (Chandran M, Devaprasad) Date: Tue, 23 Dec 2014 09:35:19 +0000 Subject: [Live-devel] isCurrentlyAwaitingData usage Message-ID: <678A43434B81AC45A1CE04B5407A9A5E01569E41@IE1AEX3007.global.ds.honeywell.com> Hi , Please let me know the function details of "isCurrentlyAwaitingData()" in FrameSource.hh, what is the use of the function. This function at times returns false. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shubham.argie at gmail.com Tue Dec 23 02:23:49 2014 From: shubham.argie at gmail.com (Shubham Goyal) Date: Tue, 23 Dec 2014 18:23:49 +0800 Subject: [Live-devel] H264 Live Input Issue Message-ID: <578B40ED-12BB-49ED-90A4-A8265BD8A4DE@gmail.com> Hi all Based on the FAQ for live input, I wrote my own subclasses for FramedSource and OnDemandServerMediaSubsession to implement a unicast server that can stream a live input. My live input source is a H264 encoded frame grab of my desktop using the Nvidia GRID SDK (which internally uses Nvenc.) Before passing the frames to live555 I also removed the start codes in every frame and created a queue of NAL units. The first frame of every stream contains 3 NALs. And a single NAL in every subsequent frame. An example of the output: Start code found in frame 1 NAL size: 24 67 42 C0 0D 95 A0 D3 F9 67 C0 52 83 02 03 20 00 00 7D 00 00 1D 4C 10 80 Start code found in frame 1 NAL size: 4 68 CE 3C 80 Start code found in frame 1 NAL size: 3228 65 B8 04 7F C4 44 D4 08 00 0C 07 8A 00 02 01 D3 58 0E 93 93 00 2D 11 F3 D9 04 BA 48 99 6A 65 D3 81 79 07 92 B2 95 81 1D BD CF E4 70 86 7E F1 41 B9 35 76 9C 28 2 A E6 3D 30 6A 2E C0 99 91 99 2F 22 3E FF 19 54 3B 13 4C C0 38 15 7F F2 7E FB CD ? //a lot of data, removed for readability 5B 5B 5B 5B 5F 6B FF FF C1 54 20 04 E7 38 40 25 29 41 C0 04 00 43 3C 1C 00 40 08 67 Start code found in frame 2 // Note: second frame here NAL size: 1820 61 E0 20 BF C6 C1 23 80 78 54 98 07 2C C0 09 50 7A A4 C0 72 CA 91 8F 2D E5 00 4E 82 01 04 03 A1 8B 24 A2 9C B5 F1 98 E0 3E 08 0C 0A 85 00 CF 12 05 E3 B1 36 82 F0 ? //a lot of data, removed for readability CC 65 72 DF FF D8 83 F3 A6 53 3F C4 2E 21 71 0B 88 5C 42 E2 17 10 BF 70 1C 43 2 A 4B 03 88 65 49 6F //Third frame.. and so forth Upon playing the RTSP stream using VLC my output is blank. VLC is receiving data because the seconds clock in VLC starts ticking as soon as the stream is played but the output is completely blank. I tried a lot of combinations in sending the data including the start codes, sending individual/multiple NALs per frame, but nothing is working. I was not sure if my data was correct, so I wrote it to a file (with start codes) and the file played back successfully. I even streamed the file using the ?testOnDemandRTSPServer? test program and that worked too. There is definitely something that isn?t right and I?m not able to figure it out. Would appreciate if somebody could point me in the right direction. I am including some of my source code below for reference. Thanks, Shubham ??testOnDemandRTSPServer.cpp?? //Live h264 based GRID stream //Note: This is only a part of the file, not the entire file { char const* streamName = "grid"; ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); sms->addSubsession(GridServerMediaSubsession::createNew(*env, reuseFirstSource)); rtspServer->addServerMediaSession(sms); announceStream(rtspServer, sms, streamName, "no file"); } ??testOnDemandRTSPServer.cpp?? ??GridServerMediaSubsession.cpp?? #include "GridServerMediaSubsession.hh" #include "H264VideoRTPSink.hh" #include "GridSource.hh" #include "H264VideoStreamDiscreteFramer.hh" GridServerMediaSubsession* GridServerMediaSubsession::createNew(UsageEnvironment& env, Boolean reuseFirstSource) { return new GridServerMediaSubsession(env, reuseFirstSource); } GridServerMediaSubsession::GridServerMediaSubsession(UsageEnvironment& env, Boolean reuseFirstSource) : OnDemandServerMediaSubsession(env, reuseFirstSource) { } GridServerMediaSubsession::~GridServerMediaSubsession() { } FramedSource* GridServerMediaSubsession::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 700; // kbps, estimate // Create the video source: GridSource* liveSource = GridSource::createNew(envir()); // Create a framer for the Video Elementary Stream: return H264VideoStreamDiscreteFramer::createNew(envir(), liveSource); } RTPSink* GridServerMediaSubsession ::createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* /*inputSource*/) { return H264VideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); ??GridServerMediaSubsession.cpp?? ?? GridSource.cpp ?? GridSource* GridSource::createNew(UsageEnvironment& env) { AppArguments args; //for input configuration //some code removed for readability return new GridSource(env, args); } EventTriggerId GridSource::eventTriggerId = 0; unsigned GridSource::referenceCount = 0; unsigned GridSource::frameCount = 0; GridSource::GridSource(UsageEnvironment& env, AppArguments args) : FramedSource(env), fargs(args) { if (referenceCount == 0) { //encoder is initialised here. Some code removed for readability } ++referenceCount; if (eventTriggerId == 0) { eventTriggerId = envir().taskScheduler().createEventTrigger(deliverFrame0); } } GridSource::~GridSource() { --referenceCount; if (referenceCount == 0) { if (encoder) { encoder->NvFBCH264Release(); } // Reclaim our 'event trigger' envir().taskScheduler().deleteEventTrigger(eventTriggerId); eventTriggerId = 0; } } void GridSource::doGetNextFrame() { //Note: next frame is read only after previous frame?s NALs have been delivered. if(nalQ.isEmpty()){ frameCount++; populateQ(); //load the NALs for each frame. NALs stored in nalQ } deliverFrame(); } void GridSource::deliverFrame0(void* clientData) { ((GridSource*)clientData)->deliverFrame(); } void GridSource::populateQ(){ //frame is grabbed by the GRID SDK //NALs for every frame are pushed to nalQ //Some code removed for readability while(/*frame data is available in frame buffer*/){ if(/*star code found in frame buffer*/) nalQ.pushNAL(outputPtr,byteSize); //data until next start code or until end of buffer - Note: data excludes start codes } } void GridSource::deliverFrame() { if (!isCurrentlyAwaitingData()) return; // we're not ready for the data yet NAL* nal = nalQ.popNAL(); nal->print(); // Deliver the data here: if (nal->getSize() > fMaxSize) { fFrameSize = fMaxSize; fNumTruncatedBytes = nal->getSize() - fMaxSize; } else { fFrameSize = nal->getSize(); } gettimeofday(&fPresentationTime, NULL); fDurationInMicroseconds = 1000000/30; //30 fps memmove(fTo, nal->getPayload(), fFrameSize); // After delivering the data, inform the reader that it is now available: FramedSource::afterGetting(this); } ??GridSource.cpp?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin at speed666.info Tue Dec 23 15:11:44 2014 From: marcin at speed666.info (Marcin) Date: Wed, 24 Dec 2014 00:11:44 +0100 Subject: [Live-devel] H264 Live Input Issue In-Reply-To: <578B40ED-12BB-49ED-90A4-A8265BD8A4DE@gmail.com> References: <578B40ED-12BB-49ED-90A4-A8265BD8A4DE@gmail.com> Message-ID: <5499F6B0.9080305@speed666.info> Hi, Do you have SPS and PPS being passed from Live Input and are they okay? Marcin W dniu 2014-12-23 o 11:23, Shubham Goyal pisze: > Hi all > > Based on the FAQ for live input, I wrote my own subclasses for > FramedSource and OnDemandServerMediaSubsession to implement a unicast > server that can stream a live input. My live input source is a H264 > encoded frame grab of my desktop using the Nvidia GRID SDK (which > internally uses Nvenc.) > > Before passing the frames to live555 I also removed the start codes in > every frame and created a queue of NAL units. The first frame of every > stream contains 3 NALs. And a single NAL in every subsequent frame. An > example of the output: > > Start code found in frame 1 > NAL size: 24 > 67 42 C0 0D 95 A0 D3 F9 67 C0 52 83 02 03 20 00 00 7D 00 00 1D 4C 10 80 > > Start code found in frame 1 > NAL size: 4 > 68 CE 3C 80 > > Start code found in frame 1 > NAL size: 3228 > 65 B8 04 7F C4 44 D4 08 00 0C 07 8A 00 02 01 D3 58 0E 93 93 00 2D 11 > F3 D9 04 BA > 48 99 6A 65 D3 81 79 07 92 B2 95 81 1D BD CF E4 70 86 7E F1 41 B9 35 > 76 9C 28 2 > A E6 3D 30 6A 2E C0 99 91 99 2F 22 3E FF 19 54 3B 13 4C C0 38 15 7F F2 > 7E FB CD > ? //a lot of data, removed for readability > 5B 5B 5B 5B 5F 6B FF FF C1 54 20 04 E7 38 40 25 29 41 C0 04 00 43 3C > 1C 00 40 08 > 67 > > Start code found in frame 2 // Note: second frame here > NAL size: 1820 > 61 E0 20 BF C6 C1 23 80 78 54 98 07 2C C0 09 50 7A A4 C0 72 CA 91 8F > 2D E5 00 4E > 82 01 04 03 A1 8B 24 A2 9C B5 F1 98 E0 3E 08 0C 0A 85 00 CF 12 05 E3 > B1 36 82 F0 > ? //a lot of data, removed for readability > CC 65 72 DF FF D8 83 F3 A6 53 3F C4 2E 21 71 0B 88 5C 42 E2 17 10 BF > 70 1C 43 2 > A 4B 03 88 65 49 6F > > //Third frame.. and so forth > > Upon playing the RTSP stream using VLC my output is blank. VLC is > receiving data because the seconds clock in VLC starts ticking as soon > as the stream is played but the output is completely blank. I tried a > lot of combinations in sending the data including the start codes, > sending individual/multiple NALs per frame, but nothing is working. I > was not sure if my data was correct, so I wrote it to a file (with > start codes) and the file played back successfully. I even streamed > the file using the ?testOnDemandRTSPServer? test program and that > worked too. There is definitely something that isn?t right and I?m not > able to figure it out. Would appreciate if somebody could point me in > the right direction. I am including some of my source code below for > reference. > > Thanks, > Shubham > > *??testOnDemandRTSPServer.cpp?? * > //Live h264 based GRID stream > //Note: This is only a part of the file, not the entire file > { > char const* streamName = "grid"; > ServerMediaSession* sms > = ServerMediaSession::createNew(*env, streamName, streamName, > descriptionString); > sms->addSubsession(GridServerMediaSubsession::createNew(*env, > reuseFirstSource)); > rtspServer->addServerMediaSession(sms); > > announceStream(rtspServer, sms, streamName, "no file"); > } > *??testOnDemandRTSPServer.cpp?? * > > *??GridServerMediaSubsession.cpp??* > #include"GridServerMediaSubsession.hh" > #include"H264VideoRTPSink.hh" > #include"GridSource.hh" > #include"H264VideoStreamDiscreteFramer.hh" > > GridServerMediaSubsession* > GridServerMediaSubsession::createNew(UsageEnvironment& env, > Boolean reuseFirstSource) { > return new GridServerMediaSubsession(env, reuseFirstSource); > } > > GridServerMediaSubsession::GridServerMediaSubsession(UsageEnvironment& > env, Boolean reuseFirstSource) > : OnDemandServerMediaSubsession(env, reuseFirstSource) { > } > > GridServerMediaSubsession::~GridServerMediaSubsession() { > } > > FramedSource* > GridServerMediaSubsession::createNewStreamSource(unsigned > /*clientSessionId*/, unsigned& estBitrate) { > estBitrate = 700; // kbps, estimate > > // Create the video source: > GridSource* liveSource = GridSource::createNew(envir()); > > // Create a framer for the Video Elementary Stream: > return H264VideoStreamDiscreteFramer::createNew(envir(), liveSource); > } > > RTPSink* GridServerMediaSubsession > ::createNewRTPSink(Groupsock* rtpGroupsock, > unsigned char rtpPayloadTypeIfDynamic, > FramedSource* /*inputSource*/) { > return H264VideoRTPSink::createNew(envir(), rtpGroupsock, > rtpPayloadTypeIfDynamic); > *??GridServerMediaSubsession.cpp??* > > *?? GridSource.cpp ??* > > GridSource* > GridSource::createNew(UsageEnvironment& env) { > AppArguments args; //for input configuration > //some code removed for readability > return new GridSource(env, args); > } > > EventTriggerId GridSource::eventTriggerId = 0; > > unsigned GridSource::referenceCount = 0; > unsigned GridSource::frameCount = 0; > > GridSource::GridSource(UsageEnvironment& env, > AppArguments args) > : FramedSource(env), fargs(args) { > if (referenceCount == 0) { > //encoder is initialised here. Some code removed for readability > } > ++referenceCount; > > if (eventTriggerId == 0) { > eventTriggerId = > envir().taskScheduler().createEventTrigger(deliverFrame0); > } > } > > GridSource::~GridSource() { > --referenceCount; > if (referenceCount == 0) { > if (encoder) > { > encoder->NvFBCH264Release(); > } > > // Reclaim our 'event trigger' > envir().taskScheduler().deleteEventTrigger(eventTriggerId); > eventTriggerId = 0; > } > } > > void GridSource::doGetNextFrame() { > > //Note: next frame is read only after previous frame?s NALs have been > delivered. > if(nalQ.isEmpty()){ > frameCount++; > populateQ(); //load the NALs for each frame. NALs stored in nalQ > } > deliverFrame(); > } > > void GridSource::deliverFrame0(void* clientData) { > ((GridSource*)clientData)->deliverFrame(); > } > > void GridSource::populateQ(){ > //frame is grabbed by the GRID SDK > //NALs for every frame are pushed to nalQ > //Some code removed for readability > > while(/*frame data is available in frame buffer*/){ > if(/*star code found in frame buffer*/) > nalQ.pushNAL(outputPtr,byteSize); //data until next start code or > until end of buffer - Note: data excludes start codes > } > > } > > void GridSource::deliverFrame() { > > if(!isCurrentlyAwaitingData()) return; // we're not ready for the data yet > > NAL* nal = nalQ.popNAL(); > nal->print(); > > // Deliver the data here: > if (nal->getSize() > fMaxSize) { > fFrameSize = fMaxSize; > fNumTruncatedBytes = nal->getSize() - fMaxSize; > } else { > fFrameSize = nal->getSize(); > } > gettimeofday(&fPresentationTime, NULL); > > fDurationInMicroseconds = 1000000/30; //30 fps > memmove(fTo, nal->getPayload(), fFrameSize); > > // After delivering the data, inform the reader that it is now available: > FramedSource::afterGetting(this); > } > > *??GridSource.cpp?? * > > > > _______________________________________________ > 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 Dec 23 16:59:36 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Dec 2014 13:59:36 +1300 Subject: [Live-devel] isCurrentlyAwaitingData usage In-Reply-To: <678A43434B81AC45A1CE04B5407A9A5E01569E41@IE1AEX3007.global.ds.honeywell.com> References: <678A43434B81AC45A1CE04B5407A9A5E01569E41@IE1AEX3007.global.ds.honeywell.com> Message-ID: > Please let me know the function details of ?isCurrentlyAwaitingData()? in FrameSource.hh, what is the use of the function. Remember, You Have Complete Source Code. > This function at times returns false. As it should. The function returns True if ?getNextFrame()? has already been called (to request a frame of data) on this object, but the requested frame has not yet been delivered. It is used to check that more than one "getNextFrame()? isn?t called on the same object concurrently (which will give you the ?attempting to read more than once at the same time? error). The function returns False if it is OK to call ?getNextFrame()? on the object (because an existing ?getNextFrame()? call is not already active). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Dec 23 17:17:41 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Dec 2014 14:17:41 +1300 Subject: [Live-devel] H264 Live Input Issue In-Reply-To: <5499F6B0.9080305@speed666.info> References: <578B40ED-12BB-49ED-90A4-A8265BD8A4DE@gmail.com> <5499F6B0.9080305@speed666.info> Message-ID: <401F432A-D53E-486F-B0EF-13AF9CBD0ED6@live555.com> Shubham, At a first (quick) glance, I don?t see anything obviously wrong here (apart from your use of an unprofessional email address, which is strongly discouraged on this mailing list). I notice that the first NALs that you deliver are SPS and PPS NAL units - which is important (and answers Marcin?s question). Because you?re streaming from a live source, make sure that the ?reuseFirstSource? parameter is True. Also, you should make sure that one (and only one) NAL unit (without start code) is delivered by your ?GridSource? class in response to each ?doGetNextFrame()? call. (Your code might already be doing this OK; I didn?t look at it in detail.) In any case, I suggest that you first use our ?openRTSP? command-line RTSP client application (rather than VLC, which is not our software) to test your server. If everything is working correctly, ?openRTSP? will give you a non-empty output file, which you can then rename to have a ?.h264? filename suffix. If the file is correct, then VLC should be able to play it (as a file). Then, and only then, should you try using VLC as a RTSP client. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Dec 27 15:20:12 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Dec 2014 09:20:12 +1000 Subject: [Live-devel] New policy for this mailing list: Postings from unprofessional email addresses will no longer be accepted Message-ID: The ?LIVE555 Streaming Media? software - and this mailing list - have always been intended for use by professional software developers: People who are affiliated with corporations using this software commercially (or schools using this software for research). As the software is open source, however, hobbyists are also free to use it, but to post to this mailing list, they are expected to demonstrate at least a minimal level of ?cluefulness? by using an email address with their own domain name - not just a generic ?@gmail?, ?@yahoo?, etc.-type email address. (Note that the underlying email *service* is not the problem; you can use your own domain name even with a public web-based email service like ?Gmail? or ?Yahoo Mail'.) Previously, we have allowed postings to this mailing list from unprofessional email addresses, but such messages have always been ?quarantined?: moderated and delayed (for hours or days) before being allowed to get delivered to the mailing list. This was intended (in part) to remind people of the ?stigma? that has always been associated with such email addresses - but it has become clear that many people simply have simply not been getting the hint. Also, we?ve been getting increasingly many postings from people who are clearly lacking in the skills required to use this software. Worse, it has become clear that several companies that use the ?LIVE555 Streaming Media? software have been trying to hide the fact that they use this software, by having their employees post to this mailing list using generic ?@gmail.com?-type email addresses, rather than their corporate email addresses. Perhaps these companies feel that this reduces their exposure to the LGPL (it doesn?t!), or perhaps they are concerned about competitors (real or imagined) learning about their plans. If you want private email support for this software, then you can do so by purchasing consulting time; you?re not going to get it ?for free? on this public mailing list. From now on, postings to this mailing list from unprofessional email addresses will no longer be accepted. This includes (but is not limited to) email addresses using the following domain names: ?@gmail.com ?, ?@yahoo.?, ?@msn.com ?, ?@aol.com ?, ?@mail.ru ?, ?@qq.com ?, ?@163.c om?. Note that this policy applies only to *postings* to the mailing list. Anyone (no matter what email address they use) can still subscribe to this mailing list to receive messages, and of course can continue to read the online archives. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Giridhara.Kalkere at Honeywell.com Mon Dec 29 03:42:17 2014 From: Giridhara.Kalkere at Honeywell.com (Kalkere, Giridhara) Date: Mon, 29 Dec 2014 11:42:17 +0000 Subject: [Live-devel] recording audio Message-ID: <955512E27CA4E9478883ACDCA9CA40C6019541A4@IE1AEX3007.global.ds.honeywell.com> Dear Ross, Can use the live555 for the audio and video recording simultaneously? Thanks and Regards, Giri -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Dec 29 06:46:02 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Dec 2014 03:46:02 +1300 Subject: [Live-devel] recording audio In-Reply-To: <955512E27CA4E9478883ACDCA9CA40C6019541A4@IE1AEX3007.global.ds.honeywell.com> References: <955512E27CA4E9478883ACDCA9CA40C6019541A4@IE1AEX3007.global.ds.honeywell.com> Message-ID: <384B1D13-15B6-4534-81DC-CDE47DA50B29@live555.com> > Can use the live555 for the audio and video recording simultaneously? Yes of course. "testRTSPClient" (and "openRTSP") demonstrate how to do this. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: