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.20071123105026@medi-a.ru> Hello again, mailinglist! One more question: has implementation of RTSPServer supports any nat traversal algorithms? I know that native RFC 2326 doesn't support such a feature, but some mmusic drafts describe methods to do this (like Symmetric RTP or STUN). Thanks for answer! -- Best regards, bagger-devel mailto:bagger-devel at medi-a.ru From finlayson at live555.com Fri Nov 23 00:48:42 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 23 Nov 2007 01:48:42 -0700 Subject: [Live-devel] live555MediaServer and RAW UDP streaming In-Reply-To: <425434606.20071123105026@medi-a.ru> References: <425434606.20071123105026@medi-a.ru> Message-ID: >One more question: has implementation of RTSPServer supports any >nat traversal algorithms? I know that native RFC 2326 doesn't support >such a feature, but some mmusic drafts describe methods to do >this (like Symmetric RTP or STUN). Yes, but note, however, that these were designed primarily for SIP, and will need to be adapted/modified somewhat (by the IETF) for use by RTSP. When that is done, however, we will be adding support for this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mail at oliroll.de Sat Nov 24 23:19:35 2007 From: mail at oliroll.de (Oliver Roll) Date: Sun, 25 Nov 2007 08:19:35 +0100 Subject: [Live-devel] Player application Message-ID: <47492207.4090801@oliroll.de> Hello all, all of the receiver programs in liveMedia/testProgs are dumping their output to stdout or into files. What is the easiest way to display a video actually received via testMPEG1or2VideoReceiver for instance? Is vlc (which is a bit too complex for me on the first sight) the only software which can be used to benefit from the streaming-power of liveMedia? Thanks & regards, Oliver From finlayson at live555.com Sat Nov 24 23:30:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 24 Nov 2007 23:30:11 -0800 Subject: [Live-devel] Player application In-Reply-To: <47492207.4090801@oliroll.de> References: <47492207.4090801@oliroll.de> Message-ID: >all of the receiver programs in liveMedia/testProgs are dumping their >output to stdout or into files. >What is the easiest way to display a video actually received via >testMPEG1or2VideoReceiver for instance? Well, if you have a video player that can read from stdin, then you could pipe the video (from "testMPEG1or2VideoReceiver") into it. >Is vlc (which is a bit too complex for me on the first sight) There are prebuilt binary versions of VLC available on their web site. VLC is easy - just enter the appropriate "rtsp://" URL into its 'open' dialog. > the only >software which can be used to benefit from the streaming-power of liveMedia? No, there's also MPlayer (although VLC is better), and probably other media players as well. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mail at oliroll.de Sat Nov 24 23:57:18 2007 From: mail at oliroll.de (Oliver Roll) Date: Sun, 25 Nov 2007 08:57:18 +0100 Subject: [Live-devel] Player application In-Reply-To: References: <47492207.4090801@oliroll.de> Message-ID: <47492ADE.5060901@oliroll.de> Ross Finlayson schrieb: >> all of the receiver programs in liveMedia/testProgs are dumping their >> output to stdout or into files. >> What is the easiest way to display a video actually received via >> testMPEG1or2VideoReceiver for instance? > > Well, if you have a video player that can read from stdin, then you > could pipe the video (from "testMPEG1or2VideoReceiver") into it. > >> Is vlc (which is a bit too complex for me on the first sight) > > There are prebuilt binary versions of VLC available on their web site. Building standard VLC is not the problem. I added modifications to liveMedia to stream RTP/RTCP over SCTP instead of UDP. It's not really clear to me how vlc makes use of liveMedia. If I have a working liveMedia streamer and receiver application is building vlc with the modified liveMedia sufficient to use the new features in VLC? Probably not. Since my work took some time, I'm looking for an easy way to display the streamed videos. Piping is a good idea, I'll have to look which player accepts input via stdin. xine seems to support this. Regards, Oliver > > VLC is easy - just enter the appropriate "rtsp://" URL into its 'open' dialog. > >> the only >> software which can be used to benefit from the streaming-power of liveMedia? > > No, there's also MPlayer (although VLC is better), and probably other > media players as well. From yuri.l at mail.ru Sun Nov 25 22:20:43 2007 From: yuri.l at mail.ru (=?koi8-r?Q?=E0=D2=C9=CA_=EC.?=) Date: Mon, 26 Nov 2007 09:20:43 +0300 Subject: [Live-devel] Vorbis implementation Message-ID: Hello, I want to stream vorbis file through RTP using Live555. In order to testMP3Streamer, I guess that my target is to implement VorbisRTPSink class and VorbisFileSource class. And some questions in this connection: 1) VorbisRTPSink. Is these correct: unsigned VorbisAudioRTPSink::specialHeaderSize() const { return 4; } unsigned VorbisAudioRTPSink::frameSpecificHeaderSize() const { return 2; } 2) VorbisRTPSink. What should I write in doSpecialFrameHandling()? Is this a place where I should fill vorbis payload header? 3) VorbisRTPSink. Is there other functions which I should to implement? 4) I have no any ideas about redefinition of FrameFileSource class. Could you explain me please what should I do in the first place and what after? Thanks! From finlayson at live555.com Mon Nov 26 04:07:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 26 Nov 2007 04:07:57 -0800 Subject: [Live-devel] Vorbis implementation In-Reply-To: References: Message-ID: >Hello, >I want to stream vorbis file through RTP using Live555. In order to >testMP3Streamer, I guess that my target is to implement >VorbisRTPSink class and VorbisFileSource class. And some questions >in this connection: >1) VorbisRTPSink. Is these correct: > unsigned VorbisAudioRTPSink::specialHeaderSize() const { > return 4; > } Yes. > unsigned VorbisAudioRTPSink::frameSpecificHeaderSize() const { > return 2; > } This depends. Is the 2-byte "length" field in each Vorbis payload 'packet' already present in the source data? If so, then you should *not* redefine "frameSpecificHeaderSize()" (so that it will continue to return 0), because the data that you'll read from the source will already contain the length field. If, however, the 2-byte "length" field is *not* present in the source data, then you will have to add it yourself (in your "doSpecialFrameHandling()" implementation, by calling "setFrameSpecificHeaderBytes(ptr, 2)") >2) VorbisRTPSink. What should I write in doSpecialFrameHandling()? >Is this a place where I should fill vorbis payload header? Yes, this is where you will fill in the 4-byte Payload Header, by calling "setSpecialHeaderWord()". You should examine the existing "MultiFramedRTPSink" subclasses, to see how "doSpecialFrameHandling()" is implemented for various RTP payload formats. >3) VorbisRTPSink. Is there other functions which I should to implement? I don't think so, no. >4) I have no any ideas about redefinition of FrameFileSource class. >Could you explain me please what should I do in the first place and >what after? I'm sorry, I can't help you here, because I don't know anything about the file format that you'll be reading. If your audio frames are all fixed size (with the size known in advance), then you might not need to define a new class - just use "ByteStreamFileSource", with an appropriate non-zero "preferredFrameSize" parameter. If, however, your audio frames are variable-sized, then you will have to define a new class. You may be able to use the existing "*AudioFileSource" classes as a model. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Nov 26 22:16:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 26 Nov 2007 22:16:21 -0800 Subject: [Live-devel] RTP/RTSP Streaming Trouble In-Reply-To: <9508D02DE5AE0247941E26B58C7FEC0A62CB12@mlbe2k5.cs.myharris.net> References: <9508D02DE5AE0247941E26B58C7FEC0A62CB12@mlbe2k5.cs.myharris.net> Message-ID: >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. The problem with this file is that its PCR timestamps show that it is *extremely* VBR - far more than any reasonable stream should be. Because the streaming server uses these timestamps to figure out how to pace the outgoing stream (i.e., how much to delay after sending each network packet), extremely VBR timestamps messes up the streaming. More specifically, here's what's happening with your test file: As shown by its last timestamp, the stream is 37.78 seconds long, and contains 285866 188-byte Transport Packets. Therefore, on average, each Transport Packet should last about 132 ms. In practice, however, the stream's durations vary widely from this average. E.g., here are the first few PCR timestamps packet number diff from last PCR timestamp diff from last duration/packet ============ ========== ============ ========== ============= 132 132 0.002257 0.002257 17 ms 197 65 0.002727 0.000470 7 ms 262 65 0.003187 0.000460 7 ms 264 2 0.024481 0.021294 10647 ms 302 38 0.024754 0.000273 7 ms 322 20 0.024896 0.000142 7 ms 326 4 0.048253 0.023357 5839 ms 454 128 0.049158 0.000905 7 ms I hope you get the picture. The extremely large jumps in PCR timestamp are messing up our streaming server's estimate of how much time to delay after sending each network packet. I don't know whether you really intended this stream to be so extremely VBR, but our server is currently not able to properly stream files like this. -- 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/20071126/b077d4e5/attachment.html From live555 at dreier.cc Tue Nov 27 04:07:57 2007 From: live555 at dreier.cc (frederic_live555) Date: Tue, 27 Nov 2007 13:07:57 +0100 Subject: [Live-devel] Raw data streaming Message-ID: <474C089D.2050903@dreier.cc> Hi, I try to write an extension to live555 in order to stream (RTSP) raw data together with video and audio. so far I wrote : - a custom DrfSubsession (extds OnDemandServerMediaSubsession) which return a custom Sink and a custom Source. - a custom DrfRTPSink (extds MultiFramedRTPSink) but I do not actually understand its role. - a custom DrfRTPSource (extds FramedSource) which do nothing (I will implements doGetNextFrame1 later). Now, I am still trying to make it run but I do not understand : - what should I implement in RTPSink? what is its role (doSpecialFrameHandling & specialHeaderSize)? - how should I implement DrfSource::doGetNextFrame1() : may I use the whole frame (fTo to fTo+fMaxSize), is fDurationInMicroseconds important? I hope I was enough precis. Thank you for your help. Regards, Frederic From arnaki_sto_fourno at yahoo.gr Tue Nov 27 04:40:23 2007 From: arnaki_sto_fourno at yahoo.gr (Tasos Kyrillidis) Date: Tue, 27 Nov 2007 12:40:23 +0000 (GMT) Subject: [Live-devel] JPEG2000 and Motion JPEG2000 Message-ID: <840837.44999.qm@web26901.mail.ukl.yahoo.com> Hi, I am newbie in LIVE555 and i really dont know much of how things work. But i intend to study the source code. Before i do this, i would like to ask some questions to be sure about some things. I want to implement a Motion JPEG2000 Real-Time Transport system between two PCs (initially). I downloaded your source code and i saw that there isnt any support for JPEG2000 files. 1. Is it in your plans to implement it soon? If not, i would like to try it. But i cannot estimate the work it needs. 2. Besides Internet Drafts, is there any RTP implementation for JPEG2000? Finally and most important: 3. As i am newbie in this project, could you please tell me what exactly should i do? I mean a general plan about which files should i look into, which files affect this implementation, where to pay more attention? Thank for your time. I would be really graceful if somebody helped me. Tasos Kyrillidis --------------------------------- ?????????????? Yahoo! ?????????? ?? ?????????? ???? ???? (spam); ?? Yahoo! Mail ???????? ??? ???????? ?????? ????????? ???? ??? ??????????? ????????? http://login.yahoo.com/config/mail?.intl=gr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071127/6becd869/attachment.html From finlayson at live555.com Tue Nov 27 06:42:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Nov 2007 06:42:40 -0800 Subject: [Live-devel] Raw data streaming In-Reply-To: <474C089D.2050903@dreier.cc> References: <474C089D.2050903@dreier.cc> Message-ID: >- what should I implement in RTPSink? what is its role Your "RTPSink" subclass will implement a particular RTP payload format (defined by a IETF RFC or (preferably) standards-track Internet-Draft). Which RTP payload format do you wish to implement?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From live555 at dreier.cc Tue Nov 27 10:00:37 2007 From: live555 at dreier.cc (live555 at dreier.cc) Date: Tue, 27 Nov 2007 19:00:37 +0100 Subject: [Live-devel] Raw data streaming In-Reply-To: References: <474C089D.2050903@dreier.cc> Message-ID: <474C5B45.1000406@dreier.cc> Ross Finlayson a ?crit : >> - what should I implement in RTPSink? what is its role >> > > Your "RTPSink" subclass will implement a particular RTP payload > format (defined by a IETF RFC or (preferably) standards-track > Internet-Draft). Which RTP payload format do you wish to implement?? > Hi, I didn't had though about this before. I thought I could re-use an already implemented payload : now I have seen that I probably have to implement another one because they are mostly media oriented. I have not found the right RFC yet, I will look further tomorrow. Thank you, Frederic From julian at graphics.cs.uni-sb.de Tue Nov 27 10:33:23 2007 From: julian at graphics.cs.uni-sb.de (Julian Albesser) Date: Tue, 27 Nov 2007 19:33:23 +0100 Subject: [Live-devel] problems with packet loss Message-ID: <474C62F3.50707@graphics.cs.uni-sb.de> Hello! I am streaming H263plus and I have have two question concerning packet loss. At the receiving site at MediaSink, doing: rtp_source = dynamic_cast(fSource); rtp_source->curPacketRTPSeqNum() it seems that some packets get lost. There are always 12 packets arriving correctly and then 7 packets are lost. However, RTPTransmissionStats::totNumPacketsLost() tells me, that no packets are lost. Am I misinterpreting curPacketRTPSeqNum() ? Secondly, if I have bad network conditions (now even RTPTransmissionStats::totNumPacketsLost()) tells me, that packets get lost) I have the following problem: If I look at "presentationTime" at the receiver, the time difference between two arriving packets is always the same, even if packets in between got lost. E.g. if packets No.1 and 2 arrive in a row, then the time difference is x. But if packets No.1 and No.3 arrive in row because No.2 got lost, then their time difference is also x (although it should be 2*x) How does that come? One last general question: With H263plus, can I assume that one RTP-Frame always contains one Video-Frame? Thank you for any comments Julian Albesser From finlayson at live555.com Tue Nov 27 12:38:48 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Nov 2007 12:38:48 -0800 Subject: [Live-devel] problems with packet loss In-Reply-To: <474C62F3.50707@graphics.cs.uni-sb.de> References: <474C62F3.50707@graphics.cs.uni-sb.de> Message-ID: >Hello! > >I am streaming H263plus and I have have two question concerning packet loss. > >At the receiving site at MediaSink ??? RTP receivers use a MediaSource (subclass). RTP senders use a MediaSink (subclass) >, doing: > >rtp_source = dynamic_cast(fSource); >rtp_source->curPacketRTPSeqNum() > >it seems that some packets get lost. There are always 12 packets >arriving correctly and then 7 packets are lost. > >However, RTPTransmissionStats::totNumPacketsLost() tells me, that no >packets are lost. "RTPTransmissionStats" is used only by senders ("RTPSink"s). At the receiving end ("RTPSource"s), you should look at "RTPReceptionStats". > >Am I misinterpreting curPacketRTPSeqNum() ? Possibly. Remember that more than one incoming RTP packet can make up a complete video frame, but that "curPacketRTPSeqNum()" returns only the sequence number of the *last-received* RTP packet. (This is why "curPacketRTPSeqNum()" should not really be exposed as a public member function in the API; sometime in the future, it will likely be removed.) >Secondly, if I have bad network conditions (now even >RTPTransmissionStats::totNumPacketsLost()) tells me, that packets get >lost) I have the following problem: > >If I look at "presentationTime" at the receiver, the time difference >between two arriving packets is always the same, even if packets in >between got lost. E.g. if packets No.1 and 2 arrive in a row, then the >time difference is x. But if packets No.1 and No.3 arrive in row >because No.2 got lost, then their time difference is also x (although >it should be 2*x) How does that come? I don't know, but perhaps you are not setting correct presentation times in your sender?? > >One last general question: With H263plus, can I assume that one >RTP-Frame always contains one Video-Frame? No. Large frames may be fragmented over several RTP packets. (See above.) Note also that packet loss can be caused by insufficiently large socket reception buffers in the receiver's OS. See for a tip on how you may be able to overcome this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From brickyard at codetyrant.com Tue Nov 27 14:47:50 2007 From: brickyard at codetyrant.com (Race Vanderdecken) Date: Tue, 27 Nov 2007 17:47:50 -0500 Subject: [Live-devel] live-devel Digest, Vol 49, Issue 13 In-Reply-To: References: Message-ID: <1196203670.6713.0.camel@ipem002> On Sat, 2007-11-24 at 23:37 -0800, live-devel-request at ns.live555.com wrote: > Send live-devel mailing list submissions to > live-devel at lists.live555.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.live555.com/mailman/listinfo/live-devel > or, via email, send a message with subject or body 'help' to > live-devel-request at lists.live555.com > > You can reach the person managing the list at > live-devel-owner at lists.live555.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of live-devel digest..." > > > Today's Topics: > > 1. Re: Lost consideration about SSM on Windows XP with VS6. > (Ross Finlayson) > 2. Re: MultiFrameRTPSource::doGetNextFrame1(): The total > received frame size exceeds to buffer client ...... (Ross Finlayson) > 3. Trouble with Amino STB (???????? ??????) > 4. Restrictions (???????? ??????) > 5. working with MJPEG streams with frame width > 2040 (and even > 2048) pixels. (Andrey Filippov) > 6. Re: Restrictions (Ross Finlayson) > 7. Re: Trouble with Amino STB (Ross Finlayson) > 8. live555MediaServer and RAW UDP streaming (bagger-devel at medi-a.ru) > 9. Re: live555MediaServer and RAW UDP streaming (Ross Finlayson) > 10. Player application (Oliver Roll) > 11. Re: Player application (Ross Finlayson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 Nov 2007 09:33:43 -0700 > From: Ross Finlayson > Subject: Re: [Live-devel] Lost consideration about SSM on Windows XP > with VS6. > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > >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/ > > > ------------------------------ > > Message: 2 > Date: Thu, 22 Nov 2007 09:40:39 -0700 > From: Ross Finlayson > Subject: Re: [Live-devel] MultiFrameRTPSource::doGetNextFrame1(): The > total received frame size exceeds to buffer client ...... > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > >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-0001.html > > ------------------------------ > > Message: 3 > Date: Thu, 22 Nov 2007 23:25:15 +0600 > From: ???????? ?????? > Subject: [Live-devel] Trouble with Amino STB > To: live-devel at ns.live555.com > Message-ID: <1563204654.20071122232515 at mail.ru> > Content-Type: text/plain; charset=us-ascii > > 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 > > > > ------------------------------ > > Message: 4 > Date: Thu, 22 Nov 2007 23:34:53 +0600 > From: ???????? ?????? > Subject: [Live-devel] Restrictions > To: live-devel at ns.live555.com > Message-ID: <1509883266.20071122233453 at mail.ru> > Content-Type: text/plain; charset=us-ascii > > 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 > > > > > ------------------------------ > > Message: 5 > Date: Thu, 22 Nov 2007 13:55:04 -0700 > From: "Andrey Filippov" > Subject: [Live-devel] working with MJPEG streams with frame width > > 2040 (and even 2048) pixels. > To: live-devel at lists.live555.com > Cc: Spectr > Message-ID: > <30288c370711221255k4ea2e55mdfd503f33f55262e at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > 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-0001.html > > ------------------------------ > > Message: 6 > Date: Thu, 22 Nov 2007 16:48:10 -0700 > From: Ross Finlayson > Subject: Re: [Live-devel] Restrictions > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > >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/ > > > ------------------------------ > > Message: 7 > Date: Thu, 22 Nov 2007 16:53:37 -0700 > From: Ross Finlayson > Subject: Re: [Live-devel] Trouble with Amino STB > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > >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/ > > > ------------------------------ > > Message: 8 > Date: Fri, 23 Nov 2007 10:50:26 +0300 > From: bagger-devel at medi-a.ru > Subject: [Live-devel] live555MediaServer and RAW UDP streaming > To: live-devel at ns.live555.com > Message-ID: <425434606.20071123105026 at medi-a.ru> > Content-Type: text/plain; charset=us-ascii > > Hello again, mailinglist! > > One more question: has implementation of RTSPServer supports any > nat traversal algorithms? I know that native RFC 2326 doesn't support > such a feature, but some mmusic drafts describe methods to do > this (like Symmetric RTP or STUN). > > Thanks for answer! > > > -- > Best regards, > bagger-devel mailto:bagger-devel at medi-a.ru > > > > ------------------------------ > > Message: 9 > Date: Fri, 23 Nov 2007 01:48:42 -0700 > From: Ross Finlayson > Subject: Re: [Live-devel] live555MediaServer and RAW UDP streaming > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > >One more question: has implementation of RTSPServer supports any > >nat traversal algorithms? I know that native RFC 2326 doesn't support > >such a feature, but some mmusic drafts describe methods to do > >this (like Symmetric RTP or STUN). > > Yes, but note, however, that these were designed primarily for SIP, > and will need to be adapted/modified somewhat (by the IETF) for use > by RTSP. When that is done, however, we will be adding support for > this. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > ------------------------------ > > Message: 10 > Date: Sun, 25 Nov 2007 08:19:35 +0100 > From: Oliver Roll > Subject: [Live-devel] Player application > To: live-devel at ns.live555.com > Message-ID: <47492207.4090801 at oliroll.de> > Content-Type: text/plain; charset=ISO-8859-15 > > Hello all, > > all of the receiver programs in liveMedia/testProgs are dumping their > output to stdout or into files. > What is the easiest way to display a video actually received via > testMPEG1or2VideoReceiver for instance? > Is vlc (which is a bit too complex for me on the first sight) the only > software which can be used to benefit from the streaming-power of liveMedia? > > Thanks & regards, > > Oliver > > > ------------------------------ > > Message: 11 > Date: Sat, 24 Nov 2007 23:30:11 -0800 > From: Ross Finlayson > Subject: Re: [Live-devel] Player application > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > >all of the receiver programs in liveMedia/testProgs are dumping their > >output to stdout or into files. > >What is the easiest way to display a video actually received via > >testMPEG1or2VideoReceiver for instance? > > Well, if you have a video player that can read from stdin, then you > could pipe the video (from "testMPEG1or2VideoReceiver") into it. > > >Is vlc (which is a bit too complex for me on the first sight) > > There are prebuilt binary versions of VLC available on their web site. > > VLC is easy - just enter the appropriate "rtsp://" URL into its 'open' dialog. > > > the only > >software which can be used to benefit from the streaming-power of liveMedia? > > No, there's also MPlayer (although VLC is better), and probably other > media players as well. From yuri.l at mail.ru Tue Nov 27 21:15:04 2007 From: yuri.l at mail.ru (=?koi8-r?Q?=E0=D2=C9=CA_=EC.?=) Date: Wed, 28 Nov 2007 08:15:04 +0300 Subject: [Live-devel] =?koi8-r?b?Vm9yYmlzIGltcGxlbWVudGF0aW9u?= In-Reply-To: References: Message-ID: Ok. That is clear. Thanks for answers! But I have some others questions. 1) What should be placed in the Ident field of Payload header? 2) I found some interesting article about vorbis packetization: http://www.acoustics.hut.fi/publications/files/theses/mutanen_mst.pdf. But process of constructing of RTP packets described in diagram Figure6.11 is for outdated vorbis rtp profile. Is this flowchart applicable for draft-ietf-avt-rtp-vorbis-08 in general? From finlayson at live555.com Tue Nov 27 21:21:56 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 27 Nov 2007 21:21:56 -0800 Subject: [Live-devel] =?koi8-r?b?Vm9yYmlzIGltcGxlbWVudGF0aW9u?= In-Reply-To: References: Message-ID: >Ok. That is clear. Thanks for answers! >But I have some others questions. >1) What should be placed in the Ident field of Payload header? >2) I found some interesting article about vorbis packetization: >http://www.acoustics.hut.fi/publications/files/theses/mutanen_mst.pdf. >But process of constructing of RTP packets described in diagram >Figure6.11 is for outdated vorbis rtp profile. Is this flowchart >applicable for draft-ietf-avt-rtp-vorbis-08 in general? I suggest that you ask the Vorbis Internet Draft's author (Luca Barbato) about this. According to the document, his email address is lu_zero at gentoo.org -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From weiyutao36 at 163.com Wed Nov 28 00:30:55 2007 From: weiyutao36 at 163.com (Yutao Wei) Date: Wed, 28 Nov 2007 16:30:55 +0800 (CST) Subject: [Live-devel] How to play a video file in real-time from Internet? Message-ID: <18132168.907071196238655465.JavaMail.coremail@bj163app69.163.com> Hi everyone? I use testOnDemandRTSPServer to stream a video (has a format, say "WY") and can use openRTSP to receive the video stream and save it as a file, named video-A-1. Also, I have a player that can read from a WY format video file and display it. Now, what I want to do is: let the player play the WY video from the testOnDemandRTSPServer in real-time. I thought a lot and still can not find a solution. Can anybody give me some advice? Thank you very much. Austin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071128/62150774/attachment-0001.html From live555 at dreier.cc Wed Nov 28 01:05:00 2007 From: live555 at dreier.cc (live555 at dreier.cc) Date: Wed, 28 Nov 2007 10:05:00 +0100 Subject: [Live-devel] Raw data streaming In-Reply-To: References: <474C089D.2050903@dreier.cc> Message-ID: <474D2F3C.6020109@dreier.cc> Hi, I just spent more time looking in live555 code and found that the MPEG4GenericRTPSink should do the job. I get the data on the other end and it look good :-) Thank You, Frederic Ross Finlayson a ?crit : >> - what should I implement in RTPSink? what is its role >> > > Your "RTPSink" subclass will implement a particular RTP payload > format (defined by a IETF RFC or (preferably) standards-track > Internet-Draft). Which RTP payload format do you wish to implement?? > From finlayson at live555.com Wed Nov 28 01:23:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Nov 2007 01:23:07 -0800 Subject: [Live-devel] How to play a video file in real-time from Internet? In-Reply-To: <18132168.907071196238655465.JavaMail.coremail@bj163app69.163.com> References: <18132168.907071196238655465.JavaMail.coremail@bj163app69.163.com> Message-ID: >Hi everyone?C > >I use testOnDemandRTSPServer to stream a video (has a format, say "WY") >and can use openRTSP to receive the video stream and save it as a file, >named video-A-1. > >Also, I have a player that can read from a WY >format video file and display it. Now, what I >want to do is: let the player play the WY video >from the testOnDemandRTSPServer in real-time. > >I thought a lot and still can not find a >solution. Can anybody give me some advice? Can your video player take input from 'stdin'? If so, use "openRTSP", with the "-v" option, to write the received video stream to stdout, and pipe this into your video player. If your video player can't take input from 'stdin' (or a named pipe), then you will need to modify your video player client (assuming that you have the source code) to include our RTSP client code, as VLC has done. Alternatively, you could modify VLC (which already includes our RTSP client code) to include your video decoder, and use VLC as your player. -- 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/20071128/137d1ce6/attachment.html From nikhiln at paxit.com Wed Nov 28 12:02:24 2007 From: nikhiln at paxit.com (Nikhil Naik) Date: Wed, 28 Nov 2007 14:02:24 -0600 Subject: [Live-devel] OpenRTSP Client Message-ID: <000001c831f9$9870dbd0$c9529370$@com> Hi Ross, I have built a player based on the openRTSP sample and it works just fine. Now I have created a password protected server by adding: UserAuthenticationDatabase* authDB = NULL; authDB = new UserAuthenticationDatabase; authDB->addUserRecord(username, password); When I pass the -u username password parameters to my application it does not receive the stream. I can receive the stream using the command line openRTSP (pre-built exe). Any clue as to what I might be doing wrong? Is there any flag that needs to be set before I can use this functionality? Thanks, Nikhil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071128/71976a8d/attachment.html From finlayson at live555.com Wed Nov 28 18:16:44 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 28 Nov 2007 18:16:44 -0800 Subject: [Live-devel] OpenRTSP Client In-Reply-To: <000001c831f9$9870dbd0$c9529370$@com> References: <000001c831f9$9870dbd0$c9529370$@com> Message-ID: >When I pass the > >-u username password > >parameters to my application it does not receive the stream. > >I can receive the stream using the command line openRTSP (pre-built exe). > >Any clue as to what I might be doing wrong? No. However, you have complete source code for: - an application that works, and - a related application (written by you) that does not work That should give you enough information to figure out what's wrong with your application. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Thu Nov 29 18:36:06 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 29 Nov 2007 20:36:06 -0600 Subject: [Live-devel] Q: incomingRequestHandler(): param 2 Message-ID: Why do all the 'incomingRequestHandler()' functions take an integer parameter which has no name? In RTSPServer.hh: static void incomingRequestHandler(void * clientData, int /* mask */); Thanks! ?????????????????????????????????????????? Xochitl Smith GS Software Engineer; Computer-E ph: 319.263.0191 xcsmith at rockwellcollins.com ?????????????????????????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071129/50f35370/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 2784 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20071129/50f35370/attachment.jpe From finlayson at live555.com Thu Nov 29 18:58:09 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 29 Nov 2007 18:58:09 -0800 Subject: [Live-devel] Q: incomingRequestHandler(): param 2 In-Reply-To: References: Message-ID: >Why do all the 'incomingRequestHandler()' functions take an integer >parameter which has no name? > >In RTSPServer.hh: >static void incomingRequestHandler(void * clientData, int /* mask */); It's to allow for the possibility of handlng socket events other than 'socket is readable'. E.g., one could define a "TaskaScheduler" subclass that also handled 'socket is writeable' events. (As you noted, though, this functionality isn't currently used at all in the released code.) -- 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/20071129/2bd49636/attachment.html From jnitin at ssdi.sharp.co.in Fri Nov 30 02:14:21 2007 From: jnitin at ssdi.sharp.co.in (Nitin Jain) Date: Fri, 30 Nov 2007 15:44:21 +0530 Subject: [Live-devel] MP4 support in live555 Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB563267@KABEX01.sharpamericas.com> Hi all, We want to add the support for read and write ISO-MP4 files as defined in ISO/IEC 14496-12, 14496-14 for our project by using some opensource mp4 file parser. Please suggest how to start working on this . Regards Nitin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20071130/4303d502/attachment-0001.html From brickyard at codetyrant.com Fri Nov 30 11:46:18 2007 From: brickyard at codetyrant.com (Race Vanderdecken) Date: Fri, 30 Nov 2007 14:46:18 -0500 Subject: [Live-devel] Can I use mplayer to capture a video stream from wis-stream to a file? Message-ID: <1196451979.14612.8.camel@ipem002> Greetings, I am trying to use wis-streamer to produce an RTSP video stream that i can capture using mplayer. I can use mplayer to capture the audio but not the video. ./wis-streamer mplayer -vo null -vc null -ao pcm:file=audio.wav rtsp://192.168.0.20:8554 Audio capture is perfect. I can capture video to a file successfully using openRTSP but it would be nice to use one less program. I can successfully use mplayer to capture some rtsp streams such as: mplayer -dumpstream rtsp://ravi.br-online.de:5050/ravi/alpha/centauri/v/041027.rm -dumpfile x.rm So I know mplayer can capture the video. Any thoughts? do i need more options for the wis-streamer start? Race Vanderdecken Code Tyrant Somewhere near Asheville From finlayson at live555.com Fri Nov 30 14:46:09 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 30 Nov 2007 14:46:09 -0800 Subject: [Live-devel] Can I use mplayer to capture a video stream from wis-stream to a file? In-Reply-To: <1196451979.14612.8.camel@ipem002> References: <1196451979.14612.8.camel@ipem002> Message-ID: I assume that you can play the RTSP stream correctly (by typing the appropriate "rtsp://" URL into MPlayer (or VLC, which I like better)). If so, then the problem is not that you can't capture the video stream - you can, using "openRTSP", for example. Instead, the problem is merely that you can't *play* the recorded file. The reason for this is that because the video stream is MPEG-4 (the default video codec used by "wis-streamer"), the recorded file is in a format (MPEG-4 Video Elementary Stream) that MPlayer or VLC cannot play directly. If you really want your video data to be recorded in a format that can later be played back by most media players, then you should instead tell "wis-streamer" to use MPEG-2 video (using the "-mpeg2" option). Alternatively, you could ask it to generate a MPEG-2 *Transport Stream*, by using "-mpegtransport " option. If you do this, then you will be able to record a *single* file that includes both audio and video. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/