From eyal.b at mavix.com Thu Nov 1 09:30:57 2007 From: eyal.b at mavix.com (eyal.b at mavix.com) Date: Thu, 1 Nov 2007 18:30:57 +0200 Subject: [Live-devel] Memory leaks in DarwinInjector.cpp Message-ID: <001201c81ca4$9614d0e0$0a0ac8c0@mavix.net.il> Hello, I have found a few memory leaks in the injector code. 1) In the SubstreamDescriptor() constructor a variable called "rtpmapLine" gets allocated but never freed. 2) In setDestination() a MediaSession is created to help the created RTSPClient to setup its sub-sessions. This session is closed on function exit, but this cause a leak as closing the session do not free the sub-sessions' ID stings allocated by the RTSPClient for its use. These IDs are freed only by RTSPClient::teardownMediaSubsession() and RTSPClient::teardownMediaSession(). I have chosen to keep the created session as part of the Injector, and "tear down" its sub-sessions and close it in the Injector destructor. Thus (plus closing sinks and sources) enabled me to start and stop the Injector per request without causing memory leaks. Attached is the revised DarwinInjector source file. Eyal Beit-Halachmi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071101/080105d7/attachment-0001.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DarwinInjector.cpp Url: http://lists.live555.com/pipermail/live-devel/attachments/20071101/080105d7/attachment-0001.ksh From finlayson at live555.com Thu Nov 1 16:19:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Nov 2007 16:19:07 -0700 Subject: [Live-devel] Memory leaks in DarwinInjector.cpp In-Reply-To: <001201c81ca4$9614d0e0$0a0ac8c0@mavix.net.il> References: <001201c81ca4$9614d0e0$0a0ac8c0@mavix.net.il> Message-ID: Eyal, Thanks for the report. These fixes will be included in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chang.yiwen at tw.panasonic.com Fri Nov 2 01:36:31 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Fri, 2 Nov 2007 16:36:31 +0800 Subject: [Live-devel] doGetNextFrame() in H264VideoStreamFramer Message-ID: <025101c81d2b$7c5abde0$59085a0a@userd7c6bde7c0> Hi, everyone, I want to ask questions about doGetNextFrame() in H264VideoStreamFramer. 1. Should I copy "a whole frame data(a sequence of NALs of a frame)" or "a individual NAL unit" into the fTo address?? 2. Who to control to call currentNALUnitEndsAccessUnit()? When? How to detect the NAL is the last one of the frame?? Please help me... Many thanks!! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071102/9273eed7/attachment.html From finlayson at live555.com Fri Nov 2 07:06:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Nov 2007 07:06:23 -0700 Subject: [Live-devel] doGetNextFrame() in H264VideoStreamFramer In-Reply-To: <025101c81d2b$7c5abde0$59085a0a@userd7c6bde7c0> References: <025101c81d2b$7c5abde0$59085a0a@userd7c6bde7c0> Message-ID: >Hi, everyone, > >I want to ask questions about doGetNextFrame() in H264VideoStreamFramer. > >1. Should I copy "a whole frame data(a sequence of NALs of a frame)" >or "a individual NAL unit" into the fTo address?? You should copy an individual NAL unit. > >2. Who to control to call currentNALUnitEndsAccessUnit()? When? You should implement this function so that it returns True if the NAL unit that you just delivered is the last NAL unit of the frame, and False otherwise. > > How to detect the NAL is the last one of the frame?? I don't know; you're going to figure that out yourself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071102/4fbb342f/attachment.html From chang.yiwen at tw.panasonic.com Mon Nov 5 02:23:16 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Mon, 5 Nov 2007 18:23:16 +0800 Subject: [Live-devel] doGetNextFrame() in H264VideoStreamFramer Message-ID: <035c01c81f95$e24ceee0$59085a0a@userd7c6bde7c0> Hi, Ross, Thank you for answering. Do you know the maximum size of a NAL unit? In doGetNextFrame(), is it possible that size of a NAL unit exceed and to be fragmented? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071105/0461fdb7/attachment.html From akalingking at gmail.com Mon Nov 5 02:54:02 2007 From: akalingking at gmail.com (Ariel Kalingking) Date: Mon, 5 Nov 2007 18:54:02 +0800 Subject: [Live-devel] MPEG1or2VideoReceiver+DarwinInjector Message-ID: Hi Ross, In the provided MPEG1or2AudioVideoStreamerToDarwin example, is it possible to directly take an inbound stream source object instead of ByteStreamFileSource as input to MPEG1or2Demux? I am experimenting on taking the source stream in the MPEG1or2VideoReceiver and fed it to MPEG1or2Demux, but I'm not able to extract the original video stream in the Darwin Server. Here's the flow of what i'm doing, let me know where I could be doing wrong. MPEG1or2VideoStreamer ------->MPEG1or2VideoReceiver|MPEG1or2AudioVideoStreamerToDarwin---->DarwinServer Thanks, Ariel Kalingking From finlayson at live555.com Mon Nov 5 04:20:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Nov 2007 04:20:40 -0800 Subject: [Live-devel] doGetNextFrame() in H264VideoStreamFramer In-Reply-To: <035c01c81f95$e24ceee0$59085a0a@userd7c6bde7c0> References: <035c01c81f95$e24ceee0$59085a0a@userd7c6bde7c0> Message-ID: >Do you know the maximum size of a NAL unit? Sorry, no. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071105/72992161/attachment.html From finlayson at live555.com Mon Nov 5 04:29:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Nov 2007 04:29:23 -0800 Subject: [Live-devel] MPEG1or2VideoReceiver+DarwinInjector In-Reply-To: References: Message-ID: >MPEG1or2VideoStreamer >------->MPEG1or2VideoReceiver|MPEG1or2AudioVideoStreamerToDarwin---->DarwinServer The problem here is that "testMPEG1or2AudioVideoToDarwin" takes a MPEG *Program Stream* as input, but the data output by "testMPEG1or2VideoReceiver" is a MPEG Video *Elementary Stream". If you want to stream a MPEG (1 or 2) Video Elementary Stream to a Darwin Server, then you would need to write your own application (modeled after the existing applications) that does thie. REMEMBER, HOWEVER: We have our own RTSP server implementation (see, for example, "testOnDemandRTSPServer"). You don't need to use a separate 'Darwin' server at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From cshumway at airvisual.com Mon Nov 5 07:30:26 2007 From: cshumway at airvisual.com (Christopher Shumway) Date: Mon, 5 Nov 2007 10:30:26 -0500 Subject: [Live-devel] Create and Handle Custom RTSP Response Message-ID: <9A46651B1CC1FF4DB6275ACD19773C6A28B77B@airvisual1.airvisual.net> Hello, I've had great success working with the information and feedback provided on this devel post. I've created a live555 media server which extends the DeviceSource class with one of my own (reads MPEG-4 frames off DVR). Thank you all! The remaining piece of the puzzle for me deals with a web client that I have written that provides interaction with the live stream. I am trying to get a timestamp back from the media server to the client, and ultimately available to a Javascript function on the page. I can formulate a RTSP request from the client in the form of a URL that triggers an internal method in the media server which provides the current timestamp. How can I get this time stamp back to the client? I'm working on trying to "send" back a response w/ the timestamp via the RTSP session - but having difficulty with how to manage/receive this with my client. I am using the VLC ActiveX control as the player, and using Javascript to interact with it. (I'd rather not have to delve into the source code of VLC in order to handle this). I'm totally open to "that sounds crazy, try it this way..." approaches as well. Thanx again, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071105/791a9ab8/attachment.html From finlayson at live555.com Mon Nov 5 16:20:51 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Nov 2007 16:20:51 -0800 Subject: [Live-devel] Create and Handle Custom RTSP Response In-Reply-To: <9A46651B1CC1FF4DB6275ACD19773C6A28B77B@airvisual1.airvisual.net> References: <9A46651B1CC1FF4DB6275ACD19773C6A28B77B@airvisual1.airvisual.net> Message-ID: >The remaining piece of the puzzle for me deals with a web client >that I have written that provides interaction with the live stream. >I am trying to get a timestamp back from the media server to the >client, and ultimately available to a Javascript function on the >page. I can formulate a RTSP request from the client in the form of >a URL that triggers an internal method in the media server which >provides the current timestamp. How can I get this time stamp back >to the client? What exactly is this "timestamp" supposed to be? You realize, I hope, that every RTP packet sent by the server (and received by the client) already has a timestamp, which gets mapped to an accurate "presentation time" that the client software (e.g., VLC) sees. > I'm working on trying to "send" back a response w/ the timestamp >via the RTSP session If you're trying to do something that's outside the RTSP/RTP/RTCP standard, then this probably isn't a good idea. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071105/0bfb495b/attachment-0001.html From chang.yiwen at tw.panasonic.com Mon Nov 5 16:44:22 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Tue, 6 Nov 2007 08:44:22 +0800 Subject: [Live-devel] doGetNextFrame() in H264VideoStreamFramer Message-ID: <000f01c8200e$2d780350$59085a0a@userd7c6bde7c0> The said NAL unit's format indicates a NAL unit stream or byte stream? Or both is ok? If our NAL unit is byte stream format, should I extract NAL unit from the byte stream? Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071105/5fe9d100/attachment.html From akalingking at gmail.com Mon Nov 5 19:25:28 2007 From: akalingking at gmail.com (Ariel Kalingking) Date: Tue, 6 Nov 2007 11:25:28 +0800 Subject: [Live-devel] MPEG1or2VideoReceiver+DarwinInjector In-Reply-To: References: Message-ID: Thanks Ross that is very insightful and realized what I really wanted to process is a Program Stream. I could use the testOnDemandRTSPServer or testMPEG1or2AudioVideoStreamer as my simulated stream source instead of MPEG1or2VideoStreamer. However I could not seem to find a counterpart example the receiver code. I have looked at openRTSP but I think there are still missing parts. Could you please point me where else in the library or examples I could further use as reference to be able to write a Program Stream receiver. Thanks, Ariel Kalingking From techuan at gmail.com Mon Nov 5 20:03:39 2007 From: techuan at gmail.com (Te-Chuan Chang) Date: Tue, 6 Nov 2007 12:03:39 +0800 Subject: [Live-devel] RTSP Client - ANNOUNCE Message-ID: Hello everyone, I would like to ask a question about how to let the RTSP Client can receive the ANNOUNCE message from RTSP Server. The Server will send out an end-of-stream information by ANNOUNCE to inform the client this session will close soon. Thanks & Regards, Techuan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071105/31993df1/attachment.html From finlayson at live555.com Mon Nov 5 21:47:59 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Nov 2007 21:47:59 -0800 Subject: [Live-devel] MPEG1or2VideoReceiver+DarwinInjector In-Reply-To: References: Message-ID: >Thanks Ross that is very insightful and realized what I really wanted >to process is a Program Stream. I could use the testOnDemandRTSPServer >or testMPEG1or2AudioVideoStreamer as my simulated stream source >instead of MPEG1or2VideoStreamer. However I could not seem to find a >counterpart example the receiver code. MPEG Program Streams are streamed - via RTP - as two separate RTP streams: one for video; one for audio. Receiviing clients (such as "openRTSP" or "VLC") will receive each of these streams separately. There is currently no support in our libraries for combining these incoming Elementary Streams into a new Program Stream. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 5 21:49:32 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Nov 2007 21:49:32 -0800 Subject: [Live-devel] RTSP Client - ANNOUNCE In-Reply-To: References: Message-ID: >Hello everyone, > >I would like to ask a question about how to let the RTSP Client can >receive the ANNOUNCE message from RTSP Server. It can't - because the RTSP "ANNOUNCE" command is sent from the client to the server, rather than vice versa. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 5 22:11:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Nov 2007 22:11:40 -0800 Subject: [Live-devel] RTSP Client - ANNOUNCE Message-ID: >Hello everyone, > >I would like to ask a question about how to let the RTSP Client can >receive the ANNOUNCE message from RTSP Server. I stand corrected. I looked at the RTSP 1.0 specification once again, and see that it does, in fact, allow for "ANNOUNCE" to be sent from the server to the client. However, our libraries do not support this (at either the server or client level). The "ANNOUNCE" command is not widely implemented. Because of this, it has been removed from the RTSP 2.0 specification. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From cshumway at airvisual.com Tue Nov 6 05:58:03 2007 From: cshumway at airvisual.com (Christopher Shumway) Date: Tue, 6 Nov 2007 08:58:03 -0500 Subject: [Live-devel] Create and Handle Custom RTSP Response In-Reply-To: References: <9A46651B1CC1FF4DB6275ACD19773C6A28B77B@airvisual1.airvisual.net> Message-ID: <9A46651B1CC1FF4DB6275ACD19773C6A28B7A2@airvisual1.airvisual.net> The timestamp is actually embedded in the MPEG-4 header and represents the historic time the frame was captured. It sounds like I shouldn't get too tricky with the RTSP/RTP/RTCP return/response commands. Thank you, Chris ________________________________ From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, November 05, 2007 7:21 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Create and Handle Custom RTSP Response The remaining piece of the puzzle for me deals with a web client that I have written that provides interaction with the live stream. I am trying to get a timestamp back from the media server to the client, and ultimately available to a Javascript function on the page. I can formulate a RTSP request from the client in the form of a URL that triggers an internal method in the media server which provides the current timestamp. How can I get this time stamp back to the client? What exactly is this "timestamp" supposed to be? You realize, I hope, that every RTP packet sent by the server (and received by the client) already has a timestamp, which gets mapped to an accurate "presentation time" that the client software (e.g., VLC) sees. I'm working on trying to "send" back a response w/ the timestamp via the RTSP session If you're trying to do something that's outside the RTSP/RTP/RTCP standard, then this probably isn't a good idea. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071106/73e5bb1c/attachment.html From finlayson at live555.com Tue Nov 6 07:08:33 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 6 Nov 2007 07:08:33 -0800 Subject: [Live-devel] Create and Handle Custom RTSP Response In-Reply-To: <9A46651B1CC1FF4DB6275ACD19773C6A28B7A2@airvisual1.airvisual.net> References: <9A46651B1CC1FF4DB6275ACD19773C6A28B77B@airvisual1.airvisual.net> <9A46651B1CC1FF4DB6275ACD19773C6A28B7A2@airvisual1.airvisual.net> Message-ID: >The timestamp is actually embedded in the MPEG-4 header and >represents the historic time the frame was captured. If it's part of the MPEG-4 data for each frame, then it will be part of the RTP payload for that frame, and will be received by the client that way. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071106/1c2b7e90/attachment.html From mail at oliroll.de Tue Nov 6 21:48:24 2007 From: mail at oliroll.de (Oliver Roll) Date: Wed, 07 Nov 2007 06:48:24 +0100 Subject: [Live-devel] RTP over SCTP Message-ID: <473151A8.1030605@oliroll.de> Hello everybody, I want to replace RTP/UDP with RTP/SCTP in LiveMedia. Has anybody done this before and would give me some tips or share his code? Thanks & regards, Oliver From Fabrice.Aeschbacher at siemens.com Thu Nov 8 01:34:34 2007 From: Fabrice.Aeschbacher at siemens.com (Aeschbacher, Fabrice) Date: Thu, 8 Nov 2007 10:34:34 +0100 Subject: [Live-devel] Read 2 video streams from 2 different multicast address on the same port In-Reply-To: <473151A8.1030605@oliroll.de> Message-ID: Hi, We have a multithreaded application (using live555 / linux) acquiring many video streams (RTP/multicast) and displaying them on differents video outputs (monitors). Under circumstances, some of our customers want to use for their video sources two different multicast addresses (let's say 239.61.87.46 and 239.61.87.46), but the same port (say 8000) Unfortunately, when reading the two RTP streams, live555 seems to mix the two streams into one. I wrote a small test program to try to reproduce this error: one multicast_reader(ip,port), one multicast_writer(ip, port,text). I started the following test: $ multicast_reader 239.61.87.46 8000 $ multicast_reader 239.61.87.47 8000 $ multicast_writer 239.61.87.46 8000 "hello, world!" and effectively, the two multicast readers become the same datagram. The raison for this is the following lines in the reader's code: saddr.sin_family = PF_INET; saddr.sin_port = htons(port); // Following DOES NOT work as expected: the socket will become datagrams from // ALL multicast addresses on the same port saddr.sin_addr.s_addr = htonl(INADDR_ANY); // bind socket to any interface status = bind(sock, (struct sockaddr *)&saddr, sizeof(struct sockaddr_in)); The solution is not to bind with INADDR_ANY, but with the desired multicast address: // Whereas following works: socket will only see datagrams from 'multicast_addr' saddr.sin_addr.s_addr = inet_addr(multicast_addr); status = bind(sock, (struct sockaddr *)&saddr, sizeof(struct sockaddr_in)); With this small modification in the reader's code, the test runs as expected: every reader becomes only the datagrams for its multicast address. Now, the problem is to try to do the same with live555 library. The socket for the reader is created in setupDatagramSocket(): MAKE_SOCKADDR_IN(name, ReceivingInterfaceAddr, port.num()); if (bind(newSocket, (struct sockaddr*)&name, sizeof name) != 0) { ... By default, ReceivingInterfaceAddr is INADDR_ANY: that's why we get the two video streams mixed on the video output. The problem is that ReceivingInterfaceAddr is a global variable. We would need here one different value (i.e. multicast address) for each reader. Could you give me some advise here to help me with this issue? Best regards, Fabrice Aeschbacher From finlayson at live555.com Thu Nov 8 02:11:30 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Nov 2007 02:11:30 -0800 Subject: [Live-devel] Read 2 video streams from 2 different multicast address on the same port In-Reply-To: References: Message-ID: >We have a multithreaded application (using live555 / linux) I hope you've read the FAQ about threads. >Under circumstances, some of our customers want to use for their video >sources two different multicast addresses (let's say 239.61.87.46 and >239.61.87.46) FWIW, those are the same multicast address :-) >, but the same port (say 8000) This is a bad idea, as you discovered. >Unfortunately, when reading the two RTP streams, live555 seems to mix >the two streams into one. This is usually an operating system problem. Some OSs do not handle this (different multicast addresses using the same port number) properly. That's why it's a bad idea to use the same port number with different multicast addresses. >The solution is not to bind with INADDR_ANY, but with the desired >multicast address: > > // Whereas following works: socket will only see datagrams from >'multicast_addr' > saddr.sin_addr.s_addr = inet_addr(multicast_addr); > status = bind(sock, (struct sockaddr *)&saddr, sizeof(struct >sockaddr_in)); No, that's not the way bind() is supposed to work (if it works at all for you, then it's only by accident, I think). I've never before heard of anyone (successfully) calling bind() on a multicast address. >By default, ReceivingInterfaceAddr is INADDR_ANY: that's why we get the >two video streams mixed on the video output. >The problem is that ReceivingInterfaceAddr is a global variable. We >would need here one different value (i.e. multicast address) for each >reader. No, if you set ReceivingInterfaceAddr at all, then it needs to be set to a *unicast* address - the IP address of the desired network interface, not a multicast address. In any case, you probably should not be running the code multi-threaded within a single address space. Instead, run multiple address spaces (i.e., one per receiver). Again, please read the FAQ on threads. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Thu Nov 8 11:21:35 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 8 Nov 2007 13:21:35 -0600 Subject: [Live-devel] LIVE Design? STL / Data Types / snprintf / strDup Message-ID: A couple of general design questions, if you please: 1. Is there specific reasoning that LIVE555 does not use STL? I have not worked with the STL before, so I can't really answer this question when it comes up. 2. I saw in the online "todo" list that there was an item to change certain data types in the library. Is it your intent to change ALL standard data types to the u_int32_t - styled types? Or only when the type size is specified by a standard (RTSP/RTP/RTCP, etc.)? 3. I notice in Media.cpp at line 181 there's a comment saying not to use "snprintf" because it is not on some systems. Are there other calls like this that are intentionally avoided? I did notice that you created strDup.cpp. Which functions do you consider "allowed" when working with your code? Thanks Xo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071108/7a58c5ae/attachment.html From finlayson at live555.com Thu Nov 8 12:57:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Nov 2007 12:57:23 -0800 Subject: [Live-devel] LIVE Design? STL / Data Types / snprintf / strDup In-Reply-To: References: Message-ID: >1. Is there specific reasoning that LIVE555 does not use STL? Basically, because I want this software to be useful for environments (e.g., embedded systems) for which STL might not be available, or might incur an excessive memory footprint if it were used. >2. I saw in the online "todo" list that there was an item to change >certain data types in the library. Is it your intent to change ALL >standard data types to the u_int32_t - styled types? Or only when >the type size is specified by a standard (RTSP/RTP/RTCP, etc.)? The latter. >3. I notice in Media.cpp at line 181 there's a comment saying not >to use "snprintf" because it is not on some systems. Are there >other calls like this that are intentionally avoided? I did notice >that you created strDup.cpp. Which functions do you >consider "allowed" when working with your code? Any software that you write that uses the software is yours, so you can use whatever functions you like. (Of course, you really should not be *modifying* the existing code; instead, you should just be extending it or adding your own code that links with it.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071108/965884c9/attachment.html From Andrew.E.Augenstein at boeing.com Thu Nov 8 15:26:14 2007 From: Andrew.E.Augenstein at boeing.com (Augenstein, Andrew E) Date: Thu, 8 Nov 2007 15:26:14 -0800 Subject: [Live-devel] Very slow playback of Transport Stream In-Reply-To: <47EFC4C84662ED459C3B02620109A31E04034569@XCH-SW-4V2.sw.nos.boeing.com> References: <47EFC4C84662ED459C3B02620109A31E04034569@XCH-SW-4V2.sw.nos.boeing.com> Message-ID: <47EFC4C84662ED459C3B02620109A31E03FDE3FE@XCH-SW-4V2.sw.nos.boeing.com> Using either VLC or an inhouse decoder/client, we make an RTSP play request to the server for playback of a file at normal (1x) speed. We have a variety of compliant transport streams, and for most of them, the playback is extremely slow. With live555mediaserver version 0.15 we see the first frame immediately, and then very slow updates. With live555mediaserver version 0.18 the first frame is delayed, and then very slow updates. The bit rate for both is less then a half a megabit per second for a 10 megabit/second transport stream. Playback of the same files using VLC or the inhouse decoder/client from a harddrive results in appropriate/normal playback. Any suggestions? From finlayson at live555.com Thu Nov 8 15:53:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Nov 2007 15:53:01 -0800 Subject: [Live-devel] Very slow playback of Transport Stream In-Reply-To: <47EFC4C84662ED459C3B02620109A31E03FDE3FE@XCH-SW-4V2.sw.nos.boeing.com> References: <47EFC4C84662ED459C3B02620109A31E04034569@XCH-SW-4V2.sw.nos.boeing.com> <47EFC4C84662ED459C3B02620109A31E03FDE3FE@XCH-SW-4V2.sw.nos.boeing.com> Message-ID: >Using either VLC or an inhouse decoder/client, we make an RTSP play >request to the server for playback of a file at normal (1x) speed. We >have a variety of compliant transport streams, and for most of them, the >playback is extremely slow. >With live555mediaserver version 0.15 we see the first frame immediately, >and then very slow updates. >With live555mediaserver version 0.18 the first frame is delayed, and >then very slow updates. >The bit rate for both is less then a half a megabit per second for a 10 >megabit/second transport stream. > >Playback of the same files using VLC or the inhouse decoder/client from >a harddrive results in appropriate/normal playback. > >Any suggestions? Thanks for the report. Please put one of the problem Transport Stream files on a web server, and send us the URL, so we can download and test this ourselves. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From brainlai at gmail.com Sun Nov 11 09:12:49 2007 From: brainlai at gmail.com (Brain Lai) Date: Mon, 12 Nov 2007 01:12:49 +0800 Subject: [Live-devel] Unable to receive multicast video stream on Windows XP Message-ID: Dear Sir: Multicast applications on Windows platform seem to have a problem. After doing some experiments with your test program, I found the openRTSP agent compiled with VC6 fails to receive video stream multicast by testMPEG4VideoStreamer on Linux(that is, getNextFrame() never get a frame after RTSP PLAY response). However, the cross-compiled(mingw32) version of openRTSP succeeds! Since VLC for win32 is also cross-compiled, it also has no problem. Using wireshark(previous ethreal) to capture the network packets, I found that the cross-compiled version sent IGMP V3 membership message to join the multicast group but the VC6 compiled version doesn't. I am not familiar with Windows socket programming but there seems something missing or wrong. Do you ever get into this trouble and solve it? BTW, all the tests link to the latest live555. BR. Brain Lai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071111/48c0dbdc/attachment.html From chang.yiwen at tw.panasonic.com Sun Nov 11 18:33:35 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Mon, 12 Nov 2007 10:33:35 +0800 Subject: [Live-devel] Received frame size on receiver side Message-ID: <015601c824d4$6ebe2180$59085a0a@userd7c6bde7c0> Dear, We want to get frame size of received frames up to present on receiver side. Does fFrameSize in RTPSource represent the received frame per time? If no, do you know how to get or compute the received frame size? Many thanks of your answering. Best Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071111/f53f8219/attachment.html From finlayson at live555.com Sun Nov 11 19:09:03 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 11 Nov 2007 19:09:03 -0800 Subject: [Live-devel] Received frame size on receiver side In-Reply-To: <015601c824d4$6ebe2180$59085a0a@userd7c6bde7c0> References: <015601c824d4$6ebe2180$59085a0a@userd7c6bde7c0> Message-ID: >Dear, > >We want to get frame size of received frames up to present on receiver side. > >Does fFrameSize in RTPSource represent the received frame per time? > >If no, do you know how to get or compute the received frame size? The size of each received frame is passed as the "frameSize" argument to the 'after getting' function that you used as a parameter to the "getNextFrame()" call. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071111/56d56177/attachment.html From chang.yiwen at tw.panasonic.com Mon Nov 12 02:16:30 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Mon, 12 Nov 2007 18:16:30 +0800 Subject: [Live-devel] if the NAL is larger than fMaxSize Message-ID: <027901c82515$1a25b980$59085a0a@userd7c6bde7c0> Dear, In doGetNextFrame(), if the NAL is larger than fMaxSize, how to process the remaing data (fNumTruncatedBytes)? Thanks. Best Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071112/2adabdca/attachment-0001.html From finlayson at live555.com Mon Nov 12 05:53:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Nov 2007 05:53:53 -0800 Subject: [Live-devel] if the NAL is larger than fMaxSize In-Reply-To: <027901c82515$1a25b980$59085a0a@userd7c6bde7c0> References: <027901c82515$1a25b980$59085a0a@userd7c6bde7c0> Message-ID: >In doGetNextFrame(), if the NAL is larger than fMaxSize, >how to process the remaing data (fNumTruncatedBytes)? You can't, because they will not have been delivered (because you did not provide enough space for hem). You need to make sure that the "maxSize" parameter to the "getNextFrame()" call is at least as large as the largest NAL unit you expect to receive. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071112/5d96f780/attachment.html From Andrew.E.Augenstein at boeing.com Mon Nov 12 10:11:21 2007 From: Andrew.E.Augenstein at boeing.com (Augenstein, Andrew E) Date: Mon, 12 Nov 2007 10:11:21 -0800 Subject: [Live-devel] Very slow playback of Transport Stream In-Reply-To: References: <47EFC4C84662ED459C3B02620109A31E04034569@XCH-SW-4V2.sw.nos.boeing.com><47EFC4C84662ED459C3B02620109A31E03FDE3FE@XCH-SW-4V2.sw.nos.boeing.com> Message-ID: <47EFC4C84662ED459C3B02620109A31E03FDE409@XCH-SW-4V2.sw.nos.boeing.com> The following web-site had several transport streams that live555mediaserver has problems with. http://www.w6rz.net/ These two specifically, start playing pretty quickly but lockup after a few seconds of playback. Park Run 1280x1080 New Mobile and Calendar 1280x1080 -----Original Message----- From: Ross Finlayson [mailto:finlayson at live555.com] Sent: Thursday, November 08, 2007 4:53 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Very slow playback of Transport Stream >Using either VLC or an inhouse decoder/client, we make an RTSP play >request to the server for playback of a file at normal (1x) speed. We >have a variety of compliant transport streams, and for most of them, >the playback is extremely slow. >With live555mediaserver version 0.15 we see the first frame >immediately, and then very slow updates. >With live555mediaserver version 0.18 the first frame is delayed, and >then very slow updates. >The bit rate for both is less then a half a megabit per second for a 10 >megabit/second transport stream. > >Playback of the same files using VLC or the inhouse decoder/client from >a harddrive results in appropriate/normal playback. > >Any suggestions? Thanks for the report. Please put one of the problem Transport Stream files on a web server, and send us the URL, so we can download and test this ourselves. -- 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 chang.yiwen at tw.panasonic.com Mon Nov 12 17:23:24 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Tue, 13 Nov 2007 09:23:24 +0800 Subject: [Live-devel] if the NAL is larger than fMaxSize Message-ID: <000b01c82593$cbca9290$59085a0a@userd7c6bde7c0> >>In doGetNextFrame(), if the NAL is larger than fMaxSize, >>how to process the remaing data (fNumTruncatedBytes)? >You can't, because they will not have been delivered (because you did >not provide enough space for hem). >You need to make sure that the "maxSize" parameter to the >"getNextFrame()" call is at least as large as the largest NAL unit >you expect to receive. Thank you. But I am confused. I am playing H.264, and just implement H264VideoStreamFramer::doGetNextFrame() and checkForFrame(). As you said, should I control to call getNextFrame() from H264RTPSink with a large enough maxSize? Could you show me directions of how to do that? Another, what is is H264FUAFragmenter used for? Thank you! Best Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071112/9408e310/attachment.html From finlayson at live555.com Mon Nov 12 18:56:38 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Nov 2007 18:56:38 -0800 Subject: [Live-devel] if the NAL is larger than fMaxSize In-Reply-To: <000b01c82593$cbca9290$59085a0a@userd7c6bde7c0> References: <000b01c82593$cbca9290$59085a0a@userd7c6bde7c0> Message-ID: >Thank you. >But I am confused. >I am playing H.264, and just implement >H264VideoStreamFramer::doGetNextFrame() and checkForFrame(). > >As you said, should I control to call getNextFrame() from >H264RTPSink with a large enough maxSize? >Could you show me directions of how to do that? Yes, add OutPacketBuffer::maxSize = ; to your code, before you create any "RTPSink"s (or create a "RTSPServer"). > >Another, what is is H264FUAFragmenter used for? It's used to implement FU-A packets, as defined in RFC 3984. You should not have to care about that code (it just works :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071112/75245712/attachment.html From chang.yiwen at tw.panasonic.com Mon Nov 12 18:36:13 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Tue, 13 Nov 2007 10:36:13 +0800 Subject: [Live-devel] the maximum buffer size for a frame Message-ID: <003201c8259d$f6f31c80$59085a0a@userd7c6bde7c0> >>In doGetNextFrame(), if the NAL is larger than fMaxSize, >>how to process the remaing data (fNumTruncatedBytes)? >You can't, because they will not have been delivered (because you did >not provide enough space for hem). >You need to make sure that the "maxSize" parameter to the >"getNextFrame()" call is at least as large as the largest NAL unit >you expect to receive. I check the maxSize is set as 60000 in default (MultiFramedRTPSink::fOutBuf). Even I assign the desired maxSize to the "getNextFrame()", it is also limited in the maxSize (60000). Should I change the default maxSize of MultiFramedRTPSink::fOutBuf? (we need 1000000 bytes of a frame at least.) Thanks. BRs, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071112/cc454e53/attachment.html From chang.yiwen at tw.panasonic.com Mon Nov 12 18:39:42 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Tue, 13 Nov 2007 10:39:42 +0800 Subject: [Live-devel] if the NAL is larger than fMaxSize Message-ID: <004701c8259e$798a0cd0$59085a0a@userd7c6bde7c0> >>In doGetNextFrame(), if the NAL is larger than fMaxSize, >>how to process the remaing data (fNumTruncatedBytes)? >You can't, because they will not have been delivered (because you did >not provide enough space for hem). >You need to make sure that the "maxSize" parameter to the >"getNextFrame()" call is at least as large as the largest NAL unit >you expect to receive. I check the maxSize is set as 60000 in default (MultiFramedRTPSink::fOutBuf). Even I assign the desired maxSize to the "getNextFrame()", it is also limited in the maxSize (60000). Should I change the default maxSize of MultiFramedRTPSink::fOutBuf? (we need 1000000 bytes of a frame at least.) Thanks. BRs, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071112/224d0f5f/attachment.html From chang.yiwen at tw.panasonic.com Mon Nov 12 19:28:08 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Tue, 13 Nov 2007 11:28:08 +0800 Subject: [Live-devel] if the NAL is larger than fMaxSize Message-ID: <007201c825a5$37dde660$59085a0a@userd7c6bde7c0> If I increase buffer size as OutPacketBuffer::maxSize = 100000 for RTPSink, is it possible that overflow occurs in receiver side? In H264VideoRTPSource(..., bufferSize, ...), the bufferSize indicates the maximum size for a received frame? Thank you very much. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071112/52f166c8/attachment.html From finlayson at live555.com Mon Nov 12 20:36:58 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Nov 2007 20:36:58 -0800 Subject: [Live-devel] if the NAL is larger than fMaxSize In-Reply-To: <007201c825a5$37dde660$59085a0a@userd7c6bde7c0> References: <007201c825a5$37dde660$59085a0a@userd7c6bde7c0> Message-ID: >If I increase buffer size as OutPacketBuffer::maxSize = 100000 for RTPSink, >is it possible that overflow occurs in receiver side? No, because that won't change the maximum size of outgoing RTP packets. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071112/12ebbf2d/attachment-0001.html From jobin.tech at gmail.com Mon Nov 12 22:05:40 2007 From: jobin.tech at gmail.com (Jobin Mathew) Date: Tue, 13 Nov 2007 11:35:40 +0530 Subject: [Live-devel] Throughput of each stream in live555 Message-ID: <1f855ed30711122205x53274621w8953416399cbb22f@mail.gmail.com> Hi all, I have using live555 as a server and VLC as clients from other systems. Can you tel me a solution for find out the throughput of each stream in live555 server. Regards, Jobin From finlayson at live555.com Mon Nov 12 22:19:42 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Nov 2007 22:19:42 -0800 Subject: [Live-devel] Throughput of each stream in live555 In-Reply-To: <1f855ed30711122205x53274621w8953416399cbb22f@mail.gmail.com> References: <1f855ed30711122205x53274621w8953416399cbb22f@mail.gmail.com> Message-ID: >Hi all, > > I have using live555 as a server and VLC as clients >from other systems. Can you tel me a solution for find out the >throughput of each stream in live555 server. You can probably figure this out from VLC - e.g., using its "Information" menu for the stream. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 12 23:12:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Nov 2007 23:12:55 -0800 Subject: [Live-devel] Very slow playback of Transport Stream In-Reply-To: <47EFC4C84662ED459C3B02620109A31E03FDE409@XCH-SW-4V2.sw.nos.boeing.com> References: <47EFC4C84662ED459C3B02620109A31E04034569@XCH-SW-4V2.sw.nos.boeing.com><47 EFC4C84662ED459C3B02620109A31E03FDE3FE@XCH-SW-4V2.sw.nos.boeing.com> <47EFC4C84662ED459C3B02620109A31E03FDE409@XCH-SW-4V2.sw.nos.boeing.com> Message-ID: >The following web-site had several transport streams that >live555mediaserver has problems with. >http://www.w6rz.net/ > >These two specifically, start playing pretty quickly but lockup after a >few seconds of playback. > Park Run 1280x1080 > New Mobile and Calendar 1280x1080 I see three files listed (at 12 Mbps, 17.6 Mbps, 22.5 Mbps) for each of those. Which one(s) cause problems for you? I downloaded the 12 Mbps version of "Park Run" and streamed it from the "LIVE555 Media Server" to VLC - running on the same computer - and didn't see any playback problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From thiyagu_tvr at hotmail.com Tue Nov 13 04:43:05 2007 From: thiyagu_tvr at hotmail.com (thiyaga rajan) Date: Tue, 13 Nov 2007 18:13:05 +0530 Subject: [Live-devel] how to stream live video MPEG4 data Message-ID: Hi , i gone through your site which seems to be very helpful in my application.Actually my application is i want to stream live video MPEG4 data which is present at some address location into network. i gone through first faq of your site in which you suggested to use the DeviceSource.cpp and DeviceSource.hh, in this DeviceSource.cpp where should i give the input live video MPEG4 data ? and whether can i use DeviceSource.cpp to stream the data into network or would you suggest any alternative. Any help in this regard would be appreciated. thanks yeah _________________________________________________________________ Check out some new online services at Windows Live Ideas?so new they haven?t even been officially released yet. http://www.msnspecials.in/windowslive/ From armandopoulos at yahoo.fr Tue Nov 13 06:57:28 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Tue, 13 Nov 2007 15:57:28 +0100 (CET) Subject: [Live-devel] Initialization of the Live555 for 2 streamings Message-ID: <315344.8017.qm@web25908.mail.ukl.yahoo.com> Hallo, is possible to initialize the live555 for doing 2 streams ? For example one for mpeg streaming at the port 1234 and the second stream for jpeg at the second port 5678 and the two streams are working with the same multicast adress. The idea is to use 2 channels for streaming 1 server and 2 clients. Thank for your support. Armando --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071113/9829643c/attachment.html From finlayson at live555.com Tue Nov 13 07:13:58 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Nov 2007 07:13:58 -0800 Subject: [Live-devel] Initialization of the Live555 for 2 streamings In-Reply-To: <315344.8017.qm@web25908.mail.ukl.yahoo.com> References: <315344.8017.qm@web25908.mail.ukl.yahoo.com> Message-ID: >Hallo, > >is possible to initialize the live555 for doing 2 streams ? Yes. Create the source and sink objects for each stream, call "sink->startPlaying(...)" for each stream, then call "scheduler.doEventLoop()" - just once - at the end, to start the event loop. > >For example one for mpeg streaming at the port 1234 and the second >stream for jpeg at the second port 5678 and the two streams are >working with the same multicast adress. It's a bad idea to use the same multicast address for two different streams, because if you do that, the receiving computer will get data for both streams, even if it wants data for only one of the streams. You should use different multicast addresses and ports for different streams. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mjn at oxysys.com Tue Nov 13 16:57:23 2007 From: mjn at oxysys.com (Marc Neuberger) Date: Tue, 13 Nov 2007 19:57:23 -0500 Subject: [Live-devel] issue with a streaming server having multiple network interfaces In-Reply-To: References: <570228.47592.qm@web53304.mail.re2.yahoo.com> Message-ID: <473A47F3.7010502@oxysys.com> Ross Finlayson wrote: >> I will try your version later on (when I get back from my vacation) >> but I believe that a simple test can be made to check your >> correction. >> >> If you connect a client from the internet to your LIVE555 server >> that is behind a NAT/firewall, you would be reproducing the same >> situation. >> > > No, that's a completely different situation. A LIVE555 server behind > a NAT won't work until we implement ICE. > I haven't seen any feedback on whether your multiple-interface fix worked for anyone. I have tried it (I am having problems with a multiple-interface machine). It seems to get halfway there: We now compute the Content-Base URL appropriately (and source= element in the RTSP SETUP reply [though the o= line of the SDP still has a different IP address. This may be appropriate, I don't have a clear idea of how it is used, if at all.]. However, the RTP and RTCP packets come from the "wrong" IP address, i.e. not necessarily the IP address of the interface that the connection was made to. It seems that some firewalls block all of the UDP traffic under these circumstances. The UDP sockets need to be bound to the appropriate interface, rather than INADDR_ANY, to ensure that they come from the correct IP address. WRT NATs: I think that what Noam Camiel was proposing was to use the actual host name/port provided in the DESCRIBE verbatim, rather than working backwards from the socket to the IP address to the IP address string. This would seem to fix multiple interfaces /and/ NATs, at least for the Content-Base header. Getting the source= element of the RTSP SETUP wouldn't work this way. Marc Neuberger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071113/9e6aa09b/attachment.html From nikhiln at paxit.com Tue Nov 13 17:15:53 2007 From: nikhiln at paxit.com (nikhiln at paxit.com) Date: Tue, 13 Nov 2007 19:15:53 -0600 Subject: [Live-devel] Streaming JPEGs from Memory using LIVE555 Message-ID: <765df8718e5944238062c7f611654d62.nikhiln@paxit.com> Hey Ross, I had shot you an email earlier this morning with regards to an issue with being unable to correctly open a file saved in memory as a JPEG. Well we soon figured out that fTo gets only the image data and the JPEG header is sent separately and that is what had caused the problem. Originally I was providing the entire JPEG array to fTo and this caused streaming issues. Now we have run into another issue! We are using our own library to create the JPEG in memory on the Server. This library has it's own method for setting the compression ratio(0-99) and we set that compression ratio on the fly. What we are seeing is that the JPEG image displayed at the client side is much more lossy-(ier) than it should be for the value of the compression ratio. We have written the JPEG from memory to a file on the Server side and it does not have nearly the amount of compression that arrives at the client. I have a feeling this is partly in regards to the fLastQfactor on the server. I tried providing the same value to fLastQfactor as the compression ratio when we create the jpeg in memory and it did not seem to help. Only when the compression is set to about 95~99 is when we see an image that isn't severely compressed. How is the fLastQfactor related to how the client side receives and decompresses the JPEG? We again are using our own custom library to decode and display the JPEG on the client side, yet how we set fLastQfactor on the server is affecting the compression ratio that is recognized on the client side. We assumed that since we are encoding and decoding the jpeg with our own library that all of the information as far as compressing/decompressing the images would come from our library rather than any code from the server or client. Our desire here is simply to have the client recognize the same amount of comression as is set on the server. Essentially whatever we compressed to memory on the server is what we want to display on the client side. Do we need to derive our own create Qfactor table on the server? Hope to hear from you at your earliest convenience. Any help in this regard Would be seriously appreciated. Thanks, Nikhil. From finlayson at live555.com Tue Nov 13 19:05:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Nov 2007 19:05:07 -0800 Subject: [Live-devel] issue with a streaming server having multiple network interfaces In-Reply-To: <473A47F3.7010502@oxysys.com> References: <570228.47592.qm@web53304.mail.re2.yahoo.com> <473A47F3.7010502@oxysys.com> Message-ID: >I have tried it (I am having problems with a multiple-interface >machine). It seems to get halfway there: We now compute the >Content-Base URL appropriately (and source= element in the RTSP >SETUP reply [though the o= line of the SDP still has a different IP >address. This may be appropriate, I don't have a clear idea of how >it is used, if at all.]. However, the RTP and RTCP packets come from >the "wrong" IP address, i.e. not necessarily the IP address of the >interface that the connection was made to. > >It seems that some firewalls block all of the UDP traffic under >these circumstances. The UDP sockets need to be bound to the >appropriate interface, rather than INADDR_ANY, to ensure that they >come from the correct IP address. You can do this by modifying your code to set "ReceivingInterfaceAddr" at the start. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mjn at oxysys.com Tue Nov 13 21:08:13 2007 From: mjn at oxysys.com (Marc Neuberger) Date: Wed, 14 Nov 2007 00:08:13 -0500 Subject: [Live-devel] issue with a streaming server having multiple network interfaces In-Reply-To: References: <570228.47592.qm@web53304.mail.re2.yahoo.com> <473A47F3.7010502@oxysys.com> Message-ID: <473A82BD.7060504@oxysys.com> Ross Finlayson wrote: >> I have tried it (I am having problems with a multiple-interface >> machine). It seems to get halfway there: We now compute the >> Content-Base URL appropriately (and source= element in the RTSP >> SETUP reply [though the o= line of the SDP still has a different IP >> address. This may be appropriate, I don't have a clear idea of how >> it is used, if at all.]. However, the RTP and RTCP packets come from >> the "wrong" IP address, i.e. not necessarily the IP address of the >> interface that the connection was made to. >> >> It seems that some firewalls block all of the UDP traffic under >> these circumstances. The UDP sockets need to be bound to the >> appropriate interface, rather than INADDR_ANY, to ensure that they >> come from the correct IP address. >> > > You can do this by modifying your code to set > "ReceivingInterfaceAddr" at the start. > The problem is that I want to be able to accept RTSP connections from *all* of the interfaces. So the UDP sockets need to be bound on a per-connection basis, depending on what interface the RTSP came in on. If I understand correctly, ReceivingInterfaceAddr is a static global, so it would set the interface once and for all. Marc Neuberger -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071113/2c5f5add/attachment-0001.html From shabbu_banu37 at yahoo.co.in Tue Nov 13 22:19:57 2007 From: shabbu_banu37 at yahoo.co.in (SHABANA BANU) Date: Wed, 14 Nov 2007 11:49:57 +0530 (IST) Subject: [Live-devel] problem in streaming mpeg4 video data Message-ID: <65726.57251.qm@web7910.mail.in.yahoo.com> Hi friends, i am working on a application where MPEG4 live video data is kept in a kit(device) and have to stream this frame data using RTP/RTSP into network. How to get the data from kit(device) and stream into network using your application programs. And also having doubt that whether it is neccessary to use the Devicesource.cpp and Devicesource.hh to get the frame data from device , 1. In Devicesource.hh given as // The following class can be used to define specific encoder parameters class DeviceParameters { }; wheteher in this class i have to mention the encoder parameters ,if yes then what are the parameters i have to give . 2. In Devicesource.cpp given as DeviceSource::DeviceSource(UsageEnvironment& env,DeviceParameters params) :FramedSource (env),fParams(params) { // Any initialization of the device would be done here } whether here i have to intialize the device parameters?if yes then how to do it. If possible pls clarify my doubts.Any help in this regard would be appreciated. thanks®ards shabby Forgot the famous last words? Access your message archive online at http://in.messenger.yahoo.com/webmessengerpromo.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071113/2a3a8d9d/attachment.html From finlayson at live555.com Tue Nov 13 22:32:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Nov 2007 22:32:57 -0800 Subject: [Live-devel] issue with a streaming server having multiple network interfaces In-Reply-To: <473A82BD.7060504@oxysys.com> References: <570228.47592.qm@web53304.mail.re2.yahoo.com> <473A47F3.7010502@oxysys.com> <473A82BD.7060504@oxysys.com> Message-ID: >Ross Finlayson wrote: > >>>I have tried it (I am having problems with a multiple-interface >>>machine). It seems to get halfway there: We now compute the >>>Content-Base URL appropriately (and source= element in the RTSP >>>SETUP reply [though the o= line of the SDP still has a different IP >>>address. This may be appropriate, I don't have a clear idea of how >>>it is used, if at all.]. However, the RTP and RTCP packets come from >>>the "wrong" IP address, i.e. not necessarily the IP address of the >>>interface that the connection was made to. >>> >>>It seems that some firewalls block all of the UDP traffic under >>>these circumstances. The UDP sockets need to be bound to the >>>appropriate interface, rather than INADDR_ANY, to ensure that they >>>come from the correct IP address. >>> >>> >> >>You can do this by modifying your code to set >>"ReceivingInterfaceAddr" at the start. >> >> >The problem is that I want to be able to accept RTSP connections >from *all* of the interfaces. So the UDP sockets need to be bound on >a per-connection basis, depending on what interface the RTSP came in >on. If I understand correctly, ReceivingInterfaceAddr is a static >global, so it would set the interface once and for all. Mumble... I suppose you could set it each time, just before creating each RTP sink object. E.g., you could do this in your "createNewRTPSink()" virtual function (in your "ServerMediaSession" subclass), before you actually create the RTP sink. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071113/965eb4cf/attachment.html From chang.yiwen at tw.panasonic.com Wed Nov 14 00:58:46 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Wed, 14 Nov 2007 16:58:46 +0800 Subject: [Live-devel] about duration time Message-ID: <017101c8269c$928013c0$59085a0a@userd7c6bde7c0> Dear, I supposed the duration time is the time of successive frames to be sends. So, I calculate the duration time based on one frame processing time via transcoder (not based on frame rate, display rate) since video is from live source. But, I view MultiFramedRTPSink.cpp code, the duration time is used to calculate the time at which the next packet is sent. If so, what should I consider to calculate the duration time? Thanks. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071114/c9d72470/attachment.html From finlayson at live555.com Wed Nov 14 01:18:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Nov 2007 01:18:23 -0800 Subject: [Live-devel] about duration time In-Reply-To: <017101c8269c$928013c0$59085a0a@userd7c6bde7c0> References: <017101c8269c$928013c0$59085a0a@userd7c6bde7c0> Message-ID: >I supposed the duration time is the time of successive frames to be sends. Yes. >But, I view MultiFramedRTPSink.cpp code, the duration time is used >to calculate the time at which the next packet is sent. Yes, and that is perfectly consistent with what you said above. > If so, what should I consider to calculate the duration time? Because you are streaming from a live source, each frame will not be delivered until the time that it's ready to be streamed. In this case, it's OK to not set "fDurationInMicroseconds" at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071114/211d859c/attachment.html From armandopoulos at yahoo.fr Wed Nov 14 02:17:52 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Wed, 14 Nov 2007 11:17:52 +0100 (CET) Subject: [Live-devel] RE : Re: Initialization of the Live555 for 2 streamings In-Reply-To: Message-ID: <894676.73889.qm@web25905.mail.ukl.yahoo.com> Hi Ross, Thank you it?s working very well. Armando Ross Finlayson a ?crit : >Hallo, > >is possible to initialize the live555 for doing 2 streams ? Yes. Create the source and sink objects for each stream, call "sink->startPlaying(...)" for each stream, then call "scheduler.doEventLoop()" - just once - at the end, to start the event loop. > >For example one for mpeg streaming at the port 1234 and the second >stream for jpeg at the second port 5678 and the two streams are >working with the same multicast adress. It's a bad idea to use the same multicast address for two different streams, because if you do that, the receiving computer will get data for both streams, even if it wants data for only one of the streams. You should use different multicast addresses and ports for different streams. -- 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 --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071114/7f722c70/attachment.html From brainlai at gmail.com Wed Nov 14 04:42:29 2007 From: brainlai at gmail.com (Brain Lai) Date: Wed, 14 Nov 2007 20:42:29 +0800 Subject: [Live-devel] Unable to receive multicast video stream on Windows XP In-Reply-To: References: Message-ID: Dear Sir: I have conquered this problem today. It was my carelessness since I didn't apply genWindowsMakefiles to build live555 but instead open a new porject in VC6 and import the sources to compile. By default, only WIN32 is defined. But NetCommon.h requres __WIN32__, _WIN32, _WINNT or WINNT to be defined on Windows XP. This causes winsock2.hand ws2tcpip.h not to be included such that inappropriate macros used to call setsocketopt() leads to failure of joining a multicast group. Besides, in a practical multicast client application, it may be a problem if the RTSP server doesn't specify the media port in its SDP, for example, m=video 0 0 RTP/AVP 96. This will cause MediaSubession::fClientPortNum to be assigned 0. and then RTSPClient::setupMediaSubsession() will return False because the following condition holds: rtpNumber = subsession .clientPortNum (); if (rtpNumber == 0) { envir().setResultMsg("Client port number unknown\n"); break; } How about assigning a randomly generated port number here when initializing a MediaSession with SDP since it is not relevant for this application? Actually RFC2326 seems not to force the server to explicitly specify a media port number: C.1.2 Media streams The "m=" field is used to enumerate the streams. It is expected that all the specified streams will be rendered with appropriate synchronization. If the session is unicast, the port number serves as a recommendation from the server to the client; the client still has to include it in its SETUP request and may ignore this recommendation. If the server has no preference, it SHOULD set the port number value to zero. Example: m=audio 0 RTP/AVP 31 BR. Brain Lai 2007/11/12, Brain Lai : > > Dear Sir: > > Multicast applications on Windows platform seem to have a problem. After > doing some experiments with your test program, I found the openRTSP agent > compiled with VC6 fails to receive video stream multicast by > testMPEG4VideoStreamer on Linux(that is, getNextFrame() never get a frame > after RTSP PLAY response). However, the cross-compiled(mingw32) version of > openRTSP succeeds! Since VLC for win32 is also cross-compiled, it also has > no problem. > > Using wireshark(previous ethreal) to capture the network packets, I found > that the cross-compiled version sent IGMP V3 membership message to join the > multicast group but the VC6 compiled version doesn't. > > I am not familiar with Windows socket programming but there seems > something missing or wrong. Do you ever get into this trouble and solve it? > > BTW, all the tests link to the latest live555. > > BR. > Brain Lai > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071114/7933dc01/attachment-0001.html From satkin05 at harris.com Wed Nov 14 10:23:49 2007 From: satkin05 at harris.com (Atkins, Sarah) Date: Wed, 14 Nov 2007 13:23:49 -0500 Subject: [Live-devel] RTP/RTSP Streaming Trouble Message-ID: <9508D02DE5AE0247941E26B58C7FEC0A62CACB@mlbe2k5.cs.myharris.net> I have a some transport stream files which play back fine locally using VLC. However, when I stream those files to VLC via the live555MediaServer, only a blank screen opens up. I can see the RTSP DESCRIBE, SETUP, etc packets and the video RTP packets being sent via Wireshark, however no playback is observed. Other transport stream files can be played back fine using the same method. I realize this is a very general question, but do you have any ideas on what is happening? As I mentioned, VLC can playback the files in question fine locally, and Live555MediaServer streams other transport stream files perfectly with similar RTSP/RTP output. Any information would be greatly appreciated. Thanks! Sarah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071114/dfeba841/attachment.html From aluigi at autistici.org Wed Nov 14 12:01:37 2007 From: aluigi at autistici.org (Luigi Auriemma) Date: Wed, 14 Nov 2007 21:01:37 +0100 Subject: [Live-devel] Denial of Service in media server Message-ID: <20071114210137.434da24e.aluigi@autistici.org> Hey, I want to report a DoS vulnerability I have found in the live555 media server 2007.11.01. The following are the details: The function which handles the incoming queries from the clients is affected by a vulnerability which can allow an attacker to crash the server remotely using the smallest query possible to use. This problem is caused by the absence of an instruction for checking if the client data is longer or equal than 8 bytes since the function makes use of unsigned numbers, so "7 - 8" is not -1 but 4294967295. >From liveMedia/RTSPCommon: Boolean parseRTSPRequestString(char const* reqStr, unsigned reqStrSize, ... unsigned i; for (i = 0; i < resultCmdNameMaxSize-1 && i < reqStrSize; ++i) { ... // Skip over the prefix of any "rtsp://" or "rtsp:/" URL that follows: unsigned j = i+1; while (j < reqStrSize && (reqStr[j] == ' ' || reqStr[j] == '\t')) ++j; for (j = i+1; j < reqStrSize-8; ++j) { ... Testing the bug is trivial so no PoC is needed, just send "x x" (without ") followed by 2 CR/LF, for a total of 7 bytes. BYEZ --- Luigi Auriemma http://aluigi.org http://forum.aluigi.org http://mirror.aluigi.org From finlayson at live555.com Wed Nov 14 14:28:28 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Nov 2007 14:28:28 -0800 Subject: [Live-devel] RTP/RTSP Streaming Trouble In-Reply-To: <9508D02DE5AE0247941E26B58C7FEC0A62CACB@mlbe2k5.cs.myharris.net> References: <9508D02DE5AE0247941E26B58C7FEC0A62CACB@mlbe2k5.cs.myharris.net> Message-ID: Thanks for the report. Please put one of the problem Transport Stream files on a web server, and send us the URL, so we can download and test this ourselves. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Nov 14 17:46:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Nov 2007 17:46:55 -0800 Subject: [Live-devel] Denial of Service in media server In-Reply-To: <20071114210137.434da24e.aluigi@autistici.org> References: <20071114210137.434da24e.aluigi@autistici.org> Message-ID: Luigi, Many thanks for the bug report. (This is exactly the kind of bug report I love to see.) > for (j = i+1; j < reqStrSize-8; ++j) { Probably the easiest fix for this problem (until I get around to rewriting/cleaning up the whole RTSP request parsing code) is to change j < reqStrSize-8 to (int)j < (int)(reqStrSize-8) and ditto for the other two similar tests elsewhere in the "parseRTSPRequestString()" function. This will be fixed in the next release of the software. Ross. From aluigi at autistici.org Thu Nov 15 01:08:50 2007 From: aluigi at autistici.org (Luigi Auriemma) Date: Thu, 15 Nov 2007 10:08:50 +0100 Subject: [Live-devel] Denial of Service in media server In-Reply-To: References: <20071114210137.434da24e.aluigi@autistici.org> Message-ID: <20071115100850.63c62e9b.aluigi@autistici.org> Ross Finlayson wrote: > Probably the easiest fix for this problem (until I get around to > rewriting/cleaning up the whole RTSP request parsing code) is to > change > j < reqStrSize-8 > to > (int)j < (int)(reqStrSize-8) Hey Ross, I'm happy that you liked my bug report 8-) Another solution could be also: if(reqStrSize < 8) return False; placed at the beginning of the function (for avoiding the first instructions since we already know that the data is invalid) or naturally before that for(). BYEZ --- Luigi Auriemma http://aluigi.org http://forum.aluigi.org http://mirror.aluigi.org From brainlai at gmail.com Thu Nov 15 04:52:43 2007 From: brainlai at gmail.com (Brain Lai) Date: Thu, 15 Nov 2007 20:52:43 +0800 Subject: [Live-devel] An implicit bug in RTSPClient::getResponse()1 on Windows Message-ID: Dear Sir: In an application where the RTSP server has a limit on the number of connections, the server may send something like "RTSP/1.0 406 Not Acceptable\r\n\r\n" and/or close the incoming socket immediately because the max number of connection is reached. If the sample agent openRTSP(VLC, too) connects to the server in the meanwhile, it will be stuck in RTSPClient::getResponse()1 on Windows while read 0 due to "connectin reset by peer" on Linux. So, I step inside RTSPClient::getResponse1() and find the following code causes the problem: unsigned bytesReadNow = readSocket(...); where readSocket(...) has return type int and may return -1 in the above scenario. Such that the condition never holds: if (bytesReadNow == 0) { envir().setResultMsg("RTSP response was truncated"); break; } This is because (unsigned)-1 is greater than zero. At this time, the client agent enters an infinite read loop and causes the CPU fulll load. Thererfore, I suggests to modify the code as the following: int bytesReadNow = readSocket(...); if (bytesReadNow <= 0) { envir().setResultMsg("RTSP response was truncated"); break; } This should ends the probelm. BR. Brain Lai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071115/cf76a56b/attachment.html From prabhakar_raju at hotmail.com Thu Nov 15 06:00:50 2007 From: prabhakar_raju at hotmail.com (Prabhakar Raju) Date: Thu, 15 Nov 2007 09:00:50 -0500 Subject: [Live-devel] (no subject) Message-ID: Hi, 1) I'm a "streaming" fan and a newbie. When I ran your 555 media server, It apparently is streaming from 192.168.86.1. Is this a dhcp assigned address? I haven't had a chance to browse thru the code yet. Is it using default rtp port (I think 5000 or something)? 2) When I ran genWindowsMakefiles from command prompt after pointing TOOLS32 to vc directory(VC 8, express edition), it was showing some errors like ... Makefile.tail Could Not Find C:\Temp\live\mediaServer\Makefile Makefile.head. Will the package work in the express edition(VC 2005) without additional libs? regards Prabha _________________________________________________________________ Windows Live Hotmail and Microsoft Office Outlook ? together at last. ?Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071115/24c5d6db/attachment.html From finlayson at live555.com Thu Nov 15 06:22:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Nov 2007 06:22:15 -0800 Subject: [Live-devel] (no subject) In-Reply-To: References: Message-ID: >Hi, > >1) I'm a "streaming" fan and a newbie. When I ran your 555 media >server, It apparently is streaming from 192.168.86.1. Is this a dhcp >assigned address? This depends upon your OS. But it is (in your case) an IP address for your computer's network interface. > I haven't had a chance to browse thru the code yet. Is it using >default rtp port (I think 5000 or something)? The server uses port numbers starting at 6970. (RTP port numbers are even; RTCP port numbers are odd.) > >2) When I ran genWindowsMakefiles from command prompt after pointing >TOOLS32 to vc directory(VC 8, express edition), it was showing some >errors like >... >Makefile.tail >Could Not Find C:\Temp\live\mediaServer\Makefile >Makefile.head. Did you "cd" to the "live" directory beforehand (as described in the online documentation)? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Nov 15 06:32:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 15 Nov 2007 06:32:14 -0800 Subject: [Live-devel] An implicit bug in RTSPClient::getResponse()1 on Windows In-Reply-To: References: Message-ID: Thanks for the report. This will be fixed in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From peter at topsdigitalsecurity.com Thu Nov 15 20:34:33 2007 From: peter at topsdigitalsecurity.com (Peter) Date: Thu, 15 Nov 2007 20:34:33 -0800 Subject: [Live-devel] rtsp server and client module issues Message-ID: <000701c82809$fcacd120$5601a8c0@PeterMobile> Hi, We are using MobilyGen MG1264 chip. And they served liveMedia module for rtsp server as qboxserver and client as qboxreceiver. Encoder uses rtsp server and Decoder uses rtsp client. Actually, I don't know what the difference is from your original. We have problems, as you know I hope. 1. RTSP client takes to long time to connect with new rtsp server and display image. - It takes 3 sec. - We expect it can be reduced to less than 1 sec. 2. Sometimes, decoder gives this error message after connecting. - QBoxFileSink: stream 2 drop cts 0x617e/8c6529f1 start 0xc2fd/18b4f988 - QBoxFileSink: stream 2 drop cts 0x617e/8c6535ab start 0xc2fd/18b4f988 - QBoxFileSink: stream 2 drop cts 0x617e/8c6535b2 start 0xc2fd/18b4f988 - QBoxFileSink: stream 2 drop cts 0x617e/8c65416d start 0xc2fd/18b4f988 - It fails to connect, at the end. Please give an advise about those problems. And Is there BEST way to solve these issues as soon as ?? possible ? The last one is question. Could you make rtsp server filter ? We need this module but I have no idea how to make that. Because my poor English, you can feel I'm soooo rude. That's not true :) Best Regards. Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071115/592529b5/attachment-0001.html From bonheur.cheung at seldes.com Fri Nov 16 00:04:23 2007 From: bonheur.cheung at seldes.com (cheung bonheur) Date: Fri, 16 Nov 2007 09:04:23 +0100 Subject: [Live-devel] Fw: Error message of VLC at starting...(libffmpeg_plugin.dll) Message-ID: <002501c82827$4cb89560$6401a8c0@rhea> ----- Original Message ----- From: cheung bonheur To: live-devel-owner at lists.live555.com Sent: Tuesday, November 13, 2007 5:27 PM Subject: Error message of VLC at starting...(libffmpeg_plugin.dll) Hello Ross, The server rtsp turn perfectly in my application but it seems that vlc client bug randomly at starting (a suite of start/stop) and i try to found a trace: In console vlc , we can read the following message : MultiFramedRTPSource::doGetNextFrame1():: The total received frame size exceeds the client's buffer size (65535) 643 bytes of trailing data will be dropped! Sending request : TEARDOWN rtsp://localhost/jpegvideosource RTSP/1.0 CSeq: 140 Session: 111 User-Agent: VLC media player (LIVE Streaming Media v2007.02.20) My video source is one image jpeg only and we can see the image correctly in VLC. I fixe the size of OutPacketBuffer::maxSize variable > than the size of image, but i think there are others parameters to set correctly. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071116/1739e709/attachment.html From finlayson at live555.com Fri Nov 16 01:00:46 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 16 Nov 2007 01:00:46 -0800 Subject: [Live-devel] Fw: Error message of VLC at starting...(libffmpeg_plugin.dll) In-Reply-To: <002501c82827$4cb89560$6401a8c0@rhea> References: <002501c82827$4cb89560$6401a8c0@rhea> Message-ID: >In console vlc , we can read the following message : > >MultiFramedRTPSource::doGetNextFrame1():: The total received frame >size exceeds the client's buffer size (65535) 643 bytes of trailing >data will be dropped! You need to turn on more debugging, so that you can see VLC-specific diagnostic messages. (Right now you're seeing only LIVE555-specific diagnostic messages,) The error above indicates only that the *first* received frame was too big for the assigned buffer. After that, VLC automatically increases the buffer size (and prints out a diagnostic message to this effect, which you should see if you increase the verbosity level in VLC). In any case, this is probably a VLC-related issue, not a "LIVE555 Streaming Media" issue. >Sending request : TEARDOWN rtsp://localhost/jpegvideosource RTSP/1.0 >CSeq: 140 >Session: 111 >User-Agent: VLC media player (LIVE Streaming Media v2007.02.20) This is just VLC closing the stream down when it ends. It probably has nothing to do with the earlier message. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071116/3d6380d6/attachment.html From finlayson at live555.com Fri Nov 16 02:04:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 16 Nov 2007 02:04:43 -0800 Subject: [Live-devel] rtsp server and client module issues In-Reply-To: <000701c82809$fcacd120$5601a8c0@PeterMobile> References: <000701c82809$fcacd120$5601a8c0@PeterMobile> Message-ID: >1. RTSP client takes to long time to connect with new rtsp server >and display image. > - It takes 3 sec. > - We expect it can be reduced to less than 1 sec. Unfortunately I can't help you with your application code; you will have to debug that yourself. However, there is little delay built in to the "LIVE555 Streaming Media" code. Therefore, the delay is probably due to your application code. My guess is that most of the delay is probably caused by excessive buffering in your client player application. However, if you have full source code for your server and application, you should be able to figure out exactly where the delay is occurring. >2. Sometimes, decoder gives this error message after connecting. > - QBoxFileSink: stream 2 drop cts 0x617e/8c6529f1 start 0xc2fd/18b4f988 > - QBoxFileSink: stream 2 drop cts 0x617e/8c6535ab start 0xc2fd/18b4f988 > - QBoxFileSink: stream 2 drop cts 0x617e/8c6535b2 start 0xc2fd/18b4f988 > - QBoxFileSink: stream 2 drop cts 0x617e/8c65416d start 0xc2fd/18b4f988 > - It fails to connect, at the end. "QBoxFileSink" is not our software, so we can't help you with that. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071116/665eebb0/attachment.html From eyal.b at mavix.com Fri Nov 16 03:42:53 2007 From: eyal.b at mavix.com (eyal.b at mavix.com) Date: Fri, 16 Nov 2007 13:42:53 +0200 Subject: [Live-devel] MORE: Memory leaks in DarwinInjector.cpp In-Reply-To: <20071114210137.434da24e.aluigi@autistici.org> References: <20071114210137.434da24e.aluigi@autistici.org> Message-ID: <003401c82845$d6cea320$0a0ac8c0@mavix.net.il> Hello, In my previous mail I have suggested how to prevent memory leaks in DarwinInjector. I want to correct a possible crash in my solution and add some more. 1) My solution could cause NULL pointer memory access error when a DarwinInjector was deleted before a session was created. So a "if (session)" clause was added before my use of "session" in DarwinInjector's destructor. 2) I have added a deletion of MediaSubsession's sessionId in the MediaSubsession destructor. This way it is safe to delete a session without causing a memory leak because of sessionId. MediaSubsession::~MediaSubsession() { ... delete[] sessionId;//allocated by RTSP, freed only by RTSP Tear-Session ... } 3) When using a couple of DarwinInjector instances/sessions, the first stream of each does not get to have a track-id of "1", but the value is being kept incremented. This is because the track-id used is a static variable in the injector module. I had changed the variable to be a member of the injector, to be init as 0 in the constructor, and be passes by reference to be incremented by SubstreamDescriptor in DarwinInjector::addStream(). Attached in DarwinInjector cpp and h files, with my previous and last modifications, marked with "/**/" on each modified line's start. Eyal Beit-Halachmi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071116/598f6f16/attachment-0001.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: DarwinInjector.cpp Url: http://lists.live555.com/pipermail/live-devel/attachments/20071116/598f6f16/attachment-0001.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: DarwinInjector.hh Type: application/octet-stream Size: 3496 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20071116/598f6f16/attachment-0001.obj From finlayson at live555.com Fri Nov 16 09:05:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 16 Nov 2007 09:05:15 -0800 Subject: [Live-devel] MORE: Memory leaks in DarwinInjector.cpp In-Reply-To: <003401c82845$d6cea320$0a0ac8c0@mavix.net.il> References: <20071114210137.434da24e.aluigi@autistici.org> <003401c82845$d6cea320$0a0ac8c0@mavix.net.il> Message-ID: The next version of gthe "LIVE555 Streaming Media" code - to be released probably within a day or so - will include your suggested changes 1) and 3). However, I won't be making your suggested change 2/. The "sessionId" field of "MediaSession" is one of a few fields that are not managed by the "MediaSession" object itself (note "MediaSession.hh"). Instead, it is managed/assigned externally. (See, e.g., "RTSPClient.cpp".) If you allocate memory to assign to the "sessionId" field, then you are also responsible for deleting that memory. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bonheur.cheung at seldes.com Fri Nov 16 09:28:48 2007 From: bonheur.cheung at seldes.com (cheung bonheur) Date: Fri, 16 Nov 2007 18:28:48 +0100 Subject: [Live-devel] Fw: VLC Crashing and Infos debug live555 Message-ID: <003d01c82876$264d20e0$6401a8c0@rhea> Sorry for mail address! I send to early this mail and i forgot to specify that i use the live555 engine with lossless image because i convert raw image (with fixed size 1447680) from camera to jpeg image (size ~75k) in deliverFrameToClient method. I set outpacketbuffer::maxsize to +- 3M (to be certainly but is it abused ?), timeTerFrame to 40ms, setDecimation is set to 16 (what's mean this?) and i have a Bandwith to 20M/s. I get decim_ms equal to 62.5 (what is mean exactly?) and last_decim to 31250(?). I think it is about time of engine to send rtp packet but i can you help me to know more about? thanks. ----- Original Message ----- From: cheung bonheur To: live-devel-owner at lists.live555.com Sent: Friday, November 16, 2007 5:14 PM Subject: VLC Crashing and Infos debug live555 Hi Ross, Thank you, now i set verbosity to 2 and see live555 debug message: main warning: clock gap, unexpected stream discontinuity main warning: late picture skipped (19876382533) main warning: late picture skipped (7018489) main warning: late picture skipped (6893489) main warning: vout warning: early picture skipped (11292713711) main warning: vout warning: early picture skipped (11292713711) main warning: late picture skipped (19883632533) main warning: late picture skipped (19000) main warning: clock gap, unexpected stream discontinuity main warning: late picture skipped (13237878) main warning: clock gap, unexpected stream discontinuity main warning: late picture skipped (19876163688) main warning: late picture skipped (2753378) main warning: late picture skipped (2628378) main warning: late picture skipped (2503378) main warning: late picture skipped (2378378) main warning: late picture skipped (19879085688) main warning: clock gap, unexpected stream discontinuity main warning: vout warning: early picture skipped (320236113074632) main warning: vout warning: early picture skipped (320236111215632) main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: vout warning: early picture skipped (320236080934199) main warning: vout warning: early picture skipped (320236080934199) main warning: vout warning: early picture skipped (320236095630121) main warning: vout warning: early picture skipped (320236095630121) main warning: late picture skipped (3389) main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: vout warning: early picture skipped (320236090263065) main warning: vout warning: early picture skipped (320236086107065) main warning: late picture skipped (4175000) main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: vout warning: early picture skipped (320236087717499) main warning: vout warning: early picture skipped (320236087717499) main warning: vout warning: early picture skipped (320236095209032) main warning: vout warning: early picture skipped (320236095209032) main warning: late picture skipped (3000) main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity live555 debug: lost 643 bytes live555 debug: increasing buffer size to 131072 main warning: vout warning: early picture skipped (320236091184288) main warning: vout warning: early picture skipped (320236091184288) main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity main warning: clock gap, unexpected stream discontinuity ... thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071116/b5c94704/attachment.html From finlayson at live555.com Fri Nov 16 09:43:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 16 Nov 2007 09:43:41 -0800 Subject: [Live-devel] Fw: VLC Crashing and Infos debug live555 In-Reply-To: <003d01c82876$264d20e0$6401a8c0@rhea> References: <003d01c82876$264d20e0$6401a8c0@rhea> Message-ID: I don't see any LIVE555-related problems here; you're going to have to ask a VLC mailing list for help. Anyway, I suspect that you're mainly seeing network packet loss. Note that JPEG is not a very efficient codec for network streaming. If network bandwidth is a problem, then other codecs (e.g., MPEG-4, H.264) are much better. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chang.yiwen at tw.panasonic.com Sun Nov 18 22:46:01 2007 From: chang.yiwen at tw.panasonic.com (Chang,Yi-Wen) Date: Mon, 19 Nov 2007 14:46:01 +0800 Subject: [Live-devel] about duration time Message-ID: <011201c82a77$daa30250$59085a0a@userd7c6bde7c0> Dear, >>I supposed the duration time is the time of successive frames to be sends. > Yes. >>But, I view MultiFramedRTPSink.cpp code, the duration time is used >>to calculate the time at which the next packet is sent. >> If so, what should I consider to calculate the duration time? >Because you are streaming from a live source, each frame will not be >delivered until the time that it's ready to be streamed. In this >case, it's OK to not set "fDurationInMicroseconds" at all. In fact, I have a need that is to send some control packets during frames, not disturb original RTP traffic. So I need to set duration time even if I am streaming from live source. My question is: If frame size of a video stream is larger than RTP packet size, the frame has to be fragmented. Since duration time is used to calculate the time at which the next packet is sent, it implies that the overflow data of a frame(carried in next packets) would delay? If so, frame rate is still suitable to be used to calculate duration time (for a video file, not live source)? Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071118/77a821fc/attachment.html From finlayson at live555.com Mon Nov 19 00:39:32 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Nov 2007 01:39:32 -0700 Subject: [Live-devel] about duration time In-Reply-To: <011201c82a77$daa30250$59085a0a@userd7c6bde7c0> References: <011201c82a77$daa30250$59085a0a@userd7c6bde7c0> Message-ID: >My question is: >If frame size of a video stream is larger than RTP packet size, the >frame has to be fragmented. >Since duration time is used to calculate the time at which the next >packet is sent, >it implies that the overflow data of a frame(carried in next >packets) would delay? No - our code ("MultiFramedRTPSink.cpp") automatically takes care of this. All you need do is provide the duration of each supplied frame. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071119/ce795912/attachment.html From satkin05 at harris.com Mon Nov 19 12:08:40 2007 From: satkin05 at harris.com (Atkins, Sarah) Date: Mon, 19 Nov 2007 15:08:40 -0500 Subject: [Live-devel] RTP/RTSP Streaming Trouble Message-ID: <9508D02DE5AE0247941E26B58C7FEC0A62CB0D@mlbe2k5.cs.myharris.net> I'm working on getting a non-proprietary video stream for your access. However, in the meantime this is the primary message that's shown in VLC's message area during playback of one of the culprit video files: main warning: PTS is out of range (38474978), dropping buffer main warning: PTS is out of range (38438112), dropping buffer main warning: PTS is out of range (39183112), dropping buffer main warning: PTS is out of range (39942378), dropping buffer main warning: PTS is out of range (40608512), dropping buffer main warning: PTS is out of range (41337656), dropping buffer main warning: PTS is out of range (41925789), dropping buffer main warning: PTS is out of range (42888923), dropping buffer main warning: PTS is out of range (43477056), dropping buffer main warning: PTS is out of range (44878189), dropping buffer main warning: PTS is out of range (45028323), dropping buffer main warning: PTS is out of range (45616467), dropping buffer main warning: PTS is out of range (46735600), dropping buffer main warning: late picture skipped (47056645) It seems to print this message for every picture. Have you seen this before? Thanks!! -Sarah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071119/f0a7213b/attachment-0001.html From eyal.b at mavix.com Mon Nov 19 13:38:47 2007 From: eyal.b at mavix.com (eyal.b at mavix.com) Date: Mon, 19 Nov 2007 23:38:47 +0200 Subject: [Live-devel] MORE: Memory leaks in DarwinInjector.cpp In-Reply-To: References: <20071114210137.434da24e.aluigi@autistici.org><003401c82845$d6cea320$0a0ac8c0@mavix.net.il> Message-ID: <003b01c82af4$935d4810$0a0ac8c0@mavix.net.il> Yes you are right about item 2, the one that allocates is the one to de-allocate. The problem is that RTSPClient uses the MediaSubsession as it own repository for the allocated sub-session id. It only keeps a copy (strDup) of the last sub-session id. So it has no way of keeping track of what it had allocated. I have no "Object Oriented" remedy to that, just the knowledge of the need to call TearDown() before destroying a session object. Eyal Beit-Halachmi -----Original Message----- From: Ross Finlayson [mailto:finlayson at live555.com] Sent: Friday, November 16, 2007 7:05 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] MORE: Memory leaks in DarwinInjector.cpp The next version of gthe "LIVE555 Streaming Media" code - to be released probably within a day or so - will include your suggested changes 1) and 3). However, I won't be making your suggested change 2/. The "sessionId" field of "MediaSession" is one of a few fields that are not managed by the "MediaSession" object itself (note "MediaSession.hh"). Instead, it is managed/assigned externally. (See, e.g., "RTSPClient.cpp".) If you allocate memory to assign to the "sessionId" field, then you are also responsible for deleting that memory. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 19 20:02:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 19 Nov 2007 21:02:57 -0700 Subject: [Live-devel] RTP/RTSP Streaming Trouble In-Reply-To: <9508D02DE5AE0247941E26B58C7FEC0A62CB0D@mlbe2k5.cs.myharris.net> References: <9508D02DE5AE0247941E26B58C7FEC0A62CB0D@mlbe2k5.cs.myharris.net> Message-ID: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C82AE7.FA66CA11" > >I'm working on getting a non-proprietary video stream for your >access. However, in the meantime this is the primary message that's >shown in VLC's message area during playback of one of the culprit >video files: > >main warning: PTS is out of range (38474978), dropping buffer >main warning: PTS is out of range (38438112), dropping buffer >main warning: PTS is out of range (39183112), dropping buffer >main warning: PTS is out of range (39942378), dropping buffer >main warning: PTS is out of range (40608512), dropping buffer >main warning: PTS is out of range (41337656), dropping buffer >main warning: PTS is out of range (41925789), dropping buffer >main warning: PTS is out of range (42888923), dropping buffer >main warning: PTS is out of range (43477056), dropping buffer >main warning: PTS is out of range (44878189), dropping buffer >main warning: PTS is out of range (45028323), dropping buffer >main warning: PTS is out of range (45616467), dropping buffer >main warning: PTS is out of range (46735600), dropping buffer >main warning: late picture skipped (47056645) These are VLC errors, and do not seem to be caused by any problems with the "LIVE555 Streaming Media" software. You will need to ask a VLC mailing list about these. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071119/5a2cf61f/attachment.html From satkin05 at harris.com Tue Nov 20 10:46:06 2007 From: satkin05 at harris.com (Atkins, Sarah) Date: Tue, 20 Nov 2007 13:46:06 -0500 Subject: [Live-devel] RTP/RTSP Streaming Trouble Message-ID: <9508D02DE5AE0247941E26B58C7FEC0A62CB12@mlbe2k5.cs.myharris.net> Hi Ross, I have a test video file to you to use. It is located at ftp.gcsd.harris.com/public, filename "live555_test_stream.ts". This is a blind FTP server, therefore it will only accept requests for exactly that filename. Also, I believe the policy is to remove the files nightly, so please let me know if you need me to upload the file again for your access. Hopefully you can reproduce what I've been seeing. Thanks! -Sarah -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071120/e7f412b7/attachment.html From finlayson at live555.com Tue Nov 20 21:11:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 20 Nov 2007 22:11:20 -0700 Subject: [Live-devel] RTP/RTSP Streaming Trouble In-Reply-To: <9508D02DE5AE0247941E26B58C7FEC0A62CB12@mlbe2k5.cs.myharris.net> References: <9508D02DE5AE0247941E26B58C7FEC0A62CB12@mlbe2k5.cs.myharris.net> Message-ID: Sarah, Thanks for posting this file. I have downloaded it, and have been able to reproduce the problem that you were having when you tried streaming it. I am investigating this now, and will post to the list when I've figured out the problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From brainlai at gmail.com Wed Nov 21 04:30:54 2007 From: brainlai at gmail.com (Brain Lai) Date: Wed, 21 Nov 2007 20:30:54 +0800 Subject: [Live-devel] Lost consideration about SSM on Windows XP with VS6. Message-ID: Dear Sir: The fourth parameter "forceMulticastOnUnspecified" of RTSPClient::setupMediaSubsession() will guide the client agent to setup a multicast subsession if the IP address is not specified in SDP. The client will then join the multicast group later by calling subsession.setDestinations(fServerAddress) which then invokes fRTPSocket->changeDestinationParameters(destAddr, destPort, destTTL). However, Groupsock::changeDestinationParameters() doesn't consider if it has a source filter address specified in SDP and just try a regular multicast address group leave and join. Hence, I suggest to modify as follows: Groupsock::changeDestinationParameters(...) { ... ... if (newDestAddr.s_addr != 0) { if (newDestAddr.s_addr != destAddr.s_addr && IsMulticastAddress(newDestAddr.s_addr)) { // If the new destination is a multicast address, then we assume that // we want to join it also. (If this is not in fact the case, then // call "multicastSendOnly()" afterwards.) if (isSSM()) { if (!socketLeaveGroupSSM(env(), socketNum(), destAddr.s_addr, sourceFilterAddress().s_addr)) socketLeaveGroup(env(), socketNum(), destAddr.s_addr); else socketLeaveGroup(env(), socketNum(), groupAddress().s_addr); if (!socketJoinGroupSSM(env(), socketNum(), newDestAddr.s_addr, sourceFilterAddress().s_addr)) { if (DebugLevel >= 3) { env() << *this << ": SSM join failed: " << env().getResultMsg(); env() << " - trying regular join instead\n"; } if (!socketJoinGroup(env(), socketNum(), newDestAddr.s_addr)) { if (DebugLevel >= 1) env() << *this << ": failed to join group: " << env().getResultMsg() << "\n"; } } } else { socketLeaveGroup(env(), socketNum(), destAddr.s_addr); socketJoinGroup(env(), socketNum(), newDestAddr.s_addr); } } destAddr.s_addr = newDestAddr.s_addr; } ... } Besides, the ws2tcpip.h provided in a newly installed Visual Studio C++ 6 doesn't define IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP so the following conditional macro in GroupHelper.cpp wiill define them as wrong values on Windows. #ifdef LINUX #define IP_ADD_SOURCE_MEMBERSHIP 39 #define IP_DROP_SOURCE_MEMBERSHIP 40 #else #define IP_ADD_SOURCE_MEMBERSHIP 25 // should be 15 on Windows #define IP_DROP_SOURCE_MEMBERSHIP 26 // should be 16 on Windows #endif Therefore, I suggest modify the above as the following: #ifdef LINUX #define IP_ADD_SOURCE_MEMBERSHIP 39 #define IP_DROP_SOURCE_MEMBERSHIP 40 #elif defined(WINNT) || defined(_WINNT) #define IP_ADD_SOURCE_MEMBERSHIP 15 /* join IP group/source */ #define IP_DROP_SOURCE_MEMBERSHIP 16 /* leave IP group/source */ #define IP_BLOCK_SOURCE 17 /* block IP group/source */ #define IP_UNBLOCK_SOURCE 18 /* unblock IP group/source */ #define IP_PKTINFO 19 /* receive packet information for ipv4*/ #define IP_RECEIVE_BROADCAST 22 /* allow/block broadcast reception */ #else #define IP_ADD_SOURCE_MEMBERSHIP 25 #define IP_DROP_SOURCE_MEMBERSHIP 26 #endif BR Brain Lai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071121/9b686c8d/attachment.html From finlayson at live555.com Wed Nov 21 09:10:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 21 Nov 2007 10:10:45 -0700 Subject: [Live-devel] Lost consideration about SSM on Windows XP with VS6. In-Reply-To: References: Message-ID: >The fourth parameter "forceMulticastOnUnspecified" of >RTSPClient::setupMediaSubsession() will guide the client agent to >setup a multicast subsession if the IP address is not specified in >SDP. The client will then join the multicast group later by calling >subsession.setDestinations(fServerAddress) which then invokes >fRTPSocket->changeDestinationParameters(destAddr, destPort, >destTTL). However, Groupsock::changeDestinationParameters() doesn't >consider if it has a source filter address specified in SDP and just >try a regular multicast address group leave and join. I don't follow this. The "forceMulticastOnUnspecified" hack - which is used only if a multicast address was *not* specified in SDP - cannot possibly be expected to work for SSM sessions, because, for such sessions, the source filter address can only be specified within a SDP description. > >Hence, I suggest to modify as follows: > >Groupsock::changeDestinationParameters(...) { I have no plans to change the existing code at this time. >Besides, the ws2tcpip.h provided in a newly installed Visual Studio >C++ 6 doesn't define IP_ADD_SOURCE_MEMBERSHIP and >IP_DROP_SOURCE_MEMBERSHIP so the following conditional macro in >GroupHelper.cpp wiill define them as wrong values on Windows. > >#ifdef LINUX >#define IP_ADD_SOURCE_MEMBERSHIP 39 >#define IP_DROP_SOURCE_MEMBERSHIP 40 >#else >#define IP_ADD_SOURCE_MEMBERSHIP 25 // should be 15 on Windows >#define IP_DROP_SOURCE_MEMBERSHIP 26 // should be 16 on Windows >#endif > >Therefore, I suggest modify the above as the following: > >#ifdef LINUX >#define IP_ADD_SOURCE_MEMBERSHIP 39 >#define IP_DROP_SOURCE_MEMBERSHIP 40 >#elif defined(WINNT) || defined(_WINNT) >#define IP_ADD_SOURCE_MEMBERSHIP 15 /* join IP group/source */ >#define IP_DROP_SOURCE_MEMBERSHIP 16 /* leave IP group/source */ >#else >#define IP_ADD_SOURCE_MEMBERSHIP 25 >#define IP_DROP_SOURCE_MEMBERSHIP 26 >#endif Can anyone else (preferably someone who doesn't use a @gmail.com email address :-) confirm that Windows uses the values 25 and 26 for IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP? (But why doesn't WIndows actually define those constants??) >#define IP_BLOCK_SOURCE 17 /* block IP group/source */ >#define IP_UNBLOCK_SOURCE 18 /* unblock IP group/source */ >#define IP_PKTINFO 19 /* receive packet information for ipv4*/ >#define IP_RECEIVE_BROADCAST 22 /* allow/block broadcast reception */ No, I won't be defining those, because they're not used anywhere in our code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bagger-devel at medi-a.ru Wed Nov 21 10:25:55 2007 From: bagger-devel at medi-a.ru (bagger-devel at medi-a.ru) Date: Wed, 21 Nov 2007 21:25:55 +0300 Subject: [Live-devel] live555MediaServer and RAW UDP streaming Message-ID: <1159161375.20071121212555@medi-a.ru> Hello, mailinglist! Is it possible to make live555MediaServer stream with RAW UDP datagrams, not with RTP? If so, how can i do this? Thanks for help! -- Best regards, bagger-devel mailto:bagger-devel at medi-a.ru From vmehrotra at rgbnetworks.com Wed Nov 21 17:07:20 2007 From: vmehrotra at rgbnetworks.com (Vivek Mehrotra) Date: Wed, 21 Nov 2007 17:07:20 -0800 Subject: [Live-devel] fOurServerMediaSession Message-ID: <9964EE0EF7D1234C8ADD051DB304E0CC1AE8B7@MSG10001.rgbnetworks.com> Hi, Can you please elaborate on how fOurServerMediaSession is updated for multiple client sessions. If I have two setup requests from the same source with all else the same but different transport parameters, does the second request override the first? Is there a limitation on the number of client connections? Do we have a incrementReferencecount to account for the same urlPreSuffix but different urlSuffixes(tracks)? Is a mediasubsession created for every increment of this count? When would you choose to create a DynamicRTSPServer as opposed to testOnDemandRTSPServer? Thanks in advance, vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071121/638a1797/attachment.html From niki at redsk.net Wed Nov 21 18:21:29 2007 From: niki at redsk.net (Nicola Bova - Redsk) Date: Thu, 22 Nov 2007 03:21:29 +0100 Subject: [Live-devel] RTSPServer Authentication: Basic Message-ID: <20071122022129.GA17140@redsk.lan> Hi all, I'm implementing a streamer server and I've defined my own sublass of "RTSPServer" to get a custom behavior. Now I'm managing authentication and I have to implement a Basic auth ("Authentication: Basic" instead of "Authentication: Digest") in order to support a legacy client. Which is the cleanest way to implement such a thing? Digging into the code I found out that the digest auth is managed in Boolean RTSPServer::RTSPClientSession::authenticationOK (char const* cmdName, char const* cseq, char const* fullRequestStr) so I'm wondering if I should redefine a subclass of "RTSPClientSession" with a redefined "authenticationOK()" (which is not virtual...) or there is a better solution. Thanks a lot Niki From brainlai at gmail.com Wed Nov 21 20:13:25 2007 From: brainlai at gmail.com (Brain Lai) Date: Thu, 22 Nov 2007 12:13:25 +0800 Subject: [Live-devel] Lost consideration about SSM on Windows XP with VS6. In-Reply-To: References: Message-ID: 2007/11/22, Ross Finlayson : > > I don't follow this. The "forceMulticastOnUnspecified" hack - which > is used only if a multicast address was *not* specified in SDP - > cannot possibly be expected to work for SSM sessions, because, for > such sessions, the source filter address can only be specified within > a SDP description. > I have no plans to change the existing code at this time. > > Do you mean according to RFC 2326 that an RTSP server should or must explicitly specify whether the session is unicast or multicast (by providing a multicast address) rather than give the client a chance to choose either? And if the server doesn't specify the multicast address in its SDP, the client should only try a regular multicast setup(join/leave) even if the SDP has source-filter attribute? >Besides, the ws2tcpip.h provided in a newly installed Visual Studio > >C++ 6 doesn't define IP_ADD_SOURCE_MEMBERSHIP and > >IP_DROP_SOURCE_MEMBERSHIP so the following conditional macro in > >GroupHelper.cpp wiill define them as wrong values on Windows. > > > >#ifdef LINUX > >#define IP_ADD_SOURCE_MEMBERSHIP 39 > >#define IP_DROP_SOURCE_MEMBERSHIP 40 > >#else > >#define IP_ADD_SOURCE_MEMBERSHIP 25 // should be 15 on Windows > >#define IP_DROP_SOURCE_MEMBERSHIP 26 // should be 16 on Windows > >#endif > > > >Therefore, I suggest modify the above as the following: > > > >#ifdef LINUX > >#define IP_ADD_SOURCE_MEMBERSHIP 39 > >#define IP_DROP_SOURCE_MEMBERSHIP 40 > >#elif defined(WINNT) || defined(_WINNT) > >#define IP_ADD_SOURCE_MEMBERSHIP 15 /* join IP group/source */ > >#define IP_DROP_SOURCE_MEMBERSHIP 16 /* leave IP group/source */ > >#else > >#define IP_ADD_SOURCE_MEMBERSHIP 25 > >#define IP_DROP_SOURCE_MEMBERSHIP 26 > >#endif > > Can anyone else (preferably someone who doesn't use a @gmail.com > email address :-) confirm that Windows uses the values 25 and 26 for > IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP? (But why > doesn't WIndows actually define those constants??) Sorry, I am that guy using a @gmail ^_~ It's easy to reason. MSDNtells that MS supports IP_ADD_SOURCE_MEMBERSHIP and IP_DROP_SOURCE_MEMBERSHIP since Windows XP but Visual C++ 6.0 was release early(1998) before XP(2001). The ws2tcpip.h is updated in newer versions of Visual Studio or the Platform SDK. See ws2tcpip.hprovided by mingw or that by wine online for their values for Windows. >#define IP_BLOCK_SOURCE 17 /* block IP group/source */ > >#define IP_UNBLOCK_SOURCE 18 /* unblock IP group/source */ > >#define IP_PKTINFO 19 /* receive packet information for > ipv4*/ > >#define IP_RECEIVE_BROADCAST 22 /* allow/block broadcast reception > */ > > No, I won't be defining those, because they're not used anywhere in our > code. > -- They are mentioned just in case. It's welcome to ignore them currently. BR. Brain Lai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071121/3b1fafa0/attachment.html From bonheur.cheung at seldes.com Thu Nov 22 00:30:31 2007 From: bonheur.cheung at seldes.com (cheung bonheur) Date: Thu, 22 Nov 2007 09:30:31 +0100 Subject: [Live-devel] FrameSize Message-ID: <000f01c82ce1$f219a5d0$6401a8c0@rhea> Hello Ross, I found the probleme of crashing vlc! It is because my jpegframesource was too large for VLC ! VLC accept to stream without bugs when the jpegframesourcesize is least than 65535 bytes and i send 70916 bytes per frame! So i attempt to solve this trouble and i wish to know how can i says to live555 to send several packets rtp for one frame ? I use the JPEGVideoRTPSink to receive correctly and OutPacketBuffer::maxSize. thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071122/84550c3a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Cheung bonheur.vcf Type: text/x-vcard Size: 136 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20071122/84550c3a/attachment.vcf From bonheur.cheung at seldes.com Thu Nov 22 07:09:45 2007 From: bonheur.cheung at seldes.com (cheung bonheur) Date: Thu, 22 Nov 2007 16:09:45 +0100 Subject: [Live-devel] MultiFrameRTPSource::doGetNextFrame1(): The total received frame size exceeds to buffer client ...... Message-ID: <017b01c82d19$b7ad0120$6401a8c0@rhea> Hello Ross, As you can see in previous mail, my problem is only at the beginning received Jpeg frame. This is because the size of frame is more than 65535 and after that vlc auto adjust it. But it still the bugs randomly when you want open the video stream. The question is how can i fragment correctly a packet size less than 65535 ? I use OutPacketBuffer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071122/098d67af/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Cheung bonheur.vcf Type: text/x-vcard Size: 136 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20071122/098d67af/attachment.vcf From finlayson at live555.com Thu Nov 22 08:30:56 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Nov 2007 09:30:56 -0700 Subject: [Live-devel] live555MediaServer and RAW UDP streaming In-Reply-To: <1159161375.20071121212555@medi-a.ru> References: <1159161375.20071121212555@medi-a.ru> Message-ID: >Is it possible to make live555MediaServer stream with RAW UDP >datagrams, not with RTP? Yes, the server will do this already, but only for MPEG Transport Streams, and only if the client explicitly requests it (e.g., Amino set-top boxes, which support only raw UDP). Note that if you are developing your own client, then you should request standard RTP streaming. (Raw UDP streaming via RTSP is not a standard, even though our server partially supports it.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bonheur.cheung at seldes.com Thu Nov 22 08:37:34 2007 From: bonheur.cheung at seldes.com (cheung bonheur) Date: Thu, 22 Nov 2007 17:37:34 +0100 Subject: [Live-devel] Control RTP packets and size Message-ID: <018f01c82d26$009a52a0$6401a8c0@rhea> Hello Ross, i try to send for example two packet RTP for one frame (image jpeg) ... Each packet has a size less than 64Ko and my frame has > 70ko How can i use Live to do that ? Before i use JPEGVideoSource class and i override this to send one packet rtp to one frame. I think the callback of live555 ( JPEGVideoSource::doGetNextFrame()) is only for each frame. is that right ? So if i override JPEGVideoRTPSource class ? is allow me to access to each rtp packet to control for example the startting rtp packet and the ending packet ? is that the callback doGetNextFrame is turnning for each packet to allow me to apply the rfc 2435 ? If you suggest me another and easy way with JPEGVideoSource with OutPacketBuffer::maxSize ? At last, i wish to know about the old variable OutPacketBuffer::numPacketsLimit ? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071122/0879cfb6/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Cheung bonheur.vcf Type: text/x-vcard Size: 136 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20071122/0879cfb6/attachment-0001.vcf From finlayson at live555.com Thu Nov 22 08:33:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Nov 2007 09:33:43 -0700 Subject: [Live-devel] Lost consideration about SSM on Windows XP with VS6. In-Reply-To: References: Message-ID: >Do you mean according to RFC 2326 that an RTSP server should or must >explicitly specify whether the session is unicast or multicast (by >providing a multicast address) rather than give the client a chance >to choose either? Yes. It is always the server - not the client - that decides whether a stream is unicast or multicast. The "forceMulticastOnUnspecified" hack was developed only to accommodate some unconventional servers that always streamed multicast, but did not put the address in the SDP description. However, as I noted earlier, that won't work for SSM streams. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Nov 22 08:40:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Nov 2007 09:40:39 -0700 Subject: [Live-devel] MultiFrameRTPSource::doGetNextFrame1(): The total received frame size exceeds to buffer client ...... In-Reply-To: <017b01c82d19$b7ad0120$6401a8c0@rhea> References: <017b01c82d19$b7ad0120$6401a8c0@rhea> Message-ID: >As you can see in previous mail, my problem is only at the beginning >received Jpeg frame. >This is because the size of frame is more than 65535 and after that >vlc auto adjust it. Yes, VLC is working correctly here. If you want to change the initial limit of 65535, you will need to modify VLC. >The question is how can i fragment correctly a packet size less than 65535 ? Our code *already* correctly fragments JPEG framesn into multiple RTP packets. (Note that RTP packets are typically about 1500 bytes - i.e., much smaller than your JPEG frames.) The problem you're seeing is that you are losing some of these RTP packets - which usually means that the receiving client will discard the entire JPEG frame. As I said before, JPEG is a poor codec to be using for streaming video. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071122/915af7e4/attachment.html From rtc_ru at mail.ru Thu Nov 22 09:25:15 2007 From: rtc_ru at mail.ru (=?windows-1251?B?wO3g8u7r6Okg0OXs7eXi?=) Date: Thu, 22 Nov 2007 23:25:15 +0600 Subject: [Live-devel] Trouble with Amino STB Message-ID: <1563204654.20071122232515@mail.ru> Hi, all! I have a problem with AMINO STB. In original version of LiveMediaServer files are in the same folder that a exe-file. I have modified code of DynamicRTSPServer.cpp for read folder list form config.ini file and getting unique file from this folder list. ============================cut here================================= static ServerMediaSession* createNewSMS(UsageEnvironment& env, char const* fileName, FILE* fid); // forward char fullname[512]; ServerMediaSession* DynamicRTSPServer::lookupServerMediaSession(char const *streamName) { // First, check whether the specified "streamName" exists as a local file: /* GetPrivateProfileString("programs", "dir_files", "", dir_files, sizeof(dir_files), ".\\config.ini"); memset(dir_files, '\0', sizeof(dir_files)); memset(targetFile, '\0', sizeof(targetFile)); targetFile[0] = '.'; targetFile[1] == '\\'; strcat(targetFile, dir_files); strcat(targetFile, "\\"); strcat(targetFile, streamName); */ //////Here we read folder list from config file //////for example: dir_files=C:\testdir1;C:\testdir2;C:\testdir1\test; char strName[512]; memset(strName, '\0', 512); strcat(strName, streamName); char* tmp = strName; char* file = strName; while(true) { tmp = strchr(file, '\\'); if(tmp == 0) break; else { tmp+=1; file = tmp; } } // in *file* we have real file name without path (full path have been deleted in previous block char name[8192]; GetPrivateProfileString("programs", "dir_files", "", name, sizeof(name), "config.ini"); char **dirs; int nameLen = strlen(name); int semicolonCount = 0; for(int i = 0; i < nameLen; i++) { if(name[i] == ';') { semicolonCount++; } } dirs = new char*[semicolonCount]; // folder's array for(int i = 0; i < semicolonCount; i++) { dirs[i] = new char[512]; // max length of full name memset(dirs[i], '\0', 512); } int i = 0; for(int j = 0; j < nameLen; j++) { if(name[j] == ';') { i++; } else { dirs[i][strlen(dirs[i])] = name[j]; } } ///////////now in dirs we have folder list/////////////////////// ///////////and search requested file there///////////////////////// FILE* fid; // our file for(int i = 0; i < semicolonCount; i++) { memset(fullname, '\0', 512); strcpy(fullname, dirs[i]); strcat(fullname, "\\"); strcat(fullname, file); // in *fullname* stored full file name (with path) which one may be presented in folders // if file exists - break the cycle fid = fopen(fullname, "rb"); if(fid) { break; } } ////////////////////////////////////////////////////////////////////////// Boolean fileExists = fid != NULL; ============================cut here================================= NOW! The VLC Player perfectly reads files - so server starts thread for it. BUT!!!! AMINO STB can't request any file - so server not to start any thread for it I've view some logs and have seen that AMINO don't send DESCRIBE command therefore VLC do it. Which mistake I have done and how to solve my problem? With best regards, Anatoliy p.S. Sorry for my bad English From rtc_ru at mail.ru Thu Nov 22 09:34:53 2007 From: rtc_ru at mail.ru (=?windows-1251?B?wO3g8u7r6Okg0OXs7eXi?=) Date: Thu, 22 Nov 2007 23:34:53 +0600 Subject: [Live-devel] Restrictions Message-ID: <1509883266.20071122233453@mail.ru> Hi, all! May I asked once more? =) 1. How to make session count restriction? 2. How to deny access from listed IP-adresses? With best regards, Anatoliy From elphel at gmail.com Thu Nov 22 12:55:04 2007 From: elphel at gmail.com (Andrey Filippov) Date: Thu, 22 Nov 2007 13:55:04 -0700 Subject: [Live-devel] working with MJPEG streams with frame width > 2040 (and even 2048) pixels. Message-ID: <30288c370711221255k4ea2e55mdfd503f33f55262e@mail.gmail.com> Ross, Some time ago we needed a patch to be able to receive MJPEG stream from our cameras (3MPix - 2048x1536) at that time. That was implemented and RTP width of 0 was treated as 2048. But sensors get bigger and the that is not enough anymore. Elphel cameras provide the frame size information in SDP file ("a=x-dimensions:width,height") and Spectr implemented a patch that does that - if the dimension is 0, it uses the data from SDP file (like with other video formats). Patch is tested with MPlayer with 5MPix MJPEG video stream from Elphel model 353 camera, the only change in the MPlayer itself was to replace that notorious "maximal frame size of 50,000" (we used just width*height for the frame buffer size). Patch is available at Elphel project page at Sourceforge ( http://sourceforge.net/project/showfiles.php?group_id=105686&package_id=120785&release_id=555832) - can you please take a look at it ? Andrey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071122/89a3e278/attachment.html From finlayson at live555.com Thu Nov 22 15:48:10 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Nov 2007 16:48:10 -0700 Subject: [Live-devel] Restrictions In-Reply-To: <1509883266.20071122233453@mail.ru> References: <1509883266.20071122233453@mail.ru> Message-ID: >1. How to make session count restriction? You would need to modify the "RTSPServer" code to do this. > >2. How to deny access from listed IP-adresses? This is easy. Define your own subclass of "RTSPServer" that redefines the virtual function "specialClientAccessCheck()". That's what that function is meant for, -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Nov 22 15:53:37 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 22 Nov 2007 16:53:37 -0700 Subject: [Live-devel] Trouble with Amino STB In-Reply-To: <1563204654.20071122232515@mail.ru> References: <1563204654.20071122232515@mail.ru> Message-ID: >I have a problem with AMINO STB. Note that the Amino STB is not our product. This is not the best mailing list to ask about problems with Amino products. >I have modified code In general, once you've modified the supplied code, you can't expect much help on this mailing list. Therefore, you should first do your testing with the original, unmodified code. > I've view some logs and have seen that AMINO don't send DESCRIBE > command Yes it does - if you type a "rtsp://" URL into the Amino STB. (Make sure that it is configured to use "nCube" mode.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bagger-devel at medi-a.ru Thu Nov 22 23:50:26 2007 From: bagger-devel at medi-a.ru (bagger-devel at medi-a.ru) Date: Fri, 23 Nov 2007 10:50:26 +0300 Subject: [Live-devel] live555MediaServer and RAW UDP streaming Message-ID: <425434606