From ee05154 at fe.up.pt Wed Jun 1 09:01:15 2011 From: ee05154 at fe.up.pt (Nuno Mota) Date: Wed, 1 Jun 2011 17:01:15 +0100 Subject: [Live-devel] RTSP considerations and more. RTP vs TS Message-ID: Hi, currently I'm developing an RTSP client using VLC bindings. However i had to make a few adjustments to the VLC source code in order to achieve fast rewind. Tests were successful, but there are still a few bugs to be attended. I have two questions relating this issue. First in the vlc devel list I'm discussing this issue: >> The problem you mentioned in the forum is kind of a big fail (yes i'm >> mundu :). When fast rewinding the time gets stuck and then it doesn't >> update. If you press play it will only start from the time you issued >> the setRate(negative), and not at the time where I pressed play again. >> Do you know where vlc actually updates its time? > There are several issues with rtsp and time update. In fact the time > will always update at 1x speed. > That's because rtsp servers re-calculate timestamps, and vlc thinks it > receives the pictures at 1x speed. > Time update is based on timestamps It seems that VLC doesn't have a way to properly figure out at what time the video is currently playing when issuing for example a set_rate(-2). Any ideas how to solve this issue? Another question relates to the TS vs RTP. As you know set top boxes request raw-UDP because they don't need RTP overhead. However I'm currently trying to understand the benefits of eradicating the transport stream container as it proves to be the most greedy in terms of overhead. I mean RTP uses 12 bytes of overhead while 6 TS packets inside a RTP packet uses 24 bytes. Twice as much as the RTP overhead. Not to mention that both have timestamp information (redundant information). In a Video on demand application while streaming HD content, this proves to be to much in a long-term use. (And normally TS is to multiplex several Programs not just a movie). I raise this question only focused on an Internet service and not TV( STBs and DVB uses TS so no questions there). My question is, what is the downsize of using H264 without a container when it comes to trick play. As far as I know the indexer already searches for H264 I-Frames, am i wrong? But i read in a paper that the computational costs of doing such a thing is too much. Is this true? Thank you for your attention. Nuno Mota -------------- next part -------------- An HTML attachment was scrubbed... URL: From ee05154 at fe.up.pt Wed Jun 1 10:21:25 2011 From: ee05154 at fe.up.pt (Nuno Mota) Date: Wed, 1 Jun 2011 18:21:25 +0100 Subject: [Live-devel] RTSP considerations and more. RTP vs TS In-Reply-To: References: Message-ID: For some reason I got mistaken. There are 7 not 6 TS packets to a total of 28 bytes. Nuno Mota -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 1 19:06:14 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Jun 2011 19:06:14 -0700 Subject: [Live-devel] How to bypass streamlimit causes by EventTriggerIDs In-Reply-To: <4CB3F3483954BD4ABD0B4DBB35C7E33801D663AC@exchsrv.idszentral.local> References: <4CB3F3483954BD4ABD0B4DBB35C7E33801D663AC@exchsrv.idszentral.local> Message-ID: >I am using live555 to stream several network >cameras. For that I generate one RTSP-Server and >for every camera a subsession on this server >with a new URL. To signal the TaskScheduler, >that there is a new frame for a stream, I use a >EventTriggerID. Every stream has his own >EventTriggerID. Now I got the problem, that the >EventTriggerID is generated by a bitmask >(0x80000000), and the line > >"m_EventTriggerId = >envir().taskScheduler().createEventTrigger(deliverFrame0);" > >generates only 32 EventTriggerID?s, so that I >have a maximum of 32 stream receivers. >Now my question: Is it possible to solve that >problem without generating more RTSP-Server with >different TaskScheduler on different ports? Sorry for the long delay in responding to this. (I've been traveling for the past two months, and am way behind on email.) Note that the implementation of 'event triggers' that we provide (for the "BasicTaskScheduler" class) is just one possible implementation. You can - if you wish - provide your own implementation, by 1/ Defining a subclass of "BasicTaskScheduler", and 2/ Reimplementing the virtual functions virtual EventTriggerId createEventTrigger(TaskFunc* eventHandlerProc); virtual void deleteEventTrigger(EventTriggerId eventTriggerId); virtual void triggerEvent(EventTriggerId eventTriggerId, void* clientData = NULL); Note that "EventTriggerId" must remain a "u_int32_t", so you won't be able to change that. So you won't be able to continue to use it as a 'bit mask', if you want to support more than 32 triggers. But you can implement event triggers any way you choose. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 1 19:20:02 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Jun 2011 19:20:02 -0700 Subject: [Live-devel] how to capture H264 stream and save it in a avi file In-Reply-To: References: Message-ID: >I'm trying to capture a video stream from Axis IP camera with openRTSP. >I get a correct file if I use: >openRTSP -d 20 -4 -f 3 -w 640 -h 480 -b 400000 >"rtsp://10.10.1.61/axis-media/media.amp?compression=35&fps=3" >video.avi >but I try this: >openRTSP -d 20 -f 3 -w 640 -h 480 -b 400000 >"rtsp://10.10.1.61/axis-media/media.amp?compression=35&fps=3" >I obtain this file: video-H264-1 >but I can't open it. >What is wrong? Sorry for the long delay in responding to this. (I've been traveling for the past two months, and am way behind on email.) The 'problem' is only that your operating system doesn't know how to open the output file named "video-H264-1", because it is (in this case) just a raw H.264 video file, not a 'mp4'-format file. (Note, BTW, that the "-4" option tells "openRTSP" to output a 'mp4'-format file, *not* an AVI-format file.) If, however, you change the name to (e.g.) "example.h264", then some media players - for example VLC - may be able to play it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 1 19:29:21 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Jun 2011 19:29:21 -0700 Subject: [Live-devel] How To codify the testH264videoStreamer Program in order to transmit NAL units? In-Reply-To: <4DA2A5CE.6020003@discover.uottawa.ca> References: <4DA2A5CE.6020003@discover.uottawa.ca> Message-ID: Sorry for the long delay in responding to this. (I've been traveling for the past two months, and am way behind on email.) >I am trying to modify the "testH264VideoStreamer" program in order >to get NAL unit instead of using file. >I have developed an user interface to work with x264 library. the UI >is able to encode each frame and generate NAL nits using x264 >library. Now, I want to integrate this UI with >"testH264VideoStreamer" program. >I have some question: >1-How can I pass the NAL unit to this program directly? The easiest way to do this is to have make your encoder a separate application that outputs its NAL units (each prefixed with 0x00000001, of course) to 'stdout', and then pipe it to "testH264VideoStreamer" (modified to read its input from "stdin" rather than from "test.264"). Alternatively (but more difficult), you could write your own "FramedSource" subclass that encapsulates your encoder, and modify the "testH264VideoStreamer" code to read from an instance of this class, rather than from a "ByteStreamFileSource" - as described in the FAQ. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jun 1 19:49:50 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 1 Jun 2011 19:49:50 -0700 Subject: [Live-devel] How to specify an rtp client without rtsp In-Reply-To: References: Message-ID: >I've been playing with Live555 for a while now and it seems pretty >awesome, good job guys. > > > >By 'playing' I mean I've developed around live555 to send out an rtp >stream from a live source (mpeg4, mjpeg, h264, etc) all via rtsp, >and it works wonderfully. The problem I'm having is I want to be >able to specify a client listening on a certain port and have >live555 send a video stream to the specified computer and port >WITHOUT having to go through the RTSP process. In general you can't really do this, because - to set up a stream - you need information exchanged in both directions between the client and the server. This information includes not just IP addresses and port numbers, but also (in many cases) codec-specific 'configuration' information, without which the client's decoder may not work properly. The RTSP protocol does all of this. It was developed and standardized (by the IETF) and implemented (by me and others) for a reason. Don't fight RTSP; instead continue to use it in your server and client. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gennadii.ivanov at livestream.com Thu Jun 2 05:53:29 2011 From: gennadii.ivanov at livestream.com (Gennadii Ivanov) Date: Thu, 2 Jun 2011 15:53:29 +0300 Subject: [Live-devel] rtsp h264 extracting Message-ID: Greetings, I need to extract h264 frames from valid rtsp stream (that is initialized with url path). How can I do this? I've managed to extract some video data from rtsp stream but don't know what to do with it next. Thanks, Gennadii -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jun 4 04:48:26 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 4 Jun 2011 04:48:26 -0700 Subject: [Live-devel] Live streaming stops after half an hour In-Reply-To: <3EC6EEDBCBD4AC4A9FBE5F1F5EEA861904497F@SRVBRIEXC012.brisa.pt> References: <3EC6EEDBCBD4AC4A9FBE5F1F5EEA861904497F@SRVBRIEXC012.brisa.pt> Message-ID: >Have you tried the latest version of the live555 library? >Because I had a similar problem and it has been solved Yes, everyone *please* make sure that you're using the latest version of the library before you report problems. You'll save lots of people (but mostly yourself) lots of time by doing this. Remember that we don't support old versions of the library. Also, when testing a possible problem with RTSP/RTP streaming, it's better to first use "openRTSP" as a client, rather than "VLC". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jshanab at smartwire.com Sat Jun 4 16:33:48 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Sat, 4 Jun 2011 23:33:48 +0000 Subject: [Live-devel] Boolean.hh and mshtml.h : 'False' : redefinition; previous definition was 'enumerator' error Message-ID: <615FD77639372542BF647F5EBAA2DBC20B116D33@IL-BOL-EXCH01.smartwire.com> I have a browser plugin project that uses live555 and did some re-arranging and have managed to break my build, but I can't see my way out of it. I am building in Visual studio 2010 pro and have been for 6 months. The conflict is because the project uses mshtml.h inside of the activex part of the framework. It defines an enumeration with an element that is "False" Boolean.hh also tries to define a non-enumeration that is named "False" Here is the error: (I get one on redefinition of 'True' also) rtsp\usageenvironment\include\boolean.hh(26): error C2365: 'False' : redefinition; previous definition was 'enumerator' I do not know how I had it building for the last 6 months. How can I get these to be in different scopes, there are no namespaces in the MS or the live555 headers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Priya_Raghavendra at mindtree.com Sun Jun 5 21:49:34 2011 From: Priya_Raghavendra at mindtree.com (Priya Raghavendra) Date: Mon, 6 Jun 2011 04:49:34 +0000 Subject: [Live-devel] warning: backward_pts != current_pts Message-ID: Hi, We are using live555 for RTSP streaming. When we see the stream on VLC player there are breaks at regular intervals. So when I see the messages, I get the following messages. main warning: backward_pts != current_pts (-156964) main warning: backward_pts != current_pts (-161570) main warning: backward_pts != current_pts (-154928) main warning: backward_pts != current_pts (-163876) main warning: backward_pts != current_pts (-157760) main warning: backward_pts != current_pts (-161366) main warning: backward_pts != current_pts (238609133685) main warning: backward_pts != current_pts (-238609452664) main warning: backward_pts != current_pts (-148244) main warning: backward_pts != current_pts (-174015) main warning: backward_pts != current_pts (-149298) What does this warning mean? When the value is really huge the stream freezes and then it recovers again. Regards, Priya ________________________________ http://www.mindtree.com/email/disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.fischer at ids-imaging.de Mon Jun 6 00:01:38 2011 From: d.fischer at ids-imaging.de (Fischer Daniel) Date: Mon, 6 Jun 2011 09:01:38 +0200 Subject: [Live-devel] How to bypass streamlimit causes by EventTriggerIDs In-Reply-To: References: <4CB3F3483954BD4ABD0B4DBB35C7E33801D663AC@exchsrv.idszentral.local> Message-ID: <4CB3F3483954BD4ABD0B4DBB35C7E33801E2B331@exchsrv.idszentral.local> No problem. Thanks for your answer. It was not the problem to reimplement ?createEventTrigger?, ?deleteEventTrigger?, ?triggerEvent? and ?SingleStep?. I did this first. But this didn?t solve my problem. Windows make the trouble :-) Windows has a limitation of numbers of sockets that can be open by one process. This is 64 ( 2 per stream = 32 stream clients ). So I can create millions of EventTriggerID?s, it didn?t effect anything? To solve this I only define FD_SETSIZE to a higher value. Viele Gr??e / Best regards - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dipl.-Inf. (FH) Daniel Fischer iGuard - Development IDS Imaging Development Systems GmbH Dimbacher Strasse 6-8 ? D-74182 Obersulm Handelsregister: Stuttgart HRB 106225 Gesch?ftsf?hrer: J?rgen Hartmann, Armin Vogt, Torsten Wiesinger T : +49 (0)7134 / 961 96-0 F : +49 (0)7134 / 961 96-99 E : d.fischer at ids-imaging.de Web: www.ids-imaging.com - www.iguard.de - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - P Please consider the environment before printing this e-mail ________________________________ Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Ross Finlayson Gesendet: Donnerstag, 2. Juni 2011 04:06 An: LIVE555 Streaming Media - development & use Betreff: Re: [Live-devel] How to bypass streamlimit causes by EventTriggerIDs I am using live555 to stream several network cameras. For that I generate one RTSP-Server and for every camera a subsession on this server with a new URL. To signal the TaskScheduler, that there is a new frame for a stream, I use a EventTriggerID. Every stream has his own EventTriggerID. Now I got the problem, that the EventTriggerID is generated by a bitmask (0x80000000), and the line "m_EventTriggerId = envir().taskScheduler().createEventTrigger(deliverFrame0);" generates only 32 EventTriggerID?s, so that I have a maximum of 32 stream receivers. Now my question: Is it possible to solve that problem without generating more RTSP-Server with different TaskScheduler on different ports? Sorry for the long delay in responding to this. (I've been traveling for the past two months, and am way behind on email.) Note that the implementation of 'event triggers' that we provide (for the "BasicTaskScheduler" class) is just one possible implementation. You can - if you wish - provide your own implementation, by 1/ Defining a subclass of "BasicTaskScheduler", and 2/ Reimplementing the virtual functions virtual EventTriggerId createEventTrigger(TaskFunc* eventHandlerProc); virtual void deleteEventTrigger(EventTriggerId eventTriggerId); virtual void triggerEvent(EventTriggerId eventTriggerId, void* clientData = NULL); Note that "EventTriggerId" must remain a "u_int32_t", so you won't be able to change that. So you won't be able to continue to use it as a 'bit mask', if you want to support more than 32 triggers. But you can implement event triggers any way you choose. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jshanab at smartwire.com Mon Jun 6 06:03:05 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Mon, 6 Jun 2011 13:03:05 +0000 Subject: [Live-devel] Boolean.hh and mshtml.h : 'False' : redefinition; previous definition was 'enumerator' error In-Reply-To: <615FD77639372542BF647F5EBAA2DBC20B116D33@IL-BOL-EXCH01.smartwire.com> References: <615FD77639372542BF647F5EBAA2DBC20B116D33@IL-BOL-EXCH01.smartwire.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC20B116FDD@IL-BOL-EXCH01.smartwire.com> I will answer my own question. There is really no good way around this. What Ended up doing was modifying Boolean.hh From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Jeff Shanab Sent: Saturday, June 04, 2011 6:34 PM To: live-devel at lists.live555.com Subject: [Live-devel] Boolean.hh and mshtml.h : 'False' : redefinition; previous definition was 'enumerator' error I have a browser plugin project that uses live555 and did some re-arranging and have managed to break my build, but I can't see my way out of it. I am building in Visual studio 2010 pro and have been for 6 months. The conflict is because the project uses mshtml.h inside of the activex part of the framework. It defines an enumeration with an element that is "False" Boolean.hh also tries to define a non-enumeration that is named "False" Here is the error: (I get one on redefinition of 'True' also) rtsp\usageenvironment\include\boolean.hh(26): error C2365: 'False' : redefinition; previous definition was 'enumerator' I do not know how I had it building for the last 6 months. How can I get these to be in different scopes, there are no namespaces in the MS or the live555 headers. #ifndef _BOOLEAN_HH #define _BOOLEAN_HH #ifdef __BORLANDC__ #define Boolean bool #define False false #define True true #else typedef unsigned Boolean; #ifndef __MSHTML_LIBRARY_DEFINED__ #ifndef False const Boolean False = 0; #endif #ifndef True const Boolean True = 1; #endif #endif #endif #endif And then early in my project ... //include this to force the order and help modified Boolean.hh to work. #include -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steve.Wallace at verint.com Mon Jun 6 05:47:04 2011 From: Steve.Wallace at verint.com (Wallace, Steve) Date: Mon, 6 Jun 2011 08:47:04 -0400 Subject: [Live-devel] Live555 and G.711 WAV Files Message-ID: Hi, I'm running into an issue with streaming G.711 WAV files using a combination of: Live555MediaServer [LIVE555 Media Server version 0.66 (LIVE555 Streaming Media library version 2011.03.14)] Windows Media Player 11.0 G.711 WAV file All running on Windows XP Pro The same combination of versions works well when streaming MP3 files. Before I dive into the source code, can you tell me if Live555MediaServer supports streaming of G.711 WAV files? If so, do you have any insight on where the issue might be? If it helps, I'm encountering the same problem with: Live555MediaServer [LIVE555 Media Server version 0.66 (LIVE555 Streaming Media library version 2011.03.14)] MPlayer 4.2.5 G.711 WAV file All running on Windows XP Pro MPlayer reports "File not found or Invalid Format". Thanks! Steve This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 6 19:30:05 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 6 Jun 2011 19:30:05 -0700 Subject: [Live-devel] Live555 and G.711 WAV Files In-Reply-To: References: Message-ID: >I'm running into an issue with streaming G.711 WAV files using a >combination of: > >Live555MediaServer [LIVE555 Media Server version 0.66 (LIVE555 >Streaming Media library version 2011.03.14)] >Windows Media Player 11.0 >G.711 WAV file >All running on Windows XP Pro > >The same combination of versions works well when streaming MP3 >files. Before I dive into the source code, can you tell me if >Live555MediaServer supports streaming of G.711 WAV files? Yes it does. > If so, do you have any insight on where the issue might be? You can't (in general) expect Windows Media Player to play a standards-compliant media stream. It is horribly non-standards-compliant. > If it helps, I'm encountering the same problem with: > >Live555MediaServer [LIVE555 Media Server version 0.66 (LIVE555 >Streaming Media library version 2011.03.14)] >MPlayer 4.2.5 >G.711 WAV file >All running on Windows XP Pro > >MPlayer reports "File not found or Invalid Format". Are you sure that your ".wav" file exists in the same directory as the server application? If you're still having problems, then please point us at an example of a file that doesn't work, so we can download and test it for ourself. http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 6 20:17:11 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 6 Jun 2011 20:17:11 -0700 Subject: [Live-devel] locally viewing the stream generated by testMPEG1or2AudioVideoStreamer in unicast mode In-Reply-To: <7F32C6A46402CD49BA87BC5874370F1A2A0C90C098@NDA-HCLT-EVS05.HCLT.CORP.HCL.I N> References: <7F32C6A46402CD49BA87BC5874370F1A2A0C90C098@NDA-HCLT-EVS05.HCLT.CORP.HCL.I N> Message-ID: >I have been successfully able to run testMPEG1or2AudioVideoStreamer >in unicast mode, by making suggested changes as per the FAQ. >Thanks a lot for those suggestions. >But I am not able to play the streaming locally on my localhost (I >have tried giving the destinationAddressStr as "127.0.0.1" or the >local ip address as output from the ipconfig command). >I am using VLC Player to view the streaming video. >If you could please provide me some pointers/suggestions for the >reason of this failure. I don't know. It may be VLC that's having trouble playing the stream (e.g., because it doesn't know the port number). In any case, I don't recommend doing unicast streaming by modifying the "test*Streamer" applications. Instead, use the "testOnDemandRTSPServer" or "live555MediaServer" applications, and use the RTSP protocol to set up the unicast stream. That's what it's for. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arn at bestmx.ru Wed Jun 1 01:29:13 2011 From: arn at bestmx.ru (Anton Yabchinskiy) Date: 01 Jun 2011 10:29:13 +0200 Subject: [Live-devel] Problem with more than 20 sessions active on win32 Message-ID: Hello. I'm unable to start more than approx. 20 RTP sessions on the task scheduler. The problem seems to be Windows specific, as I was able to start even couple of hundreds of streams per task scheduler on Linux. Is it some kind of known limitation? >From inside the program it looks like there is no response to RTSP DESCRIBE request (in this case it is the first request from the client). In the dump of network packets from sniffer it could be seen that: server side actually responds to it with 200 OK and complete session description; client side sends TCP ACK; client side sends TCP RST ACK. Any suggestions? From satram at juniper.net Mon Jun 6 23:16:05 2011 From: satram at juniper.net (satheesh Ramalingam) Date: Tue, 7 Jun 2011 11:46:05 +0530 Subject: [Live-devel] how to detect frame loss In-Reply-To: References: Message-ID: Hi, I remember we had similar discussion earlier regarding packet loss. Search the archive for subject "[Live-devel] Buffering incoming data with openRTSP?" The first byte in the payload has the payload type (I or P or Non-ref P or....). In case of packet loss, keep dropping packets till you get next I frame. This logic has to be added as part of your application on top of live555 rtsp receiver. -- Satheesh R +91 99405 37776 From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Digital Qtum Sent: Thursday, May 19, 2011 10:10 AM To: live-devel at ns.live555.com Subject: [Live-devel] how to detect frame loss Hello, I'm doing this almost 2 weeks it is somewhat difficult to me.. My embedded board receive h.264 baseline stream from IP camera. During the system overhead or temporary network disconnection, P frame (or I frame) is lost, and then screen display breaks until next I frame received. So, I wanna detect (P) frame loss and skip P frames to next I frame. Can this be done by live555? Or need some application side process? To summarise 1. How can I detect P frame loss? 2. If above is possible, where should it be done to skip P frames? (Live555 or application) Any advice will be welcomed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.fischer at ids-imaging.de Mon Jun 6 23:58:13 2011 From: d.fischer at ids-imaging.de (Fischer Daniel) Date: Tue, 7 Jun 2011 08:58:13 +0200 Subject: [Live-devel] Problem with more than 20 sessions active on win32 In-Reply-To: References: Message-ID: <4CB3F3483954BD4ABD0B4DBB35C7E33801E53400@exchsrv.idszentral.local> Looks like a similar problem to this: http://lists.live555.com/pipermail/live-devel/2011-June/013374.html Note that you have to define FD_SETSIZE in the main application and not in in a part like an DLL or something else. Best you do this as a pre-processor statement in your development environment. Viele Gr??e / Best regards - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Dipl.-Inf. (FH) Daniel Fischer iGuard - Development IDS Imaging Development Systems GmbH Dimbacher Strasse 6-8 ? D-74182 Obersulm Handelsregister: Stuttgart HRB 106225 Gesch?ftsf?hrer: J?rgen Hartmann, Armin Vogt, Torsten Wiesinger T : +49 (0)7134 / 961 96-0 F : +49 (0)7134 / 961 96-99 E : d.fischer at ids-imaging.de Web: www.ids-imaging.com - www.iguard.de - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - P Please consider the environment before printing this e-mail -----Urspr?ngliche Nachricht----- Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Anton Yabchinskiy Gesendet: Mittwoch, 1. Juni 2011 10:29 An: live-devel at ns.live555.com Betreff: [Live-devel] Problem with more than 20 sessions active on win32 Hello. I'm unable to start more than approx. 20 RTP sessions on the task scheduler. The problem seems to be Windows specific, as I was able to start even couple of hundreds of streams per task scheduler on Linux. Is it some kind of known limitation? >From inside the program it looks like there is no response to RTSP DESCRIBE request (in this case it is the first request from the client). In the dump of network packets from sniffer it could be seen that: server side actually responds to it with 200 OK and complete session description; client side sends TCP ACK; client side sends TCP RST ACK. Any suggestions? _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From ee05154 at fe.up.pt Tue Jun 7 00:06:54 2011 From: ee05154 at fe.up.pt (Nuno Mota) Date: Tue, 7 Jun 2011 08:06:54 +0100 Subject: [Live-devel] Live555 scalability issue. Message-ID: Hi, a couple of days ago i conducted some scalability tests with the live555 media server. The computer in test was a quad core that handle the job pretty well and of course a Gigabit port was used. For the last test I used several openRTSP clients. The video source I used was a transport steam file. The normal client downloads an average of 10Mbit/s (1,3Mbytes/s). For the test I created 68 clients all connecting to the same live555 server. The connection sequence was the following, 25 clients, 24 clients, 12 clients and 8. For the first 49 clients the connection was stable and normal, having a total throughput of more than 500Mbit/s. However when connecting the next 12 and 8, the bandwidth was reduced more than 20% for every client i think. Because testing for one the average speed was less than 8Mbit/s with a total Throughput from the server of around 500Mbit/s. Later when the first 25 clients disconnected and the rest remained, the connection went up reaching almost 750Mbit for 5 minutes and just for 44 clients, meaning they were compensating I guess for the stream delay. In the end all the remaining clients had a video file almost identical to the original one (missing a few seconds maybe). Why did this happen? Why couldn't the bandwidth keep up for all the users? I'm guessing ofcourse this is due to the RTCP protocol. But i can't understand why this is happening. Regards, Nuno Mota -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 7 01:41:05 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 Jun 2011 01:41:05 -0700 Subject: [Live-devel] Live555 scalability issue. In-Reply-To: References: Message-ID: >a couple of days ago i conducted some scalability tests with the >live555 media server. The computer in test was a quad core that >handle the job pretty well and of course a Gigabit port was used. >For the last test I used several openRTSP clients. The video source >I used was a transport steam file. The normal client downloads an >average of 10Mbit/s (1,3Mbytes/s). For the test I created 68 clients >all connecting to the same live555 server. The connection sequence >was the following, 25 clients, 24 clients, 12 clients and 8. For the >first 49 clients the connection was stable and normal, having a >total throughput of more than 500Mbit/s. However when connecting the >next 12 and 8, the bandwidth was reduced more than 20% for every >client i think. Because testing for one the average speed was less >than 8Mbit/s with a total Throughput from the server of around >500Mbit/s. > >Later when the first 25 clients disconnected and the rest remained, >the connection went up reaching almost 750Mbit for 5 minutes and >just for 44 clients, meaning they were compensating I guess for the >stream delay. In the end all the remaining clients had a video file >almost identical to the original one (missing a few seconds maybe). >Why did this happen? I don't know. You'll have to explicitly measure exactly where in your system the bottleneck(s) are occurring, and exactly what is getting overloaded. Note that there's a lot more in 'your system' than just our software. In particular, you have operating systems, CPUs, networks, routers, etc. Any of which could be limiting scalability. Note in particular that scalability problems with this (and other) software is often caused by operating-system-imposed limits on the number of open sockets. Such a limit can usually be increased by reconfiguring your OS, so that's one of many things that you might try. >I'm guessing ofcourse this is due to the RTCP protocol. No, that's highly unlikely. The overhead of RTCP is negligible. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jun 7 01:38:42 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 Jun 2011 01:38:42 -0700 Subject: [Live-devel] live555 broken link: tips to build "live555 Streaming Media" code under Visual Studio 2005 are no more available In-Reply-To: References: Message-ID: >"Eric Flickner hints" reported >in http://www.live555.com/liveMedia/#config-windows section >are no more available. OK, I've removed that link now. >This broken link >is: http://letsgoustc.spaces.live.com/blog/cns!89AD27DFB5E249BA!167.entry > >Can anyone give me these tips? > >And then, it would be interesting to publish these tips in live555 >site, not as an external non permanent link. No, because that was never 'official' advice. (The proper way to build the code for Windows - and every other OS - is to use Makefiles.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 7 02:24:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 Jun 2011 02:24:20 -0700 Subject: [Live-devel] mem leak when BasicTaskScheduler destructed In-Reply-To: References: Message-ID: Thanks for the report. This bug will be fixed in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jun 7 02:24:45 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 Jun 2011 02:24:45 -0700 Subject: [Live-devel] Small memory leak In-Reply-To: <92D05FD48DA1CD41AD57254CB23732D70379B5C670@WS-BCO-MBX2.milky-way.battelle .org> References: <92D05FD48DA1CD41AD57254CB23732D70379B5C670@WS-BCO-MBX2.milky-way.battelle .org> Message-ID: >Not sure if this has been confirmed by the live555 developers yet, >but I believe there is a small memory leak that occurs during >destruction of DelayQueue, if there are any entries left on the >queue when DelayQueue is destroyed. Thanks for the report. This bug will be fixed in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From stephane.pigeon at visualdefence.com Tue Jun 7 06:48:48 2011 From: stephane.pigeon at visualdefence.com (Stephane Pigeon) Date: Tue, 7 Jun 2011 13:48:48 +0000 Subject: [Live-devel] Axis multicast crash Message-ID: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local> Hello, Our company has been using the Live555 streaming library in a custom DirectShow source filter for well over a year. We handle cameras from many vendors, in multicast and unicast, without issues. However, we noticed a problem with Axis cameras, configured for streaming H264 in multicast: - When multiple connections are attempted simultaneously on different Axis devices (via multiple instances of the source filter), sometimes the client application will close unexpectedly. It's a silent shutdown; no exceptions are caught by the source filter/Live555 lib; no errors are logged. Further observations: - More simultaneous connections = higher incidence of crash - It happens sometimes in unicast, but very rarely. - It happens regardless of the other filters in the DirectShow graph (CoreAVC, ffdshow, DivX, VMR7, VMR9, EVR, etc). Admittedly, the crash could happen in our own source filter code and be unrelated to Live555... but our source filter code is unaware of specific camera vendors... Also, we are using the Live555 streaming library from 2009, but it contains the typical fixes for Axis (ex. getting the ports/addresses from RTSP SETUP, not from RTSP DESCRIBE). This is really puzzling... I really hope someone can help us on this. Best regards, Stephane Pigeon Senior Software Developer Visual Defence Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ee05154 at fe.up.pt Tue Jun 7 10:25:59 2011 From: ee05154 at fe.up.pt (Nuno Mota) Date: Tue, 7 Jun 2011 18:25:59 +0100 Subject: [Live-devel] Live555 scalability issue. In-Reply-To: References: Message-ID: Thanks for the input I'll try to look into those issues. Regards, Nuno 2011/6/7 Ross Finlayson > a couple of days ago i conducted some scalability tests with the live555 >> media server. The computer in test was a quad core that handle the job >> pretty well and of course a Gigabit port was used. For the last test I used >> several openRTSP clients. The video source I used was a transport steam >> file. The normal client downloads an average of 10Mbit/s (1,3Mbytes/s). For >> the test I created 68 clients all connecting to the same live555 server. The >> connection sequence was the following, 25 clients, 24 clients, 12 clients >> and 8. For the first 49 clients the connection was stable and normal, having >> a total throughput of more than 500Mbit/s. However when connecting the next >> 12 and 8, the bandwidth was reduced more than 20% for every client i think. >> Because testing for one the average speed was less than 8Mbit/s with a >> total Throughput from the server of around 500Mbit/s. >> >> Later when the first 25 clients disconnected and the rest remained, the >> connection went up reaching almost 750Mbit for 5 minutes and just for 44 >> clients, meaning they were compensating I guess for the stream delay. In the >> end all the remaining clients had a video file almost identical to the >> original one (missing a few seconds maybe). Why did this happen? >> > > I don't know. You'll have to explicitly measure exactly where in your > system the bottleneck(s) are occurring, and exactly what is getting > overloaded. > > Note that there's a lot more in 'your system' than just our software. In > particular, you have operating systems, CPUs, networks, routers, etc. Any > of which could be limiting scalability. > > Note in particular that scalability problems with this (and other) software > is often caused by operating-system-imposed limits on the number of open > sockets. Such a limit can usually be increased by reconfiguring your OS, so > that's one of many things that you might try. > > > > I'm guessing ofcourse this is due to the RTCP protocol. >> > > No, that's highly unlikely. The overhead of RTCP is negligible. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 7 15:48:17 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 Jun 2011 15:48:17 -0700 Subject: [Live-devel] Axis multicast crash In-Reply-To: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local> References: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local> Message-ID: >Also, we are using the Live555 streaming library from 2009 Sorry, but we can't support old versions of the code (especially as old as 2009). There have been *vast* changes (improvements) to the RTSP client code since then. >, but it contains the typical fixes for Axis (ex. getting the >ports/addresses from RTSP SETUP, not from RTSP DESCRIBE). I don't know what these "typical fixes for Axis" are, because I don't think anyone on this mailing list has ever mentioned them before, nor have I seen reports (at least, not recently) of any problems with non-standard use of RTSP by Axis cameras (that require any modification to our code). (If you are seeing such problems - even when using the latest version of our code - then perhaps they could be fixed by doing a firmware upgrade on your Axis cameras??) In any case, you'll need to be using the latest version of our code, otherwise we won't be able to help you. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From komal.dhote at gmail.com Tue Jun 7 09:27:53 2011 From: komal.dhote at gmail.com (Komal Dhote) Date: Tue, 7 Jun 2011 21:57:53 +0530 Subject: [Live-devel] Axis multicast crash In-Reply-To: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local> References: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local> Message-ID: AXIS camera doesn't give NALU 7 and NALU 8. So RTSP has no issues with the streaming only the parsing and decoding at the receiving end have issues. Try to see what is the NALU unit type you are receiving from the url. Thanks and Regards, Komal On Tue, Jun 7, 2011 at 7:18 PM, Stephane Pigeon < stephane.pigeon at visualdefence.com> wrote: > Hello, > > > > Our company has been using the Live555 streaming library in a custom > DirectShow source filter for well over a year. We handle cameras from many > vendors, in multicast and unicast, without issues. However, we noticed a > problem with Axis cameras, configured for streaming H264 in multicast: > > > > - When multiple connections are attempted simultaneously on different Axis > devices (via multiple instances of the source filter), sometimes the client > application will close unexpectedly. It's a silent shutdown; no exceptions > are caught by the source filter/Live555 lib; no errors are logged. > > > > Further observations: > > > > - More simultaneous connections = higher incidence of crash > > - It happens sometimes in unicast, but very rarely. > > - It happens regardless of the other filters in the DirectShow graph > (CoreAVC, ffdshow, DivX, VMR7, VMR9, EVR, etc). > > > > > > Admittedly, the crash could happen in our own source filter code and be > unrelated to Live555... but our source filter code is unaware of specific > camera vendors... > > Also, we are using the Live555 streaming library from 2009, but it > contains the typical fixes for Axis (ex. getting the ports/addresses from > RTSP SETUP, not from RTSP DESCRIBE). > > > > > > This is really puzzling... I really hope someone can help us on this. > > > > Best regards, > > Stephane Pigeon > > Senior Software Developer > > Visual Defence Inc. > > > > _______________________________________________ > 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 warren at etr-usa.com Tue Jun 7 16:29:18 2011 From: warren at etr-usa.com (Warren Young) Date: Tue, 07 Jun 2011 17:29:18 -0600 Subject: [Live-devel] Axis multicast crash In-Reply-To: References: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local> Message-ID: <4DEEB44E.9080702@etr-usa.com> On 6/7/2011 4:48 PM, Ross Finlayson wrote: > > I don't know what these "typical fixes for Axis" are, because I don't > think anyone on this mailing list has ever mentioned them before, I'm not sure if it's what the OP meant, but Axis has a very strange idea of what "multicast" means. Instead of just sending packets out blindly for anyone to receive who wants, letting the switching fabric take care of pruning off network segments where no one wants to listen, Axis makes the first client send an RTSP request to start the stream. Then, instead of some interleaved A/V format, you get audio and video elementaries on different ports. I guess this allows a client to negotiate certain parameters of the stream, but how is that helpful in a multicast scenario, where presumably you have later clients who will just come along and "listen in" on the stream? If they're expected to know /a priori/ what format the A/V stream is in, why allow the first client to negotiate anything? Too much br?nnvin consumption going on there, I think. (http://en.wikipedia.org/wiki/Alcoholic_beverages_in_Sweden) (http://www.axis.com/corporate/contact.htm) From finlayson at live555.com Tue Jun 7 16:56:33 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 Jun 2011 16:56:33 -0700 Subject: [Live-devel] Axis multicast crash In-Reply-To: <4DEEB44E.9080702@etr-usa.com> References: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local> <4DEEB44E.9080702@etr-usa.com> Message-ID: >>I don't know what these "typical fixes for Axis" are, because I don't >>think anyone on this mailing list has ever mentioned them before, > >I'm not sure if it's what the OP meant, but Axis has a very strange >idea of what "multicast" means. > >Instead of just sending packets out blindly for anyone to receive >who wants, letting the switching fabric take care of pruning off >network segments where no one wants to listen, Axis makes the first >client send an RTSP request to start the stream. Then, instead of >some interleaved A/V format, you get audio and video elementaries on >different ports. Audio and video being streamed to different ports is how almost all audio+video RTP streams work - unicast or multicast. (The only significant exception is when streaming a MPEG Transport Stream; in that case the audio+video remains multiplexed inside the Transport Stream.) For multicast streams, the different port numbers (for audio and video) are (necessarily) the same for all clients, so (for multicast streams) these port numbers (and the IP multicast address) are *usually* specified inside the stream's SDP description, which the client gets in response to the RTSP "DESCRIBE" command. For unicast streams, however, the port numbers can differ for differing clients (and there will also be server port numbers - needed for RTCP). In this case, all these port numbers are set up in the response to the RTSP "SETUP" command. (This, by the way, is one reason why it's difficult to get unicast streaming to work without using RTSP - and it's why we don't recommend trying to do unicast streaming without using RTSP.) Now, I suppose it's possible that some servers (e.g., some Axis or other cameras) are using the RTSP "SETUP" command to set up the port numbers even for multicast streams. I have seen some servers that specify the IP multicast address in the "SETUP" response, rather than in the SDP description (i.e., "DESCRIBE" response). But I hadn't heard of any servers doing this for multicast port numbers also. But if anyone has such a server, then please post an example "rtsp://" URL online, so we can check to see whether or not our RTSP client software works with it. (If our software doesn't work - and the server's use of RTSP is otherwise standards-compliant - then I'm willing to consider updating (the latest version of) our client software to work with this server. But again, I'd need an actual example stream to work with.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jun 7 17:12:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 7 Jun 2011 17:12:20 -0700 Subject: [Live-devel] config.macosx change In-Reply-To: References: Message-ID: > I could not get the macos version to compile with > >LIBRARY_LINK = ar cr > >so I used > >LIBRARY_LINK = libtool -s -o > >which seems to work fine. That's interesting. On my Mac OS X system, I have both "ar" and "libtool". So I don't know why you don't have "ar". Could other Mac OS X developers please check this? Does anyone else have "libtool" , but not "ar"? And does anyone have "ar", but not "libtool"? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From thomas.maier at uni-kassel.de Tue Jun 7 22:55:24 2011 From: thomas.maier at uni-kassel.de (Thomas Maier) Date: Wed, 8 Jun 2011 07:55:24 +0200 Subject: [Live-devel] config.macosx change In-Reply-To: References: Message-ID: <58CBC899-E76C-4C14-B865-B8E08EB44001@uni-kassel.de> Am 08.06.2011 um 02:12 schrieb Ross Finlayson: >> I could not get the macos version to compile with >> >> LIBRARY_LINK = ar cr >> >> so I used >> >> LIBRARY_LINK = libtool -s -o >> >> which seems to work fine. > > That's interesting. On my Mac OS X system, I have both "ar" and "libtool". So I don't know why you don't have "ar". > > Could other Mac OS X developers please check this? Does anyone else have "libtool" , but not "ar"? And does anyone have "ar", but not "libtool"? I have both ar and libtool but I remember I also had problems compiling because make aborted. A simple ranlib on the libs followed by another call to make did the job. Never tried the libtool way but I'll give it a shot once I get to it. I am on 10.6.7, XCode 3.2.6. I think I also had the change the Boolean typedef on OS X because there was some historical definition (or so I read) to unsigned char instead of unsigned. That was only necessary to use Live555 in my own programs, not to compile Live555 by itself. Just a heads-up to the OP and maybe it is no longer necessary for newer versions of Live555. Cheers, Thomas. From thomas.maier at uni-kassel.de Tue Jun 7 23:03:22 2011 From: thomas.maier at uni-kassel.de (Thomas Maier) Date: Wed, 8 Jun 2011 08:03:22 +0200 Subject: [Live-devel] config.macosx change In-Reply-To: <58CBC899-E76C-4C14-B865-B8E08EB44001@uni-kassel.de> References: <58CBC899-E76C-4C14-B865-B8E08EB44001@uni-kassel.de> Message-ID: Am 08.06.2011 um 07:55 schrieb Thomas Maier: > Am 08.06.2011 um 02:12 schrieb Ross Finlayson: >>> I could not get the macos version to compile with >>> >>> LIBRARY_LINK = ar cr >>> >>> so I used >>> >>> LIBRARY_LINK = libtool -s -o >>> >>> which seems to work fine. >> >> That's interesting. On my Mac OS X system, I have both "ar" and "libtool". So I don't know why you don't have "ar". >> >> Could other Mac OS X developers please check this? Does anyone else have "libtool" , but not "ar"? And does anyone have "ar", but not "libtool"? > > I have both ar and libtool but I remember I also had problems compiling because make aborted. A simple ranlib on the libs followed by another call to make did the job. Never tried the libtool way but I'll give it a shot once I get to it. To be more explicit, maybe the reason he "could not get the macos version to compile" is not that he doesn't have ar like you deduced but that ar doesn't work as expected on OS X. That sure was the case for me. -- Thomas From finlayson at live555.com Wed Jun 8 00:14:33 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Jun 2011 00:14:33 -0700 Subject: [Live-devel] issue with streaming ulaw from memory buffer In-Reply-To: References: Message-ID: >I'm writing some code to stream live audio in ulaw format over RTP >multicast. I derived a class from framedSource class to read in the >data from a memory buffer. An audio recorder thread feeds ulaw audio >data to this buffer. In the derived class, I specified frame size @ >128 bytes, duration @ 16000 us and the presentation time, etc in the >"doGetNextFrame" function. The network sink is an instance of >"SimpleRTPSink". It seems to be straightforward. However, the audio >was very broken when played back from VLC. Later I found that the >output RTP packet has 1024 bytes payload and arriving interval for >each RTP packet is 128 ms. I intended to have a 16-ms arriving >interval and 128-byte RTP payload (which is the audio recorder's >output frame size). Does this make any sense and how should I do that? Yes, the solution is to specify that your "SimpleRTPSink" object should pack no more than one input frame at a time into each outgoing RTP packet. You can do this by setting the "allowMultipleFramesPerPacket" parameter in the "createNew::createNew()" call to False. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From norris.j at gmail.com Tue Jun 7 01:47:17 2011 From: norris.j at gmail.com (James Norris) Date: Tue, 7 Jun 2011 09:47:17 +0100 Subject: [Live-devel] H264VideoStreamDiscreteFramer vs H264VideoStreamFramer vs other Message-ID: Hey all, I know some parts of this have been covered in (many) other posts, I've spent sometime reading through them so apologies if I've missed the crucial post but believe this is unique. I have a live camera source providing individual frames which I'm encoding in the x264 library, I've setup an RTSP server using a custom "OnDemandServerMediaSubsession", and a custom FramedSource (using DeviceSource as a template). To give an idea of how it chains together I've provided "createNewStreamSource" and "createNewRTPSink" in the footer, but AFAIK they follow the guidance in the FAQ. I can watch this stream using either the Discrete or normal framer classes in VLC over the RTSP server when the x264 library provides annex-b supporting NAL units (with the 00000001 start code) AND I do not try to separate the NALs into individual calls to "doGetNextFrame()" - each frame is provided as a single concatenated block of data where several NALs could be within. However there are problems with using both the discrete and standard framers: - If I use the H264VideoStreamFramer class, the fMaxSize variable counts down till a frame is truncated, this truncation is visible in VLC as a broken frame. This problem is similar to http://lists.live555.com/pipermail/live-devel/2010-July/012357.html where it is advised to use a Discrete framer. - If I use the H264VideoStreamDiscreteFramer class, I get the warnings about a startcode being present, looking at the code this means that saveCopyOfSPS and saveCopyOfPPS are never called. It does play in VLC, I'm just concerned about the implications of never using these functions? If I remove the startcode (just provide the remaining data block), VLC won't display anything & in the messages it says "waiting for SPS/PPS", this is true whether or not I split the NALs into individual "doGetNextFrame()" calls, but in this case live555 seems happy and doesn't output any warnings. - I've seen hints at writing your own framer class, but it's unclear why & what I need to achieve in doing so? Thanks in advance & do appreciate all help, James -- FramedSource* FramedServerMediaSubsession::createNewStreamSource(unsigned clientSessionId, unsigned& estBitrate) { estBitrate = 500; // Create the video source: DeviceParameters p; RTPFrameLoader* frameSource = RTPFrameLoader::createNew( envir(), p ); // encoder outputs to RTPFrameLoader encoder = new H264Encoder ( frameSource, 640, 480, 3 ); Camera *cam = CameraFactory::getInstance()->getCamera( CameraFactory::FAKE ); // the encoder listens in for raw camera frames cam->registerFrameListener ( encoder ); encoder->go(); // Create a framer for the Video Elementary Stream: return H264VideoStreamDiscreteFramer::createNew ( envir(), frameSource ); } RTPSink* FramedServerMediaSubsession::createNewRTPSink ( Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource ) { return H264VideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 8 02:06:45 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Jun 2011 02:06:45 -0700 Subject: [Live-devel] H264VideoStreamDiscreteFramer vs H264VideoStreamFramer vs other In-Reply-To: References: Message-ID: I suggest that you use "H264VideoStreamDiscreteFramer", but modify your input source object so that it 1/ Delivers one NAL unit at a time (and no more), and 2/ Does *not* include the 00000001 start code at the beginning of each NAL unit. (This is important; "H264VideoStreamDiscreteFramer" will not work correctly if this start code is included.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From stephane.pigeon at visualdefence.com Wed Jun 8 06:20:42 2011 From: stephane.pigeon at visualdefence.com (Stephane Pigeon) Date: Wed, 8 Jun 2011 13:20:42 +0000 Subject: [Live-devel] Axis multicast crash In-Reply-To: References: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local>, Message-ID: <541B5E207848624088BDC9F07CCA99CE02F2637C@VDI-EXCHANGE.vdi.local> > I don't know what these "typical fixes for Axis" are, because I don't think anyone on this mailing list has ever mentioned them before, nor have I seen reports (at least, not recently) of any problems with non-standard use of RTSP by Axis cameras (that require any modification to our code). Thanks Ross, All our Axis cameras specify the multicast port numbers in the SETUP response, not in the DESCRIBE response. >>> SETUP rtsp://172.16.5.70:554/axis-media/media.amp/trackID=1?videocodec=h264 RTSP/1.0\\r\\n <<< RTP/AVP;multicast;destination=239.198.215.5;ttl=5;port=50380-50381;mode=\"PLAY\" Models we use: AXIS Q6032-E Network Camera AXIS Q7401 Video Encoder AXIS P5534 Network Camera AXIS Q1755 Network Camera But that is besides the point. Streaming works fine... under normal circumstances. In my original post, my point was that there is a crash when attempting simultaneous multicast connections. I understand that you cannot help because I use old 2009 code. I was just hoping some else had noticed similar behavior. Regards, Stephane Pigeon Senior Software Developer Visual Defence Inc ________________________________________ From: live-devel-bounces at ns.live555.com [live-devel-bounces at ns.live555.com] on behalf of Ross Finlayson [finlayson at live555.com] Sent: June 7, 2011 6:48 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Axis multicast crash >Also, we are using the Live555 streaming library from 2009 Sorry, but we can't support old versions of the code (especially as old as 2009). There have been *vast* changes (improvements) to the RTSP client code since then. >, but it contains the typical fixes for Axis (ex. getting the >ports/addresses from RTSP SETUP, not from RTSP DESCRIBE). I don't know what these "typical fixes for Axis" are, because I don't think anyone on this mailing list has ever mentioned them before, nor have I seen reports (at least, not recently) of any problems with non-standard use of RTSP by Axis cameras (that require any modification to our code). (If you are seeing such problems - even when using the latest version of our code - then perhaps they could be fixed by doing a firmware upgrade on your Axis cameras??) In any case, you'll need to be using the latest version of our code, otherwise we won't be able to help you. -- 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 From norris.j at gmail.com Wed Jun 8 04:02:27 2011 From: norris.j at gmail.com (James Norris) Date: Wed, 8 Jun 2011 12:02:27 +0100 Subject: [Live-devel] H264VideoStreamDiscreteFramer vs H264VideoStreamFramer vs other In-Reply-To: References: Message-ID: Thanks Ross, as I said though in that case VLC cannot decode the stream, it gives "waiting for SPS/PPS" messages then times out. In what sense will the framer not work correctly with the start code? In my tests it seems to be working well, apart from the warnings. James On Wed, Jun 8, 2011 at 10:06 AM, Ross Finlayson wrote: > I suggest that you use "H264VideoStreamDiscreteFramer", but modify your > input source object so that it > 1/ Delivers one NAL unit at a time (and no more), and > 2/ Does *not* include the 00000001 start code at the beginning of each NAL > unit. (This is important; "H264VideoStreamDiscreteFramer" will not work > correctly if this start code is included.) > -- > > 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 Bruno.Basilio at brisa.pt Wed Jun 8 07:15:34 2011 From: Bruno.Basilio at brisa.pt (Bruno Filipe Basilio) Date: Wed, 8 Jun 2011 14:15:34 +0000 Subject: [Live-devel] RTCP bug in multicast? In-Reply-To: References: Message-ID: <3EC6EEDBCBD4AC4A9FBE5F1F5EEA861904AEF6@SRVBRIEXC012.brisa.pt> Hi Mark, > I just read the rtcp.cpp and find a problem in multicast mode. > In RTCPInstance::incomingReportHandler1(), from line 342 There's a report of a similar problem which is affecting me also. You can see the symptoms here: http://lists.live555.com/pipermail/live-devel/2011-May/013313.html > To avoid this bug we must enable the code in > Groupsock::multicastSendOnly(), so the server will not received any > multicast packets that it just sent out. I'm not shore how to implement your suggestion and I would very appreciated if could you help me on this? Something like a patch would be great. Best regards, Bruno Basilio Brisa Inova??o e Tecnologia, S.A. > > ------------------------------ > > Message: 5 > Date: Mon, 25 Apr 2011 14:10:32 +0800 > From: Mark > To: live-devel > Subject: [Live-devel] RTCP bug in multicast? > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Ross, > I just read the rtcp.cpp and find a problem in multicast mode. > In RTCPInstance::incomingReportHandler1(), from line 342 : > > // Ignore the packet if it was looped-back from ourself: > if (RTCPgs()->wasLoopedBackFromUs(envir(), fromAddress)) { > // However, we still want to handle incoming RTCP packets from > // *other processes* on the same machine. To distinguish this > // case from a true loop-back, check whether we've just sent a > // packet of the same size. (This check isn't perfect, but it > seems > // to be the best we can do.) > if (fHaveJustSentPacket && fLastPacketSentSize == packetSize) { > // This is a true loop-back: > fHaveJustSentPacket = False; > break; // ignore this packet > } > } > > Here, the mechanism to prevent endless loop seems not perfect, > checking the variables fHaveJustSentPacket and fLastPacketSentSize is > not enough. > > Think about this situation: > 1. client1 sends out an RR(receive report) > 2. server receives the RR and run into > RTCPInstance::incomingReportHandler1() > 3. before server runs to line 364 of rtcp.cpp ( > fRTCPInterface.sendPacket(pkt, packetSize); ) , client2 sends out an > RR packet > 4. now server runs line 364-366; resending the client1's RR > packet to the multicast group, then modify fHaveJustSentPacket and > fLastPacketSentSize; > fRTCPInterface.sendPacket(pkt, packetSize); > fHaveJustSentPacket = True; > fLastPacketSentSize = packetSize; > 5. in the next SingleStep(), the RTCP will receive the client2's > RR packet and resending the packet( line 364-366 of rtcp.cpp) to the > multicast group > 6. in the next SingleStep(), the RR packet in step 4 is arrived and > server runs into RTCPInstance::incomingReportHandler1(), when it check > looped-back packet in line 342, > the variables fHaveJustSentPacket and fLastPacketSentSize are > modified in step 5, so the checking is incorrect and may cause endless > loop of multicast RTCP packet sending > > To avoid this bug we must enable the code in > Groupsock::multicastSendOnly(), so the server will not received any > multicast packets that it just sent out. > -------------------------------------------------------------------------------- Declara??o: A informa??o contida nesta mensagem, e os ficheiros anexos, ? privilegiada e confidencial, destinando-se exclusivamente ao(s) destinat?rio(s).Se n?o ? o destinat?rio (ou o respons?vel pela sua entrega ao destinat?rio) e recebeu a mesma por engano, fica notificado que ? estritamente proibido reproduzir, guardar ou distribuir toda ou qualquer parte desta mensagem e ficheiros anexos.Por favor reencaminhe a mensagem para o respons?vel pelo seu envio ou contacte-nos por telefone e elimine a mensagem e ficheiros anexos do seu computador,sem os reproduzir. Disclaimer: The information contained in this message, and any files attached, is privileged and confidential, and intended exclusively for the included addresses.If you are not the intended recipient (or the person responsible for delivering to the intended recipient) and received this message by mistake, be aware that copy, storage, distribution or any other use of all or part of this message and the files attached is strictly prohibited. Please notify the sender by reply e-mail or contact us by telephone and delete this message and the files attached, without retaining a copy. -------------------------------------------------------------------------------- From finlayson at live555.com Wed Jun 8 07:22:01 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Jun 2011 07:22:01 -0700 Subject: [Live-devel] H264VideoStreamDiscreteFramer vs H264VideoStreamFramer vs other In-Reply-To: References: Message-ID: >Thanks Ross, as I said though in that case VLC cannot decode the >stream, it gives "waiting for SPS/PPS" messages then times out. > >In what sense will the framer not work correctly with the start >code? In my tests it seems to be working well, apart from the >warnings. I don't know how much clearer I can make this: If you're using "H264VideoStreamDiscreteFramer", then the NAL units that you feed to it MUST NOT begin with the 00000001 start code. If you do this, you will end up with a non-standards-compliant RTP packet (which receiving clients might not understand), and also our server code will not recognize SPS and PPS NAL units - when they occur. We need to do this in order to be able to generate proper configuration information in the stream's SDP description. You've already noticed that VLC does not decode your stream if you include the start codes. So don't include them. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jun 8 07:23:42 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Jun 2011 07:23:42 -0700 Subject: [Live-devel] Axis multicast crash In-Reply-To: <541B5E207848624088BDC9F07CCA99CE02F2637C@VDI-EXCHANGE.vdi.local> References: <541B5E207848624088BDC9F07CCA99CE02D9417E@VDI-EXCHANGE.vdi.local>, <541B5E207848624088BDC9F07CCA99CE02F2637C@VDI-EXCHANGE.vdi.local> Message-ID: >All our Axis cameras specify the multicast port numbers in the SETUP >response, not in the DESCRIBE response. > >>>> SETUP >>>>rtsp://172.16.5.70:554/axis-media/media.amp/trackID=1?videocodec=h264 >>>>RTSP/1.0\\r\\n ><<< >RTP/AVP;multicast;destination=239.198.215.5;ttl=5;port=50380-50381;mode=\"PLAY\" I believe that our RTSP client code (the latest version) will handle this situation - and there's a good chance that it will also overcome the crashing problem that you see. So please upgrade. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From norris.j at gmail.com Wed Jun 8 08:24:33 2011 From: norris.j at gmail.com (James Norris) Date: Wed, 8 Jun 2011 16:24:33 +0100 Subject: [Live-devel] H264VideoStreamDiscreteFramer vs H264VideoStreamFramer vs other In-Reply-To: References: Message-ID: Ah so it effects the SDP description, I'll check what VLC thinks the stream is. You've got it the other way round, when I include the startcode it works & VLC displays (but I get warnings in live555), when it's missing (& NALs are broken into pieces) VLC will not playback but live555 is happy. In summary, VLC will not display the stream unless I include the startcode to the discrete framer. Surely I'm not the only one with these symptoms? I might try checking the RTP stream at a lower level, see what's going on with the startcodes, don't know what I'll do with that information but hopefully will shed some light on how a non-standards-compliant RTP packet can be shown in VLC. Thanks again, James On Wed, Jun 8, 2011 at 3:22 PM, Ross Finlayson wrote: > Thanks Ross, as I said though in that case VLC cannot decode the stream, >> it gives "waiting for SPS/PPS" messages then times out. >> In what sense will the framer not work correctly with the start code? In >> my tests it seems to be working well, apart from the warnings. >> > > I don't know how much clearer I can make this: > > If you're using "H264VideoStreamDiscreteFramer", then the NAL units that > you feed to it MUST NOT begin with the 00000001 start code. If you do this, > you will end up with a non-standards-compliant RTP packet (which receiving > clients might not understand), and also our server code will not recognize > SPS and PPS NAL units - when they occur. We need to do this in order to be > able to generate proper configuration information in the stream's SDP > description. > > You've already noticed that VLC does not decode your stream if you include > the start codes. So don't include them. > > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 8 16:01:23 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Jun 2011 16:01:23 -0700 Subject: [Live-devel] How to enter arguments on playCommon.cpp? In-Reply-To: References: Message-ID: >I'm working on my final project in Software Engineering Does your school not have its own domain name :-) >, which its purpose is to stream rtsp unicast broadcast from digital >intercom to another end station >that using the same intercom. >My renewal idea is not using the VLC player, but to create a simple >media player, based on C# programming OK, but our code is C++, not C# >, which will improve the reloading time of the stream >and etc. >Anyway, I'm having a trouble with the file playCommon.cpp. I'm >trying to broadcast from some test program of yours, called >testMPEG4VideoStreamer.cpp. When I run it, >I get the output message that says: > "Play this stream using the URL >'rtsp://192.168.2.103:8554/testStream' >" >"Beginning streaming..." >"Beginning to read from file..." > >So, my problem is when I'm compiling playCommon.cpp (while broadcast >testMPEG4VideoStreamer.cpp) I get the usage message from the >playCommon.cpp, which indicates >I neeed to enter a list of arguments, and I'm really confused which >arguments should I use, and which arguments I shall not use? I'm also confused, because "playCommon.cpp" is used to build only the "openRTSP" and "playSIP" applications; not "testMPEG4VideoStreamer". Instructions for how to configure and build this software are on http://www.live555.com/liveMedia/ -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ydgoo9 at gmail.com Wed Jun 1 19:32:55 2011 From: ydgoo9 at gmail.com (YD) Date: Thu, 2 Jun 2011 11:32:55 +0900 Subject: [Live-devel] Want to receive packet directly not file. Message-ID: Hi all, I am making a RTSP Client player with using the liveMedia library. My reference code is openRTSP, but it receives the RTP data in a File. I want to receive the RTP data(raw or Payload OK) directly and will put the decoder directly. I saw AuxilliaryReadHandler() for this, but I read somewhere this function is not good and it will be removed soon. Please tell me how to do it. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 8 20:12:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 8 Jun 2011 20:12:20 -0700 Subject: [Live-devel] live555 latency In-Reply-To: References: Message-ID: >I use live555 mediaserver and VLC player. > >When I play a 264 file (slamtv60.264), it gets about 10 sec latency. > >My VLC play have 1.2 sec latency. Does any other source cause the latency? I don't know why you're seeing 10 second latency; I don't see this when I try streaming/playing the same file. The only thing I can think of is that perhaps the latency is occurring inside your network somewhere - e.g., in a firewall and/or router somewhere between the server and client. I suggest that you first try streaming/playing the file on the same local network. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jshanab at smartwire.com Thu Jun 9 05:43:21 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Thu, 9 Jun 2011 12:43:21 +0000 Subject: [Live-devel] live555 latency In-Reply-To: References: Message-ID: <615FD77639372542BF647F5EBAA2DBC20B119C9C@IL-BOL-EXCH01.smartwire.com> By latency do you mean how long time before it starts to display or do you mean the video is 10 seconds behind. Being recorded, this is obviously hard to see unless you record a clock and see if the first 10 seconds are there and late or just plain dropped. VLC has a large buffer and if the file fails to give the info up front that it needs, then it starts trying to decode. If keyframes are every few seconds and it is forced to chew on a few frames until it can decode one, I could see it taking this long. Indeed, I Have seen it. I would grab a program called madedit if you are on windows or xedit and inspect the file looking for the nal units and see if you have the pattern [7][8][5][1][1][1] or if has [2] and [6]'s in there or no [7] and [8]. (In my file I search for the binary 00 00 01 and look at the next byte, the lower nibble is the nal unit type Perhaps vlc -vvv file.h264, which will give you a play-by-play, may give hints of something it is doing that the other code is not. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, June 08, 2011 10:12 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] live555 latency >I use live555 mediaserver and VLC player. > >When I play a 264 file (slamtv60.264), it gets about 10 sec latency. > >My VLC play have 1.2 sec latency. Does any other source cause the latency? I don't know why you're seeing 10 second latency; I don't see this when I try streaming/playing the same file. The only thing I can think of is that perhaps the latency is occurring inside your network somewhere - e.g., in a firewall and/or router somewhere between the server and client. I suggest that you first try streaming/playing the file on the same local network. -- 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 From Steve.Wallace at verint.com Thu Jun 9 12:53:53 2011 From: Steve.Wallace at verint.com (Wallace, Steve) Date: Thu, 9 Jun 2011 15:53:53 -0400 Subject: [Live-devel] "My File Doesn't Work" Message-ID: Any guidance on the following issue would be greatly appreciated. I've posted two WAV files to the following FTP location: ftp://live555:pltdekXHt at atlftp.verint.com user: Live555 pass: pltdekXHt Combinations: testOnDemandRTSPServer.exe + MPlayer + M1F1-mulaw-AFsp.wav (works) testOnDemandRTSPServer.exe + WMPlayer + M1F1-mulaw-AFsp.wav (streams, but no audio) testOnDemandRTSPServer.exe + MPlayer + test_not_working.wav (does not work) testOnDemandRTSPServer.exe + WMPlayer + test_not_working.wav (does not work) In both scenarios, I renamed the source file to "test.wav" and placed it in the same directory as "testOnDemandRTSPServer.exe". The version of "testOnDemandRTSPServer.exe" I'm testing with is unmodified. Additional version details: Live555MediaServer [LIVE555 Media Server version 0.66 (LIVE555 Streaming Media library version 2011.03.14)] Windows Media Player 9 and 11.0 (same results) Both WAV files are G.711 Windows XP Pro Thanks! Steve This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sokratis.barmpounakis at unige.ch Thu Jun 9 05:03:22 2011 From: sokratis.barmpounakis at unige.ch (Sokratis Barmpounakis) Date: Thu, 9 Jun 2011 14:03:22 +0200 Subject: [Live-devel] 264 raw byte buffer directly to streamer Message-ID: Hello, I want to modify the "testOnDemandRTSPServer" test program for streaming via unicast, so that I take the input from a byte buffer inside my C++ code, and not from a file. I have already the corresponding paragraph in FAQ. There is no input device (so I don't think I can use stdin etc). In particular, I am encoding some other buffer with x264lib and I get raw 264 data bytes. The testOnDemandRTSPServer works perfectly if the encoder writes these raw 264 data into a .264 file. (Tested it with VLC) However, I want the system to work live (not wait for the file to be closed, then open it and stream). More simply: In the same loop where each video frame is encoded, I want to send directly the encoded bytes to be streamed. I really need some ideas... Thank you very much in advance, Sokratis. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arn at bestmx.ru Thu Jun 9 11:06:51 2011 From: arn at bestmx.ru (arn at bestmx.ru) Date: Thu, 09 Jun 2011 22:06:51 +0400 Subject: [Live-devel] Problem with more than 20 sessions active on win32 In-Reply-To: <4CB3F3483954BD4ABD0B4DBB35C7E33801E53400@exchsrv.idszentral.local> References: <4CB3F3483954BD4ABD0B4DBB35C7E33801E53400@exchsrv.idszentral.local> Message-ID: <87lixazxok.wl%arn@bestmx.ru> At Tue, 7 Jun 2011 08:58:13 +0200, Fischer Daniel wrote: > > Looks like a similar problem to this: > > http://lists.live555.com/pipermail/live-devel/2011-June/013374.html > > Note that you have to define FD_SETSIZE in the main application and not in in a part like an DLL or something else. Best you do this as a pre-processor statement in your development environment. Thanks! From finlayson at live555.com Thu Jun 9 14:08:00 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Jun 2011 14:08:00 -0700 Subject: [Live-devel] "My File Doesn't Work" In-Reply-To: References: Message-ID: >Combinations: >testOnDemandRTSPServer.exe + MPlayer + M1F1-mulaw-AFsp.wav (works) >testOnDemandRTSPServer.exe + WMPlayer + M1F1-mulaw-AFsp.wav >(streams, but no audio) > >testOnDemandRTSPServer.exe + MPlayer + test_not_working.wav (does not work) >testOnDemandRTSPServer.exe + WMPlayer + test_not_working.wav (does not work) First, one can never expect Windows Media Player to be able to play a standards-compliant RTSP/RTP stream, so one should never use it for testing. The problem with the "test_not_working.wav" file is that it contains a non-standard WAV header. Specifically: %hexdump -C test_not_working.wav | head 00000000 52 49 46 46 6c 8b 06 00 57 41 56 45 73 69 67 6e |RIFFl...WAVEsign| 00000010 20 00 00 00 ea 27 77 c2 cc bf c3 84 1b 32 7f fc | ....'w......2..| 00000020 97 a1 42 c6 b1 91 bb b0 c4 ca f5 5f 38 50 81 9d |..B........_8P..| 00000030 3f 23 0b 29 66 6d 74 20 14 00 00 00 07 00 02 00 |?#.)fmt ........| 00000040 40 1f 00 00 80 3e 00 00 02 00 08 00 00 00 00 00 |@....>..........| 00000050 66 61 63 74 04 00 00 00 55 3d 57 00 65 79 72 65 |fact....U=W.eyre| 00000060 08 00 00 00 00 00 00 00 00 00 00 00 64 61 74 61 |............data| 00000070 00 8b 06 00 ff f5 ff f5 ff 7a ff fe ff fd ff 7d |.........z.....}| 00000080 ff 75 ff f8 f2 f1 f4 7a f8 fa fb f5 fb 6c ff f7 |.u.....z.....l..| 00000090 fc f7 fd f9 7c 79 7e 73 79 fc 75 71 7a 67 7e f6 |....|y~sy.uqzg~.| Note that after "WAVE" and before "fmt ", there's a chunk of data beginning with "sign". Our server code doesn't recognize this data, and is therefore rejecting the WAV file as being invalid. Is this "sign" data defined anywhere? I have never seen it described in any online description of the WAV file format. In any case, if you remove this data from the file, then you should be able to stream it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 9 14:11:59 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Jun 2011 14:11:59 -0700 Subject: [Live-devel] 264 raw byte buffer directly to streamer In-Reply-To: References: Message-ID: >I want to modify the "testOnDemandRTSPServer" test program for >streaming via unicast, so that I take the input from a byte buffer >inside my C++ code, and not from a file. I have already the >corresponding paragraph in FAQ. Yes, and the FAQ entries http://www.live555.com/liveMedia/faq.html#liveInput http://www.live555.com/liveMedia/faq.html#liveInput-unicast should give you the information that you need. What parts of this are unclear? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jun 9 15:04:33 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 9 Jun 2011 15:04:33 -0700 Subject: [Live-devel] openRTSP h264 decoding In-Reply-To: References: Message-ID: >Hello, first of all thank you all for maintaining this forum so active > >I am using openRTSP to recieve a stream with a >.sdp this stream contains video and audio >streams, but I?m only interested in the video, >which is encoded with h264, when i am trying to >decode with ffmpeg I obtain NAL errors. > >I also tried to write the stream in a file with >FileSink and open it with vlc or ffmpeg but i >obtained the same result, > >ffmpeg -i "video-H264-1" >video-H264-1: Unknown format Try renaming the file so that its name ends with ".h264". Then, VLC *might* be able to play the file. (Note, however, that this is not a VLC mailing list.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jun 10 01:17:10 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 01:17:10 -0700 Subject: [Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer In-Reply-To: <8CD7A9204779214D9FDC255DE48B952150CDF897@EXPMBX105-1.exch.logostech.net> References: <8CD7A9204779214D9FDC255DE48B952150CDF897@EXPMBX105-1.exch.logostech.net> Message-ID: >I am using the live555 library in a Linux application that receives >a low frame rate MPEG2-TS from a live source one frame at a time. >The source is not represented as a file by the OS. To make the >interface to the live555 library easier, I opened a pipe and write >each frame to it as I receive them. The read end of the pipe is >given as the source to a ByteStreamFileSource instance which then >feeds an instance of MPEG2TransportStreamFramer, which in turn feeds >a BasicUDPSink (unfortunately my requirements do not allow me to use >RTP/RTCP, which I would have preferred). This seems to work fairly >well with the following exceptions. > >1. BasicUDPSink has a default packet size of 1450. > MPEG2TransportStreamFramer asks its source (ByteStreamFileSource in >this case) for 1450 bytes You should instead be setting the "preferredFrameSize" parameter to "ByteStreamFileSource::createNew()". See, for example, line 144 of "testProgs/testMPEG2TransportStreamer.cpp", or line 199 of "liveMedia/MPEG2TransportFileServerMediaSubsession.cpp". If you set the "preferredFrameSize" parameter to 1316, then your "ByteStreamFileSource" will deliver that many bytes. >2. Since data is given to me and thus written to the pipe >frame-by-frame, it is very common that a single write to the pipe >will not be a multiple of 7 188-byte TS packets (e.g. a frame might >be 25192 bytes = 134 188-byte TS packets = 19 UDP packets containing >7 TS packets each + 1 UDP packet containing 1 TS packet). While the >MPEG2-TS source continues to produce frames this does not cause any >problems. However, when the source is paused/stopped it can cause >the event loop to hang indefinitely. This is due to the fact that >ByteStreamFileSource::doReadFromFile is trying to read more data >than it can receive and thus blocks in the "fFrameSize = fread(fTo, >1, fMaxSize, fFid);" line. Hmm, reads from the input file (in this case, a pipe) are supposed to be non-blocking, returning only as many bytes as are currently available (which will always be >0, because the read is happening only in response to a return from "select()" on the input file's socket). Perhaps there's some way you can configure your pipe to ensure that reads from it don't block? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From TWiser at logostech.net Fri Jun 10 05:28:07 2011 From: TWiser at logostech.net (Wiser, Tyson) Date: Fri, 10 Jun 2011 05:28:07 -0700 Subject: [Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer In-Reply-To: References: <8CD7A9204779214D9FDC255DE48B952150CDF897@EXPMBX105-1.exch.logostech.net> Message-ID: <8CD7A9204779214D9FDC255DE48B952150F13A06@EXPMBX105-1.exch.logostech.net> Ross, Thanks for the reply. Please see my comments inline below. Tyson >>I am using the live555 library in a Linux application that receives >>a low frame rate MPEG2-TS from a live source one frame at a time. >>The source is not represented as a file by the OS. To make the >>interface to the live555 library easier, I opened a pipe and write >>each frame to it as I receive them. The read end of the pipe is >>given as the source to a ByteStreamFileSource instance which then >>feeds an instance of MPEG2TransportStreamFramer, which in turn feeds >>a BasicUDPSink (unfortunately my requirements do not allow me to use >>RTP/RTCP, which I would have preferred). This seems to work fairly >>well with the following exceptions. >> >>1. BasicUDPSink has a default packet size of 1450. >> MPEG2TransportStreamFramer asks its source (ByteStreamFileSource in >>this case) for 1450 bytes > >You should instead be setting the "preferredFrameSize" parameter to >"ByteStreamFileSource::createNew()". See, for example, line 144 of >"testProgs/testMPEG2TransportStreamer.cpp", or line 199 of >"liveMedia/MPEG2TransportFileServerMediaSubsession.cpp". If you set >the "preferredFrameSize" parameter to 1316, then your >"ByteStreamFileSource" will deliver that many bytes. Thanks for pointing this out. I should have notice this but didn't. This is a much better solution. >>2. Since data is given to me and thus written to the pipe >>frame-by-frame, it is very common that a single write to the pipe >>will not be a multiple of 7 188-byte TS packets (e.g. a frame might >>be 25192 bytes = 134 188-byte TS packets = 19 UDP packets containing >>7 TS packets each + 1 UDP packet containing 1 TS packet). While the >>MPEG2-TS source continues to produce frames this does not cause any >>problems. However, when the source is paused/stopped it can cause >>the event loop to hang indefinitely. This is due to the fact that >>ByteStreamFileSource::doReadFromFile is trying to read more data >>than it can receive and thus blocks in the "fFrameSize = fread(fTo, >>1, fMaxSize, fFid);" line. > >Hmm, reads from the input file (in this case, a pipe) are supposed to >be non-blocking, returning only as many bytes as are currently >available (which will always be >0, because the read is happening >only in response to a return from "select()" on the input file's >socket). Perhaps there's some way you can configure your pipe to >ensure that reads from it don't block? I agree that, since a select call was made, we are guaranteed that there is at least one byte available for reading. I think the problem lies in the fread() function. From the Linux man page and other online documentation I get the impression that fread() will block until the requested amount of data has been read, there is an error, or EOF is reached. On the other hand, the read() function is not blocking and returns the requested amount of data or less if the requested amount is not currently available. From finlayson at live555.com Fri Jun 10 05:59:10 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 05:59:10 -0700 Subject: [Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer In-Reply-To: <8CD7A9204779214D9FDC255DE48B952150F13A06@EXPMBX105-1.exch.logostech.net> References: <8CD7A9204779214D9FDC255DE48B952150CDF897@EXPMBX105-1.exch.logostech.net> <8CD7A9204779214D9FDC255DE48B952150F13A06@EXPMBX105-1.exch.logostech.net> Message-ID: > >Hmm, reads from the input file (in this case, a pipe) are supposed to >>be non-blocking, returning only as many bytes as are currently >>available (which will always be >0, because the read is happening >>only in response to a return from "select()" on the input file's >>socket). Perhaps there's some way you can configure your pipe to >>ensure that reads from it don't block? > >I agree that, since a select call was made, we are guaranteed that there >is at least one byte available for reading. I think the problem lies in >the fread() function. From the Linux man page and other online documentation >I get the impression that fread() will block until the requested amount of >data has been read, there is an error, or EOF is reached. On the other >hand, the read() function is not blocking and returns the requested amount >of data or less if the requested amount is not currently available. I'm not convinced that any such distinction between the behavior of "fread()" and "read()" is portable across OSs. (For example, on FreeBSD, the man page for "fread()" doesn't mention blocking at all.) A better solution is to add the following code to the "ByteStreamFileSource" constructor (which is currently empty): #ifndef READ_FROM_FILES_SYNCHRONOUSLY makeSocketNonBlocking(fileno(fFid)); #endif and continue to implement "doReadFromFile()" using "fread()" rather than "read()". Please let us know if that works OK for you. If so, I'll make this change in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From TWiser at logostech.net Fri Jun 10 08:47:51 2011 From: TWiser at logostech.net (Wiser, Tyson) Date: Fri, 10 Jun 2011 08:47:51 -0700 Subject: [Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer In-Reply-To: References: <8CD7A9204779214D9FDC255DE48B952150CDF897@EXPMBX105-1.exch.logostech.net> <8CD7A9204779214D9FDC255DE48B952150F13A06@EXPMBX105-1.exch.logostech.net> Message-ID: <8CD7A9204779214D9FDC255DE48B952150F13C29@EXPMBX105-1.exch.logostech.net> >> >Hmm, reads from the input file (in this case, a pipe) are supposed to >>>be non-blocking, returning only as many bytes as are currently >>>available (which will always be >0, because the read is happening >>>only in response to a return from "select()" on the input file's >>>socket). Perhaps there's some way you can configure your pipe to >>>ensure that reads from it don't block? >> >>I agree that, since a select call was made, we are guaranteed that there >>is at least one byte available for reading. I think the problem lies in >>the fread() function. From the Linux man page and other online documentation >>I get the impression that fread() will block until the requested amount of >>data has been read, there is an error, or EOF is reached. On the other >>hand, the read() function is not blocking and returns the requested amount >>of data or less if the requested amount is not currently available. > >I'm not convinced that any such distinction between the behavior of >"fread()" and "read()" is portable across OSs. (For example, on >FreeBSD, the man page for "fread()" doesn't mention blocking at all.) > >A better solution is to add the following code to the >"ByteStreamFileSource" constructor (which is currently empty): > >#ifndef READ_FROM_FILES_SYNCHRONOUSLY > makeSocketNonBlocking(fileno(fFid)); >#endif > >and continue to implement "doReadFromFile()" using "fread()" rather >than "read()". > >Please let us know if that works OK for you. If so, I'll make this >change in the next release of the software. I have been unable to reproduce the event loop hang to test if this suggestion fixes it. It must have been a combination of the two issues mentioned in my original post that caused this. However, I have been able to verify that your suggested addition to the "ByteStreamFileSource" constructor still does not behave as I would expect it to when using "fread()". My video source can be as slow as 2 FPS. In this case I would expect that after I write a complete frame to the pipe (again this is H.264 video wrapped in an MPEG2-TS that is getting written to the pipe) that the entire frame would be read and sent out over the network before the next frame arrives with the last Ethernet packet of the frame potentially containing less than 1316 bytes of data. I put a debug statement in "ByteStreamFileSource::doReadFromFile()" that prints the value of "fMaxSize" and "fFrameSize" just after the "fread()" call. With or without your suggested addition to the constructor both values are always equal to 1316 (meaning it never reads less than that). This results in some data not being read and sent out on the network until the next frame arrives. I have seen as much as two of the 1316 byte reads get held back each frame. This means that the client does not receive the complete frame until the next frame comes in, which can be up to 500 milliseconds later. If I change the "fread()" call to a "read()" call, however, the behavior is what I expect. The majority of the debug statements show that the values of "fMaxSize" and "fFrameSize" are still equal to 1316, but when we reach the end of the frame the last read (and thus the value of "fFrameSize") is less than 1316. This results in the entire frame being read and sent out on the network as soon as it is written to my pipe (I've confirmed this with WireShark). I checked the FreeBSD man page for "fread()" and it appears to be essentially the same as the Linux man page. Neither one specifically mention blocking. You have to read between the lines. Quoting from the Linux man page: "The function fread() reads nmemb elements of data, each of size bytes long..." "fread() and fwrite() return the number of items successfully read or written (i.e., not the number of characters). **If** an error occurs, or the end-of-file is reached, the return value is a short item count (or zero)." I emphasized "If" because that suggests to me that the error or EOF condition is the only way that the returned count would not be equal to the requested count, thus implying blocking. http://www.cplusplus.com/reference/clibrary/cstdio/fread/ seems to also imply that "fread()" is blocking (emphasis is mine again): "The total number of elements successfully read is returned as a size_t object, which is an integral data type. **If this number differs from the count parameter, either an error occurred or the End Of File was reached**." Thus, for my application, using "fread()" gives incorrect behavior while using "read()" gives the correct behavior. You are obviously much more cognizant of the ramifications of this change than I am, so you may decide that the change should not be included in the live555 library. I ask that you at least consider it again. Meanwhile I will continue to try to reproduce the event loop hang. Thanks, Tyson From finlayson at live555.com Fri Jun 10 11:25:01 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 11:25:01 -0700 Subject: [Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer In-Reply-To: <8CD7A9204779214D9FDC255DE48B952150F13C29@EXPMBX105-1.exch.logostech.net> References: <8CD7A9204779214D9FDC255DE48B952150CDF897@EXPMBX105-1.exch.logostech.net> <8CD7A9204779214D9FDC255DE48B952150F13A06@EXPMBX105-1.exch.logostech.net> <8CD7A9204779214D9FDC255DE48B952150F13C29@EXPMBX105-1.exch.logostech.net> Message-ID: >Thus, for my application, using "fread()" gives incorrect behavior while using >"read()" gives the correct behavior. You are obviously much more >cognizant of the >ramifications of this change than I am, so you may decide that the >change should >not be included in the live555 library. I ask that you at least >consider it again. OK, in the next release of the software, "ByteStreamFileSource" will include *both* the call to "makeSocketNonBlocking()" (in the constructor), and call "read()" rather than "fread()" to read the data. (In each case, these will happen only if READ_FROM_FILES_SYNCHRONOUSLY is not defined (the default behavior).) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From debraj.manna at yahoo.co.in Fri Jun 10 11:46:26 2011 From: debraj.manna at yahoo.co.in (DEBRAJ MANNA) Date: Sat, 11 Jun 2011 00:16:26 +0530 (IST) Subject: [Live-devel] Live Media Server Concurrent Connections Message-ID: <978841.84679.qm@web95307.mail.in2.yahoo.com> Hi, What are the maximum number of parallel connections Live555 Media Server can support? I observed that in my set-up LiveMedia Server can support 250 connections ( generated using OpenRTSP ) each doing a mp3 file transfer. Media Server is running on 64 bit Linux Machine with 1GB RAM. Is there any way I can increase the number of parallel connections? Thanks, Debraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 10 13:31:22 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 13:31:22 -0700 Subject: [Live-devel] Live Media Server Concurrent Connections In-Reply-To: <978841.84679.qm@web95307.mail.in2.yahoo.com> References: <978841.84679.qm@web95307.mail.in2.yahoo.com> Message-ID: >What are the maximum number of parallel connections Live555 Media >Server can support? There's no fixed limit in our code. In practice, however, the number of open files (sockets) supported by the underlying operating system often sets a limiting factor. If you can increase this number (in your operating system), then this sometimes can increase scalability. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jun 10 14:15:38 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 14:15:38 -0700 Subject: [Live-devel] Problem with more than 20 sessions active on win32 In-Reply-To: <87lixazxok.wl%arn@bestmx.ru> References: <4CB3F3483954BD4ABD0B4DBB35C7E33801E53400@exchsrv.idszentral.local> <87lixazxok.wl%arn@bestmx.ru> Message-ID: Because this sort of question (about the scalability of our RTSP server) has been asked so many times recently, I've now added a FAQ entry: http://www.live555.com/liveMedia/faq.html#scalability -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jun 10 14:41:18 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 14:41:18 -0700 Subject: [Live-devel] Problems on iPhone when on cell network In-Reply-To: <07F2F3C9-6E28-46C1-99B3-7A9BE44A74BB@uni-kassel.de> References: <3EC6EEDBCBD4AC4A9FBE5F1F5EEA86190438E9@SRVBRIEXC012.brisa.pt> <8D680F20-2096-4D0A-9084-B71CEB146BDB@uni-kassel.de> <4DCC07C4.3050306@schuckmannacres.com> <07F2F3C9-6E28-46C1-99B3-7A9BE44A74BB@uni-kassel.de> Message-ID: Sorry for the long delay in responding to this. (I've been traveling for the past two months, and am way behind on email.) >Unable to determine our source address: This computer has an invalid >IP address: 0x0 Our code (specifically, the function "ourIPAddress()" in "groupsock/GroupsockHelper.cpp") uses two mechanisms (in succession) to try to find the computer's IP address: 1/ It sends a multicast packet, then receives it and looks at the IP source address. 2/ If step 1/ fails, the code then calls "gethostname()", extracts the resulting domain name, and then calls "gethostbyname()" on this domain name. Step 1/ is by far the most reliable mechanism of the two (because many systems either don't have a domain name, or else "gethostname()" and/or "gethostbyname()" aren't supported). However, for Step 1/ to work, you *must* have IP multicast working on your system. In particular, you need to have a route installed on your system for 224/8. Nonetheless, this is the first thing that people should try to do if they encounter this problem. Now, I'm (pleasantly) surprised to learn that you have the "LIVE555 Streaming Media" code working on an iPhone, because our documentation does not include instructions for compiling for the iPhone. (If anyone would like to contribute some instructions/tips for doing this, I'd be happy to add them to our online documentation.) However, because you're getting this error, it means that both 1/ the iPhone's OS doesn't have an IP multicast route installed for 224/8, *and* 2/ the combination of "gethostname()" and "gethostbyname()" isn't working. If you can't fix either 1/ or 2/, then you'll have to come up with some other mechanism for getting your IP address. (If you can do this, let us know, and we'll consider adding it (as a third mechanism to try) to our "ourIPAddress()" code.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Brad.Lackey at schneider-electric.com Fri Jun 10 17:20:06 2011 From: Brad.Lackey at schneider-electric.com (Lackey, Brad) Date: Fri, 10 Jun 2011 17:20:06 -0700 Subject: [Live-devel] Find a particular rtsp session Message-ID: <4BBAF403456ED74981E7164ED3A4C22402D0A426@CA-EVS02.pelco.org> Is there a way to find a specific rtsp client session? I currently have the RTSPServer object, and I would like a way to search it's connected clients for a specific connection and ultimately get it's FramedSource object so that I can tell it to stop sending frames, send one frame every couple seconds, send one frame, send last frame, play normal, etc The stream controls (send one frame, send last frame) are sent to me via a webservice and I have to manipulate the way I send out frames to a particular already connected rtsp client. Is there an easy way of doing what I have described? Thanks in advance! ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 10 20:14:53 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 20:14:53 -0700 Subject: [Live-devel] Find a particular rtsp session In-Reply-To: <4BBAF403456ED74981E7164ED3A4C22402D0A426@CA-EVS02.pelco.org> References: <4BBAF403456ED74981E7164ED3A4C22402D0A426@CA-EVS02.pelco.org> Message-ID: >Is there a way to find a specific rtsp client session? I currently >have the RTSPServer object, and I would like a way to search it's > connected clients for a specific connection and ultimately get it's >FramedSource object so that I can tell it to stop sending frames, >send one frame every couple seconds, send one frame, send last >frame, play normal, etc > >The stream controls (send one frame, send last frame) are sent to me >via a webservice and I have to manipulate the way I send out frames >to a particular already connected rtsp client. > >Is there an easy way of doing what I have described? Thanks in advance! There's no way to do this with the supplied "RTSPServer" implementation 'as is', because it does not maintain any data structure that keeps track of the "RTSPClientSession" objects as they're created/deleted (because, with this basic implementation, such a data structure is not needed). However, you can get the functionality you want by subclassing. You should be able to do this without modifying the existing code. Specifically, you would define your own subclass of "RTSPServer", and reimplement the virtual function "createNewClientSession()" so that it not only creates a new "RTSPClientSession" object, but also records it in some data structure (that you would define) that you want to use for searching. Of course, you'll also need to keep track of the *deletion* of each "RTSPClientSession" object, so you'll probably also want to subclass "RTSPClientSession", and implement a (virtual) destructor in the subclass that removes itself from your data structure. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jun 10 22:11:19 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 22:11:19 -0700 Subject: [Live-devel] Question about trickmode with liveMediaserver In-Reply-To: References: Message-ID: >I am testing RTSP/RTP with liveMediaserver with MPEG2-TS. >I made index file and the file for trickmode using >testMPEG2TransportStreamTrickPlay.exe > >For example, original contents is avatar.ts >index file is avatar.tsx and file for trickplay is avatar2.ts You have misunderstood the purpose of the "testMPEG2TransportStreamTrickPlay" application. This application is *not* needed to implement server 'trick play' operations for Transport Streams. Instead, it is merely a demonstration application that *simulates* the effect of trick play, by generating a new Transport Stream (from the original transport stream) that can be played directly by a media player. To support 'trick play' for your file "avatar.ts", you need *only* generate the index file "avatar.tsx" - by running: MPEG2TransportStreamIndexer avatar.ts Then make sure that both "avatar.ts" and "avatar.tsx" are present in the same directory as the "live555MediaServer" application. Once again, see http://www.live555.com/liveMedia/transport-stream-trick-play.html >1. Is it possible the trickplay on VLC with liveMediaserver ? Yes, using VLC's 'fast forward' (i.e. ">>") GUI button. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jun 10 22:17:12 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 22:17:12 -0700 Subject: [Live-devel] Questions about MPEG2 transport streams In-Reply-To: <4DBFE9B2.5000303@bertin.fr> References: <4DBFE9B2.5000303@bertin.fr> Message-ID: >I'm currently using openRTSP to receive MPEG2 transport streams. >I'd rather have N subsessions for N streams, but I'm not responsible >for these servers, so I must stick with TS packets. > >And here are my two questions : > >Is it possible, in a RTSP client, to select a specific stream among >the others, and only receive this one ? No (unless the server happens to explicitly support such an operation, which ours does not (nor does any other server that I'm aware of)). > I think it's not possible, but maybe you have some code to so in >liveMedia APIs ? It would be possible, in principle, to do this with our code, by subclassing "RTSPServer", and writing your own server-side filter (sitting between the "ByteStreamFileSource" and the "MPEG2TransportStreamFramer") that converted the input Transport Stream to one that contained just the specific substream that the client had requested. >Otherwise, are there some methods available, always on client' side, >to parse a TS packet, list its inner streams, and extract one ? No, not in our code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 10 22:51:49 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 10 Jun 2011 22:51:49 -0700 Subject: [Live-devel] Raw RTP Packet Info In-Reply-To: References: Message-ID: >Is there a way to get information about the RTP packets that make up >each media frame (client-side)? I want to know the sequence number of >each packet, the size of each packet, and the time that each one >arrived. I plan to write my own MediaSink for "frame" statistics, but >I'd also like information about the packets that compose that frame. > >I've run openRTSP and studied the code. I've also looked through the >code for the inheritance tree from H264VideoRTPSource through Medium. >I'm not sure if I need to implement an auxiliary read handler for the >source or if there's an easier option. Look at how "openRTSP" implements the "-Q" option. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jun 11 08:05:23 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Jun 2011 08:05:23 -0700 Subject: [Live-devel] [live-devel] Rtsp-alt [FIN, ACK] after about one minute In-Reply-To: <002101cbff02$5d83b040$188b10c0$@kim@lge.com> References: <002101cbff02$5d83b040$188b10c0$@kim@lge.com> Message-ID: >Recently, I've been reviewing Live555 S/W package. > >Regarding to the issue below -- >"Rtsp-alt [FIN, ACK] after about one minute testOnDemandRTSPServer" >http://lists.live555.com/pipermail/live-devel/2008-November/009751.html >is there anyone who has an answer? Rather than referring to a confusing, badly-written question from more than 2 years ago, why don't you tell us what specific question *you* have about the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jun 11 08:08:53 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Jun 2011 08:08:53 -0700 Subject: [Live-devel] rtsp h264 extracting In-Reply-To: References: Message-ID: >I need to extract h264 frames from valid rtsp stream (that is >initialized with url path). How can I do this? I've managed to >extract some video data from rtsp stream but don't know what to do >with it next. Our RTSP client code - when receiving H.264/RTP streams - delivers H.264 NAL units (one at a time). You'll need to feed this data to a H.264 decoder (software or hardware). Note, however, that our software does *not* do any audio or video decoding. You'll need to find/write separate software (or hardware) to do this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jun 11 08:12:01 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Jun 2011 08:12:01 -0700 Subject: [Live-devel] SSRC Changing mid stream In-Reply-To: <6ECEF82A-E445-4918-A939-335E56A2FD25@stevemcfarlin.com> References: <6ECEF82A-E445-4918-A939-335E56A2FD25@stevemcfarlin.com> Message-ID: >I have an issue with the unsupported Darwin injector pushing a >H264VidoRtpSink. It appears the SSRC is changing mid stream as >reported by my server. I took a look at RTPSink and see this is >randomly generated in the constructor. Is there any reason this >might change? Not in our code (at present), no. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jun 11 08:16:09 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Jun 2011 08:16:09 -0700 Subject: [Live-devel] warning: backward_pts != current_pts In-Reply-To: References: Message-ID: >We are using live555 for RTSP streaming. When we see the stream on >VLC player there are breaks at regular intervals. >So when I see the messages, I get the following messages. > >main warning: backward_pts != current_pts (-156964) >main warning: backward_pts != current_pts (-161570) >main warning: backward_pts != current_pts (-154928) >main warning: backward_pts != current_pts (-163876) >main warning: backward_pts != current_pts (-157760) >main warning: backward_pts != current_pts (-161366) >main warning: backward_pts != current_pts (238609133685) >main warning: backward_pts != current_pts (-238609452664) >main warning: backward_pts != current_pts (-148244) >main warning: backward_pts != current_pts (-174015) >main warning: backward_pts != current_pts (-149298) > >What does this warning mean? This is not a VLC mailing list! VLC is not our software! -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jun 11 08:20:00 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Jun 2011 08:20:00 -0700 Subject: [Live-devel] what's the filename extension for the audio file generated by openRTSP In-Reply-To: <157dbe6.451.12f687c48f6.Coremail.llzz2@163.com> References: <157dbe6.451.12f687c48f6.Coremail.llzz2@163.com> Message-ID: >I'm fresh in the site and executed the command line as below >./openRTSP rtsp://video2.americafree.tv/AFTVHorrorH26496.sdp >and it gerenated 1 video (video-H264-1)and 1 >audio(audio-MPEG4-GENERIC-2) files. Either .264 or .mpg extension >matches the file of video-H264-1 and it plays well in the movie >player in Ubuntu, but for the audio-MPEG4-GENERIC-2 of the audio >file, I tyried .aac, .amr, mp3, wav, ts, they all failed and can't >be played. I'm confused. The "audio-MPEG4-GENERIC-2" file is a raw AAC audio file, with no header. Most media players will probably not be able to play this file, unless it is given a header (e.g., an ADTS header), which our software (currently) does not do when it writes the file. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jun 11 08:22:43 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Jun 2011 08:22:43 -0700 Subject: [Live-devel] Want to receive packet directly not file. In-Reply-To: References: Message-ID: >I am making a RTSP Client player with using the liveMedia library. >My reference code is openRTSP, but it receives the RTP data in a File. > >I want to receive the RTP data(raw or Payload OK) directly and >will put the decoder directly. > >I saw AuxilliaryReadHandler() for this, but I read somewhere this >function is not good and it will be removed soon. > >Please tell me how to do it. Use the "-v" option (to output video-only to stdout), or the "-a" option (to output audio only to stdout), and then pipe it to a decoder application (that reads from stdin). If you can't do this, you'll need to write your own "MediaSink" subclass, and use that instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jun 11 08:27:03 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 11 Jun 2011 08:27:03 -0700 Subject: [Live-devel] subsession->readSource() is 0x0 In-Reply-To: References: Message-ID: >I'm trying to use live555 to make an rtsp client. So, I think i'm >really close to succeed but I'm getting errors. When I call > >subsession->sink->startPlaying(*(subsession->readSource()), >subsessionAfterPlaying, subsession); > > > subsession->readSource() returns a null pointer so, how can make it right ? You're probably forgetting to call "MediaSession::initiate()" (after doing the RTSP "DESCRIBE", but before doing the RTSP "SETUP"). That's the function that creates the "readSource()" pointers. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 12 01:42:39 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Jun 2011 01:42:39 -0700 Subject: [Live-devel] RTCP bug in multicast? In-Reply-To: References: Message-ID: > I just read the rtcp.cpp and find a problem in multicast mode. > In RTCPInstance::incomingReportHandler1(), from line 342 : [...] > Here, the mechanism to prevent endless loop seems not perfect, >checking the variables fHaveJustSentPacket and fLastPacketSentSize is >not enough. Yes, you're correct. As you noted, this is a problem if we're a SSM source, because (in that case) we want to resend the incoming packet back to the multicast group, and if the packet originated from us, then this would cause a 'packet storm'. > To avoid this bug we must enable the code in >Groupsock::multicastSendOnly(), so the server will not received any >multicast packets that it just sent out. Unfortunately we can't do that, because some OSs have a bug whereby multicast sending doesn't work if we don't also join the group. What I've done instead is change the RTCP code so that we send the incoming packet back to the multicast group only if we know for sure that the packet originated from another host. This should avoid the possibility of a 'packet storm'. I've now installed a new version (2011.06.12 ) of the code that includes this change. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jun 12 01:44:42 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Jun 2011 01:44:42 -0700 Subject: [Live-devel] Strange problem with h264 streaming In-Reply-To: <3EC6EEDBCBD4AC4A9FBE5F1F5EEA861904376B@SRVBRIEXC012.brisa.pt> References: <3EC6EEDBCBD4AC4A9FBE5F1F5EEA861904376B@SRVBRIEXC012.brisa.pt> Message-ID: FYI, I've now installed a new version (2011.06.12 ) of the "LIVE555 Streaming Media" code that fixes a problem that *might* have been causing this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jun 12 14:34:44 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Jun 2011 14:34:44 -0700 Subject: [Live-devel] RTSP Authentication memory leak In-Reply-To: <1305715302.16174.7.camel@VTPL-Quad2> References: <1305715302.16174.7.camel@VTPL-Quad2> Message-ID: > I am using live555 for last few months. Last week I downloaded the >latest archive. Now when i integrate it, from valgrind I have some >memory leak problem. For RTSPClient.cpp sendPlayCommand, >sendSetupCommand, sendOptionsCommand and sendDescribeCommand the >statement "if (authenticator != NULL) fCurrentAuthenticator = >*authenticator;" allocated the the memory for the overloaded operartor >"=". But memory is not deleted. The previous versions don't have this >problem. I cannot access the class as i inherited my own client from it. >Any idea about this... Thanks for the note. There was a bug in "Authenticator::operator=()": We weren't freeing the left-hand-side object's memory before assigning to it. This will be fixed in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jun 12 14:47:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Jun 2011 14:47:20 -0700 Subject: [Live-devel] RTSP considerations and more. RTP vs TS In-Reply-To: References: Message-ID: >currently I'm developing an RTSP client using VLC bindings. However >i had to make a few adjustments to the VLC source code in order to >achieve fast rewind. Tests were successful, but there are still a >few bugs to be attended. I have two questions relating this issue. > >First in the vlc devel list I'm discussing this issue: > > >> The problem you mentioned in the forum is kind of a big fail (yes i'm >>> mundu :). When fast rewinding the time gets stuck and then it doesn't >>> update. If you press play it will only start from the time you issued >>> the setRate(negative), and not at the time where I pressed play again. >>> Do you know where vlc actually updates its time? > > > There are several issues with rtsp and time update. In fact the time >> will always update at 1x speed. >> That's because rtsp servers re-calculate timestamps, and vlc thinks it >> receives the pictures at 1x speed. >> Time update is based on timestamps > >It seems that VLC doesn't have a way to properly figure out at what >time the video is currently playing when issuing for example a >set_rate(-2). The "LIVE555 Streaming Media" library *does* provide such a function: "MediaSubsession::getNormalPlayTime()". Furthermore, this function *is* called by VLC's LIVE555 interface code ("live555.cpp"). Note, however, that this is VLC code, not ours - so it's outside the scope of this mailing list. >Another question relates to the TS vs RTP. As you know set top boxes >request raw-UDP because they don't need RTP overhead. However I'm >currently trying to understand the benefits of eradicating the >transport stream container as it proves to be the most greedy in >terms of overhead. I mean RTP uses 12 bytes of overhead while 6 TS >packets inside a RTP packet uses 24 bytes. Twice as much as the RTP >overhead. Not to mention that both have timestamp information >(redundant information). In a Video on demand application while >streaming HD content, this proves to be to much in a long-term use. >(And normally TS is to multiplex several Programs not just a movie). >I raise this question only focused on an Internet service and not >TV( STBs and DVB uses TS so no questions there). My question is, >what is the downsize of using H264 without a container when it comes >to trick play. The only downside (sic) of doing trickplay on H.264/RTP streams (rather than on H.264 video-only Transport Streams) is that our server implementation currently doesn't support this. > As far as I know the indexer already searches for H264 I-Frames, am >i wrong? But i read in a paper that the computational costs of doing >such a thing is too much. Is this true? I don't really understand this question, but I think the answer is "no". There's no reason in principle why our server couldn't support trick play when streaming raw H.264 files over RTP - e.g., by using an 'index file' on such files (just as we use an index file for trick play when streaming Transport Stream files). However, we just haven't implemented such a thing yet. Note, though, that there's another benefit for using Transport Streams - they include audio as well as video. If you wanted to stream from raw H.264 files, then you wouldn't get any audio (because H.264 files are, by definition, video only). That would be OK if your stream doesn't contain any audio (e.g., if it's from a security camera), but if your stream contains audio, then you'd need to tie it to the video stream in some way. Transport Streams provide one standard way of doing this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jun 12 15:32:42 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 12 Jun 2011 15:32:42 -0700 Subject: [Live-devel] RTSPServer crash with simultaneous identical requests In-Reply-To: <20110503094608.M21495@livingdata.pt> References: <20110503094608.M21495@livingdata.pt> Message-ID: >So we ran testOnDemandRTSPServer with some of the videos you supply >for tests and >created a simple shell script with the following lines for the clients: > >#!/bin/sh >./openRTSP -F "0-" rtsp://127.0.0.1:8554/h264ESVideoTest > >openRTSP-0.log 2>&1 & >./openRTSP -F "1-" rtsp://127.0.0.1:8554/h264ESVideoTest > >openRTSP-1.log 2>&1 & > >This should launch (almost simultaneously) two instances of openRTSP >that ask for the >same video segment from the server. And we got similar results to our app. > >Either the server crashes with a segfault or it delivers the video >correctly to one of >the clients but it delivers a SDP description containing errors to >the 2nd (or so >openRTSP complains). From that point on every new request from a >client receives a >corrupted SDP description. Sorry for the long delay in responding to this. (I've been traveling for the past two months, and am way behind on email.) Many thanks for reporting this (and for the detailed instructions of how to reproduce this with the installed code). I'm currently looking into this problem, and will update the mailing list shortly, when I find out more. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From debraj.manna at yahoo.co.in Tue Jun 14 00:18:12 2011 From: debraj.manna at yahoo.co.in (DEBRAJ MANNA) Date: Tue, 14 Jun 2011 12:48:12 +0530 (IST) Subject: [Live-devel] Configuring IP & Port for Live Media Server Message-ID: <93314.97736.qm@web95301.mail.in2.yahoo.com> Hi, I am new to Live Media Server. The linux machine that I am using has two IPs. Is it possible to bind the Live Media Server to a specific IP & port on that machine? I am currently using Live Media Server's pre-built binaries for Linux. Thanks, Debraj -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 14 02:28:38 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 02:28:38 -0700 Subject: [Live-devel] Configuring IP & Port for Live Media Server In-Reply-To: <93314.97736.qm@web95301.mail.in2.yahoo.com> References: <93314.97736.qm@web95301.mail.in2.yahoo.com> Message-ID: >I am new to Live Media Server. The linux machine that I am using has >two IPs. Is it possible to bind the Live Media Server to a specific >IP & port on that machine? I am currently using Live Media Server's >pre-built binaries for Linux. No, the "LIVE555 Media Server" application first tries to use port 554 (the default port number for RTSP), and then (if port 554 can't be used) it tries to use port 8554 (the alternative port number for RTSP). These port numbers can't be changed (unless you were to modify the source code). As for the IP address: The application will use whichever network interface is used for multicast routing. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Szoke at BeeComputing.com Tue Jun 14 03:17:27 2011 From: Szoke at BeeComputing.com (Szoke) Date: Tue, 14 Jun 2011 12:17:27 +0200 Subject: [Live-devel] Configuring IP & Port for Live Media Server In-Reply-To: References: <93314.97736.qm@web95301.mail.in2.yahoo.com> Message-ID: <4DF73537.90304@BeeComputing.com> On 14/06/2011 11:28, Ross Finlayson wrote: >> I am new to Live Media Server. The linux machine that I am using has >> two IPs. Is it possible to bind the Live Media Server to a specific >> IP & port on that machine? I am currently using Live Media Server's >> pre-built binaries for Linux. > > No, the "LIVE555 Media Server" application first tries to use port 554 > (the default port number for RTSP), and then (if port 554 can't be > used) it tries to use port 8554 (the alternative port number for > RTSP). These port numbers can't be changed (unless you were to modify > the source code). > > As for the IP address: The application will use whichever network > interface is used for multicast routing. Be aware that some Internet providers may block port 554. My provider (Belgacom) is definitely doing that. We never succeeded accessing our IP cameras from Internet using port 554. Using port 5554 worked fine. Stan From thomas.maier at uni-kassel.de Tue Jun 14 05:14:35 2011 From: thomas.maier at uni-kassel.de (Thomas Maier) Date: Tue, 14 Jun 2011 14:14:35 +0200 Subject: [Live-devel] Problems on iPhone when on cell network In-Reply-To: References: <3EC6EEDBCBD4AC4A9FBE5F1F5EEA86190438E9@SRVBRIEXC012.brisa.pt> <8D680F20-2096-4D0A-9084-B71CEB146BDB@uni-kassel.de> <4DCC07C4.3050306@schuckmannacres.com> <07F2F3C9-6E28-46C1-99B3-7A9BE44A74BB@uni-kassel.de> Message-ID: <7950C696-4E27-4BE3-8B5C-32B982F90511@uni-kassel.de> Am 10.06.2011 um 23:41 schrieb Ross Finlayson: > Sorry for the long delay in responding to this. (I've been traveling for the past two months, and am way behind on email.) Hi Ross, thanks for the follow-up. Hope it was a nice vacation. >> Unable to determine our source address: This computer has an invalid IP address: 0x0 > > Our code (specifically, the function "ourIPAddress()" in "groupsock/GroupsockHelper.cpp") uses two mechanisms (in succession) to try to find the computer's IP address: > > 1/ It sends a multicast packet, then receives it and looks at the IP source address. > > 2/ If step 1/ fails, the code then calls "gethostname()", extracts the resulting domain name, and then calls "gethostbyname()" on this domain name. > > Step 1/ is by far the most reliable mechanism of the two (because many systems either don't have a domain name, or else "gethostname()" and/or "gethostbyname()" aren't supported). However, for Step 1/ to work, you *must* have IP multicast working on your system. In particular, you need to have a route installed on your system for 224/8. Nonetheless, this is the first thing that people should try to do if they encounter this problem. > > Now, I'm (pleasantly) surprised to learn that you have the "LIVE555 Streaming Media" code working on an iPhone, because our documentation does not include instructions for compiling for the iPhone. (If anyone would like to contribute some instructions/tips for doing this, I'd be happy to add them to our online documentation.) However, because you're getting this error, it means that both 1/ the iPhone's OS doesn't have an IP multicast route installed for 224/8, *and* 2/ the combination of "gethostname()" and "gethostbyname()" isn't working. If you can't fix either 1/ or 2/, then you'll have to come up with some other mechanism for getting your IP address. (If you can do this, let us know, and we'll consider adding it (as a third mechanism to try) to our "ourIPAddress()" code.) Thanks for the overview, Ross. Unfortunately I have not found a solution. Regarding iOS, um, there actually was a config.iphoneos in the archive I downloaded. You might want to apply the "ar vs. libtool" patch there, too. Isn't it great when you forget on how many platforms your own software runs :). -- Thomas From finlayson at live555.com Tue Jun 14 06:53:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 06:53:20 -0700 Subject: [Live-devel] Configuring IP & Port for Live Media Server In-Reply-To: <4DF73537.90304@BeeComputing.com> References: <93314.97736.qm@web95301.mail.in2.yahoo.com> <4DF73537.90304@BeeComputing.com> Message-ID: >>No, the "LIVE555 Media Server" application first tries to use port >>554 (the default port number for RTSP), and then (if port 554 can't >>be used) it tries to use port 8554 (the alternative port number for >>RTSP). These port numbers can't be changed (unless you were to >>modify the source code). >[...] >Be aware that some Internet providers may block port 554. My >provider (Belgacom) is definitely doing that. We never succeeded >accessing our IP cameras from Internet using port 554. Using port >5554 worked fine. You shouldn't use port number 5554, because that's defined for use by the "SGI ESP HTTP" protocol, whatever that is; see . If - for whatever reason - you can't use port number 554, then you should use port number 8554 instead, because both 554 and 8554 are defined for use by RTSP. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jun 14 07:05:53 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 07:05:53 -0700 Subject: [Live-devel] Problems on iPhone when on cell network In-Reply-To: <7950C696-4E27-4BE3-8B5C-32B982F90511@uni-kassel.de> References: <3EC6EEDBCBD4AC4A9FBE5F1F5EEA86190438E9@SRVBRIEXC012.brisa.pt> <8D680F20-2096-4D0A-9084-B71CEB146BDB@uni-kassel.de> <4DCC07C4.3050306@schuckmannacres.com> <07F2F3C9-6E28-46C1-99B3-7A9BE44A74BB@uni-kassel.de> <7950C696-4E27-4BE3-8B5C-32B982F90511@uni-kassel.de> Message-ID: >However, because you're getting this error, it means that both 1/ >the iPhone's OS doesn't have an IP multicast route installed for >224/8, *and* 2/ the combination of "gethostname()" and >"gethostbyname()" isn't working. If you can't fix either 1/ or 2/, >then you'll have to come up with some other mechanism for getting >your IP address. (If you can do this, let us know, and we'll >consider adding it (as a third mechanism to try) to our >"ourIPAddress()" code.) > >Thanks for the overview, Ross. Unfortunately I have not found a solution. I would imagine that this - finding the iPhone's own IP address - is a common problem encountered by iPhone app developers. You might want to ask on iPhone development forums about this. >Regarding iOS, um, there actually was a config.iphoneos in the >archive I downloaded. You might want to apply the "ar vs. libtool" >patch there, too. > >Isn't it great when you forget on how many platforms your own >software runs :). Aha, yes, I'd completely forgotten about "config.iphoneos"; someone had contributed this just over a year ago: http://lists.live555.com/pipermail/live-devel/2010-May/012178.html -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From d.velkin at ids-imaging.de Tue Jun 14 07:42:17 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Tue, 14 Jun 2011 16:42:17 +0200 Subject: [Live-devel] RTP over TCP with iPhone Message-ID: Hello, i am developing an iPhone/iPad App that receives RTSP-streams. It works fine, while the server and client are in the same network. But If I try to get a stream from outside(from Internet) i run in problems with UDP-ports. On the server side i can open ports, but on a client side it is sometimes impossible. So i tried to use RTP over TCP: m_pRtspClient->sendSetupCommand(*pSubsession, continueAfterSETUP,False,True); But it doesn't work, even if i am in the same network. If I set last parameter to False than my app works fine(but only in the same network). About my systems: My server is "self implemented media server"(January 2011 Version ) that runs on windows. I use unicast. My client has a latest live555 (Mai 2011) version. I can't find out where is a problem. Can You point me to solve this problem? (if You need more information ask me please) thanks! Dmitrij P.S: In attachment is a wireshark protokoll(i caputured it in a simulator) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iPhone_internet Type: application/octet-stream Size: 622012 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 14 08:33:05 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 08:33:05 -0700 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: Message-ID: >i am developing an iPhone/iPad App that receives RTSP-streams. It >works fine, while the server and client are in the same network. But >If I try to get a stream from outside(from Internet) i run in >problems with UDP-ports. On the server side i can open ports, but on >a client side it is sometimes impossible. So i tried to use RTP >over TCP: > > m_pRtspClient->sendSetupCommand(*pSubsession, >continueAfterSETUP,False,True); > >But it doesn't work, even if i am in the same network. If I set last >parameter to False than my app works fine(but only in the same >network). > >About my systems: >My server is "self implemented media server"(January 2011 Version ) >that runs on windows. I use unicast. >My client has a latest live555 (Mai 2011) version. > >I can't find out where is a problem. Perhaps the problem is with your "self implemented media server"? I suggest that you try testing your client using one of our (unmodified) RTSP server applications - "testOnDemandRTSPServer" or "live555MediaServer" first. It might also help if you could get our "openRTSP" client running on your iPhone/iPad, and first use that - rather than your own client application - for testing. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From matt at schuckmannacres.com Tue Jun 14 11:33:05 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Tue, 14 Jun 2011 11:33:05 -0700 Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters Message-ID: <4DF7A961.3090701@schuckmannacres.com> Has anyone succeeded in modifying the LiveMedia classes to support accepting parameters in the URI, something like the following to request a specific height and width, bitrate, and framerate: rtsp://media.server.com/live_video?height=320&width=400&kbps=300&fps=15 With a H.264 stream changing some of these parameters will change the SPS, and PPS and thus change the SDP. The way RTSPServer, ServerMediaSession, and OnDemandMediaSession work they all make assumptions about the media name and that the SDP will not change and key parts of each classes interfaces are not virtual so changing things appears to be difficult without changing the LiveMedia code. I just wanted to ask if anybody else has tackled this task and how it went for them. Thanks, Matt S. PS I will admit that I'm still using a somewhat older version of LiveMedia, if recent changes to the library has made this task easier let me know and I'll look into updating things. From jshanab at smartwire.com Tue Jun 14 11:59:25 2011 From: jshanab at smartwire.com (Jeff Shanab) Date: Tue, 14 Jun 2011 18:59:25 +0000 Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters In-Reply-To: <4DF7A961.3090701@schuckmannacres.com> References: <4DF7A961.3090701@schuckmannacres.com> Message-ID: <615FD77639372542BF647F5EBAA2DBC20B11ADEB@IL-BOL-EXCH01.smartwire.com> By rtsp you mean as a client? The system often connects and is told by the server what it supports. DESCRIBE,SETUP,PLAY I am talking to security cameras and I am expecting on some cameras this info to change. I will detect this on the fly from a changed PPS and SPS. Indeed since I embed them or they are embedded in the stream it is the decoder that detects this on decode of first frame made by the [7][8][5] -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Matt Schuckmannn Sent: Tuesday, June 14, 2011 1:33 PM To: live-devel at ns.live555.com Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters Has anyone succeeded in modifying the LiveMedia classes to support accepting parameters in the URI, something like the following to request a specific height and width, bitrate, and framerate: rtsp://media.server.com/live_video?height=320&width=400&kbps=300&fps=15 With a H.264 stream changing some of these parameters will change the SPS, and PPS and thus change the SDP. The way RTSPServer, ServerMediaSession, and OnDemandMediaSession work they all make assumptions about the media name and that the SDP will not change and key parts of each classes interfaces are not virtual so changing things appears to be difficult without changing the LiveMedia code. I just wanted to ask if anybody else has tackled this task and how it went for them. Thanks, Matt S. PS I will admit that I'm still using a somewhat older version of LiveMedia, if recent changes to the library has made this task easier let me know and I'll look into updating things. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From kidjan at gmail.com Tue Jun 14 08:58:05 2011 From: kidjan at gmail.com (Jeremy Noring) Date: Tue, 14 Jun 2011 08:58:05 -0700 Subject: [Live-devel] Some extra files in testProgs... Message-ID: In the latest release (6-14), some raw h264 files and openRTSP log files found their way into the testProgs folder. -Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 14 12:53:56 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 12:53:56 -0700 Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters In-Reply-To: <4DF7A961.3090701@schuckmannacres.com> References: <4DF7A961.3090701@schuckmannacres.com> Message-ID: >Has anyone succeeded in modifying the LiveMedia classes to support >accepting parameters in the URI, something like the following to >request a specific height and width, bitrate, and framerate: > >rtsp://media.server.com/live_video?height=320&width=400&kbps=300&fps=15 > >With a H.264 stream changing some of these parameters will change >the SPS, and PPS and thus change the SDP. The way RTSPServer, >ServerMediaSession, and OnDemandMediaSession work they all make >assumptions about the media name and that the SDP will not change For this reason, you should probably treat each stream as having its own "ServerMediaSubsession" (subclass) object, rather than trying to use the same "ServerMediaSubsession" (subclass) object for each stream. That way, these objects can continue to work from the assumption that their SDP config information - once set up - will not change. For example (to use your example string), "live_video?height=320&width=400&kbps=300&fps=15" would use a completely separate "ServerMediaSubsession" (subclass) object than "live_video?height=320&width=400&kbps=300&fps=30". You can probably do this by subclassing "RTSPServer" and redefining the virtual function "lookupServerMediaSession()" in your subclass. Plus, of course, you'll need your own subclass of "OnDemandServerMediaSubsession" (it'll be similar to "H264VideoFileServerMediaSubsession" if you're streaming H.264), but you're presumably already doing that. Once again, when you think of extending the supplied code, you should be thinking first about subclassing, and modify the supplied code only as a last resort (if at all). I also want to remind everyone that subclassing the code considerably simplifies your obligations under the LGPL. If you modify the supplied code, and then release a product based on these modifications, then you are required to also make your modified source code available. If, instead, you subclass the supplied code (without modifying it), then you are not required to make available any of your source code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jun 14 12:55:44 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 12:55:44 -0700 Subject: [Live-devel] Some extra files in testProgs... In-Reply-To: References: Message-ID: >In the latest release (6-14), some raw h264 files and openRTSP log >files found their way into the testProgs folder. Yes, these got left in by mistake. I've just released a new version (2011.06.14a) that removes these (but makes no other changes from 2011.06.14). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jun 14 12:59:09 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 12:59:09 -0700 Subject: [Live-devel] RTSPServer crash with simultaneous identical requests In-Reply-To: <20110503094608.M21495@livingdata.pt> References: <20110503094608.M21495@livingdata.pt> Message-ID: Thanks again for reporting this bug. I have identified and fixed (I hope) a 'race condition' that was causing this problem. It affected streaming both H.264 video files (your example), and MPEG-4 video files. The latest release - 2011.06.14a - of the "LIVE555 Streaming Media" code fixes this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From matt at schuckmannacres.com Tue Jun 14 13:42:44 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Tue, 14 Jun 2011 13:42:44 -0700 Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters In-Reply-To: References: <4DF7A961.3090701@schuckmannacres.com> Message-ID: <4DF7C7C4.7060606@schuckmannacres.com> > > For example (to use your example string), > "live_video?height=320&width=400&kbps=300&fps=15" would use a > completely separate "ServerMediaSubsession" (subclass) object than > "live_video?height=320&width=400&kbps=300&fps=30". > This seems infeasible as I want to be able support any number of combination of all 4 of these parameters (plus more parameters like GoP size etc). Seems much more reasonable to have one subclass of ServerMediaSession and ServerMediaSubsession that can read and interpret the parameters on a per connection basis. > You can probably do this by subclassing "RTSPServer" and redefining > the virtual function "lookupServerMediaSession()" in your subclass. > Plus, of course, you'll need your own subclass of > "OnDemandServerMediaSubsession" (it'll be similar to > "H264VideoFileServerMediaSubsession" if you're streaming H.264), but > you're presumably already doing that. > > Once again, when you think of extending the supplied code, you should > be thinking first about subclassing, and modify the supplied code only > as a last resort (if at all). > Oh I definitely first turned to sub classing, I don't want to modify the library code if I don't have to, and it's probably possible, but as they say the proof is in the pudding and it's easy to say just subclass it until you actually dig in and try and you find the little things that are less than ideal. I've already got a sub class of RTSPServer, RTSPClientSession, OnDemandServerMediaSubSession and ServerMediaSession. I think I can see at least most of the way there with out modifying the library, but I'll have to do some copy, paste, modify of some the library methods into my own to get there and I always hate doing that if I don't have to. I've done my own version of lookupServerMediaSession() to do the look up based on the the media name and not the whole urlSuffix (as it's called in the code). I then turned how to pass the parameters to the ServerMediaSession::generateSDPDescription(), which is not virtual nor takes any parameters, so I'd probably have to create a new ServerMediaSessioN::generateSDPDescription that takes the parameters part of the URI and then re-implements much of what is in your ServerMediaSession::generateSDPDescription() but simply passes the parameter string on to the subsessions sdpLines methods. Then I'll need to over load the OnDemandServerMediaSubsession::sdpLines() method which is virtual but again I'll have to copy much of what is already there and I'll need a way to pass the parameters to sdpLines() so the fact that's it's virtual really doesn't matter. Of course the member variable fSDPLines which is used by sdpLines() is private so not available to a subclass but that's probably OK in this case, I just wont use it. I'm sure the problem goes a bit deeper in the class hierarchy and it's manageable in one form or another. I didn't say I couldn't see how to do it, rather I was asking if anybody else had successfully done it and perhaps what there methodology was. From matt at schuckmannacres.com Tue Jun 14 13:48:23 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Tue, 14 Jun 2011 13:48:23 -0700 Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters In-Reply-To: <615FD77639372542BF647F5EBAA2DBC20B11ADEB@IL-BOL-EXCH01.smartwire.com> References: <4DF7A961.3090701@schuckmannacres.com> <615FD77639372542BF647F5EBAA2DBC20B11ADEB@IL-BOL-EXCH01.smartwire.com> Message-ID: <4DF7C917.6030901@schuckmannacres.com> On 6/14/2011 11:59 AM, Jeff Shanab wrote: > By rtsp you mean as a client? No I'm talking about modifying the RTSPServer which a client will connect to. > The system often connects and is told by the server what it supports. DESCRIBE,SETUP,PLAY > > I am talking to security cameras and I am expecting on some cameras this info to change. I will detect this on the fly from a changed PPS and SPS. Indeed since I embed them or they are embedded in the stream it is the decoder that detects this on decode of first frame made by the [7][8][5] > Yes I've seen security cameras that support the type of URI I'm talking about (Axis comes to mind first). I think I've already been doing what you suggest, i.e. leave the PPS and SPS in the byte stream and let the decoder detect the changes and react accordingly, and it works quite well as long as I have complete control over the client (for a long time I didn't even bother to put the PPS and SPS in the SDP) However, I'm starting to work with a client (a RTSP to RTMP protocol trans-coder) that is not OK with this so I need to allow things to be setup correctly in the SDP from the get go. Matt S. From finlayson at live555.com Tue Jun 14 14:27:08 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 14:27:08 -0700 Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters In-Reply-To: <4DF7C7C4.7060606@schuckmannacres.com> References: <4DF7A961.3090701@schuckmannacres.com> <4DF7C7C4.7060606@schuckmannacres.com> Message-ID: >>For example (to use your example string), >>"live_video?height=320&width=400&kbps=300&fps=15" would use a >>completely separate "ServerMediaSubsession" (subclass) object than >>"live_video?height=320&width=400&kbps=300&fps=30". >> >This seems infeasible as I want to be able support any number of >combination of all 4 of these parameters (plus more parameters like >GoP size etc). No, it's completely feasible. The trick is *not* to create all of the possible the "ServerMediaSession" (and "ServerMediaSubsession") objects upfront, but instead to create them 'on demand', when needed. This is what we do for the "LIVE555 Media Server" application, using the "DynamicRTSPServer" class - which subclasses "RTSPServer" and reimplements the virtual function "lookupServerMediaSession()". (Note the code in the "mediaServer" directory.) You could do something similar. >Seems much more reasonable to have one subclass of >ServerMediaSession and ServerMediaSubsession that can read and >interpret the parameters on a per connection basis. Well, the problem with that is - as you've discovered - that the "ServerMediaS(ubs)ession" objects are assumed to each represent a single 'media object' that you're streaming - e.g., a file. If you open another stream with different codec parameters, it's conceptually like streaming from a different file. Either way will probably work, but I suspect that you'll find it easier to use a different "ServerMediaS(ubs)ession" object for each parameter combination - but create these on demand. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From matt at schuckmannacres.com Tue Jun 14 14:45:56 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Tue, 14 Jun 2011 14:45:56 -0700 Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters In-Reply-To: References: <4DF7A961.3090701@schuckmannacres.com> <4DF7C7C4.7060606@schuckmannacres.com> Message-ID: <4DF7D694.7090105@schuckmannacres.com> Ah I think I see what your saying I took your words "ServerMediaSubsession (subclass)" to mean that you were suggesting that I create an entirely new subclass type for each possible combination of parameters but you meant a new instance of a sub class of ServerMediaSubsession for each connection. Yes, that does seem much more feasible, don't know why I didn't see it before. I will investigate that approach and let you know how it goes. Thanks, Matt S. On 6/14/2011 2:27 PM, Ross Finlayson wrote: >>> For example (to use your example string), >>> "live_video?height=320&width=400&kbps=300&fps=15" would use a >>> completely separate "ServerMediaSubsession" (subclass) object than >>> "live_video?height=320&width=400&kbps=300&fps=30". >>> >> This seems infeasible as I want to be able support any number of >> combination of all 4 of these parameters (plus more parameters like >> GoP size etc). > > No, it's completely feasible. The trick is *not* to create all of the > possible the "ServerMediaSession" (and "ServerMediaSubsession") > objects upfront, but instead to create them 'on demand', when needed. > This is what we do for the "LIVE555 Media Server" application, using > the "DynamicRTSPServer" class - which subclasses "RTSPServer" and > reimplements the virtual function "lookupServerMediaSession()". (Note > the code in the "mediaServer" directory.) You could do something > similar. > > >> Seems much more reasonable to have one subclass of ServerMediaSession >> and ServerMediaSubsession that can read and interpret the parameters >> on a per connection basis. > > Well, the problem with that is - as you've discovered - that the > "ServerMediaS(ubs)ession" objects are assumed to each represent a > single 'media object' that you're streaming - e.g., a file. If you > open another stream with different codec parameters, it's conceptually > like streaming from a different file. > > Either way will probably work, but I suspect that you'll find it > easier to use a different "ServerMediaS(ubs)ession" object for each > parameter combination - but create these on demand. From Brad.Lackey at schneider-electric.com Tue Jun 14 18:40:54 2011 From: Brad.Lackey at schneider-electric.com (Lackey, Brad) Date: Tue, 14 Jun 2011 18:40:54 -0700 Subject: [Live-devel] Find a particular rtsp session In-Reply-To: References: <4BBAF403456ED74981E7164ED3A4C22402D0A426@CA-EVS02.pelco.org> Message-ID: <4683A740-A882-453D-8A47-4E6DDE395AE2@pelco.com> Thanks! That put me on the right track, one last question. Once I have a list of RTSPClientSession objects, what's the best way to grab it's FramedSource? There doesn't seem to be a straight forward way to acquire it. Thanks again. On Jun 10, 2011, at 9:37 PM, "Ross Finlayson" wrote: >> Is there a way to find a specific rtsp client session? I currently have the RTSPServer object, and I would like a way to search it's connected clients for a specific connection and ultimately get it's FramedSource object so that I can tell it to stop sending frames, send one frame every couple seconds, send one frame, send last frame, play normal, etc >> >> The stream controls (send one frame, send last frame) are sent to me via a webservice and I have to manipulate the way I send out frames to a particular already connected rtsp client. >> >> Is there an easy way of doing what I have described? Thanks in advance! > > There's no way to do this with the supplied "RTSPServer" implementation 'as is', because it does not maintain any data structure that keeps track of the "RTSPClientSession" objects as they're created/deleted (because, with this basic implementation, such a data structure is not needed). > > However, you can get the functionality you want by subclassing. You should be able to do this without modifying the existing code. > > Specifically, you would define your own subclass of "RTSPServer", and reimplement the virtual function "createNewClientSession()" so that it not only creates a new "RTSPClientSession" object, but also records it in some data structure (that you would define) that you want to use for searching. Of course, you'll also need to keep track of the *deletion* of each "RTSPClientSession" object, so you'll probably also want to subclass "RTSPClientSession", and implement a (virtual) destructor in the subclass that removes itself from your data structure. > > -- > > 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 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 14 20:30:14 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 20:30:14 -0700 Subject: [Live-devel] Find a particular rtsp session In-Reply-To: <4683A740-A882-453D-8A47-4E6DDE395AE2@pelco.com> References: <4BBAF403456ED74981E7164ED3A4C22402D0A426@CA-EVS02.pelco.org> <4683A740-A882-453D-8A47-4E6DDE395AE2@pelco.com> Message-ID: >Thanks! That put me on the right track, one last question. Once I >have a list of RTSPClientSession objects, what's the best way to >grab it's FramedSource? There doesn't seem to be a straight forward >way to acquire it. You're right - there isn't, unfortunately. This information isn't exposed to the "RTSPServer" code, because it's not needed there. Instead, it's used by the "ServerMediaS(ubs)ession" object for the stream, via the 'streamToken' pointer (which the "RTSPServer" code treats as opaque). Here's what I would do. Unfortunately it requires first moving the definition of "class StreamState" from "OnDemandServerMediaSubsession.cpp" to "include/OnDemandServerMediaSubsession.hh". (I might make that change in a future release of the code.) 1/ Have your "OnDemandServerMediaSubsession" subclass export a function FramedSource* framedSource(void* streamToken) { StreamState* streamState = (StreamState*)streamToken; return streamState->mediaSource(); } 2/ In your "RTSPServer" subclass, for each RTSPClientSession* clientSession : for (unsigned i = 0; i < fNumStreamStates; ++i) { YourOnDemandServerMediaSubsession* subsession = (YourOnDemandServerMediaSubsession*) (fStreamStates[i].subsession); FramedSource* source = subsession->framedSource(fStreamStates[i].streamToken); } -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jun 14 21:40:35 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 21:40:35 -0700 Subject: [Live-devel] Stream JPEG images created with OpenCV In-Reply-To: <4FA6FF25-8E32-415B-97A2-75EC97E655A3@archlinux.cl> References: <4FA6FF25-8E32-415B-97A2-75EC97E655A3@archlinux.cl> Message-ID: >\Hi!!... i'm trying to solve a problem to create a stream application. > >I have an application that use OpenCV to capture frames from any >camera connected .. this works in a thread feeding a circular buffer >(using semaphores ).. then i read from this buffer to do some >processing and feed another circular buffer to storages the frames >(OpenCV image representation) ... So i wan't to read from this >frame, encode the data into a JPEG image (this can be donde with >libjpeg or using OpenCV so no problem here) .. and use this new jpeg >image (not a file a memory buffer) .. and stream this.. > >Can this be done with live555? (first question) > >I read the Elphel code and i trying to understand how the library works. > >I need to create a VideoSource or something like that or i can use >something to "Push" this jpeg images to do the streaming part? > >Is there any guideline, example or something where i can found >information of how to do this.. Yes, see http://www.live555.com/liveMedia/faq.html#liveInput -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jun 14 21:47:24 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 14 Jun 2011 21:47:24 -0700 Subject: [Live-devel] Streaming testMPEG1or2AudioVideoStreamer behind network firewall In-Reply-To: <7F32C6A46402CD49BA87BC5874370F1A2A0C90C362@NDA-HCLT-EVS05.HCLT.CORP.HCL.I N> References: <7F32C6A46402CD49BA87BC5874370F1A2A0C90C362@NDA-HCLT-EVS05.HCLT.CORP.HCL.I N> Message-ID: >We have setup a Windows server (with a publically accessible IP >address) outside our LAN. When I setup and run >"live555MediaServer.exe" on this server, and try to access (using >VLC Player) the generated RTSP URL from my local machine (which >resides behind a network firewall), I am able to see the stream. >However when I try to do the same, using >"testMPEG1or2AudioVideoStreamer.exe", I am unable to view the stream >from my local machine (which resides behind a network firewall). That's probably because your firewall does not support multicast routing - i.e., does not pass multicast packets. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From d.velkin at ids-imaging.de Wed Jun 15 00:29:50 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Wed, 15 Jun 2011 09:29:50 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: Message-ID: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> Hello Ross, thank you for replying! I guess that it isn't a server's problem. I tested the connection with an unmodified openRTSP client and got an image(see output below). My question is, are there other places i have to change in source code for using TCP except sendSetupCommand? Thanks! Console input: ./openRTSP -t rtsp://193.158.57.66:8555/mjpeg Console output: Opening connection to 193.158.57.66, port 8555... ...remote connection opened Sending request: OPTIONS rtsp://193.158.57.66:8555/mjpeg RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Received 122 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Wed, Jun 15 2011 08:17:16 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: DESCRIBE rtsp://193.158.57.66:8555/mjpeg RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Accept: application/sdp Received 538 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Wed, Jun 15 2011 08:17:16 GMT Content-Base: rtsp://192.168.30.41:8555/mjpeg/ Content-Type: application/sdp Content-Length: 373 v=0 o=- 1307089321210096 1 IN IP4 192.168.30.41 s=RTSP/RTP stream from IDS VSE i=mjpeg t=0 0 a=tool:LIVE555 Streaming Media v2008.04.02 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from IDS VSE a=x-qt-text-inf:mjpeg m=video 0 RTP/AVP 26 c=IN IP4 0.0.0.0 a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 a=control:track2 Opened URL "rtsp://193.158.57.66:8555/mjpeg", returning a SDP description: v=0 o=- 1307089321210096 1 IN IP4 192.168.30.41 s=RTSP/RTP stream from IDS VSE i=mjpeg t=0 0 a=tool:LIVE555 Streaming Media v2008.04.02 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from IDS VSE a=x-qt-text-inf:mjpeg m=video 0 RTP/AVP 26 c=IN IP4 0.0.0.0 a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 a=control:track2 Created receiver for "video/JPEG" subsession (client ports 53608-53609) Created receiver for "audio/PCMU" subsession (client ports 58372-58373) Sending request: SETUP rtsp://192.168.30.41:8555/mjpeg/track1 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Received 173 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Wed, Jun 15 2011 08:17:17 GMT Transport: RTP/AVP/TCP;unicast;destination=89.199.63.222;source=192.168.30.41;interleaved=0-1 Session: 80 Setup "video/JPEG" subsession (client ports 53608-53609) Sending request: SETUP rtsp://192.168.30.41:8555/mjpeg/track2 RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 80 Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Date: Wed, Jun 15 2011 08:17:17 GMT Transport: RTP/AVP/TCP;unicast;destination=89.199.63.222;source=192.168.30.41;interleaved=2-3 Session: 80 Setup "audio/PCMU" subsession (client ports 58372-58373) Created output file: "video-JPEG-1" Created output file: "audio-PCMU-2" Sending request: PLAY rtsp://192.168.30.41:8555/mjpeg/ RTSP/1.0 CSeq: 6 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Session: 80 Range: npt=0.000- Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Date: Wed, Jun 15 2011 08:17:17 GMT Range: npt=0.000- Session: 80 RTP-Info: url=rtsp://192.168.30.41:8555/mjpeg/track1;seq=42451;rtptime=658530933,url=rtsp://192.168.30.41:8555/mjpeg/track2;seq=9573;rtptime=2871840167 Started playing session Receiving streamed data (signal with "kill -HUP 39105" or "kill -USR1 39105" to terminate)... Am 14.06.2011 um 17:33 schrieb Ross Finlayson: > >i am developing an iPhone/iPad App that receives RTSP-streams. It > >works fine, while the server and client are in the same network. But > >If I try to get a stream from outside(from Internet) i run in > >problems with UDP-ports. On the server side i can open ports, but on > >a client side it is sometimes impossible. So i tried to use RTP > >over TCP: > > > > m_pRtspClient->sendSetupCommand(*pSubsession, > >continueAfterSETUP,False,True); > > > >But it doesn't work, even if i am in the same network. If I set last > >parameter to False than my app works fine(but only in the same > >network). > > > >About my systems: > >My server is "self implemented media server"(January 2011 Version ) > >that runs on windows. I use unicast. > >My client has a latest live555 (Mai 2011) version. > > > >I can't find out where is a problem. > > Perhaps the problem is with your "self implemented media server"? I > suggest that you try testing your client using one of our > (unmodified) RTSP server applications - "testOnDemandRTSPServer" or > "live555MediaServer" first. > > It might also help if you could get our "openRTSP" client running on > your iPhone/iPad, and first use that - rather than your own client > application - for testing. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 15 00:33:19 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Jun 2011 00:33:19 -0700 Subject: [Live-devel] VLC stops working due to live555 breakdown after 2147 seconds In-Reply-To: <4DE39727.6040506@BeeComputing.com> References: <4DE39727.6040506@BeeComputing.com> Message-ID: >I have started a discussion on the VLC forum, which explains the >problem I have with Live555: >http://forum.videolan.org/viewtopic.php?f=14&t=90813 As noted in one of the messages on that forum, you should use a recent version of the LIVE555 code, which should fix the bug that you noted. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jun 15 01:16:32 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Jun 2011 01:16:32 -0700 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> Message-ID: >I guess that it isn't a server's problem. I tested the connection >with an unmodified openRTSP client and got an image(see output >below). >My question is, are there other places i have to change in source >code for using TCP except sendSetupCommand? No. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sebastien-devel at celeos.eu Wed Jun 15 01:43:42 2011 From: sebastien-devel at celeos.eu (=?ISO-8859-1?Q?S=E9bastien?= Escudier) Date: Wed, 15 Jun 2011 10:43:42 +0200 Subject: [Live-devel] VLC stops working due to live555 breakdown after 2147 seconds In-Reply-To: References: <4DE39727.6040506@BeeComputing.com> Message-ID: <1308127422.21345.3.camel@stim-desktop> On Wed, 2011-06-15 at 00:33 -0700, Ross Finlayson wrote: > >I have started a discussion on the VLC forum, which explains the > >problem I have with Live555: > >http://forum.videolan.org/viewtopic.php?f=14&t=90813 > > As noted in one of the messages on that forum, you should use a > recent version of the LIVE555 code, which should fix the bug that you > noted. VLC 1.1.10 has a recent version of live555 if it does not work, then I think it's a camera issue. You could also test live555 directly (testProgs), to see if the stream disconnect after 35 minutes. It would tell you if the problem is in vlc or not. From sumeet.kumar at hcl.com Wed Jun 15 03:36:44 2011 From: sumeet.kumar at hcl.com (Sumeet Kumar - ERS, HCL Tech) Date: Wed, 15 Jun 2011 16:06:44 +0530 Subject: [Live-devel] Streaming testMPEG1or2AudioVideoStreamer behind network firewall Message-ID: <7F32C6A46402CD49BA87BC5874370F1A2C92A2A253@NDA-HCLT-EVS05.HCLT.CORP.HCL.IN> Hi Ross, Thank you for suggesting the reason for possible failure in streaming testMPEG1or2AudioVideoStreamer behind network firewall. It is indeed the case, as you have correctly pointed that firewall does not support multicast routing. But I face the same problem if I run the testMPEG1or2AudioVideoStreamer in unicast mode also. Can you please advise, why does this problem appear even when I run the testMPEG1or2AudioVideoStreamer in unicast mode. Regards, Sumeet Kumar ________________________________ ::DISCLAIMER:: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brad.Lackey at schneider-electric.com Wed Jun 15 09:26:33 2011 From: Brad.Lackey at schneider-electric.com (Lackey, Brad) Date: Wed, 15 Jun 2011 09:26:33 -0700 Subject: [Live-devel] Find a particular rtsp session In-Reply-To: References: <4BBAF403456ED74981E7164ED3A4C22402D0A426@CA-EVS02.pelco.org><4683A740-A882-453D-8A47-4E6DDE395AE2@pelco.com> Message-ID: <4BBAF403456ED74981E7164ED3A4C22402D0A875@CA-EVS02.pelco.org> Perfect, thank you! -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, June 14, 2011 8:30 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Find a particular rtsp session >Thanks! That put me on the right track, one last question. Once I >have a list of RTSPClientSession objects, what's the best way to >grab it's FramedSource? There doesn't seem to be a straight forward >way to acquire it. You're right - there isn't, unfortunately. This information isn't exposed to the "RTSPServer" code, because it's not needed there. Instead, it's used by the "ServerMediaS(ubs)ession" object for the stream, via the 'streamToken' pointer (which the "RTSPServer" code treats as opaque). Here's what I would do. Unfortunately it requires first moving the definition of "class StreamState" from "OnDemandServerMediaSubsession.cpp" to "include/OnDemandServerMediaSubsession.hh". (I might make that change in a future release of the code.) 1/ Have your "OnDemandServerMediaSubsession" subclass export a function FramedSource* framedSource(void* streamToken) { StreamState* streamState = (StreamState*)streamToken; return streamState->mediaSource(); } 2/ In your "RTSPServer" subclass, for each RTSPClientSession* clientSession : for (unsigned i = 0; i < fNumStreamStates; ++i) { YourOnDemandServerMediaSubsession* subsession = (YourOnDemandServerMediaSubsession*) (fStreamStates[i].subsession); FramedSource* source = subsession->framedSource(fStreamStates[i].streamToken); } -- 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 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From finlayson at live555.com Wed Jun 15 09:39:00 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Jun 2011 09:39:00 -0700 Subject: [Live-devel] Streaming testMPEG1or2AudioVideoStreamer behind network firewall In-Reply-To: <7F32C6A46402CD49BA87BC5874370F1A2C92A2A253@NDA-HCLT-EVS05.HCLT.CORP.HCL.I N> References: <7F32C6A46402CD49BA87BC5874370F1A2C92A2A253@NDA-HCLT-EVS05.HCLT.CORP.HCL.I N> Message-ID: >Thank you for suggesting the reason for possible failure in >streaming testMPEG1or2AudioVideoStreamer behind network firewall. It >is indeed the case, as you have correctly pointed that firewall does >not support multicast routing. But I face the same problem if I run >the testMPEG1or2AudioVideoStreamer in unicast mode also. Can you >please advise, why does this problem appear even when I run the >testMPEG1or2AudioVideoStreamer in unicast mode. Perhaps you're not doing it right. Or perhaps your firewall is causing more problems. But, in any case, I really don't care, because you also said (in your first message) that "live555MediaServer" - streaming unicast via RTSP/RTP - worked OK for you. So that is what you should be using. RTSP is the best way to set up unicast streams; do not fight it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From matt at schuckmannacres.com Wed Jun 15 16:58:05 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Wed, 15 Jun 2011 16:58:05 -0700 Subject: [Live-devel] Modifying LiveMedia RTSPServer classes to support URI parameters In-Reply-To: <4DF7D694.7090105@schuckmannacres.com> References: <4DF7A961.3090701@schuckmannacres.com> <4DF7C7C4.7060606@schuckmannacres.com> <4DF7D694.7090105@schuckmannacres.com> Message-ID: <4DF9470D.5070607@schuckmannacres.com> Worked like a charm, thank you Ross. Matt S. On 6/14/2011 2:45 PM, Matt Schuckmannn wrote: > Ah I think I see what your saying I took your words > "ServerMediaSubsession (subclass)" to mean that you were suggesting > that I create an entirely new subclass type for each possible > combination of parameters but you meant a new instance of a sub class > of ServerMediaSubsession for each connection. > > Yes, that does seem much more feasible, don't know why I didn't see it > before. > I will investigate that approach and let you know how it goes. > > Thanks, > Matt S. > > On 6/14/2011 2:27 PM, Ross Finlayson wrote: >>>> For example (to use your example string), >>>> "live_video?height=320&width=400&kbps=300&fps=15" would use a >>>> completely separate "ServerMediaSubsession" (subclass) object than >>>> "live_video?height=320&width=400&kbps=300&fps=30". >>>> >>> This seems infeasible as I want to be able support any number of >>> combination of all 4 of these parameters (plus more parameters like >>> GoP size etc). >> >> No, it's completely feasible. The trick is *not* to create all of >> the possible the "ServerMediaSession" (and "ServerMediaSubsession") >> objects upfront, but instead to create them 'on demand', when needed. >> This is what we do for the "LIVE555 Media Server" application, using >> the "DynamicRTSPServer" class - which subclasses "RTSPServer" and >> reimplements the virtual function "lookupServerMediaSession()". (Note >> the code in the "mediaServer" directory.) You could do something >> similar. >> >> >>> Seems much more reasonable to have one subclass of >>> ServerMediaSession and ServerMediaSubsession that can read and >>> interpret the parameters on a per connection basis. >> >> Well, the problem with that is - as you've discovered - that the >> "ServerMediaS(ubs)ession" objects are assumed to each represent a >> single 'media object' that you're streaming - e.g., a file. If you >> open another stream with different codec parameters, it's >> conceptually like streaming from a different file. >> >> Either way will probably work, but I suspect that you'll find it >> easier to use a different "ServerMediaS(ubs)ession" object for each >> parameter combination - but create these on demand. > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From sokratis.barmpounakis at unige.ch Wed Jun 15 02:15:40 2011 From: sokratis.barmpounakis at unige.ch (Sokratis Barmpounakis) Date: Wed, 15 Jun 2011 11:15:40 +0200 Subject: [Live-devel] stream from data pointer, not file Message-ID: I want to stream the data included in nal[0].p_payload (the variable is uint8_t *p_payload) which is output of x264 encoding. I want to stream each byte after it gets out of the encoder. I am using testOnDemandRTSPServer (because I want unicast). Which is the simplest way to do it? Thank you, Sokratis -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 15 21:34:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 15 Jun 2011 21:34:20 -0700 Subject: [Live-devel] stream from data pointer, not file In-Reply-To: References: Message-ID: >I want to stream the data included in > >nal[0].p_payload (the variable is uint8_t *p_payload) which is >output of x264 encoding. I want to stream each byte after it gets >out of the encoder. >I am using testOnDemandRTSPServer (because I want unicast). >Which is the simplest way to do it? You could start by reading the FAQ, as you were asked to do before posting to the mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From d.velkin at ids-imaging.de Thu Jun 16 01:02:34 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Thu, 16 Jun 2011 10:02:34 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> Message-ID: <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> Hello Ross, I am still searching for my error. I had debugged in your source code in the hope that i can find my error. I came to the place where you read data from TCP. In RTPInterface.cpp in 'tcpReadHandler1' I figure out, that the value of 'fNextTCPReadStreamSocketNum' is a big negative value. This makes a Problem to read in 'HandleRead' from TCP and not from 'groupsock'. Do you have an Idea why is fNextTCPReadStreamSocketNum negative? And What I can do to get it positive? thanks, Dmitrij! Am 15.06.2011 um 10:16 schrieb Ross Finlayson: >> I guess that it isn't a server's problem. I tested the connection with an unmodified openRTSP client and got an image(see output below). >> My question is, are there other places i have to change in source code for using TCP except sendSetupCommand? > > No. > -- > > 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 d.velkin at ids-imaging.de Thu Jun 16 01:03:45 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Thu, 16 Jun 2011 10:03:45 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> Message-ID: Hello Ross, I am still searching for my error. I had debugged in your source code in the hope that i can find my error. I came to the place where you read data from TCP. In RTPInterface.cpp in 'tcpReadHandler1' I figure out, that the value of 'fNextTCPReadStreamSocketNum' is a big negative value. This makes a Problem to read in 'HandleRead' from TCP and not from 'groupsock'. Do you have an Idea why is fNextTCPReadStreamSocketNum negative? And What I can do to get it positive? thanks, Dmitrij! Am 15.06.2011 um 10:16 schrieb Ross Finlayson: >> I guess that it isn't a server's problem. I tested the connection with an unmodified openRTSP client and got an image(see output below). >> My question is, are there other places i have to change in source code for using TCP except sendSetupCommand? > > No. > -- > > 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 d.velkin at ids-imaging.de Thu Jun 16 01:03:45 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Thu, 16 Jun 2011 10:03:45 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> Message-ID: Hello Ross, I am still searching for my error. I had debugged in your source code in the hope that i can find my error. I came to the place where you read data from TCP. In RTPInterface.cpp in 'tcpReadHandler1' I figure out, that the value of 'fNextTCPReadStreamSocketNum' is a big negative value. This makes a Problem to read in 'HandleRead' from TCP and not from 'groupsock'. Do you have an Idea why is fNextTCPReadStreamSocketNum negative? And What I can do to get it positive? thanks, Dmitrij! Am 15.06.2011 um 10:16 schrieb Ross Finlayson: >> I guess that it isn't a server's problem. I tested the connection with an unmodified openRTSP client and got an image(see output below). >> My question is, are there other places i have to change in source code for using TCP except sendSetupCommand? > > No. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 16 02:10:17 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Jun 2011 02:10:17 -0700 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> Message-ID: Please don't send the same message to the mailing list more than once. You already know that "openRTSP -t" - built from the supplied, unmodified source code - works OK on your system. So I suggest that you start from this code, making only small, incremental changes at a time, until it evolves into your new application. Unfortunately we can't debug your new code for you; you're going to have to do this yourself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jun 16 03:03:24 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Jun 2011 03:03:24 -0700 Subject: [Live-devel] streaming AC3 over RTP using LIve555 In-Reply-To: References: Message-ID: Sorry for the long delay in addressing this issue. It turns out that our "AC3AudioStreamFramer" implementation was not implemented properly for streaming from a raw AC-3 audio file. (Instead, it was working only when streaming AC-3 audio that had been extracted from a VOB file.) I have now installed a new version (2011.06.16) of the "LIVE555 Streaming Media" code that: 1/ Fixes "AC3AudioStreamFramer". 2/ Adds a new class "AC3AudioFileServerMediaSubsession" (as you originally suggested). 3/ Updates the "testOnDemandRTSPServer" and "live555MediaServer" applications to support streaming AC-3 audio files via RTSP/RTP. (Currently, only the source code for "live555MediaServer" has been updated; not the pre-built binary versions.) 4/ Updates the implementation of "AC3AudioRTPSink" and "AC3AudioRTPSource" to properly conform to the RTP payload format for AC-3 audio, as defined by RFC 4184. (Previously, we were using a different, incompatible payload format that had been defined by an earlier draft document.) Unfortunately, this means that older clients that use our code - including existing binary versions of VLC and MPlayer - will no longer be able to play AC-3/RTP streams from our server (until they are rebuilt using this newest version of our library). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From d.velkin at ids-imaging.de Thu Jun 16 03:45:17 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Thu, 16 Jun 2011 12:45:17 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> Message-ID: Am 16.06.2011 um 11:10 schrieb Ross Finlayson: > Please don't send the same message to the mailing list more than once. > Sorry for this! > You already know that "openRTSP -t" - built from the supplied, unmodified source code - works OK on your system. I have to correct my statement. Sorry! I get only first image with: ./openRTSP -t -F ______Video rtsp://193.158.57.66:8555/mjpeg If I wont to write .avi, I find nothing in testProgs directory. With: ./openRTSP -i -t -n -F ______Video rtsp://193.158.57.66:8555/mjpeg thanks! Here ist output: Warning: The -q, -4 or -i option was used, but not -w. Assuming a video width of 240 pixels Warning: The -q, -4 or -i option was used, but not -h. Assuming a video height of 180 pixels Warning: The -q, -4 or -i option was used, but not -f. Assuming a video frame rate of 15 frames-per-second Opening connection to 193.158.57.66, port 8555... ...remote connection opened Sending request: OPTIONS rtsp://193.158.57.66:8555/mjpeg RTSP/1.0 CSeq: 2 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Received 122 new bytes of response data. Received a complete OPTIONS response: RTSP/1.0 200 OK CSeq: 2 Date: Thu, Jun 16 2011 11:33:07 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: DESCRIBE rtsp://193.158.57.66:8555/mjpeg RTSP/1.0 CSeq: 3 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Accept: application/sdp Received 538 new bytes of response data. Received a complete DESCRIBE response: RTSP/1.0 200 OK CSeq: 3 Date: Thu, Jun 16 2011 11:33:07 GMT Content-Base: rtsp://192.168.30.41:8555/mjpeg/ Content-Type: application/sdp Content-Length: 373 v=0 o=- 1308142837917588 1 IN IP4 192.168.30.41 s=RTSP/RTP stream from IDS VSE i=mjpeg t=0 0 a=tool:LIVE555 Streaming Media v2008.04.02 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from IDS VSE a=x-qt-text-inf:mjpeg m=video 0 RTP/AVP 26 c=IN IP4 0.0.0.0 a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 a=control:track2 Opened URL "rtsp://193.158.57.66:8555/mjpeg", returning a SDP description: v=0 o=- 1308142837917588 1 IN IP4 192.168.30.41 s=RTSP/RTP stream from IDS VSE i=mjpeg t=0 0 a=tool:LIVE555 Streaming Media v2008.04.02 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream from IDS VSE a=x-qt-text-inf:mjpeg m=video 0 RTP/AVP 26 c=IN IP4 0.0.0.0 a=control:track1 m=audio 0 RTP/AVP 0 c=IN IP4 0.0.0.0 a=control:track2 Created receiver for "video/JPEG" subsession (client ports 58638-58639) Created receiver for "audio/PCMU" subsession (client ports 64600-64601) Sending request: SETUP rtsp://192.168.30.41:8555/mjpeg/track1 RTSP/1.0 CSeq: 4 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Received 173 new bytes of response data. Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 4 Date: Thu, Jun 16 2011 11:33:07 GMT Transport: RTP/AVP/TCP;unicast;destination=89.199.54.248;source=192.168.30.41;interleaved=0-1 Session: 50 Setup "video/JPEG" subsession (client ports 58638-58639) Sending request: SETUP rtsp://192.168.30.41:8555/mjpeg/track2 RTSP/1.0 CSeq: 5 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 50 Received a complete SETUP response: RTSP/1.0 200 OK CSeq: 5 Date: Thu, Jun 16 2011 11:33:07 GMT Transport: RTP/AVP/TCP;unicast;destination=89.199.54.248;source=192.168.30.41;interleaved=2-3 Session: 50 Setup "audio/PCMU" subsession (client ports 64600-64601) RIFFAVI LISThdrlavihj ????8LISTstrlstrhvidsmjpg??????@???8strf(??mjpg@?(JUNK00dc?LISTstrlstrhauds@??????8strf at JUNK01wbxJUNKodmldmlh?h"LISTmovi?"Sending request: PLAY rtsp://192.168.30.41:8555/mjpeg/ RTSP/1.0 CSeq: 6 User-Agent: ./openRTSP (LIVE555 Streaming Media v2011.05.25) Session: 50 Range: npt=0.000- Received a complete PLAY response: RTSP/1.0 200 OK CSeq: 6 Date: Thu, Jun 16 2011 11:33:07 GMT Range: npt=0.000- Session: 50 RTP-Info: url=rtsp://192.168.30.41:8555/mjpeg/track1;seq=37853;rtptime=2535217148,url=rtsp://192.168.30.41:8555/mjpeg/track2;seq=10945;rtptime=3751685148 Started playing session Receiving streamed data (signal with "kill -HUP 1570" or "kill -USR1 1570" to terminate)... 00dc?&????JFIF??T??C ' .)10.)-,3:J>36F7,- at WAFLNRSR2>ZaZP`JQRO??C&&O5-5OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO?`?"?? ???}!1AQa"q2??#B??R??$3br? %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz??????????????????????????????????????????????????????????????????????????? ???w!1AQaq"2B???? #3R?br? $4?%?&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz?????????????????????????????????????????????????????????????????????????? From finlayson at live555.com Thu Jun 16 07:27:19 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 16 Jun 2011 07:27:19 -0700 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> Message-ID: > > You already know that "openRTSP -t" - built from the supplied, >unmodified source code - works OK on your system. > >I have to correct my statement. Sorry! > >I get only first image with: > >./openRTSP -t -F ______Video rtsp://193.158.57.66:8555/mjpeg You probably got a very large video file, which contains all JPEG frames, in sequence. A viewer application will likely show only the first JPEG frame - but you probably got all of them. You should also have gotten a MPEG audio file, which you should be able to play. >If I wont to write .avi, I find nothing in testProgs directory That's because the "-i" option outputs an AVI-format file to stdout. You'll need to redirect it to a file, i.e. ./openRTSP -i -t > test.avi But, I would not have high expectations about being able to play the resulting file. The "-i" option (AVI file writing) is very unreliable. In any case, if you get two large files - audio and video - when you run "openRTSP -t", then it's working OK. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Autuori.Gianluigi.Wintime at ansaldobreda.it Fri Jun 17 03:26:19 2011 From: Autuori.Gianluigi.Wintime at ansaldobreda.it (Autuori Gianluigi) Date: Fri, 17 Jun 2011 12:26:19 +0200 Subject: [Live-devel] R: how to capture H264 stream and save it in a avifile References: Message-ID: Hi James, I can't use -i option with -4 option... could you make me an example of use with openRTSP Thanks Gianluigi _____ Da: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Per conto di James Dougherty Inviato: venerd? 13 maggio 2011 0.46 A: LIVE555 Streaming Media - development & use Oggetto: Re: [Live-devel] how to capture H264 stream and save it in a avifile Hi Gianluigi, Please provide the -i option and review the options on the main site, below: http://www.live555.com/openRTSP/#quicktime Those options all work for me, and very well! Here is another recipe I use for additional cross-validation. If you have L16 media, put a riff header on it: sox -B -t raw -s -b 16 -c 2 -r 48k audio-L16-2 audio-L16-2.wav For MP4 (openRTSP -4 option): mp4box -fps 30 -add video-H264-1.264 -add audio-L16-2.wav -new myfile.mp4 For AVI (openRTSP -i option) ffmpeg -r 30 -i video-H264-1 -i audio-L16-2.wav -vcodec copy -acodec copy myfile.avi I use the openRTSP options, but at times, I have used the above to verify I didn't break something :-) YMMV best regards -james On Wed, May 11, 2011 at 6:53 AM, Autuori Gianluigi wrote: Hello, I'm trying to capture a video stream from Axis IP camera with openRTSP. I get a correct file if I use: openRTSP -d 20 -4 -f 3 -w 640 -h 480 -b 400000 "rtsp://10.10.1.61/axis-media/media.amp?compression=35&fps=3" >video.avi but I try this: openRTSP -d 20 -f 3 -w 640 -h 480 -b 400000 "rtsp://10.10.1.61/axis-media/media.amp?compression=35&fps=3" I obtain this file: video-H264-1 but I can't open it. What is wrong? I read this post: http://lists.live555.com/pipermail/live-devel/2007-January/005886.html is it the same problem? thanks Gianluigi _____ Questo messaggio e-mail e ogni documento ad esso eventualmente allegato puo' avere carattere riservato ed essere tutelato da segreto. Esso,comunque, e' ad esclusivo utilizzo del destinatario in indirizzo. Qualora non foste il destinatario del messaggio vi preghiamo di volerci avvertire immediatamente per e-mail o telefono e di cancellare il presente messaggio e ogni eventuale allegato dal vostro sistema. E' vietata la duplicazione o l'utilizzo per qualunque fine del messaggio e di ogni allegato, nonche' la loro divulgazione, distribuzione o inoltro a terzi senza l'espressa autorizzazione del mittente. In ragione del mezzo di trasmissione utilizzato, il mittente non assume alcuna responsabilita' sulla segretezza/riservatezza delle informazioni contenute nel messaggio e nei relativi allegati. This e-mail and any file transmitted with it may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. If you are not the intended recipient of this e-mail, please do not read it, notify us immediately by e-mail or by telephone and then delete this message and any file attached from your system. You should not copy or use it for any purpose, disclose the contents of the same to any other person or forward it without express permission. Considering the means of transmission, we do not undertake any liability with respect to the secrecy and confidentiality of the information contained in this e-mail and its attachments. _______________________________________________ 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 piotr.piwko at gmail.com Sat Jun 18 02:32:23 2011 From: piotr.piwko at gmail.com (Piotr Piwko) Date: Sat, 18 Jun 2011 11:32:23 +0200 Subject: [Live-devel] RTSP server and MediaSource input Message-ID: Hello, I would like to develop the RTSP server using MediaSource object as a input. In order to do that I base on the "testOnDemandRTSPServer" example where the file is used as the input stream. Do you know any hints or possibilities to create MediaSubsession which will be based on MediaSource instead of conventional file? I've found one hint about MPEG2TransportFileServerMediaSubsession::createNewStreamSource(), but to be honest I can't find out how to provide the FramedSource object to it. Thank you in advance for your engagement. -- Piotr Piwko http://www.embedded-engineering.pl/ From finlayson at live555.com Sat Jun 18 02:45:17 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 18 Jun 2011 02:45:17 -0700 Subject: [Live-devel] RTSP server and MediaSource input In-Reply-To: References: Message-ID: >I would like to develop the RTSP server using MediaSource object as a >input. In order to do that I base on the "testOnDemandRTSPServer" >example where the file is used as the input stream. Do you know any >hints or possibilities to create MediaSubsession which will be based >on MediaSource instead of conventional file? Yes, read the FAQ (as you were asked to do before posting to the mailing list :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From renaud.guezennec.ext at valeo.com Mon Jun 20 06:08:18 2011 From: renaud.guezennec.ext at valeo.com (Renaud GUEZENNEC) Date: Mon, 20 Jun 2011 15:08:18 +0200 Subject: [Live-devel] Second connection fails Message-ID: Hi all, At the first connection every thing seems fine but then I stop the connection with teardown message. Then I start again my client and I'm getting : "OPTIONS send() failed: Broken pipe" I guess this error comes from the fact that the socket of my rtsp_client has not been clean but I don't know how to do it. Should I create a new one or there is function into the rtsp client to clean up socket stuff ? Regards Renaud This e-mail message is intended only for the use of the intended recipient(s). The information contained therein may be confidential or privileged, and its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please return it immediately to its sender at the above address and destroy it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From socbar at gmail.com Mon Jun 20 04:46:13 2011 From: socbar at gmail.com (Sokratis) Date: Mon, 20 Jun 2011 13:46:13 +0200 Subject: [Live-devel] live-devel Digest, Vol 92, Issue 19 In-Reply-To: References: Message-ID: Thank you Ross for your response. I didn't explain myself earlier as I should. I have already read the FAQ of course before posting. I have understood that I have to create my own createNewStreamSource in a new myH264VideoFileServerMediaSubsession. My questions is, which is the simplest way to change the input and instead of reading from file, just give as input a data buffer uint8_t *. I guess I will have to change ByteStreamFileSource:createNew , right? That means ByteStreamFileSource::doReadFromFile ? For example putting into doReadFromFile input parameters a data buffer, and call it from my code? Does what I think make sense? Do you have to suggest something faster and easier? Thank you again and sorry for my previous vague post. Sokratis > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Jun 2011 21:34:20 -0700 > From: Ross Finlayson > To: LIVE555 Streaming Media - development & use > > Subject: Re: [Live-devel] stream from data pointer, not file > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > >I want to stream the data included in > > > >nal[0].p_payload (the variable is uint8_t *p_payload) which is > >output of x264 encoding. I want to stream each byte after it gets > >out of the encoder. > >I am using testOnDemandRTSPServer (because I want unicast). > >Which is the simplest way to do it? > > You could start by reading the FAQ, as you were asked to do before > posting to the mailing list. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From developpeur02 at kafemeeting.com Mon Jun 20 07:32:10 2011 From: developpeur02 at kafemeeting.com (Rodolophe Fouquet) Date: Mon, 20 Jun 2011 16:32:10 +0200 Subject: [Live-devel] About forward error correction. Message-ID: Hello, I'm working on a streaming application with a network part based on your live 555 library. And I'm wondering if your library provides a FEC system, especially the Reed-Solomon algorithm (another maybe ok). Otherwise, we may use feclib within live 555, but it sounds a bit tricky. Rodolphe Fouquet, Kafemeeting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 20 08:10:40 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Jun 2011 08:10:40 -0700 Subject: [Live-devel] About forward error correction. In-Reply-To: References: Message-ID: >I'm working on a streaming application with a network part based on >your live 555 library. And I'm wondering if your library provides a >FEC system No it doesn't - sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jun 20 18:13:01 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Jun 2011 18:13:01 -0700 Subject: [Live-devel] stream from data pointer, not file In-Reply-To: References: Message-ID: >Thank you Ross for your response. I didn't explain myself earlier as >I should. I have already read the FAQ of course before posting. Well, I'm not sure that you read http://www.live555.com/liveMedia/faq.html#liveInput and http://www.live555.com/liveMedia/faq.html#liveInput-unicast which address your question. >I have understood that I have to create my own createNewStreamSource >in a new myH264VideoFileServerMediaSubsession. My questions is, >which is the simplest way to change the input and instead of reading >from file, just give as input a data buffer uint8_t *. Define your own subclass of "FramedSource" (perhaps based on the "DeviceSource" model), and create an instance of this subclass to encapsulate your data buffer. > I guess I will have to change ByteStreamFileSource:createNew , right? WRONG! You do not need to change the supplied code! (The "ByteStreamFileSource" code works perfectly well, as is. However, you won't be using that class.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jun 20 19:18:13 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 20 Jun 2011 19:18:13 -0700 Subject: [Live-devel] Second connection fails In-Reply-To: References: Message-ID: >At the first connection every thing seems fine but then I stop the >connection with teardown message. Then I start again my client and >I'm getting :p, li { white-space: pre-wrap; } > >"OPTIONS send() failed: Broken pipe" > > >I guess this error comes from the fact that the socket of my >rtsp_client has not been clean but I don't know how to do it. Should >I create a new one or there is function into the rtsp client to >clean up socket stuff ? It wasn't quite clear from your message what you're trying to do, but (in any case) you should use a different "RTSPClient" object for each new stream that you're requesting (even from the same server). "RTSPClient" was not designed to handle more than one stream in succession. I.e., you should call Medium::close() on your first "RTSPClient" object, then create a new one using RTSPClient::createNew() for your next stream. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From developpeur02 at kafemeeting.com Wed Jun 22 05:35:53 2011 From: developpeur02 at kafemeeting.com (Rodolophe Fouquet) Date: Wed, 22 Jun 2011 14:35:53 +0200 Subject: [Live-devel] About forward error correction. In-Reply-To: References: Message-ID: Well, so, do you know where the UDP socket is used and initialized in the library? I guess I should modify the UDP socket usage to make FecEncode+UDPsend and UDPreceive+FecDecode. Rodolphe Fouquet. 2011/6/20 Ross Finlayson > I'm working on a streaming application with a network part based on your >> live 555 library. And I'm wondering if your library provides a FEC system >> > > No it doesn't - sorry. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > ______________________________**_________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/**mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.myers at panogenics.com Fri Jun 24 02:27:14 2011 From: david.myers at panogenics.com (David J Myers) Date: Fri, 24 Jun 2011 10:27:14 +0100 Subject: [Live-devel] RTSP Server crash on TEARDOWN Message-ID: <002501cc3250$e806e440$b814acc0$@myers@panogenics.com> Hi, I've been trying to get my RTSP server working, getting desperate now. It's a unicast live server for embedding in my IP camera. It's based on sub-classing the FramedSource class and it uses a Linux pipe to get the frames into the streams from the application thread. The camera is pretty ambitious in that it can generate up to 14 different simultaneous video streams, so I have this many streams and substreams added but not always active or being viewed. The server is basically working and I can connect via a client such as VLC. However, when I click on Stop in the client, which sends a TEARDOWN command, my server crashed with a SIGPIPE error. I've built my app with a debug version of Live555 and managed to get the following debug trace. However on SIGPIPE, Eclipse (my IDE) can't give me a stack trace. It looks like the crash is somewhere in RTPInterface.cpp, sendRTPOverTCP. Maybe the socket has been closed under my feet. Anyway, here's the debug trace, thanks in advance for any advice. DavidJ sendRTPOverTCP: 1448 bytes over channel 0 (socket 35) sendRTPOverTCP: completed sendRTPOverTCP: 1096 bytes over channel 0 (socket 35) sendRTPOverTCP: completed Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:T Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:E Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:A Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:R Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:D Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:O Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:W Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:N Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:r Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:t Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:s Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:p Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:/ Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:/ Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:1 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:0 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:. Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:2 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:6 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:. Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:7 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:. Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:2 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:8 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:4 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:/ Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:s Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:t Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:r Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:e Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:a Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:m Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:1 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:/ Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:R Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:T Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:S Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:P Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:/ Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:1 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:. Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:0 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:C Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:S Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:e Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:q Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:6 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:U Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:s Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:e Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:r Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:- Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:A Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:g Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:e Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:n Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:t Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:L Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:i Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:b Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:V Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:L Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:C Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:/ Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:1 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:. Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:1 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:. Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:1 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:0 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:( Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:L Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:I Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:V Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:E Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:S Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:t Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:r Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:e Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:a Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:m Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:i Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:n Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:g Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:M Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:e Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:d Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:i Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:a Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:v Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:2 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:0 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:1 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:1 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:. Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:0 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:. Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:2 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:) Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:S Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:e Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:s Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:s Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:i Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:o Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:n Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes: Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:5 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:C Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:8 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:C Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:0 Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:E Liveness indication from client at 10.26.7.81 RTSPClientSession[0x104ca0]::handleRequestBytes() read 1 new bytes:D sendRTPOverTCP: 1448 bytes over channel 0 (socket 35) sendRTPOverTCP: completed sendRTPOverTCP: 1448 bytes over channel 0 (socket 35) *******SIGPIPE happens here****************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerard at streamit.eu Fri Jun 24 02:58:06 2011 From: gerard at streamit.eu (Gerard Hollemans) Date: Fri, 24 Jun 2011 11:58:06 +0200 Subject: [Live-devel] "Discarding interleaved RTP or RTCP packet" between GET_PARAMETER request and response Message-ID: <009b01cc3255$37326400$a5972c00$@eu> Hi, I run into "Discarding interleaved RTP or RTCP packet" leading to visual distortions even though the video server correctly responds to the GET_PARAMETER request immediately before the discarding of the packets. How can this be solved? Let me elaborate: We use Wowza Media Server, latest version and tuned according to the vendors recommendations. This streams to (among others) a VLC client (1.0.6 Goldeneye) running on Ubuntu Linux (10.04) that uses Live555 (v2010.02.10) to play the stream. There are frequent visual distortions that are time-correlated to the moment that Live555 posts a GET_PARAMETER request to the stream server. The log file extract below shows that the client sends the request to the server, the server responds to the client correctly (see also http://www.ietf.org/rfc/rfc2326.txt, section 10.8). Nevertheless, packets are discarded: "Discarding interleaved RTP or RTCP packet (1140 bytes, channel id 0)". The number of packets that is discarded, differs per occassion. Note that packet are only discarded between the request and the response (as they appear in the log file). Wireshark logging and testing with other players show that the stream and the internet connection are fine. Please provide me a solution to prevent Live555 from dropping packets in the described situation. Kind regards, Gerard Hollemans --- LOG FILE EXTRACT: Sending request: GET_PARAMETER rtsp://www.viddist.nl:1935/live/_definst_/streamit/stream1.sdp/ RTSP/1.0 CSeq: 19 Session: 925629582 User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Discarding interleaved RTP or RTCP packet (1140 bytes, channel id 0) Discarding interleaved RTP or RTCP packet (1140 bytes, channel id 0) Discarding interleaved RTP or RTCP packet (1140 bytes, channel id 0) Received GET_PARAMETER response: RTSP/1.0 200 OK Session: 925629582;timeout=60 Supported: play.basic, con.persistent Cseq: 19 Server: Wowza Media Server 2.1.2.02 build25301 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jun 24 07:14:33 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 24 Jun 2011 07:14:33 -0700 Subject: [Live-devel] "Discarding interleaved RTP or RTCP packet" between GET_PARAMETER request and response In-Reply-To: <009b01cc3255$37326400$a5972c00$@eu> References: <009b01cc3255$37326400$a5972c00$@eu> Message-ID: >I run into "Discarding interleaved RTP or RTCP packet" leading to >visual distortions even though the video server correctly responds >to the GET_PARAMETER request immediately before the discarding of >the packets. How can this be solved? You can start by upgrading your client to use an up-to-date version of the "LIVE555 Streaming Media" code: >a VLC client (1.0.6 Goldeneye) running on Ubuntu Linux (10.04) that >uses Live555 (v2010.02.10) Sorry, but no support is given for old versions of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jun 24 07:46:31 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 24 Jun 2011 07:46:31 -0700 Subject: [Live-devel] RTSP Server crash on TEARDOWN In-Reply-To: <002501cc3250$e806e440$b814acc0$@myers@panogenics.com> References: <002501cc3250$e806e440$b814acc0$@myers@panogenics.com> Message-ID: >The server is basically working and I can connect via a client such >as VLC. However, when I click on Stop in the client, which sends a >TEARDOWN command, my server crashed with a SIGPIPE error. I've built >my app with a debug version of Live555 and managed to get the >following debug trace. However on SIGPIPE, Eclipse (my IDE) can't >give me a stack trace. It looks like the crash is somewhere in >RTPInterface.cpp, sendRTPOverTCP. Maybe the socket has been closed >under my feet. Well, the server code implements the RTSP "TEARDOWN" command by deleting the "RTSPServer::RTSPClientSession" object. Perhaps your subclass[*] of "RTSPServer::RTSPClientSession" is deleting your pipe's endpoint socket? If this pipe is a property of the data being streamed, rather than a particular client, then it should really be associated with your "ServerMediaS(ubs)ession" subclass[*], rather than with the "RTSPServer::RTSPClientSession". [*] I say *subclass* because, as you know, you should not be modifying the supplied source code at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From piotr.piwko at gmail.com Sun Jun 26 05:03:07 2011 From: piotr.piwko at gmail.com (Piotr Piwko) Date: Sun, 26 Jun 2011 14:03:07 +0200 Subject: [Live-devel] DeviceSource and RTSP server Message-ID: Hello, I have written the my own DeviceSource class which receives data from real-time video input. My goal is to stream data via RTSP server, so in order to achieve this, I created *MediaSubsession implementation which is used as it is presented in testOnDemandRTSPServer demo. *MediaSubsession::createNewStreamSource() creates the instance of DeviceSource object, so every client has its own instance of input source. This approach exists in FileServerMediaSubsession class, so I suppose it is correct. If there is only one client connected everything is going good, but when the another client will connect, the first instance of DeviceSource doesn't get any data (deliverFrame() and doGetNextFrame() will not be executed) and only current instance is executed. How can I force executing of all DeviceSource instances? Thank in advance for any hints. -- Piotr Piwko http://www.embedded-engineering.pl/ From finlayson at live555.com Sun Jun 26 07:48:10 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 26 Jun 2011 07:48:10 -0700 Subject: [Live-devel] DeviceSource and RTSP server In-Reply-To: References: Message-ID: >If there is only one client connected everything is going good, but >when the another client will connect, the first instance of >DeviceSource doesn't get any data (deliverFrame() and doGetNextFrame() >will not be executed) and only current instance is executed. How can I >force executing of all DeviceSource instances? Actually, you have this backwards. Because you are streaming from a live input source, you want only one instance of your "DeviceSource" class to be created at a time, even if more than one client is connecting concurrently. To do this, make sure that the constructor of your "OnDemandServerMediaSubsession" subclass sets the "reuseFirstSource" parameter to True, when it calls the "OnDemandServerMediaSubsession" (i.e., its parent class) constructor. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From piotr.piwko at gmail.com Sun Jun 26 08:59:52 2011 From: piotr.piwko at gmail.com (Piotr Piwko) Date: Sun, 26 Jun 2011 17:59:52 +0200 Subject: [Live-devel] DeviceSource and RTSP server In-Reply-To: References: Message-ID: 2011/6/26 Ross Finlayson : > Actually, you have this backwards. ?Because you are streaming from a live > input source, you want only one instance of your "DeviceSource" class to be > created at a time, even if more than one client is connecting concurrently. All right, I've moved the initialization of DeviceSource and needed framer object outside *MediaSubsession implementation. I'm not sure what exactly the createNewStreamSource() function shall contain in this case. I suppose that it should just return the pointer to global input framer, but it doesn't work properly. I don't know why the ~DeviceSource() is called after createNewRTPSink() execution. Thank you for your valuable replies. -- Piotr Piwko http://www.embedded-engineering.pl/ From finlayson at live555.com Sun Jun 26 12:35:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 26 Jun 2011 12:35:20 -0700 Subject: [Live-devel] DeviceSource and RTSP server In-Reply-To: References: Message-ID: >2011/6/26 Ross Finlayson : >> Actually, you have this backwards. Because you are streaming from a live >> input source, you want only one instance of your "DeviceSource" class to be >> created at a time, even if more than one client is connecting concurrently. > >All right, I've moved the initialization of DeviceSource and needed >framer object outside *MediaSubsession implementation. I'm not sure >what exactly the createNewStreamSource() function shall contain in >this case. It should do exactly the same as it always did: Create a new source object, hook it into a 'framer' (if necessary), and then return the resulting data source. However, because you set "reuseFirstSource" to True in the call to the "OnDemandServerMediaSubsession" constructor, "createNewStreamSource()" will be called just once if two or more clients are accessing the stream concurrently. However, this doesn't mean that "createNewStreamSource()" will be called *only* once. Instead, if a client begins streaming, then closes the stream, then another client begins streaming, then "createNewStreamSource() will be called twice (with a call to "~DeviceSource()" inbetween. (Also, "createNewStreamSource()" and then "~DeviceSource()" are also called to handle the very first RTSP "DESCRIBE" - so set up the stream's SDP description.) You need to be prepared for "createNewStreamSource()" and "~DeviceSource()" to be called several times, in succession. >I don't know why the >~DeviceSource() is called after createNewRTPSink() execution. See above. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From debraj.manna at yahoo.co.in Tue Jun 28 02:50:28 2011 From: debraj.manna at yahoo.co.in (DEBRAJ MANNA) Date: Tue, 28 Jun 2011 15:20:28 +0530 (IST) Subject: [Live-devel] QoS Statistics (kbits_per_second_ave) for OpenRTSP and Live555 Server Message-ID: <1309254628.85392.YahooMailNeo@web95301.mail.in2.yahoo.com> Hi, I am using OpenRTSP & Live555 in my internal network. OpenRTSP is connected to the Live555 Media Server through Linktropy WAN Emulator. I started doing a .mpg file transfer using OpenRTSP Client. I started 40 parallel connections between openRTSP & Live555 Media Server (with no other data transfer going on). I want to measure the data transfer rate for all the connections. So, I sum up the? value of 'kbits_per_second_ave' for the video and audio stream ( as reported by -Q option ) for all the 40 connections. I get around 30 Mbps. But the WAN Emulator shows around 80 Mbps data transfer.? But when I repeat the above steps with 10 parallel connections the value reported by the WAN Emulator and the sum of 'kbits_per_second_ave' for all the connections matches. Also when I use a.mp3 file containing only audio stream(with 250 parallel connections) then also both the value reported by both are same. I also verified that using WANEM(http://wanem.sourceforge.net/) in place of Linktropy WAN Emulator. It also reported the same observation. Why the values shown are different in both the cases? What is the significance of 'kbits_per_second'? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jun 28 17:01:04 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 28 Jun 2011 17:01:04 -0700 Subject: [Live-devel] QoS Statistics (kbits_per_second_ave) for OpenRTSP and Live555 Server In-Reply-To: <1309254628.85392.YahooMailNeo@web95301.mail.in2.yahoo.com> References: <1309254628.85392.YahooMailNeo@web95301.mail.in2.yahoo.com> Message-ID: >Why the values shown are different in both the cases? I don't know, but note that "kbits_per_second_ave" is computed on line 1088 of "testProgs/playCommon.cpp". Remember, You Have Complete Source Code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From matt at schuckmannacres.com Wed Jun 29 10:38:29 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Wed, 29 Jun 2011 10:38:29 -0700 Subject: [Live-devel] RTSPClient using the synchronous interface spinning on the processor Message-ID: <4E0B6315.7080001@schuckmannacres.com> I just updated my code to use the latest Live555 code and I imeadiately noticed that my RTSP client application is spinning on the processor and taking up 100% of the processor it's running on. I tried running OpenRTSP against the same server and I don't the problem. The main difference between OpenRTSP and my client is my client is still using the synchronous interface and OpenRTSP isn't. The application seems to be spinning in the taskScheduler().doEventLoop(), and or SingleStep() methods. It's almost as if Select() is always returning immediately or something like that. Did I miss something that I should have changed with my client? I did noticed that with the new synchronous interface I am nesting calls to doEventLoop(). i.e. my app cals doEventLoop() at start up and then each time I I need to send a SET_PARAMETER command the synchronous interfaces calls doEventLoop() again, Could this be the problem? I'll continue to debug and figure it out, but I appreciate any suggestions. Matt S. From matt at schuckmannacres.com Wed Jun 29 14:25:17 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Wed, 29 Jun 2011 14:25:17 -0700 Subject: [Live-devel] RTSPClient using the synchronous interface spinning on the processor In-Reply-To: <4E0B6315.7080001@schuckmannacres.com> References: <4E0B6315.7080001@schuckmannacres.com> Message-ID: <4E0B983D.3@schuckmannacres.com> Ok here's what it looks like is happening. I'm initializing the TaskScheduler, the usageEnvironment, and my RTSPClient instance and then calling TaskSchedular::doEvenLoop() without having initiated any RTSP connection (I've been doing that later after the fact via an outside signal). The first time BasicTaskScheduler::SingeStep is called the fReadSet, fWriteSet, and fExceptionSet are all empty and select() returns an error (WSAINVAL) and the code starting on line 86 of BasicTaskScheduler.cpp (did I mention I'm on Windows) gets invoked to create a dummySocket so that the error doesn't occur again. However, the problem is from then on select() will always return immediately indicating that dummySocket is ready for writing and that's why my client is spinning at 100 percent on the CPU. So I realize that I'm doing things a little different that openRTSP() but I don't think I'm doing anything wrong and my code has worked just fine for the last 2 years. Is this a bug in the library (maybe the dummySocket shouldn't be added to the fWriteSet) or should I change the way my code works? Thanks, Matt S. On 6/29/2011 10:38 AM, Matt Schuckmannn wrote: > I just updated my code to use the latest Live555 code and I > imeadiately noticed that my RTSP client application is spinning on the > processor and taking up 100% of the processor it's running on. I tried > running OpenRTSP against the same server and I don't the problem. The > main difference between OpenRTSP and my client is my client is still > using the synchronous interface and OpenRTSP isn't. > The application seems to be spinning in the > taskScheduler().doEventLoop(), and or SingleStep() methods. It's > almost as if Select() is always returning immediately or something > like that. > Did I miss something that I should have changed with my client? > > I did noticed that with the new synchronous interface I am nesting > calls to doEventLoop(). > i.e. my app cals doEventLoop() at start up and then each time I I need > to send a SET_PARAMETER command the synchronous interfaces calls > doEventLoop() again, Could this be the problem? > > I'll continue to debug and figure it out, but I appreciate any > suggestions. > > Matt S. > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From matt at schuckmannacres.com Wed Jun 29 15:14:18 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Wed, 29 Jun 2011 15:14:18 -0700 Subject: [Live-devel] Bug with RTP over TCP and sending SET_PARAMETER after streaming has started Message-ID: <4E0BA3BA.8040504@schuckmannacres.com> Looks like there is a bug in RTSPClientSession::handleRequestBytes() when SET_PARAMETER is sent to the server while streaming RTP over TCP and after the PLAY command has been issued. The problem is the code starting on or about line 422 of RTSPServer.cpp assumes that the the message is complete when a double \r\n sequence is encountered. However, in the case of SET_PARAMETER and GET_PARAMETER there is a double \r\n between the headers and the content, so this code is truncating the command. I haven't come up with a fix for this yet but I imagine that it shouldn't be to hard. FYI if your doing normal RTP over UDP there is no problem, the answer probably is to find the command handler code for that code and do the same thing for the TCP case. Matt S. From matt at schuckmannacres.com Wed Jun 29 16:03:34 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Wed, 29 Jun 2011 16:03:34 -0700 Subject: [Live-devel] Bug with RTP over TCP and sending SET_PARAMETER after streaming has started In-Reply-To: <4E0BA3BA.8040504@schuckmannacres.com> References: <4E0BA3BA.8040504@schuckmannacres.com> Message-ID: <4E0BAF46.2090405@schuckmannacres.com> Looks like the problem is more insidious than I thought. The way the code starting on line 422 of RTSPServer.cpp is written it will always assume that the message is complete when it sees the first double \r\n regardless if it's RTP over UDP or TCP. However, if the whole message comes in at once (i.e. in the same socket receive notification), including the content, then the whole message including the content will be passed on down to the proper handler method. However if the whole message doesn't come in at one time then only the part received at the time the double \r\n is detected will be passed on to the handler method. In the case of RTP over TCP and interleaving a SET_PARAMETER message with the video data already streaming the message dribbles in 1 byte at a time (I'm not sure why this is yet) and therefore the message gets passed on to the SET_PARAMETER handler method before the entire message is received. So something needs to be done to keep the message parsing going in the case of a RTSP command with a Content-length header and I think you might want to look into checking whether it's OK that the whole buffer of received data is passed on to the RTSP handing code, if the server receives a large chunk of data with a RTSP message interleaved with RTP data I think you maybe be assuming that all of that data is RTSP and end up dropping some of the RTP packet data. I'll continue to look into this for my own edification and I'll make public any suggestions I have but I assume you Ross will want to come up with your own solution, and hopefully you'll be quicker than me. Thanks, Matt S. On 6/29/2011 3:14 PM, Matt Schuckmannn wrote: > Looks like there is a bug in RTSPClientSession::handleRequestBytes() > when SET_PARAMETER is sent to the server while streaming RTP over TCP > and after the PLAY command has been issued. The problem is the code > starting on or about line 422 of RTSPServer.cpp assumes that the the > message is complete when a double \r\n sequence is encountered. > However, in the case of SET_PARAMETER and GET_PARAMETER there is a > double \r\n between the headers and the content, so this code is > truncating the command. > > I haven't come up with a fix for this yet but I imagine that it > shouldn't be to hard. > FYI if your doing normal RTP over UDP there is no problem, the answer > probably is to find the command handler code for that code and do the > same thing for the TCP case. > > Matt S. > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From d.velkin at ids-imaging.de Wed Jun 29 07:23:44 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Wed, 29 Jun 2011 16:23:44 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> Message-ID: Hi Ross, I followed your advice and start to implement with openRTSP. I need data in buffer and not in file and so i wrote little class to subclass MediaSink: class MyMediaSink:public MediaSink { public: MyMediaSink(UsageEnvironment &env):MediaSink(env){buffer = new uint8_t();} virtual ~MyMediaSink(){} protected: Boolean continuePlaying(){/*CODE will come soon*/ return true;} private: uint8_t *buffer; }; After that I invoke my Class in setupStreams()-funktion: void setupStreams() { static MediaSubsessionIterator* setupIter = NULL; if (setupIter == NULL) setupIter = new MediaSubsessionIterator(*session); while ((subsession = setupIter->next()) != NULL) { // We have another subsession left to set up: if (subsession->clientPortNum() == 0) continue; // port # was not set setupSubsession(subsession, streamUsingTCP, continueAfterSETUP); //--------------------- MyMediaSink *ms = new MyMediaSink(*env); ms->startPlaying(*(subsession->readSource()), subsessionAfterPlaying, subsession); //--------------------- return; } . . . . } I know there are leaks and the implementation of MyMediaSink is not complete, but I can see that I have the same Problem as with my App. Thank you in advance! Dmitrij Am 16.06.2011 um 16:27 schrieb Ross Finlayson: >> > You already know that "openRTSP -t" - built from the supplied, unmodified source code - works OK on your system. >> I have to correct my statement. Sorry! >> >> I get only first image with: >> >> ./openRTSP -t -F ______Video rtsp://193.158.57.66:8555/mjpeg > > You probably got a very large video file, which contains all JPEG frames, in sequence. A viewer application will likely show only the first JPEG frame - but you probably got all of them. > > You should also have gotten a MPEG audio file, which you should be able to play. > > >> If I wont to write .avi, I find nothing in testProgs directory > > > That's because the "-i" option outputs an AVI-format file to stdout. You'll need to redirect it to a file, i.e. > ./openRTSP -i -t > test.avi > But, I would not have high expectations about being able to play the resulting file. The "-i" option (AVI file writing) is very unreliable. > > In any case, if you get two large files - audio and video - when you run "openRTSP -t", then it's working OK. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 29 20:18:19 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 Jun 2011 20:18:19 -0700 Subject: [Live-devel] Bug with RTP over TCP and sending SET_PARAMETER after streaming has started In-Reply-To: <4E0BA3BA.8040504@schuckmannacres.com> References: <4E0BA3BA.8040504@schuckmannacres.com> Message-ID: Yes, the server code needs to be checking for the "Content-length" header, if present (which it will be for "GET_PARAMETER" and "SET_PARAMETER"). A fix will be coming... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From d.velkin at ids-imaging.de Wed Jun 29 23:03:03 2011 From: d.velkin at ids-imaging.de (Velkin Dmitrij) Date: Thu, 30 Jun 2011 08:03:03 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de><58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> Message-ID: <4CB3F3483954BD4ABD0B4DBB35C7E33801ECAB50@exchsrv.idszentral.local> Some additional information: I invoke open rtsp with "-i" and "-t" options and uncomment the code where you create and use AviFileSink. Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Dmitrij Velkin Gesendet: Mittwoch, 29. Juni 2011 16:24 An: LIVE555 Streaming Media - development & use Betreff: Re: [Live-devel] RTP over TCP with iPhone Hi Ross, I followed your advice and start to implement with openRTSP. I need data in buffer and not in file and so i wrote little class to subclass MediaSink: class MyMediaSink:public MediaSink { public: MyMediaSink(UsageEnvironment &env):MediaSink(env){buffer = new uint8_t();} virtual ~MyMediaSink(){} protected: Boolean continuePlaying(){/*CODE will come soon*/ return true;} private: uint8_t *buffer; }; After that I invoke my Class in setupStreams()-funktion: void setupStreams() { static MediaSubsessionIterator* setupIter = NULL; if (setupIter == NULL) setupIter = new MediaSubsessionIterator(*session); while ((subsession = setupIter->next()) != NULL) { // We have another subsession left to set up: if (subsession->clientPortNum() == 0) continue; // port # was not set setupSubsession(subsession, streamUsingTCP, continueAfterSETUP); //--------------------- MyMediaSink *ms = new MyMediaSink(*env); ms->startPlaying(*(subsession->readSource()), subsessionAfterPlaying, subsession); //--------------------- return; } . . . . } I know there are leaks and the implementation of MyMediaSink is not complete, but I can see that I have the same Problem as with my App. Thank you in advance! Dmitrij Am 16.06.2011 um 16:27 schrieb Ross Finlayson: > You already know that "openRTSP -t" - built from the supplied, unmodified source code - works OK on your system. I have to correct my statement. Sorry! I get only first image with: ./openRTSP -t -F ______Video rtsp://193.158.57.66:8555/mjpeg You probably got a very large video file, which contains all JPEG frames, in sequence. A viewer application will likely show only the first JPEG frame - but you probably got all of them. You should also have gotten a MPEG audio file, which you should be able to play. If I wont to write .avi, I find nothing in testProgs directory That's because the "-i" option outputs an AVI-format file to stdout. You'll need to redirect it to a file, i.e. ./openRTSP -i -t > test.avi But, I would not have high expectations about being able to play the resulting file. The "-i" option (AVI file writing) is very unreliable. In any case, if you get two large files - audio and video - when you run "openRTSP -t", then it's working OK. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jun 29 23:06:37 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 Jun 2011 23:06:37 -0700 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> Message-ID: > Boolean continuePlaying(){/*CODE will come soon*/ return true;} I'm not sure what your question is, but once your "MyMediaSink" class should work once you implement the "continuePlaying()" function (etc.). I suggest that you use the "FileSink" code as a model. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jun 29 23:17:08 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 29 Jun 2011 23:17:08 -0700 Subject: [Live-devel] RTSPClient using the synchronous interface spinning on the processor In-Reply-To: <4E0B983D.3@schuckmannacres.com> References: <4E0B6315.7080001@schuckmannacres.com> <4E0B983D.3@schuckmannacres.com> Message-ID: >The first time BasicTaskScheduler::SingeStep is called the fReadSet, >fWriteSet, and fExceptionSet are all empty and select() returns an >error (WSAINVAL) and the code starting on line 86 of >BasicTaskScheduler.cpp (did I mention I'm on Windows) gets invoked >to create a dummySocket so that the error doesn't occur again. >However, the problem is from then on select() will always return >immediately indicating that dummySocket is ready for writing and >that's why my client is spinning at 100 percent on the CPU. Try commenting out lines 91 and 92 of "BasicUsageEnvironment/BasicTaskScheduler.cpp" - i.e., don't add "dummySocket" to "fWriteSet" or "fExceptionSet". I'm hoping that this won't trigger the Windows bug that forced me to add "dummySocket" in the first place - i.e., I'm hoping that I need to add "dummySocket" only to "fReadSet". Please let me know if this works for you. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From d.velkin at ids-imaging.de Thu Jun 30 00:04:51 2011 From: d.velkin at ids-imaging.de (Dmitrij Velkin) Date: Thu, 30 Jun 2011 09:04:51 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> Message-ID: <1575D155-0CB3-47F9-BFE9-8E6AC90198AD@ids-imaging.de> Yes I use FileSink as model: class MyMediaSink:public MediaSink { public: MyMediaSink(UsageEnvironment &env):MediaSink(env){buffer = new uint8_t[fileSinkBufferSize];} virtual ~MyMediaSink(){} protected: Boolean continuePlaying() { if (NULL == fSource) { return False; } buffer = NULL; fSource->getNextFrame(buffer, fileSinkBufferSize, afterGettingFrame, this, onSourceClosure, this); return True; } static void afterGettingFrame(void* clientData, unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds) { MyMediaSink* sink = (MyMediaSink*)clientData; sink->afterGettingFrame1(frameSize, presentationTime); } void afterGettingFrame1(unsigned frameSize, struct timeval presentationTime) { AddData(buffer, frameSize, presentationTime); // Then try getting the next frame: continuePlaying(); } void AddData(uint8_t* pData, uint32_t nDataSize, struct timeval presentationTime) { if(pData == NULL) { printf("NO DATA"); } } private: uint8_t *buffer; }; if I implement it in this way i never get into "afterGettingFrame". What am I doing wrong? thanks! Am 30.06.2011 um 08:06 schrieb Ross Finlayson: >> Boolean continuePlaying(){/*CODE will come soon*/ return true;} > > I'm not sure what your question is, but once your "MyMediaSink" class should work once you implement the "continuePlaying()" function (etc.). I suggest that you use the "FileSink" code as a model. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jun 30 00:18:06 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 30 Jun 2011 00:18:06 -0700 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: <1575D155-0CB3-47F9-BFE9-8E6AC90198AD@ids-imaging.de> References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de> <58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de> <1575D155-0CB3-47F9-BFE9-8E6AC90198AD@ids-imaging.de> Message-ID: >if I implement it in this way i never get into "afterGettingFrame". >What am I doing wrong? I don't know; you're going to have to figure this out for yourself. Remember, you're starting from code that you know works - the "openRTSP" code. By making incremental changes to this code, and testing after each change, you should be able to figure out what's wrong. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From d.velkin at ids-imaging.de Thu Jun 30 00:40:23 2011 From: d.velkin at ids-imaging.de (Velkin Dmitrij) Date: Thu, 30 Jun 2011 09:40:23 +0200 Subject: [Live-devel] RTP over TCP with iPhone In-Reply-To: References: <53152925-1CD6-4075-9944-FA7E87C50D3D@ids-imaging.de><58E22145-6735-4011-A233-3AA78B38E819@ids-imaging.de><1575D155-0CB3-47F9-BFE9-8E6AC90198AD@ids-imaging.de> Message-ID: <4CB3F3483954BD4ABD0B4DBB35C7E33801ECABF0@exchsrv.idszentral.local> I can't change the code incremental. I have to use a new/ohther sink. And it works fine if I invoke this code without "-t" option! -----Urspr?ngliche Nachricht----- Von: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Im Auftrag von Ross Finlayson Gesendet: Donnerstag, 30. Juni 2011 09:18 An: LIVE555 Streaming Media - development & use Betreff: Re: [Live-devel] RTP over TCP with iPhone >if I implement it in this way i never get into "afterGettingFrame". >What am I doing wrong? I don't know; you're going to have to figure this out for yourself. Remember, you're starting from code that you know works - the "openRTSP" code. By making incremental changes to this code, and testing after each change, you should be able to figure out what's wrong. -- 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 From RGlobisch at csir.co.za Thu Jun 30 03:17:27 2011 From: RGlobisch at csir.co.za (Ralf Globisch) Date: Thu, 30 Jun 2011 12:17:27 +0200 Subject: [Live-devel] live-devel Digest, Vol 92, Issue 23 In-Reply-To: References: Message-ID: <4E0C695B.5DA9.004D.1@csir.co.za> Hi Matt, Interesting post about the CPU usage! FYI, we recently upgraded our live555 version too and I also noticed that my RTSP client application starts using up my processor (only after experiencing network issues where the connection seems to drop). We are also still using the synchronous version of the client and stream over TCP. I will revert our live555 version and confirm whether the issue still happens. Regards, Ralf ------------------------------ Message: 3 Date: Wed, 29 Jun 2011 10:38:29 -0700 From: Matt Schuckmannn To: live-devel at ns.live555.com Subject: [Live-devel] RTSPClient using the synchronous interface spinning onthe processor Message-ID: <4E0B6315.7080001 at schuckmannacres.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I just updated my code to use the latest Live555 code and I imeadiately noticed that my RTSP client application is spinning on the processor and taking up 100% of the processor it's running on. I tried running OpenRTSP against the same server and I don't the problem. The main difference between OpenRTSP and my client is my client is still using the synchronous interface and OpenRTSP isn't. The application seems to be spinning in the taskScheduler().doEventLoop(), and or SingleStep() methods. It's almost as if Select() is always returning immediately or something like that. Did I miss something that I should have changed with my client? I did noticed that with the new synchronous interface I am nesting calls to doEventLoop(). i.e. my app cals doEventLoop() at start up and then each time I I need to send a SET_PARAMETER command the synchronous interfaces calls doEventLoop() again, Could this be the problem? I'll continue to debug and figure it out, but I appreciate any suggestions. Matt S. -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at schuckmannacres.com Thu Jun 30 09:02:24 2011 From: matt at schuckmannacres.com (Matt Schuckmannn) Date: Thu, 30 Jun 2011 09:02:24 -0700 Subject: [Live-devel] RTSPClient using the synchronous interface spinning on the processor In-Reply-To: References: <4E0B6315.7080001@schuckmannacres.com> <4E0B983D.3@schuckmannacres.com> Message-ID: <4E0C9E10.6070404@schuckmannacres.com> Yes it works fine. Thanks, Matt S. On 6/29/2011 11:17 PM, Ross Finlayson wrote: >> The first time BasicTaskScheduler::SingeStep is called the fReadSet, >> fWriteSet, and fExceptionSet are all empty and select() returns an >> error (WSAINVAL) and the code starting on line 86 of >> BasicTaskScheduler.cpp (did I mention I'm on Windows) gets invoked to >> create a dummySocket so that the error doesn't occur again. However, >> the problem is from then on select() will always return immediately >> indicating that dummySocket is ready for writing and that's why my >> client is spinning at 100 percent on the CPU. > > Try commenting out lines 91 and 92 of > "BasicUsageEnvironment/BasicTaskScheduler.cpp" - i.e., don't add > "dummySocket" to "fWriteSet" or "fExceptionSet". I'm hoping that this > won't trigger the Windows bug that forced me to add "dummySocket" in > the first place - i.e., I'm hoping that I need to add "dummySocket" > only to "fReadSet". > > Please let me know if this works for you.