From jeanluc.bonnet at barco.com Mon Mar 3 04:19:36 2014 From: jeanluc.bonnet at barco.com (Bonnet, Jean-Luc) Date: Mon, 3 Mar 2014 12:19:36 +0000 Subject: [Live-devel] TR: MP4 Video over Transport Stream Message-ID: <75C4803536D10B4EB6FA0743F98B6A0A1ECB55F7@KUUMEX10.barco.com> ________________________________ De : Bonnet, Jean-Luc Envoy? : lundi 3 mars 2014 13:13 ? : 'live-devel at lists.live555.com' Objet : MP4 Video over Transport Stream Hi Ross, * I receive a MP4 video stream over MPEG TS: * I use test program testMPEG2TransportReceiver and It works fine. * Now I need to write an AVI file containing the MPG4 video Frames. * But I don't find which filter i need to use in order to convert MPEG TS packets to MP4V frames and how I can detect key frames inside this stream. * I also need to stream these AVI files using MPEG TS: * I think to use testMPEG2TransportStreamer test program * But I don't find which filter i need to use in order to convert MP4V frames to MPEG TS packets. Thanks for your help best regards Jean-Luc Bonnet This message is subject to the following terms and conditions: MAIL DISCLAIMER -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Mar 3 07:19:09 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Mar 2014 04:19:09 +1300 Subject: [Live-devel] TR: MP4 Video over Transport Stream In-Reply-To: <75C4803536D10B4EB6FA0743F98B6A0A1ECB55F7@KUUMEX10.barco.com> References: <75C4803536D10B4EB6FA0743F98B6A0A1ECB55F7@KUUMEX10.barco.com> Message-ID: <362617D6-E0EA-43A7-9F41-79C66B6D2054@live555.com> > I receive a MP4 video stream over MPEG TS: > I use test program testMPEG2TransportReceiver and It works fine. > Now I need to write an AVI file containing the MPG4 video Frames. > But I don't find which filter i need to use in order to convert MPEG TS packets to MP4V frames and how I can detect key frames inside this stream. Unfortunately we don't provide any 'demultiplexor' for Transport Streams, so you can't do this using our software. > > I also need to stream these AVI files using MPEG TS: > I think to use testMPEG2TransportStreamer test program > But I don't find which filter i need to use in order to convert MP4V frames to MPEG TS packets. You could do this using our software by 1/ Creating a "MPEG2TransportStreamFromESSource" object 2/ Calling "addNewVideoSource()" on this "MPEG2TransportStreamFromESSource" object, with the input MPEG-4 video source as parameter, and with a "mpegVersion" parameter of 4. (If the MPEG-4 video comes from a MPEG-4 Video Elementary Stream file - *not* an AVI file - then you must first pass this file through a "MPEG4VideoStreamFramer" object. Unfortunately, however, we don't support reading from AVI files.) 3/ Creating a "FileSink" object (for the output Transport Stream file) 4/ Calling "startPlaying()" on the "FileSink" object, with the "MPEG2TransportStreamFromESSource" object as source. 5/ Call "doEventLoop()" to enter the LIVE555 event loop (if you're not already in it). In short, if your input file is a MPEG-4 Video Elementary Stream file - *not* an AVI file - then you could use the code for the "testH264VideoToTransportStream" demo application (in the "testProgs" directory), except that - You would use "MPEG4VideoStreamFramer" rather than "H264VideoStreamFramer". - The "addNewVideoSource()" call would use a "mpegVersion" parameter of 4 rather than 5. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanluc.bonnet at barco.com Mon Mar 3 08:07:20 2014 From: jeanluc.bonnet at barco.com (Bonnet, Jean-Luc) Date: Mon, 3 Mar 2014 16:07:20 +0000 Subject: [Live-devel] TR: MP4 Video over Transport Stream In-Reply-To: <362617D6-E0EA-43A7-9F41-79C66B6D2054@live555.com> Message-ID: <75C4803536D10B4EB6FA0743F98B6A0A1ECB5635@KUUMEX10.barco.com> Thanks Ross for the quick reply, In fact I have the choice of the stream protocol, may be it is more simple to use MP4 video stream over RTP. * For receiving: * I can use testMPEG2TransportReceiver and replace SimpleRTPSource with MPEG4ESVideoRTPSource. * But I need to use MPEG4VideoStreamFramer in order to extract the MP4V frames. * Is it right? * For streaming: * I can use testMPEG2TransportStreamer and replace SimpleRTPSink with MPEG4ESVideoRTPSink. * But which filter I need to use in order to convert MP4V frames to MP4V-ES packets? thanks for your help best regards Jean-Luc Bonnet ________________________________ De : live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] De la part de Ross Finlayson Envoy? : lundi 3 mars 2014 16:19 ? : LIVE555 Streaming Media - development & use Objet : Re: [Live-devel] TR: MP4 Video over Transport Stream * I receive a MP4 video stream over MPEG TS: * I use test program testMPEG2TransportReceiver and It works fine. * Now I need to write an AVI file containing the MPG4 video Frames. * But I don't find which filter i need to use in order to convert MPEG TS packets to MP4V frames and how I can detect key frames inside this stream. Unfortunately we don't provide any 'demultiplexor' for Transport Streams, so you can't do this using our software. * * I also need to stream these AVI files using MPEG TS: * I think to use testMPEG2TransportStreamer test program * But I don't find which filter i need to use in order to convert MP4V frames to MPEG TS packets. You could do this using our software by 1/ Creating a "MPEG2TransportStreamFromESSource" object 2/ Calling "addNewVideoSource()" on this "MPEG2TransportStreamFromESSource" object, with the input MPEG-4 video source as parameter, and with a "mpegVersion" parameter of 4. (If the MPEG-4 video comes from a MPEG-4 Video Elementary Stream file - *not* an AVI file - then you must first pass this file through a "MPEG4VideoStreamFramer" object. Unfortunately, however, we don't support reading from AVI files.) 3/ Creating a "FileSink" object (for the output Transport Stream file) 4/ Calling "startPlaying()" on the "FileSink" object, with the "MPEG2TransportStreamFromESSource" object as source. 5/ Call "doEventLoop()" to enter the LIVE555 event loop (if you're not already in it). In short, if your input file is a MPEG-4 Video Elementary Stream file - *not* an AVI file - then you could use the code for the "testH264VideoToTransportStream" demo application (in the "testProgs" directory), except that - You would use "MPEG4VideoStreamFramer" rather than "H264VideoStreamFramer". - The "addNewVideoSource()" call would use a "mpegVersion" parameter of 4 rather than 5. Ross Finlayson Live Networks, Inc. http://www.live555.com/ This message is subject to the following terms and conditions: MAIL DISCLAIMER -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Mar 3 12:44:54 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Mar 2014 09:44:54 +1300 Subject: [Live-devel] TR: MP4 Video over Transport Stream In-Reply-To: <75C4803536D10B4EB6FA0743F98B6A0A1ECB5635@KUUMEX10.barco.com> References: <75C4803536D10B4EB6FA0743F98B6A0A1ECB5635@KUUMEX10.barco.com> Message-ID: <7814FE60-5E3D-454C-8D76-23B62DEB91C7@live555.com> > In fact I have the choice of the stream protocol, may be it is more simple to use MP4 video stream over RTP. OK, in that case you wouldn't use anything with the word "Transport" in the name. For streaming, you could use our "testMPEG4VideoStreamer" demo application. This reads from a MPEG-4 Video Elementary Stream file (named "test.m4e"), and streams it via RTP multicast. (We have some example MPEG-4 Video Elementary Stream files that you can use for testing; see http://www.live555.com/liveMedia/faq.html#m4e-file ) For receiving, you would use a RTSP receiver application, such as "openRTSP" , or "testRTSPClient". Note that - for MPEG-4 video - there is no "testMPEG4VideoReceiver" application, for the reason explained here: http://www.live555.com/liveMedia/faq.html#rtsp-needed Instead, you will need to use a RTSP client to receive this stream. Alternatively, if you want to stream MPEG-4 video via RTP *unicast* (rather than multicast), then you would need to use a dedicated RTSP server application - such as "testOnDemandRTSPServer" or the "LIVE555 Media Server" - to stream it. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoker at pythagdev.com Tue Mar 4 10:32:25 2014 From: rcoker at pythagdev.com (Rob Coker) Date: Tue, 4 Mar 2014 12:32:25 -0600 Subject: [Live-devel] testRTSPClient - can't find a port not in use Message-ID: <005e01cf37d8$17b400d0$471c0270$@com> Ross, Thanks for the help. I was able to use setClientPortNum() inside setupNextSubsession() to specify which port for it to use so it didn't auto-search. Oddly enough, any even port between 65408 - 65518 seems to work. That was just the range I tested, it probably works outside of that as well. With that change, things work great! As a follow-on question, is there a way to use the Live555 library to MUX in a custom data structure into the audio & video stream that I'm getting via RTSP? The application is to save some custom data on top of an A/V stream from an IP camera into a data file that includes audio, video, and the custom data. Thanks again, Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From umar at janteq.com Tue Mar 4 12:36:43 2014 From: umar at janteq.com (Umar Qureshey) Date: Tue, 4 Mar 2014 20:36:43 +0000 Subject: [Live-devel] TS thrashing Message-ID: Hello, I have modified the testH264VideoToTransportStream.cpp program by simply replacing inputFileName to "stdin" and outputFileName to "/dev/my_device". /dev/my_device is a Linux device driver that transports the TS data to the streaming hardware. Then I run the following command line: ./openRTSP -v rtsp://192.168.1.214/stream/profile1=u | ./testH264VideoToTransportStreamToMicrowave This works well except there is a lot of "thrashing". Even with constant bitrate set in the encoder, the bitrate varies a lot. At first I suspected that this may be happening because of the Linux pipe so I recompiled the kernel and increased to pipe size to 1 MB. This did not help. So to verify if this is a Linux pipe issue I modified testH264VideoToTransportStream.cpp to output to UDP: ./openRTSP -v rtsp://192.168.1.214/stream/profile1=u | ./testH264VideoToTransportStreamToUDP The above command line showed a very constant bitrate on the receiver side so I can deduce it's not a Linux pipe issue. Finally, I put some debug prints in the Linux device driver and it shows that each fwrite call by the FileSink object is 188 bytes. I have already changed the bufferSize of FileSink to 1000000 for testing but that doesn't seem to help; it's still writing only 188 bytes per fwrite call: MediaSink* outputSink = FileSink::createNew(*env, outputFileName, 1000000); So is there a way to have more buffering going on so at each fwrite call writes more than 188 bytes at a time to /dev/my_device ?? Thanks. From finlayson at live555.com Tue Mar 4 13:51:49 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Mar 2014 10:51:49 +1300 Subject: [Live-devel] testRTSPClient - can't find a port not in use In-Reply-To: <005e01cf37d8$17b400d0$471c0270$@com> References: <005e01cf37d8$17b400d0$471c0270$@com> Message-ID: > Thanks for the help. I was able to use setClientPortNum() inside setupNextSubsession() to specify which port for it to use so it didn?t auto-search. Oddly enough, any even port between 65408 ? 65518 seems to work. That was just the range I tested, it probably works outside of that as well. With that change, things work great! Nonetheless, something must be broken in your system if the normal ephemeral port number selection code (the "while" loop starting at line 726 of "MediaSession.cpp") is not working for you. Nobody else has had any problem with this. I suggest that you figure out what's wrong with your system, rather than just 'papering over it' like this. > As a follow-on question, is there a way to use the Live555 library to MUX in a custom data structure into the audio & video stream that I?m getting via RTSP? Are you still talking about a RTSP *client*, receiving from an existing RTSP server? If so, then please post an example of the SDP description that the RTSP client reports (you can use "testRTSPClient" or "openRTSP" to get this; it'll be the text returned by the RTSP "DESCRIBE" command). Or are you talking about developing your own RTSP *server*, and want to know how to add your own new media data (in addition to an audio and video track) to the stream transmitted by the server? If so, then you'll need to explain a lot more about what kind of media this is. (Is this data time-based? If not, then it probably doesn't make sense to stream it via RTSP/RTP?) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 4 14:20:46 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Mar 2014 11:20:46 +1300 Subject: [Live-devel] TS thrashing In-Reply-To: References: Message-ID: <3FACD469-59E4-4EA1-BAAF-ED4650EBB4A3@live555.com> > So is there a way to have more buffering going on so at each fwrite call writes more than 188 bytes at a time to /dev/my_device ?? Yes, one solution would be to insert another pipe - between your modified "testH264VideoToTransportStream" code, and your output device. I.e., modify your code again, changing "outputFileName" from "/dev/my_device" to "stdout". Then run ./openRTSP -v rtsp://192.168.1.214/stream/profile1=u | ./yourModifiedTestH264VideoToTransportStreamApplication | cat - > /dev/my_device (You could also try ./openRTSP -v rtsp://192.168.1.214/stream/profile1=u | ./yourModifiedTestH264VideoToTransportStreamApplication > /dev/my_device but I don't think that will create a pipe.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Tue Mar 4 15:19:26 2014 From: cmatsuura at vivint.com (Craig Matsuura) Date: Tue, 4 Mar 2014 16:19:26 -0700 Subject: [Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server In-Reply-To: <7814FE60-5E3D-454C-8D76-23B62DEB91C7@live555.com> References: <75C4803536D10B4EB6FA0743F98B6A0A1ECB5635@KUUMEX10.barco.com> <7814FE60-5E3D-454C-8D76-23B62DEB91C7@live555.com> Message-ID: <53165F7E.9080406@vivint.com> I'm still consider myself a newbie with RTSP, but had a question I hope someone can help me with. I have a general question about a camera session and keeping it alive. The rtsp proxy uses OPTIONS by default and optionally can use GET_PARAMETER. If a camera closes a session due to some bug how would the proxy server know if the camera responds to the OPTIONS command. I assume the Session header is sent with the OPTIONS command once a session is setup for a camera. Should the camera honor the Session header and if the camera closed the session the OPTIONS command should respond with a 454 Session Not Found? I noticed in the RTSP RFC there is an example with a GET_PARAMETER call with a Session header, but no example with an OPTIONS command with a Session header. So if the GET_PARAMETER was used for keep-alive should the server honor the Session header and respond with a 454 if the session was closed on the camera? If my understanding on the session header is inaccurate I apologize. Thanks, Craig From finlayson at live555.com Tue Mar 4 15:32:47 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Mar 2014 12:32:47 +1300 Subject: [Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server In-Reply-To: <53165F7E.9080406@vivint.com> References: <75C4803536D10B4EB6FA0743F98B6A0A1ECB5635@KUUMEX10.barco.com> <7814FE60-5E3D-454C-8D76-23B62DEB91C7@live555.com> <53165F7E.9080406@vivint.com> Message-ID: <9F674DD7-7073-4A3E-AE59-03A650058D64@live555.com> I'm not sure I understand your question. If the 'liveness' command from the proxy server (*either* "OPTIONS" or "GET_PARAMETER") fails - either because the TCP connection fails, or because the back-end server responded with a response code other than 200 - then the proxy server will assume that the session has failed, It will then reset its state with the back-end server. It will then attempt to send another "DESCRIBE" command (and then "SETUP", "PLAY", etc. for any subsequent front-end client connection(s). Note that this is true *regardless* of whether the 'liveness' command is "OPTIONS" (by default), or "GET_PARAMETER" (if you've "#define"d SEND_GET_PARAMETER_IF_SUPPORTED). So I don't understand the "OPTIONS vs GET_PARAMETER" in your "Subject:" line. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Tue Mar 4 15:59:27 2014 From: cmatsuura at vivint.com (Craig Matsuura) Date: Tue, 4 Mar 2014 16:59:27 -0700 Subject: [Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server In-Reply-To: <9F674DD7-7073-4A3E-AE59-03A650058D64@live555.com> References: <75C4803536D10B4EB6FA0743F98B6A0A1ECB5635@KUUMEX10.barco.com> <7814FE60-5E3D-454C-8D76-23B62DEB91C7@live555.com> <53165F7E.9080406@vivint.com> <9F674DD7-7073-4A3E-AE59-03A650058D64@live555.com> Message-ID: <531668DF.1010101@vivint.com> It appears the GET_PARAMETER will accept the Session header as a OPTIONS does not care. So if for some reason the camera server closes the session what is the indicator to the client? If the GET_PARAMETER is sent with a Session I assume the camera server should respond with a 454 and not reply to the message with a 200? In my logs it appears the Session header is sent in the OPTIONS command but assume a OPTIONS is not session dependent it will ignore any session header. So I guess my point is how the session header would be honored in a OPTIONS vs GET_PARAMETER. Seems the GET_PARAMETER is a better solution. Thanks, Craig On 03/04/2014 04:32 PM, Ross Finlayson wrote: I'm not sure I understand your question. If the 'liveness' command from the proxy server (*either* "OPTIONS" or "GET_PARAMETER") fails - either because the TCP connection fails, or because the back-end server responded with a response code other than 200 - then the proxy server will assume that the session has failed, It will then reset its state with the back-end server. It will then attempt to send another "DESCRIBE" command (and then "SETUP", "PLAY", etc. for any subsequent front-end client connection(s). Note that this is true *regardless* of whether the 'liveness' command is "OPTIONS" (by default), or "GET_PARAMETER" (if you've "#define"d SEND_GET_PARAMETER_IF_SUPPORTED). So I don't understand the "OPTIONS vs GET_PARAMETER" in your "Subject:" line. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at jfs-tech.com Tue Mar 4 16:47:00 2014 From: jshanab at jfs-tech.com (Jeff Shanab) Date: Tue, 4 Mar 2014 19:47:00 -0500 Subject: [Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server In-Reply-To: <531668DF.1010101@vivint.com> References: <75C4803536D10B4EB6FA0743F98B6A0A1ECB5635@KUUMEX10.barco.com> <7814FE60-5E3D-454C-8D76-23B62DEB91C7@live555.com> <53165F7E.9080406@vivint.com> <9F674DD7-7073-4A3E-AE59-03A650058D64@live555.com> <531668DF.1010101@vivint.com> Message-ID: In my Archiver, Restreamer, and Player I have a watchdog that is kicked when frames come in. If I fail to get frames the watchdog expires; or if ever there is a socket error. It is a do-over. I start again with the DESCRIBE. I did my own server and there was never more than 1 stream from the camera, I reference counted my frames and when that reference count hit zero it returned the frame object to the pool. Not sure if that answers your question. Part of this is basic sockets. I was using TCP. It KNOWs when a connection is broken. I couldn't wait for it so I added the watchdog. On Tue, Mar 4, 2014 at 6:59 PM, Craig Matsuura wrote: > It appears the GET_PARAMETER will accept the Session header as a OPTIONS > does not care. So if for some reason the camera server closes the session > what is the indicator to the client? If the GET_PARAMETER is sent with a > Session I assume the camera server should respond with a 454 and not reply > to the message with a 200? > > In my logs it appears the Session header is sent in the OPTIONS command > but assume a OPTIONS is not session dependent it will ignore any session > header. > > So I guess my point is how the session header would be honored in a > OPTIONS vs GET_PARAMETER. Seems the GET_PARAMETER is a better solution. > > Thanks, > Craig > > > On 03/04/2014 04:32 PM, Ross Finlayson wrote: > > I'm not sure I understand your question. > > If the 'liveness' command from the proxy server (*either* "OPTIONS" or > "GET_PARAMETER") fails - either because the TCP connection fails, or > because the back-end server responded with a response code other than 200 - > then the proxy server will assume that the session has failed, It will > then reset its state with the back-end server. It will then attempt to > send another "DESCRIBE" command (and then "SETUP", "PLAY", etc. for any > subsequent front-end client connection(s). > > Note that this is true *regardless* of whether the 'liveness' command is > "OPTIONS" (by default), or "GET_PARAMETER" (if you've "#define"d > SEND_GET_PARAMETER_IF_SUPPORTED). So I don't understand the "OPTIONS vs > GET_PARAMETER" in your "Subject:" line. > > > 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 rcoker at pythagdev.com Wed Mar 5 09:07:44 2014 From: rcoker at pythagdev.com (Rob Coker) Date: Wed, 5 Mar 2014 11:07:44 -0600 Subject: [Live-devel] testRTSPClient - can't find a port not in In-Reply-To: References: Message-ID: <005801cf3895$6d62ae60$48280b20$@com> >> As a follow-on question, is there a way to use the Live555 library to MUX in >> a custom data structure into the audio & video stream that I?m getting via >> RTSP? > Are you still talking about a RTSP *client*, receiving from an existing RTSP > server? If so, then please post an example of the SDP description that the > RTSP client reports (you can use "testRTSPClient" or "openRTSP" to get this; > it'll be the text returned by the RTSP "DESCRIBE" command). > Or are you talking about developing your own RTSP *server*, and want to know > how to add your own new media data (in addition to an audio and video track) > to the stream transmitted by the server? If so, then you'll need to explain a > lot more about what kind of media this is. (Is this data time-based? If not, > then it probably doesn't make sense to stream it via RTSP/RTP?) The idea was that my program would be a "client," receiving from an existing RTSP server (namely an h264 video camera that support RTSP) and I would be saving the data from the streams coming in on the camera. So far, there's nothing new here. There is a Live 555 test program that will do all that. The unique thing is that the client gets other real-time data (has nothing to do with RTSP) that we would like to MUX in with the audio and video streams from the video camera as we save the file. This isn't exactly our example, but say you were videoing an experiment in a lab and wanted to insert the temperature and barometric pressure in the same file as the video and then planned to write a custom app that would display the video with a side bar showing temp and pressure. All the data (the video, barometric pressure and temp) would be in the same file and would be time aligned. Something like that is the goal. I don't have a camera right now, so can't get you the DESCRIBE response, but I'm not sure that it's relevant. AFAICT, the real issue is how to MUX in a custom stream to other existing streams when saving a file. As I re-read your response, the server example is something like what we're trying to do, but writing to a file. So, yes, we have our own time-based data (let's just pretend it's temp and baro pressure), we want to stream it along with the incoming video and audio streams to a file. Hope this helps explain the problem a little better. Thanks, Rob From rwoods at vaytek.com Wed Mar 5 12:58:25 2014 From: rwoods at vaytek.com (Ron Woods) Date: Wed, 5 Mar 2014 14:58:25 -0600 Subject: [Live-devel] Error in testH264VideoStreamer Message-ID: <27FB82F7EB0DA04C92361A01E7BA9A9301B51C157659@GODFATHERII.vaytek2003.local> I have downloaded and compiled version 2014.02.19 using your makefiles in Visual Studio 2012 on Win 7 Pro. I have also successfully run testMPEG1or2VideoStreamer with an Elementary Stream test.mpg (that I found on the internet). Now I am trying testH264VideoStreamer with an ES that I downloaded from your link in the FAQ; but, the test app dies with an AccessViolationException. Call Stack is as follows: > testH264VideoStreamer.exe!reclaimGroupsockPriv(UsageEnvironment & env) Line 67 C++ testH264VideoStreamer.exe!setupDatagramSocket(UsageEnvironment & env, Port port) Line 103 C++ testH264VideoStreamer.exe!ourIPAddress(UsageEnvironment & env) Line 594 C++ testH264VideoStreamer.exe!chooseRandomIPv4SSMAddress(UsageEnvironment & env) Line 687 C++ testH264VideoStreamer.exe!main(int argc, char * * argv) Line 45 C++ testH264VideoStreamer.exe!__tmainCRTStartup() Line 536 C kernel32.dll!7562336a() Unknown [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!772d9f72() Unknown ntdll.dll!772d9f45() Unknown Your prompt help in this matter will be greatly appreciated. Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Mar 5 13:16:52 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Mar 2014 10:16:52 +1300 Subject: [Live-devel] testRTSPClient - can't find a port not in In-Reply-To: <005801cf3895$6d62ae60$48280b20$@com> References: <005801cf3895$6d62ae60$48280b20$@com> Message-ID: > the real issue is how to MUX in a custom stream to other existing streams > when saving a file. This depends upon the type of file that you're saving. For some file types, it might not be possible. > > As I re-read your response, the server example is something like what we're > trying to do, but writing to a file. So, yes, we have our own time-based > data (let's just pretend it's temp and baro pressure), we want to stream it > along with the incoming video and audio streams to a file. OK, now this is something different. *Now* you're talking about streaming data, not writing data into a file. For streaming (transmitting) time-based text using RTP, you can use our class "T140TextRTPSink". For receiving such a RTP stream, you can use our class "SimpleRTPSource". Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwoods at vaytek.com Sun Mar 9 09:21:24 2014 From: rwoods at vaytek.com (Ron Woods) Date: Sun, 9 Mar 2014 11:21:24 -0500 Subject: [Live-devel] Error in testH264VideoStreamer In-Reply-To: <27FB82F7EB0DA04C92361A01E7BA9A9301B51C157659@GODFATHERII.vaytek2003.local> References: <27FB82F7EB0DA04C92361A01E7BA9A9301B51C157659@GODFATHERII.vaytek2003.local> Message-ID: <27FB82F7EB0DA04C92361A01E7BA9A9301B51C1576C3@GODFATHERII.vaytek2003.local> I did get testH264VideoStreamer working in my VS 2012 environment by cleaning and rebuilding each component library. I'm not sure what was wrong before, except that possibly there was some inconsistency in the builds. I built each library in debug mode; so, I had to change the reference to msvcrt.lib to msvcrtd.lib in the win32.config file as well as comment out the NODEBUG=1 line as noted at the top. (Original file has msvcirt.lib, but that's been superseded by msvcrt.lib). To build release mode, I do the inverse. Also, it would be good to note somewhere in the documentation that the clean line in the make files: -rm -rf *.$(OBJ) $(ALL) core *.core *~ include/*~ is for Unix or Linux and doesn't work for Windows. I used the following line: del *.$(OBJ) $(ALL) that works; but, is this fully equivalent to the Unix/Linux command? Ron From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ron Woods Sent: Wednesday, March 05, 2014 2:58 PM To: live-devel at lists.live555.com Subject: [Live-devel] Error in testH264VideoStreamer I have downloaded and compiled version 2014.02.19 using your makefiles in Visual Studio 2012 on Win 7 Pro. I have also successfully run testMPEG1or2VideoStreamer with an Elementary Stream test.mpg (that I found on the internet). Now I am trying testH264VideoStreamer with an ES that I downloaded from your link in the FAQ; but, the test app dies with an AccessViolationException. Call Stack is as follows: > testH264VideoStreamer.exe!reclaimGroupsockPriv(UsageEnvironment & env) Line 67 C++ testH264VideoStreamer.exe!setupDatagramSocket(UsageEnvironment & env, Port port) Line 103 C++ testH264VideoStreamer.exe!ourIPAddress(UsageEnvironment & env) Line 594 C++ testH264VideoStreamer.exe!chooseRandomIPv4SSMAddress(UsageEnvironment & env) Line 687 C++ testH264VideoStreamer.exe!main(int argc, char * * argv) Line 45 C++ testH264VideoStreamer.exe!__tmainCRTStartup() Line 536 C kernel32.dll!7562336a() Unknown [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] ntdll.dll!772d9f72() Unknown ntdll.dll!772d9f45() Unknown Your prompt help in this matter will be greatly appreciated. Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmatsuura at vivint.com Fri Mar 7 13:22:12 2014 From: cmatsuura at vivint.com (Craig Matsuura) Date: Fri, 7 Mar 2014 14:22:12 -0700 Subject: [Live-devel] OPTIONS vs GET_PARAMETER for keep alive with proxy server In-Reply-To: References: <75C4803536D10B4EB6FA0743F98B6A0A1ECB5635@KUUMEX10.barco.com> <7814FE60-5E3D-454C-8D76-23B62DEB91C7@live555.com> <53165F7E.9080406@vivint.com> <9F674DD7-7073-4A3E-AE59-03A650058D64@live555.com> <531668DF.1010101@vivint.com> Message-ID: <531A3884.2030102@vivint.com> Thanks for the insight Jeff. After further digging I found the issue we were having. I have moved back to OPTIONS as a keepalive. I posted a patch to the mailing list but have not seen it approved. Thanks, Craig On 03/04/2014 05:47 PM, Jeff Shanab wrote: In my Archiver, Restreamer, and Player I have a watchdog that is kicked when frames come in. If I fail to get frames the watchdog expires; or if ever there is a socket error. It is a do-over. I start again with the DESCRIBE. I did my own server and there was never more than 1 stream from the camera, I reference counted my frames and when that reference count hit zero it returned the frame object to the pool. Not sure if that answers your question. Part of this is basic sockets. I was using TCP. It KNOWs when a connection is broken. I couldn't wait for it so I added the watchdog. On Tue, Mar 4, 2014 at 6:59 PM, Craig Matsuura > wrote: It appears the GET_PARAMETER will accept the Session header as a OPTIONS does not care. So if for some reason the camera server closes the session what is the indicator to the client? If the GET_PARAMETER is sent with a Session I assume the camera server should respond with a 454 and not reply to the message with a 200? In my logs it appears the Session header is sent in the OPTIONS command but assume a OPTIONS is not session dependent it will ignore any session header. So I guess my point is how the session header would be honored in a OPTIONS vs GET_PARAMETER. Seems the GET_PARAMETER is a better solution. Thanks, Craig On 03/04/2014 04:32 PM, Ross Finlayson wrote: I'm not sure I understand your question. If the 'liveness' command from the proxy server (*either* "OPTIONS" or "GET_PARAMETER") fails - either because the TCP connection fails, or because the back-end server responded with a response code other than 200 - then the proxy server will assume that the session has failed, It will then reset its state with the back-end server. It will then attempt to send another "DESCRIBE" command (and then "SETUP", "PLAY", etc. for any subsequent front-end client connection(s). Note that this is true *regardless* of whether the 'liveness' command is "OPTIONS" (by default), or "GET_PARAMETER" (if you've "#define"d SEND_GET_PARAMETER_IF_SUPPORTED). So I don't understand the "OPTIONS vs GET_PARAMETER" in your "Subject:" line. 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 hackeron at gmail.com Tue Mar 11 03:58:24 2014 From: hackeron at gmail.com (Roman Gaufman) Date: Tue, 11 Mar 2014 10:58:24 +0000 Subject: [Live-devel] Closing connection after DESCRIBE? Message-ID: Hi there, I'm trying to implement a monit (or equivalent) check that a stream is available and if not, to check if the camera is alive (with ping) and report an issue if it's not. I am sending this to the live555ProxyServer: DESCRIBE rtsp://localhost/proxyStream RTSP/1.0 CSeq: 1 To which it responds with: RTSP/1.0 200 OK CSeq: 1 Date: Tue, Mar 11 2014 10:55:55 GMT Content-Base: rtsp://127.0.0.1:12347/proxyStream/ Content-Type: application/sdp Content-Length: 761 ...more lines... So far so good, but then it keeps the connection open indefinitely and my test fails. Is there anyway to ask live555ProxyServer to close the connection after the DESCRIBE? - or to somehow timeout the connection after a few seconds? Thank you, Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Mar 12 02:25:14 2014 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 12 Mar 2014 22:25:14 +1300 Subject: [Live-devel] Closing connection after DESCRIBE? In-Reply-To: References: Message-ID: <1B50DBC7-5A09-4573-B2BC-4A64D8871EC5@live555.com> The best way to check the status of the 'back end' stream is via the entity that actually creates and controls the 'back end' stream - i.e., the proxy server. In particular, you could modify the function "ProxyRTSPClient::continueAfterLivenessCommand()" to do whatever you want (at which point, of course, you can't expect any more support from this mailing list). In contrast, the 'front end' stream doesn't tell you anything about the status of the 'back end' stream. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Abins_Jose at mindtree.com Wed Mar 12 02:33:09 2014 From: Abins_Jose at mindtree.com (Abins Joseph Jose) Date: Wed, 12 Mar 2014 09:33:09 +0000 Subject: [Live-devel] proxyServer: Extra bytes before PLAY response Message-ID: <40554F17052CB1429A35F21A239194E00769DD42@MTW02MBX01.mindtree.com> Hi, I have noticed that when a client connects to the live555ProxyServer using RTP over TCP, some extra bytes are present before the PLAY response. This happens only if the client is not the first one to connect to the live555ProxyServer (ie. There are existing clients that have connected too). This behavior doesn?t happen in case of RTP over UDP. I suspect the reason is because in the RTSPServer.cpp file, in response to the PLAY command, the startStream for each media subsession is called and then the PLAY response is sent. I think that the startStream may be sending the data before the PLAY response, but I am not able to track down the exact place where this is happening. Below is the wireshark trace captured between the openRTSP and live555ProxyServer with this issue: OPTIONS rtsp://172.22.65.58/proxyStream RTSP/1.0 CSeq: 2 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2014.02.26) RTSP/1.0 200 OK CSeq: 2 Date: Wed, Mar 12 2014 09:10:19 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE rtsp://172.22.65.58/proxyStream RTSP/1.0 CSeq: 3 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2014.02.26) Accept: application/sdp RTSP/1.0 200 OK CSeq: 3 Date: Wed, Mar 12 2014 09:10:19 GMT Content-Base: rtsp://172.22.65.58/proxyStream/ Content-Type: application/sdp Content-Length: 536 v=0 o=- 1394615373237045 1 IN IP4 172.22.65.58 s=LIVE555 Streaming Media v2014.02.26 i=LIVE555 Streaming Media v2014.02.26 t=0 0 a=tool:LIVE555 Streaming Media v2014.02.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v2014.02.26 a=x-qt-text-inf:LIVE555 Streaming Media v2014.02.26 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:50000 a=rtpmap:96 H264/90000 a=fmtp:96 packetization-mode=1;profile-level-id=420029;sprop-parameter-sets=Z0IAKeKQFAe2AtwEBAaQeJEV,aM48gA== a=control:track1 SETUP rtsp://172.22.65.58/proxyStream/track1 RTSP/1.0 CSeq: 4 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2014.02.26) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 RTSP/1.0 200 OK CSeq: 4 Date: Wed, Mar 12 2014 09:10:19 GMT Transport: RTP/AVP/TCP;unicast;destination=172.22.65.73;source=172.22.65.58;interleaved=0-1 Session: 8A527274;timeout=65 PLAY rtsp://172.22.65.58/proxyStream/ RTSP/1.0 CSeq: 5 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2014.02.26) Session: 8A527274 Range: npt=0.000- $..4......;......1.!.y.......+........;.. A2ML20710L....RTSP/1.0 200 OK CSeq: 5 Date: Wed, Mar 12 2014 09:10:19 GMT Range: npt=0.000- Session: 8A527274 RTP-Info: url=rtsp://172.22.65.58/proxyStream/track1;seq=49180;rtptime=4135167983 Best regards, Abins ________________________________ http://www.mindtree.com/email/disclaimer.html From cmatsuura at vivint.com Wed Mar 12 15:17:14 2014 From: cmatsuura at vivint.com (Craig Matsuura) Date: Wed, 12 Mar 2014 16:17:14 -0600 Subject: [Live-devel] Best place to ask general RTSP questions Message-ID: <5320DCEA.1070605@vivint.com> I'm hoping this is a reasonable request? Thanks, Craig From finlayson at live555.com Thu Mar 13 01:51:08 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Mar 2014 01:51:08 -0700 Subject: [Live-devel] proxyServer: Extra bytes before PLAY response In-Reply-To: <40554F17052CB1429A35F21A239194E00769DD42@MTW02MBX01.mindtree.com> References: <40554F17052CB1429A35F21A239194E00769DD42@MTW02MBX01.mindtree.com> Message-ID: > I have noticed that when a client connects to the live555ProxyServer using RTP over TCP, some extra bytes are present before the PLAY response. This happens only if the client is not the first one to connect to the live555ProxyServer (ie. There are existing clients that have connected too). Unfortunately I wasn't able to reproduce this - nor can I explain it. These 'extra bytes' look like an interleaved RTCP packet, but we explicitly set ourselves up to receive and handle such data after we get the response to the "SETUP" command. So interleaved RTCP packets appearing after "PLAY" should not be a problem. (A bug here was fixed last October, but I see that you're using a newer version of the code - so I'm at a loss to explain this. Sorry.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From R.Suijker at tkhsecurity.com Thu Mar 13 02:55:58 2014 From: R.Suijker at tkhsecurity.com (Robert Suijker) Date: Thu, 13 Mar 2014 09:55:58 +0000 Subject: [Live-devel] Crash in MPEG4/H264/H265 VideoFileServerMediaSubSession Message-ID: Hi Ross, I ran into a crash when adding the RTSP server to our storage engine. I have come up with a work around but I'm not sure if it is the right place to fix. The work around I've implemented is adding a check to the checkForAuxSDPLine1() method: void H264VideoFileServerMediaSubsession::checkForAuxSDPLine1() { char const* dasl; + if (fDoneFlag) return; + if (fAuxSDPLine != NULL) { // Signal the event loop that we're done: But I'm not sure if this is the right place to do the check since it seems more related to the order of how the events are handled. This same fix (if it is a fix) should also be applied to H265VideoFileServerMediaSubsession and the MPEG4VideoFileServerMediaSubsession class. Explanation of what I figured out so far: It started with my own source filter (based on DeviceSource) that extracts recorded data (raw MPEG-4 or H.264). But sometimes there isn't data recorded in which case the Source filter calls handleClosure() to shutdown. What then happens is I get a crash in fDummyRTPSink->auxSDPLine() called from checkForAuxSDPLine1() which tries to access a freed source filter. Since fDummyRTPSink is just a pointer to the created source filter but no longer pointing to a valid source filter. Then I checked if it was a specific problem with my source filter by running the DynamicRTSPServer and request a RTSP session with VLC for an empty file (zero byte) 'media.h264' file. I got the same crash in the server with the H264VideoFileSource as I had with my source filter. What I see happening is when a DESCRIBE comes in a RTP sink is created to extract auxiliary SDP lines by calling into getAuxSDPLine(). This starts the source filter in the startPlaying() call. The source filter's doGetNextFrame() is called which calls handleClosure() which triggers afterPlayingDummy1() which will set the done flag and unschedules any tasks (which aren't yet started). Next checkForAuxSDPLine1 will be called which schedules a task to checkForAuxSDPLine() since there is no data available. Then in getAuxSDPLine() the event loop is started that eventually runs the scheduled task and checkForAuxSDPLine1() will be entered again, but this time the source filter is freed and the pointer fDummyRTPSink points to a chunk of memory no longer being a source filter the result is a crash. When I prevent the source from calling handleClosure() I can't shutdown my application since it runs the even loop from the H264VideoFileServerMediaSubsession which won't check my flag. It will also crash the server eventually if enough RTSP describe requests have been received with a stack overflow since it basically recurse the getAuxSDPLine() method. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. From finlayson at live555.com Thu Mar 13 14:00:57 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Mar 2014 14:00:57 -0700 Subject: [Live-devel] Crash in MPEG4/H264/H265 VideoFileServerMediaSubSession In-Reply-To: References: Message-ID: Robert, Thanks for the note. I found a couple of things confusing, however: > Then I checked if it was a specific problem with my source filter by running > the DynamicRTSPServer and request a RTSP session with VLC for an empty file > (zero byte) 'media.h264' file. I got the same crash in the server with the > H264VideoFileSource as I had with my source filter. By this I presume you meant that you ran the (unmodified) "LIVE555 Media Server" with a zero-length file named "media.264" (note, *not* "media.h264"; the server doesn't handle ".h264" filename suffixes), and then tried to access it using VLC. (Note: It is better to use "testRTSPClient" or "openRTSP" as clients to test your server, because they - unlike VLC - show the RTSP protocol exchange.) However, when I did this, I didn't get any crash. Can you reproduce this problem using the unmodified "LIVE555 Media Server" (with unmodified LIVE555 library code)? (I am far more interested in problems that people can reproduce using unmodified code.) Also, at least one part of your explanation is wrong. You said - in a couple of places - that "fDummyRTPSink" is a pointer to your own 'source filter' object that you freed. That's incorrect. "fDummyRTPSink" is a pointer to a "H264VideoRTPSink" object, *not* to a "FramedSource" subclass. However, your own explanation hinted at a possible cause of your problem. You say that your 'source filter' object - if it runs out of data - calls "handleClosure()" to indicate this to the downstream objects. That's OK, and good. However, when you do this, you MUST NOT also delete the 'source filter' object (by calling "Medium::close()" on it). This object automatically gets deleted later, by higher-level code (specifically "OnDemandServerMediaSubsession.cpp", line 70). So, you MUST NOT ever delete that object yourself. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Mar 13 14:21:06 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Mar 2014 14:21:06 -0700 Subject: [Live-devel] Best place to ask general RTSP questions In-Reply-To: <5320DCEA.1070605@vivint.com> References: <5320DCEA.1070605@vivint.com> Message-ID: Questions about RTSP should be posted to this mailing list *only if* they relate specifically to the "LIVE555 Streaming Media" software. I.e., you'll need to explain - clearly and specifically - how your question relates to our software. Note that questions about how other companies products (e.g., network cameras) use RTSP should be directed instead to the manufacturers of those products - *not* to this mailing list. If you have a question about RTSP - completely independent of our (or any other) implementation - then you could send it to the IETF's "mmusic" mailing list (which discusses the RTSP standard). In any case, questions should be clear and concise. Vague, wishy-washy questions aren't appreciated anywhere. Also, a reminder that if you've made modifications to the supplied code, you can't, in general, expect support in this mailing list. So please don't try to sneak around this by trying to pretend that a question about your own code is really a general question about LIVE555 code, or about RTSP in general. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aduran at tredess.com Fri Mar 14 04:47:20 2014 From: aduran at tredess.com (=?ISO-8859-1?Q?=C1ngel_Dur=E1n_Alcaide?=) Date: Fri, 14 Mar 2014 12:47:20 +0100 Subject: [Live-devel] base64Decode issue Message-ID: <5322EC48.1050007@tredess.com> Hi Ross, I am working with live555 version 2013.09.11 on Linux and I found the following issue. I can't give more information since it is something that not always happens. (gdb) bt #0 0x00007ffff5b67425 in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff5b6ab8b in __GI_abort () at abort.c:91 #2 0x00007ffff5ba539e in __libc_message (do_abort=2, fmt=0x7ffff5caf748 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201 #3 0x00007ffff5bafb96 in malloc_printerr (action=3, str=0x7ffff5caf910 "free(): invalid next size (fast)", ptr=) at malloc.c:5039 #4 0x0000000000558a08 in base64Decode (in=0x7fffe8163a6a "", inSize=224, resultSize=@0x7ffff06d13ec: 168, trimTrailingZeros=1 '\001') at Base64.cpp:80 #5 0x000000000053d9e3 in RTSPServer::RTSPClientConnection::handleRequestBytes (this=0x7fffe8163a40, newBytesRead=224) at RTSPServer.cpp:855 #6 0x000000000053d6e9 in RTSPServer::RTSPClientConnection::incomingRequestHandler1 (this=0x7fffe8163a40) at RTSPServer.cpp:786 #7 0x000000000053d665 in RTSPServer::RTSPClientConnection::incomingRequestHandler (instance=0x7fffe8163a40) at RTSPServer.cpp:779 #8 0x00000000005e75ad in BasicTaskScheduler::SingleStep(unsigned int) () #9 0x00000000005e8d4c in BasicTaskScheduler0::doEventLoop(char*) () Is it solved in a newer version? Regards. From finlayson at live555.com Fri Mar 14 07:30:18 2014 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Mar 2014 07:30:18 -0700 Subject: [Live-devel] base64Decode issue In-Reply-To: <5322EC48.1050007@tredess.com> References: <5322EC48.1050007@tredess.com> Message-ID: <1C56E98C-0C61-4E38-82CF-50AB86E865E9@live555.com> > I am working with live555 version 2013.09.11 [...] > Is it solved in a newer version? Why don't you just try it and find out?! http://www.live555.com/liveMedia/faq.html#latest-version We support only the latest version of the software. http://www.live555.com/liveMedia/faq.html#old-versions Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Mar 16 01:18:33 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Mar 2014 01:18:33 -0700 Subject: [Live-devel] FYI: The "LIVE555 Streaming Media" software now supports streaming/receiving several 'Xiph.org' codecs Message-ID: <35C2B6BA-8039-4666-9869-1785DCDB556C@live555.com> FYI, as of the current release (2014.03.16), the "LIVE555 Streaming Media" software supports several 'Xiph.org' (and related unencumbered) audio and video codecs. (Just to be clear, our software doesn't include any codec (encoding or decoding) functionality of its own, but it can be used in combination with third-party codec libraries.) In particular: - We now support streaming (transmitting and/or receiving) RTSP/RTP streams containing any of the following 'Xiph.org' (and related) codecs: Audio: Vorbis, Speex, Opus Video: Theora, VP8. (VP9 is not yet supported, because its RTP payload format has not yet been defined.) - Our RTSP server implementation (including the "LIVE555 Media Server" product) can now demultiplex and stream from an 'Ogg'-format file (with filename extension ".ogg", ".opus", or ".ogv"). It can also demultiplex and stream Vorbis, Theora, Opus, or VP8 streams from Matroska (".mkv" or ".webm") files. (This is in addition to the many other codecs - including AAC, AC3, H.264 and H.265 - that we have been able to demlutiplex and stream from Matroska files for some time.) - We now have a new 'sink' class "OggFileSink" for writing a (single) incoming Vorbis, Theora, or Opus stream into a corresponding 'Ogg'-format file that can be played by a media player. (Our "openRTSP" client application automatically uses this class when receiving such streams via RTSP/RTP.) Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpcarrol at eagle.fgcu.edu Sun Mar 16 09:23:07 2014 From: jpcarrol at eagle.fgcu.edu (James Carroll) Date: Sun, 16 Mar 2014 16:23:07 +0000 Subject: [Live-devel] Compilation error -- NetCommon.h: No such file or directory Message-ID: Hi, all. I'm new to the list, so forgive me if this has been asked before. I have been looking into the issue and can't seem to find a straightforward answer. I have done the basic installation of live555 for Linux, via: ./genMakefiles linux make make install which compiles the library and puts the resulting files in /usr/local/include, lib, and bin. I can't seem to get a basic program working, though, due to improperly referenced header files in the code. (compiler output) [root at apollo streamtest]# g++ streamtest.cpp In file included from streamtest.cpp:1:0: /usr/local/include/UsageEnvironment/UsageEnvironment.hh:28:23: fatal error: NetCommon.h: No such file or directory #include "NetCommon.h" What is the best way to resolve this? Kind regards, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Mar 16 13:10:37 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Mar 2014 13:10:37 -0700 Subject: [Live-devel] Compilation error -- NetCommon.h: No such file or directory In-Reply-To: References: Message-ID: <56B615DF-1600-47C9-A93F-7218DF3A209C@live555.com> > I have done the basic installation of live555 for Linux, via: > > ./genMakefiles linux > make > make install > > which compiles the library and puts the resulting files in /usr/local/include, lib, and bin. I can't seem to get a basic program working, though, due to improperly referenced header files in the code. > > (compiler output) > > [root at apollo streamtest]# g++ streamtest.cpp > In file included from streamtest.cpp:1:0: > /usr/local/include/UsageEnvironment/UsageEnvironment.hh:28:23: fatal error: NetCommon.h: No such file or directory > #include "NetCommon.h" > > What is the best way to resolve this? Your problem is simply that you're not including the include path for the LIVE555 header files in your compilation line. Most people build applications using the "make" command, rather than directly invoking the compiling/linking tools from the command line. Look at how the "Makefile" in the "testProgs" directory works. You'll want to do something similar. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From R.Suijker at tkhsecurity.com Mon Mar 17 00:29:01 2014 From: R.Suijker at tkhsecurity.com (Robert Suijker) Date: Mon, 17 Mar 2014 07:29:01 +0000 Subject: [Live-devel] Crash in MPEG4/H264/H265 VideoFileServerMediaSubSession Message-ID: Hi Ross, Thanks for the input so far. > By this I presume you meant that you ran the (unmodified) "LIVE555 Media Server" with a zero-length file named "media.264" Yes, this is correct, unmodified live 555 code (latest version) and a zero length media.265 file. This was a typo on my side :( > Also, at least one part of your explanation is wrong. You said - in a couple of places - that "fDummyRTPSink" is a pointer to your own 'source filter' object that you freed. I can't recall that I said that I freed the object myself, this is certainly not what I do. But I made an error saying it was the source filter, but I meant the RTPSink. I've tested again with the DynamicRTSPServer (unmodified) and this time with the testRTSPClient (also unmodified). Running again I've the same *crash*. Tested on Window 7 and 8. I've added the client output at the end of this mail. What I see is that the server does return a SDP, but I'm missing the a=fmtp line. Testing with the slamtv10.264 file everything works as expected of course ;-) I've followed program of the server execution in the Visual Studio 2013 debugger and I get an access violation accessing 0xfeeefeee which is an indication that the program is accessing freed memory. I've traced method execution a little bit better this time and this is what I see executed (again, debugged compiled server from unmodified source code): When a DESCRIBE request is handled: generateSDPDescription() will be call which calls sdpLines() on the OnDemandServerMediaSubsession object. sdpLines() will create a new streamSource (aka FramedSource) and a dummy RTPSink with this source. It will then call setSDPLinesFromRTPSink() which will call getAuxSDPLine() which is implemented in H265/H265/MPEG4VideoFileServerMediaSubsession. getAuxSDPLine() assigned a the passed rtpSink pointer to fDummyRTPSink. Then it will initiate startPlaying() which will eventually call into ByteStreamFileSource::doGetNextFrame(). Since it is an zero length file the source will call handleClosure(). This eventually will trigger afterPlayingDummy1() which set the done flag with setDoneFlag(). Then we end up after the next line after startPlaying() in getAuxSDPLine() which is checkForAuxSDPLine(), this will fail also to read bytes so it ends up in the final else which will schedule a task checkForAuxSDPLine(). Again we end up in getAuxSDPLine() which execute the envir().taskScheduler().doEventLoop(&fDoneFlag) but will exit since the done flag was set. Then we're back in OnDemandServerMediaSubsession::sdpLines() which will call Medium::close(dummyRTPSink) and closeStreamSource(inputSource) closing the inputSource. Both will call the virtual destructors on Medium. Since there is still one scheduled task left from the else in checkForAuxSDPLine1() it will (when entering the main loop) call back into checkForAuxSDPLine1() which will crash on fDummRTPSink->auxSDPLine() which will access the rtpSink (and through it the source) which are already deleted. So I do see an execution order that will eventual access a freed object (rtpSink). I hope this explains it a bit more clear. Regards, Robert Sujker Output of the server/client: Opening connection to 127.0.0.1, port 8554... ...remote connection opened Sending request: DESCRIBE rtsp://localhost:8554/media.264 RTSP/1.0 CSeq: 2 User-Agent: rtsp_client.exe (LIVE555 Streaming Media v2014.02.26) Accept: application/sdp Received 562 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Fri, Mar 14 2014 13:30:59 GMT Content-Base: rtsp://127.0.0.1:8554/media.264/ Content-Type: application/sdp Content-Length: 397 v=0 o=- 1394803859323704 1 IN IP4 10.0.0.193 s=H.264 Video, streamed by the LIVE555 Media Server i=media.264 t=0 0 a=tool:LIVE555 Streaming Media v2014.02.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server a=x-qt-text-inf:media.264 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=control:track1 [URL:"rtsp://127.0.0.1:8554/media.264/"]: Got a SDP description: v=0 o=- 1394803859323704 1 IN IP4 10.0.0.193 s=H.264 Video, streamed by the LIVE555 Media Server i=media.264 t=0 0 a=tool:LIVE555 Streaming Media v2014.02.26 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server a=x-qt-text-inf:media.264 m=video 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:500 a=rtpmap:96 H264/90000 a=control:track1 [URL:"rtsp://127.0.0.1:8554/media.264/"]: Initiated the "video/H264" subsession (client ports 58194-58195) Sending request: SETUP rtsp://127.0.0.1:8554/media.264/track1 RTSP/1.0 CSeq: 3 User-Agent: rtsp_client.exe (LIVE555 Streaming Media v2014.02.26) Transport: RTP/AVP;unicast;client_port=58194-58195 Received 208 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Fri, Mar 14 2014 13:30:59 GMT Transport: RTP/AVP;unicast;destination=127.0.0.1;source=127.0.0.1;client_port=58194-58195;server_port=6970-6971 Session: A2DE3417;timeout=65 [URL:"rtsp://127.0.0.1:8554/media.264/"]: Set up the "video/H264" subsession (client ports 58194-58195) [URL:"rtsp://127.0.0.1:8554/media.264/"]: Created a data sink for the "video/H264" subsession Sending request: PLAY rtsp://127.0.0.1:8554/media.264/ RTSP/1.0 CSeq: 4 User-Agent: rtsp_client.exe (LIVE555 Streaming Media v2014.02.26) Session: A2DE3417 Range: npt=0.000- [URL:"rtsp://127.0.0.1:8554/media.264/"]: Received RTCP "BYE" on "video/H264" subsession [URL:"rtsp://127.0.0.1:8554/media.264/"]: Closing the stream. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. From finlayson at live555.com Mon Mar 17 01:15:08 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Mar 2014 01:15:08 -0700 Subject: [Live-devel] Crash in MPEG4/H264/H265 VideoFileServerMediaSubSession In-Reply-To: References: Message-ID: Robert, Thanks for the note. You analysis seems correct. The following change should prevent the crash: In "H264VideoFileServerMediaSubsession.cpp", line 73, change } else { to } else if (!fDoneFlag) { (Ditto for "H265VideoFileServerMediaSubsession.cpp", etc.) If - for whatever reason - that doesn't work, let me know. Otherwise I'll make this change in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From R.Suijker at tkhsecurity.com Mon Mar 17 05:33:19 2014 From: R.Suijker at tkhsecurity.com (Robert Suijker) Date: Mon, 17 Mar 2014 12:33:19 +0000 Subject: [Live-devel] Crash in MPEG4/H264/H265 VideoFileServerMediaSubSession Message-ID: Many thanks, > In "H264VideoFileServerMediaSubsession.cpp", line 73, change Yes, I agree. I gave a similar fix in my first post. So the fix you suggest works. The only thing that troubles me a bit is that a SDP is still returned from the DESCRIBE, so that the client still issues a PLAY which then fails. But I'm not sure what the correct action should be in this case (my gut feeling tells me that the DESCRIBE should fail however). Regards, Robert Suijker This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. From thetraveller94 at gmail.com Tue Mar 18 12:24:59 2014 From: thetraveller94 at gmail.com (lonely heart) Date: Wed, 19 Mar 2014 00:54:59 +0530 Subject: [Live-devel] Implementation of RTSP server Message-ID: Hi, Does anyone have an implemented RSTP server to stream the video file which the client has requested. The user DOES NOT want to allow all the files, but only a few files which he wants to share. If anyone has a good documentation of the library, please share it. Any help would be greatly appreciated. Thanks and Regards, TheTraveller -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Tue Mar 18 14:48:04 2014 From: warren at etr-usa.com (Warren Young) Date: Tue, 18 Mar 2014 15:48:04 -0600 Subject: [Live-devel] Implementation of RTSP server In-Reply-To: References: Message-ID: <5328BF14.4020906@etr-usa.com> On 3/18/2014 13:24, lonely heart wrote: > Does anyone have an implemented RSTP server to stream the video file > which the client has requested. The testOnDemandRTSPServer program that comes with Live555 does exactly that. > The user DOES NOT want to allow all the > files, testOnDemandRTSPServer only serves files in the current directory, or in directories underneath that one. Unless you run it from your system's root directory, it cannot serve all files, even if it had permissions to read all of them. > but only a few files which he wants to share. So put those files in a directory, and run testOnDemandRTSPServer in that directory. Alternately, you can use your OS's permissions system to make certain files readable to the user running testOnDemandRTSPServer, while others which are available in that directory are unreadable. > If anyone has a good documentation of the library, please share it. You believe we are holding out on you, keeping the good documentation for ourselves? The documentation on live555.com is all there is, good, bad or mixed. From finlayson at live555.com Tue Mar 18 15:34:03 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Mar 2014 15:34:03 -0700 Subject: [Live-devel] Implementation of RTSP server In-Reply-To: <5328BF14.4020906@etr-usa.com> References: <5328BF14.4020906@etr-usa.com> Message-ID: <8EC55608-73EC-4A30-AF99-F293BC637AED@live555.com> By default, our "RTSPServer" class - as illustrated by the "testOnDemandRTSPServer" demo application - serves only those files that have explicitly been 'installed' in the server (by the server's source code, calling "ServerMediaSession::createNew()", followed by "RTSPServer::addServerMediaSession()"). In contrast, the "LIVE555 Media Server" application uses a subclass of "RTSPServer" (named "DynamicRTSPServer") that will serve any file that's accessible to the server. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren at etr-usa.com Wed Mar 19 09:21:31 2014 From: warren at etr-usa.com (Warren Young) Date: Wed, 19 Mar 2014 10:21:31 -0600 Subject: [Live-devel] Implementation of RTSP server In-Reply-To: <8EC55608-73EC-4A30-AF99-F293BC637AED@live555.com> References: <5328BF14.4020906@etr-usa.com> <8EC55608-73EC-4A30-AF99-F293BC637AED@live555.com> Message-ID: <5329C40B.9060307@etr-usa.com> On 3/18/2014 16:34, Ross Finlayson wrote: > In contrast, the "LIVE555 Media Server" application uses a subclass of > "RTSPServer" (named "DynamicRTSPServer") that will serve any file that's > accessible to the server. mediaServer seems to be smart enough not to follow .. in paths, so not "any" file, unless you start it from the root directory. From mjbroek at gmail.com Mon Mar 24 02:44:16 2014 From: mjbroek at gmail.com (Martijn van den Broek) Date: Mon, 24 Mar 2014 10:44:16 +0100 Subject: [Live-devel] openRTSP crash with -P Message-ID: Hello, I'm getting a segfault after x seconds (whatever is in -P) when running openRTSP. This seem to only happen when I pass the -P parameter together with -4 (or -i or -q). Ive build the openRTSP from the live555-latest.tar.gz from 17 of march on Ubuntu 12.04.3 64bit connecting to a Foscam FI9805W camera. Any idea what goes wrong? Let me know how I can provide more debug information. (gdb) run -P 10 -4 -v -b 1000000 -w 1280 -h 960 -f 10 rtsp:// cam:cam at 192.168.16.31:88/videoMain The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP -P 10 -4 -v -b 1000000 -w 1280 -h 960 -f 10 rtsp:// cam:cam at 192.168.16.31:88/videoMain Opening connection to 192.168.16.31, port 88... ...remote connection opened Sending request: OPTIONS rtsp://cam:cam at 192.168.16.31:88/videoMain RTSP/1.0 CSeq: 2 User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Received 152 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Mar 24 2014 09:26:45 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Sending request: DESCRIBE rtsp://cam:cam at 192.168.16.31:88/videoMain RTSP/1.0 CSeq: 3 User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Accept: application/sdp Received 175 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 401 Unauthorized CSeq: 3 Date: Mon, Mar 24 2014 09:26:45 GMT WWW-Authenticate: Digest realm="LIVE555 Streaming Media", nonce="a620b479ced20fa51d971cca1c6702f8" Resending... Sending request: DESCRIBE rtsp://cam:cam at 192.168.16.31:88/videoMain RTSP/1.0 CSeq: 4 Authorization: Digest username="cam", realm="LIVE555 Streaming Media", nonce="a620b479ced20fa51d971cca1c6702f8", uri="rtsp:// cam:cam at 192.168.16.31:88/videoMain", response="b6c53b448696f7a2f8a1adccb7a80490" User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Accept: application/sdp Received 670 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Mar 24 2014 09:26:45 GMT Content-Base: rtsp://192.168.16.31:65534/videoMain/ Content-Type: application/sdp Content-Length: 500 v=0 o=- 1395574381238165 1 IN IP4 192.168.1.233 s=IP Camera Video i=videoMain t=0 0 a=tool:LIVE555 Streaming Media v2013.01.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:IP Camera Video a=x-qt-text-inf:videoMain 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=42001F;sprop-parameter-sets=Z0IAH5WoFAFuQA==,aM48gA== a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 b=AS:64 a=control:track2 Opened URL "rtsp://cam:cam at 192.168.16.31:88/videoMain", returning a SDP description: v=0 o=- 1395574381238165 1 IN IP4 192.168.1.233 s=IP Camera Video i=videoMain t=0 0 a=tool:LIVE555 Streaming Media v2013.01.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:IP Camera Video a=x-qt-text-inf:videoMain 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=42001F;sprop-parameter-sets=Z0IAH5WoFAFuQA==,aM48gA== a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 b=AS:64 a=control:track2 Created receiver for "video/H264" subsession (client ports 43534-43535) Ignoring "audio/PCMU" subsession, because we've asked to receive a single video session only Sending request: SETUP rtsp://192.168.16.31:65534/videoMain/track1 RTSP/1.0 CSeq: 5 Authorization: Digest username="cam", realm="LIVE555 Streaming Media", nonce="a620b479ced20fa51d971cca1c6702f8", uri="rtsp:// 192.168.16.31:65534/videoMain/", response="95bdf51c465616b26ff93b1bde08a5e4" User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Transport: RTP/AVP;unicast;client_port=43534-43535 Received 205 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Date: Mon, Mar 24 2014 09:26:45 GMT Transport: RTP/AVP;unicast;destination=192.168.16.22;source=192.168.16.31;client_port=43534-43535;server_port=6970-6971 Session: 1017CD45 Setup "video/H264" subsession (client ports 43534-43535) Outputting to the file: "output-00000-00010.mp4" Sending request: PLAY rtsp://192.168.16.31:65534/videoMain/ RTSP/1.0 CSeq: 6 Authorization: Digest username="cam", realm="LIVE555 Streaming Media", nonce="a620b479ced20fa51d971cca1c6702f8", uri="rtsp:// 192.168.16.31:65534/videoMain/", response="8e2bfca1c423739d325c08057d511fc4" User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Session: 1017CD45 Range: npt=0.000- Received 253 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Date: Mon, Mar 24 2014 09:26:45 GMT Range: npt=0.000- Session: 1017CD45 RTP-Info: url=rtsp:// 192.168.16.31:65534/videoMain/track1;seq=4855;rtptime=710532019,url=rtsp://192.168.16.31:65534/videoMain/track2;seq=0;rtptime=0 Started playing session Receiving streamed data (signal with "kill -HUP 24716" or "kill -USR1 24716" to terminate)... Program received signal SIGSEGV, Segmentation fault. 0x0000000000428f60 in FramedSource::stopGettingFrames() () (gdb) bt #0 0x0000000000428f60 in FramedSource::stopGettingFrames() () #1 0x0000000000425024 in QuickTimeFileSink::~QuickTimeFileSink() () #2 0x00000000004250a9 in QuickTimeFileSink::~QuickTimeFileSink() () #3 0x0000000000403141 in closeMediaSinks() () #4 0x0000000000404a55 in periodicFileOutputTimerHandler(void*) () #5 0x0000000000449d2b in AlarmHandler::handleTimeout() () #6 0x0000000000447ec9 in BasicTaskScheduler::SingleStep(unsigned int) () #7 0x000000000044961c in BasicTaskScheduler0::doEventLoop(char*) () #8 0x0000000000402391 in main () (gdb) -- Martijn van den Broek -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Mar 24 13:40:20 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Mar 2014 13:40:20 -0700 Subject: [Live-devel] openRTSP crash with -P In-Reply-To: References: Message-ID: > Any idea what goes wrong? Unfortunately not, because I wasn't able to reproduce this crash. Please recompile everything with "-g" (by doing: "make clean; genMakefiles linux-gdb; make"), and rerun gdb, so we can see a more detailed stack trace. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjbroek at gmail.com Tue Mar 25 00:46:37 2014 From: mjbroek at gmail.com (Martijn van den Broek) Date: Tue, 25 Mar 2014 08:46:37 +0100 Subject: [Live-devel] openRTSP crash with -P In-Reply-To: References: Message-ID: Hi Ross, Thanks for looking into this. I recompilled with linux-gdb enabled, see output below. martijn at shuttle:~/src/live$ gdb /home/martijn/src/live/testProgs/openRTSP GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: ... Reading symbols from /mnt/stuff/home/martijn/src/live/testProgs/openRTSP...done. (gdb) run -P 10 -4 -v -b 1000000 -w 1280 -h 960 -f 10 rtsp:// cam:cam at 192.168.16.31:88/videoMain Starting program: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP -P 10 -4 -v -b 1000000 -w 1280 -h 960 -f 10 rtsp:// cam:cam at 192.168.16.31:88/videoMain Opening connection to 192.168.16.31, port 88... ...remote connection opened Sending request: OPTIONS rtsp://cam:cam at 192.168.16.31:88/videoMain RTSP/1.0 CSeq: 2 User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Received 152 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Tue, Mar 25 2014 07:44:55 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER Sending request: DESCRIBE rtsp://cam:cam at 192.168.16.31:88/videoMain RTSP/1.0 CSeq: 3 User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Accept: application/sdp Received 175 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 401 Unauthorized CSeq: 3 Date: Tue, Mar 25 2014 07:44:55 GMT WWW-Authenticate: Digest realm="LIVE555 Streaming Media", nonce="924155ed4db06741a59cfef0502d2e92" Resending... Sending request: DESCRIBE rtsp://cam:cam at 192.168.16.31:88/videoMain RTSP/1.0 CSeq: 4 Authorization: Digest username="cam", realm="LIVE555 Streaming Media", nonce="924155ed4db06741a59cfef0502d2e92", uri="rtsp:// cam:cam at 192.168.16.31:88/videoMain", response="93b6d7c0469c38629f2c27981416f72c" User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Accept: application/sdp Received 670 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 4 Date: Tue, Mar 25 2014 07:44:55 GMT Content-Base: rtsp://192.168.16.31:65534/videoMain/ Content-Type: application/sdp Content-Length: 500 v=0 o=- 1395662349946269 1 IN IP4 192.168.1.233 s=IP Camera Video i=videoMain t=0 0 a=tool:LIVE555 Streaming Media v2013.01.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:IP Camera Video a=x-qt-text-inf:videoMain 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=42001F;sprop-parameter-sets=Z0IAH5WoFAFuQA==,aM48gA== a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 b=AS:64 a=control:track2 Opened URL "rtsp://cam:cam at 192.168.16.31:88/videoMain", returning a SDP description: v=0 o=- 1395662349946269 1 IN IP4 192.168.1.233 s=IP Camera Video i=videoMain t=0 0 a=tool:LIVE555 Streaming Media v2013.01.25 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:IP Camera Video a=x-qt-text-inf:videoMain 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=42001F;sprop-parameter-sets=Z0IAH5WoFAFuQA==,aM48gA== a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 b=AS:64 a=control:track2 Created receiver for "video/H264" subsession (client ports 41802-41803) Ignoring "audio/PCMU" subsession, because we've asked to receive a single video session only Sending request: SETUP rtsp://192.168.16.31:65534/videoMain/track1 RTSP/1.0 CSeq: 5 Authorization: Digest username="cam", realm="LIVE555 Streaming Media", nonce="924155ed4db06741a59cfef0502d2e92", uri="rtsp:// 192.168.16.31:65534/videoMain/", response="eff5eb22bfd82a5ef46a49ce014fbe68" User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Transport: RTP/AVP;unicast;client_port=41802-41803 Received 205 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Date: Tue, Mar 25 2014 07:44:55 GMT Transport: RTP/AVP;unicast;destination=192.168.16.22;source=192.168.16.31;client_port=41802-41803;server_port=6970-6971 Session: B742999A Setup "video/H264" subsession (client ports 41802-41803) Outputting to the file: "output-00000-00010.mp4" Sending request: PLAY rtsp://192.168.16.31:65534/videoMain/ RTSP/1.0 CSeq: 6 Authorization: Digest username="cam", realm="LIVE555 Streaming Media", nonce="924155ed4db06741a59cfef0502d2e92", uri="rtsp:// 192.168.16.31:65534/videoMain/", response="34bef512edcddeadc328c20b0d95fb14" User-Agent: /mnt/stuff/home/martijn/src/live/testProgs/openRTSP (LIVE555 Streaming Media v2014.03.18) Session: B742999A Range: npt=0.000- Received 255 new bytes of response data. Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Date: Tue, Mar 25 2014 07:44:55 GMT Range: npt=0.000- Session: B742999A RTP-Info: url=rtsp:// 192.168.16.31:65534/videoMain/track1;seq=18320;rtptime=3117251154,url=rtsp://192.168.16.31:65534/videoMain/track2;seq=0;rtptime=0 Started playing session Receiving streamed data (signal with "kill -HUP 20696" or "kill -USR1 20696" to terminate)... Program received signal SIGSEGV, Segmentation fault. FramedSource::stopGettingFrames (this=0x0) at FramedSource.cpp:108 108 fIsCurrentlyAwaitingData = False; // indicates that we can be read again (gdb) bt #0 FramedSource::stopGettingFrames (this=0x0) at FramedSource.cpp:108 #1 0x00000000004222cf in QuickTimeFileSink::~QuickTimeFileSink (this=0x67daf0, __in_chrg=) at QuickTimeFileSink.cpp:321 #2 0x0000000000422349 in QuickTimeFileSink::~QuickTimeFileSink (this=0x67daf0, __in_chrg=) at QuickTimeFileSink.cpp:333 #3 0x0000000000405427 in MediaLookupTable::remove (this=0x671a30, name=) at Media.cpp:151 #4 0x000000000040551a in Medium::close (env=..., name=0x67db00 "liveMedia4") at Media.cpp:53 #5 0x0000000000405532 in Medium::close (medium=) at Media.cpp:59 #6 0x00000000004021b1 in closeMediaSinks () at playCommon.cpp:1053 #7 0x0000000000403a0e in periodicFileOutputTimerHandler () at playCommon.cpp:1126 #8 0x0000000000443e7b in AlarmHandler::handleTimeout (this=0x67e7d0) at BasicTaskScheduler0.cpp:34 #9 0x0000000000442d9c in DelayQueue::handleAlarm (this=0x671018) at DelayQueue.cpp:187 #10 0x0000000000442813 in BasicTaskScheduler::SingleStep (this=0x671010, maxDelayTime=) at BasicTaskScheduler.cpp:204 #11 0x0000000000443925 in BasicTaskScheduler0::doEventLoop (this=0x671010, watchVariable=0x0) at BasicTaskScheduler0.cpp:80 #12 0x0000000000405182 in main (argc=, argv=) at playCommon.cpp:609 On Mon, Mar 24, 2014 at 9:40 PM, Ross Finlayson wrote: > Any idea what goes wrong? > > > Unfortunately not, because I wasn't able to reproduce this crash. Please > recompile everything with "-g" (by doing: "make clean; genMakefiles > linux-gdb; make"), and rerun gdb, so we can see a more detailed stack trace. > > > 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 > > -- Martijn van den Broek -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 25 02:35:28 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 25 Mar 2014 02:35:28 -0700 Subject: [Live-devel] openRTSP crash with -P In-Reply-To: References: Message-ID: <1991BE20-189F-4C97-A995-4D604BA96F81@live555.com> Martijn, Thanks for the report. The following change to the code should prevent the problem: In "QuickTimeFileSink.cpp", line 321, change subsession->readSource()->stopGettingFrames(); to if (subsession->readSource() != NULL) subsession->readSource()->stopGettingFrames(); I'll make this change in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Mar 25 15:13:33 2014 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 25 Mar 2014 15:13:33 -0700 Subject: [Live-devel] New "LIVE555 Streaming Media" release - now supporting RTCP multiplexed with RTP on a single port Message-ID: <8555CDD6-E099-4E7E-A291-ADB6E53B67F0@live555.com> The latest release (2014.03.25) of the "LIVE555 Streaming Media" software supports (both transmitting and receiving) RTCP packets that are multiplexed on the same port as RTP packets. (This is optional behavior; the default behavior is still to have RTP packets sent on an even-numbered port, and RTCP packets sent on the next (i.e., odd-numbered) port. Also, this applies only to RTP/RTCP-over-UDP, not to RTP/RTCP-over-TCP streaming.) In particular: - RTCP-multiplexing-with-RTP is signaled by a media-level attribute "a=rtcp-mux" (as defined in RFC 5761) in the stream's SDP description. If a RTSP client sees this attribute in the stream's SDP description, it uses a single UDP port number (which can be odd or even) to receive both RTP and RTCP. - A RTSP server can (optionally) be set up to stream RTCP-multiplexed-with-RTP (in which case it will choose either an odd or even-numbered port, and automatically include the "a=rtcp-mux" attribute in the stream's SDP description). When programming a RTSP server application, you can enable RTCP-multiplexing-with-RTP by doing the following: - If you're creating a "PassiveServerMediaSubsession" (for streaming via multicast), make the "rtpSink" and "rtcpInstance" parameter objects use the same "Groupsock" object. - If you're creating an "OnDemandServerMediaSubsession" (for streaming via unicast), either: 1/ Set the optional "multiplexRTCPWithRTP" parameter (in the "OnDemandServerMediaSubsession" constructor) to True, or 2/ After the "OnDemandServerMediaSubsession" object has been created, call the new "multiplexRTCPWithRTP()" member function on it. IMPORTANT NOTE: Few (if any) RTSP clients (other than those that use this software - version 2014.03.25 or later) will support RTCP-multiplexing-with-RTP. Therefore, if you're programming a RTSP server application, you should not enable this feature, unless you know for sure that all RTCP clients will be using our software (version 2014.03.25 or later). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From putta.pv at gmail.com Wed Mar 26 19:42:47 2014 From: putta.pv at gmail.com (PUTTA SUKESH) Date: Thu, 27 Mar 2014 08:12:47 +0530 Subject: [Live-devel] How can I stream video in live555 using FFMPEG Message-ID: I am making an application for streaming webcam. I would like to use *ffmpeg *to capture camera, *ffmpeg *as encoder and live555 as server. Can anyone help, how can I capture encoder video and how can I stream it using live555. I am using VLC on client side. So can anyone provide me some tutorial or example about implementing. Thanks in advanced -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.pis.langlois at transport.alstom.com Thu Mar 27 11:55:23 2014 From: olivier.pis.langlois at transport.alstom.com (LANGLOIS Olivier PIS -EXT) Date: Thu, 27 Mar 2014 18:55:23 +0000 Subject: [Live-devel] RTSP/1.0 454 Session Not Found question Message-ID: <89F8E4011FD7234ABFE48744E300CBC206C0F5A6@041-DB3MPN1-093.041d.mgd.msft.net> Hi, I am using live555MediaServer v0.82 on Windows. When using the server, I receive teh 454 Session Not Found error. Can someone point me on the reason why I am having this error. The client is using the id just returned by the server. I'm a bit puzzled. Thank you, Below are all the details: By attempting to use it with mplayer with the following cmdline: [meego at localhost librtsp]$ mplayer -vo vaapi -noborder -geometry 640x480+0+0 rtsp://192.168.16.1/Sam3-640x480.ts MPlayer SVN-r36265-4.5.1 (C) 2000-2013 MPlayer Team Cannot test OS support for SSE, disabling to be safe. Playing rtsp://192.168.16.1/Sam3-640x480.ts. Connecting to server 192.168.16.1[192.168.16.1]: 554... librtsp: server responds: 'RTSP/1.0 454 Session Not Found' And on the windows side: D:\Documents and Settings\100517891\My Documents\My Movies>dir *.ts Volume in drive D is DATA Volume Serial Number is 9013-67C6 Directory of D:\Documents and Settings\100517891\My Documents\My Movies 03/24/2014 03:54 PM 134,508,360 Sam3-640x480.ts 1 File(s) 134,508,360 bytes 0 Dir(s) 125,650,284,544 bytes free D:\Documents and Settings\100517891\My Documents\My Movies>live555MediaServer.exe LIVE555 Media Server version 0.82 (LIVE555 Streaming Media library version 2014.03.16). Play streams from this server using the URL rtsp://10.90.50.69/ where is a file present in the current directory. Each file's type is inferred from its name suffix: ".264" => a H.264 Video Elementary Stream file ".265" => a H.265 Video Elementary Stream file ".aac" => an AAC Audio (ADTS format) file ".ac3" => an AC-3 Audio file ".amr" => an AMR Audio file ".dv" => a DV Video file ".m4e" => a MPEG-4 Video Elementary Stream file ".mkv" => a Matroska audio+video+(optional)subtitles file ".mp3" => a MPEG-1 or 2 Audio file ".mpg" => a MPEG-1 or 2 Program Stream (audio+video) file ".ogg" or ".ogv" or ".opus" => an Ogg audio and/or video file ".ts" => a MPEG Transport Stream file (a ".tsx" index file - if present - provides server 'trick play' support) ".vob" => a VOB (MPEG-2 video with AC-3 audio) file ".wav" => a WAV Audio file ".webm" => a WebM audio(Vorbis)+video(VP8) file See http://www.live555.com/mediaServer/ for additional documentation. (We use port 8000 for optional RTSP-over-HTTP tunneling, or for HTTP live streaming (for indexed Transport Stream files only).) With WireShark, I see this: OPTIONS rtsp://192.168.16.1:554 RTSP/1.0 CSeq: 1 User-Agent: RealMedia Player Version 6.0.9.1235 (linux-2.0-libc6-i386-gcc2.95) ClientChallenge: 9e26d33f2984236010ef6253fb1887f7 PlayerStarttime: [28/03/2003:22:50:23 00:00] CompanyID: KnKV4M4I/B2FjJ1TToLycw== GUID: 00000000-0000-0000-0000-000000000000 RegionData: 0 ClientID: Linux_2.4_6.0.9.1235_play32_RN01_EN_586 RTSP/1.0 200 OK CSeq: 1 Date: Mon, Mar 24 2014 20:09:45 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER DESCRIBE rtsp://192.168.16.1:554/Sam3-640x480.ts RTSP/1.0 CSeq: 2 Accept: application/sdp RTSP/1.0 200 OK CSeq: 2 Date: Mon, Mar 24 2014 20:09:45 GMT Content-Base: rtsp://192.168.16.1/Sam3-640x480.ts/ Content-Type: application/sdp Content-Length: 407 v=0 o=- 1395691762241832 1 IN IP4 10.90.50.69 s=MPEG Transport Stream, streamed by the LIVE555 Media Server i=Sam3-640x480.ts t=0 0 a=tool:LIVE555 Streaming Media v2014.03.16 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:MPEG Transport Stream, streamed by the LIVE555 Media Server a=x-qt-text-inf:Sam3-640x480.ts m=video 0 RTP/AVP 33 c=IN IP4 0.0.0.0 b=AS:5000 a=control:track1 SETUP rtsp://192.168.16.1:554/Sam3-640x480.ts/track1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=31336-31337;mode="PLAY" RTSP/1.0 200 OK CSeq: 3 Date: Mon, Mar 24 2014 20:09:45 GMT Transport: RTP/AVP;unicast;destination=192.168.16.235;source=192.168.16.1;client_port=31336-31337;server_port=6972-6973 Session: 35E0EC2D;timeout=65 PLAY rtsp://192.168.16.1:554/Sam3-640x480.ts RTSP/1.0 CSeq: 4 Session: 35E0EC2D;timeout=65 Range: npt=0- RTSP/1.0 454 Session Not Found CSeq: 4 Date: Mon, Mar 24 2014 20:09:46 GMT ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium. From finlayson at live555.com Thu Mar 27 16:20:25 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Mar 2014 16:20:25 -0700 Subject: [Live-devel] RTSP/1.0 454 Session Not Found question In-Reply-To: <89F8E4011FD7234ABFE48744E300CBC206C0F5A6@041-DB3MPN1-093.041d.mgd.msft.net> References: <89F8E4011FD7234ABFE48744E300CBC206C0F5A6@041-DB3MPN1-093.041d.mgd.msft.net> Message-ID: <4FEBC58D-76B6-4366-9C03-A3B83EB3C3AF@live555.com> The problem is in the RTSP "PLAY" request that your media player ("MPlayer") is sending. > PLAY rtsp://192.168.16.1:554/Sam3-640x480.ts RTSP/1.0 > > CSeq: 4 > > Session: 35E0EC2D;timeout=65 > > Range: npt=0- The ";timeout=65" in the "Session:" header is wrong. The RTSP specification (RFC 2326, section 12.37) clearly states that "The timeout parameter is only allowed in a response header". Please ask the developers of your media player to fix this problem. Alternatively, you could use a better media player. I suggest using VLC Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From goran.ambardziev at gmail.com Thu Mar 27 02:43:39 2014 From: goran.ambardziev at gmail.com (Goran Ambardziev) Date: Thu, 27 Mar 2014 10:43:39 +0100 Subject: [Live-devel] H264 RTP multicast Message-ID: Hello, A little bit info about my application: I have created H264 RTP Multicast application, based on *testH264VideoStreamer* application. Instead from a file, I'm interested in streaming H264 from Microsoft Media Foundation H264 Video Encoder ( http://msdn.microsoft.com/en-us/library/windows/desktop/dd797816(v=vs.85).aspx ) So, I've sub classed FramedSource and created my own H264FramedSource which feeds the H264VideoStreamDiscreteFramer. So far so good: I've tested with VLC and openRTSP and my server is streaming packets to them. Now the problem is that the picture is all scrambled. I know that it got something to do with how I deliver/handle NAL Units and this is my question to this forum. >From the encoder, I get buffers with multiple NAL Units. NAL Units are all with 0x00000001 start codes. I strip this codes from the buffers, break the buffer and send the packets as separate NAL units. Also, I get NAL Units with fragments. As much as I understand, live555 lib can handle NAL Units with fragments. But anyway, I've tried it both ways: 1. send NAL Units as single packet or 2. divide fragments and send them separately. If 1, I get a scrambled picture in VLC, if 2 I get no picture at all. Can somebody point to me where I should be looking next, and where might the problem be? What should I be looking on? Thanks, Goran. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Mar 27 20:20:21 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Mar 2014 20:20:21 -0700 Subject: [Live-devel] How can I stream video in live555 using FFMPEG In-Reply-To: References: Message-ID: > I am making an application for streaming webcam. I would like to use ffmpeg to capture camera, ffmpeg as encoder and live555 as server. Can anyone help, how can I capture encoder video and how can I stream it using live555. I am using VLC on client side. So can anyone provide me some tutorial or example about implementing. Thanks in advanced See 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 Thu Mar 27 20:43:37 2014 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 27 Mar 2014 20:43:37 -0700 Subject: [Live-devel] H264 RTP multicast In-Reply-To: References: Message-ID: > From the encoder, I get buffers with multiple NAL Units. NAL Units are all with 0x00000001 start codes. I strip this codes from the buffers, break the buffer and send the packets as separate NAL units. Yes, this is correct (provided that you deliver NAL units to the downstream "H264VideoStreamDiscreteFramer" one at a time) > Also, I get NAL Units with fragments. What specifically do you mean by "fragments" here? Do you mean slices? I.e., are you talking about NAL units that each represent just one 'slice' of a frame (picture)? If so, then yes, we support this. You can treat these NAL units just like any other; deliver them (one at a time) to the downstream "H264VideoStreamDiscreteFramer". Or are you instead referring to multiple chunks of data (that are *not* NAL units themselves) that, if combined together, form a single (large) NAL unit? If so, then you *must not* deliver these chunks of data separately. Instead, you *must* combine these chunks into a single NAL unit, and deliver this completely (without the 'start code', of course) to the downstream "H264VideoStreamDiscreteFramer"). Another thing to be aware of is that if a NAL unit can be very large, you may need to change the value of "OutPacketBuffer::maxSize" (in "testH264VideoStreamer.cpp" from 100000 (bytes) to something larger. Far better, though, is to (if possible) reconfigure your encoder to break up such large NAL units into multiple 'slice' NAL units. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From goran.ambardziev at gmail.com Fri Mar 28 15:49:10 2014 From: goran.ambardziev at gmail.com (Goran Ambardziev) Date: Fri, 28 Mar 2014 23:49:10 +0100 Subject: [Live-devel] H264 RTP multicast Message-ID: <5335FC66.1030002@gmail.com> Ross, thanks a lot for your help! > From the encoder, I get buffers with multiple NAL Units. NAL Units are all with 0x00000001 start codes. I strip this codes from the buffers, break the buffer and send the packets as separate NAL units. >> Yes, this is correct (provided that you deliver NAL units to the downstream "H264VideoStreamDiscreteFramer" one at a time) Yes, when I receive the buffer, I look for start codes, break the buffer and send NALU's to the downstream "H264VideoStreamDiscreteFramer" one by one (off course, without start codes). In this situation, in VLC I just get the first image and the following error(s): direct3d warning: trying surface pixel format: YV12 main error: ES_OUT_RESET_PCR called In openRTSP, which I start to create mp4 files with 5 seconds length (openRTSP -4 -P 5 -w 720 -h 576 -f 25 rtsp://...) I get mp4 files, which VLC reports that are 40 seconds long (also MediaInfo) and not a single frame can be decoded. Now, this is the first approach I'm trying. > Also, I get NAL Units with fragments. >> What specifically do you mean by "fragments" here? Do you mean slices? I.e., are you talking about NAL units that each represent just one 'slice' of a frame (picture)? If so, then yes, we support this. You can treat these NAL units just like any other; deliver them (one at a time) to the downstream "H264VideoStreamDiscreteFramer". >> Or are you instead referring to multiple chunks of data (that are *not* NAL units themselves) that, if combined together, form a single (large) NAL unit? If so, then you *must not* deliver these chunks of data separately. Instead, you *must* combine these chunks into a single NAL unit, and deliver this completely (without the 'start code', of course) to the downstream "H264VideoStreamDiscreteFramer"). I'm not all that much familiar with H264 specification or the inner workings of the encoder. I based my code on a working RTSP server (wrapped as a DirectShow filter, from here: http://www.gdcl.co.uk/2013/05/16/RTSP-Jukebox.html). Now, in that code, there's a NAL unit parser, which my code is based on. The code there presumes that: const int max_packet_size = 1514 - 42; // observed from Wireshark const int rtp_header_size = 12; static int SinglePacketSize() { return max_packet_size - rtp_header_size; } static int FragmentSize() { return SinglePacketSize() -2; } If the NALU size is <= SinglePacketSize, it gets forwarded as it is, but when NALU is bigger then SinglePacketSize, then the code fragments the buffer by the value of FragmentSize. So if NALU buffer size is 2 x SinglePacketSize, then it will fragment it to buffers with FragmentSize size and send it downstream one by one. Now, I don't know why is this, but this RTSP server (unicast) is working fine with the Media Foundation H264 Encoder and playing fine in VLC and/or other Streaming Clients. If I try this approach in my code, in VLC I get the error: "live555 warning: unsupported NAL type for H264" and after that, "avcodec warning: cannot decode one frame (1614 bytes)" In openRTSP the same situation as in previous case. This is the second approach I'm trying. > Another thing to be aware of is that if a NAL unit can be very large, you may need to change the value of "OutPacketBuffer::maxSize" (in "testH264VideoStreamer.cpp" from 100000 (bytes) to something larger. The max size of the NALU packets I'm forwarding to live555 isn't bigger then 4000-5000 bytes. Thanks and sorry for the long post, Goran. -------------- next part -------------- An HTML attachment was scrubbed... URL: From goran.ambardziev at gmail.com Fri Mar 28 16:55:12 2014 From: goran.ambardziev at gmail.com (Goran Ambardziev) Date: Sat, 29 Mar 2014 00:55:12 +0100 Subject: [Live-devel] H264 RTP multicast In-Reply-To: <5335FC66.1030002@gmail.com> References: <5335FC66.1030002@gmail.com> Message-ID: <53360BE0.4030204@gmail.com> Ross (and everybody), Sorry for wasting your time! live555 can handle NAL units as I send them, and there's no need for fragmentation (as I've mentioned before). My error was in timing the packets in my H264FramedSource class. I feel so silly now. Thanks, Goran. On 28.03.2014 23:49, Goran Ambardziev wrote: > Ross, thanks a lot for your help! > > > From the encoder, I get buffers with multiple NAL Units. NAL Units are all with 0x00000001 start codes. I strip this codes from the buffers, break the buffer and send the packets as separate NAL units. > > >> Yes, this is correct (provided that you deliver NAL units to the downstream "H264VideoStreamDiscreteFramer" one at a time) > > Yes, when I receive the buffer, I look for start codes, break the buffer and send NALU's to the downstream "H264VideoStreamDiscreteFramer" one by one (off course, without start codes). > > In this situation, in VLC I just get the first image and the following error(s): > direct3d warning: trying surface pixel format: YV12 > main error: ES_OUT_RESET_PCR called > > In openRTSP, which I start to create mp4 files with 5 seconds length (openRTSP -4 -P 5 -w 720 -h 576 -f 25 rtsp://...) I get mp4 files, which VLC reports that are 40 seconds long (also MediaInfo) and not a single frame can be decoded. > > Now, this is the first approach I'm trying. > > > Also, I get NAL Units with fragments. > > >> What specifically do you mean by "fragments" here? Do you mean slices? I.e., are you talking about NAL units that each represent just one 'slice' of a frame (picture)? If so, then yes, we support this. You can treat these NAL units just like any other; deliver them (one at a time) to the downstream "H264VideoStreamDiscreteFramer". > > >> Or are you instead referring to multiple chunks of data (that are *not* NAL units themselves) that, if combined together, form a single (large) NAL unit? If so, then you *must not* deliver these chunks of data separately. Instead, you *must* combine these chunks into a single NAL unit, and deliver this completely (without the 'start code', of course) to the downstream "H264VideoStreamDiscreteFramer"). > > I'm not all that much familiar with H264 specification or the inner workings of the encoder. I based my code on a working RTSP server (wrapped as a DirectShow filter, from here:http://www.gdcl.co.uk/2013/05/16/RTSP-Jukebox.html). > > Now, in that code, there's a NAL unit parser, which my code is based on. The code there presumes that: > > const int max_packet_size = 1514 - 42; // observed from Wireshark > const int rtp_header_size = 12; > > static int SinglePacketSize() { return max_packet_size - rtp_header_size; } > static int FragmentSize() { return SinglePacketSize() -2; } > > If the NALU size is <= SinglePacketSize, it gets forwarded as it is, but when NALU is bigger then SinglePacketSize, then the code fragments the buffer by the value of FragmentSize. So if NALU buffer size is 2 x SinglePacketSize, then it will fragment it to buffers with FragmentSize size and send it downstream one by one. > Now, I don't know why is this, but this RTSP server (unicast) is working fine with the Media Foundation H264 Encoder and playing fine in VLC and/or other Streaming Clients. > If I try this approach in my code, in VLC I get the error: "live555 warning: unsupported NAL type for H264" and after that, "avcodec warning: cannot decode one frame (1614 bytes)" > In openRTSP the same situation as in previous case. > > This is the second approach I'm trying. > > > Another thing to be aware of is that if a NAL unit can be very large, you may need to change the value of "OutPacketBuffer::maxSize" (in "testH264VideoStreamer.cpp" from 100000 (bytes) to something larger. > > The max size of the NALU packets I'm forwarding to live555 isn't bigger then 4000-5000 bytes. > > Thanks and sorry for the long post, > Goran. -------------- next part -------------- An HTML attachment was scrubbed... URL: From goran.ambardziev at gmail.com Sat Mar 29 03:46:10 2014 From: goran.ambardziev at gmail.com (Goran Ambardziev) Date: Sat, 29 Mar 2014 11:46:10 +0100 Subject: [Live-devel] AAC RTP Multicast Message-ID: <5336A472.4080305@gmail.com> Hello, Based on test testH264VideoStreamer I have created application that streams live H264 packets, using my custom H264FramedSource, and H264VideoStreamDiscreteFramer. Now, I want to add Audio AAC stream to it, in the same manner. Can you help me and tell me that this is the correct way to do it: 1. Create AACFramedSource (subclass of FramedSource), which will be fed with AAC buffers. 2. The RTP sink will be MPEG4GenericRTPSink 2.1. How would I determine rtpPayloadFormat, rtpTimestampFrequency, sdpMediaTypeString, mpeg4Mode and configString? 3. Create another PassiveServerMediaSubsession for AAC stream and add it to sms 3.1. I should create separate Groupsock's for the AAC, right? (not use the ones for H264) 4. In the case of H264 I have used H264VideoStreamDiscreteFramer. Should I create one for AAC too? If yes, what class should I subclass? 5. Will this scenario work with RAW AAC frames (i.e. not ADTS)? Thanks, Goran. From finlayson at live555.com Sat Mar 29 14:58:43 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Mar 2014 14:58:43 -0700 Subject: [Live-devel] AAC RTP Multicast In-Reply-To: <5336A472.4080305@gmail.com> References: <5336A472.4080305@gmail.com> Message-ID: <2D6387F2-6B3E-457C-810E-611F09E9F348@live555.com> > Now, I want to add Audio AAC stream to it, in the same manner. > > Can you help me and tell me that this is the correct way to do it: > > 1. Create AACFramedSource (subclass of FramedSource), which will be fed with AAC buffers. Yes. Have it deliver one AAC audio frame at a time. > 2. The RTP sink will be MPEG4GenericRTPSink Yes. > 2.1. How would I determine rtpPayloadFormat Use a different value (in the dynamic rage) than the value (96) that you used for H.264. I suggest using 97. > , rtpTimestampFrequency This should be the sampling frequency of your AAC audio. > , sdpMediaTypeString This must be "audio" > , mpeg4Mode This should be "AAC-hbr" > and configString? This is a string - consisting of 4 hex digits - that's constructed from parameters of the audio stream. For illustration, see line 108 of "ADTSAudioFileSource.cpp". > 3. Create another PassiveServerMediaSubsession for AAC stream and add it to sms Yes. > 3.1. I should create separate Groupsock's for the AAC, right? (not use the ones for H264) Yes, you must create separate "Groupsock" objects (for RTP and RTCP) for audio. The destination IP address may be the same (multicast) address that you used for H.264 video, or it could be a different multicast address. The RTP port number must be a different port number from the port number (18888) that you used for H.264 video, and it must be even. I suggest using 18890. The RTCP port number must be the RTP port number +1 (i.e., odd). > 4. In the case of H264 I have used H264VideoStreamDiscreteFramer. Should I create one for AAC too? No. You can feed your "AACFramedSource" object directly into your "MPEG4GenericRTPSink". > 5. Will this scenario work with RAW AAC frames (i.e. not ADTS)? Yes. "ADTS" is just a file format, but you're not reading from a file. Be sure to set "fPresentationTime" properly (in your "AACFramedSource" class) for each AAC frame. To get proper audio/video sync in each media player client, this presentation time must be properly aligned with the H.264 video presentation times, and with 'wall clock' time (i.e., the time that you'd get by calling "gettimeofday()"). Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fantasyvideo at 126.com Sat Mar 29 23:57:47 2014 From: fantasyvideo at 126.com (Tony) Date: Sun, 30 Mar 2014 14:57:47 +0800 (CST) Subject: [Live-devel] Regarding the crash if the rtsp client counts is over than 10 Message-ID: <2a0c9316.e456.14511c7a4e5.Coremail.fantasyvideo@126.com> Hi Ross, I use live555 to setup one server which supports g711 and h264? And use ten vlc controls to open the rtsp stream in chrome. At last, the server crashes. it crashes in the BasicTashSchedule:setBackgroundHandling. I attach the crash screen. I hope you can check it . THANKS! Best Regards! Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: crash.png Type: image/png Size: 263437 bytes Desc: not available URL: From finlayson at live555.com Sun Mar 30 13:46:58 2014 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 30 Mar 2014 13:46:58 -0700 Subject: [Live-devel] Regarding the crash if the rtsp client counts is over than 10 In-Reply-To: <2a0c9316.e456.14511c7a4e5.Coremail.fantasyvideo@126.com> References: <2a0c9316.e456.14511c7a4e5.Coremail.fantasyvideo@126.com> Message-ID: <3C1CC4FE-CEDD-449C-947E-A54D1FDC1065@live555.com> Are you using the latest version of the "LIVE555 Streaming Media" software?? Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From goran.ambardziev at gmail.com Mon Mar 31 13:06:38 2014 From: goran.ambardziev at gmail.com (Goran Ambardziev) Date: Mon, 31 Mar 2014 22:06:38 +0200 Subject: [Live-devel] AAC/H264 RTP Multicast timestamps Message-ID: <5339CACE.5050009@gmail.com> Ross, Thanks for all the help so far! So, I have a working AAC/H264 application and I'm very close to it working just OK, except couple of glitches that needs to be settled. > Be sure to set "fPresentationTime" properly (in your "AACFramedSource" class) for each AAC frame. To get proper audio/video sync in each media player client, this presentation time must be properly aligned with the H.264 video presentation times, and with 'wall clock' time (i.e., the time that you'd get by calling "gettimeofday()"). I implemented presentation timestamping like this: 1. There's one shared timeval start presentation time variable (startPresentationTime ) between AACFramedSource and H264FramedSource. Whichever gets its sample first, it will set the startPresentationTime to gettimeofday. 2. After that, in each FramedSource (AAC/H264) fPresentationTime is set like this: unsigned uSeconds = PlayTimeOfTheSampleInMicroSeconds; fPresentationTime.tv_sec = (uSeconds/1000000) + m_presentationStartTime.tv_sec; fPresentationTime.tv_usec = (uSeconds%1000000) + m_presentationStartTime.tv_usec; PlayTimeOfTheSampleInMicroSeconds I get from the AAC/H264 encoders, respectively. Is this a good setup? When I run this, and preview it with VLC, it is kind of working, but there are lots of frames and audio buffers dropped, and I get a lot of warning messages, like this: main warning: playback too late (177441): up-sampling main warning: playback way too late (181443): flushing buffers main warning: picture is too late to be displayed (missing 655 ms) main warning: picture is too late to be displayed (missing 616 ms) main warning: picture is too late to be displayed (missing 576 ms) main warning: picture is too late to be displayed (missing 536 ms) ... Why can this be happening? I even tried to set the presentationStartTime to be 1 second ahead in the future, but to no avail, i.e.: gettimeofday(&m_presentationStartTime, NULL); // Set it 1 sec into the future m_presentationStartTime.tv_sec += 1; Thanks, Goran. From rglobisch at csir.co.za Mon Mar 31 21:55:49 2014 From: rglobisch at csir.co.za (Ralf Globisch) Date: Tue, 01 Apr 2014 06:55:49 +0200 Subject: [Live-devel] AAC/H264 RTP Multicast timestamps In-Reply-To: <5339CACE.5050009@gmail.com> References: <5339CACE.5050009@gmail.com> Message-ID: <533A62F50200004D0009F431@pta-emo.csir.co.za> > main warning: playback too late (177441): up-sampling > main warning: playback way too late (181443): flushing buffers > main warning: picture is too late to be displayed (missing 655 ms) > main warning: picture is too late to be displayed (missing 616 ms) > main warning: picture is too late to be displayed (missing 576 ms) > main warning: picture is too late to be displayed (missing 536 ms) Goran, AFAICT this is usually a VLC issue. - We see these types of messages all the time in our platform (which is implemented using live555 on the server.) A different media player we've tried seems to play the stream without these "glitches". - I see the same messages using my own RTSP/RTP stack written from scratch. Not sure if it will help at all, but you could try playing around with the various caching values in VLC. -- 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 soupim at gmail.com Mon Mar 31 21:07:19 2014 From: soupim at gmail.com (ChaSeop Im) Date: Tue, 1 Apr 2014 13:07:19 +0900 Subject: [Live-devel] debug mode build failed. Message-ID: Hi. when I try build with debug mode(2014.03.25 version). error message is oggFileServerDemux.cpp(54) : error C2039 : 'codecID' : is not a member of 'OggTrack'. oggFileServerDemux.cpp(54) is fprintf(stderr, "Created 'ServerMediaSubsession' object for track #%d: %s (%s)\n", track->trackNumber, track->codecID, track->mimeType); so, just removed track->codecID, it works. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Mar 31 22:54:53 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 31 Mar 2014 22:54:53 -0700 Subject: [Live-devel] AAC/H264 RTP Multicast timestamps In-Reply-To: <533A62F50200004D0009F431@pta-emo.csir.co.za> References: <5339CACE.5050009@gmail.com> <533A62F50200004D0009F431@pta-emo.csir.co.za> Message-ID: I also suggest making sure that: - streaming H.264 video only works OK (I think you've already done this) - streaming AAC audio only works OK before trying to stream both audio and video together. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Mar 31 23:19:53 2014 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 31 Mar 2014 23:19:53 -0700 Subject: [Live-devel] debug mode build failed. In-Reply-To: References: Message-ID: Thanks for the note. This will be fixed in the next release of the software. Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: