From Daniel at smartCast.org Sun Oct 1 11:33:05 2006 From: Daniel at smartCast.org (Daniel Graupner) Date: Sun, 1 Oct 2006 20:33:05 +0200 Subject: [Live-devel] Looping a source Message-ID: <200610012033.06768.Daniel@smartCast.org> Hello, I want to loop a source. Therefore I used the afterPlay Callback to sink->startplaying and start sink->startPlaying again in this callback. The result is as expected, the input file is looped, but the memory used by the application grows with every loop, so I have a memory leak. How can I loop a source properly? Do I have to setup the whole source/sink chain again for every loop run? Thanks, Danie. From finlayson at live555.com Sun Oct 1 19:46:35 2006 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 1 Oct 2006 19:46:35 -0700 Subject: [Live-devel] Looping a source In-Reply-To: <200610012033.06768.Daniel@smartCast.org> References: <200610012033.06768.Daniel@smartCast.org> Message-ID: >I want to loop a source. Therefore I used the afterPlay Callback to >sink->startplaying and start sink->startPlaying again in this callback. >The result is as expected, the input file is looped, but the memory used by >the application grows with every loop, so I have a memory leak. > >How can I loop a source properly? Do I have to setup the whole source/sink >chain again for every loop run? No, what you are doing is correct. I don't know what would be causing the memory leak; I don't think it is an inherent problem with the library. Did you write any new source and/or sink code yourself? If so, then could the leak be occurring there? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Daniel at smartCast.org Mon Oct 2 03:14:39 2006 From: Daniel at smartCast.org (Daniel Graupner) Date: Mon, 2 Oct 2006 12:14:39 +0200 Subject: [Live-devel] Looping a source In-Reply-To: References: <200610012033.06768.Daniel@smartCast.org> Message-ID: <200610021214.40505.Daniel@smartCast.org> Am Montag 02 Oktober 2006 04:46 schrieb Ross Finlayson: > No, what you are doing is correct. ?I don't know what would be > causing the memory leak; I don't think it is an inherent problem with > the library. ?Did you write any new source and/or sink code yourself? > If so, then could the leak be occurring there? My first rule is to NOT modify live555 libs ;-). However, I found out that I create a new sink object after each play cycle. This may cause the leak. Now I call Media::close(soource), create the source again and call sink->startPlaying in afterPlay callback and everything is fine. Regards, Daniel. From egf05 at doc.ic.ac.uk Mon Oct 2 08:52:09 2006 From: egf05 at doc.ic.ac.uk (egf05 at doc.ic.ac.uk) Date: Mon, 2 Oct 2006 16:52:09 +0100 Subject: [Live-devel] RTSP: is random access possible on the server side? Message-ID: <20061002165209.rpef3020lcssko80@tern.doc.ic.ac.uk> Dear all, I am trying to solve a problem for a while and although I read the documentation thought I could get some help from the users of that list. I am trying to provide mpeg files as Video on Demand (VoD) using RTSP streaming, leaving to the client the ability to play pause and seek the video. I used live555 libraries with VLC and this works pretty well from the client side. However, I would like to be able to provide more control from the server side: I would like to be able to start a video file at a specific time, for instance in the middle of the file. Is there a way to do this? I simply want to provide the same video file as a "chaptered" file (like DVDs), where clients can start the file at a specific time. This should be an RTSP object itself that could be provided through an HTTP link (rtsp://my.server/file_chapter_5, where file_chapter_5 is an RTSP instance created at the server level, using a starting time option for chapter_5). Since I want people to be able to rewind before the starting time, splitting the video is not an option for me. Therefore, from the same file, I want to create file_chapter_1, file_chapter_2, etc... from the same mpeg video file. Then the client would be able to take control of the stream, for example by rewinding before the starting point. Is that possible ? Using VLC, there is a -start-time option that can be provided at the creation of the RTSP stream, however, this is very buggy and the client cannot rewind the stream. I tried to discuss this on the videolan mailing lists but nobody could really help me. So I don't know if this is a limitation from the implementation or the protocol itself. I would be very glad if you could help me on this problem. thank you very much, Eric From finlayson at live555.com Mon Oct 2 11:07:53 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 2 Oct 2006 11:07:53 -0700 Subject: [Live-devel] RTSP: is random access possible on the server side? In-Reply-To: <20061002165209.rpef3020lcssko80@tern.doc.ic.ac.uk> References: <20061002165209.rpef3020lcssko80@tern.doc.ic.ac.uk> Message-ID: >Is that possible ? In principle, yes. However, server support for this kind of thing is (necessarily) media type dependent. See > Using VLC, there is a -start-time option that can >be provided at the creation of the RTSP stream, however, this is very >buggy It shouldn't be. Specifying a start time in the RTSP "PLAY" command is a well-established part of the protocol, and VLC's RTSP client implementation supports this, I believe. However, it's up to the server to decide if and how to implement this. As I noted in the link above, it works for some media types only. -- 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/20061002/f6f66df6/attachment.html From egf05 at doc.ic.ac.uk Mon Oct 2 11:27:08 2006 From: egf05 at doc.ic.ac.uk (egf05 at doc.ic.ac.uk) Date: Mon, 2 Oct 2006 19:27:08 +0100 Subject: [Live-devel] RTSP: is random access possible on the server side? In-Reply-To: References: <20061002165209.rpef3020lcssko80@tern.doc.ic.ac.uk> Message-ID: <20061002192708.fmm05kdvk4og0skc@tern.doc.ic.ac.uk> Quoting Ross Finlayson : >> Using VLC, there is a -start-time option that can be provided at >> the creation of the RTSP stream, however, this is very buggy > > It shouldn't be. Specifying a start time in the RTSP "PLAY" command is > a well-established part of the protocol, and VLC's RTSP client > implementation supports this, I believe. However, it's up to the > server to decide if and how to implement this. As I noted in the link > above, it works for some media types only. Thank you very much for these infos. Actually, since I want the user to be able to start video at a specific time, by clicking on a single HTTP link (without using javascript) this should be implemented on the server side, as I cannot pass options to a client in a link (and I don't want to be client specific too). This should be entirely transparen to the user. Do you see any other way than having several RTSP/VoD objects for the same file, each one starting at the different times? Maybe in that case I should work on the VLC server code to add better support for the start time (which is certainly a harder work)? Regards, Eric From darnold at futurec.net Mon Oct 2 16:39:42 2006 From: darnold at futurec.net (David Arnold) Date: Mon, 2 Oct 2006 16:39:42 -0700 Subject: [Live-devel] H.264 and MPEG2 Transport Stream In-Reply-To: Message-ID: Ross, Thank you for your suggestions. I have been working with MPEG2TransportStreamFromESSource using my H.264 source. I needed to modify MPEG2TransportMultiplexor so that it generates the appropriate "streamType" for H.264. Also, the multiplexor is calling my sources "doGetNextFrame()" without considering the fDurationInMicroseconds. Looking at the end of doGetNextFrame() in MPEG2TransportStreamMultiplexor.cpp I see the following comment: " // NEED TO SET fPresentationTime, durationInMicroseconds ##### // Complete the delivery to the client: " I don't understand how I can determine what the correct presentation time and duration should be. Thanks again, Dave Arnold Future Concepts, La Verne CA -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com]On Behalf Of Ross Finlayson Sent: Wednesday, September 27, 2006 1:38 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] H.264 and MPEG2 Transport Stream >>My question is this: What do we need to do to modify our video server so >>that it can stream the H.264 and PCMU sources within a MPEG-2 Transport >>Stream > >You should be able to do this by writing your own subclass of >"MPEG2TransportStreamMultiplexor". It would probably be similar to >the existing "MPEG2TransportStreamFromESSource" class, which is used >to create a MPEG-2 Transport Stream that contains MEPG Elementary >Stream data. One more thing: You may find the code for the "wis-streamer" application useful. This code makes use of the "MPEG2TransportStreamFromESSource" class, in a way that may be similar to your intended application. -- 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 The information contained in this electronic mail transmission is intended only for the use of the individual or entity named above and is privileged and confidential. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Any dissemination, distribution or copying of this communication other than to the person or entity named above is strictly prohibited. If you have received this communication in error, please immediately delete it from your system. From sanjeev.sood at gmail.com Tue Oct 3 00:36:24 2006 From: sanjeev.sood at gmail.com (Sanjeev Sood) Date: Tue, 3 Oct 2006 00:36:24 -0700 Subject: [Live-devel] Groupsock doesn't bind to Multicast Address Message-ID: <7d5f35040610030036j65ae8d82p5ac3e45df951261@mail.gmail.com> Hello, I am relatively new user to the Live Media library. In our application, we would like to bind to a multicast address in addition to binding to the local port number. This is so that we *only* receive packets destined for a given *Multicast address & port* combination and prevent other datagrams destined for that same port from being deliverd to our socket. To achieve this, I am using "ReceivingInterfaceAddr" global variable to set our MULTICAST address. This allows Groupsock to bind to this address, however following code in the GroupsockHelper.cpp fails: // socketJoinGroup() code snippet imr.imr_multiaddr.s_addr = groupAddress; imr.imr_interface.s_addr = ReceivingInterfaceAddr; if (setsockopt(socket, IPPROTO_IP, IP_ADD_MEMBERSHIP, (const char*)&imr, sizeof (struct ip_mreq)) < 0) { This is because ReceivingInterfaceAddr being a Multicast address, is not a valid interface address. However, if the above one line was modified as follows to use the INADDR_ANY as the interface address when ReceivingInterfaceAddr is a multicast address, it should work: // change imr.imr_interface.s_addr = ReceivingInterfaceAddr; to following: if (IN_MULTICAST(ntohl(ReceivingInterfaceAddr))) { // Bound to MULTICAST Address, so use INADDR_ANY as the i/f address imr.imr_interface.s_addr = INADDR_ANY; } else { // Bound to UNICAST Address, so use this address as the i/f address imr.imr_interface.s_addr = ReceivingInterfaceAddr; } This simple change enables applications interested in receiving specific packets only. Here are my questions: 1. Is this an acceptable solution to my problem? If so, can this change be included in your code base and future release? 2. If not, is there an existing solution to this problem? I will sincerely appreciate any input and guidance on this issue. Best regards, -Sanjeev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061003/ad5af490/attachment.html From lkovacs at xperts.hu Tue Oct 3 02:22:38 2006 From: lkovacs at xperts.hu (Levente Kovacs) Date: Tue, 3 Oct 2006 11:22:38 +0200 Subject: [Live-devel] IPv6 Message-ID: <20061003112238.9385014b.lkovacs@xperts.hu> Hi All, Just a question. Does Live555 support IPv6? Levente From lkovacs at xperts.hu Tue Oct 3 02:32:37 2006 From: lkovacs at xperts.hu (Levente Kovacs) Date: Tue, 3 Oct 2006 11:32:37 +0200 Subject: [Live-devel] redirecting a mpeg4 rtsp stream In-Reply-To: <20060929234739.60141.qmail@web28007.mail.ukl.yahoo.com> References: <20060929234739.60141.qmail@web28007.mail.ukl.yahoo.com> Message-ID: <20061003113237.bb36d0bc.lkovacs@xperts.hu> On Sat, 30 Sep 2006 01:47:39 +0200 (CEST) Paolo Prete wrote: > I have an IP cam whith an embedded mpeg4 rtsp > streaming server; > unfortunately, the max number of allowed clients is > small. > In order to solve this limit, I would like to create a > new simple streaming server, on my machine, which only > redirectes the ip-cam's stream. > > Is there a support, or sample codes for this operation > in an easy way, or should I do it using the OpenRTSP > (--->RTSPClient) and/or testMPEG4VideoStreamer > programs as a base for my purpose (but it wouldn't be > trivia As far as I know, if you use multicast streaming, and a multicast router, the number of clients is only limited by network bitrate. If I am wrong, what I'd do is to write scripts and set up a NAT wich converts the unicast IP address to multicast address on a router. Just my HUF 1. Levente From finlayson at live555.com Tue Oct 3 02:52:37 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Oct 2006 02:52:37 -0700 Subject: [Live-devel] IPv6 In-Reply-To: <20061003112238.9385014b.lkovacs@xperts.hu> References: <20061003112238.9385014b.lkovacs@xperts.hu> Message-ID: >Just a question. Does Live555 support IPv6? Not yet, no. From finlayson at live555.com Tue Oct 3 02:55:07 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Oct 2006 02:55:07 -0700 Subject: [Live-devel] Groupsock doesn't bind to Multicast Address In-Reply-To: <7d5f35040610030036j65ae8d82p5ac3e45df951261@mail.gmail.com> References: <7d5f35040610030036j65ae8d82p5ac3e45df951261@mail.gmail.com> Message-ID: >I am relatively new user to the Live Media library. In our >application, we would like to bind to a multicast address in >addition to binding to the local port number. This is so that we >*only* receive packets destined for a given Multicast address & port >combination and prevent other datagrams destined for that same port >from being deliverd to our socket. This is often an operating system issue. Some OSs work the way you want; others do not. >// change imr.imr_interface.s_addr = ReceivingInterfaceAddr; to following: > >if (IN_MULTICAST(ntohl(ReceivingInterfaceAddr))) { > // Bound to MULTICAST Address, so use INADDR_ANY as the i/f address > imr.imr_interface.s_addr = INADDR_ANY; > } > else { > // Bound to UNICAST Address, so use this address as the i/f address > imr.imr_interface.s_addr = ReceivingInterfaceAddr; > } This is bogus, because the default value of "ReceivingInterfaceAddr" *is* INADDR_ANY. I.e., you'll get the same effect as your proposed change if you don't set "ReceivingInterfaceAddr" 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/20061003/d6cc2b16/attachment.html From rahul.ray at gmail.com Tue Oct 3 11:01:22 2006 From: rahul.ray at gmail.com (Rahul Ray) Date: Tue, 3 Oct 2006 11:01:22 -0700 Subject: [Live-devel] compiling live on xp Message-ID: Hi, Has anybody been successful in compiling live on xp ? If so, please share your experience. I am having trouble. I am following the instructions at : http://www.live555.com/liveMedia/#config-windows I ran: genWindowsMakefiles but when I ran make after this in live directory, it says : make[1]: Entering directory 'liveMedia' make[1]: *** No targets specified and no makefile found. Stop. ....... From finlayson at live555.com Tue Oct 3 11:11:57 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 3 Oct 2006 11:11:57 -0700 Subject: [Live-devel] compiling live on xp In-Reply-To: References: Message-ID: >Hi, > Has anybody been successful in compiling live on xp ? If so, >please share your experience. >I am having trouble. I am following the instructions at : >http://www.live555.com/liveMedia/#config-windows These instructions are for tools such as "Visual Studio" - that use ".mak" files. If, instead, you are using 'cygwin' (which has a regular "make" command), then you instead do genMakefiles cygwin make -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sanjeev.sood at gmail.com Tue Oct 3 12:15:45 2006 From: sanjeev.sood at gmail.com (Sanjeev Sood) Date: Tue, 3 Oct 2006 12:15:45 -0700 Subject: [Live-devel] Groupsock doesn't bind to Multicast Address Message-ID: <7d5f35040610031215w5e72188axaab58110c689e108@mail.gmail.com> Hello Ross, Thanks for taking time in responding to my question. We are using Live Media library on Linux. I am not clear when you say it is often an operating system issue. Isn't it the responsibility of the application to bind to a pariticular address if it wants too? If a multicast application needs to only receive traffic on a particular multicast address, it will have to bind to that address? Also, regarding your other comment " This is bogus, because the default value of "ReceivingInterfaceAddr" *is* INADDR_ANY. I.e., you'll get the same effect as your proposed change if you don't set "ReceivingInterfaceAddr" at all." We are planning to set the ReceivingInterfaceAddr to our multicast address and it does work for us. Also, this change doesn't change your default behavior (where it is set to NULL) and thus wont break any existing applications. However, I did notice that after setting ReceivingInterfaceAddr to a multicast address, ourSourceAddressForMulticast() in Groupsock.cpp is failing with "This computer has an invalid IP address:" error. I am in the process of debugging why this error happens. Any hints on this as well? Once again, I appreciate your help here. Best, -Sanjeev ---------- Forwarded message ---------- From: Ross Finlayson To: LIVE555 Streaming Media - development & use Date: Tue, 3 Oct 2006 02:55:07 -0700 Subject: Re: [Live-devel] Groupsock doesn't bind to Multicast Address I am relatively new user to the Live Media library. In our application, we would like to bind to a multicast address in addition to binding to the local port number. This is so that we *only* receive packets destined for a given* Multicast address & port* combination and prevent other datagrams destined for that same port from being deliverd to our socket. This is often an operating system issue. Some OSs work the way you want; others do not. // change imr.imr_interface.s_addr = ReceivingInterfaceAddr; to following: if (IN_MULTICAST(ntohl(ReceivingInterfaceAddr))) { // Bound to MULTICAST Address, so use INADDR_ANY as the i/f address imr.imr_interface.s_addr = INADDR_ANY; } else { // Bound to UNICAST Address, so use this address as the i/f address imr.imr_interface.s_addr = ReceivingInterfaceAddr; } This is bogus, because the default value of "ReceivingInterfaceAddr" *is* INADDR_ANY. I.e., you'll get the same effect as your proposed change if you don't set "ReceivingInterfaceAddr" 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/20061003/2a1e26d8/attachment.html From rahul.ray at gmail.com Tue Oct 3 18:15:09 2006 From: rahul.ray at gmail.com (Rahul Ray) Date: Tue, 3 Oct 2006 18:15:09 -0700 Subject: [Live-devel] On failure Message-ID: Hi, While openRTSP fails ( due to camera problem or network), it comes out of the program by some exit(..) perhaps inside shutdown. I would like to return from a fucntion and release the stream on a failure. Is this possible , how ? Thanks for your help. -best, Rahul From shaswata at alumnux.com Wed Oct 4 03:54:03 2006 From: shaswata at alumnux.com (Shaswata Jash) Date: Wed, 4 Oct 2006 16:24:03 +0530 Subject: [Live-devel] RTSP: is random access possible on the server side? References: <20061002165209.rpef3020lcssko80@tern.doc.ic.ac.uk> <20061002192708.fmm05kdvk4og0skc@tern.doc.ic.ac.uk> Message-ID: <003f01c6e7a3$68c7fc20$2e0aa8c0@NITU> Hi Eric, Just having a thought... Why several RTSP object ? The intelligence can reside at the MediaSource level (more specifically file sources). That intelligence in the source itself will decide from which part of media, frames has to be fetched. This intelligence must depend on three factors : chapter name, position of key video frame and a mapping of time with chapter names. The suffix part (chapter name) of the RTSP URL can easily be sent to the sources (through the constructor of the sources in createNewStreamSource() functions of media sub session classes) as part of file name. Though mapping of key frames with the time is not always present explicitely (like in mpeg PS , you have to precalculate the mapping between the I-frame with time where as for ISO base media file formats, this information can be found directly from "stts" box). With regards, Shaswata ----- Original Message ----- From: To: "LIVE555 Streaming Media - development & use" Sent: Monday, October 02, 2006 11:57 PM Subject: Re: [Live-devel] RTSP: is random access possible on the server side? > Quoting Ross Finlayson : > > >> Using VLC, there is a -start-time option that can be provided at > >> the creation of the RTSP stream, however, this is very buggy > > > > It shouldn't be. Specifying a start time in the RTSP "PLAY" command is > > a well-established part of the protocol, and VLC's RTSP client > > implementation supports this, I believe. However, it's up to the > > server to decide if and how to implement this. As I noted in the link > > above, it works for some media types only. > > Thank you very much for these infos. > > Actually, since I want the user to be able to start video at a > specific time, by clicking on a single HTTP link (without using > javascript) this should be implemented on the server side, as I cannot > pass options to a client in a link (and I don't want to be client > specific too). This should be entirely transparen to the user. > > Do you see any other way than having several RTSP/VoD objects for the > same file, each one starting at the different times? Maybe in that > case I should work on the VLC server code to add better support for > the start time (which is certainly a harder work)? > > Regards, > Eric > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From rajeshkumar.r at imimobile.com Wed Oct 4 04:29:22 2006 From: rajeshkumar.r at imimobile.com (Rajesh) Date: Wed, 4 Oct 2006 16:59:22 +0530 Subject: [Live-devel] How to write streaming data recvd into 3gp file format Message-ID: <00c601c6e7a8$57167790$f801000a@imidomain.com> Hi all I am trying to develop my own rtsp client who will recv the streaming data from server and write into the file.The file format will be 3gp.I am able to recv the streaming data ,but unable to understand what should be next approach. my objective is to write the streaming data into 3gp file format. with regards rajesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061004/7741ecd8/attachment.html From shaswata at alumnux.com Wed Oct 4 05:34:38 2006 From: shaswata at alumnux.com (Shaswata Jash) Date: Wed, 4 Oct 2006 18:04:38 +0530 Subject: [Live-devel] How to write streaming data recvd into 3gp file format References: <00c601c6e7a8$57167790$f801000a@imidomain.com> Message-ID: <005401c6e7b1$74f10ce0$2e0aa8c0@NITU> It is difficult to form a 3gp file until and unless you have all the media frames captured from the RTP stream. But any how, after capturing all of them, you have to write a file compliant to ISO Base media file format (more specifically the ISO derived standard for 3GP specification). For this you may use GPAC or MPEG4IP libraries. ----- Original Message ----- From: Rajesh To: LIVE555 Streaming Media - development & use Sent: Wednesday, October 04, 2006 4:59 PM Subject: [Live-devel] How to write streaming data recvd into 3gp file format Hi all I am trying to develop my own rtsp client who will recv the streaming data from server and write into the file.The file format will be 3gp.I am able to recv the streaming data ,but unable to understand what should be next approach. my objective is to write the streaming data into 3gp file format. with regards rajesh ------------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061004/8dcc7451/attachment.html From lkovacs at xperts.hu Wed Oct 4 05:47:44 2006 From: lkovacs at xperts.hu (Levente Kovacs) Date: Wed, 4 Oct 2006 14:47:44 +0200 Subject: [Live-devel] How to write streaming data recvd into 3gp file format In-Reply-To: <00c601c6e7a8$57167790$f801000a@imidomain.com> References: <00c601c6e7a8$57167790$f801000a@imidomain.com> Message-ID: <20061004144744.ee53c926.lkovacs@xperts.hu> On Wed, 4 Oct 2006 16:59:22 +0530 "Rajesh" wrote: > Hi all > I am trying to develop my own rtsp client who will recv the streaming data from server and write into the file.The file format will be 3gp.I am able to recv the streaming data ,but unable to understand what should be next approach. > my objective is to write the streaming data into 3gp file format. I think you sould start by understanding what is going on in OpenRTSP. Then get your self a library which'll do the job about 3gp (or it is implemented in live already? Ross?). What you should do is to link the two together. IMHO. Levente From finlayson at live555.com Wed Oct 4 08:12:46 2006 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 4 Oct 2006 08:12:46 -0700 Subject: [Live-devel] How to write streaming data recvd into 3gp file format In-Reply-To: <00c601c6e7a8$57167790$f801000a@imidomain.com> References: <00c601c6e7a8$57167790$f801000a@imidomain.com> Message-ID: >Hi all >I am trying to develop my own rtsp client who will recv the >streaming data from server and write into the file.The file format >will be 3gp.I am able to recv the streaming data ,but unable to >understand what should be next approach. >my objective is to write the streaming data into 3gp file format. You should not need to "develop your own RTSP client". Instead, just use "openRTSP" with the "-4" option, which writes a MPEG-4 format file to stdout. (Note that a so-called '3GPP' file is really just a MPEG-4 format file.) See -- 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/20061004/28e63231/attachment-0001.html From bidibulle at operamail.com Wed Oct 4 12:34:49 2006 From: bidibulle at operamail.com (David BERTRAND) Date: Wed, 04 Oct 2006 20:34:49 +0100 Subject: [Live-devel] Some modifications done on the library Message-ID: <20061004193449.C870643D78@ws5-1.us4.outblaze.com> Hi Ross, I had to modify slightly some classes of your latest build to be able to use inheritance for my project. The most difficult tasks were to inherit from MediaSession and from RTCPInstance. As the LGPL license requires it, I would like to publish my patches, so please find them here attached. It is, most of the time, just changing accessors (from "private" to "protected"). Of course, I would pleased if you could consider those patches. This would help me in always keeping the latest liveMedia library in my project and maybe help some other folks integrating liveMedia library in projects like mine. Of course, would you need more rationale about any of those changes, feel free to ask me. David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze -------------- next part -------------- --- ./liveMedia/include/AMRAudioFileSink.hh 2006-10-04 16:39:19.000000000 +0200 +++ ./liveMedia/include/AMRAudioFileSink.hh.orig 2006-10-03 23:36:41.000000000 +0200 @@ -32,7 +32,7 @@ Boolean oneFilePerFrame = False); // (See "FileSink.hh" for a description of these parameters.) -protected: +private: AMRAudioFileSink(UsageEnvironment& env, FILE* fid, unsigned bufferSize, char const* perFrameFileNamePrefix); // called only by createNew() @@ -43,7 +43,7 @@ virtual void afterGettingFrame1(unsigned frameSize, struct timeval presentationTime); -protected: +private: Boolean fHaveWrittenHeader; }; --- ./liveMedia/include/AMRAudioRTPSink.hh 2006-10-04 14:57:05.000000000 +0200 +++ ./liveMedia/include/AMRAudioRTPSink.hh.orig 2006-10-03 15:22:31.000000000 +0200 @@ -33,9 +33,6 @@ Boolean sourceIsWideband = False, unsigned numChannelsInSource = 1); -public: - Boolean sourceIsWideband() const { return fSourceIsWideband; } - protected: AMRAudioRTPSink(UsageEnvironment& env, Groupsock* RTPgs, unsigned char rtpPayloadFormat, --- ./liveMedia/include/FramedSource.hh 2006-10-04 14:58:26.000000000 +0200 +++ ./liveMedia/include/FramedSource.hh.orig 2006-10-03 15:22:51.000000000 +0200 @@ -95,7 +95,7 @@ // redefined virtual functions: virtual Boolean isFramedSource() const; -protected: +private: afterGettingFunc* fAfterGettingFunc; void* fAfterGettingClientData; onCloseFunc* fOnCloseFunc; --- ./liveMedia/include/MediaSession.hh 2006-10-04 14:52:53.000000000 +0200 +++ ./liveMedia/include/MediaSession.hh.orig 2006-10-03 15:21:32.000000000 +0200 @@ -67,7 +67,7 @@ private: // redefined virtual functions virtual Boolean isMediaSession() const; -protected: +private: MediaSession(UsageEnvironment& env); // called only by createNew(); virtual ~MediaSession(); @@ -87,7 +87,7 @@ static unsigned guessRTPTimestampFrequency(char const* mediumName, char const* codecName); -protected: +private: friend class MediaSubsessionIterator; char* fCNAME; // used for RTCP @@ -222,7 +222,7 @@ unsigned fRealRuleNumber; #endif -protected: +private: friend class MediaSession; friend class MediaSubsessionIterator; MediaSubsession(MediaSession& parent); @@ -240,7 +240,7 @@ Boolean parseSDPAttribute_x_dimensions(char const* sdpLine); Boolean parseSDPAttribute_framerate(char const* sdpLine); -protected: +private: // Linkage fields: MediaSession& fParent; MediaSubsession* fNext; --- ./liveMedia/include/MediaSink.hh 2006-10-04 15:37:35.000000000 +0200 +++ ./liveMedia/include/MediaSink.hh.orig 2006-10-03 23:27:27.000000000 +0200 @@ -39,8 +39,6 @@ // Test for specific types of sink: virtual Boolean isRTPSink() const; - FramedSource* source() const {return fSource;} - protected: MediaSink(UsageEnvironment& env); // abstract base class virtual ~MediaSink(); --- ./liveMedia/include/MPEG4ESVideoRTPSink.hh 2006-10-04 14:48:09.000000000 +0200 +++ ./liveMedia/include/MPEG4ESVideoRTPSink.hh.orig 2006-10-03 15:21:07.000000000 +0200 @@ -55,9 +55,8 @@ virtual char const* auxSDPLine(); -protected: - Boolean fVOPIsPresent; private: + Boolean fVOPIsPresent; char* fAuxSDPLine; }; --- ./liveMedia/include/MPEG4VideoStreamDiscreteFramer.hh 2006-10-04 16:40:52.000000000 +0200 +++ ./liveMedia/include/MPEG4VideoStreamDiscreteFramer.hh.orig 2006-10-04 14:16:37.000000000 +0200 @@ -33,11 +33,10 @@ static MPEG4VideoStreamDiscreteFramer* createNew(UsageEnvironment& env, FramedSource* inputSource); -protected: +private: MPEG4VideoStreamDiscreteFramer(UsageEnvironment& env, FramedSource* inputSource); // called only by createNew() - virtual ~MPEG4VideoStreamDiscreteFramer(); private: @@ -57,20 +56,15 @@ Boolean getNextFrameBit(u_int8_t& result); Boolean getNextFrameBits(unsigned numBits, u_int32_t& result); // Which are used by: - -protected: void analyzeVOLHeader(); private: unsigned fNumBitsSeenSoFar; // used by the getNextFrameBit*() routines - -protected: u_int32_t vop_time_increment_resolution; unsigned fNumVTIRBits; // # of bits needed to count to "vop_time_increment_resolution" struct timeval fLastNonBFramePresentationTime; unsigned fLastNonBFrameVop_time_increment; - }; #endif --- ./liveMedia/include/RTCP.hh 2006-10-04 15:31:56.000000000 +0200 +++ ./liveMedia/include/RTCP.hh.orig 2006-10-03 17:08:47.000000000 +0200 @@ -110,52 +110,51 @@ void addReport(); void addSR(); void addRR(); - virtual void enqueueCommonReportPrefix(unsigned char packetType, u_int32_t SSRC, + void enqueueCommonReportPrefix(unsigned char packetType, u_int32_t SSRC, unsigned numExtraWords = 0); - virtual void enqueueCommonReportSuffix(); + void enqueueCommonReportSuffix(); + void enqueueReportBlock(RTPReceptionStats* receptionStats); void addSDES(); void addBYE(); void sendBuiltPacket(); + static void onExpire(RTCPInstance* instance); void onExpire1(); static void incomingReportHandler(RTCPInstance* instance, int /*mask*/); void incomingReportHandler1(); + void onReceive(int typeOfPacket, int totPacketSize, u_int32_t ssrc); void unsetSpecificRRHandler(netAddressBits fromAddress, Port fromPort); -protected: - static void onExpire(RTCPInstance* instance); - void onReceive(int typeOfPacket, int totPacketSize, u_int32_t ssrc); - void enqueueReportBlock(RTPReceptionStats* receptionStats); - private: + unsigned char* fInBuf; + OutPacketBuffer* fOutBuf; + RTPInterface fRTCPInterface; unsigned fTotSessionBW; + RTPSink* fSink; + RTPSource const* fSource; + Boolean fIsSSMSource; + + SDESItem fCNAME; RTCPMemberDatabase* fKnownMembers; unsigned fOutgoingReportCount; // used for SSRC member aging + double fAveRTCPSize; int fIsInitial; double fPrevReportTime; + double fNextReportTime; int fPrevNumMembers; + int fLastSentSize; int fLastReceivedSize; u_int32_t fLastReceivedSSRC; - int fTypeOfPacket; - AddressPortLookupTable* fSpecificRRHandlerTable; - -protected: - unsigned char* fInBuf; - OutPacketBuffer* fOutBuf; - RTPInterface fRTCPInterface; - RTPSink* fSink; - RTPSource const* fSource; - Boolean fIsSSMSource; - SDESItem fCNAME; - double fNextReportTime; int fTypeOfEvent; + int fTypeOfPacket; Boolean fHaveJustSentPacket; unsigned fLastPacketSentSize; + TaskFunc* fByeHandlerTask; void* fByeHandlerClientData; Boolean fByeHandleActiveParticipantsOnly; @@ -163,9 +162,10 @@ void* fSRHandlerClientData; TaskFunc* fRRHandlerTask; void* fRRHandlerClientData; + AddressPortLookupTable* fSpecificRRHandlerTable; public: // because this stuff is used by an external "C" function - virtual void schedule(double nextTime); + void schedule(double nextTime); void reschedule(double nextTime); void sendReport(); void sendBYE(); --- ./liveMedia/include/RTPSource.hh 2006-10-04 15:29:04.000000000 +0200 +++ ./liveMedia/include/RTPSource.hh.orig 2006-10-03 15:46:20.000000000 +0200 @@ -144,21 +144,19 @@ RTPReceptionStats* lookup(u_int32_t SSRC) const; -protected: // constructor and destructor, called only by RTPSource: +private: // constructor and destructor, called only by RTPSource: friend class RTPSource; RTPReceptionStatsDB(RTPSource& rtpSource); virtual ~RTPReceptionStatsDB(); -protected: +private: void add(u_int32_t SSRC, RTPReceptionStats* stats); -protected: +private: friend class Iterator; RTPSource& fOurRTPSource; - unsigned fNumActiveSourcesSinceLastReset; - -private: HashTable* fTable; + unsigned fNumActiveSourcesSinceLastReset; unsigned fTotNumPacketsReceived; // for all SSRCs }; @@ -197,7 +195,7 @@ return fTotalInterPacketGaps; } -protected: +private: // called only by RTPReceptionStatsDB: friend class RTPReceptionStatsDB; RTPReceptionStats(RTPSource& rtpSource, u_int32_t SSRC, @@ -205,7 +203,6 @@ RTPReceptionStats(RTPSource& rtpSource, u_int32_t SSRC); virtual ~RTPReceptionStats(); -private: void noteIncomingPacket(u_int16_t seqNum, u_int32_t rtpTimestamp, unsigned timestampFrequency, Boolean useForJitterCalculation, @@ -220,33 +217,23 @@ // resets periodic stats (called each time they're used to // generate a reception report) -protected: +private: RTPSource& fOurRTPSource; u_int32_t fSSRC; unsigned fNumPacketsReceivedSinceLastReset; unsigned fTotNumPacketsReceived; - -private: u_int32_t fTotBytesReceived_hi, fTotBytesReceived_lo; Boolean fHaveSeenInitialSequenceNumber; - -protected: unsigned fBaseExtSeqNumReceived; unsigned fLastResetExtSeqNumReceived; unsigned fHighestExtSeqNumReceived; - -private: int fLastTransit; // used in the jitter calculation u_int32_t fPreviousPacketRTPTimestamp; - -protected: double fJitter; // The following are recorded whenever we receive a RTCP SR for this SSRC: unsigned fLastReceivedSR_NTPmsw; // NTP timestamp (from SR), most-signif unsigned fLastReceivedSR_NTPlsw; // NTP timestamp (from SR), least-signif struct timeval fLastReceivedSR_time; - -private: struct timeval fLastPacketReceptionTime; unsigned fMinInterPacketGapUS, fMaxInterPacketGapUS; struct timeval fTotalInterPacketGaps; From jeremy at electrosilk.net Wed Oct 4 19:46:30 2006 From: jeremy at electrosilk.net (Jeremy) Date: Thu, 5 Oct 2006 10:46:30 +0800 (WST) Subject: [Live-devel] bug in MPEG2TRansportStreamFromESSource.cpp In-Reply-To: References: <00c601c6e7a8$57167790$f801000a@imidomain.com> Message-ID: <4313.202.189.68.42.1160016390.squirrel@mail.ardley.org> In the following function fVideoSourceCounter should be fAudioSourceCounter 00088 void MPEG2TransportStreamFromESSource 00089 ::addNewAudioSource(FramedSource* inputSource, int mpegVersion) { 00090 u_int8_t streamId = 0xC0 | (fVideoSourceCounter++&0x0F); 00091 addNewInputSource(inputSource, streamId, mpegVersion); 00092 } From finlayson at live555.com Thu Oct 5 00:23:18 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Oct 2006 00:23:18 -0700 Subject: [Live-devel] bug in MPEG2TRansportStreamFromESSource.cpp In-Reply-To: <4313.202.189.68.42.1160016390.squirrel@mail.ardley.org> References: <00c601c6e7a8$57167790$f801000a@imidomain.com> <4313.202.189.68.42.1160016390.squirrel@mail.ardley.org> Message-ID: Thanks - this bug has now been fixed in the released source code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Oct 5 00:24:38 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Oct 2006 00:24:38 -0700 Subject: [Live-devel] Some modifications done on the library In-Reply-To: <20061004193449.C870643D78@ws5-1.us4.outblaze.com> References: <20061004193449.C870643D78@ws5-1.us4.outblaze.com> Message-ID: David, I have made most of your proposed changes; they have been included in the latest release of the software. However, in a couple of cases, I held off on making the changes, because I was not convinced that they are justified. In particular: - In "FramedSource.hh", I don't believe that variables such as "fAfterGettingFunc" should be "protected". These are used only by the implementations of "FramedSource::getNextFrame()" and "FramedSource::afterGetting()" - which are central to the functioning of the library - and I don't see how/why subclasses would want to access (let alone modify) these variables. - In "RTCP.hh", I'm not (yet) convinced about the need or desirability of subclassing "RTCPInstance". If the intention is to support new RTCP report types, then there may end up being a better way to do that. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bidibulle at operamail.com Thu Oct 5 01:19:55 2006 From: bidibulle at operamail.com (David BERTRAND) Date: Thu, 05 Oct 2006 09:19:55 +0100 Subject: [Live-devel] Some modifications done on the library Message-ID: <20061005081955.5088E246AE@ws5-3.us4.outblaze.com> Hi Ross, > I have made most of your proposed changes; they have been included in > the latest release of the software. Thank you very much for this. > - In "FramedSource.hh", I don't believe that variables such as > "fAfterGettingFunc" should be "protected". These are used only by > the implementations of "FramedSource::getNextFrame()" and > "FramedSource::afterGetting()" - which are central to the functioning > of the library - and I don't see how/why subclasses would want to > access (let alone modify) these variables. That's because I implemented a class to duplicate received frames in order to serve several RTP sinks from a single RTP source. The signature of method getNextFrame() had to be modified to add a clientID in argument list and therefore I needed to get access to those variables. Extract of my code : void RTPDuplicator::getNextFrame(u_int8_t clientId, unsigned char* to, unsigned maxSize, FramedSource::afterGettingFunc* afterGettingFunc, void* afterGettingClientData, FramedSource::onCloseFunc* onCloseFunc, void* onCloseClientData) { [...] fAfterGettingFunc = afterGettingFunc; fAfterGettingClientData = afterGettingClientData; fOnCloseFunc = onCloseFunc; fOnCloseClientData = onCloseClientData; fIsCurrentlyAwaitingData = True; [...] doGetNextFrame(); } > - In "RTCP.hh", I'm not (yet) convinced about the need or > desirability of subclassing "RTCPInstance". If the intention is to > support new RTCP report types, then there may end up being a better > way to do that. No, the idea was to be able to "transparently" relay receiver reports from a player to a server instead of generating our own reports towards player and server (when we are in a RTSP proxy configuration). Our final goal is to implement 3GPP Rel 6 "Transparent end-to-end Packet-switched Streaming Service" standard (known as 26234-670) whisle keeping using liveMedia library. To do so, we needed to modify completely the way reports are sent (in particular, the scheduling mechanis)and had to add methods like : static void ReceiverReportHandler(void* clientData); David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze From jeremy at electrosilk.net Thu Oct 5 01:51:18 2006 From: jeremy at electrosilk.net (Jeremy) Date: Thu, 5 Oct 2006 16:51:18 +0800 (WST) Subject: [Live-devel] Time calculation in MPEG2TransportStreamFromESSource In-Reply-To: <20061005081955.5088E246AE@ws5-3.us4.outblaze.com> References: <20061005081955.5088E246AE@ws5-3.us4.outblaze.com> Message-ID: <1035.202.189.68.42.1160038278.squirrel@mail.ardley.org> in MPEG2TransportStreamFromESSource 00239 if (fInputBufferBytesAvailable == SIMPLE_PES_HEADER_SIZE) { 00240 // Use this presentationTime for our SCR: 00241 fSCR.highBit 00242 = ((presentationTime.tv_sec*45000 + (presentationTime.tv_usec*9)/200)& 00243 0x80000000) != 0; 00244 fSCR.remainingBits 00245 = presentationTime.tv_sec*90000 + (presentationTime.tv_usec*9)/100; 00246 fSCR.extension = (presentationTime.tv_usec*9)%100; >From ISO/IEC 13818-1 2.4.2.2 extension time is the lower 9 bits of a 27Mhz clock. PCR_base(i) = ((system_clock_ frequency ? t(i)) DIV 300) % 233 (2-2) PCR_ext(i) = ((system_clock_ frequency ? t(i)) DIV 1) % 300 (2-3) Are the calculations on lines 245 and 246 above correct? From finlayson at live555.com Thu Oct 5 06:23:45 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Oct 2006 06:23:45 -0700 Subject: [Live-devel] Time calculation in MPEG2TransportStreamFromESSource In-Reply-To: <1035.202.189.68.42.1160038278.squirrel@mail.ardley.org> References: <20061005081955.5088E246AE@ws5-3.us4.outblaze.com> <1035.202.189.68.42.1160038278.squirrel@mail.ardley.org> Message-ID: >in MPEG2TransportStreamFromESSource > >00239 if (fInputBufferBytesAvailable == SIMPLE_PES_HEADER_SIZE) { >00240 // Use this presentationTime for our SCR: >00241 fSCR.highBit >00242 = ((presentationTime.tv_sec*45000 + >(presentationTime.tv_usec*9)/200)& >00243 0x80000000) != 0; >00244 fSCR.remainingBits >00245 = presentationTime.tv_sec*90000 + >(presentationTime.tv_usec*9)/100; >00246 fSCR.extension = (presentationTime.tv_usec*9)%100; > >>From ISO/IEC 13818-1 2.4.2.2 extension time is the lower 9 bits of a 27Mhz >clock. Not quite. It's actually the portion of a 27 MHz clock that can't be represented in the 90 kHz PCR base - i.e., it's the 27 MHz clock value modulo 300 (because 27 MHz = 90 kHz * 300). You're correct that this is a 9-bit value (because you need 9 bits to represent the values [0,299]; however, it's not "the lower 9 bits of a 27 MHz clock". >Are the calculations on lines 245 and 246 above correct? I believe so, yes. (Note that ((x/1000000)*27000000) % 300 == (9*x) % 100) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Oct 5 06:42:36 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Oct 2006 06:42:36 -0700 Subject: [Live-devel] Some modifications done on the library In-Reply-To: <20061005081955.5088E246AE@ws5-3.us4.outblaze.com> References: <20061005081955.5088E246AE@ws5-3.us4.outblaze.com> Message-ID: > > - In "FramedSource.hh", I don't believe that variables such as >> "fAfterGettingFunc" should be "protected". These are used only by >> the implementations of "FramedSource::getNextFrame()" and >> "FramedSource::afterGetting()" - which are central to the functioning >> of the library - and I don't see how/why subclasses would want to >> access (let alone modify) these variables. >That's because I implemented a class to duplicate received frames in >order to serve several RTP sinks from a single RTP source. The >signature of method getNextFrame() had to be modified to add a >clientID in argument list and therefore I needed to get access to >those variables. Alternatively (and this is the method I'd use), don't change "getNextFrame()", but instead have your 'Duplicator' class create a new object (of some new class - e.g., called "SourceDuplicate") to serve each of your sinks. I.e., each "SourceDuplicate" object would still be read by only one sink - preserving the current "getNextFrame()" model (and code). Instead, the (multiple) "SourceDuplicate" objects would read from the (single) "Duplicator" object using a *new* function that looks similar to "getNextFrame()", but which adds a new 'clientId' parameter. This would be similar to what I currently do with "MPEG1or2Demux" and "MPEG1or2DemuxedElementaryStream" (except that code is demultiplexing data rather than duplicating it). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Daniel at smartCast.org Thu Oct 5 13:04:55 2006 From: Daniel at smartCast.org (Daniel Graupner) Date: Thu, 5 Oct 2006 22:04:55 +0200 Subject: [Live-devel] MP3HTTPSource and reconnect Message-ID: <200610052204.56191.Daniel@smartCast.org> Hello, I create a MP3HTTPSource with a radio stream (icecast2), everything works fine. But if I use it with a mp3 file on a web-server I have problems with looping. The file plays once, then in afterplay the source is closed and created (same procedure as first play), this time the constructor hangs in connect (MP3HTTPSource line 42) and the call does not return. After killing it I got the following error: connect() failed: Interrupted system call. However, the connection is closed and opened again in afterplay, I verified this with sokstat (FreeBSD). Any Ideas why the constructor does not return? Regards, Daniel. From bidibulle at operamail.com Thu Oct 5 13:25:48 2006 From: bidibulle at operamail.com (David BERTRAND) Date: Thu, 05 Oct 2006 21:25:48 +0100 Subject: [Live-devel] Some modifications done on the library Message-ID: <20061005202548.7BC467AE9F@ws5-10.us4.outblaze.com> Ross, > instead have your 'Duplicator' class create a > new object (of some new class - e.g., called "SourceDuplicate") to > serve each of your sinks. I.e., each "SourceDuplicate" object would > still be read by only one sink - preserving the current > "getNextFrame()" model (and code). I have also created such object. It is inherited from FramedFilter and I can't remember exactly why but I failed to keep the existing getNextFrame ()function. Nevetheless I agree it is probably possible and should have been done a better way. I will maybe change this later ... Anyway, thank you for your tip David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze From rajeshkumar.r at imimobile.com Thu Oct 5 22:14:58 2006 From: rajeshkumar.r at imimobile.com (Rajesh) Date: Fri, 6 Oct 2006 10:44:58 +0530 Subject: [Live-devel] How can I play the recvd streaming Data using vlc or any other player Message-ID: <03f701c6e906$5dfb1750$f801000a@imidomain.com> Hi all I have made rtsp client and i am able to recv the stream and now I want to play the recvd stream.How should I integrate my rtsp client with any player. My requirement is to play the recvd streaming data thru any player with regards rajesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061005/d004c980/attachment.html From finlayson at live555.com Thu Oct 5 22:34:33 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 5 Oct 2006 22:34:33 -0700 Subject: [Live-devel] How can I play the recvd streaming Data using vlc or any other player In-Reply-To: <03f701c6e906$5dfb1750$f801000a@imidomain.com> References: <03f701c6e906$5dfb1750$f801000a@imidomain.com> Message-ID: >Hi all >I have made rtsp client and i am able to recv the stream and now I want to >play the recvd stream.How should I integrate my rtsp client with any player. >My requirement is to play the recvd streaming data thru any player You could just use the (open source) VLC media player , which has already done 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/20061005/aa0392f2/attachment.html From bidibulle at operamail.com Fri Oct 6 01:18:23 2006 From: bidibulle at operamail.com (David BERTRAND) Date: Fri, 06 Oct 2006 09:18:23 +0100 Subject: [Live-devel] memory leak in MultiFrameRTPSource on fSavedPacket Message-ID: <20061006081824.05A37246AE@ws5-3.us4.outblaze.com> Hi Ross, We have detected a memory leak in MultiFramedRTPSource.cpp on the fSavedPacket pointer. We don't know exactly when it happens but it seems that it happens for sure when there is a problem on the first packet received bt the MultiFramedRTPSource. Indeed, in this case the packet is not stored (not put in the queue) and hence not delete either. To fix this we just removed completelety fSavedPacket from the code, and it works. Can you tell me what is the goal of this pointer. Can't we simply remove it ? I attached the valgrind log (to show you the memory leak) and the patch that we use to fix the problem. Thanks, David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze -------------- next part -------------- A non-text attachment was scrubbed... Name: valgrind.log Type: application/octet-stream Size: 847 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20061006/85d36d56/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: MultiFramedRTPSource.cpp.diff Type: application/octet-stream Size: 2191 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20061006/85d36d56/attachment-0001.obj From max at code-it-now.com Fri Oct 6 02:10:37 2006 From: max at code-it-now.com (Maxim Petrov) Date: Fri, 06 Oct 2006 12:10:37 +0300 Subject: [Live-devel] buggy MPEG4 ES? Message-ID: <45261D8D.8080700@code-it-now.com> Hi Ross, I have example of MPEG4 ES file (http://82.207.113.45/test.m4v) which could not be correct parsed by "MPEG4VideoStreamParser" I invesigated that in that stream "VIDEO_OBJECT_LAYER" code appears (randomly) after VOP and before next VOP. I'm not sure if that's buggy stream or not, but ffmpeg decodes that stream without complains. Could you please look at that file? Thanks. -- Bye, Maxim. From lkovacs at xperts.hu Fri Oct 6 02:25:41 2006 From: lkovacs at xperts.hu (Levente Kovacs) Date: Fri, 6 Oct 2006 11:25:41 +0200 Subject: [Live-devel] buggy MPEG4 ES? In-Reply-To: <45261D8D.8080700@code-it-now.com> References: <45261D8D.8080700@code-it-now.com> Message-ID: <20061006112541.7641964f.lkovacs@xperts.hu> On Fri, 06 Oct 2006 12:10:37 +0300 Maxim Petrov wrote: > I have example of MPEG4 ES file (http://82.207.113.45/test.m4v) which > could not be correct parsed by "MPEG4VideoStreamParser" > I invesigated that in that stream "VIDEO_OBJECT_LAYER" code appears > (randomly) after VOP and before next VOP. > I'm not sure if that's buggy stream or not, but ffmpeg decodes that > stream without complains. > Could you please look at that file? >From what source did you capture thi file? I think this is not randomly, but after P_VOP before the first I_VOP in a new GVOP. Just an idea, did not looked in to the file. Levente From riwanda at yahoo.com Fri Oct 6 02:31:50 2006 From: riwanda at yahoo.com (Gunar Riwanda) Date: Fri, 6 Oct 2006 02:31:50 -0700 (PDT) Subject: [Live-devel] can't stream a file with testmpeg4videostreamer.cpp In-Reply-To: Message-ID: <20061006093150.22263.qmail@web54605.mail.yahoo.com> Hello, i'm a newbie with livemedia and really want to learn more about it. i tried to run the testmpeg4videostreamer.cpp with visual studio 2003 but it didn't really work like what i expected. first of all, i always got the error message: basictaskscheduler::singlestep():select() fails: no error which i think quite odd. If there's no error, why do i get this error message? or do i have misunderstanding here? After doing some debugging i noticed that this error message comes after the variable freadset has the fd_count value of 3 and the fd_array is (1920,1904,3). i think the problem is the 3rd array (3), but i'm not quite sure why.it has the socket error message 10038. other than that problem, the rtpGroupsock.multicastSendOnly(); and rtcpGroupsock.multicastSendOnly(); have the socket error message 10049. is it also a problem? i would be really grateful for every help. best regards, gunar ps: i use the file test.avi which is generated/encoded by the output_example.c of FFMPEG (but only video stream, without the audio. so basically i encoded an only-video AVI file.) pss: the same problem also occured when i used testmpeg1or2videostreamer.cpp the problem will occur by testondemandrtspserver after i tried to open the file with windows media player --------------------------------- Stay in the know. Pulse on the new Yahoo.com. Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061006/4834ecf6/attachment.html From max at code-it-now.com Fri Oct 6 04:45:31 2006 From: max at code-it-now.com (Maxim Petrov) Date: Fri, 06 Oct 2006 14:45:31 +0300 Subject: [Live-devel] buggy MPEG4 ES? In-Reply-To: <20061006112541.7641964f.lkovacs@xperts.hu> References: <45261D8D.8080700@code-it-now.com> <20061006112541.7641964f.lkovacs@xperts.hu> Message-ID: <452641DB.4030106@code-it-now.com> An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061006/0d5eae6e/attachment-0001.html From max at code-it-now.com Fri Oct 6 04:57:43 2006 From: max at code-it-now.com (Maxim Petrov) Date: Fri, 06 Oct 2006 14:57:43 +0300 Subject: [Live-devel] buggy MPEG4 ES? In-Reply-To: <20061006112541.7641964f.lkovacs@xperts.hu> References: <45261D8D.8080700@code-it-now.com> <20061006112541.7641964f.lkovacs@xperts.hu> Message-ID: <452644B7.2030101@code-it-now.com> Levente Kovacs wrote: >On Fri, 06 Oct 2006 12:10:37 +0300 >Maxim Petrov wrote: > > > >>I have example of MPEG4 ES file (http://82.207.113.45/test.m4v) which >>could not be correct parsed by "MPEG4VideoStreamParser" >>I invesigated that in that stream "VIDEO_OBJECT_LAYER" code appears >>(randomly) after VOP and before next VOP. >>I'm not sure if that's buggy stream or not, but ffmpeg decodes that >>stream without complains. >>Could you please look at that file? >> >> > >>From what source did you capture thi file? I think this is not randomly, but after P_VOP before the first I_VOP in a new GVOP. Just an idea, did not looked in to the file. > > Sorry, my previous message was in HTML.. Replying again. Stream like that send MangoDSP devices.. not sure about what's model was sending exactly that stream. Yes, seems you are right.. VOL does not appear randomly, just before next I_VOP. It looks like: parsing VisualObjectSequence profile_and_level_indication: 03 parsing VisualObject visual_object_type: 0x1 saw a video_object_start_code: 0x00000101 parsing VideoObjectLayer vop_time_increment_resolution: 30 fixed_vop_time_increment: 1 fixed_vop_rate: 1; 'frame' (really tick) rate: 30.000000 parsing GroupOfVideoObjectPlane time_code: 0x00040, hours 0, minutes 0, marker_bit 1, seconds 0 #parsing VideoObjectPlane vop_coding_type: 0(I), modulo_time_base: 0, vop_time_increment: 0 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 1 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 2 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 3 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 4 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 5 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 6 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 7 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 8 #parsing VideoObjectPlane vop_coding_type: 1(P), modulo_time_base: 0, vop_time_increment: 9 MPEG4VideoStreamParser::parseVideoObjectPlane(): Saw unexpected code 0x120 <---- VOL start code here But liveMedia thinks that's VOP #parsing VideoObjectPlane MPEG4VideoStreamParser::parseVideoObjectPlane(): marker bit not set! vop_coding_type: 0(I), modulo_time_base: 0, vop_time_increment: 1 #parsing VideoObjectPlane vop_coding_type: 0(I), modulo_time_base: 0, vop_time_increment: 10 .... I've added little path to MPEG4VideoStreamFramer.cpp: @@ -634,7 +634,15 @@ default: { if (isVideoObjectStartCode(next4Bytes)) { setParseState(PARSING_VIDEO_OBJECT_LAYER); - } else { + } else if (isVideoObjectLayerStartCode(next4Bytes)){ + // copy all bytes that we see, up until we reach a VOP_START_CODE: + u_int32_t next4Bytes = get4Bytes(); + while (next4Bytes != VOP_START_CODE) { + saveToNextCode(next4Bytes); + } + setParseState(PARSING_VIDEO_OBJECT_PLANE); + } else + { usingSource()->envir() << "MPEG4VideoStreamParser::parseVideoObjectPlane(): Saw unexpected code " << (void*)next4Bytes << "\n"; setParseState(PARSING_VIDEO_OBJECT_PLANE); // the safest way to recover... Works fine for me. But not sure if it will work fine for other streams. -- Bye, Maxim. From lkovacs at xperts.hu Fri Oct 6 05:28:03 2006 From: lkovacs at xperts.hu (Levente Kovacs) Date: Fri, 6 Oct 2006 14:28:03 +0200 Subject: [Live-devel] buggy MPEG4 ES? In-Reply-To: <452644B7.2030101@code-it-now.com> References: <45261D8D.8080700@code-it-now.com> <20061006112541.7641964f.lkovacs@xperts.hu> <452644B7.2030101@code-it-now.com> Message-ID: <20061006142803.66047a58.lkovacs@xperts.hu> On Fri, 06 Oct 2006 14:57:43 +0300 Maxim Petrov wrote: > I've added little path to MPEG4VideoStreamFramer.cpp: Seems good to me. Ross? But I think it's not the task of Live555 to parse an mpeg4 stream. Will be done in the final decoder. The thing is, that there is 10000+ type of MPEG4 streams out there. I am dealing with streams comming from Panasonic IP cameras. It is a big mess. They not even insert VOS headers, so I have to insert pseudo VOSs. Sigh. Levente From finlayson at live555.com Fri Oct 6 07:34:22 2006 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 6 Oct 2006 07:34:22 -0700 Subject: [Live-devel] can't stream a file with testmpeg4videostreamer.cpp In-Reply-To: <20061006093150.22263.qmail@web54605.mail.yahoo.com> References: <20061006093150.22263.qmail@web54605.mail.yahoo.com> Message-ID: >first of all, i always got the error message: > >basictaskscheduler::singlestep():select() fails: no error > >which i think quite odd. If there's no error, why do i get this error message? Are you running an old version of Windows (prior to XP)? If so, try adding #define READ_FROM_FILES_SYNCHRONOUSLY 1 to the start of "liveMedia/ByteStreamFileSource.cpp", and recompile. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From riwanda at yahoo.com Fri Oct 6 08:10:29 2006 From: riwanda at yahoo.com (Gunar Riwanda) Date: Fri, 6 Oct 2006 08:10:29 -0700 (PDT) Subject: [Live-devel] can't stream a file with testmpeg4videostreamer.cpp In-Reply-To: Message-ID: <20061006151029.53200.qmail@web54615.mail.yahoo.com> thanks for the fast reply :) i'm using xp professional sp2, so i guess #define READ_FROM_FILES_SYNCHRONOUSLY 1 don't really help that much. i've done what u said, though, with no luck of course. and i'd like to add some more information, when i'm testing the mpeg4 part testondemandtrspserver, and try open it with windows media player, then i get the error message "basictaskscheduler::singlestep():select() fails: no error", right away. But when i use the mpeg1or2ES part, i don't get any error message. But WMP still cant open it. For me its quite confusing. regards, gunar Ross Finlayson wrote: >first of all, i always got the error message: > >basictaskscheduler::singlestep():select() fails: no error > >which i think quite odd. If there's no error, why do i get this error message? Are you running an old version of Windows (prior to XP)? If so, try adding #define READ_FROM_FILES_SYNCHRONOUSLY 1 to the start of "liveMedia/ByteStreamFileSource.cpp", and recompile. -- 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 --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2?/min or less. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061006/2ecfc92f/attachment.html From finlayson at live555.com Fri Oct 6 12:44:36 2006 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 6 Oct 2006 12:44:36 -0700 Subject: [Live-devel] buggy MPEG4 ES? In-Reply-To: <20061006142803.66047a58.lkovacs@xperts.hu> References: <45261D8D.8080700@code-it-now.com> <20061006112541.7641964f.lkovacs@xperts.hu> <452644B7.2030101@code-it-now.com> <20061006142803.66047a58.lkovacs@xperts.hu> Message-ID: >On Fri, 06 Oct 2006 14:57:43 +0300 >Maxim Petrov wrote: > >> I've added little path to MPEG4VideoStreamFramer.cpp: > >Seems good to me. Ross? Yes, this patch looks OK. It will be included in the next release of the source code. >But I think it's not the task of Live555 to parse an mpeg4 stream. When we're reading a MPEG-4 stream from a file (i.e., not as discrete frames), we need to parse the stream in order to figure out where 'visual objects' etc. start and end. This is so we can pack data into the outgoing RTP packets correctly. (We also need to parse timing information, so we can set the RTP timestamp correctly.) You're correct, though, that the most detailed parsing of the MPEG-4 data is left to decoders. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Oct 6 12:51:20 2006 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 6 Oct 2006 12:51:20 -0700 Subject: [Live-devel] can't stream a file with testmpeg4videostreamer.cpp In-Reply-To: <20061006151029.53200.qmail@web54615.mail.yahoo.com> References: <20061006151029.53200.qmail@web54615.mail.yahoo.com> Message-ID: >and i'd like to add some more information, >when i'm testing the mpeg4 part testondemandtrspserver, and try open >it with windows media player, then i get the error message >"basictaskscheduler::singlestep():select() fails: no error", right away. >But when i use the mpeg1or2ES part, i don't get any error message. >But WMP still cant open it. For me its quite confusing. I'm sorry I can't help you with your problem. However, don't try to use Windows Media Player to play the stream - it probably won't work. Instead, use a standards compliant player such as VLC (preferred), or QuickTime Player. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Oct 6 13:45:50 2006 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 6 Oct 2006 13:45:50 -0700 Subject: [Live-devel] memory leak in MultiFrameRTPSource on fSavedPacket In-Reply-To: <20061006081824.05A37246AE@ws5-3.us4.outblaze.com> References: <20061006081824.05A37246AE@ws5-3.us4.outblaze.com> Message-ID: >To fix this we just removed completelety fSavedPacket from the >code, and it works. Can you tell me what is the goal of this >pointer. "fSavedPacket" is used to optimize the common case where packets arrive in order, without loss. It is a preallocated buffer that is kept around to avoid having to do a "new"/"delete" - for each incoming packet - in this common case. (See the code for "getFreePacket()" and "freePacket()".) > Can't we simply remove it ? Yes, but you then lose the optimization. > I attached the valgrind log (to show you the memory leak) I think "valgrind" may be mistaken in this case. I don't think there is a memory leak here. (The "fSavedPacket" buffer is allocated only once, when the "MultiFramedRTPSource" object first starts receiving data, and is deleted when the "MultiFramedRTPSource" object is deleted.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rahul.ray at gmail.com Fri Oct 6 15:51:19 2006 From: rahul.ray at gmail.com (Rahul Ray) Date: Fri, 6 Oct 2006 15:51:19 -0700 Subject: [Live-devel] global time-out Message-ID: Hi, Is there a global timeout function, in case getResponse1(..) [ called from openRTSP] does not return anything ? Rather is there any timeout parameters that could be set to make no function wait for some amount of time before they are forced to return ? Thanks for your help. -best, Rahul From jordanjohnp at yahoo.com Sat Oct 7 08:17:55 2006 From: jordanjohnp at yahoo.com (John Jordan) Date: Sat, 7 Oct 2006 08:17:55 -0700 (PDT) Subject: [Live-devel] need access to Server Type from RTSPClient Message-ID: <20061007151755.54947.qmail@web51412.mail.yahoo.com> Hi, I have an application that uses the RTSPClient. The application needs to know what kind of server it is accessing. However, this information is not exposed in the public interface of the RTSPClient. Do you think it is reasonable to add a new operation, of the form: class RTSPClient: public Medium { . . public: serverType(void) { return fServerTypeStr; } private: char *fServerTypeStr; } The fServerTypeStr would be assigned like this (or similar): else if (_strncasecmp(lineStart, "Server: ", 8) == 0) { delete fServerTypeStr; fServerTypeStr = strDup(&lineStart[8]); } This would be done in both the RTSPClient::sendOptionsCmd() and RTSPClient::describeURL() implementations. Note that at least one commercial RTSP video server provides the "Server:" string in the OPTIONS response. I'd like to request that this function be added to a future release of liveMedia. If there is a better approach, please let me know. Thanks for your help John __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From e.beckers at gmail.com Sat Oct 7 09:53:58 2006 From: e.beckers at gmail.com (Erwin Beckers) Date: Sat, 7 Oct 2006 18:53:58 +0200 Subject: [Live-devel] openrtsp stackoverflow Message-ID: First of, thank you for this great library! I'm trying to stream a mpeg-2 transport stream using the testOnDemandRTSPServer over rtsp But i get several issues 1. Playback is perfect when using mplayer, but when using VLC, i only get video and no audio 2. When using openRTSP to record the stream to disk, it produces a stack overflow I know VLC is not your program, but just wondering is this is a known issue But openrtsp seems to produce a stack overflow and maybe this happens since we're only streaming 1 media (a mpeg-2 transport stream) and not the normal 2 media types (audio and video track) I tried analyzing the stack overflow and it happens in FileSink::afterGettingFrame1() at the end this function calls continuePlaying() which again in the end seems to calls FileSink::afterGettingFrame1() again openrtsp log: >openrtsp rtsp://192.168.100.102/stream1 Opened URL "rtsp://192.168.100.102/stream1", returning a SDP description: v=0 o=- 1160239838399000 1 IN IP4 192.168.100.102 s=Session streamed by "Streamserver v1.0" i=stream1 t=0 0 a=tool:LIVE555 Streaming Media v2006.06.27 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "Streamserver v1.0" a=x-qt-text-inf:stream1 m=video 0 RTP/AVP 33 c=IN IP4 0.0.0.0 a=control:track1 Created receiver for "video/MP2T" subsession (client ports 3208-3209) Setup "video/MP2T" subsession (client ports 3208-3209) Created output file: "video-MP2T-1" Started playing session Receiving streamed data... .... crashes after a few seconds... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061007/67ea6afa/attachment-0001.html From finlayson at live555.com Sat Oct 7 10:45:02 2006 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 7 Oct 2006 10:45:02 -0700 Subject: [Live-devel] "test.m4v" is now "test.m4e" Message-ID: FYI, starting with the current software release, the demo applications (in the "testProgs" directory) that stream MPEG-4 Elementary Stream video files now use a file name "test.m4e" rather than "test.m4v". This is to avoid confusion, because Apple has coopted the ".m4v" suffix for MPEG-4 (audio+video) files, which are different. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Oct 7 10:47:18 2006 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 7 Oct 2006 10:47:18 -0700 Subject: [Live-devel] need access to Server Type from RTSPClient In-Reply-To: <20061007151755.54947.qmail@web51412.mail.yahoo.com> References: <20061007151755.54947.qmail@web51412.mail.yahoo.com> Message-ID: >I'd like to request that this function be added to a >future release of liveMedia. That sounds reasonable. Please send a 'patch' file, and I'll look into merging it into the released code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Oct 7 11:20:25 2006 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 7 Oct 2006 11:20:25 -0700 Subject: [Live-devel] openrtsp stackoverflow In-Reply-To: References: Message-ID: >I'm trying to stream a mpeg-2 transport stream using the >testOnDemandRTSPServer over rtsp >But i get several issues >1. Playback is perfect when using mplayer, but when using VLC, i >only get video and no audio >2. When using openRTSP to record the stream to disk, it produces a >stack overflow > >I know VLC is not your program However, it does use the "LIVE555 Streaming Media" code (for RTSP client support), so this is of interest to us. >but just wondering is this is a known issue No, it's not. Please make your server available on the public Internet (i.e., not behind a NAT), and send us the (publically accessible) "rtsp://" URL, so we can test this for ourselves. >But openrtsp seems to produce a stack overflow and maybe this >happens since we're only >streaming 1 media (a mpeg-2 transport stream) and not the normal 2 >media types (audio and video track) > >I tried analyzing the stack overflow and it happens in >FileSink::afterGettingFrame1() >at the end this function calls continuePlaying() >which again in the end seems to calls FileSink::afterGettingFrame1() again No, there's no infinite recursion (and so there should be no stack overflow) happening here. Between the call to "continuePlaying()" and the next call to "afterGettingFrame1()", the code returns to the event loop (to handle the reception of the incoming network packet). But again, in order to debug your problem, I would need to know the (publically accessible) "rtsp://" URL of your stream. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yunjnz at yahoo.com Sat Oct 7 17:49:46 2006 From: yunjnz at yahoo.com (yj) Date: Sat, 7 Oct 2006 17:49:46 -0700 (PDT) Subject: [Live-devel] About long time waiting while stream unavailable when using Live555 as a client In-Reply-To: Message-ID: <20061008004946.24989.qmail@web35812.mail.mud.yahoo.com> Hi, I have a problem while using Live555 as a RTSP client, If the streaming URL isn't available, the RTSPClient::sendOptionsCmd and describeURL won't return until a long time waiting, how does this problem happened? is there any way to let the corresponding call return immedialtely if the URL isn't available? Thanks a lot. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From miha at martinec.si Sun Oct 8 09:11:36 2006 From: miha at martinec.si (Miha Martinec) Date: Sun, 08 Oct 2006 18:11:36 +0200 Subject: [Live-devel] live555 rtsp ff/rw question Message-ID: Hello everyone. Ross Finlayson directed me to this list. I have successfully developed a small RTSP server using live555 libraries and set up a testing environment. I am using MPEG2TS video stream for testing the RTSP server. The server works fine, but I can't get the functions fast forward and reverse to work. I have done some code-digging and found out that the functions for fast forward and reverse have not yet been implemented in live555 libs. Does anyone here have a working code for ff/rw for MPEG2TS streams or knows when this functions will be implemented? The FAQ says this functions are done, but in a seperate project and may be added to this project in the end of 2006. How soon will this be implemented, is there a more specific date in place? Is it possible to get the code from the other project, so I can add it to this one by myself? Thank you. Best regards, Miha Martinec From finlayson at live555.com Sun Oct 8 10:57:06 2006 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 8 Oct 2006 10:57:06 -0700 Subject: [Live-devel] live555 rtsp ff/rw question In-Reply-To: References: Message-ID: >Does anyone here have a working code for ff/rw for MPEG2TS streams or >knows when this functions will be implemented? The FAQ says this functions >are done, but in a seperate project and may be added to this project in >the end of 2006. How soon will this be implemented, is there a more >specific date in place? No. If I could give you a more specific date (that I could be sure of), then I would already have done so. I realize that lots of people are waiting for this, but everyone, please stop asking about it - it won't make it happen any faster. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gertjan.de.back.2006 at cer.com Mon Oct 9 04:21:37 2006 From: gertjan.de.back.2006 at cer.com (Gertjan de Back) Date: Mon, 09 Oct 2006 13:21:37 +0200 Subject: [Live-devel] Stream to sound card hickups Message-ID: <452A4CE2.9929.E8DB8C0@gertjan.de.back.2006.cer.com> Hello all, I'm using the LiveMedia stack to play an RTP based VoIP audio stream (uLaw) to a sound card (VIA82C686/AC97). Basically I open a FileSink (/dev/dsp) and SimpleRTPSource as follows: ~~~~ in_addr clientip; clientip.s_addr = our_inet_addr("192.168.10.216"); fileSink = FileSink::createNew(*env, "/dev/dsp", 20000, False); if (fileSink == NULL) { *env << "\nFailed to open audio device.\n"; return 0; } Groupsock rtpGroupsock(*env, clientip, 10010, 1); SimpleRTPSource* RTPSource = SimpleRTPSource::createNew(*env, &rtpGroupsock, (unsigned char)0, 8000, "PCMU", (unsigned)0, False); if (RTPSource == NULL) { *env << "error while creating RTPSource\n"; return 0; } receivedAudioSource = PCMFromuLawAudioSource::createNew(*env, RTPSource); if(receivedAudioSource == NULL) { *env << "Error while creating u-law to 16bit PCM converter\n"; return 0; } fileSink->startPlaying(*receivedAudioSource, subsessionAfterPlaying, NULL); env->taskScheduler().doEventLoop(); // does not return ~~~~ It works okay, except for irregular delays in playback of the incoming RTP stream. Occasional buffer underruns are seen in the via82cxx_audio driver in Linux 2.4.32 which seem to temporarily pause the DMA transfers causing hicks and delays up to a few seconds, which makes it unusable for a telephone conversation. * Did I understand the use of the API correctly? * Is there any proved sample code to play a stream to the sound card? * Has anyone experienced similar hicks/delays in playback to a (VIA) sound card? * Does anyone know of a LiveMedia based app which runs fine on the VIA audio chip? Thanks for your help! Gertjan de Back From riwanda at yahoo.com Mon Oct 9 07:29:04 2006 From: riwanda at yahoo.com (Gunar Riwanda) Date: Mon, 9 Oct 2006 07:29:04 -0700 (PDT) Subject: [Live-devel] can't stream a file with testmpeg4videostreamer.cpp In-Reply-To: Message-ID: <20061009142904.88627.qmail@web54614.mail.yahoo.com> after some more debugging i'm almost sure that it has a socket problem, because of the produced error code (10038 and 10049). In addition, i didn't really quite follow the instruction "how to configure and build the code on windows" What i did was: -generate the .mak files -build these .mak files on command prompt using nmake /f *****.mak in the project properties on visual studio i did: -put all the include folders under "additional include directories" - copy all the made .lib files (libUsageEnvironment.lib libliveMedia.lib libgroupsock.lib libBasicUsageEnvironment.lib) into one folder and put the folder under "additional library directories" - put all the .lib files under "additional dependencies" - put wsock32.lib also under "additional dependencies" (otherwise i'd get a bunch of error LNK 2001) i did this, because i didn't find any "open workspace" menu command on visualstudio 2003 did i miss something? or did i do something wrong? regards, gunar --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061009/23634e86/attachment.html From g00d_t0_g0 at hotmail.com Mon Oct 9 14:04:16 2006 From: g00d_t0_g0 at hotmail.com (Kareem Kev M.) Date: Mon, 09 Oct 2006 21:04:16 +0000 Subject: [Live-devel] Help for Windows Xp user Message-ID: I am trying to build the code in Windows Xp, but i cannot follow the instructions on the site..Can anyone give me astep by step outline on what to do and the software i need to download to complete the build?....What is Devstudio.. and how do I run 'cd' to my 'live' directory, if i dont have Cygwin on my Windows PC... please help..thanks _________________________________________________________________ Find a local pizza place, music store, museum and more…then map the best route! http://local.live.com From xcsmith at rockwellcollins.com Mon Oct 9 14:44:03 2006 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 9 Oct 2006 16:44:03 -0500 Subject: [Live-devel] Help for Windows Xp user Message-ID: I am trying to build the code in Windows Xp, but i cannot follow the instructions on the site..Can anyone give me astep by step outline on what to do and the software i need to download to complete the build?....What is Devstudio.. and how do I run 'cd' to my 'live' directory, if i dont have Cygwin on my Windows PC... please help..thanks Devstudio is refering to whatever arbitrary Development Environment you are using (Microsoft Visual Studio and Eclipse are both exampes of Development Environments). 'cd' is a DOS command meaning "change directory." There are a few ways to get the DOS interface up. Try Start->Run and then type "cmd /k" into the box. You will get a new window that shows your hard drive letter and a cursor. "C:\> _ " Then type "cd" followed by the path to your LIVE directory. So if my LIVE is in a folder named "LIVE" on hard drive "C", then I type "cd C:\LIVE" You need a compiler to make the LIVE library. So you should either download Cygwin or buy MS Visual Studio. http://en.wikipedia.org/wiki/Cygwin Hope this helps! ~Medra From finlayson at live555.com Mon Oct 9 15:06:27 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 9 Oct 2006 15:06:27 -0700 Subject: [Live-devel] Stream to sound card hickups In-Reply-To: <452A4CE2.9929.E8DB8C0@gertjan.de.back.2006.cer.com> References: <452A4CE2.9929.E8DB8C0@gertjan.de.back.2006.cer.com> Message-ID: Gertjan, Your code looks OK. However, as you've discovered, the natural variablity (jitter) of incoming RTP packets means that you need to have sufficient buffering at the receiver end to handle this. The simplest way to add buffer space - if you can - is using the operating system. Perhaps there's some way to increase the buffer size used by the audio driver (e.g., using an "ioctl" of some sort, or perhaps some boot-time kernel configuration)?? Alternatively, if you have named pipes available, then you might be able to use one of those (in front of your audio device) to increase buffer space. As a last resort, you could write your own buffering filter object - for your application - that would work with the "LIVE555 Streaming Media" libraries. I would investigate OS-based solutions first, though. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chenw at blrcsv.china.bell-labs.com Mon Oct 9 19:31:39 2006 From: chenw at blrcsv.china.bell-labs.com (chenwei) Date: Tue, 10 Oct 2006 10:31:39 +0800 Subject: [Live-devel] How can I add audio track ? Message-ID: <20061010022904.020C58719@blrcsv.china.bell-labs.com> Dear All: I found a lot of demos in directory "testProgs" have only video track, how can I transfer audio track too? Is there any example such as mpeg1/2 program stream? many thanks. ????????chenwei ????????chenw at blrcsv.china.bell-labs.com ??????????2006-10-10 From chenw at blrcsv.china.bell-labs.com Tue Oct 10 19:56:05 2006 From: chenw at blrcsv.china.bell-labs.com (chenwei) Date: Wed, 11 Oct 2006 10:56:05 +0800 Subject: [Live-devel] How can I inject a stream to a remote darwin? Message-ID: <20061011025323.E0993872D@blrcsv.china.bell-labs.com> Dear all: I am using testMpeg4VideoToDarwin for injecting test.m4v to a remote Darwin Server. I type ./testMpeg4ViedoToDarwin ServerAddress, but there is a error: injector->setDestination() failed: cannot handle ANNOUNCE response: RTSP/1.0 401 Unauthorized I think it is because I didn't announce the userName and password of the remote server machine, so, how can I add them? I have read the code of testMpeg4VideoToDarwin.cpp, but there are no hint:( Please help me out. Many thanks. ????????chenwei ????????chenw at blrcsv.china.bell-labs.com ??????????2006-10-11 From finlayson at live555.com Tue Oct 10 23:33:25 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 10 Oct 2006 23:33:25 -0700 Subject: [Live-devel] How can I inject a stream to a remote darwin? In-Reply-To: <20061011025323.E0993872D@blrcsv.china.bell-labs.com> References: <20061011025323.E0993872D@blrcsv.china.bell-labs.com> Message-ID: >Dear all: > > I am using testMpeg4VideoToDarwin for injecting test.m4v to a >remote Darwin Server. > > I type ./testMpeg4ViedoToDarwin ServerAddress, but there is a error: > > injector->setDestination() failed: cannot handle ANNOUNCE >response: RTSP/1.0 401 Unauthorized > > I think it is because I didn't announce the userName and >password of the remote server machine, so, how can I > >add them? I have read the code of testMpeg4VideoToDarwin.cpp, but >there are no hint:( As noted in "liveMedia/include/DarwinInjector.hh": Note: You must have 'write' permission on the Darwin Streaming Server. This can be set up using a "qtaccess" file in the server's 'movies' directory. For example, the following "qtaccess" file allows anyone to play streams from the server, but allows only valid users to inject streams *into* the server: require valid-user require any-user Use the "remoteUserName" and "remotePassword" parameters to "setDestination()", as appropriate. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bidibulle at operamail.com Wed Oct 11 05:57:25 2006 From: bidibulle at operamail.com (David BERTRAND) Date: Wed, 11 Oct 2006 13:57:25 +0100 Subject: [Live-devel] memory leak in MultiFrameRTPSource on fSavedPacket Message-ID: <20061011125725.5D2F9CA0A4@ws5-11.us4.outblaze.com> Ross, We further investigated this (very complex) issue and finally found what happens. Everything is fine when the packet buffer always contain one single packet (common case, only "fSavedPacket" in the queue). However, if a second packet comes in the list, we have "fSavedPacket" and another packet that I will call "second packet" in the list. If "sink->stopPlaying()" occurs between delivery of "fSavedPacket" (to the sink) and delivery of "second packet", then "ReorderingPacketBiffer:reset()" method doesn't delete "fSavedPacket" because : - "fHeadPacket" is not NULL ("second packet" is still in the queue) - and "fSavedPacket" is not in the list anymore. Do you see now the problem ? FYI each memory loss is 10KB size. We tried to fix this in the attached patch, without removing your optimization algorithm. We added a boolean "fSavedPacketFree" to know whether "fSavedPacket" is in the queue. Thank you in advance for your feedback on this. David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze -------------- next part -------------- A non-text attachment was scrubbed... Name: MultiFramedRTPSource.cpp.patch Type: application/octet-stream Size: 2549 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20061011/df86b848/attachment.obj From rahul.ray at gmail.com Wed Oct 11 12:49:33 2006 From: rahul.ray at gmail.com (Rahul Ray) Date: Wed, 11 Oct 2006 12:49:33 -0700 Subject: [Live-devel] format Message-ID: Hi, When I use mpeg4 stream using rtsp ( openrtsp) and -m option, what format the frames are stored in ? When I do : file it says, data. Is it possible to direct it to store it as jpeg while using mpeg4 ? -rahul From finlayson at live555.com Thu Oct 12 00:27:14 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Oct 2006 00:27:14 -0700 Subject: [Live-devel] memory leak in MultiFrameRTPSource on fSavedPacket In-Reply-To: <20061011125725.5D2F9CA0A4@ws5-11.us4.outblaze.com> References: <20061011125725.5D2F9CA0A4@ws5-11.us4.outblaze.com> Message-ID: >Do you see now the problem ? Yes - thanks for the patch. It will be included in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From wei.francois at gmail.com Thu Oct 12 01:30:20 2006 From: wei.francois at gmail.com (=?GB2312?B?s8K2q86w?=) Date: Thu, 12 Oct 2006 16:30:20 +0800 Subject: [Live-devel] couldn't "make" sucessfully with ./genMakefile uClinux Message-ID: <503760b30610120130w4960a77bndee5b3828868d3e4@mail.gmail.com> Hi, everyone: I couldn't "make" sucessfully with uClinux, after "make", it shows: ./BasicUsageEnvironment/libBasicUsageEnvironment.a(.gnu.linkonce.d._ZTI15DelayQueueEntry+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info' ../BasicUsageEnvironment/libBasicUsageEnvironment.a(.gnu.linkonce.d._ZTI10DelayQueue+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' ../BasicUsageEnvironment/libBasicUsageEnvironment.a(.gnu.linkonce.d._ZTIN14BasicHashTable8IteratorE+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' ../BasicUsageEnvironment/libBasicUsageEnvironment.a(.gnu.linkonce.d._ZTI14BasicHashTable+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' collect2: ld returned 1 exit status make[1]: *** [testMP3Streamer] Error 1 make[1]: Leaving directory `/opt/MPlayer/live/testProgs' make: *** [testProgs/testMP3Streamer] Error 2 Does it because I should modify "config.uClinux" file(I used it as default option) or something else? Then, how could i test Live555 can stream live video to the client and the client can view the live video in the web browser(such as IE,firefox)? Thank you for your helping! -- Regards, francois_wei -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061012/0237a4ed/attachment.html From darnold at futurec.net Thu Oct 12 11:55:38 2006 From: darnold at futurec.net (David Arnold) Date: Thu, 12 Oct 2006 11:55:38 -0700 Subject: [Live-devel] Problem with GroupsockHellper.cpp In-Reply-To: Message-ID: With the latest version of live555 (Oct 07 2006) on Windows XP, all outgoing datagrams have a TTL (Time-to-Live) value of 1, which won't work across the Internet. I noticed that at around line # 77 in GroupsockHelper.cpp, the #ifdef WINDOZE were removed causing the calls to setsockopt(REUSEPORT) and (IP_MULTICAST_LOOP) to be called. When I comment-out these calls, the TTL value is set to 128 on outgoing unicast datagrams. Dave Arnold Future Concepts, La Verne The information contained in this electronic mail transmission is intended only for the use of the individual or entity named above and is privileged and confidential. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Any dissemination, distribution or copying of this communication other than to the person or entity named above is strictly prohibited. If you have received this communication in error, please immediately delete it from your system. From finlayson at live555.com Thu Oct 12 12:58:07 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 12 Oct 2006 12:58:07 -0700 Subject: [Live-devel] Problem with GroupsockHellper.cpp In-Reply-To: References: Message-ID: >With the latest version of live555 (Oct 07 2006) on Windows XP, all outgoing >datagrams have a TTL (Time-to-Live) value of 1, which won't work across the >Internet. > >I noticed that at around line # 77 in GroupsockHelper.cpp, the #ifdef >WINDOZE were removed causing the calls to setsockopt(REUSEPORT) and >(IP_MULTICAST_LOOP) to be called. When I comment-out these calls, the TTL >value is set to 128 on outgoing unicast datagrams. OK, starting with the newest version (2006.10.12a), those calls are now #ifdef'd out, once again, for Windows. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dbikash at gmail.com Thu Oct 12 21:55:26 2006 From: dbikash at gmail.com (Deeptendu Bikash) Date: Fri, 13 Oct 2006 10:25:26 +0530 Subject: [Live-devel] H.264 Message-ID: <29758ec70610122155o107a1f9bs874586625c67b023@mail.gmail.com> Hi, Though this might not strictly involve Live555.com, yet I would appreciate any help. I am writing a RTP depacketizer that feeds directly to the ffmpeg decoder. Though I am able to pass on the NAL units correctly, the decoder is not able to decode it...in fact it says the frames are of zero length and discards the NAL Units. Does the ffmpeg H.264 decoder require anything other than the NAL Units for decoding? I mean any other parameters from SDP like config, sprop-parameter-sets, width, height, etc? If yes, what and in what format? Thanks, Deeptendu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061012/f1deccaa/attachment.html From finlayson at live555.com Fri Oct 13 00:39:59 2006 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 13 Oct 2006 00:39:59 -0700 Subject: [Live-devel] H.264 In-Reply-To: <29758ec70610122155o107a1f9bs874586625c67b023@mail.gmail.com> References: <29758ec70610122155o107a1f9bs874586625c67b023@mail.gmail.com> Message-ID: >Though this might not strictly involve >Live555.com, yet I would appreciate any help. > >I am writing a RTP depacketizer that feeds directly to the ffmpeg decoder. If you're not using the "LIVE555 Streaming Media" code for this, then your message is off-topic for this mailing list. You're also reinventing the wheel. The Open Source VLC media player already does this - using the "LIVE555 Streaming Media" code, and ffmpeg. -- 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/20061013/a6f837eb/attachment-0001.html From juraj.michalek at asinus.org Sat Oct 14 10:56:09 2006 From: juraj.michalek at asinus.org (Juraj Michalek) Date: Sat, 14 Oct 2006 19:56:09 +0200 Subject: [Live-devel] Bug and fix report: WISstreamer.cpp - Unable to find emulated OSS device. Message-ID: <453124B9.1070707@asinus.org> Hello. I want to report you problem which I found in: http://www.live555.com/wis-streamer/source/wis-streamer.tar.gz I have kernel 2.6.16 and Plextor ConvertX. wis-streamer refuse to start with following error: wis-streamer: A streaming server for the WIS GO7007 encoder driver For driver documentation and source code, see: For server documentation and source code, see: Built using "LIVE555 Streaming Media": Initializing... ERROR: Unable to find emulated OSS device. ERROR: Failed to create WIS input device When I found this, I dig deeper in the code and I've found following strange behaviour. Here is list of cat /proc/asound/oss/devices 0: [0- 0]: mixer 1: : sequencer 2: [0- 0]: raw midi 3: [0- 0]: digital audio 4: [0- 0]: digital audio 8: : sequencer 9: [0- 0]: raw midi 12: [0- 1]: digital audio 13: [0- 1]: raw midi 14: [0- 1]: raw midi 16: [1- 0]: mixer 19: [1- 0]: digital audio 20: [1- 0]: digital audio Plextor minor number is 19. But for some weird reson wis-streamer parse this file only to line with minor number 16 and use this number. Which make no sense. It seem that method - WISInput.cpp - line 208: if (sscanf(line, "%d: [%u-%*u]: digital audio\n", &m, &n) != 2) continue; match line: 16: [1- 0]: mixer instead of: 19: [1- 0]: digital audio I try to find reason, why there is problem in sscanf, but I have no idea why it behave in this way. Definition of sscanf is e.g. here: http://www.cplusplus.com/ref/cstdio/sscanf.html I test it with gcc-4.0 and gcc-4.1 and appropritiate libraries, but result was always same. So I solve this problem by adding one more cotrol after 208: if (strstr(line, "digital audio")== NULL) continue; After this fix wis-streame work correctly. Please consider appropritiate correction for wis-streamer. Have a nice day and good luck with development Juraj Michalek -- Asinus IT Group - http://www.asinus.org Personal page: http://juraj.michalek.asinus.org Asinus is member of Blucina.net team From chenw at blrcsv.china.bell-labs.com Sun Oct 15 19:41:42 2006 From: chenw at blrcsv.china.bell-labs.com (chenwei) Date: Mon, 16 Oct 2006 10:41:42 +0800 Subject: [Live-devel] How to demux mpeg1/2 Transport stream and so on Message-ID: <20061016023834.0DBB88719@blrcsv.china.bell-labs.com> Dear all: I found only program stream can be demuxed by live555 library. How can we demux other formats? ????????chenwei ????????chenw at blrcsv.china.bell-labs.com ??????????2006-10-16 From finlayson at live555.com Sun Oct 15 21:26:57 2006 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 15 Oct 2006 21:26:57 -0700 Subject: [Live-devel] Bug and fix report: WISstreamer.cpp - Unable to find emulated OSS device. In-Reply-To: <453124B9.1070707@asinus.org> References: <453124B9.1070707@asinus.org> Message-ID: >It seem that method - WISInput.cpp - line 208: >if (sscanf(line, "%d: [%u-%*u]: digital audio\n", &m, &n) != 2) continue; > >match line: 16: [1- 0]: mixer >instead of: 19: [1- 0]: digital audio > >I try to find reason, why there is problem in sscanf, but I have no idea >why it behave in this way. >Definition of sscanf is e.g. here: >http://www.cplusplus.com/ref/cstdio/sscanf.html > >I test it with gcc-4.0 and gcc-4.1 and appropritiate libraries, but >result was always same. > > >So I solve this problem by adding one more cotrol after 208: >if (strstr(line, "digital audio")== NULL) continue; > >After this fix wis-streame work correctly. > >Please consider appropritiate correction for wis-streamer. Sorry, but I'm not going to make a change like this solely to compensate for one person's broken compiler (or runtime library). If you're not able to fix your compiler (and/or runtime library), then you'll just have to continue patching your own copy of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jerry.johns at gmail.com Mon Oct 16 12:38:54 2006 From: jerry.johns at gmail.com (Jerry Johns) Date: Mon, 16 Oct 2006 15:38:54 -0400 Subject: [Live-devel] H264 Streaming Message-ID: <550c59e90610161238l4413919alfb68a85994f30fe3@mail.gmail.com> Hello, I'm sorta new to the livemedia streaming framework ? have been trying to get a H264 streaming solution going on linux? Trying making my own H264VideoRTPSink, but there doesn't seem to be a valid framer (at least they seem like stub functions) Any ideas how to get this going? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061016/5eba994d/attachment.html From finlayson at live555.com Mon Oct 16 14:41:06 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 16 Oct 2006 14:41:06 -0700 Subject: [Live-devel] H264 Streaming In-Reply-To: <550c59e90610161238l4413919alfb68a85994f30fe3@mail.gmail.com> References: <550c59e90610161238l4413919alfb68a85994f30fe3@mail.gmail.com> Message-ID: >Hello, > > I'm sorta new to the livemedia >streaming framework - have been trying to get a >H264 streaming solution going on linux? > >Trying making my own H264VideoRTPSink, but there >doesn't seem to be a valid framer (at least they >seem like stub functions) Yes, to use "H264VideoRTPSink", you need to define and implement your own subclass of "H264VideoStreamFramer". This subclass delivers discrete H.263 NAL units - one at a time - using your implementation of "doGetNextFrame()". (See "DeviceSource.cpp" - and the code for other 'source' classes - for hints on how to implement "doGetNextFrame()".) -- 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/20061016/58a199b3/attachment.html From vkozhuhov at gmx.net Mon Oct 16 14:52:26 2006 From: vkozhuhov at gmx.net (Victor Kozhuhov) Date: Tue, 17 Oct 2006 00:52:26 +0300 Subject: [Live-devel] RTP padding feature Message-ID: <006b01c6f16d$d93ef930$0100a8c0@sleepy> Hello, I found that RTP padding is required in some scenarios, so I added such feature into MultiFramedRTPSink. There are two new functions: void setPaddingBit(); - to set corresponding bit only (just in case), and void setFramePadding(unsigned numPaddingBytes); - to set padding bit and advance required number of bytes. I expect the last function to be called from the doSpecialFrameHandling(...), so to make it working I slightly changed MultiFramedRTPSink::afterGettingFrame(...). Here is the sample code: void SomeRTPSink::doSpecialFrameHandling(unsigned fragmentationOffset, unsigned char* frameStart, unsigned numBytesInFrame, struct timeval frameTimestamp, unsigned numRemainingBytes) { //align to some boundary unsigned neededPaddingBytes = X; //according to your need if (neededPaddingBytes && //requires alignment numRemainingBytes == 0 ) //can modify frame { setFramePadding(neededPaddingBytes); numBytesInFrame += neededPaddingBytes; //for future use within this function //... } } I also did a few more changes: - made SimpleRTPSource constuctor protected to be able to inherit it - made WAVAudioFileServerMediaSubsession methods and data members protected to be able to inherit it - slightly improved WAVAudioFileServerMediaSubsession code to make it more robust If you are interested in such changes, you may find all of them attached. I hope you find this usefull and correct. Regards, Victor Kozhuhov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061016/72b0bbe7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.zip Type: application/x-zip-compressed Size: 12035 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20061016/72b0bbe7/attachment-0001.bin From wei.francois at gmail.com Mon Oct 16 19:49:50 2006 From: wei.francois at gmail.com (=?GB2312?B?s8K2q86w?=) Date: Tue, 17 Oct 2006 10:49:50 +0800 Subject: [Live-devel] =?gb2312?b?SG93IHRvIGdldCB0aGUgdmFyaW91cyB0eXBlcyBv?= =?gb2312?b?ZiBtZWRpYSBmaWxlIHRoYXQgdGhlIKGwdGVzdE9uRGVtYW5kUlRT?= =?gb2312?b?UFNlcnZlcqGxdXNlPw==?= Message-ID: <503760b30610161949l6f8a3223i187803a170993150@mail.gmail.com> Hi alls: Does the Live555 website provide the testing video such as testv.mpg or test.ts? -- Regards, francois_wei -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061016/10705295/attachment.html From wei.francois at gmail.com Tue Oct 17 02:42:04 2006 From: wei.francois at gmail.com (=?GB2312?B?s8K2q86w?=) Date: Tue, 17 Oct 2006 17:42:04 +0800 Subject: [Live-devel] can't open rtsp with openRTSP Message-ID: <503760b30610170242u44ef7c26kcb3d66039d694685@mail.gmail.com> Hi, After I execute the testOnDemandRTSPServer, I execute openRTSP with the rtsp://172.16.11.231:8554/mp3AudioTest, but I can't listen the MP3?it shows: ./openRTSP rtsp://172.16.11.231:8554/mp3AudioTest Opened URL "rtsp://172.16.11.231:8554/mp3AudioTest", returning a SDP description: v=0 o=- 1161077339684935 1 IN IP4 172.16.11.231 s=Session streamed by "testOnDemandRTSPServer" i=mp3AudioTest t=0 0 a=tool:LIVE555 Streaming Media v2006.10.07 a=type:broadcast a=control:* a=range:npt=0-453.922 a=x-qt-text-nam:Session streamed by "testOnDemandRTSPServer" a=x-qt-text-inf:mp3AudioTest m=audio 0 RTP/AVP 14 c=IN IP4 0.0.0.0 a=control:track1 Created receiver for "audio/MPA" subsession (client ports 32798-32799) Setup "audio/MPA" subsession (client ports 32798-32799) Created output file: "audio-MPA-1" Started playing session Receiving streamed data (for up to 458.921997 seconds)... Why does it have no response? I put the test.mp3 in the directory with openRTSP. While, I can listen the MP3 through the MPlayer and can input the "rtsp://172.16.11.231:8554/mp3AudioTest" to the IE. -- Regards, francois_wei -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061017/a43759cf/attachment.html From finlayson at live555.com Tue Oct 17 07:55:53 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Oct 2006 07:55:53 -0700 Subject: [Live-devel] can't open rtsp with openRTSP In-Reply-To: <503760b30610170242u44ef7c26kcb3d66039d694685@mail.gmail.com> References: <503760b30610170242u44ef7c26kcb3d66039d694685@mail.gmail.com> Message-ID: >Created receiver for "audio/MPA" subsession (client ports 32798-32799) >Setup "audio/MPA" subsession (client ports 32798-32799) >Created output file: "audio-MPA-1" >Started playing session >Receiving streamed data (for up to 458.921997 seconds)... > > Why does it have no response? Note that "openRTSP" is a RTSP client, but it is not a media player. It receives data, but does not do any audio or video decoding on the received data. If you look at the received file "audio-MPA-1", you'll see that it contains MP3 data. You can rename this file - e.g., to "output.mp3" - and then play it using a media player. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jerry.johns at nuvation.com Tue Oct 17 08:26:51 2006 From: jerry.johns at nuvation.com (Jerry Johns) Date: Tue, 17 Oct 2006 08:26:51 -0700 Subject: [Live-devel] H264 Streaming Message-ID: Hello, I'm sorta new to the livemedia streaming framework - have been trying to get a H264 streaming solution going on linux... The H264VideoRTPSink looks likes it fully coded , but there doesn't seem to be a valid framer (at least they seem like stub functions) I'm guessing I'll have to write a framer to get this going - has anyone done this already? / has this been added in beta versions? Any help would be much appreciated :-) Thanks Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061017/7aaa530f/attachment.html From jmbaio at gmail.com Tue Oct 17 08:39:15 2006 From: jmbaio at gmail.com (Juan Manuel Lopez Baio) Date: Tue, 17 Oct 2006 12:39:15 -0300 Subject: [Live-devel] input frame data too large for buffer Message-ID: Hello. I was doing some tests with videos encoded with mencoder from air tv, of very poor quality (lots of garbage) and when trying to stream them got the following error: MultiFramedRTPSink::afterGettingFrame1(): The input frame data was too large for our buffer size (60753). 34086 bytes of trailing data was dropped! Correct this by increasing "OutPacketBuffer::maxSize" to at least 94839, *before* creating this 'RTPSink'. (Current value is 60000.) StreamParser internal error (149997+ 4 > 150000) I looked in LiveMedia code and found a couple of places where OutPacketBuffer::maxSize is assigned; but, is there a way to modify this without touching the code, I mean, is it configurable? Thanks a lot, Juan From finlayson at live555.com Tue Oct 17 08:56:20 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Oct 2006 08:56:20 -0700 Subject: [Live-devel] input frame data too large for buffer In-Reply-To: References: Message-ID: >I looked in LiveMedia code and found a couple of places where >OutPacketBuffer::maxSize is assigned; but, is there a way to modify >this without touching the code, I mean, is it configurable? Yes, but you do this in *your* code - not by changing the library code. I.e., add OutPacketBuffer::maxSize = 100000; to your code, before you create any "RTPSink"s. However, if your data really iw malformed, then there's no guarantee that this will solve your problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Oct 17 08:59:27 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Oct 2006 08:59:27 -0700 Subject: [Live-devel] H264 Streaming In-Reply-To: References: Message-ID: Note the email that I sent (to the list) about this yesterday. Because H.264 video streams usually don't come from a file (and because doesn't seem to be a single, well-defined way to package H.264 video data in byte-stream form anyway), each developer who wants to stream his H.264 video source will need to write a "H264VideoStreamFramer" subclass that encapsulates the H.264 video source (thereby delivering the H.264 video data in discrete NAL units). -- 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/20061017/5eb824c2/attachment.html From jmbaio at gmail.com Tue Oct 17 11:03:14 2006 From: jmbaio at gmail.com (Juan Manuel Lopez Baio) Date: Tue, 17 Oct 2006 15:03:14 -0300 Subject: [Live-devel] input frame data too large for buffer In-Reply-To: References: Message-ID: On 10/17/06, Ross Finlayson wrote: > >I looked in LiveMedia code and found a couple of places where > >OutPacketBuffer::maxSize is assigned; but, is there a way to modify > >this without touching the code, I mean, is it configurable? > > Yes, but you do this in *your* code - not by changing the library code. > > I.e., add > OutPacketBuffer::maxSize = 100000; > to your code, before you create any "RTPSink"s. Ok, but how could I do this, given that I'm using RTSPServer and ServerMediaSession and SubSession, and don't know from my app any lower abstraction from LiveMedia? > However, if your data really iw malformed, then there's no guarantee > that this will solve your problem. > I souldn't think that it's malformed... there's just a lot of garbage from the source as to the real data being encoded, but mencoder should be working correctly... I thought maybe because of some unusual sizes caused by this I was getting that error... anyway, my app crashes thrugh LiveMedia when this ocurrs. From finlayson at live555.com Tue Oct 17 11:29:01 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 17 Oct 2006 11:29:01 -0700 Subject: [Live-devel] input frame data too large for buffer In-Reply-To: References: Message-ID: >On 10/17/06, Ross Finlayson wrote: >> >I looked in LiveMedia code and found a couple of places where >> >OutPacketBuffer::maxSize is assigned; but, is there a way to modify >> >this without touching the code, I mean, is it configurable? >> >> Yes, but you do this in *your* code - not by changing the library code. >> >> I.e., add >> OutPacketBuffer::maxSize = 100000; >> to your code, before you create any "RTPSink"s. > >Ok, but how could I do this, given that I'm using RTSPServer and >ServerMediaSession and SubSession, and don't know from my app any >lower abstraction from LiveMedia? OK, add that code before you create your "RTSPServer" object. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From freegnu at 163.com Tue Oct 17 23:31:05 2006 From: freegnu at 163.com (freegnu) Date: Wed, 18 Oct 2006 14:31:05 +0800 Subject: [Live-devel] cant anyone describe the process of a media program stream server? References: <550c59e90610161238l4413919alfb68a85994f30fe3@mail.gmail.com> Message-ID: <003f01c6f27e$fd79d920$6401a8c0@zwenqiang> Re: [Live-devel] H264 Streaminghi all, im a newbie to media programming, and i use livemedia now. but i find there is little reference, so i only to read the code to know the process of a media program stream server, but it is difficult and expend a lot of time. so is anyone describe the process or tell me the exact reference (the mail lists are really disrupt and it will wast me losts of time to find the correlative content) thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061017/65c0e0c9/attachment-0001.html From finlayson at live555.com Wed Oct 18 01:04:57 2006 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Oct 2006 01:04:57 -0700 Subject: [Live-devel] RTP padding feature In-Reply-To: <006b01c6f16d$d93ef930$0100a8c0@sleepy> References: <006b01c6f16d$d93ef930$0100a8c0@sleepy> Message-ID: >I found that RTP padding is required in some scenarios, so I added >such feature into MultiFramedRTPSink. Thanks for the suggestion. This has now been added to the latest release of the software (2006.10.18a). >There are two new functions: >void setPaddingBit(); - to set corresponding bit only (just in case) I decided not to make this a public member function, because the RTP padding bit should never be set without the padding bytes actually being present. -- 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/20061018/94550f62/attachment.html From freegnu at 163.com Wed Oct 18 01:48:11 2006 From: freegnu at 163.com (freegnu) Date: Wed, 18 Oct 2006 16:48:11 +0800 Subject: [Live-devel] cant run testMPEG1or2AudioVideoStreamer References: <006b01c6f16d$d93ef930$0100a8c0@sleepy> Message-ID: <001901c6f292$24b645b0$6401a8c0@zwenqiang> Re: [Live-devel] RTP padding featurehi all, when i run estMPEG1or2AudioVideoStreamer, it will display Beginning streaming... ...done reading from file Beginning streaming... ...done reading from file ....... ....... it doesnt seem to run well, and the vlc (rtsp://ip:7777/mpeg1or2AudioVideo) cant to play it -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061018/be2e1e05/attachment.html From riwanda at yahoo.com Wed Oct 18 02:34:26 2006 From: riwanda at yahoo.com (Gunar Riwanda) Date: Wed, 18 Oct 2006 02:34:26 -0700 (PDT) Subject: [Live-devel] cant run testMPEG1or2AudioVideoStreamer Message-ID: <20061018093426.31145.qmail@web54614.mail.yahoo.com> i presume you run it without any change.So, i think the Streamer works really well. so, what you should do is maybe uncomment the line "//#define IMPLEMENT_RTSP_SERVER 1" and then try to run it again. you can see a line that says "Play this stream using the URL rtsp:// yoururladdress" try open that URL address with VLC again.... There's actually another way by opening RTP multicast 239.255.42.42. But i'm not sure with the port address, since i always test it only with video stream and never audio video. but correct me if i'm wrong. I've never run mpeg1or2audiovideostreamer. ----- Original Message ---- From: freegnu To: LIVE555 Streaming Media - development & use Sent: Wednesday, October 18, 2006 10:48:11 AM Subject: [Live-devel] cant run testMPEG1or2AudioVideoStreamer Re: [Live-devel] RTP padding feature BLOCKQUOTE { PADDING-BOTTOM:0px;PADDING-TOP:0px;} DL { PADDING-BOTTOM:0px;PADDING-TOP:0px;} UL { PADDING-BOTTOM:0px;PADDING-TOP:0px;} OL { PADDING-BOTTOM:0px;PADDING-TOP:0px;} LI { PADDING-BOTTOM:0px;PADDING-TOP:0px;} hi all, when i run estMPEG1or2AudioVideoStreamer, it will display Beginning streaming... ...done reading from file Beginning streaming... ...done reading from file ....... ....... it doesnt seem to run well, and the vlc (rtsp://ip:7777/mpeg1or2AudioVideo) cant to play it _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061018/c27c6ce4/attachment.html From freegnu at 163.com Wed Oct 18 03:01:20 2006 From: freegnu at 163.com (freegnu) Date: Wed, 18 Oct 2006 18:01:20 +0800 Subject: [Live-devel] cant run testMPEG1or2AudioVideoStreamer References: <20061018093426.31145.qmail@web54614.mail.yahoo.com> Message-ID: <004801c6f29c$5cd59900$6401a8c0@zwenqiang> Re: [Live-devel] RTP padding featureit is ok now thanks ----- Original Message ----- From: Gunar Riwanda To: LIVE555 Streaming Media - development & use Sent: Wednesday, October 18, 2006 5:34 PM Subject: Re: [Live-devel] cant run testMPEG1or2AudioVideoStreamer i presume you run it without any change.So, i think the Streamer works really well. so, what you should do is maybe uncomment the line "//#define IMPLEMENT_RTSP_SERVER 1" and then try to run it again. you can see a line that says "Play this stream using the URL rtsp:// yoururladdress" try open that URL address with VLC again.... There's actually another way by opening RTP multicast 239.255.42.42. But i'm not sure with the port address, since i always test it only with video stream and never audio video. but correct me if i'm wrong. I've never run mpeg1or2audiovideostreamer. ----- Original Message ---- From: freegnu To: LIVE555 Streaming Media - development & use Sent: Wednesday, October 18, 2006 10:48:11 AM Subject: [Live-devel] cant run testMPEG1or2AudioVideoStreamer hi all, when i run estMPEG1or2AudioVideoStreamer, it will display Beginning streaming... ...done reading from file Beginning streaming... ...done reading from file ....... ....... it doesnt seem to run well, and the vlc (rtsp://ip:7777/mpeg1or2AudioVideo) cant to play it _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ------------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061018/c4e7d583/attachment.html From jmbaio at gmail.com Wed Oct 18 06:25:30 2006 From: jmbaio at gmail.com (Juan Manuel Lopez Baio) Date: Wed, 18 Oct 2006 10:25:30 -0300 Subject: [Live-devel] input frame data too large for buffer In-Reply-To: References: Message-ID: On 10/17/06, Ross Finlayson wrote: > >On 10/17/06, Ross Finlayson wrote: > >> >I looked in LiveMedia code and found a couple of places where > >> >OutPacketBuffer::maxSize is assigned; but, is there a way to modify > >> >this without touching the code, I mean, is it configurable? > >> > >> Yes, but you do this in *your* code - not by changing the library code. > >> > >> I.e., add > >> OutPacketBuffer::maxSize = 100000; > >> to your code, before you create any "RTPSink"s. > > > >Ok, but how could I do this, given that I'm using RTSPServer and > >ServerMediaSession and SubSession, and don't know from my app any > >lower abstraction from LiveMedia? > > OK, add that code before you create your "RTSPServer" object. > -- Ok, that worked, but I had overviewed the last error which of course now I'm still getting "StreamParser internal error (149997+ 4 > 150000)"; I looked in the code and found this comment: // If this happens, it means that we have too much saved parser state. // To fix this, increase BANK_SIZE as appropriate. Guess I'm running out of buffer, only now it's a #define and not a static attribute, so I guess there's no clean way to fix it, right? From jerry.johns at nuvation.com Wed Oct 18 10:20:09 2006 From: jerry.johns at nuvation.com (Jerry Johns) Date: Wed, 18 Oct 2006 10:20:09 -0700 Subject: [Live-devel] printf Message-ID: Hello, This might be a weird question, but to help me understand the class traversing and program flow, is there a way I can pipe fprintf debug statements to a file easy and cleanly? (FILE *debugFile) - where would I declare this so I can get universal access to this variable? Or is there a way to pipe fprintf to a file without declaring a FILE* struct thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061018/5bb798f3/attachment-0001.html From finlayson at live555.com Wed Oct 18 10:31:18 2006 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Oct 2006 10:31:18 -0700 Subject: [Live-devel] printf In-Reply-To: References: Message-ID: >Hello, > This might be a weird question, but to help me understand >the class traversing and program flow, is there a way I can pipe >fprintf debug statements to a file easy and cleanly? (FILE >*debugFile) - where would I declare this so I can get universal >access to this variable? Or is there a way to pipe fprintf to a file >without declaring a FILE* struct Of course - just output to stdout, or stderr, and then redirect this to a file using the command shell. (I assume that you're familiar with Unix-style I/O redirection; it works in the Windoze command shell also.) -- 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/20061018/3c2000e0/attachment.html From balr0g at poczta.onet.pl Wed Oct 18 14:23:12 2006 From: balr0g at poczta.onet.pl (balr0g at poczta.onet.pl) Date: Wed, 18 Oct 2006 23:23:12 +0200 Subject: [Live-devel] Problem with socket buffer or not ? Message-ID: <20061018212153Z4356782-7316+959@kps4.test.onet.pl> Hello! I'm trying to create simple rtsp client uisng LIVE555. I have some problem with buffer socket, witch seems to be comsumed by somethig. I receive frames (consisting of hundrets of packets, because of uncompressed video), using getNextFrame function. I looks like that: while(1) { event = 0; readSource->getNextFrame( buffer, buffer_size, StreamRead, state, StreamClose, state); env->taskScheduler().doEventLoop(&(event)); } ... static void StreamRead(void *data, unsigned int i_size, unsigned int i_truncated_bytes, struct timeval pts, unsigned int duration) { env << i_size; event = 0xff; } And after few first recived frames, i'm receiving only one packet. Output looks like that: 144000 144000 144000 300 300 .. and so on The sum of 3 first packet is less than socket buffer, witch is set using increaseReceiveBufferTo function. Setting high value can help only for few minutes. Mayby socket is collecting packets? From finlayson at live555.com Wed Oct 18 15:29:24 2006 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 18 Oct 2006 15:29:24 -0700 Subject: [Live-devel] Problem with socket buffer or not ? In-Reply-To: <20061018212153Z4356782-7316+959@kps4.test.onet.pl> References: <20061018212153Z4356782-7316+959@kps4.test.onet.pl> Message-ID: >while(1) >{ > event = 0; > readSource->getNextFrame( buffer, buffer_size, StreamRead, >state, StreamClose, state); > env->taskScheduler().doEventLoop(&(event)); >} >... >static void StreamRead(void *data, unsigned int i_size, > unsigned int i_truncated_bytes, struct timeval pts, > unsigned int duration) >{ > env << i_size; > event = 0xff; >} This code is very strange, and might be the cause of your problems (although I'm not certain of this). Note that you don't need to call "doEventLoop()" within a loop, because it already *is* a loop. Instead, restructure your code as: readSource->getNextFrame( buffer, buffer_size, StreamRead, state, StreamClose, state); doEventLoop(); ... static void StreamRead(void *data, unsigned int i_size, unsigned int i_truncated_bytes, struct timeval pts, unsigned int duration) { env << i_size; readSource->getNextFrame( buffer, buffer_size, StreamRead, state, StreamClose, state); } -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From darnold at futurec.net Wed Oct 18 16:07:38 2006 From: darnold at futurec.net (David Arnold) Date: Wed, 18 Oct 2006 16:07:38 -0700 Subject: [Live-devel] Resolution of scheduleDelayedTask() In-Reply-To: Message-ID: On Windows XP, what kind of resolution for executing scheduled tasks can I expect? I have a audio FramedSource class that sets fDurationInMicroseconds to 24000 and I'm seeing actual execution intervals of doGetNextFrame() from 400 to has high as 80000 and more. I am using the Windows API QueryPerformanceCounter() in doGetNextFrame() to calculate the intervals. I was expecting intervals very close to the value I set in fDurationInMicroseconds. I'm tracking down some timing problems I'm experiencing and this could be part of the problem. Thank you, Dave Arnold Future Concepts, La Verne CA The information contained in this electronic mail transmission is intended only for the use of the individual or entity named above and is privileged and confidential. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Any dissemination, distribution or copying of this communication other than to the person or entity named above is strictly prohibited. If you have received this communication in error, please immediately delete it from your system. From balr0g at poczta.onet.pl Thu Oct 19 03:00:04 2006 From: balr0g at poczta.onet.pl (balr0g at poczta.onet.pl) Date: Thu, 19 Oct 2006 12:00:04 +0200 Subject: [Live-devel] Problem with socket buffer or not ? In-Reply-To: Message-ID: <20061019095604Z4895408-15122+1944@kps5.test.onet.pl> An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061019/c021a046/attachment.html -------------- next part -------------- I've restructured code, as you said, but the problem hasn't disapeared. :(. I'm still losing frames. Mayby you have some other idea? ? >>while(1) >>{ >> event = 0; >> readSource->getNextFrame( buffer, buffer_size, StreamRead, >>state, StreamClose, state); >> env->taskScheduler().doEventLoop(&(event)); >>} >>... >>static void StreamRead(void *data, unsigned int i_size, >> unsigned int i_truncated_bytes, struct timeval pts, >> unsigned int duration) >>{ >> env << i_size; >> event = 0xff; >>} > >This code is very strange, and might be the cause of your problems >(although I'm not certain of this). Note that you don't need to call >"doEventLoop()" within a loop, because it already *is* a loop. >Instead, restructure your code as: > >readSource->getNextFrame( buffer, buffer_size, StreamRead, state, >StreamClose, state); >doEventLoop(); >... >static void StreamRead(void *data, unsigned int i_size, > unsigned int i_truncated_bytes, struct timeval pts, > unsigned int duration) >{ > env << i_size; > readSource->getNextFrame( buffer, buffer_size, StreamRead, state, >StreamClose, state); >} >-- > >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ >_______________________________________________ From balr0g at poczta.onet.pl Thu Oct 19 04:30:43 2006 From: balr0g at poczta.onet.pl (balr0g at poczta.onet.pl) Date: Thu, 19 Oct 2006 13:30:43 +0200 Subject: [Live-devel] Problem with socket buffer or not ? In-Reply-To: <20061019095604Z4895408-15122+1944@kps5.test.onet.pl> Message-ID: <20061019113045Z1231066-16814+2271@kps9.test.onet.pl> An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061019/51e76409/attachment.html -------------- next part -------------- I found that a socket buffer is filling up with waiting packet, waiting to be received by user. I play some video, and before buffer filled up, the video was playing very slow. After buffer was filled up, video suddenly speed up, droping some frames all the time. But using VLC media player every thing is OK. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061019/51e76409/attachment-0001.html From finlayson at live555.com Thu Oct 19 05:54:49 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Oct 2006 05:54:49 -0700 Subject: [Live-devel] Problem with socket buffer or not ? In-Reply-To: <20061019113045Z1231066-16814+2271@kps9.test.onet.pl> References: <20061019113045Z1231066-16814+2271@kps9.test.onet.pl> Message-ID: >I found that a socket buffer is filling up with waiting packet, >waiting to be received by user. I play some video, and before buffer >filled up, the video was playing very slow. After buffer was filled >up, video suddenly speed up, droping some frames all the time. But >using VLC media player every thing is OK. > > >I've restructured code, as you said, but the problem hasn't >disapeared. :(. I'm still losing frames. Mayby you have some other >idea? The only thing I can suggest right now is that you increase the OS's socket reception buffer - using "increaseReceiverBufferTo()" - to the same value that's currently used in VLC: 2000000. (You said before that increasing this buffer helped someehat; perhaps you didn't increase it enough?) Alternatively, just use VLC, because it is already working OK for you :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From paul_li20 at yahoo.com.cn Thu Oct 19 13:39:18 2006 From: paul_li20 at yahoo.com.cn (Li bz) Date: Fri, 20 Oct 2006 04:39:18 +0800 (CST) Subject: [Live-devel] timestamps of B frame in mpeg-4 video elementary streaming Message-ID: <20061019203918.27500.qmail@web15111.mail.cnb.yahoo.com> Hi Ross, I just want to confirm that during mpeg-4 video elementary streaming, if there is B frame in the video stream, the timestamps for those packets with data of B frame should be the same as previous packets of P or I frame, Is that right? Since I look into the source of MPEG4VideoStreamFramer.cpp, you don't do any processing about timestamps when the frame is B. Then at the decoder side, the decoder receive those packets with same timestamps, however, those packets maybe belong to different frame and does it know present them at different time? Thank you for clarification. Paul ___________________________________________________________ ??????-3.5G???20M?? http://cn.mail.yahoo.com/ From freegnu at 163.com Thu Oct 19 20:54:30 2006 From: freegnu at 163.com (freegnu) Date: Fri, 20 Oct 2006 11:54:30 +0800 Subject: [Live-devel] void RTPInterface::sendPacket References: <20061019203918.27500.qmail@web15111.mail.cnb.yahoo.com> Message-ID: <005701c6f3fc$bb318250$6401a8c0@zwenqiang> hi, all, im reading the code, and i find int the function -- void RTPInterface::sendPacket(unsigned char* packet, unsigned packetSize) -- // Normal case: Send as a UDP packet: fGS->output(envir(), fGS->ttl(), packet, packetSize); // Also, send over each of our TCP sockets: for (tcpStreamRecord* streams = fTCPStreams; streams != NULL; streams = streams->fNext) { sendRTPOverTCP(packet, packetSize, streams->fStreamSocketNum, streams->fStreamChannelId); } why it have to send a UDP packet and over TCP socket? but it seems the RTCP uses UDP also and its port is the RTP port number + 1; From finlayson at live555.com Thu Oct 19 23:29:14 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 19 Oct 2006 23:29:14 -0700 Subject: [Live-devel] void RTPInterface::sendPacket In-Reply-To: <005701c6f3fc$bb318250$6401a8c0@zwenqiang> References: <20061019203918.27500.qmail@web15111.mail.cnb.yahoo.com> <005701c6f3fc$bb318250$6401a8c0@zwenqiang> Message-ID: >why it have to send a UDP packet and over TCP socket? For most streams, RTP and RTCP packets are sent via UDP only. However, for some RTSP streams, RTP and RTCP are sent via TCP instead - if the RTSP client has requested this. In one special case - a RTSP server that streams to multiple clients from the same input source ("reuseFirstSource==True") - it is possible for a single "RTPInterface" to stream via both UDP and TCP (to different clients). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From hanfeng1124 at gmail.com Sat Oct 21 02:09:32 2006 From: hanfeng1124 at gmail.com (=?GB2312?B?uqvBorGm?=) Date: Sat, 21 Oct 2006 17:09:32 +0800 Subject: [Live-devel] I'm so glad to be here. Message-ID: I'm so glad to be here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061021/ca04124a/attachment.html From jerry.johns at gmail.com Sat Oct 21 20:13:11 2006 From: jerry.johns at gmail.com (Jerry Johns) Date: Sat, 21 Oct 2006 23:13:11 -0400 Subject: [Live-devel] Linux / Input buffers Message-ID: <550c59e90610212013o73970193gbdd7c10a6d3af477@mail.gmail.com> Hello, I'm trying to integrate the livemedia framework into a project of mine, compiling it for linux; can i create a pthread and run the framework on that? how would that function with respect to the doEvent loop for the task scheduler? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061021/b4218505/attachment.html From jerry.johns at gmail.com Sun Oct 22 09:02:36 2006 From: jerry.johns at gmail.com (Jerry Johns) Date: Sun, 22 Oct 2006 12:02:36 -0400 Subject: [Live-devel] H264 Framer Message-ID: <550c59e90610220902x47881303t85722b1a5206b347@mail.gmail.com> As a follow up to my previous post, i'm having some dilemmas here: As a basis to create my H264StreamFramer class, i'm looking at several other code samples to figure out how to do this: i note that the existing H264VideoStreamFramer class inherits FramedFilter i'm looking at AC3AudioStreamFramer, and AMRAudioFileSource as my two examples now the AC3 one defines a StreamParser, and uses that as its way to access the file source using test4bytes, etc while AMR does freads on its own StreamFramer class my idea was to do it like the AMR for now, (stream H264 from a file, process it, copy it to fTo, and call afterGetting) but later on, i have to integrate this with my linux application (multi threaded), which will encode video to h264 and pass it to this in a shared buffer will the filesource approach hamper me later on? or should i use streamparser (forgive me if these questions sound really lame...i'm just starting up here...) Jerry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061022/24841b19/attachment.html From jmbaio at gmail.com Mon Oct 23 05:16:26 2006 From: jmbaio at gmail.com (Juan Manuel Lopez Baio) Date: Mon, 23 Oct 2006 09:16:26 -0300 Subject: [Live-devel] Linux / Input buffers In-Reply-To: <550c59e90610212013o73970193gbdd7c10a6d3af477@mail.gmail.com> References: <550c59e90610212013o73970193gbdd7c10a6d3af477@mail.gmail.com> Message-ID: On 10/22/06, Jerry Johns wrote: > Hello, > I'm trying to integrate the livemedia framework into a project of > mine, compiling it for linux; can i create a pthread and run the framework > on that? how would that function with respect to the doEvent loop for the > task scheduler? According to the FAQ, LM is not thread-safe, so all api-calls should be made from the same thread. Be that as it may, you can integrate it with a threaded framework applying the correct sync mechanisms and sharing data structures to notify state-changes. What I did was create a task to check this data structures and give it to livemedia to run in the doEventLoop(), which I called from its own thread. It appears to work fine. From p4olo_prete at yahoo.it Mon Oct 23 05:34:31 2006 From: p4olo_prete at yahoo.it (Paolo Prete) Date: Mon, 23 Oct 2006 14:34:31 +0200 (CEST) Subject: [Live-devel] Making an AVI file from MPEG4 frames Message-ID: <20061023123431.11803.qmail@web28002.mail.ukl.yahoo.com> Hi, I would like to develop a MPEG4 avi recorder. I have a series of MPEG4 frames obtained through a socket from an IP-CAM. Actually, following the code of OpenRTSP, I can create my recorder only on a RTP stream. Is there a trivial way to "link" the AVIFileSink object to the frames, instead of the RTSPClient? If so, are there any examples or tips which I can follow, or should I implement my "own" AVIFileSink class and its startPlaying(), continuePlaying() etc. functions? Thanks in advance Paolo __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From p4olo_prete at yahoo.it Mon Oct 23 05:55:48 2006 From: p4olo_prete at yahoo.it (Paolo Prete) Date: Mon, 23 Oct 2006 14:55:48 +0200 (CEST) Subject: [Live-devel] Making an AVI file from MPEG4 frames (no more need for an answer) Message-ID: <20061023125548.35856.qmail@web28009.mail.ukl.yahoo.com> I apologize about my unuseful previous question: "Making an AVI file from MPEG4 frames" Searching in the archive, I've just found the path for the solution ([Live-devel] FW: Convert H263 framed stream to.avi), so there's no need for an answer Regards, Paolo Prete __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From bidibulle at operamail.com Mon Oct 23 07:24:31 2006 From: bidibulle at operamail.com (David BERTRAND) Date: Mon, 23 Oct 2006 15:24:31 +0100 Subject: [Live-devel] Change Request about rtp timestamping when doing PAUSE/PLAY Message-ID: <20061023142432.38CDB43D75@ws5-1.us4.outblaze.com> Hi Ross, As you maybe know, there is some ambiguity in RFC2326 about rtp timestamping when a sequence of PAUSE/PLAY messages occurs. I noted that live555 implementation for this consists of setting in the rtp-info header a rtptime value corresponding to the last RTP timestamp sent for this track (see testOnDemandRTSPServer for example). This probably works fine for some players but I personnaly made several tests with RealPlayer 10 and VLC 0.8.5 and none of those players are able to resynchronize the stream after the resume. I tried to find out what would be the best behaviour of the library regarding this issue and it seems that a solution has been adopted by both draft RFC2326bis (draft-ietf-mmusic-rfc2326bis-13.txt) and 3GPP PSS specifications. I must admit that I can't say that liveMedia's implemntation is buggy but as it is a very difficult issue that has been finally fixed by competent authorities, would you consider this as a valid Change Request ? I personnaly would appreciate a lot :-) Thanks in advance for your feedback on this, David PS : Please find here below the section of rfc2326bis talking about this : B.2.4 Handling RTP Timestamps after PAUSE During a PAUSE / PLAY interaction in an RTSP session, the duration of time for which the RTP transmission was halted MUST be reflected in the RTP timestamp of each RTP stream. The duration can be calculated for each RTP stream as the time elapsed from when the last RTP packet was sent before the PAUSE request was received and when the first RTP packet was sent after the subsequent PLAY request was received. The duration includes all latency incurred and processing time required to complete the request. The RTP RFC [18] states that: The RTP timestamp for each unit[packet] would be related to the wallclock time at which the unit becomes current on the virtual presentation timeline. In order to satisfy the requirements of [18], the RTP timestamp space needs to increase continuously with real time. While this is not optimal for stored media, it is required for RTP and RTCP to function as intended. Using a continuous RTP timestamp space allows the same timestamp model for both stored and live media and allows better opportunity to integrate both types of media under a single control. As an example, assume a clock frequency of 8000 Hz, a packetization interval of 100 ms and an initial sequence number and timestamp of zero. C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 CSeq: 4 Session: abcdefg Range: npt=10-15; S->C: RTSP/2.0 200 OK CSeq: 4 Session: abcdefg Range: npt=10-15 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" ssrc=0D12F123:seq=0;rtptime=0 The ensuing RTP data stream is depicted below: S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s The client then sends a PAUSE request: C->S: PAUSE rtsp://xyz/fizzle RTSP/2.0 CSeq: 5 Session: abdcdefg S->C: RTSP/2.0 200 OK CSeq: 5 Session: abcdefg Range: npt=10.4-15 20 seconds elapse and then the client sends a PLAY request. In addition the server requires 15 ms to process the request: C->S: PLAY rtsp://xyz/fizzle RTSP/2.0 CSeq: 6 Session: abcdefg S->C: RTSP/2.0 200 OK CSeq: 6 Session: abcdefg Range: npt=10.4-15 RTP-Info: url="rtsp://xyz/fizzle/audiotrack" ssrc=0D12F123:seq=4;rtptime=164400 The ensuing RTP data stream is depicted below: S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s First, NPT 10 through 10.3 is played, then a PAUSE is received by the server. After 20 seconds a PLAY is received by the server which take 15ms to process. The duration of time for which the session was paused is reflected in the RTP timestamp of the RTP packets sent after this PLAY request. A client can use the RTSP range header and RTP-Info header to map NPT time of a presentation with the RTP timestamp. Note: In RFC 2326 [28], this matter was not clearly defined and was misunderstood commonly. However for RTSP 2.0 it is expected that this will be handled correctly and no exception handling will be required. -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze From finlayson at live555.com Mon Oct 23 14:12:06 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Oct 2006 14:12:06 -0700 Subject: [Live-devel] Change Request about rtp timestamping when doing PAUSE/PLAY In-Reply-To: <20061023142432.38CDB43D75@ws5-1.us4.outblaze.com> References: <20061023142432.38CDB43D75@ws5-1.us4.outblaze.com> Message-ID: >I noted that live555 implementation for this consists of setting in >the rtp-info header a rtptime value corresponding to the last RTP >timestamp sent for this track I believe this is correct, because the RTP timestamp *does* increase appropriately after a PAUSE/PLAY (see below). >This probably works fine for some players but I personnaly made >several tests with RealPlayer 10 and VLC 0.8.5 and none of those >players are able to resynchronize the stream after the resume. Note that VLC currently doesn't use the "RTPInfo" header at all. However, it should synchronize normally (via RTCP "Sender Report" packets) after playing resumes. I don't know why this would not be working for you. (As for RealPlayer, I can't comment on it, because it is closed source and therefore I have no way of knowing how it works.) >B.2.4 Handling RTP Timestamps after PAUSE > > During a PAUSE / PLAY interaction in an RTSP session, the duration of > time for which the RTP transmission was halted MUST be reflected in > the RTP timestamp of each RTP stream. The duration can be calculated > for each RTP stream as the time elapsed from when the last RTP packet > was sent before the PAUSE request was received and when the first RTP > packet was sent after the subsequent PLAY request was received. The > duration includes all latency incurred and processing time required > to complete the request. > > > The RTP RFC [18] states that: The RTP timestamp for each > unit[packet] would be related to the wallclock time at > which the unit becomes current on the virtual presentation > timeline. > > In order to satisfy the requirements of [18], the RTP timestamp space > needs to increase continuously with real time. I believe our implementation does this. The presentation time (from which the RTP timestamp is derived) of each input stream is reset to the 'wall clock' time (using "gettimeofday()") after each PAUSE/PLAY. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From xcsmith at rockwellcollins.com Mon Oct 23 14:42:00 2006 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 23 Oct 2006 16:42:00 -0500 Subject: [Live-devel] Demultiplex TS Message-ID: I am trying to demultiplex a TS into its ES sources. I have opened the TS file as ByteStreamFileSource and applied MPEG2TransportStreamFramer. So next I want to use MPEG1or2Demux to demultiplex this stream. But MPEG1or2Demux does not have a TS parser, so this cannot work, right? I should create a TransportStreamParser from StreamParser and add this friend to MPEG1or2Demux? After I have TransportStreamParser in MPEG1or2Demux, then I would create MPEG1or2DemuxedElementaryStream by using MPEG1or2Demux::newRawPESStream(), and then pass to my File Sink? Thanks! ~Medra From finlayson at live555.com Mon Oct 23 15:55:02 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 23 Oct 2006 15:55:02 -0700 Subject: [Live-devel] Demultiplex TS In-Reply-To: References: Message-ID: >I am trying to demultiplex a TS into its ES sources. I have opened the TS >file as ByteStreamFileSource and applied MPEG2TransportStreamFramer. So >next I want to use MPEG1or2Demux to demultiplex this stream. No, you can't do this, because "MPEG1or2Demux" is only for demultiplexing MPEG *Program* Streams. > But >MPEG1or2Demux does not have a TS parser, so this cannot work, right? I >should create a TransportStreamParser from StreamParser and add this friend >to MPEG1or2Demux? No, you would need to write new classes, completely separate from "MPEG1or2Demux" and "MPEG1or2DemuxedElementaryStream". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From freegnu at 163.com Mon Oct 23 18:29:47 2006 From: freegnu at 163.com (freegnu) Date: Tue, 24 Oct 2006 09:29:47 +0800 Subject: [Live-devel] how to implement env->taskScheduler().doEventLoop() by while(!signal) References: <20061023142432.38CDB43D75@ws5-1.us4.outblaze.com> Message-ID: <000d01c6f70b$e5559550$6401a8c0@zwenqiang> hi all, i want to read the PS from a circular buffer(which get from encode), and the transfers it by testMPEG4VideoStream, so i want to explant testMPEG4VideoStream but the testMPEG4VideoStream it get the media PS from a file , so i want to use memcpy(fTo, p_buf, fMaxSize) to copy the PS tho fTo buffer, but the env->taskScheduler().doEventLoop(); to do the task for loop, but memcpy(fTo, p_buf, fMaxSize) is also in a while circular, it look like the this: while(!signal) { memcpy(fTo, p_buf, fMaxSize); } but i dont how to send the packet of fTo to client use RTP and RTCP, so i only to imitate testMPEG4VideoStream.cpp, but i dont know how to use while() instead of env->taskScheduler().doEventLoop() From bidibulle at operamail.com Tue Oct 24 03:14:27 2006 From: bidibulle at operamail.com (David Betrand) Date: Tue, 24 Oct 2006 11:14:27 +0100 Subject: [Live-devel] Change Request about rtp timestamping when doing PAUSE/PLAY Message-ID: <20061024101427.DB2CE43D4C@ws5-1.us4.outblaze.com> Ross, > > I noted that live555 implementation for this consists of > setting > in the rtp-info header a rtptime value corresponding to > the last > RTP timestamp sent for this track > > I believe this is correct, because the RTP timestamp *does* increase > appropriately after a PAUSE/PLAY (see below). The problem here is not the timestamps present in the RTP packets, they are correct. It is the "rtptime" value present in the PLAY Response which is incorrect because it equals to the last rtp timestamp sent BEFORE the Pause. (see usage of rtpSink()->currentTimestamp() in OnDemandServerMediaSubsession::startStream()) Following RFC2326bis, the definition of "rtptime" is the following : rtptime: SHALL indicate the RTP timestamp value corresponding to the start time value in the Range response header, or if not explicitly given the implied start point. The client uses this value to calculate the mapping of RTP time to NPT or other media timescale. This parameter SHOULD be present to ensure inter-media synchronization is achieved. There exist no requirement that any received RTP packet will have the same RTP timestamp value as the one in the parameter used to establish synchronization. You cannot use an old value for this rtptime otherwise players will think the packets they receive are in the future. That's exactly what VLC think (see VLC output message in attachment, starting from the time I resumed the stream). In the example sent in my previous email (extracted from the RFC2326bis) you can see that this rtptime value is coherent with the start time value in the Range response header (20 seconds elapsed between the PAUSE and the PLAY, so the rtptime jumps from 2400 to 164400). To summarize, I would say that -at least in this case- you cannot use fCurrentTimestamp as rtptime value. David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze -------------- next part -------------- main debug: control type=1 main debug: control type=1 mpeg_audio debug: emulated startcode (no startcode on following frame) main warning: computed PTS is out of range (7649957), clearing out main warning: timing screwed, stopping resampling main warning: PTS is out of range (7687639), dropping buffer main warning: output PTS is out of range (7675728), clearing out main warning: vout synchro warning: pts != current_date (-8861183) main warning: late picture skipped (7769560) main warning: backward_pts != current_pts (8827815) main warning: input PTS is out of range (8376350), trashing main warning: received buffer in the future (9314190) main warning: received buffer in the future (9340122) main warning: received buffer in the future (9364909) main warning: received buffer in the future (9390993) main warning: received buffer in the future (9416960) main warning: received buffer in the future (9443055) main warning: received buffer in the future (9469152) main warning: received buffer in the future (9495248) main warning: received buffer in the future (9521346) main warning: received buffer in the future (9547443) main warning: received buffer in the future (9573540) main warning: vout synchro warning: pts != current_date (-17521672) main warning: late picture skipped (21730324785) main warning: computed PTS is out of range (17452792), clearing out main debug: audio output is starving (411517), playing silence main debug: decoded 104/107 pictures main warning: received buffer in the future (5698582) main warning: received buffer in the future (5724622) main warning: received buffer in the future (5750023) main warning: received buffer in the future (5776068) main warning: received buffer in the future (5802091) main warning: received buffer in the future (5828149) main warning: received buffer in the future (5854213) main warning: received buffer in the future (5880277) main warning: received buffer in the future (5906342) main warning: received buffer in the future (5932208) main warning: received buffer in the future (5958270) main warning: received buffer in the future (5984334) main warning: received buffer in the future (6010398) main warning: received buffer in the future (6029848) main warning: received buffer in the future (6054098) main warning: received buffer in the future (6080123) main warning: received buffer in the future (6106185) main warning: received buffer in the future (6132248) main warning: received buffer in the future (6158311) main warning: received buffer in the future (6184146) main warning: received buffer in the future (6210209) main warning: received buffer in the future (6236273) main warning: received buffer in the future (6262336) main warning: received buffer in the future (6288401) main warning: received buffer in the future (6314465) main warning: received buffer in the future (6340529) main warning: received buffer in the future (6366593) main warning: received buffer in the future (6392646) main warning: received buffer in the future (6418699) main warning: received buffer in the future (6444764) main warning: received buffer in the future (6470828) main warning: received buffer in the future (6496892) main warning: received buffer in the future (6522956) main warning: received buffer in the future (6549019) main warning: received buffer in the future (6575085) main warning: received buffer in the future (6601148) main warning: received buffer in the future (6625459) main warning: received buffer in the future (6651486) main warning: received buffer in the future (6677548) main warning: received buffer in the future (6703612) main warning: received buffer in the future (6729675) main warning: received buffer in the future (6755738) main warning: received buffer in the future (6781802) main warning: received buffer in the future (6807867) main warning: received buffer in the future (6833931) main warning: received buffer in the future (6859995) main warning: received buffer in the future (6886059) main warning: received buffer in the future (6912123) main warning: received buffer in the future (6938186) main warning: received buffer in the future (6964240) main warning: received buffer in the future (6990302) main warning: received buffer in the future (7016365) main warning: received buffer in the future (7042429) main warning: received buffer in the future (7068481) main warning: received buffer in the future (7094543) main warning: received buffer in the future (7120605) main warning: received buffer in the future (7146667) main warning: received buffer in the future (7172730) main warning: received buffer in the future (7198791) main warning: received buffer in the future (7224854) main warning: received buffer in the future (7250918) main warning: received buffer in the future (7276982) main warning: received buffer in the future (7303045) main warning: received buffer in the future (7329109) main warning: received buffer in the future (7355171) main warning: received buffer in the future (7381234) main warning: received buffer in the future (7407274) main warning: received buffer in the future (7433337) main warning: received buffer in the future (7459400) main warning: received buffer in the future (7485463) main warning: received buffer in the future (7511528) main warning: received buffer in the future (7537592) main warning: received buffer in the future (7563655) main warning: received buffer in the future (7589717) main warning: received buffer in the future (7615780) main warning: received buffer in the future (7641844) main warning: received buffer in the future (7667907) main warning: received buffer in the future (7693960) main warning: received buffer in the future (7720023) main warning: received buffer in the future (7746087) main warning: received buffer in the future (7772151) main warning: received buffer in the future (7798213) main warning: received buffer in the future (7824268) main warning: received buffer in the future (7850331) main warning: received buffer in the future (7876395) main warning: received buffer in the future (7902454) main warning: received buffer in the future (7928517) main warning: received buffer in the future (7954581) main warning: received buffer in the future (7980644) main warning: received buffer in the future (8006709) main warning: received buffer in the future (8032773) main warning: received buffer in the future (8058836) main warning: received buffer in the future (8084899) main warning: received buffer in the future (8110963) main warning: received buffer in the future (8137026) main warning: received buffer in the future (8163089) main warning: received buffer in the future (8189152) main warning: received buffer in the future (8215216) main warning: received buffer in the future (8241280) main warning: received buffer in the future (8267336) main warning: received buffer in the future (8293399) main warning: received buffer in the future (8319462) main warning: received buffer in the future (8345526) main warning: received buffer in the future (8371590) main warning: received buffer in the future (8397643) main warning: received buffer in the future (8423706) main warning: received buffer in the future (8449349) main warning: received buffer in the future (8475410) main warning: received buffer in the future (8501472) main warning: received buffer in the future (8527481) main warning: received buffer in the future (8552163) main warning: received buffer in the future (8578219) main warning: received buffer in the future (8604281) main warning: received buffer in the future (8630344) main warning: received buffer in the future (8656407) main warning: received buffer in the future (8682468) main warning: received buffer in the future (8708530) main warning: received buffer in the future (8734592) main warning: received buffer in the future (8760583) main warning: received buffer in the future (8786642) main warning: received buffer in the future (8812704) main warning: received buffer in the future (8838767) main warning: received buffer in the future (8864830) main warning: received buffer in the future (8890892) main warning: received buffer in the future (8916954) main warning: received buffer in the future (8943016) main warning: received buffer in the future (8969078) main warning: received buffer in the future (8995129) main warning: received buffer in the future (9021190) main warning: received buffer in the future (9047253) main warning: received buffer in the future (9073315) main warning: received buffer in the future (9099378) main warning: received buffer in the future (9125441) main warning: received buffer in the future (9151502) main warning: received buffer in the future (9177532) main warning: received buffer in the future (9203594) main warning: received buffer in the future (9229656) main warning: received buffer in the future (9255718) main warning: received buffer in the future (9281780) main warning: received buffer in the future (9307843) main warning: received buffer in the future (9333906) main warning: received buffer in the future (9359969) main warning: received buffer in the future (9386031) main warning: received buffer in the future (9412095) main warning: received buffer in the future (9438224) main warning: received buffer in the future (9464288) main warning: received buffer in the future (9490351) main warning: received buffer in the future (9516415) main warning: received buffer in the future (9542478) main warning: received buffer in the future (9568540) main warning: received buffer in the future (9594596) main warning: received buffer in the future (9620659) main warning: received buffer in the future (9646722) main warning: received buffer in the future (9672785) main warning: received buffer in the future (9698846) main warning: received buffer in the future (9724909) main warning: received buffer in the future (9750971) main warning: received buffer in the future (9777035) main warning: received buffer in the future (9803097) main warning: received buffer in the future (9829161) main warning: received buffer in the future (9855213) main warning: received buffer in the future (9881276) main warning: received buffer in the future (9907338) main warning: received buffer in the future (9933400) main warning: received buffer in the future (9959464) main warning: received buffer in the future (9985527) main warning: received buffer in the future (10011590) main warning: received buffer in the future (10037100) main warning: received buffer in the future (9904055) main warning: received buffer in the future (9929171) main warning: received buffer in the future (9955100) main warning: received buffer in the future (9980750) main warning: received buffer in the future (10006682) main warning: received buffer in the future (10032587) main warning: received buffer in the future (10058492) main warning: received buffer in the future (10082037) main warning: late picture skipped (80250) main warning: late picture skipped (102009) main warning: received buffer in the future (9987616) main warning: received buffer in the future (10013461) main warning: late picture skipped (129015) main warning: received buffer in the future (9977979) main warning: received buffer in the future (10003946) main warning: received buffer in the future (9981495) main warning: received buffer in the future (10007392) main warning: received buffer in the future (10033435) main warning: received buffer in the future (10059372) main warning: late picture skipped (89028) main warning: late picture skipped (106854) main warning: late picture skipped (40439) main warning: received buffer in the future (10024508) main warning: received buffer in the future (10050580) main warning: received buffer in the future (10076632) main warning: received buffer in the future (10003995) main warning: received buffer in the future (10029257) main warning: received buffer in the future (10055121) main warning: received buffer in the future (10081162) main warning: received buffer in the future (10008388) main warning: received buffer in the future (10034405) main warning: received buffer in the future (10060431) main warning: received buffer in the future (9987438) main warning: received buffer in the future (10013442) main warning: received buffer in the future (10039489) main warning: received buffer in the future (10065537) main warning: received buffer in the future (9991047) main warning: received buffer in the future (9913771) main warning: received buffer in the future (9939783) main warning: received buffer in the future (9965650) main warning: received buffer in the future (9991590) main warning: received buffer in the future (10017496) main warning: received buffer in the future (10043439) main warning: received buffer in the future (9973746) main warning: received buffer in the future (9999232) main warning: received buffer in the future (10024899) main warning: received buffer in the future (10050826) main warning: received buffer in the future (9972550) main warning: received buffer in the future (9998434) main warning: received buffer in the future (10023982) main warning: received buffer in the future (10049918) main warning: received buffer in the future (10075821) main warning: received buffer in the future (10007533) main warning: received buffer in the future (10032254) main warning: received buffer in the future (10058145) main warning: received buffer in the future (9987830) main warning: received buffer in the future (10013870) main warning: received buffer in the future (10039815) main warning: received buffer in the future (10065685) main warning: received buffer in the future (9992422) main warning: received buffer in the future (10018242) main warning: received buffer in the future (10044177) main warning: received buffer in the future (10004580) main warning: received buffer in the future (10030335) main warning: received buffer in the future (10056233) main warning: received buffer in the future (10047986) main warning: received buffer in the future (10073786) main warning: received buffer in the future (10001616) main warning: received buffer in the future (10027523) main warning: received buffer in the future (10053421) main warning: received buffer in the future (9979757) main warning: received buffer in the future (10005639) main warning: received buffer in the future (10031536) main warning: received buffer in the future (10057479) main warning: received buffer in the future (9984974) main warning: received buffer in the future (10010551) main warning: received buffer in the future (10036448) main warning: received buffer in the future (10062380) main warning: received buffer in the future (9988806) main warning: received buffer in the future (10014633) main warning: received buffer in the future (10040566) main warning: received buffer in the future (9959278) main warning: received buffer in the future (9985129) main warning: received buffer in the future (10011027) main warning: received buffer in the future (9945024) main warning: received buffer in the future (9971011) main warning: received buffer in the future (9997056) main warning: received buffer in the future (10023104) main warning: received buffer in the future (10049150) main warning: received buffer in the future (10075199) main warning: received buffer in the future (10000444) main warning: received buffer in the future (10026518) main warning: received buffer in the future (10052602) main warning: received buffer in the future (9980708) main warning: received buffer in the future (10001920) main warning: received buffer in the future (10027878) main warning: received buffer in the future (9958761) main warning: received buffer in the future (9977455) main warning: received buffer in the future (10003391) main warning: received buffer in the future (9936803) main warning: received buffer in the future (9955488) main warning: received buffer in the future (9981457) main warning: received buffer in the future (9915823) main debug: control type=0 main debug: control: stopping input main debug: closing input main debug: removing module "livedotcom" main debug: removing module "libmpeg2" main debug: thread times: real 0m36.112287s, kernel 0m0.030043s, user 0m0.680979s main debug: thread 3952 joined (input/decoder.c:191) main debug: killing decoder fourcc `mpgv', 29 PES in FIFO main debug: removing module "mpeg_audio" main debug: thread times: real 0m36.102272s, kernel 0m0.010014s, user 0m0.971396s main debug: thread 4036 joined (input/decoder.c:191) main debug: killing decoder fourcc `mpga', 0 PES in FIFO main debug: removing module "mpgatofixed32" main debug: removing module "bandlimited_resampler" aout_directx debug: closing audio device aout_directx debug: DirectSoundThread exiting main debug: thread times: real 0m36.042185s, kernel 0m0.000000s, user 0m0.000000s main debug: thread 4668 joined (directx.c:598) main debug: removing module "aout_directx" main debug: removing module "float32tos16" main debug: removing module "trivial_mixer" main debug: thread times: real 0m36.322591s, kernel 0m0.060086s, user 0m0.140201s main debug: thread 4108 joined (input/input.c:399) main warning: refcount is 1, delaying before deletion (id=396,type=-7) main debug: garbage collector destroys 1 vout vout_directx debug: DirectXCloseSurface vout_directx debug: DirectXCloseDisplay vout_directx debug: DirectXCloseDisplay clipper vout_directx debug: DirectXCloseDisplay display vout_directx debug: DirectXCloseDDraw vout_directx debug: CloseVideo vout_directx debug: DirectXEventThread terminating vout_directx debug: DirectXCloseWindow vout_directx debug: WinProc WM_DESTROY main debug: thread times: real 0m36.412722s, kernel 0m0.010014s, user 0m0.010014s main debug: thread 4372 joined (directx.c:494) main debug: removing module "vout_directx" main debug: thread times: real 0m36.322591s, kernel 0m0.050072s, user 0m0.420604s main debug: thread 4632 joined (video_output/video_output.c:461) From darnold at futurec.net Tue Oct 24 10:50:14 2006 From: darnold at futurec.net (David Arnold) Date: Tue, 24 Oct 2006 10:50:14 -0700 Subject: [Live-devel] Problem with gettimeofday() in GroupsockHelper.cpp In-Reply-To: <20061024101427.DB2CE43D4C@ws5-1.us4.outblaze.com> Message-ID: We have been having many timing and synchonization problems that I believe I have isolated to a problem in the implementation of gettimeofday() in groupsockHelper.cpp for Windoze. The problem is the time returned from ftime() has a resolution of about 15 milliseconds. Since the task scheduler uses this time for scheduling and interval times for frames for our application are 24000 microseconds and 66667 microseconds, gettimeofday() needs to return times of higher resolution. The changes I have made to gettimeofday() are included below. As you can see, I use QueryPerformanceCounter(), which I believe has a resolution of about 100-nanoseconds. I have tested this change and it has solved our problems. If you see a problem with this solution or suggest an alternate I would appreciate your suggestions. Thank you, Dave Arnold Future Concepts, La Verne, CA --- groupsockHelper.cpp [...] int gettimeofday(struct timeval* tp, int* /*tz*/) { #if defined(_WIN32_WCE) /* FILETIME of Jan 1 1970 00:00:00. */ static const unsigned __int64 epoch = 116444736000000000L; FILETIME file_time; SYSTEMTIME system_time; ULARGE_INTEGER ularge; GetSystemTime(&system_time); SystemTimeToFileTime(&system_time, &file_time); ularge.LowPart = file_time.dwLowDateTime; ularge.HighPart = file_time.dwHighDateTime; tp->tv_sec = (long) ((ularge.QuadPart - epoch) / 10000000L); tp->tv_usec = (long) (system_time.wMilliseconds * 1000); #else #if 0 struct timeb tb; ftime(&tb); tp->tv_sec = tb.time; tp->tv_usec = 1000*tb.millitm; #endif LARGE_INTEGER tickNow; static LARGE_INTEGER tickFrequency; static BOOL tickFrequencySet = FALSE; if (tickFrequencySet == FALSE) { QueryPerformanceFrequency(&tickFrequency); tickFrequencySet = TRUE; } QueryPerformanceCounter(&tickNow); tp->tv_sec = tickNow.QuadPart / tickFrequency.QuadPart; tp->tv_usec =((tickNow.QuadPart % tickFrequency.QuadPart) * 1000000L) / tickFrequency.QuadPart; #endif return 0; } #endif -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com]On Behalf Of David Betrand Sent: Tuesday, October 24, 2006 3:14 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Change Request about rtp timestamping when doing PAUSE/PLAY Ross, > > I noted that live555 implementation for this consists of > setting > in the rtp-info header a rtptime value corresponding to > the last > RTP timestamp sent for this track > > I believe this is correct, because the RTP timestamp *does* increase > appropriately after a PAUSE/PLAY (see below). The problem here is not the timestamps present in the RTP packets, they are correct. It is the "rtptime" value present in the PLAY Response which is incorrect because it equals to the last rtp timestamp sent BEFORE the Pause. (see usage of rtpSink()->currentTimestamp() in OnDemandServerMediaSubsession::startStream()) Following RFC2326bis, the definition of "rtptime" is the following : rtptime: SHALL indicate the RTP timestamp value corresponding to the start time value in the Range response header, or if not explicitly given the implied start point. The client uses this value to calculate the mapping of RTP time to NPT or other media timescale. This parameter SHOULD be present to ensure inter-media synchronization is achieved. There exist no requirement that any received RTP packet will have the same RTP timestamp value as the one in the parameter used to establish synchronization. You cannot use an old value for this rtptime otherwise players will think the packets they receive are in the future. That's exactly what VLC think (see VLC output message in attachment, starting from the time I resumed the stream). In the example sent in my previous email (extracted from the RFC2326bis) you can see that this rtptime value is coherent with the start time value in the Range response header (20 seconds elapsed between the PAUSE and the PLAY, so the rtptime jumps from 2400 to 164400). To summarize, I would say that -at least in this case- you cannot use fCurrentTimestamp as rtptime value. David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze The information contained in this electronic mail transmission is intended only for the use of the individual or entity named above and is privileged and confidential. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Any dissemination, distribution or copying of this communication other than to the person or entity named above is strictly prohibited. If you have received this communication in error, please immediately delete it from your system. From finlayson at live555.com Tue Oct 24 11:51:05 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Oct 2006 11:51:05 -0700 Subject: [Live-devel] Change Request about rtp timestamping when doing PAUSE/PLAY In-Reply-To: <20061024101427.DB2CE43D4C@ws5-1.us4.outblaze.com> References: <20061024101427.DB2CE43D4C@ws5-1.us4.outblaze.com> Message-ID: >Ross, >> > I noted that live555 implementation for this consists of >> setting > in the rtp-info header a rtptime value corresponding to >> the last > RTP timestamp sent for this track >> >> I believe this is correct, because the RTP timestamp *does* increase >> appropriately after a PAUSE/PLAY (see below). > >The problem here is not the timestamps present in the RTP packets, >they are correct. It is the "rtptime" value present in the PLAY >Response which is incorrect because it equals to the last rtp >timestamp sent BEFORE the Pause. OK, I'll see if I can fix this in the next release of the software. However, this i unlikely to be the cause of your problem with VLC, because (as far as I can tell), VLC does not use the "RTPInfo" header information at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Oct 24 11:59:25 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 24 Oct 2006 11:59:25 -0700 Subject: [Live-devel] Problem with gettimeofday() in GroupsockHelper.cpp In-Reply-To: References: Message-ID: >We have been having many timing and synchonization problems that I believe I >have isolated to a problem in the implementation of gettimeofday() in >groupsockHelper.cpp for Windoze. The problem is the time returned from >ftime() has a resolution of about 15 milliseconds. Since the task scheduler >uses this time for scheduling and interval times for frames for our >application are 24000 microseconds and 66667 microseconds, gettimeofday() >needs to return times of higher resolution. The changes I have made to >gettimeofday() are included below. Great, thanks. This will get included in the next release of the software. (I assume/hope that "QueryPerformance*" works OK on Win2k (and presumably Vista) as well as Windows XP...) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bidibulle at operamail.com Wed Oct 25 01:24:34 2006 From: bidibulle at operamail.com (David Betrand) Date: Wed, 25 Oct 2006 09:24:34 +0100 Subject: [Live-devel] Change Request about rtp timestamping when doing PAUSE/PLAY Message-ID: <20061025082435.1005BCA0A4@ws5-11.us4.outblaze.com> Thank you so much, Ross. Regarding VLC, I just checked in source code and you're right it doesn't use 'rtptime' at all. So, there is probably an additional issue (maybe at VLC side) that I will try to investigate... David > ----- Original Message ----- > From: "Ross Finlayson" > To: "LIVE555 Streaming Media - development & use" > Subject: Re: [Live-devel] Change Request about rtp timestamping when doing PAUSE/PLAY > Date: Tue, 24 Oct 2006 11:51:05 -0700 > > > > Ross, > >> > I noted that live555 implementation for this consists of > >> setting > in the rtp-info header a rtptime value corresponding to > >> the last > RTP timestamp sent for this track > >> > >> I believe this is correct, because the RTP timestamp *does* increase > >> appropriately after a PAUSE/PLAY (see below). > > > > The problem here is not the timestamps present in the RTP packets, > > they are correct. It is the "rtptime" value present in the PLAY > > Response which is incorrect because it equals to the last rtp > > timestamp sent BEFORE the Pause. > > OK, I'll see if I can fix this in the next release of the software. > > However, this i unlikely to be the cause of your problem with VLC, > because (as far as I can tell), VLC does not use the "RTPInfo" header > information at all. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze From p4olo_prete at yahoo.it Wed Oct 25 13:59:34 2006 From: p4olo_prete at yahoo.it (Paolo Prete) Date: Wed, 25 Oct 2006 22:59:34 +0200 (CEST) Subject: [Live-devel] AVIFileSink and chunks Message-ID: <20061025205935.47010.qmail@web28013.mail.ukl.yahoo.com> Hi, I'm trying to make a mJPEG avi file from a sequence of JPEG frames, following the tip explained in this post: "[Live-devel] FW: Convert H263 framed stream to.avi)" I have created my own implementation (MyJPEGFramedSource) of FramedSource subclass, based on ElphelJpegDeviceSource, and it works for streaming. Then I've tried to link it in my own implementation of AviFileSink changing all the lines containing: "FramedSource* subsessionSource = subsession->readSource()" with a pointer to my MyJpegFramedSource (plus other modifications) When the Avi file is created, the header seems ok, but the jpegs chunks result in an uncorrect order... Now: there's a fragment of AviFileSink which I couldn't "adapt" to MyAviFileSink unsigned short rtpSeqNum = fOurSubsession.rtpSource()->curPacketRTPSeqNum(); . . . fLastPacketRTPSeqNum = rtpSeqNum; Given that I don't use a RtpSource but a FramedSource, I can't obtain the rtpSeqNum and, consequently, fLastPacktRTSeqNum. So I was forced to cut this fragment (and it's the only one i've cut). So I ask: could it be the reason for the uncorrect order of the chunks or the fragment is uninfluent for making an avi file from a FramedSource? thanks for your help, regards Paolo Prete __________________________________________________ Do You Yahoo!? Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi http://mail.yahoo.it From freegnu at 163.com Wed Oct 25 20:33:22 2006 From: freegnu at 163.com (freegnu) Date: Thu, 26 Oct 2006 11:33:22 +0800 Subject: [Live-devel] delay the delay time of doReadFromFile References: <20061024101427.DB2CE43D4C@ws5-1.us4.outblaze.com> Message-ID: <000901c6f8af$7d5eae00$6401a8c0@zwenqiang> hi all, i ust testMPEG4Videostream to sent a mpeg4 video, but i find the doReadFromFile read stream faster than input(input from fifo), and the frame will lose, how can i delay it what have to do ? thanks From romit.chatterjee at gmail.com Wed Oct 25 22:07:18 2006 From: romit.chatterjee at gmail.com (Romit Chatterjee) Date: Thu, 26 Oct 2006 14:07:18 +0900 Subject: [Live-devel] How to set the IP address the RTSP server should use? Message-ID: Hi, I have installed live555 on my linux machine (FC5). I have two interfaces in my machine (eth0, eth1). Now, whenever I start up 'testOnDemandRTSPServer', it starts up where the rtsp stream urls have IP address of eth0. I need it to use the IP address of eth1 instead. How can I set it up? Thanks in advance for your help. ..Romit Chatterjee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061025/68c4624b/attachment.html From finlayson at live555.com Wed Oct 25 23:03:39 2006 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 25 Oct 2006 23:03:39 -0700 Subject: [Live-devel] How to set the IP address the RTSP server should use? In-Reply-To: References: Message-ID: >Hi, > >I have installed live555 on my linux machine (FC5). I have two >interfaces in my machine (eth0, eth1). Now, whenever I start up >'testOnDemandRTSPServer', it starts up where the rtsp stream urls >have IP address of eth0. I need it to use the IP address of eth1 >instead. How can I set it up? Try adding the line ReceivingInterfaceAddr = our_inet_addr("x.y.z.w"); at the start of your application. (Replace "x.y.z.w" with the IP address of your desired interface.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From buscarini at gmail.com Thu Oct 26 04:36:38 2006 From: buscarini at gmail.com (Antonio Garcia) Date: Thu, 26 Oct 2006 13:36:38 +0200 Subject: [Live-devel] Problem trying to use libavcodec and live555 Message-ID: <78DAC5B7-64E5-4CDF-90F5-F2B7C4C0EA2A@cc.upv.es> Hello, I'm trying to send video opened with libavcodec using liveMedia, but I haven't succeded. I have tried to pass the AVPacket member variables (data and size) to a MPEG1or2RTPSink, but it doesn't work. Each packet starts with 4 bytes of 0's, which is something that the live555 doesn't recognize (It says it's not a fragment or something like that). Does anyone know how to connect both libraries? Thanks in advance , Antonio Garcia From shaswata at alumnux.com Thu Oct 26 06:29:23 2006 From: shaswata at alumnux.com (Shaswata Jash) Date: Thu, 26 Oct 2006 18:59:23 +0530 Subject: [Live-devel] Problem trying to use libavcodec and live555 References: <78DAC5B7-64E5-4CDF-90F5-F2B7C4C0EA2A@cc.upv.es> Message-ID: <000901c6f902$c076f4b0$2e0aa8c0@NITU> All those classes derived from FramedFileSource and FramedFilter are responsible to extract a complete media frame and to send it to corresponding RTPSink. So will it not be better that libavcodec should be used within these classes? If that is so, there is no need to change any code within RTPSinks, they are just very perfect to encapsulate to form RTP packets from those media frames (provided by classes derived from FramedFileSource and FramedFilter ). Also, you have probably mixed-matched between the AVPacket and real RTPPackets. You can extract media data from AVPicture and then put that to 'fTo' (internal buffer defined by LIVE). If you clarify further your requirements, then it will be easy to understand the overall scheme of yours. With regards, Shaswata ----- Original Message ----- From: "Antonio Garcia" To: Sent: Thursday, October 26, 2006 5:06 PM Subject: [Live-devel] Problem trying to use libavcodec and live555 > Hello, > > I'm trying to send video opened with libavcodec using liveMedia, but > I haven't succeded. I have tried to pass the AVPacket member > variables (data and size) to a MPEG1or2RTPSink, but it doesn't work. > Each packet starts with 4 bytes of 0's, which is something that the > live555 doesn't recognize (It says it's not a fragment or something > like that). > Does anyone know how to connect both libraries? > > Thanks in advance , > Antonio Garcia > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From hartman at videolan.org Thu Oct 26 07:21:51 2006 From: hartman at videolan.org (Derk-Jan Hartman) Date: Thu, 26 Oct 2006 16:21:51 +0200 Subject: [Live-devel] Content-Base Message-ID: <04B40826-7A5F-452A-8855-632599456ACF@videolan.org> Hi Ross, I have a user in the forum that has an issue with a stream that specifies a Content-Base != URL http://forum.videolan.org/viewtopic.php?t=27794 Is this behaviour as expected? Is it a bug in liveMedia Or is it a bug in VLC ? DJ From finlayson at live555.com Thu Oct 26 09:47:23 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Oct 2006 09:47:23 -0700 Subject: [Live-devel] Content-Base In-Reply-To: <04B40826-7A5F-452A-8855-632599456ACF@videolan.org> References: <04B40826-7A5F-452A-8855-632599456ACF@videolan.org> Message-ID: >Hi Ross, > >I have a user in the forum that has an issue with a stream that >specifies a Content-Base != URL >http://forum.videolan.org/viewtopic.php?t=27794 > >Is this behaviour as expected? >Is it a bug in liveMedia Yes - the RTSP client code should be looking at the "Content-Base:" header, but currently doesn't (because, for most streams, it's not needed). This is the first stream I've seen where it's important. I'll fix this (although, unfortunately, the server in question seems to be stuck behind a firewall, so I can't use it for testing). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From buscarini at gmail.com Thu Oct 26 12:34:13 2006 From: buscarini at gmail.com (=?UTF-8?Q?Jos=C3=A9_Manuel_S=C3=A1nchez?=) Date: Thu, 26 Oct 2006 21:34:13 +0200 Subject: [Live-devel] %5BLive-devel%5D%20Problem%20trying%20to%20use%20libavcodec%20and%20live555 Message-ID: <979b10010610261234s2d6e0c3ct9ee12d4a595cd588@mail.gmail.com> Thanks for the quick response. I'll try to clarify what I'm trying to do. This is what I intend to do: file -> ffmpeg -> modify frame -> ffmpeg -> liveMedia -> network -> vlc I want to load a movie, modify the raw frames, encode it again and send it to another computer which has a VLC client. I have been successful with the last part (with the example testMPEG1or2VideoStreamer), and with the first one (I can read the file with libavcoded and then see the decoded frames). The next thing I have tried is this: file -> ffmpeg -> liveMedia -> network -> vlc This is where it fails. I decode the movie with av_read_frame, and then I connect the output with a MPEG1or2StreamFramer, which is connected with a MPEG1or2RTPSink. This is more or less the code of the test. Should I decode the frame and put it to MPEG1or2StreamFramer or is the AVPacket what it's expecting? The main problem is that I don't know what each module is expecting. Does the liveMedia send decoded frames? does it encode them? Thanks, Antonio Garcia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061026/2046d252/attachment-0001.html From finlayson at live555.com Thu Oct 26 12:53:09 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Oct 2006 12:53:09 -0700 Subject: [Live-devel] Problem trying to use libavcodec and live555 In-Reply-To: <979b10010610261234s2d6e0c3ct9ee12d4a595cd588@mail.gmail.com> References: <979b10010610261234s2d6e0c3ct9ee12d4a595cd588@mail.gmail.com> Message-ID: >The next thing I have tried is this: > >file -> ffmpeg -> liveMedia -> network -> vlc > >This is where it fails. I decode the movie with av_read_frame, and >then I connect the output with a MPEG1or2StreamFramer, which is >connected with a MPEG1or2RTPSink. That can't possibly work, because "MPEG1or2VideoStreamFramer" (and "MPEG1or2VideoRTPSink") expects to see *encoded* MPEG (1 or 2) video data, not raw (decoded) video data. > Does the liveMedia send decoded frames? does it encode them? No to both. The "LIVE555 Streaming Media" code does not include any encoders or decoders. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From romit.chatterjee at gmail.com Thu Oct 26 17:52:16 2006 From: romit.chatterjee at gmail.com (Romit Chatterjee) Date: Fri, 27 Oct 2006 09:52:16 +0900 Subject: [Live-devel] live-devel Digest, Vol 36, Issue 15 In-Reply-To: References: Message-ID: Hi, Thanks a lot Ross for the suggestion. It worked well! However I have another issue. My client is connected to the live555.com server through an USB cable, and I find that the RTSP packets are exchanged alright. However, the RTP packets are sent by the server with a a 15 seconds time gap between each packet! As a result I can see no media in my client. Do you have any idea why the RTP packets are so slow in coming (is it due the the speed of USB?)? Can you suggest something for improving the rate? Thanks again for your help. I really appreciate it! ..Romit On 10/27/06, live-devel-request at ns.live555.com < live-devel-request at ns.live555.com> wrote: > > ------------------------------ > > Message: 6 > Date: Thu, 26 Oct 2006 14:07:18 +0900 > From: "Romit Chatterjee" > Subject: [Live-devel] How to set the IP address the RTSP server should > use? > To: live-devel at ns.live555.com > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I have installed live555 on my linux machine (FC5). I have two interfaces > in > my machine (eth0, eth1). Now, whenever I start up > 'testOnDemandRTSPServer', > it starts up where the rtsp stream urls have IP address of eth0. I need it > to use the IP address of eth1 instead. How can I set it up? > > Thanks in advance for your help. > > ..Romit Chatterjee > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.live555.com/pipermail/live-devel/attachments/20061025/68c4624b/attachment-0001.html > > ------------------------------ > > Message: 7 > Date: Wed, 25 Oct 2006 23:03:39 -0700 > From: Ross Finlayson > Subject: Re: [Live-devel] How to set the IP address the RTSP server > should use? > To: LIVE555 Streaming Media - development & use > > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > >Hi, > > > >I have installed live555 on my linux machine (FC5). I have two > >interfaces in my machine (eth0, eth1). Now, whenever I start up > >'testOnDemandRTSPServer', it starts up where the rtsp stream urls > >have IP address of eth0. I need it to use the IP address of eth1 > >instead. How can I set it up? > > Try adding the line > > ReceivingInterfaceAddr = our_inet_addr("x.y.z.w"); > > at the start of your application. (Replace "x.y.z.w" with the IP > address of your desired interface.) > -- > > 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/20061026/1314e0e7/attachment.html From freegnu at 163.com Thu Oct 26 19:40:01 2006 From: freegnu at 163.com (freegnu) Date: Fri, 27 Oct 2006 10:40:01 +0800 Subject: [Live-devel] This computer has an invalid IP address References: <979b10010610261234s2d6e0c3ct9ee12d4a595cd588@mail.gmail.com> Message-ID: <005d01c6f971$342c7fb0$6401a8c0@zwenqiang> hi, all , when i run the testMPEG4VideoStream on the computer, i t said :This computer has an invalid IP :0x0 and i really confused that it call chooseRandomIPv4SSMAddress(*env) to get a random multicast address? From freegnu at 163.com Thu Oct 26 20:18:16 2006 From: freegnu at 163.com (freegnu) Date: Fri, 27 Oct 2006 11:18:16 +0800 Subject: [Live-devel] This computer has an invalid IP address References: <979b10010610261234s2d6e0c3ct9ee12d4a595cd588@mail.gmail.com> <005d01c6f971$342c7fb0$6401a8c0@zwenqiang> Message-ID: <007301c6f976$8bd224e0$6401a8c0@zwenqiang> failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error : No such device it cant join the multicast group fail, and reference that: No such device(the value is ENODEV), but when the setsockopt() function fail it will set the error by EBADF,ENOTSOCK,ENOPROTTOOPT,EFAULT ----- Original Message ----- From: "freegnu" To: "LIVE555 Streaming Media - development & use" Sent: Friday, October 27, 2006 10:40 AM Subject: [Live-devel] This computer has an invalid IP address > hi, all , when i run the testMPEG4VideoStream on the computer, i t said :This computer has an invalid IP :0x0 > > and i really confused that it call chooseRandomIPv4SSMAddress(*env) > to get a random multicast address? > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From shaswata at alumnux.com Thu Oct 26 22:08:07 2006 From: shaswata at alumnux.com (Shaswata Jash) Date: Fri, 27 Oct 2006 10:38:07 +0530 Subject: [Live-devel] %5BLive-devel%5D%20Problem%20trying%20to%20use%20libavcodec%20and%20live555 References: <979b10010610261234s2d6e0c3ct9ee12d4a595cd588@mail.gmail.com> Message-ID: <002b01c6f985$e40dbcf0$2e0aa8c0@NITU> As said by Ross, LIVE doesn't encode or decode. Now first of all take a look at the following code - FramedSource* MPEG1or2VideoFileServerMediaSubsession ::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 500; // kbps, estimate ByteStreamFileSource* fileSource = ByteStreamFileSource::createNew(envir(), fFileName); if (fileSource == NULL) return NULL; fFileSize = fileSource->fileSize(); return MPEG1or2VideoStreamFramer ::createNew(envir(), fileSource, fIFramesOnly, fVSHPeriod); } If you notice that it is using ByteStreamFileSource which reads bytes from a file and then MPEG1or2VideoStreamFramer uses those data from ByteStreamFileSource to create a MPEG1or2 video frame. So without changing any other code, you can make a tweak- i) Create a class similar to ByteStreamFileSource ii) Your created class (derived from FramedFileSource) will directly return the encoded frame (using ffmpeg that you have already done) iii) For that you have to implement that doGetNextFrame() In this scheme, only drawback is that MPEG1or2VideoStreamFramer parses an already framed media data. But advantage of this scheme is that you need not change in other live classes where code may be quite involved. With regards, Shaswata ----- Original Message ----- From: Jos? Manuel S?nchez To: live-devel at ns.live555.com Sent: Friday, October 27, 2006 1:04 AM Subject: [Live-devel]%5BLive-devel%5D%20Problem%20trying%20to%20use%20libavcodec%20and%20live555 Thanks for the quick response. I'll try to clarify what I'm trying to do. This is what I intend to do: file -> ffmpeg -> modify frame -> ffmpeg -> liveMedia -> network -> vlc I want to load a movie, modify the raw frames, encode it again and send it to another computer which has a VLC client. I have been successful with the last part (with the example testMPEG1or2VideoStreamer), and with the first one (I can read the file with libavcoded and then see the decoded frames). The next thing I have tried is this: file -> ffmpeg -> liveMedia -> network -> vlc This is where it fails. I decode the movie with av_read_frame, and then I connect the output with a MPEG1or2StreamFramer, which is connected with a MPEG1or2RTPSink. This is more or less the code of the test. Should I decode the frame and put it to MPEG1or2StreamFramer or is the AVPacket what it's expecting? The main problem is that I don't know what each module is expecting. Does the liveMedia send decoded frames? does it encode them? Thanks, Antonio Garcia ------------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061026/a96572a6/attachment.html From finlayson at live555.com Thu Oct 26 23:05:12 2006 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 26 Oct 2006 23:05:12 -0700 Subject: [Live-devel] Problem trying to use libavcodec and live555 In-Reply-To: <002b01c6f985$e40dbcf0$2e0aa8c0@NITU> References: <979b10010610261234s2d6e0c3ct9ee12d4a595cd588@mail.gmail.com> <002b01c6f985$e40dbcf0$2e0aa8c0@NITU> Message-ID: >In this scheme, only drawback is that MPEG1or2VideoStreamFramer >parses an already framed media data. Note that if your input source (e.g., your ffmpeg-derived video encoder object) delivers complete frames - one at a time - rather than an unstructured byte stream, then you can use "MPEG1or2VideoStreamDiscreteFramer" rather than "MPEG1or2VideoStreamFramer". -- 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/20061026/cfc2a808/attachment.html From e.beckers at gmail.com Fri Oct 27 02:02:58 2006 From: e.beckers at gmail.com (Erwin Beckers) Date: Fri, 27 Oct 2006 11:02:58 +0200 Subject: [Live-devel] patch for stackoverflow Message-ID: Hi, I'm using the LiveMedia555 library and compiled it under Windows XP using Visual Studio 2005 With this environment i sometimes received a stackoverflow when using the library to receive a RTSP stream which contains a MPEG-2 TS stream Fortunaly i found out what causes it and this is the fix i'm using. The problem is that: 1. MultiFramedRTPSource::doGetNextFrame1() is called 2. in this method afterGetting(this); is called 3. afterGetting(this) does a lot, but in the end it calls continuePlaying() which again calls MultiFramedRTPSource::doGetNextFrame() 4. MultiFramedRTPSource::doGetNextFrame() again calls MultiFramedRTPSource::doGetNextFrame1() which can lead to the stack overflow. I added a simple boolean to check if we're already in doGetNextFrame1() and ifso, i simply return. Not sure if this is the best way todo it, but it works for me static bool bInDoGetNextFrame1=false; void MultiFramedRTPSource::doGetNextFrame1() { if (bInDoGetNextFrame1) return; bInDoGetNextFrame1=true; while (fNeedDelivery) { ..... Another thing i noticed is that many pointers,buffers,variables are not initialized correctly in the constructors. The library assumed that the compiler initializes all variables to 0 but this is not the case when using visual studio in debug mode. In debug mode the compiled initializes all variabled with the value 0xcd which is especially done to detect un-initialized vars. Perhaps it would be better to initialize all variables,buffers,pointers in the constructors Regards Erwin Beckers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061027/bf9a3064/attachment-0001.html From e.beckers at gmail.com Fri Oct 27 02:06:46 2006 From: e.beckers at gmail.com (Erwin Beckers) Date: Fri, 27 Oct 2006 11:06:46 +0200 Subject: [Live-devel] patch for stackoverflow Message-ID: I forgot to mention that at the end of void MultiFramedRTPSource::doGetNextFrame1() the bInDoGetNextFrame1 is set to false again.So it looks like this: static bool bInDoGetNextFrame1=false; void MultiFramedRTPSource::doGetNextFrame1() { if (bInDoGetNextFrame1) return; bInDoGetNextFrame1=true; while (fNeedDelivery) { ...... } bInDoGetNextFrame1=false; } Sorry for the double-post. Erwin Beckers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061027/aeb61028/attachment.html From finlayson at live555.com Fri Oct 27 10:39:35 2006 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Oct 2006 10:39:35 -0700 Subject: [Live-devel] patch for stackoverflow In-Reply-To: References: Message-ID: >The problem is that: >1. MultiFramedRTPSource::doGetNextFrame1() is called >2. in this method afterGetting(this); is called >3. afterGetting(this) does a lot, but in the end it calls >continuePlaying() which again calls >MultiFramedRTPSource::doGetNextFrame() >4. MultiFramedRTPSource::doGetNextFrame() again calls >MultiFramedRTPSource::doGetNextFrame1() >which can lead to the stack overflow. Erwin, Under normal circumstances, that's not the case. Step 2 directly follows step 1 only when there is previously read, but still unused, incoming RTP packet data awaiting to be processed. In most circumstances, this chain of calls ends quickly, and the code's control flow returns to the event loop - so there's no stack overflow. On looking at the code some more, however, I realize that there is one special situation that *may* cause a long chain of calls (and thus potentially a stack overflow, especially if you have a small stack). If you are receiving a high-bitrate stream that has some packet loss, then it is possible - with the current code - to have a long chain of calls (when processing the queue of packets that arrived after a lost packet). Until I fix this problem (in the next release), you can work around it by changing "fThresholdTime(100000)" on line 433 of "MultiFramedRTPSource" to "fThresholdTime(0)". (Note that the 'fix' that you suggested is not correct, because it won't properly handle those RTP payload formats that include more than one frame in each RTP packet.) >Another thing i noticed is that many pointers,buffers,variables are >not initialized correctly in the constructors. >The library assumed that the compiler initializes all variables to 0 The library should not be assuming this. Whenever it does not initialize a variable, this is because it does not expect the variable to be read before it is first assigned. If, however, you find places where the library is (improperly) assuming that a variable is initialized to 0, then please let us know, so we can fix this. >Perhaps it would be better to initialize all >variables,buffers,pointers in the constructors As I noted above, for efficiency we sometimes do not initialize a variable in the constructor if we know that it will never be accessed prior to first being assigned. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jerry.johns at nuvation.com Fri Oct 27 12:14:04 2006 From: jerry.johns at nuvation.com (Jerry Johns) Date: Fri, 27 Oct 2006 12:14:04 -0700 Subject: [Live-devel] Multi-thread Message-ID: <22F8D1FFED33654987DE9D447F74E54607AB@mailguy2.nuvation.com> Hi all, Me again with the multi threaded business: so I managed to compile and integrate the livemedia framework on a separate thread, and allow it to run with the 3 or 4 other threads I have on my application; it works fine with the others (some frames are being lost, but thats something I have to look into, most prob due to extra load of other threads) My next task involves feed live frames from another thread to this livemedia thread; in this scenario, I'm thinking of two possibilities; a) just letting the all threads run as is, and let livemedia constantly check a shared buffer to see if new data exists; if it does, parse and send through RTP; otherwise, return nothing from doGetNextFrame() - in this version, the video thread and livemedia thread act as separate entities b) the video thread passes data to livemedia, which has to process it imeediately and send it through rtp; once its done, it blocks itself and lets video resume execution; this part I'm not too sure of; can I block this livemedia thread, even though the select function in the doEventLoop also does blocking when no sockets or available or no events are scheduled? (Double blocks I mean) What do you guys advise? Or a better approach? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061027/8baab09e/attachment.html From finlayson at live555.com Fri Oct 27 12:38:58 2006 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Oct 2006 12:38:58 -0700 Subject: [Live-devel] Multi-thread In-Reply-To: <22F8D1FFED33654987DE9D447F74E54607AB@mailguy2.nuvation.com> References: <22F8D1FFED33654987DE9D447F74E54607AB@mailguy2.nuvation.com> Message-ID: >What do you guys advise? You can start by (re)reading the FAQ. -- 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/20061027/13274181/attachment.html From finlayson at live555.com Fri Oct 27 16:04:21 2006 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 27 Oct 2006 16:04:21 -0700 Subject: [Live-devel] Content-Base In-Reply-To: <04B40826-7A5F-452A-8855-632599456ACF@videolan.org> References: <04B40826-7A5F-452A-8855-632599456ACF@videolan.org> Message-ID: FYI, the latest release (2006.10.27) of the "LIVE555 Streaming Media" software now recognizes the "Content-Base" header, and so should fix this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From frepe at bredband.net Sat Oct 28 04:04:07 2006 From: frepe at bredband.net (Fredrik Persson) Date: Sat, 28 Oct 2006 13:04:07 +0200 Subject: [Live-devel] Bug: "Unable to find emulated OSS device" Message-ID: <1162033447.5379.9.camel@localhost> wis-streamer currently does not work on a large number of systems due to a bug in sscanf. There is a workaround to handle this in a previous post to the list: http://lists.live555.com/pipermail/live-devel/2006-October/005244.html My guess is that the number of people affected by this bug is HUGE. I base this assumption on the fact that I tried this on a fresh Ubuntu Linux installation. I have filed a bug report with Ubuntu, hoping that they will escalate to the libc developers: https://launchpad.net/bugs/68813 /Fredrik Persson From finlayson at live555.com Sat Oct 28 10:36:33 2006 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 28 Oct 2006 10:36:33 -0700 Subject: [Live-devel] Bug: "Unable to find emulated OSS device" In-Reply-To: <1162033447.5379.9.camel@localhost> References: <1162033447.5379.9.camel@localhost> Message-ID: >wis-streamer currently does not work on a large number of systems due to >a bug in sscanf. If that's the case, then it's "sscanf()" that should be fixed. The code for it is Open Source - just like "wis-streamer". It should be possible - by looking at the code - to figure out *exactly* what is going wrong. >There is a workaround to handle this in a previous post to the list: I'm not going to consider adding this 'workaround' to the code unless and until someone explains/convinces me of all of the following: 1/ Exactly what the bug is that is causing this. 2/ That a lot of people really are affected by this bug (in particular, that the bug is not just in one version of the runtime library code that has subsequently been fixed). 3/ That the proposed 'workaround' is the best way to overcome the problem, and that there are no other instances of the problem (e.g., in the other places where "sscanf()" is called) in the "wis-streamer" code (or, for that matter, anywhere in the "LIVE555 Streaming Media" code). >I have filed a bug report with Ubuntu, hoping that they will escalate to >the libc developers: Again, it would be better to have first identified *exactly* what the problem is. Remember, You Have Complete Source Code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From frepe at bredband.net Sat Oct 28 10:56:18 2006 From: frepe at bredband.net (Fredrik Persson) Date: Sat, 28 Oct 2006 19:56:18 +0200 Subject: [Live-devel] Bug: "Unable to find emulated OSS device" In-Reply-To: References: <1162033447.5379.9.camel@localhost> Message-ID: <1162058178.5401.14.camel@localhost> On Sat, 2006-10-28 at 10:36 -0700, Ross Finlayson wrote: > >wis-streamer currently does not work on a large number of systems due to > >a bug in sscanf. > > If that's the case, then it's "sscanf()" that should be fixed. Agreed. And my bug report to Ubuntu is a step in that direction. > The > code for it is Open Source - just like "wis-streamer". It should be > possible - by looking at the code - to figure out *exactly* what is > going wrong. Agreed. The question is, who is going to do that? > Again, it would be better to have first identified *exactly* what the > problem is. Remember, You Have Complete Source Code. I do have the complete source, but if I did identify exactly what was wrong with every faulty piece of open source software that I use, which happens daily, I would not have time to eat, sleep or work for the next thousand years. My problem, which was to run wis-streamer, is solved. I don't care about this issue anymore. Your problem, although you don't seem to perceive this as a problem, is that your software currently does not function on one of the worlds largest linux distributions out there, Ubuntu 6.10 (released two days ago), is not solved. /Fredrik Persson From morgan.torvolt at gmail.com Sun Oct 29 13:21:03 2006 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 30 Oct 2006 01:21:03 +0400 Subject: [Live-devel] Strange problem when spawning multiple instances of Live555 programs Message-ID: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> Hi all I have encountered a strange problem. I am setting up a unittest system, and thought everything was going smoothly. What I do is spawn multiple occurences of programs that are based on live555. One of wich is the openRTSP rtsp client. What happens, is that most of the running programs works fine. I have made one program that accepts data on a socket, and retransmits it on a RTSP socket (sort of like testOnDemandRTSPServer, but with socket input instead of a file), and the other one i run is the openRTSP program to "simulate" a client. Everything works fine as long as I spawn no more than 25 server/client pairs. If I go above that, say 40, one of the programs (sometimes openRTSP, other times the server) starts hogging CPU power. What is really weird is that they give the exact same output when I use "strace -p [PID]" on the pid that "hangs". What is even stranger, is that when some or all of the other spawned processes dies, the one that has "crashed" comes back to life. It seems to dump all the data it has accumulated to the openRTSP client in one big chunk, regardless of which program that crashed. I use timeout on openRTSP (-e 60), and the one that crashes finishes after exactly the double of the timeout value. It seems to hang until the other processes finish, and then continue, but not always. Sometimes it finishes at the correct time, but I think it is always tvserver that has failed when that happens. This happens no matter what. If I delay for 1 second between spawning processes, it still hangs. Sometimes more than one hangs also, but not so often. I allways make sure that the server is up and running before I spawn the openRTSP client. At the bottom is some printouts from "ps aux | grep open" Here is the output from strace from both processes when failing and OK: openRTSP failing: Process 31156 attached - interrupt to quit socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(4, SOL_IP, IP_MULTICAST_LOOP, "\1", 1) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(" 0.0.0.0")}, [16]) = 0 bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(45067), sin_addr=inet_addr("0.0.0.0")}, [68719476752]) = 0 close(5) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(5, SOL_IP, IP_MULTICAST_LOOP, "\1", 1) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(" 0.0.0.0")}, [16]) = 0 bind(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(45185), sin_addr=inet_addr("0.0.0.0")}, [68719476752]) = 0 close(4) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(4, SOL_IP, IP_MULTICAST_LOOP, "\1", 1) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(" 0.0.0.0")}, [16]) = 0 bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(45195), sin_addr=inet_addr("0.0.0.0")}, [68719476752]) = 0 close(5) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(5, SOL_IP, IP_MULTICAST_LOOP, "\1", 1) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(" 0.0.0.0")}, [16]) = 0 bind(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(45313), sin_addr=inet_addr("0.0.0.0")}, [68719476752]) = 0 close(4) = 0 openRTSP working OK. This is from the exact same process as above, just later, when the others have died: write(1, "G\0 \237\377\33\336I\302N\367<\10\266\5T\236\326\373+\261"..., 1316) = 1316 gettimeofday({1162164160, 636987}, NULL) = 0 select(6, [4 5], NULL, NULL, {0, 390220}) = 1 (in [5], left {0, 390220}) gettimeofday({1162164160, 637055}, NULL) = 0 select(6, [5], NULL, NULL, NULL) = 1 (in [5]) recvfrom(5, "\200!\232A\331\207Z\0\342\224\4dG\0 \224,\344 \244,U\312"..., 9984, 0, {sa_family=AF_INET, sin_port=htons(57624), sin_addr=inet_addr(" 10.0.0.20")}, [16]) = 1328 gettimeofday({1162164160, 637176}, NULL) = 0 gettimeofday({1162164160, 637204}, NULL) = 0 write(1, "G\0 \224,\344 \244,U\312KS\352\303d\216*.d\r\n\345\231"..., 1316) = 1316 gettimeofday({1162164160, 637302}, NULL) = 0 select(6, [4 5], NULL, NULL, {0, 389905}) = 1 (in [5], left {0, 388000}) gettimeofday({1162164160, 638019}, NULL) = 0 select(6, [5], NULL, NULL, NULL) = 1 (in [5]) recvfrom(5, "\200!\232B\331\207Z\363\342\224\4dG\0 \272\177\0\377\377"..., 9984, 0, {sa_family=AF_INET, sin_port=htons(57624), sin_addr=inet_addr(" 10.0.0.20")}, [16]) = 1328 gettimeofday({1162164160, 638143}, NULL) = 0 gettimeofday({1162164160, 638173}, NULL) = 0 write(1, "G\0 \272\177\0\377\377\377\377\377\377\377\377\377\377"..., 1316) = 1316 gettimeofday({1162164160, 638253}, NULL) = 0 select(6, [4 5], NULL, NULL, {0, 388954}) = 1 (in [5], left {0, 388000}) gettimeofday({1162164160, 643212}, NULL) = 0 select(6, [5], NULL, NULL, NULL) = 1 (in [5]) recvfrom(5, "\200!\232C\331\207\\\306\342\224\4dG\0000\232\204]\374"..., 9984, 0, {sa_family=AF_INET, sin_port=htons(57624), sin_addr=inet_addr(" 10.0.0.20")}, [16]) = 1328 gettimeofday({1162164160, 643335}, NULL) = 0 gettimeofday({1162164160, 643365}, NULL) = 0 write(1, "G\0000\232\204]\374\r\216b8\273\322\234\275\205\261K\245"..., 1316) = 1316 gettimeofday({1162164160, 643445}, NULL) = 0 select(6, [4 5], NULL, NULL, {0, 383762} Process 31156 detached Here is the output from my server when failing: Process 389 attached - interrupt to quit socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(5, SOL_IP, IP_MULTICAST_LOOP, "\1", 1) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(" 0.0.0.0")}, [8589934608]) = 0 bind(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(38411), sin_addr=inet_addr("0.0.0.0")}, [834854789513740304]) = 0 close(4) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(4, SOL_IP, IP_MULTICAST_LOOP, "\1", 1) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(" 0.0.0.0")}, [8589934608]) = 0 bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(38529), sin_addr=inet_addr("0.0.0.0")}, [9337650885989236752]) = 0 close(5) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(5, SOL_IP, IP_MULTICAST_LOOP, "\1", 1) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(" 0.0.0.0")}, [8589934608]) = 0 bind(5, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(5, {sa_family=AF_INET, sin_port=htons(38539), sin_addr=inet_addr("0.0.0.0")}, [10058226826368516112]) = 0 close(4) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(4, SOL_IP, IP_MULTICAST_LOOP, "\1", 1) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr(" 0.0.0.0")}, [8589934608]) = 0 bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 getsockname(4, {sa_family=AF_INET, sin_port=htons(38657), sin_addr=inet_addr("0.0.0.0")}, [114560324111171600]) = 0 close(5) = 0 And here when running correctly. As with openRTSP, this too is from the same pid, and thus exactly the same program: gettimeofday({1162168430, 124871}, NULL) = 0 gettimeofday({1162168430, 124901}, NULL) = 0 sendto(4, "\200!M\225J\341?\211\256\374)JG\0 \322\305\273u\260\357"..., 1328, 0, {sa_family=AF_INET, sin_port=htons(57796), sin_addr=inet_addr(" 10.0.0.20")}, 16) = 1328 gettimeofday({1162168430, 125012}, NULL) = 0 gettimeofday({1162168430, 125043}, NULL) = 0 select(6, [0 1 5], NULL, NULL, {0, 0}) = 0 (Timeout) select(101, [100], NULL, NULL, {0, 500000}) = 1 (in [100], left {0, 468000}) select(101, [100], NULL, NULL, {1, 0}) = 1 (in [100], left {1, 0}) read(100, "G\0 \330\236\25~o\35A\240\370O>Cs^\255\334S\227t}\352\206"..., 1316) = 1316 gettimeofday({1162168430, 157521}, NULL) = 0 gettimeofday({1162168430, 157552}, NULL) = 0 sendto(4, "\200!M\226J\341K\4\256\374)JG\0 \330\236\25~o\35A\240\370"..., 1328, 0, {sa_family=AF_INET, sin_port=htons(57796), sin_addr=inet_addr(" 10.0.0.20")}, 16) = 1328 gettimeofday({1162168430, 157650}, NULL) = 0 gettimeofday({1162168430, 157682}, NULL) = 0 select(6, [0 1 5], NULL, NULL, {0, 0}) = 1 (in [1], left {0, 0}) select(101, [100], NULL, NULL, {0, 500000}) = 1 (in [100], left {0, 500000}) select(101, [100], NULL, NULL, {1, 0}) = 1 (in [100], left {1, 0}) read(100, "G\0 \336f\t?\272Q0x\02019\231\27*\"\2424/T\205\202\320"..., 1316) = 1316 gettimeofday({1162168430, 157891}, NULL) = 0 gettimeofday({1162168430, 157921}, NULL) = 0 sendto(4, "\200!M\227J\341K%\256\374)JG\0 \336f\t?\272Q0x\02019\231"..., 1328, 0, {sa_family=AF_INET, sin_port=htons(57796), sin_addr=inet_addr(" 10.0.0.20")}, 16) = 1328 gettimeofday({1162168430, 158004}, NULL) = 0 gettimeofday({1162168430, 158036}, NULL) = 0 gettimeofday({1162168430, 158092}, NULL) = 0 select(2, [1], NULL, NULL, NULL) = 1 (in [1]) recvfrom(1, "TEARDOWN rtsp://10.0.0.20:23896/"..., 10000, 0, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\3604F\335\377\177\0\0"}, [0]) = 130 time(NULL) = 1162168430 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=73, ...}) = 0 sendto(1, "RTSP/1.0 200 OK\r\nCSeq: 5\r\nDate: "..., 65, 0, NULL, 0) = 65 close(1) = 0 gettimeofday({1162168430, 159298}, NULL) = 0 write(1, "Str::::::::::::::::::::::::::::::::::::::::::::::::::.., 178) = -1 EBADF (Bad file descriptor) munmap(0x2addcd65c000, 8192) = 0 exit_group(0) = ? Process 389 detached I did insert some :::: to remove some revealing debug info. ps aux | grep open mt 2335 0.6 0.0 7708 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:37534/test mt 2339 0.6 0.0 7708 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:40199/test mt 2343 0.6 0.0 7712 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:35529/test mt 2347 0.4 0.0 7708 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:24026/test mt 2351 0.6 0.0 7708 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:22651/test mt 2355 0.4 0.0 7708 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:53278/test mt 2359 0.8 0.0 7712 1264 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:47319/test mt 2363 0.6 0.0 7708 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:1619/test mt 2367 0.6 0.0 7712 1264 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:40071/test mt 2371 0.8 0.0 7712 1264 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:40077/test mt 2375 0.6 0.0 7712 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:36133/test mt 2379 0.4 0.0 7712 1264 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:41026/test mt 2383 0.2 0.0 7712 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:15370/test mt 2387 0.4 0.0 7708 1252 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:48064/test mt 2391 0.6 0.0 7712 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:8066/test mt 2395 0.6 0.0 7712 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:26160/test mt 2399 0.6 0.0 7712 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:32218/test mt 2403 0.4 0.0 7708 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:55087/test mt 2407 0.8 0.0 7712 1264 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:60707/test mt 2411 0.4 0.0 7712 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:53483/test mt 2415 0.2 0.0 7708 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:44898/test mt 2419 0.5 0.0 7712 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:9270/test mt 2423 0.7 0.0 7708 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:3285/test mt 2427 1.0 0.0 7712 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:48237/test mt 2431 1.5 0.0 7708 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:59885/test mt 2435 1.2 0.0 7708 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:16589/test mt 2439 0.5 0.0 7712 1264 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:52152/test mt 2443 1.0 0.0 7712 1260 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:52485/test mt 2447 1.0 0.0 7712 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:47785/test mt 2451 1.5 0.0 7708 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:47341/test mt 2455 0.7 0.0 7708 1256 pts/0 S+ 04:53 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:56161/test mt 2459 90.2 0.0 7584 1148 pts/0 R+ 04:53 0:03 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:4292/test mt 2653 0.4 0.0 7708 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:42335/test mt 2657 0.4 0.0 7712 1264 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:55211/test mt 2661 0.4 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:11026/test mt 2665 0.4 0.0 7708 1256 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:49709/test mt 2669 0.4 0.0 7708 1256 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:29708/test mt 2673 0.4 0.0 7708 1256 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:18744/test mt 2677 0.2 0.0 7712 1252 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:4189/test mt 2681 0.4 0.0 7712 1264 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:43829/test mt 2685 0.2 0.0 7712 1264 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:52841/test mt 2689 0.5 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:37863/test mt 2693 0.5 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:18338/test mt 2697 0.2 0.0 7708 1256 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:31492/test mt 2701 0.2 0.0 7708 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:37513/test mt 2705 0.5 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:43648/test mt 2709 0.5 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:58518/test mt 2713 0.2 0.0 7708 1256 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:49463/test mt 2717 0.7 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:39673/test mt 2721 0.2 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:6324/test mt 2725 0.2 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:31094/test mt 2729 0.5 0.0 7708 1252 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:52132/test mt 2733 0.2 0.0 7712 1256 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:59113/test mt 2737 0.5 0.0 7712 1264 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:11684/test mt 2741 0.5 0.0 7708 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:25164/test mt 2745 0.2 0.0 7712 1264 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:24016/test mt 2749 0.2 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:12952/test mt 2753 0.7 0.0 7708 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:18726/test mt 2757 0.5 0.0 7712 1264 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:5380/test mt 2761 0.2 0.0 7712 1256 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:24411/test mt 2765 0.2 0.0 7712 1260 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:16271/test mt 2769 0.7 0.0 7712 1264 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:60321/test mt 2773 0.6 0.0 7712 1264 pts/0 S+ 04:55 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:63052/test mt 2777 95.0 0.0 7584 1148 pts/0 R+ 04:55 0:02 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:18769/test The last two is when running 32 instances. The following is when running 36 instances: mt 3580 0.3 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:19701/test mt 3584 1.0 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:8559/test mt 3588 0.5 0.0 7712 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:34120/test mt 3592 0.6 0.0 7712 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:13121/test mt 3596 0.8 0.0 7712 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:14770/test mt 3600 0.6 0.0 7712 1264 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:30675/test mt 3604 0.6 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:40455/test mt 3608 0.6 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:45766/test mt 3612 0.8 0.0 7712 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:29900/test mt 3616 1.0 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:33734/test mt 3620 0.8 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:13557/test mt 3624 0.6 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:3390/test mt 3628 0.6 0.0 7712 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:60172/test mt 3632 0.8 0.0 7712 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:28942/test mt 3636 1.1 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:46137/test mt 3640 0.5 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:22724/test mt 3644 1.0 0.0 7712 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:45092/test mt 3648 0.8 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:23933/test mt 3652 1.0 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:1793/test mt 3656 0.6 0.0 7712 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:8811/test mt 3660 1.0 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:42799/test mt 3664 1.4 0.0 7712 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:30680/test mt 3668 0.6 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:65038/test mt 3672 1.6 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:56001/test mt 3676 1.0 0.0 7712 1264 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:22071/test mt 3680 1.2 0.0 7712 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:20123/test mt 3684 0.4 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:39937/test mt 3688 1.2 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:6393/test mt 3692 1.4 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:48283/test mt 3696 1.0 0.0 7712 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:33740/test mt 3700 0.8 0.0 7712 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:36566/test mt 3704 2.2 0.0 7712 1252 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:55543/test mt 3708 3.4 0.0 7708 1260 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:27525/test mt 3712 0.6 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:37965/test mt 3717 0.6 0.0 7708 1256 pts/0 S+ 04:58 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:17433/test mt 3721 84.2 0.0 7584 1152 pts/0 R+ 04:58 0:03 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:58968/test Just to show that it is not allways the last spawed instance that crashes: mt 4079 0.4 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:12677/test mt 4083 0.4 0.0 7712 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:11143/test mt 4087 0.8 0.0 7712 1264 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:35927/test mt 4091 0.5 0.0 7712 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:36827/test mt 4095 0.5 0.0 7708 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:38474/test mt 4099 0.8 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:36485/test mt 4103 0.6 0.0 7712 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:53506/test mt 4107 0.6 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:43803/test mt 4111 0.2 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:62285/test mt 4115 0.4 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:40644/test mt 4119 0.5 0.0 7712 1264 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:17821/test mt 4123 0.3 0.0 7708 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:19737/test mt 4127 0.6 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:36281/test mt 4131 0.7 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:58183/test mt 4135 0.6 0.0 7712 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:28540/test mt 4139 0.5 0.0 7708 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:48256/test mt 4143 0.6 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:12372/test mt 4147 0.5 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:46237/test mt 4151 0.4 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:1155/test mt 4155 0.7 0.0 7712 1264 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:16354/test mt 4159 1.0 0.0 7708 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:14622/test mt 4163 1.0 0.0 7708 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:4048/test mt 4167 0.6 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:53274/test mt 4171 0.5 0.0 7708 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:28029/test mt 4175 0.7 0.0 7712 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:7066/test mt 4179 0.8 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:9035/test mt 4183 0.6 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:31896/test mt 4187 0.8 0.0 7712 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:27972/test mt 4191 0.6 0.0 7712 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:4945/test mt 4195 0.3 0.0 7712 1264 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:53198/test mt 4199 0.8 0.0 7712 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:37152/test mt 4203 4.1 0.0 7708 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:56146/test mt 4207 0.5 0.0 7708 1260 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:17086/test mt 4211 0.7 0.0 7708 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:13065/test mt 4215 80.3 0.0 7580 1148 pts/0 R+ 05:00 0:06 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:23968/test mt 4219 0.3 0.0 7712 1256 pts/0 S+ 05:00 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:2395/test mt 4444 0.2 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:54427/test mt 4448 0.5 0.0 7712 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:36333/test mt 4452 0.2 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:42537/test mt 4456 0.5 0.0 7712 1264 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:5617/test mt 4460 0.2 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:65533/test mt 4464 0.5 0.0 7712 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:3179/test mt 4468 0.5 0.0 7712 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:35069/test mt 4472 0.5 0.0 7712 1264 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:34098/test mt 4476 0.7 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:14348/test mt 4480 0.7 0.0 7712 1264 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:60991/test mt 4484 1.0 0.0 7712 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:54749/test mt 4488 1.0 0.0 7712 1264 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:49684/test mt 4492 1.3 0.0 7712 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:47274/test mt 4496 0.6 0.0 7712 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:64707/test mt 4500 0.6 0.0 7712 1264 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:17401/test mt 4504 0.3 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:19447/test mt 4508 1.0 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:15503/test mt 4512 0.6 0.0 7708 1252 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:49044/test mt 4516 1.0 0.0 7708 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:8465/test mt 4520 0.6 0.0 7708 1252 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:20504/test mt 4524 0.6 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:60290/test mt 4528 0.6 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:47538/test mt 4532 0.6 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:63574/test mt 4536 1.0 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:13516/test mt 4540 0.6 0.0 7708 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:61854/test mt 4544 0.6 0.0 7712 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:64414/test mt 4548 1.0 0.0 7712 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:41141/test mt 4552 1.3 0.0 7708 1252 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:38540/test mt 4556 0.3 0.0 7708 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:40004/test mt 4560 0.6 0.0 7712 1252 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:23057/test mt 4564 1.0 0.0 7712 1252 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:26355/test mt 4568 3.6 0.0 7708 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:63377/test mt 4572 94.0 0.0 7580 1152 pts/0 R+ 05:01 0:01 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:36356/test mt 4576 0.5 0.0 7712 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:49026/test mt 4580 1.0 0.0 7708 1256 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:4392/test mt 4584 0.5 0.0 7712 1260 pts/0 S+ 05:01 0:00 openRTSP -v -E 2 -e 10 rtsp://10.0.0.20:59680/test I am going to continue searching, but any hints that could lead to a solution to this would be much appreciated. Best regards -Morgan- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061029/5a81d89b/attachment-0001.html From finlayson at live555.com Sun Oct 29 14:24:56 2006 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 29 Oct 2006 14:24:56 -0800 Subject: [Live-devel] Strange problem when spawning multiple instances of Live555 programs In-Reply-To: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> References: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> Message-ID: >I have made one program that accepts data on a socket, and >retransmits it on a RTSP socket (sort of like >testOnDemandRTSPServer, but with socket input instead of a file) Be sure to set the "reuseFirstSource" parameter to "True" when creating each "ServerMediaSubsession" object. >Everything works fine as long as I spawn no more than 25 >server/client pairs. If I go above that, say 40, one of the programs >(sometimes openRTSP, other times the server) starts hogging CPU >power. I suspect you're running into some internal OS limit here - e.g., maximum number of sockets or open files. If so, then this may be something that you can reconfigure. Apart from this, I don't have anything else to suggest right now, unfortunately. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dbikash at gmail.com Sun Oct 29 22:39:17 2006 From: dbikash at gmail.com (Deeptendu Bikash) Date: Mon, 30 Oct 2006 12:09:17 +0530 Subject: [Live-devel] Strange problem when spawning multiple instances of Live555 programs In-Reply-To: References: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> Message-ID: <29758ec70610292239wf811317q232517a1269f294f@mail.gmail.com> We did such a test some time back. We reached a limit to the number of clients (a modification of openRTSP) at around 75. I guess we failed to close some file descriptors. Deeptendu On 10/30/06, Ross Finlayson wrote: > > >I have made one program that accepts data on a socket, and > >retransmits it on a RTSP socket (sort of like > >testOnDemandRTSPServer, but with socket input instead of a file) > > Be sure to set the "reuseFirstSource" parameter to "True" when > creating each "ServerMediaSubsession" object. > > >Everything works fine as long as I spawn no more than 25 > >server/client pairs. If I go above that, say 40, one of the programs > >(sometimes openRTSP, other times the server) starts hogging CPU > >power. > > I suspect you're running into some internal OS limit here - e.g., > maximum number of sockets or open files. If so, then this may be > something that you can reconfigure. > > Apart from this, I don't have anything else to suggest right now, > unfortunately. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061029/4b33189a/attachment.html From jeremy at electrosilk.net Sun Oct 29 22:43:02 2006 From: jeremy at electrosilk.net (Jeremy) Date: Mon, 30 Oct 2006 14:43:02 +0800 (WST) Subject: [Live-devel] Mask value in MPEG2TransportStreamMultiplexor ? In-Reply-To: References: Message-ID: <1202.202.189.68.42.1162190582.squirrel@mail.ardley.org> In MPEG2TransportStreamMultiplexor.cpp is the value 0xE0 in line 113 correct or should it be 0xF0? 00107 if (streamType == 0) { 00108 // Instead, set the stream's type to default values, based on whether 00109 // the stream is audio or video, and whether it's MPEG-1 or MPEG-2: 00110 if ((stream_id&0xF0) == 0xE0) { // video 00111 streamType = mpegVersion == 1 ? 1 : 2;00112 if (fPCR_PID == 0) fPCR_PID = fCurrentPID; // use this stream's SCR for PCR 00113 } else if ((stream_id&0xE0) == 0xC0) { // audio From finlayson at live555.com Mon Oct 30 00:05:59 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Oct 2006 00:05:59 -0800 Subject: [Live-devel] Mask value in MPEG2TransportStreamMultiplexor ? In-Reply-To: <1202.202.189.68.42.1162190582.squirrel@mail.ardley.org> References: <1202.202.189.68.42.1162190582.squirrel@mail.ardley.org> Message-ID: >In MPEG2TransportStreamMultiplexor.cpp is the value 0xE0 in line 113 >correct Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Mon Oct 30 01:19:00 2006 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 30 Oct 2006 13:19:00 +0400 Subject: [Live-devel] Strange problem when spawning multiple instances of Live555 programs In-Reply-To: References: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> Message-ID: <3cc3561f0610300119m119fb83dmdecc409ff82d81e3@mail.gmail.com> Hi Ross. Yes, I am setting reuseFirstSource to true. I do not believe that this problem is caused by a internal limit. The reason for my opinion is that if i run 40 or 50 instances, it is usually only one of them that fails. Even when running 100, no more than a few of the processes fail. What really has me wondering is the fact that it usually continues as soon as the other processes die. Now, after some more testing, I have maybe found a pattern. It seems everything works OK up until the 31. pair of server/openRTSP. it is always the 32. pair that fails. Sometimes when spawning a lot of threads at once, it is not the last pid, but always one of the last ones. Spawning one and one will always make sure that it is the 32. that fails. If I add another server/client pair, it is random if the new one fails, and the old failed one continues, or vica versa, but one starts/continues OK, and the other one fails. If I remove one of the pairs, then the hanging one starts, and everything runs fine. Since this happens in both the RTSPserver lookalike server of mine and the openRTSP, I have been trying to dig trough the live555 code see what I can find. Especially I have searched for uses of the bind command. I could not really understand why one would run bind on a client. In GroupsockHelper.cpp around line 520 there is a comment saying "// Hack - ....". I suspect that it is there that the bind call comes from on the openRTSP. The output: getsockname(4, {sa......... bind(4, {sa_family............ getsockname(4, {sa........ that you can see in my first mail (from strace), seems to concur with this thought, since getsockname is called before and after. After some searching I see that you use this function in RTSPServer.cpp and OnDemandServerMediaSubsession.cpp. It must be the last of those two that hangs since that is the only one with an infinite loop possibility (while(1) vs. while(0)), and that sort of makes sense the way I read the code. In OnDemandServerMediaSubsession.cpp you have a while (1) loop, grabbing a port with an even number (why you need an even number, I cannot guess). I expect there is some grace period on the uneven ports that you will have received and discarded which made the 31 first processes work nicely. What I suspect happens is that the OS figures "Wow, 31 ports taken but not in use. Free them now" when the 32. pair starts, making it so that it receives every odd port over and over. When a new pair arrives, they will interfere with each other and make one of them (the random part I talked about) able to get an even numbered port. This seems to continue until I go above 63 clients, when the "crash" and CPU-hogging happens to two processes. With a dual-core CPU, I am unable to take this any further, but I would be surprised if it does not happen at 95 and 127 also. What needs to be done to fix this is addressing the port number issue. One suggestion would be to try random ports with even numbers until you get one that is "vacant". Another to check the /proc/net/tcp and find a port that is free. That would be quite ugly though, and not very portable. It is not certain that any of my suggestions is any good of course, but something should be done with this issue as it will happen on all Linux systems, and quite possibly on other as well. If you want me to make a fix for it, I can do so, but I unfortunately have more urgent matters that needs to be addressed first and I do not have the time at the moment to do a lot of debugging and stability testing. It could therefor take some time before I get around to take care of it. I could of course be me that is totally wrong here, but I have been unable to find anything in the kernel that suggest that I can set a limit on these things. It seems to be a OS thing as you suggested though. Sorry for the long e-mail. I thought that giving alot of information would probably make it easier for you. Regards -Morgan T?rvolt- Btw, I had to think hard to understand the do{ ... } while(0) loop calling getSourcePort in RTSPServer.cpp. It seems to work like goto, only using break and a do-while loop instead. Below I have written something that is a bit more readable in my eyes. I threw it together in a hurry, and don't have the time to test it today unfortunately. Your decicion though. It is obvious that your code works well. ourSocket = setupStreamSocket(env, ourPort); if (ourSocket >= 0) { // Make sure we have a big send buffer: if (increaseSendBufferTo(env, ourSocket, 50*1024)) { // Allow multiple simultaneous connections: if (listen(ourSocket, LISTEN_BACKLOG_SIZE) >= 0) { if (ourPort.num() != 0) { return ourSocket; } else { // bind() will have chosen a port for us; return it also: if (!getSourcePort(env, ourSocket, ourPort)) break; } } else { env.setResultErrMsg("listen() failed: "); break; } } } On 30/10/06, Ross Finlayson wrote: > >I have made one program that accepts data on a socket, and > >retransmits it on a RTSP socket (sort of like > >testOnDemandRTSPServer, but with socket input instead of a file) > > Be sure to set the "reuseFirstSource" parameter to "True" when > creating each "ServerMediaSubsession" object. > > >Everything works fine as long as I spawn no more than 25 > >server/client pairs. If I go above that, say 40, one of the programs > >(sometimes openRTSP, other times the server) starts hogging CPU > >power. > > I suspect you're running into some internal OS limit here - e.g., > maximum number of sockets or open files. If so, then this may be > something that you can reconfigure. > > Apart from this, I don't have anything else to suggest right now, > unfortunately. > -- > > 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 morgan.torvolt at gmail.com Mon Oct 30 02:18:45 2006 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 30 Oct 2006 14:18:45 +0400 Subject: [Live-devel] Strange problem when spawning multiple instances of Live555 programs In-Reply-To: <29758ec70610292239wf811317q232517a1269f294f@mail.gmail.com> References: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> <29758ec70610292239wf811317q232517a1269f294f@mail.gmail.com> Message-ID: <3cc3561f0610300218j6338c98bs2375aa119e28c33a@mail.gmail.com> Hi. This could easily be the same issue as I am having. I get problems after starting 31 pairs of server+openRTSP. This is 62 instances of the live code. If your problems startet when having more than 64 clients, I believe that it probably was the same bug. -Morgan- On 30/10/06, Deeptendu Bikash wrote: > We did such a test some time back. We reached a limit to the number of > clients (a modification of openRTSP) at around 75. I guess we failed to > close some file descriptors. > > Deeptendu > > > > On 10/30/06, Ross Finlayson wrote: > > >I have made one program that accepts data on a socket, and > > >retransmits it on a RTSP socket (sort of like > > >testOnDemandRTSPServer, but with socket input instead of a file) > > > > Be sure to set the "reuseFirstSource" parameter to "True" when > > creating each "ServerMediaSubsession" object. > > > > >Everything works fine as long as I spawn no more than 25 > > >server/client pairs. If I go above that, say 40, one of the programs > > >(sometimes openRTSP, other times the server) starts hogging CPU > > >power. > > > > I suspect you're running into some internal OS limit here - e.g., > > maximum number of sockets or open files. If so, then this may be > > something that you can reconfigure. > > > > Apart from this, I don't have anything else to suggest right now, > > unfortunately. > > -- > > > > 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 > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > From finlayson at live555.com Mon Oct 30 02:37:40 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Oct 2006 02:37:40 -0800 Subject: [Live-devel] Strange problem when spawning multiple instances of Live555 programs In-Reply-To: <3cc3561f0610300119m119fb83dmdecc409ff82d81e3@mail.gmail.com> References: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> <3cc3561f0610300119m119fb83dmdecc409ff82d81e3@mail.gmail.com> Message-ID: >In OnDemandServerMediaSubsession.cpp you have a while (1) loop, >grabbing a port with an even number Not anymore! That code changed starting with version 2006.08.07 - i.e., more than 2 months ago. You should upgrade. Everybody - please: Upgrade to the latest version of the code before spending (wasting) a lot of time digging into alleged problems. > (why you need an even number, cannot guess). Because the RTP standard specifies that even port numbers should be used for RTP, with the next highest (and thus, odd) port number being used for RTCP. (Actually, this rule is not quite as manditory as it used to be, but it remains the default and usual behavior.) >What needs to be done to fix this is addressing the port number issue. Right now I'm not convinced that there is anything that needs to be 'fixed'. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From buscarini at gmail.com Mon Oct 30 03:06:18 2006 From: buscarini at gmail.com (Antonio Garcia) Date: Mon, 30 Oct 2006 12:06:18 +0100 Subject: [Live-devel] Problem trying to use libavcodec and live555 Message-ID: First I want to five thanks to everyone for their support. I have accomplished to pass data to MPEG1or2RTPSink, and VLC receives it, but it keeps waiting for a sequence start header, so it doesn't show anything. So, what I do is this: file -> ffmpeg -> MPEG1or2RTPSink > That can't possibly work, because "MPEG1or2VideoStreamFramer" (and > "MPEG1or2VideoRTPSink") expects to see *encoded* MPEG (1 or 2) video > data, not raw (decoded) video data. Sorry, I didn't explain it very well. In ffmpeg I only do a call to av_read_frame, which delivers an AVPacket with the data still encoded. This is the code I have: virtual void doGetNextFrame(){ fFrameSize = _frame.size; if (fFrameSize > fMaxSize) { fNumTruncatedBytes = fFrameSize - fMaxSize; fFrameSize = fMaxSize; } memmove(fTo,_frame.data,fFrameSize); fDurationInMicroseconds = _frame.duration; nextTask() = envir().taskScheduler().scheduleDelayedTask(0, (TaskFunc*)afterGetting,this); }; Sometimes liveMedia prints this warning: Warning: MPEG1or2VideoRTPSink::doSpecialFrameHandling saw strange first 4 bytes 0x531d050f, but we're not a fragment If I connect the ffmpeg with an MPEG1or2StreamFramer I receive nothing with VLC. So, anyone knows how to pass the video sequence start header from ffmpeg to liveMedia? Antonio Garc?a From morgan.torvolt at gmail.com Mon Oct 30 03:40:56 2006 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 30 Oct 2006 15:40:56 +0400 Subject: [Live-devel] Strange problem when spawning multiple instances of Live555 programs In-Reply-To: References: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> <3cc3561f0610300119m119fb83dmdecc409ff82d81e3@mail.gmail.com> Message-ID: <3cc3561f0610300340q197d39feld206ce989cf9c105@mail.gmail.com> Darn. I had the latest version, but I never checked the timestamps on the files. :-/ Changing a symbolic link fixed the problem *flush*. That was an easy fix. Thanks... -Morgan T?rvolt- On 30/10/06, Ross Finlayson wrote: > >In OnDemandServerMediaSubsession.cpp you have a while (1) loop, > >grabbing a port with an even number > > Not anymore! That code changed starting with version 2006.08.07 - > i.e., more than 2 months ago. You should upgrade. > > Everybody - please: Upgrade to the latest version of the code before > spending (wasting) a lot of time digging into alleged problems. > > > (why you need an even number, cannot guess). > > Because the RTP standard specifies that even port numbers should be > used for RTP, with the next highest (and thus, odd) port number being > used for RTCP. (Actually, this rule is not quite as manditory as it > used to be, but it remains the default and usual behavior.) > > >What needs to be done to fix this is addressing the port number issue. > > Right now I'm not convinced that there is anything that needs to be 'fixed'. > -- > > 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 shaswata at alumnux.com Mon Oct 30 03:53:22 2006 From: shaswata at alumnux.com (Shaswata Jash) Date: Mon, 30 Oct 2006 17:23:22 +0530 Subject: [Live-devel] Problem trying to use libavcodec and live555 References: Message-ID: <002d01c6fc19$ffc0df90$2e0aa8c0@NITU> If you are not using GLOBAL_HEADER flag in ffmpeg, then the seq-header must have come with the first frame. If that is not so, then you can find that header in AVCodecContext->extradata. With regards, Shaswata ----- Original Message ----- From: "Antonio Garcia" To: Sent: Monday, October 30, 2006 4:36 PM Subject: Re: [Live-devel] Problem trying to use libavcodec and live555 > First I want to five thanks to everyone for their support. > > I have accomplished to pass data to MPEG1or2RTPSink, and VLC receives > it, but it keeps waiting for a sequence start header, so it doesn't > show anything. > > So, what I do is this: > > file -> ffmpeg -> MPEG1or2RTPSink > > > That can't possibly work, because "MPEG1or2VideoStreamFramer" (and > > "MPEG1or2VideoRTPSink") expects to see *encoded* MPEG (1 or 2) video > > data, not raw (decoded) video data. > > Sorry, I didn't explain it very well. In ffmpeg I only do a call to > av_read_frame, which delivers an AVPacket with the data still encoded. > > This is the code I have: > > virtual void doGetNextFrame(){ > > fFrameSize = _frame.size; > if (fFrameSize > fMaxSize) { > fNumTruncatedBytes = fFrameSize - fMaxSize; > fFrameSize = fMaxSize; > } > > memmove(fTo,_frame.data,fFrameSize); > > > fDurationInMicroseconds = _frame.duration; > > > nextTask() = envir().taskScheduler().scheduleDelayedTask(0, > (TaskFunc*)afterGetting,this); > > }; > > Sometimes liveMedia prints this warning: > > Warning: MPEG1or2VideoRTPSink::doSpecialFrameHandling saw strange > first 4 bytes 0x531d050f, but we're not a fragment > > > If I connect the ffmpeg with an MPEG1or2StreamFramer I receive > nothing with VLC. > > So, anyone knows how to pass the video sequence start header from > ffmpeg to liveMedia? > > Antonio Garc?a > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From xcsmith at rockwellcollins.com Mon Oct 30 08:20:31 2006 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 30 Oct 2006 10:20:31 -0600 Subject: [Live-devel] LIVE version control Message-ID: Can you tell me anything about what sort of inspection, testing, and approval patches go through before they become an official part of the LIVE555 library? I am a somewhat new programmer, and I am having trouble convincing my higher ups to allow me to keep the library up to date. They seem to believe that every LIVE release is considered an "unstable" version, and so are reluctant to upgrade. In the meanwhile, I see patches and updates going by on the mail list for classes that we use, but I don't understand the problems well enough to decide whether or not the patches affect us nor how necessary they are. The latest version we've acquired is 2006.08.26. Which I think might be the one right before there were some changes related to asynchronous/synchronous reading. From finlayson at live555.com Mon Oct 30 08:36:05 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Oct 2006 08:36:05 -0800 Subject: [Live-devel] LIVE version control In-Reply-To: References: Message-ID: You can read the changelog for the libraries at . In general, support is provided for the latest version of the code only. -- 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/20061030/a5b17501/attachment.html From marthi at graphics.cs.uni-sb.de Mon Oct 30 10:14:09 2006 From: marthi at graphics.cs.uni-sb.de (Martin) Date: Mon, 30 Oct 2006 19:14:09 +0100 Subject: [Live-devel] Problems with Streaming of AMR Message-ID: <454640F1.9040904@graphics.cs.uni-sb.de> Hi, I'm trying to stream AMR which is encoded by the ffmpeg-library with liblive but I'm having problems. Streaming of MP3, alaw and u-law are working well. But with AMR the doGetNextFrame() of my class MyFramedSource which is derived from FramedSource is not executed. The relevant code looks like this: // Init UsageEnvironment and Groupsock rtp_sink = AMRAudioRTPSink::createNew(env, rtp_sock, 97); MyFramedSource* my_framed_source = MyFramedSource::createNew(env); RTCPInstance::createNew(*env, &rtcpGroupsock, bandwidth, CNAME, rtp_sink, NULL)); // play // start doEventLoop Is there something special I have to consider when using AMR? Thanks for helping! Martin From zemariamm at gmail.com Mon Oct 30 10:49:01 2006 From: zemariamm at gmail.com (Ze maria) Date: Mon, 30 Oct 2006 18:49:01 +0000 Subject: [Live-devel] Problem compiling VLC for wince Message-ID: Hi there, I saw the post: http://lists.live555.com/pipermail/live-devel/2005-January/001934.html I need to compile live555 lib and the openRTSP client for wince, I've tried to compile VLC (in ubuntu) but I was unsucessfull Can someone tell me where to start ? (or send me the reply to *Moretzky Sarit* post) Tks in advance Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061030/00662e98/attachment.html From finlayson at live555.com Mon Oct 30 10:54:12 2006 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 30 Oct 2006 10:54:12 -0800 Subject: [Live-devel] Problems with Streaming of AMR In-Reply-To: <454640F1.9040904@graphics.cs.uni-sb.de> References: <454640F1.9040904@graphics.cs.uni-sb.de> Message-ID: >Is there something special I have to consider when using AMR? Yes, when delivering data to an "AMRAudioRTPSink": 1/ The input source must be an "AMRAudioSource" (usually a subclass of this), and 2/ Each input frame must include the 1-byte AMR header (at the beginning). If I recall correctly, the FFMPEG AMR encoding software doesn't include this header, by default. In any case, I suggest looking at the "wis-streamer" code: , because it includes a software AMR audio encoder (using the FFMPEG code). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Tue Oct 31 02:41:18 2006 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Tue, 31 Oct 2006 14:41:18 +0400 Subject: [Live-devel] Strange problem when spawning multiple instances of Live555 programs In-Reply-To: <3cc3561f0610300340q197d39feld206ce989cf9c105@mail.gmail.com> References: <3cc3561f0610291321l5b233d3dq954e0a1e13fdf627@mail.gmail.com> <3cc3561f0610300119m119fb83dmdecc409ff82d81e3@mail.gmail.com> <3cc3561f0610300340q197d39feld206ce989cf9c105@mail.gmail.com> Message-ID: <3cc3561f0610310241p71c98277r75075a75736cfea8@mail.gmail.com> Hi again. I now seem to have another problem. Running the testOnDemandRTSPserver with .ts or .mpg files makes it use all cpu power. A quick profiling suggests that there is something in the BasicTaskScheduler that is doing this: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 19.79 0.57 0.57 BasicTaskScheduler::SingleStep(unsigned int) 10.42 0.87 0.30 HandlerSet::~HandlerSet() 9.72 1.15 0.28 BasicTaskScheduler::turnOffBackgroundReadHandling(int) 6.94 1.35 0.20 DelayQueue::synchronize() 6.94 1.55 0.20 DelayQueue::removeEntry(long) 6.25 1.73 0.18 DelayQueue::handleAlarm() 5.90 1.90 0.17 DelayQueue::~DelayQueue() 4.51 2.03 0.13 Timeval::operator>=(Timeval const&) const 4.17 2.15 0.12 TimeNow() 3.13 2.24 0.09 operator*(short, DelayInterval const&) 2.78 2.32 0.08 DelayQueue::~DelayQueue() 2.43 2.39 0.07 TransportStreamAnalyze::maskTables(unsigned int) 1.39 2.43 0.04 BasicTaskScheduler::createNew() 1.39 2.47 0.04 BasicTaskScheduler0::scheduleDelayedTask(long, void (*)(void*), void*) 1.39 2.51 0.04 TransportStreamAnalyzeTS::analyze(unsigned char const*) 1.39 2.55 0.04 TransportStreamAnalyzePID::parsePESHeader(unsigned char const*, unsigned int&) 1.39 2.59 0.04 __gnu_cxx::slist >::end() 1.04 2.62 0.03 DelayQueue::findEntryByToken(long) 0.69 2.64 0.02 BasicTaskScheduler::BasicTaskScheduler() This does of course effect all applications that use the Live555 TaskScheduler. Can anyone confirm this? I find it strange that noone has noticed this before. -Morgan- On 30/10/06, Morgan T?rvolt < morgan.torvolt at gmail.com> wrote: > Darn. I had the latest version, but I never checked the timestamps on > the files. :-/ > > Changing a symbolic link fixed the problem *flush*. That was an easy fix. > > Thanks... > > -Morgan T?rvolt- > > On 30/10/06, Ross Finlayson < finlayson at live555.com> wrote: > > >In OnDemandServerMediaSubsession.cpp you have a while (1) loop, > > >grabbing a port with an even number > > > > Not anymore! That code changed starting with version 2006.08.07 - > > i.e., more than 2 months ago. You should upgrade. > > > > Everybody - please: Upgrade to the latest version of the code before > > spending (wasting) a lot of time digging into alleged problems. > > > > > (why you need an even number, cannot guess). > > > > Because the RTP standard specifies that even port numbers should be > > used for RTP, with the next highest (and thus, odd) port number being > > used for RTCP. (Actually, this rule is not quite as manditory as it > > used to be, but it remains the default and usual behavior.) > > > > >What needs to be done to fix this is addressing the port number issue. > > > > Right now I'm not convinced that there is anything that needs to be 'fixed'. > > -- > > > > Ross Finlayson > > Live Networks, Inc. > > http://www.live555.com/ > > _______________________________________________ > > live-devel mailing list > > live-devel at lists.live555.com > > http://lists.live555.com/mailman/listinfo/live-devel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061031/c3829621/attachment-0001.html From dermot at dspsrv.com Tue Oct 31 02:43:31 2006 From: dermot at dspsrv.com (Dermot McGahon) Date: Tue, 31 Oct 2006 10:43:31 +0000 Subject: [Live-devel] LIVE version control In-Reply-To: References: Message-ID: <454728D3.7030509@dspsrv.com> xcsmith at rockwellcollins.com wrote: > Can you tell me anything about what sort of inspection, testing, and > approval patches go through before they become an official part of the > LIVE555 library? Realistically you will have to reverse this line of thinking. Could you set up inspection, testing and approval processes in your organisation that satisfy the people you report to? Even if Ross gave a detailed answer to your question how would it assure you that the software is suitable for your particular requirements? I think you need to either go on trust or create some acceptance criteria on your side and test/upgrade as often as can be justified by the business. If it's any help, they are wrong to think that the latest version of Live555 is unstable. That would only be the case if there was significant new development going on which is not the case. It's my understanding that new development is often customer driven and well tested before being rolled in to the free releases. But again, how could any of this satisfy your organisation without you doing the testing yourself? Dermot. From mas at daimi.au.dk Tue Oct 31 05:32:50 2006 From: mas at daimi.au.dk (Thomas Jakobsen) Date: Tue, 31 Oct 2006 14:32:50 +0100 Subject: [Live-devel] Support for security? Message-ID: <1162301570.4547508270ddd@webmail.daimi.au.dk> Hi I'm currently working in a research project in which we plan to do some prototyping regarding various multimedia setups based on NMM and liblive. In that regard, I have the following questions: 1) Does liblive currently support secure (encrypted and/or signed) multimedia transfer (eg support for SRTP)? 2) If not, are there any future plans for adding such features? Regards, Thomas Jakobsen From riwanda at yahoo.com Tue Oct 31 07:39:39 2006 From: riwanda at yahoo.com (Gunar Riwanda) Date: Tue, 31 Oct 2006 07:39:39 -0800 (PST) Subject: [Live-devel] can't decode file that is received by opentrsp Message-ID: <20061031153939.38838.qmail@web54602.mail.yahoo.com> hallo, I tried to receive a file using openrtsp(named test.avi) which was sent using testmpeg4videostreamer. I set the end time -e to 5 seconds (which the exact play time of test.avi). i added an extension the outputfile video-MP4V-ES-1 to video-MP4V-ES-1.avi i tried to decode the output file video-MP4V-ES-1.avi using ffmpeg library. but it didn't work. in other words, i can't decode it. Does anybody know why? thanks in advance, Gunar ps: i also notice that there is no summary properties available for video-MP4V-ES-1.avi nor video-MP4V-ES-1 (right click->properties->summary). It means also that the received file doesn't know its own data(framepersecond, height, width). Could it be the reason why i couldn't decode it (since my decoder needs those data.) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061031/c46ebd2a/attachment.html From finlayson at live555.com Tue Oct 31 07:52:32 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 31 Oct 2006 07:52:32 -0800 Subject: [Live-devel] can't decode file that is received by opentrsp In-Reply-To: <20061031153939.38838.qmail@web54602.mail.yahoo.com> References: <20061031153939.38838.qmail@web54602.mail.yahoo.com> Message-ID: >I tried to receive a file using openrtsp(named test.avi) which was >sent using testmpeg4videostreamer. >I set the end time -e to 5 seconds (which the exact play time of test.avi). > >i added an extension the outputfile video-MP4V-ES-1 to video-MP4V-ES-1.avi No, that won't work. To create an output file in "AVI" format, you must use the "-i" option. See . Note also that the "-i" option causes "openRTSP" to output to 'stdout'. (If 'stdout' means nothing to you, then you should not be using "openRTSP" :-) >ps: i also notice that there is no summary properties available for >video-MP4V-ES-1.avi nor video-MP4V-ES-1 (right >click->properties->summary). This is because it contains raw elementary stream data only. -- 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/20061031/6fa9a190/attachment.html From finlayson at live555.com Tue Oct 31 07:55:06 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 31 Oct 2006 07:55:06 -0800 Subject: [Live-devel] Support for security? In-Reply-To: <1162301570.4547508270ddd@webmail.daimi.au.dk> References: <1162301570.4547508270ddd@webmail.daimi.au.dk> Message-ID: >1) Does liblive currently support secure (encrypted and/or signed) multimedia >transfer (eg support for SRTP)? No. > >2) If not, are there any future plans for adding such features? Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From marthi at graphics.cs.uni-sb.de Tue Oct 31 07:57:41 2006 From: marthi at graphics.cs.uni-sb.de (Martin) Date: Tue, 31 Oct 2006 16:57:41 +0100 Subject: [Live-devel] Problems with Streaming of AMR In-Reply-To: References: <454640F1.9040904@graphics.cs.uni-sb.de> Message-ID: <45477275.5070500@graphics.cs.uni-sb.de> Hi, Ross Finlayson wrote: >>Is there something special I have to consider when using AMR? > > > Yes, when delivering data to an "AMRAudioRTPSink": > 1/ The input source must be an "AMRAudioSource" (usually a subclass > of this), and > 2/ Each input frame must include the 1-byte AMR header (at the > beginning). If I recall correctly, the FFMPEG AMR encoding software > doesn't include this header, by default. > > In any case, I suggest looking at the "wis-streamer" code: > , because it includes a > software AMR audio encoder (using the FFMPEG code). thanks a lot for your help! Now that I've used a subclass of AMRAudioSource the method doGetNextFrame() is called. Unfortunately I got a message on the receiver side from ffmpeg: [amr_nb @ 0xb45fc008]amr frame too short (12, should be 32) So as you suggested I looked into the wis-streamer code as well and included the part for the AMR-header: enum Mode ourAMRMode = MR122; // the only mode that we support fLastFrameHeader = toc_byte[ourAMRMode]; fNumTruncatedBytes = 0; But on the receiver side the frame is still to short: [amr_nb @ 0xb45fc008]amr frame too short (31, should be 32) Maybe I'm still missing something? Another thing that could be the problem is the following: As the AMR frames transmitted are not interleaved (because it is not supported) I used the RawAMRRTPSource rtp_source instead of AMRAudioSource. RTPSource* rtp_source = 0; AMRAudioSource* audio_source = AMRAudioRTPSource::createNew(env, rtp_sock, rtp_source, 97); // audio_source is not further used, instead rtp_source is used. Is it correct that I can use the rtp_source? What is the difference in these two? If I would use the audio_source, what is the purpose of rtp_source in this example? Thanks in advance for your help! Martin From finlayson at live555.com Tue Oct 31 10:34:58 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 31 Oct 2006 10:34:58 -0800 Subject: [Live-devel] Problems with Streaming of AMR In-Reply-To: <45477275.5070500@graphics.cs.uni-sb.de> References: <454640F1.9040904@graphics.cs.uni-sb.de> <45477275.5070500@graphics.cs.uni-sb.de> Message-ID: >So as you suggested I looked into the wis-streamer code as well and >included the part for the AMR-header: > >enum Mode ourAMRMode = MR122; // the only mode that we support >fLastFrameHeader = toc_byte[ourAMRMode]; >fNumTruncatedBytes = 0; > >But on the receiver side the frame is still to short: > >[amr_nb @ 0xb45fc008]amr frame too short (31, should be 32) > >Maybe I'm still missing something? You're probably forgetting - in your encoder - to adjust the returned frame size to allow for the extra 1-byte header. Search for "EncoderIncludeHeaderByte" in "AMREncoder/interf_enc.c" in the "wis-streamer" code, to see where I had to modify the existing FFMPEG code to do this. >Another thing that could be the problem is the following: As the AMR >frames transmitted are not interleaved (because it is not supported) I >used the RawAMRRTPSource rtp_source instead of AMRAudioSource. > >RTPSource* rtp_source = 0; >AMRAudioSource* audio_source = AMRAudioRTPSource::createNew(env, >rtp_sock, rtp_source, 97); >// audio_source is not further used, instead rtp_source is used. No, your receiving application must read from the object that's returned by "AMRAudioRTPSource::createNew()" - in your case, "audio_source". > >Is it correct that I can use the rtp_source? No (see above). >What is the difference in >these two? If I would use the audio_source, what is the purpose of >rtp_source in this example? "rtp_source" would then be used only for RTP-specific operations, *not* for reading from the incoming stream (you would use "audio_source" for this). For example, you would use "rtp_source" when creating your "RTCPInstance" object, which you should be doing, because you should be using RTCP (at both ends) as well as RTP. See, for example, the code in "MediaSession.cpp" that creates and uses a "AMRAudioRTPSource". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jerry.johns at nuvation.com Tue Oct 31 14:57:07 2006 From: jerry.johns at nuvation.com (Jerry Johns) Date: Tue, 31 Oct 2006 14:57:07 -0800 Subject: [Live-devel] RTCP APP Report Message-ID: <22F8D1FFED33654987DE9D447F74E5460B45@mailguy2.nuvation.com> Hello, I was wondering if livemedia supports sending custom APP RTCP control information back to the server? I wanted to stream video, and to send video specific control info back to the source >From my initial digups, it looks like it supports sending SR, RR reports, but not APP; in that case, if I add my own APP report, I just have to add extra report, and custom call it through RTCPInterface function? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20061031/1192166a/attachment.html From finlayson at live555.com Tue Oct 31 16:21:53 2006 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 31 Oct 2006 16:21:53 -0800 Subject: [Live-devel] RTCP APP Report In-Reply-To: <22F8D1FFED33654987DE9D447F74E5460B45@mailguy2.nuvation.com> References: <22F8D1FFED33654987DE9D447F74E5460B45@mailguy2.nuvation.com> Message-ID: >Hello, > I was wondering if livemedia supports sending custom APP >RTCP control information back to the server? No, not at present, although it should be quite easy to do this, by modifying "liveMedia/RTCP.cpp". -- 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/20061031/8de34725/attachment-0001.html