From finlayson at live555.com Fri Feb 1 02:14:20 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 01 Feb 2008 02:14:20 -0800 Subject: [Live-devel] MPEG2-TS: Error in Position Info In-Reply-To: References: Message-ID: <200802011023.m11ANsmd004940@ns.live555.com> >I am working with the vlc media player trying to play mpeg2-ts from an >RTSP source. Once the stream is initiated I find the position is not >available. After the debugging the problem a bit, it appears that >there may be a bug in the way the pcr info is captured from the ts and >computed.(MPEG2TransportStreamFramer.cpp) This is a VLC problem, and probably has nothing to do with our software. (Note, in particular, that VLC does not use our "MPEG2TransportStreamFramer" class at all.) Ross Finlayson Live Networks, Inc. (LIVE555.COM) From finlayson at live555.com Fri Feb 1 02:17:49 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 01 Feb 2008 02:17:49 -0800 Subject: [Live-devel] If my encoded data has special header and tailor.How to implement the parse. In-Reply-To: <293795498.1401401201833601317.JavaMail.coremail@yeahapp3.y eah.net> References: <293795498.1401401201833601317.JavaMail.coremail@yeahapp3.yeah.net> Message-ID: <200802011023.m11ANthU004975@ns.live555.com> >so if I want to stream this format element stream, what should I do? You can't (at least, not in any way that I can help you with) because this data format is completely non-standard, and is not supported by any of our classes, and will not be understandable by any standard receiver. Ross Finlayson Live Networks, Inc. (LIVE555.COM) From finlayson at live555.com Fri Feb 1 02:34:00 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 01 Feb 2008 02:34:00 -0800 Subject: [Live-devel] Packet Loss Problem In-Reply-To: References: Message-ID: <200802011037.m11Ab5Po027821@ns.live555.com> >I used the ??iperf?? to check the Bandwidth >between the PCs which have 3.8 Mbits/sec Your video codec is "MPV", which is MPEG-1 or 2 video. Many MPEG-1 or 2 video streams are close to, or greater than, 3.8 Mbits/second. Perhaps your network just doesn't have enough bandwidth for your stream? Ross Finlayson Live Networks, Inc. (LIVE555.COM) From roor0735-ml at yahoo.fr Fri Feb 1 04:15:29 2008 From: roor0735-ml at yahoo.fr (roor0735-ml at yahoo.fr) Date: Fri, 1 Feb 2008 13:15:29 +0100 (CET) Subject: [Live-devel] bug found and corrected Message-ID: <194041.99559.qm@web25911.mail.ukl.yahoo.com> Hi I try to stream MPEG2 TS DVB-T channel using your library (through the MediaPortal TV Server project) and I have problem with some particular channels. In VLC, I get a lot of "PTS out of range" messages, the video is choppy and most of the time stops. I have tested with the mediaServer application distributed with the library and the same problem occurs, so I think the problem comes from incompatibility between the streaming server and the TS recordings. I suspected that the problem comes from the way the PCR is broadcast inside the Transport stream. I have enabled the DEBUG_PCR in the MPEG2TransportStreamFramer.cpp file to check the evolution of time. As you can see, the packet duration estimation is not good and leads to a accumulate delays. I think the problem comes from the fact the PCR is not periodically announced in the Transport Stream. Sometimes, there is very few packets between two PCR announcements. In this case, the calculation made two estimate the packet duration (fTSPacketDurationEstimate) is not reliable. So I added a new test in MPEG2TransportStreamFramer::updateTSPacketDurationEstimate method in order to check there are enough packets between two packet duration estimation. With at least 20 packets, it seems the estimation converges to the right value and there is no more problem in VLC :) That's the code and my log in attached file. It would be better to add a new define value for the minimum number of packets that must be processed before re-estimating the packet duration. Thank you Romain void MPEG2TransportStreamFramer ::updateTSPacketDurationEstimate(unsigned char* pkt, double timeNow) { // Sanity check: Make sure we start with the sync byte: if (pkt[0] != TRANSPORT_SYNC_BYTE) { envir() << "Missing sync byte!\n"; return; } ++fTSPacketCount; // If this packet doesn't contain a PCR, then we're not interested in it: u_int8_t const adaptation_field_control = (pkt[3]&0x30)>>4; if (adaptation_field_control != 2 && adaptation_field_control != 3) return; // there's no adaptation_field u_int8_t const adaptation_field_length = pkt[4]; if (adaptation_field_length == 0) return; u_int8_t const discontinuity_indicator = pkt[5]&0x80; u_int8_t const pcrFlag = pkt[5]&0x10; if (pcrFlag == 0) return; // no PCR // There's a PCR. Get it, and the PID: u_int32_t pcrBaseHigh = (pkt[6]<<24)|(pkt[7]<<16)|(pkt[8]<<8)|pkt[9]; double clock = pcrBaseHigh/45000.0; if ((pkt[10]&0x80) != 0) clock += 1/90000.0; // add in low-bit (if set) unsigned short pcrExt = ((pkt[10]&0x01)<<8) | pkt[11]; clock += pcrExt/27000000.0; unsigned pid = ((pkt[1]&0x1F)<<8) | pkt[2]; // Check whether we already have a record of a PCR for this PID: PIDStatus* pidStatus = (PIDStatus*)(fPIDStatusTable->Lookup((char*)pid)); if (pidStatus == NULL) { // We're seeing this PID's PCR for the first time: pidStatus = new PIDStatus(clock, timeNow); fPIDStatusTable->Add((char*)pid, pidStatus); #ifdef DEBUG_PCR fprintf(stderr, "PID 0x%x, FIRST PCR 0x%08x+%d:%03x == %f @ %f, pkt #%lu\n", pid, pcrBaseHigh, pkt[10]>>7, pcrExt, clock, timeNow, fTSPacketCount); #endif } else { // We've seen this PID's PCR before; update our per-packet duration estimate: double durationPerPacket = (clock - pidStatus->lastClock)/(fTSPacketCount - pidStatus->lastPacketNum); ==> if (fTSPacketCount - pidStatus->lastPacketNum<=20) // The new test ==> return; if (fTSPacketDurationEstimate == 0.0) { // we've just started fTSPacketDurationEstimate = durationPerPacket; } else if (discontinuity_indicator == 0 && durationPerPacket >= 0.0) { fTSPacketDurationEstimate = durationPerPacket*NEW_DURATION_WEIGHT + fTSPacketDurationEstimate*(1-NEW_DURATION_WEIGHT); // Also adjust the duration estimate to try to ensure that the transmission // rate matches the playout rate: double transmitDuration = timeNow - pidStatus->firstRealTime; double playoutDuration = clock - pidStatus->firstClock; if (transmitDuration > playoutDuration) { fTSPacketDurationEstimate *= TIME_ADJUSTMENT_FACTOR; // reduce estimate } else if (transmitDuration + MAX_PLAYOUT_BUFFER_DURATION < playoutDuration) { fTSPacketDurationEstimate /= TIME_ADJUSTMENT_FACTOR; // increase estimate } } else { // the PCR has a discontinuity from its previous value; don't use it now, // but reset our PCR and real-time values to compensate: pidStatus->firstClock = clock; pidStatus->firstRealTime = timeNow; } #ifdef DEBUG_PCR fprintf(stderr, "PID 0x%x, PCR 0x%08x+%d:%03x == %f @ %f (diffs %f @ %f), pkt #%lu, discon %d => this duration %f, new estimate %f\n", pid, pcrBaseHigh, pkt[10]>>7, pcrExt, clock, timeNow, clock - pidStatus->firstClock, timeNow - pidStatus->firstRealTime, fTSPacketCount, discontinuity_indicator != 0, durationPerPacket, fTSPacketDurationEstimate); #endif } pidStatus->lastClock = clock; pidStatus->lastRealTime = timeNow; pidStatus->lastPacketNum = fTSPacketCount; } --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080201/8423b140/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: log.zip Type: application/x-zip-compressed Size: 4642 bytes Desc: 2822840594-log.zip Url : http://lists.live555.com/pipermail/live-devel/attachments/20080201/8423b140/attachment.bin From belloni at imavis.com Fri Feb 1 06:44:52 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Fri, 01 Feb 2008 15:44:52 +0100 Subject: [Live-devel] MPEG4ESVideoRTPSource: Two frames at the price of one packet! Message-ID: <47A33064.2030205@imavis.com> Hi to all, I'm implementing my MPEG4ESVideoRTPSource for a clients who gets non-standard MPEG4 data. The problem is: packets are mixed. That is, when in a RTP packet a MPEG4 frame finishes, immediately after (in the same packet) the next frame starts. Here's a schema of how it works: |___frame_n_end_packet__|____frame_n+1_start_packet________| (hope the mail clients won't mess up the ASCII schema) I resolve the problem with a memory buffer. Sometimes, rarely but constantly, I get a packet made of the ending part of a frame in the first part, then a *complete* frame in the second part: |___frame_n_end_packet______|____complete_frame_n+1_____| When I'm in these conditions, my own processSpecialHeader method has *two* frames on its hands, but can return only *one*. Is there a way to make processSpecialHeader return more than one frame? And if it's not, is there a way to stuff some special data in the frame that will be read from my custom sink, so that the sink could tell it's two frames instead of one and divide them accordingly? Thank you very much, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From finlayson at live555.com Fri Feb 1 07:11:08 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 01 Feb 2008 07:11:08 -0800 Subject: [Live-devel] MPEG4ESVideoRTPSource: Two frames at the price of one packet! In-Reply-To: <47A33064.2030205@imavis.com> References: <47A33064.2030205@imavis.com> Message-ID: <200802011511.m11FBNnT005437@ns.live555.com> At 06:44 AM 2/1/2008, you wrote: >Hi to all, I'm implementing my MPEG4ESVideoRTPSource for a clients who >gets non-standard MPEG4 data. We've been here before. If you are trying to stream a non-standard RTP payload format, then you 're not going to get any help from me. Sorry. Ross Finlayson Live Networks, Inc. (LIVE555.COM) From belloni at imavis.com Fri Feb 1 07:25:04 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Fri, 01 Feb 2008 16:25:04 +0100 Subject: [Live-devel] MPEG4ESVideoRTPSource: Two frames at the price of one packet! In-Reply-To: <200802011511.m11FBNnT005437@ns.live555.com> References: <47A33064.2030205@imavis.com> <200802011511.m11FBNnT005437@ns.live555.com> Message-ID: <47A339D0.6050902@imavis.com> Ross Finlayson wrote: > We've been here before. > > If you are trying to stream a non-standard RTP payload format, then > you 're not going to get any help from me. Sorry. > Why? sounds like it's a sin :) Besides, I'm not trying to stream anything, I'm trying to decode a non standard stream from a non standard camera on the market. I'd really like if the camera was standard compliant, believe me, but it isn't, and i can't change it. By the way, I just asked info about the library behaviour: if it was possible to return two frames at once, or to add "out of band" data to a frame. Thanks anyway, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From finlayson at live555.com Fri Feb 1 13:56:26 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 01 Feb 2008 13:56:26 -0800 Subject: [Live-devel] bug found and corrected In-Reply-To: <194041.99559.qm@web25911.mail.ukl.yahoo.com> References: <194041.99559.qm@web25911.mail.ukl.yahoo.com> Message-ID: <200802012202.m11M205H024053@ns.live555.com> Thanks. However, the existing code is not really a 'bug', although your suggested change is (arguably) an improvement. As you noticed, the current per-transport-packet duration estimation code has trouble converging on a stable estimate for streams - such as yours - that are wildly VBR. Your suggested change will probably help things (although I can also imagine streams for which it might make things worse by taking longer to converge to the 'correct' average duration). I am also a bit concerned about the arbitrariness of the constant "20" that you use. Nonetheless, I'll add your change to the next release of the library. (Looking longer-term, a better solution for streaming prerecorded files (but not live streams) will be to extend the existing "index file" mechanism to include accurate durations - which could be computed in advance when generating the index file.) Ross Finlayson Live Networks, Inc. (LIVE555.COM) From finlayson at live555.com Fri Feb 1 14:04:03 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 01 Feb 2008 14:04:03 -0800 Subject: [Live-devel] MPEG4ESVideoRTPSource: Two frames at the price of one packet! In-Reply-To: <47A339D0.6050902@imavis.com> References: <47A33064.2030205@imavis.com> <200802011511.m11FBNnT005437@ns.live555.com> <47A339D0.6050902@imavis.com> Message-ID: <200802012205.m11M5gAG030423@ns.live555.com> > > We've been here before. > > > > If you are trying to stream a non-standard RTP payload format, then > > you 're not going to get any help from me. Sorry. > > > >Why? sounds like it's a sin :) No, not a sin - just a waste of my time. > I'm trying to decode a non >standard stream from a non standard camera on the market. I hope they go out of business soon. Ross Finlayson Live Networks, Inc. (LIVE555.COM) From vinodmenon2004 at gmail.com Fri Feb 1 23:08:47 2008 From: vinodmenon2004 at gmail.com (Vinod Menon) Date: Sat, 2 Feb 2008 02:08:47 -0500 Subject: [Live-devel] MPEG2-TS: Error in Position Info Message-ID: Ross, Is there any doc/info on how the position info is computed from the transport stream in live555. Btw fyi, I did use a debugger to find that the MPEG2TransportStreamFramer.cpp is used by VLC for RTSP/mpeg2-ts sessions Thanks, -V From finlayson at live555.com Fri Feb 1 23:20:55 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 01 Feb 2008 23:20:55 -0800 Subject: [Live-devel] MPEG2-TS: Error in Position Info In-Reply-To: References: Message-ID: <200802020728.m127SFAq006982@ns.live555.com> >Is there any doc/info on how the position info is computed from the >transport stream in live555. I don't know what you mean by "position info". > Btw fyi, I did use a debugger to find >that the MPEG2TransportStreamFramer.cpp is used by VLC for >RTSP/mpeg2-ts sessions You are mistaken. VLC (when used as a RTSP client) uses the code in the "modules/demux/live555.cpp" file to interface with the "LIVE555 Streaming Media" libraries. That code does not use "MPEG2TransportStreamFramer" at all. Instead, VLC uses its own decoding code to parse the MPEG Transport Stream data (for PCR timestamps, etc.). Ross Finlayson Live Networks, Inc. (LIVE555.COM) From jnitin at ssdi.sharp.co.in Mon Feb 4 03:01:17 2008 From: jnitin at ssdi.sharp.co.in (Nitin Jain) Date: Mon, 4 Feb 2008 16:31:17 +0530 Subject: [Live-devel] mp4 file format Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB56334B@KABEX01.sharpamericas.com> Hi all, I want to stream mp4 file which can contains mpeg4 or mpeg2 elementry stream data from live555 media server. My understanding is that I need to extract the mpeg2 or mpeg4 data and feed it to the corresponding mpeg2 or mpeg4 RTP sink.For this purpose I need to write a demultiplexer class which will come before respective video sink. Please provide suggestions on this. Thanks and Regards Nitin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080204/61193eff/attachment.html From eric.pheatt at gmail.com Mon Feb 4 13:28:48 2008 From: eric.pheatt at gmail.com (Eric Pheatt) Date: Mon, 4 Feb 2008 13:28:48 -0800 Subject: [Live-devel] Mpeg Audio missing or corrupted in MPEG-2 Transport Stream or seperate sreams In-Reply-To: <56ad9b8c0801301335y2b0b2efem2b822df0607c629c@mail.gmail.com> References: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> <56ad9b8c0712161544wc1e25cap39be550d73795628@mail.gmail.com> <56ad9b8c0712171609g6b9c62cck8192ee68669c417b@mail.gmail.com> <56ad9b8c0801281729q299ec874v547040ee6cd5ecd0@mail.gmail.com> <200801290533.m0T5XwkV032751@ns.live555.com> <56ad9b8c0801301335y2b0b2efem2b822df0607c629c@mail.gmail.com> Message-ID: <56ad9b8c0802041328y224d6088kba9904cbfc4654b4@mail.gmail.com> Sucess! Attached is a patch of the changes I made to wis-streamer to get mpegaudio encoded for me in addition to raw pcm and ulaw. In the patch I: added a define for WORDS_BIGENDIAN in bswap.h changed the define for PCM_AUDIO_IS_LITTLE_ENDIAN to 0 in Options.hh changed the arg for alsa initialization from AFMT_S16_LE to AFMT_S16_BE in WISInput.cpp changed the audio device scan to use the same logic as gorecord from the wis SDK. Since all of this is hardcoded, this patch won't work for anyone but PowerPC Big-Endian users. What do you suggest is the best route for determining these settings dynamically so this can be included in your source? Thanks, Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: wis-streamer-powerpc.patch Type: application/octet-stream Size: 1861 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20080204/87b5f343/attachment.obj From chenyingcn at hotmail.com Tue Feb 5 01:31:06 2008 From: chenyingcn at hotmail.com (ChenYing) Date: Tue, 5 Feb 2008 17:31:06 +0800 Subject: [Live-devel] About RTSPOverHTTPServer Message-ID: hi, I am a newer to livemedia. I read the RTSPOverHTTPServer.cpp, and found some of the code are masked, does the rtsp-over-http function not completed yet? Thanks. araluni _________________________________________________________________ ????? MSN ?????????? http://mobile.msn.com.cn/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080205/c980c200/attachment.html From erwan.miry at gmail.com Tue Feb 5 06:20:49 2008 From: erwan.miry at gmail.com (Erwan Miry) Date: Tue, 5 Feb 2008 09:20:49 -0500 Subject: [Live-devel] streaming data not contained in a file In-Reply-To: <200801311606.m0VG69sC086365@ns.live555.com> References: <809816cb0801310517o7c185159s3a863e0369340ada@mail.gmail.com> <200801311606.m0VG69sC086365@ns.live555.com> Message-ID: <809816cb0802050620p390ab5c3h81811c3919ba31ea@mail.gmail.com> Hi Ross, First of all, thank you for your quick responses! 2008/1/31, Ross Finlayson : > > >I need to transmit data > > What kind of data is this? Well, for now it's not a media file like live555 stream usually, but a collection of media files (images, informations about those images, etc.) I receive in a buffer, with packet headers to delimit them. I understand live555 is used to stream audio or video files. But I have to stream JPEG too. So, my payload format is not a standard one for my buffer, but my questions are not are not about this. I managed to run the MP3 example, all works. I think I have to create my own classes for a RTP sink "myBufferSink", a RTP source "myBufferRTPsource" and a data source "myBufferSource". I understand well RTPSource and Sinkclasses, but I've got some difficulties with the Source classes (udp, fileSource, etc.). Depending on the source, it takes the next frame in it. But if my buffer has the good size for a RTP packet, do I need to implement myBufferSource class? I just have another question about jpeg streaming: is there an example like testMP3? Or do I have to make my own? Is there special difficulties with this streaming example? Is it because testJPEG is similar to another built example there's no JPEG test? Thanks for your response, and sorry if I didn't write you back earlier. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080205/bb5764ce/attachment.html From finlayson at live555.com Tue Feb 5 01:34:57 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Feb 2008 01:34:57 -0800 Subject: [Live-devel] About RTSPOverHTTPServer In-Reply-To: References: Message-ID: >hi, > I am a newer to livemedia. I read the RTSPOverHTTPServer.cpp, >and found some of the code are masked, does the rtsp-over-http >function not completed yet? No, it's still 'work in progress'. Please be patient; it will be available (and supported in the "LIVE555 Media Server") soon. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Feb 5 07:53:08 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Feb 2008 07:53:08 -0800 Subject: [Live-devel] streaming data not contained in a file In-Reply-To: <809816cb0802050620p390ab5c3h81811c3919ba31ea@mail.gmail.com> References: <809816cb0801310517o7c185159s3a863e0369340ada@mail.gmail.com> <200801311606.m0VG69sC086365@ns.live555.com> <809816cb0802050620p390ab5c3h81811c3919ba31ea@mail.gmail.com> Message-ID: > >I need to transmit data > >What kind of data is this? > >Well, for now it's not a media file like live555 stream usually, but >a collection of media files (images, informations about those >images, etc.) I receive in a buffer, with packet headers to delimit >them. >I understand live555 is used to stream audio or video files. But I >have to stream JPEG too. Well, if your data is JPEG, see . But if it's not JPEG, then you;'ll have to do something else. It's important to understand that RTP is not a protocol for streaming arbitrary, untyped data. It's a protocol for streaming specific types of media, and you have to know in advance what type of media you're streaming (because the details of the protocol vary depending on the particular media type). If you want to just stream arbitary, untyped data, then just use something like HTTP. -- 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/20080205/e7bc835c/attachment-0001.html From gbonneau at matrox.com Tue Feb 5 08:02:33 2008 From: gbonneau at matrox.com (Guy Bonneau) Date: Tue, 5 Feb 2008 11:02:33 -0500 Subject: [Live-devel] Timestamp gap in RTCP Report for MPEG1or2VideoStreamFramer Message-ID: <03c401c86810$84a65d80$8642a8c0@dorvalmatrox.matrox.com> I believe I might have ran into a design issue for the TimeStamp creation when MPEG1or2VideoStreamFramer is used. Here what I have found. I have checked the RTCP SR packets that are sent when I play a video Mpeg2 ES. I have used the sample application testMPEG1or2VideoStreamer. I have followed the RTP/RTCP packets that are sent when no client has synchronized through a RTSP session. The TimeStamp values computed in the RTCP SR packet have a gap that mismatch the Mpeg2 ES RTP timestamp packet. Here are the value computed by the library fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 sending REPORT fTimestampBase: 0xae0daf0d, tv: 683383.099932, RTP timestamp: 101919 Creating RTCP SR packet, SSRC is 0x6da5, NTP is : tv: 683383.099932, TimeStamp is: 101919 sending RTCP packet 80c80006 00006da5 83b4ebf7 199524c0 00018e1f 000000db 0003c76d 81ca0005 00006da5 010a7377 6f70742d 766f6970 00000000 schedule(1.015347->683384.121916) fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.235273, RTP timestamp: 24100 fTimestampBase: 0xae0daf0d, tv: 683382.235273, RTP timestamp: 24100 Obviously the TimeStamp value of the RTCP SR packet should be between 21097 and 24100. After looking in the code I have found that the first TimeStamp is initialized from the creation of the MPEG1or2VideoStreamFramer object when MPEGVideoStreamFramer::reset() is called. However there is gap between the time the MPEG1or2VideoStreamFramer object is created and the time it take from videoSink->startPlaying(...) to initiate the reading of the file through the ByteStreamFileSource object. This notwithstanding the delay that can be induced between the creation of MPEG1or2VideoStreamFramer and the calling of videoSink->startPlaying(...) and also the time it take for the operating system to open and begin reading the file itself. This will introduce a delay that will offset all TimeStamp of the RTP packets to be sent with the RTCP SR computed timestamp. I believe the timestamp should be created somewhere else. May be when the MPEG1or2VideoRTPSink send the first RTP packet. I have not checked but this problem is likely to occurs in other framer object if they use the same timestamp initialization methodology. Guy Bonneau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080205/7b450fd0/attachment.html From finlayson at live555.com Tue Feb 5 08:10:32 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Feb 2008 08:10:32 -0800 Subject: [Live-devel] Mpeg Audio missing or corrupted in MPEG-2 Transport Stream or seperate sreams In-Reply-To: <56ad9b8c0802041328y224d6088kba9904cbfc4654b4@mail.gmail.com> References: <56ad9b8c0712161329l7d74ae09g912ff4718037d4c5@mail.gmail.com> <56ad9b8c0712161544wc1e25cap39be550d73795628@mail.gmail.com> <56ad9b8c0712171609g6b9c62cck8192ee68669c417b@mail.gmail.com> <56ad9b8c0801281729q299ec874v547040ee6cd5ecd0@mail.gmail.com> <200801290533.m0T5XwkV032751@ns.live555.com> <56ad9b8c0801301335y2b0b2efem2b822df0607c629c@mail.gmail.com> <56ad9b8c0802041328y224d6088kba9904cbfc4654b4@mail.gmail.com> Message-ID: >What do you suggest is the best route for determining these settings >dynamically I don't know of a good way to do this. As far as I know, everyone who uses the "wis-streamer" software defines these statically for their particular target environment (e.g., using -D directives on the compiler command line, in the Makefiles). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Feb 5 08:32:28 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Feb 2008 08:32:28 -0800 Subject: [Live-devel] Timestamp gap in RTCP Report for MPEG1or2VideoStreamFramer In-Reply-To: <03c401c86810$84a65d80$8642a8c0@dorvalmatrox.matrox.com> References: <03c401c86810$84a65d80$8642a8c0@dorvalmatrox.matrox.com> Message-ID: >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >sending REPORT >fTimestampBase: 0xae0daf0d, tv: 683383.099932, RTP timestamp: 101919 >Creating RTCP SR packet, SSRC is 0x6da5, NTP is : tv: 683383.099932, >TimeStamp is: 101919 >sending RTCP packet > 80c80006 00006da5 83b4ebf7 199524c0 00018e1f 000000db 0003c76d >81ca0005 00006da5 010a7377 6f70742d 766f6970 00000000 >schedule(1.015347->683384.121916) >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 >fTimestampBase: 0xae0daf0d, tv: 683382.235273, RTP timestamp: 24100 >fTimestampBase: 0xae0daf0d, tv: 683382.235273, RTP timestamp: 24100 > >Obviously the TimeStamp value of the RTCP SR packet should be >between 21097 and 24100. No - because the 'NTP' time (683383.099932) that's used for the RTCP SR packet is not between 683382.201906 and 683382.235273. The RTP timestamp of 101919 corresponds to the time 683383.099932. It's perfectly OK for the NTP time that's used in a RTCP "SR" report to differ from the presentation time used in RTP packets that bracket it. However, because the RTCP SR 'NTP' time is computed using "gettimeofday()" (i.e., 'wall clock' time), the presentation times for your media samples (that get passed to RTP) *must* also be aligned with 'wall clock' time. The timestamp generation code (for both RTP and RTCP) is correct. However, for it to work correctly, you must feed it correct presentation times. -- 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/20080205/fa413030/attachment.html From aravind.account at gmail.com Tue Feb 5 09:13:05 2008 From: aravind.account at gmail.com (Aravind K) Date: Tue, 5 Feb 2008 12:13:05 -0500 Subject: [Live-devel] MP3 streaming Message-ID: I need to stream line-in information.I have converted the PCM samples to MP3 ,but how do I change the default "test.mp3 " in mp3streamer and what do I write instead of that ? thanks Aravind -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080205/f3303988/attachment.html From finlayson at live555.com Tue Feb 5 09:28:44 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Feb 2008 09:28:44 -0800 Subject: [Live-devel] MP3 streaming In-Reply-To: References: Message-ID: >I need to stream line-in information.I have converted the PCM >samples to MP3 ,but how do I change the default "test.mp3 " in >mp3streamer and what do I write instead of that ? Please read the FAQ. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gbonneau at matrox.com Tue Feb 5 10:05:34 2008 From: gbonneau at matrox.com (Guy Bonneau) Date: Tue, 5 Feb 2008 13:05:34 -0500 Subject: [Live-devel] Timestamp gap in RTCP Report for MPEG1or2VideoStreamFramer In-Reply-To: References: <03c401c86810$84a65d80$8642a8c0@dorvalmatrox.matrox.com> Message-ID: <001301c86821$b43c4f80$8642a8c0@dorvalmatrox.matrox.com> fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 sending REPORT fTimestampBase: 0xae0daf0d, tv: 683383.099932, RTP timestamp: 101919 Creating RTCP SR packet, SSRC is 0x6da5, NTP is : tv: 683383.099932, TimeStamp is: 101919 sending RTCP packet 80c80006 00006da5 83b4ebf7 199524c0 00018e1f 000000db 0003c76d 81ca0005 00006da5 010a7377 6f70742d 766f6970 00000000 schedule(1.015347->683384.121916) fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.201906, RTP timestamp: 21097 fTimestampBase: 0xae0daf0d, tv: 683382.235273, RTP timestamp: 24100 fTimestampBase: 0xae0daf0d, tv: 683382.235273, RTP timestamp: 24100 Obviously the TimeStamp value of the RTCP SR packet should be between 21097 and 24100. No - because the 'NTP' time (683383.099932) that's used for the RTCP SR packet is not between 683382.201906 and 683382.235273. The RTP timestamp of 101919 corresponds to the time 683383.099932. Agree It's perfectly OK for the NTP time that's used in a RTCP "SR" report to differ from the presentation time used in RTP packets that bracket it. Agree However, because the RTCP SR 'NTP' time is computed using "gettimeofday()" (i.e., 'wall clock' time), the presentation times for your media samples (that get passed to RTP) *must* also be aligned with 'wall clock' time. Agree. But this is the problem, as I said the MPEGVideoStreamFramer computes the TimeStamp from the Mpeg2 Stream. There is no mean to bypass or feed the presentation times. The Presentation computing mechanism is internal to the object and follow the Mpeg2 Video Stream. Unless I have missing something but I use the sample application as provided with the library. The timestamp generation code (for both RTP and RTCP) is correct. No it is not. Well I mean the RTP timestamp. The RTCP timestamp is correctly computed. For the following discussion it is important that I add this information. The Mpeg2 Video ES is an I frame only stream. Thus the Timestamp will always increment from frame to frame. When the Timestamp go from 21097 to 24100 then a new Mpeg2 I frame begin. Since the RTCP packet is sent near the end of the I frame with timestamp 21097 but before any packet of I frame with timestamp 24100 has been sent then the RTCP RS timestamp should have been somewhere between timestamp 21097 and 24100 if the RTP timestamp would have been correctly timestamped. Actually the RTCP is timestamped with value 101919 which is greater than 24100 and way off. This is out of the RTP specification to the best of my understanding. If you have the book of Colin Perkins : "RTP Audio and Video for the Internet" then please turn to page 109. This will make it more clear. Of course since the RTP packets are Mpeg2 formatted then the timestamp stay constant until the next I frame. The reason of the discrepancy is the delay introduced by the parsing of the Mpeg2 Video Stream and the reading of the raw data. This will create Timestamps that are offset in the past. However, for it to work correctly, you must feed it correct presentation times. I might not know the library code enough but at first glance it seems I cannot because the mechanism is internal to the MPEG1or2VideoStreamFramer/MpegVideoStreamFramer. Unless I change the source code of the library file. Guy Bonneau -- 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/20080205/d2fb3d6a/attachment-0001.html From finlayson at live555.com Tue Feb 5 10:32:11 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 5 Feb 2008 10:32:11 -0800 Subject: [Live-devel] Timestamp gap in RTCP Report for MPEG1or2VideoStreamFramer In-Reply-To: <001301c86821$b43c4f80$8642a8c0@dorvalmatrox.matrox.com> References: <03c401c86810$84a65d80$8642a8c0@dorvalmatrox.matrox.com> <001301c86821$b43c4f80$8642a8c0@dorvalmatrox.matrox.com> Message-ID: You need to stop thinking about RTP timestamps. Instead, think about presentation times. At the RTP sender end, you provide - for each frame of media data - a presentation time. At the RTP receiver end, you get - for each frame of media data - a presentation time. This presentation time is used for decoding (and a/v sync). If you also implement RTCP, then (after the initial RTCP "SR" is received) the presentation times that you get at the RTP receiver end will be *exactly the same* as the presentation times that you provided at the RTP sender end. You can verify this for youself. In other words, you can - and should - think of the RTP/RTCP implementation, at the sender and receiver ends, as being a 'black box' that takes presentation times as input at one end, and produces *the same* presentation times as output at the other end. This 'black box' happens to work by using RTP timestamps and RTCP reports. But you shouldn't concern yourself with this. This code works. Trust me. Thus, the thing that you need to worry about is presentation times. Look at the *presentation times* that are coming out of "MPEG1or2VideoStreamFramer". Are they correct? Because your stream is I-frame only, then it's not inconceivable that there is a problem with the way that "MPEG1or2VideoStreamFramer" generates presentation times for your streams. You should be able to easily check this for yourself. But don't concern yourself with RTP timestamps; that's a total red herring. Note also that if your input data consists of discrete MPEG video frames, rather than a byte stream, then you could instead use "MPEG1or2VideoStreamDiscreteFramer", which is simpler and more efficient than "MPEG1or2VideoStreamFramer". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gbonneau at matrox.com Tue Feb 5 11:01:12 2008 From: gbonneau at matrox.com (Guy Bonneau) Date: Tue, 5 Feb 2008 14:01:12 -0500 Subject: [Live-devel] Timestamp gap in RTCP Report for MPEG1or2VideoStreamFramer In-Reply-To: References: <03c401c86810$84a65d80$8642a8c0@dorvalmatrox.matrox.com><001301c86821$b43c4f80$8642a8c0@dorvalmatrox.matrox.com> Message-ID: <002901c86829$79a2f650$8642a8c0@dorvalmatrox.matrox.com> Ross, Give me a few days. I have to double check a few things and I will getting back to you about that. Then I will provide you with some feedback about the AAC support in Mpeg2 Transport Stream if it work for me. Thanks for you great support. Best Regards Guy > -----Original Message----- > From: live-devel-bounces at ns.live555.com > [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson > Sent: Tuesday, February 05, 2008 1:32 PM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] Timestamp gap in RTCP Report for > MPEG1or2VideoStreamFramer > > You need to stop thinking about RTP timestamps. Instead, > think about presentation times. > > At the RTP sender end, you provide - for each frame of media > data - a presentation time. > > At the RTP receiver end, you get - for each frame of media > data - a presentation time. This presentation time is used > for decoding (and a/v sync). > > If you also implement RTCP, then (after the initial RTCP "SR" is > received) the presentation times that you get at the RTP > receiver end will be *exactly the same* as the presentation > times that you provided at the RTP sender end. You can > verify this for youself. > > In other words, you can - and should - think of the RTP/RTCP > implementation, at the sender and receiver ends, as being a > 'black box' that takes presentation times as input at one > end, and produces *the same* presentation times as output at > the other end. This 'black box' happens to work by using RTP > timestamps and RTCP reports. > But you shouldn't concern yourself with this. This code works. > Trust me. > > Thus, the thing that you need to worry about is presentation times. > Look at the *presentation times* that are coming out of > "MPEG1or2VideoStreamFramer". Are they correct? Because your > stream is I-frame only, then it's not inconceivable that > there is a problem with the way that > "MPEG1or2VideoStreamFramer" generates presentation times for > your streams. You should be able to easily check this for > yourself. But don't concern yourself with RTP timestamps; > that's a total red herring. > > Note also that if your input data consists of discrete MPEG > video frames, rather than a byte stream, then you could > instead use "MPEG1or2VideoStreamDiscreteFramer", which is > simpler and more efficient than "MPEG1or2VideoStreamFramer". > -- > > 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 roor0735-ml at yahoo.fr Tue Feb 5 13:03:36 2008 From: roor0735-ml at yahoo.fr (roor0735-ml at yahoo.fr) Date: Tue, 5 Feb 2008 22:03:36 +0100 (CET) Subject: [Live-devel] RE : Re: bug found and corrected In-Reply-To: <200802012202.m11M205H024053@ns.live555.com> Message-ID: <477156.16791.qm@web25912.mail.ukl.yahoo.com> I agree, it is not really a bug. In fact, your library is used to stream live DVB-T MPEG2 Transport stream in real-time over the network. So, I think it will be hard to calculate indexes before streaming the recording TS files. Concerning the proposed changes, I try to find a better way to correct the packet duration estimation issues. Normally, the PCR should be annouced with a quite regular periodicity. If the packet interval between two PCR annoucement is too low compared to the mean periodiciy of the PCR, then the PCR must be ignored in order to not introduce errors in the packet duration estimation. So, I introduce a new constant called PCR_PERIOD_VARIATION_RATIO that adjusts the minimum and tolerated packet interval from the mean PCR announcement period. For instance, in my sequence, the mean period of PCR announcement converges to around 47. The ratio is set to 50%, so the minimum packet interval between two PCR is 23. I think this method is less arbitrary than the "20" value. I hope this can help people that wants to broadcast VBR multiplexed dataflows. Regards, Romain Ross Finlayson a ?crit : Thanks. However, the existing code is not really a 'bug', although your suggested change is (arguably) an improvement. As you noticed, the current per-transport-packet duration estimation code has trouble converging on a stable estimate for streams - such as yours - that are wildly VBR. Your suggested change will probably help things (although I can also imagine streams for which it might make things worse by taking longer to converge to the 'correct' average duration). I am also a bit concerned about the arbitrariness of the constant "20" that you use. Nonetheless, I'll add your change to the next release of the library. (Looking longer-term, a better solution for streaming prerecorded files (but not live streams) will be to extend the existing "index file" mechanism to include accurate durations - which could be computed in advance when generating the index file.) Ross Finlayson Live Networks, Inc. (LIVE555.COM) --------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080205/b4f4e77d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2TransportStreamFramer.cpp Type: application/octet-stream Size: 9292 bytes Desc: 2250531848-MPEG2TransportStreamFramer.cpp Url : http://lists.live555.com/pipermail/live-devel/attachments/20080205/b4f4e77d/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2TransportStreamFramer.hh Type: application/octet-stream Size: 2426 bytes Desc: 2480703395-MPEG2TransportStreamFramer.hh Url : http://lists.live555.com/pipermail/live-devel/attachments/20080205/b4f4e77d/attachment-0003.obj From gbonneau at matrox.com Tue Feb 5 13:44:53 2008 From: gbonneau at matrox.com (Guy Bonneau) Date: Tue, 5 Feb 2008 16:44:53 -0500 Subject: [Live-devel] Timestamp gap in RTCP Report for MPEG1or2VideoStreamFramer Message-ID: <005001c86840$57844120$8642a8c0@dorvalmatrox.matrox.com> Ross, It didn't take me days. I have solved my problem of synchronization that was caused by wrong "presentation time" decoded by the library. I have had to modify the library as explained in my email exchange. > At the RTP receiver end, you get - for each frame of media > data - a presentation time. This presentation time is used > for decoding (and a/v sync). I have used the VLC Media application for receiver. > If you also implement RTCP, then (after the initial RTCP "SR" is > received) the presentation times that you get at the RTP > receiver end will be *exactly the same* as the presentation > times that you provided at the RTP sender end. You can > verify this for yourself. Yes Indeed I have. And there are exactly the same until VLC Media receive hasBeenSynchronizedUsingRTCP status from the library. > > In other words, you can - and should - think of the RTP/RTCP > implementation, at the sender and receiver ends, as being a > 'black box' that takes presentation times as input at one > end, and produces *the same* presentation times as output at > the other end. This 'black box' happens to work by using RTP > timestamps and RTCP reports. > But you shouldn't concern yourself with this. This code works. > Trust me. Unfortunately there is a use case that doesn't work and this is what I am trying to explain. The use case can only show up when you try to synchronize at least those 2 streams. A video Mpeg stream and an audio PCM stream. (They might be also other use cases I haven't found) > > Thus, the thing that you need to worry about is presentation times. > Look at the *presentation times* that are coming out of > "MPEG1or2VideoStreamFramer". Are they correct? No there are not...!!! But only once library has called the function hasBeenSynchronizedUsingRTCP()at the receiver side. > Because your > stream is I-frame only, then it's not inconceivable that > there is a problem with the way that > "MPEG1or2VideoStreamFramer" generates presentation times for > your streams. It do fine and there is no bug to the best of my knowledge. The parser doesn't complain. The problem is in the Presentation time delay associated to the Mpeg2 streamer of the library. > You should be able to easily check this for > yourself. I did !!! I have been able to reproduce the issue easily with a small testing application that has been created from testing application testMPEG1or2VideoStreamer. If possible and if you can provide me an upload ftp I could provide you with a use case and steps to reproduce the problem. I also added some message at the StreamRead function of VLC Media Player inside the live555.cpp file that shows the Presentation time that VLC receives (It is Win32 based however) that I can send with the use case. The problem is easy to see with the message window of VLC Media player. Once VLC catch the status hasBeenSynchronizedUsingRTCP() the live555 library send desynchronized presentation time between audio/video. You see it. I can also send you the modification to the library to solve the problem. It is a very minor change in the file MPEGVideoStreamFramer.cpp. Let me know. Regards and thanks Guy From mail at oliroll.de Tue Feb 5 23:17:43 2008 From: mail at oliroll.de (Oliver Roll) Date: Wed, 06 Feb 2008 08:17:43 +0100 Subject: [Live-devel] Discarding out-of-order frames Message-ID: <47A95F17.7060702@oliroll.de> Hello, while streaming MPEG2 or MPEG4, when do out-of-order or too late arriving frames get discarded? For example, I guess that an I-frame experiencing a delay of 1 second on its way will not be of use any more. I had a look at MultiFramedRTPSource and ReorderingPacketBuffer. Is ReorderingPacketBuffer's fThresholdTime the time after which an out-of-order arriving frame gets discarded? Or is there a receive buffer on the client side which has to be filled? Thanks & regards, Oliver From finlayson at live555.com Wed Feb 6 00:36:13 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 6 Feb 2008 00:36:13 -0800 Subject: [Live-devel] Discarding out-of-order frames In-Reply-To: <47A95F17.7060702@oliroll.de> References: <47A95F17.7060702@oliroll.de> Message-ID: >while streaming MPEG2 or MPEG4, when do out-of-order or too late >arriving frames get discarded? >For example, I guess that an I-frame experiencing a delay of 1 second on >its way will not be of use any more. >I had a look at MultiFramedRTPSource and ReorderingPacketBuffer. Is >ReorderingPacketBuffer's fThresholdTime the time after which an >out-of-order arriving frame gets discarded? Yes. The default value is 100ms, but you can change this using the function "RTPSource:: setPacketReorderingThresholdTime()". Note that this applies only to out-of-order packets. Packets that are in order, but just 'slow', will always get delivered. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kan at pisem.net Thu Feb 7 04:05:28 2008 From: kan at pisem.net (Karlov Andrey) Date: Thu, 07 Feb 2008 15:05:28 +0300 Subject: [Live-devel] is it possible to stream one file to several IP addresses? Message-ID: <47AAF408.9020600@pisem.net> How can I add several "RTPSink" or "UDPSink" objects to testMPEG2TransportStreamer? From xcsmith at rockwellcollins.com Thu Feb 7 08:42:19 2008 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 7 Feb 2008 10:42:19 -0600 Subject: [Live-devel] is it possible to stream one file to several IP addresses? In-Reply-To: <47AAF408.9020600@pisem.net> Message-ID: > How can I add several "RTPSink" or "UDPSink" objects to > testMPEG2TransportStreamer? testMPEG2TransportStreamer delivers a multicast stream, so you can already have multiple clients connect and watch this stream. is it your intent to have a stream received by several clients or to make several multicast streams? i don't think it makes sense to have several multicast streams. if you have ReuseFirstSource set to TRUE in testOnDemandRTSPServer, then multiple clients can also get the stream in a time-sync'd fashion via unicast. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080207/98d4b7be/attachment.html From kan at pisem.net Thu Feb 7 12:39:12 2008 From: kan at pisem.net (Karlov Andrey) Date: Thu, 07 Feb 2008 23:39:12 +0300 Subject: [Live-devel] is it possible to stream one file to several IP addresses? Message-ID: <47AB6C70.8090909@pisem.net> indeed I need several multicast streams from one source, not unicas, not on demand From dee at renci.org Thu Feb 7 13:13:53 2008 From: dee at renci.org (Daniel Evans) Date: Thu, 07 Feb 2008 16:13:53 -0500 Subject: [Live-devel] Uncompressed video payload format over RTP per RFC4175 Message-ID: <47AB7491.9060907@renci.org> Hi, My first question/post to this list :) ... has anyone implemented an uncompressed payload format yet? Just checking before I subclass the MultiFramedRTPXXX classes. Thanks in advance, Daniel Evans From finlayson at live555.com Thu Feb 7 14:31:26 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 7 Feb 2008 14:31:26 -0800 Subject: [Live-devel] is it possible to stream one file to several IP addresses? In-Reply-To: <47AB6C70.8090909@pisem.net> References: <47AB6C70.8090909@pisem.net> Message-ID: > indeed I need several multicast streams from one source, not unicas, >not on demand OK, so you will need to write a new class that acts as a data 'duplicator' - i.e., taking one input, but generating several outputs. Each output would be fed to a separate "RTPSink" object (each with its own "groupsock"). You would call "startPlaying()" on each of these "RTPSink"s. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Feb 7 14:52:38 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 7 Feb 2008 14:52:38 -0800 Subject: [Live-devel] Uncompressed video payload format over RTP per RFC4175 In-Reply-To: <47AB7491.9060907@renci.org> References: <47AB7491.9060907@renci.org> Message-ID: >My first question/post to this list :) ... has anyone implemented an >uncompressed payload format yet? Just checking before I subclass the >MultiFramedRTPXXX classes. No, right now I know of no implementation (for our libraries) of the RFC 4175 payload format. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tl11305 at salle.url.edu Fri Feb 8 00:33:42 2008 From: tl11305 at salle.url.edu (Ramon Martin de Pozuelo Genis) Date: Fri, 8 Feb 2008 09:33:42 +0100 (CET) Subject: [Live-devel] Streaming HD with two interfaces Message-ID: <1298.172.16.11.128.1202459622.squirrel@webmail.salle.url.edu> Hi all, I am trying to send a H.264 HD v?deo in two diferent networks using the same computer with two network cards. It works perfectly when I am streaming it at 6 Mbps using one network card. But, when I replicate the same or other similar video into the other network, the bitrate slow down to 4 Mbps in both videos. It doesn't happen when I stream the same videos in only one network using one network card. I don't notice if I have packet loss. I sniff the network with Wireshark and there aren't jumps on timestamps or sequence numbers of the RTP packets. Do you perceive what the problem could be? Thanks in advance, Ramon From renard.nicolas at gmail.com Fri Feb 8 02:48:26 2008 From: renard.nicolas at gmail.com (Nicolas Renard) Date: Fri, 8 Feb 2008 11:48:26 +0100 Subject: [Live-devel] is it possible to stream one file to several IP addresses? In-Reply-To: References: <47AB6C70.8090909@pisem.net> Message-ID: I find a simpler way to do this by adding several multicast address to the group sock by using the addDestination method before the creation of the RTPsink. Nicolas Renard 2008/2/7, Ross Finlayson : > > > indeed I need several multicast streams from one source, not unicas, > >not on demand > > OK, so you will need to write a new class that acts as a data > 'duplicator' - i.e., taking one input, but generating several > outputs. Each output would be fed to a separate "RTPSink" object > (each with its own "groupsock"). You would call "startPlaying()" on > each of these "RTPSink"s. > -- > > 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/20080208/56f5390d/attachment-0001.html From renard.nicolas at gmail.com Fri Feb 8 08:20:43 2008 From: renard.nicolas at gmail.com (Nicolas Renard) Date: Fri, 8 Feb 2008 17:20:43 +0100 Subject: [Live-devel] change source in a relay Message-ID: Hi all. I have a relay which take a live source (MP4V-ES) as FramedSource and transmit it to a multicast address. I would like to change the source on the flight on an external event (for instance a timer) without breaking the client side session. Anybody has a hint? regards Nicolas Renard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080208/5c0124d5/attachment.html From finlayson at live555.com Fri Feb 8 12:29:08 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 8 Feb 2008 12:29:08 -0800 Subject: [Live-devel] is it possible to stream one file to several IP addresses? In-Reply-To: References: <47AB6C70.8090909@pisem.net> Message-ID: >I find a simpler way to do this by adding several multicast address >to the group sock by using the addDestination method before the >creation of the RTPsink. Yes, I had forgotten about that option. (I currently use the "addDestination()" method to add unicast addresses, but it works for multicast addresses as well.) This is the best way to get what you are looking for. (Thanks, Nicolas, for the reminder.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Feb 8 14:08:51 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 8 Feb 2008 14:08:51 -0800 Subject: [Live-devel] change source in a relay In-Reply-To: References: Message-ID: >Hi all. > >I have a relay which take a live source (MP4V-ES) as FramedSource >and transmit it to a multicast address. >I would like to change the source on the flight on an external event >(for instance a timer) without breaking the client side session. > >Anybody has a hint? Yes, you should be able to do this by first calling "stopPlaying()" on the sink, then call "startPlaying()" again with the new source. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vinodmenon2004 at gmail.com Mon Feb 11 08:02:45 2008 From: vinodmenon2004 at gmail.com (Vinod Menon) Date: Mon, 11 Feb 2008 11:02:45 -0500 Subject: [Live-devel] MPEG2TransportStream time/position info Message-ID: Hi, I would like to know how I can use the PresentationTime and PacketDurationEstimate to compute the time info from the start of the stream. The intent is determine the time lapsed since the stream started playing. Appreciate any help Thanks, - V From vinodmenon2004 at gmail.com Mon Feb 11 09:01:57 2008 From: vinodmenon2004 at gmail.com (Vinod Menon) Date: Mon, 11 Feb 2008 12:01:57 -0500 Subject: [Live-devel] LIVE555 Server (RTSP-TCP Streaming) Message-ID: Hi, I'd like to know whether LIVE555 Media Server supports RTSP with TCP streaming. Thanks, -V From finlayson at live555.com Mon Feb 11 20:15:50 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Feb 2008 20:15:50 -0800 Subject: [Live-devel] LIVE555 Server (RTSP-TCP Streaming) In-Reply-To: References: Message-ID: >I'd like to know whether LIVE555 Media Server supports RTSP with TCP >streaming. I assume that by "RTSP with TCP streaming" you mean "RTSP with RTP-over-TCP streaming". The answer is yes. If a client requests RTP-over-TCP streaming, then our server will deliver this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Feb 11 20:22:15 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 11 Feb 2008 20:22:15 -0800 Subject: [Live-devel] MPEG2TransportStream time/position info In-Reply-To: References: Message-ID: >I would like to know how I can use the PresentationTime and >PacketDurationEstimate to compute the time info from the start >of the stream. The intent is determine the time lapsed since the >stream started playing. This information is obtained from PCR timestamps that appear in the MPEG Transport Data itself. It is also present in the Presentation Times that are carried by RTP, but most receiving ciients, when decoding Transport Stream data, will use the PCR timestamps instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From clifford at cs.bris.ac.uk Tue Feb 12 00:57:15 2008 From: clifford at cs.bris.ac.uk (Raphael Clifford) Date: Tue, 12 Feb 2008 08:57:15 +0000 Subject: [Live-devel] audio/x-Purevoice problem Message-ID: It was suggested by Compn in #mplayer that I report a problem with playing rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov in mplayer. If I play it in mplayer the video works fine but it seems live555 can't handle the audio. The crucial error message is Failed to initiate "audio/X-PUREVOICE" RTP subsession: RTP payload format unknown or not supported I attach the full output from mplayer rc2 below. The latest svn mplayer on Feb 11 gives much the same error. (please cc me on any reply as I am not subscribed to the mailing list) Best wishes, Raphael mplayer -v -rtsp-stream-over-tcp rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov MPlayer 1.0rc2-4.1.3 (C) 2000-2007 MPlayer Team CPU: Intel(R) Pentium(R) M processor 1.30GHz (Family: 6, Model: 13, Stepping: 8) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. get_path('codecs.conf') -> '/home/raph/.mplayer/codecs.conf' Reading /home/raph/.mplayer/codecs.conf: Can't open '/home/raph/.mplayer/codecs.conf': No such file or directory Reading /etc/mplayer/codecs.conf: Can't open '/etc/mplayer/codecs.conf': No such file or directory Using built-in default codecs.conf. Configuration: --target=i586-linux --prefix=/usr --confdir=/etc/mplayer --mandir=/usr/share/man --win32codecsdir=/usr/lib/win32 --enable-runtime-cpudetection --enable-largefiles --disable-libdvdcss-internal --enable-smb --enable-ftp --enable-cdparanoia --enable-radio --enable-lirc --enable-joystick --enable-xf86keysym --disable-tremor-internal --enable-liba52 --enable-musepack --enable-speex --enable-libvorbis --enable-mad --enable-mp3lib --enable-theora --enable-libdv --enable-libmpeg2 --enable-tv-v4l2 --enable-alsa --enable-ossaudio --enable-esd --enable-arts --enable-pulse --enable-nas --enable-xinerama --enable-menu --enable-xv --enable-vm --enable-gl --enable-xmga --enable-mga --enable-3dfx --enable-tdfxfb --enable-sdl --enable-aa --enable-caca --enable-dxr3 --enable-xvmc --with-xvmclib=XvMCW --enable-ggi --enable-fbdev --enable-freetype --enable-gif --enable-png --enable-jpeg --enable-liblzo --enable-fribidi --enable-ladspa --enable-gui --enable-mencoder CommandLine: '-v' '-rtsp-stream-over-tcp' 'rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov' init_freetype get_path('font/font.desc') -> '/home/raph/.mplayer/font/font.desc' font: can't open file: /home/raph/.mplayer/font/font.desc font: can't open file: /usr/share/mplayer/font/font.desc Using MMX (with tiny bit MMX2) Optimized OnScreenDisplay get_path('fonts') -> '/home/raph/.mplayer/fonts' Using nanosleep() timing get_path('input.conf') -> '/home/raph/.mplayer/input.conf' Can't open input config file /home/raph/.mplayer/input.conf: No such file or directory Parsing input config file /etc/mplayer/input.conf Input config file /etc/mplayer/input.conf parsed: 81 binds Setting up LIRC support... mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. get_path('Sec_pt_10935_4fpsB.mov.conf') -> '/home/raph/.mplayer/Sec_pt_10935_4fpsB.mov.conf' Playing rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov. get_path('sub/') -> '/home/raph/.mplayer/sub/' STREAM_RTSP, URL: rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov Filename for url is now rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov Filename for url is now rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov Resolving 129.7.38.97 for AF_INET6... Couldn't resolve name for AF_INET6: 129.7.38.97 Connecting to server 129.7.38.97[129.7.38.97]: 80... SDP: v=0 o=StreamingServer 3411749870 1134166329000 IN IP4 129.7.38.97 s=/streaming/Sec_pt_10935_4fpsB.mov u=http:/// e=admin@ c=IN IP4 0.0.0.0 b=AS:47 t=0 0 a=control:* a=mpeg4-iod:"data:application/mpeg4-iod;base64,AoIbAE/////z/wOBKgABQIxkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVXdCU2dVZkEwWUF5UUFFTHlBUkFBQUFBQUFBQUFBQUFBQUZJQUFBQWJEekFBQUJ0UTdnUU1EUEFBQUJBQUFBQVNBQWhFRDZLSUFoZ0tJZkJoQUFSQUFBQWxnQUFBSllJQ0FBQUFBRAQNAQUAAMgAAAAAAAAAAAYJAQAAAAAAAAAAA2UAAkBCZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFRZndBQUFIOEFBQUVRb0lvS2ZnQT09BBICDQAAZAAAAAAAAAAABQMAAGAGCQEAAAAAAAAAAA==" a=isma-compliance:1,1.0,1 a=range:npt=0- 551.00000 m=video 0 RTP/AVP 96 b=AS:40 a=rtpmap:96 MP4V-ES/90000 a=control:trackID=3 a=cliprect:0,0,384,512 a=fmtp:96 profile-level-id=1;config=000001B0F3000001B50EE040C0CF0000010000000120008440FA28802180A21F a=mpeg4-esid:201 m=audio 0 RTP/AVP 97 b=AS:6 a=rtpmap:97 x-Purevoice/11025/1 a=control:trackID=4 A single media stream only is supported atm. rtsp_session: unsupported RTSP server. Server type is 'QTSS/5.5.3 (Build/489.0.4; Platform/MacOSX; Release/Update; )'. Filename for url is now rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov Filename for url is now rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov STREAM_LIVE555, URL: rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov STREAM: [RTSP and SIP] rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov STREAM: Description: standard RTSP and SIP STREAM: Author: Ross Finlayson STREAM: Comment: Uses LIVE555 Streaming Media library. Stream not seekable! file format detected. Sending request: DESCRIBE rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov RTSP/1.0 CSeq: 1 Accept: application/sdp User-Agent: MPlayer (LIVE555 Streaming Media v2007.02.20) Received DESCRIBE response: RTSP/1.0 200 OK Server: QTSS/5.5.3 (Build/489.0.4; Platform/MacOSX; Release/Update; ) Cseq: 1 Last-Modified: Fri, 09 Dec 2005 22:12:09 GMT Cache-Control: must-revalidate Content-length: 968 Date: Mon, 11 Feb 2008 20:17:50 GMT Expires: Mon, 11 Feb 2008 20:17:50 GMT Content-Type: application/sdp x-Accept-Retransmit: our-retransmit x-Accept-Dynamic-Rate: 1 Content-Base: rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov/ Need to read 968 extra bytes Read 968 extra bytes: v=0 o=StreamingServer 3411749870 1134166329000 IN IP4 129.7.38.97 s=/streaming/Sec_pt_10935_4fpsB.mov u=http:/// e=admin@ c=IN IP4 0.0.0.0 b=AS:47 t=0 0 a=control:* a=mpeg4-iod:"data:application/mpeg4-iod;base64,AoIbAE/////z/wOBKgABQIxkYXRhOmFwcGxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVXdCU2dVZkEwWUF5UUFFTHlBUkFBQUFBQUFBQUFBQUFBQUZJQUFBQWJEekFBQUJ0UTdnUU1EUEFBQUJBQUFBQVNBQWhFRDZLSUFoZ0tJZkJoQUFSQUFBQWxnQUFBSllJQ0FBQUFBRAQNAQUAAMgAAAAAAAAAAAYJAQAAAAAAAAAAA2UAAkBCZGF0YTphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTWVFRZndBQUFIOEFBQUVRb0lvS2ZnQT09BBICDQAAZAAAAAAAAAAABQMAAGAGCQEAAAAAAAAAAA==" a=isma-compliance:1,1.0,1 a=range:npt=0- 551.00000 m=video 0 RTP/AVP 96 b=AS:40 a=rtpmap:96 MP4V-ES/90000 a=control:trackID=3 a=cliprect:0,0,384,512 a=fmtp:96 profile-level-id=1;config=000001B0F3000001B50EE040C0CF0000010000000120008440FA28802180A21F a=mpeg4-esid:201 m=audio 0 RTP/AVP 97 b=AS:6 a=rtpmap:97 x-Purevoice/11025/1 a=control:trackID=4 Initiated "video/MP4V-ES" RTP subsession on port 32856 Increased video socket receive buffer to 2000000 bytes Sending request: SETUP rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov/trackID=3 RTSP/1.0 CSeq: 2 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: MPlayer (LIVE555 Streaming Media v2007.02.20) Received SETUP response: RTSP/1.0 200 OK Server: QTSS/5.5.3 (Build/489.0.4; Platform/MacOSX; Release/Update; ) Cseq: 2 Last-Modified: Fri, 09 Dec 2005 22:12:09 GMT Cache-Control: must-revalidate Session: 2025512804997603191 Date: Mon, 11 Feb 2008 20:17:51 GMT Expires: Mon, 11 Feb 2008 20:17:51 GMT Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=234FDA8B Failed to initiate "audio/X-PUREVOICE" RTP subsession: RTP payload format unknown or not supported Sending request: PLAY rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov/ RTSP/1.0 CSeq: 3 Session: 2025512804997603191 Range: npt=0.000- User-Agent: MPlayer (LIVE555 Streaming Media v2007.02.20) Received PLAY response: RTSP/1.0 200 OK Server: QTSS/5.5.3 (Build/489.0.4; Platform/MacOSX; Release/Update; ) Cseq: 3 Session: 2025512804997603191 Range: npt=0.00000-551.00000 RTP-Info: url=rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov/trackID=3;seq=52470;rtptime=1499070065 ==> Found video stream: 0 video stream has been synchronized using RTCP demux_rtp: Guessed the video frame rate as 2 frames-per-second. (If this is wrong, use the "-fps " option instead.) VIDEO: [mp4v] 0x0 0bpp 2.000 fps 0.0 kbps ( 0.0 kbyte/s) [V] filefmt:21 fourcc:0x7634706D size:0x0 fps: 2.00 ftime:=0.5000 get_path('sub/') -> '/home/raph/.mplayer/sub/' X11 opening display: :0.0 vo: X11 color mask: FFFFFF (R:FF0000 G:FF00 B:FF) vo: X11 running at 1024x768 with depth 24 and 32 bpp (":0.0" => local display) [x11] Detected wm supports layers. [x11] Using workaround for Metacity bugs. [x11] Detected wm supports NetWM. [x11] Detected wm supports ABOVE state. [x11] Detected wm supports BELOW state. [x11] Detected wm supports FULLSCREEN state. [x11] Current fstype setting honours FULLSCREEN ABOVE BELOW X atoms Disabling DPMS DPMSDisable stat: 1 xscreensaver_disable: Could not find XScreenSaver window. GNOME screensaver disabled [xv common] Drawing colorkey manually. [xv common] Using colorkey from Xv (0x0101fe). [xv common] Maximum source image dimensions: 1920x1088 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family INFO: libavcodec init OK! Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4) ========================================================================== Audio: no sound Freeing 0 unused audio chunks. Starting playback... [ffmpeg] aspect_ratio: 1.333333 VDec: vo config request - 512 x 384 (preferred colorspace: Planar YV12) Trying filter chain: vo VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO Config (512x384->512x384,flags=0,'MPlayer',0x32315659) VO: [xv] 512x384 => 512x384 Planar YV12 VO: Description: X11/Xv VO: Author: Gerd Knorr and others Xvideo image format: 0x32595559 (YUY2) packed Xvideo image format: 0x32315659 (YV12) planar Xvideo image format: 0x30323449 (I420) planar Xvideo image format: 0x59565955 (UYVY) packed using Xvideo port 73 for hw scaling [xv] dx: 0 dy: 0 dw: 512 dh: 384 *** [vo] Allocating (slices) mp_image_t, 512x384x12bpp YUV planar, 294912 bytes [xv] dx: 6 dy: 27 dw: 512 dh: 384 *** [vo] Allocating (slices) mp_image_t, 512x384x12bpp YUV planar, 294912 bytes get_path('subfont.ttf') -> '/home/raph/.mplayer/subfont.ttf' Unicode font: 255 glyphs. Uninit video: ffmpeg 0% 0.0% 0 0 Sending request: TEARDOWN rtsp://129.7.38.97:80/streaming/Sec_pt_10935_4fpsB.mov/ RTSP/1.0 CSeq: 4 Session: 2025512804997603191 User-Agent: MPlayer (LIVE555 Streaming Media v2007.02.20) From finlayson at live555.com Tue Feb 12 01:13:59 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 12 Feb 2008 01:13:59 -0800 Subject: [Live-devel] audio/x-Purevoice problem In-Reply-To: References: Message-ID: See References: Message-ID: On 12/02/2008, Ross Finlayson wrote: > See -- Thanks. It's a real shame that a university would use such a format which seems to make it unplayable under linux by any means. Best wishes, Raphael From gbonneau at matrox.com Tue Feb 12 09:23:07 2008 From: gbonneau at matrox.com (Guy Bonneau) Date: Tue, 12 Feb 2008 12:23:07 -0500 Subject: [Live-devel] Mpeg2 ES and audio PCM stream Synchronization with Live555 Message-ID: <038b01c86d9b$eebfba00$8642a8c0@dorvalmatrox.matrox.com> I would like to provide some feedback of my synchronization issues with mpeg video and audio PCM. I think it might be useful to other users of the library. I have slightly modified 2 testing applications included with Live555: testMPEG1or2VideoStreamer and testMPEG1or2VideoReceiver. I have included these 2 applications with this email. I have added logging in the testing application testMPEG1or2VideoReceiver to a log file. Logging to the console was causing "stress" to the environment thread and starved the library from CPU processing. I first start the testMPEG1or2VideoStreamer application. That application streams an Mpeg2 Video Elementary Stream and a PCM audio wave. The audio file must be 48KHz 2 Channels 16 bits. Otherwise modification to the testMPEG1or2VideoReceiver app will be needed. I have introduced a delay of 3 seconds between the creation of the source objects of the library and the actual starting of the sinking that begin the streaming. This closely simulates our use of the library by our own application. Our application starts the sinking when the user press the "play" button but create the objects when the application is instantiated. Once testMPEG1or2VideoStreamer begins streaming I start the second application testMPEG1or2VideoReceiver. I have modified the application to closely match the design of the main receiving loop of the VLC Media application. The application receives both the video and audio streams. I don't store the data in this testing case. Here is an excerpt of the log on the receiving client before the library send the RTCP SR: Video received 1311 bytes at time 0-00:20:13-702.255 Video received 1339 bytes at time 0-00:20:13-702.255 Video received 1348 bytes at time 0-00:20:13-702.255 Video received 1395 bytes at time 0-00:20:13-702.255 Video received 1068 bytes at time 0-00:20:13-702.255 Video received 506 bytes at time 0-00:20:13-702.255 Audio received 1400 bytes at time 0-00:20:13-720.633 Audio received 1400 bytes at time 0-00:20:13-727.924 Audio received 1400 bytes at time 0-00:20:13-735.215 (...) At this point both the Video and Audio are closely in sync. I guess using the client wall clock until RTCP SR. Here is an excerpt of the log after the library sent the RTCP SR: Video received 506 bytes at time 0-00:20:13-702.255 Audio received 1400 bytes at time 0-00:20:13-720.633 Audio received 1400 bytes at time 0-00:20:13-727.924 Audio received 1400 bytes at time 0-00:20:13-735.215 Audio hasBeenSynchronizedUsingRTCP() Audio received 1400 bytes at time 0-00:33:24-123.145 Video hasBeenSynchronizedUsingRTCP() Video received 1047 bytes at time 0-00:33:21-122.121 Video received 987 bytes at time 0-00:33:21-122.121 Video received 1205 bytes at time 0-00:33:21-122.121 Video received 1152 bytes at time 0-00:33:21-122.121 Audio received 1400 bytes at time 0-00:33:24-130.436 (3 Sec GAP) Video received 1160 bytes at time 0-00:33:21-122.121 Video received 994 bytes at time 0-00:33:21-122.121 Video received 1007 bytes at time 0-00:33:21-122.121 Video received 559 bytes at time 0-00:33:21-122.121 Audio received 1400 bytes at time 0-00:33:24-137.727 Audio received 1400 bytes at time 0-00:33:24-145.018 Audio received 1400 bytes at time 0-00:33:24-152.309 Video received 1053 bytes at time 0-00:33:21-155.487 Video received 991 bytes at time 0-00:33:21-155.487 As soon as the RTCP SR report is received at the client side the library resync the presentation time to the server wall clock but a gap is created between the audio and video. The presentation time gap matches the delay between the creation of the source objects and the actual starting of the sinking. I noted that the object MPEGVideoStreamFramer creates the base presentation time when method MPEGVideoStreamFramer::reset() is called. This method is called at creation time of MPEGVideoStreamFramer or when the method flushInput() is called. The comment associated to this method is: //called if there is a discontinuity (seeking) in the input. In our case the Mpeg2 stream was streaming from a live source and the flushInput() method was never called. Thus the base presentation time used when the Mpeg2 streaming began was from the object creation time. This created a huge gap between the audio and mpeg2 stream. And VLC media player was baffled by the presentation time once RTCP sync was received. VLC Media Player got lost trying to regain synchronization. This gap can be solved if the library source objects are instantiated when the sink are started. But this was unacceptable in my case. I can also make a call to the method flushInput() just before starting the sinking. This is the easiest solution. A small modification could also be done to the library. Since the computing of the presentation time by MPEGVideoStreamFramer is internal to the library and cannot be reassigned I fell the initialization of the base presentation time should be done when method computePresentationTime is called by object MPEGVideoStreamFramer. This could be done like this: void MPEGVideoStreamFramer::reset() { fPictureCount = 0; fPictureEndMarker = False; fPicturesAdjustment = 0; fPictureTimeBase = 0.0; fTcSecsBase = 0; fHaveSeenFirstTimeCode = False; fPresentationTimeBase.tv_sec = 0; //added fPresentationTimeBase.tv_usec = 0; //added fFlushedInput = True; // Added this private member to object //Removed call to gettimeofday } void MPEGVideoStreamFramer ::computePresentationTime(unsigned numAdditionalPictures) { // Use the current wallclock time as the base 'presentation time': if( fFlushedInput == True ) { fFlushedInput = False; gettimeofday(&fPresentationTimeBase, NULL); } (...) } Or I suggest the adding of the calling to the method flushInput() in the testing application testMPEG1or2VideoStreamer of the library before starting the sink. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testMpeg1or2VideoAndLPCMStreamer.cpp Url: http://lists.live555.com/pipermail/live-devel/attachments/20080212/8ba7dba1/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: testMPEG1or2VideoReceiver.cpp Url: http://lists.live555.com/pipermail/live-devel/attachments/20080212/8ba7dba1/attachment-0001.ksh From finlayson at live555.com Tue Feb 12 17:55:53 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 12 Feb 2008 17:55:53 -0800 Subject: [Live-devel] Mpeg2 ES and audio PCM stream Synchronization with Live555 In-Reply-To: <038b01c86d9b$eebfba00$8642a8c0@dorvalmatrox.matrox.com> References: <038b01c86d9b$eebfba00$8642a8c0@dorvalmatrox.matrox.com> Message-ID: I haven't had time to wade through this in detail, but it seems that you've run into the same problem that I had when I was developing the "wis-streamer" application . Namely, if your streaming server is fed audio and video data as two streams of *unstructured data* - rather than two streams of discrete frames - then it is difficult to ensure that the resulting audio and video frames - when parsed from each stream - will get accurate presentation times (and it will be difficult to ensure that they remain accurate over time). (You get proper a/v synchronization at the client end if and only if the server-generated presentation times were accurate.) As I found with "wis-streamer", the solution is to change your application so that it is fed streams of *discrete* frames, each having its own presentation timestamp that is generated directly, when it the frame is produced (e.g., by a hardware encoder). Then you don't have to parse the streams to extract (possibly inaccurate) presentation times. I.e., instead of using "MPEG1or2VideoStreamFramer", use "MPEG1or2VideoStreamDiscreteFramer". So, I suggest that you revew the "wis-streamer" source code for hints that may help your application. (This will be my last posting on this subject.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gbonneau at matrox.com Wed Feb 13 06:14:16 2008 From: gbonneau at matrox.com (Guy Bonneau) Date: Wed, 13 Feb 2008 09:14:16 -0500 Subject: [Live-devel] Mpeg2 ES and audio PCM stream Synchronization with Live555 In-Reply-To: References: <038b01c86d9b$eebfba00$8642a8c0@dorvalmatrox.matrox.com> Message-ID: <043201c86e4a$b7de17c0$8642a8c0@dorvalmatrox.matrox.com> Thanks Ross for the feedback, I understand that you are quite busy. Keep the good work. That library is great work. Regards Guy > -----Original Message----- > From: live-devel-bounces at ns.live555.com > [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson > Sent: Tuesday, February 12, 2008 8:56 PM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] Mpeg2 ES and audio PCM stream > Synchronization with Live555 > > I haven't had time to wade through this in detail, but it > seems that you've run into the same problem that I had when I > was developing the "wis-streamer" application > . > Namely, if your streaming server is fed audio and video data > as two streams of *unstructured data* - rather than two > streams of discrete frames - then it is difficult to ensure > that the resulting audio and video frames - when parsed from > each stream - will get accurate presentation times (and it > will be difficult to ensure that they remain accurate over > time). (You get proper a/v synchronization at the client end > if and only if the server-generated presentation times were accurate.) > > As I found with "wis-streamer", the solution is to change > your application so that it is fed streams of *discrete* > frames, each having its own presentation timestamp that is > generated directly, when it the frame is produced (e.g., by a > hardware encoder). Then you don't have to parse the streams > to extract (possibly inaccurate) presentation times. I.e., > instead of using "MPEG1or2VideoStreamFramer", use > "MPEG1or2VideoStreamDiscreteFramer". > > So, I suggest that you revew the "wis-streamer" source code > for hints that may help your application. > > (This will be my last posting on this subject.) > -- > > 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 ymreddy at ssdi.sharp.co.in Wed Feb 13 06:17:57 2008 From: ymreddy at ssdi.sharp.co.in (Mallikharjuna Reddy) Date: Wed, 13 Feb 2008 19:47:57 +0530 Subject: [Live-devel] MP4 streaming implementation in LIVE555 codebase References: <200704250410.MAA12762@msr11.hinet.net> Message-ID: <9219A756FBA09B4D8CE75D4D7987D6CB01D8DC1B@KABEX01.sharpamericas.com> Hi Ross, We are planning to implement MP4 streaming in server side in LIVE555 code base with the help of libmp4 library. We have the following clarifications: 1. We are planning to create a separate class called MP4VideoStreamParser which is derived from MPEGVideoStreamParser. This class (MP4VideoStreamParser) contains methods to parse the MP4 file and return individual frames and set fTo and fStart variables. 2. After individual frame is read from MP4 file from above step, the respective MPEG1or2VideoStreamFramer or MPEG4VideoStreamFramer classes are called to construct the RTP packet from the buffer and send the packet to the client. We assume that MP4 file contains MPEG2 or MPEG4 video data only. Here we have a clarification here. Do we need to create a separate class called MP4VideoStreamFramer derived from FramedSource, which does the job of constructing the RTP packet from the buffer and send the packet to the client. Or We can use the existing classes (MPEG1or2VideoStreamFramer or MPEG4VideoStreamFramer) to construct and send the packets. Please provide your inputs whether we are in the right direction or not. Best Regards Y. Mallikharjuna Reddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080213/445ffcaa/attachment.html From finlayson at live555.com Wed Feb 13 07:00:42 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 13 Feb 2008 07:00:42 -0800 Subject: [Live-devel] MP4 streaming implementation in LIVE555 codebase In-Reply-To: <9219A756FBA09B4D8CE75D4D7987D6CB01D8DC1B@KABEX01.sharpamericas.com> References: <200704250410.MAA12762@msr11.hinet.net> <9219A756FBA09B4D8CE75D4D7987D6CB01D8DC1B@KABEX01.sharpamericas.com> Message-ID: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C86E4B.3B145C33" > >Hi Ross, > >We are planning to implement MP4 streaming in server side in LIVE555 >code base with the help of libmp4 library. We have the following >clarifications: > >1. We are planning to create a separate class called >MP4VideoStreamParser which is derived from MPEGVideoStreamParser. >This class (MP4VideoStreamParser) contains methods to parse the MP4 >file and return individual frames and set fTo and fStart variables. A "MPEG4VideoStreamParser" class *already* exists. However, see below... >2. After individual frame is read from MP4 file from above >step, the respective MPEG1or2VideoStreamFramer or >MPEG4VideoStreamFramer classes are called to construct the RTP >packet from the buffer and send the packet to the client. We assume >that MP4 file contains MPEG2 or MPEG4 video data only. Here we have >a clarification here. Do we need to create a separate class called >MP4VideoStreamFramer derived from FramedSource, which does the job >of constructing the RTP packet from the buffer and send the packet >to the client. Or We can use the existing classes >(MPEG1or2VideoStreamFramer or MPEG4VideoStreamFramer) to construct >and send the packets. Because you are generating discrete frames - one at a time - from the "libmp4" library, instead of an unstructured byte stream, you should use the *existing* "MPEG4VideoStreamDiscreteFramer" (for MPEG-4 video) or "MPEG1or2VideoStreamDiscreteFramer" (for MPEG-1 or MPEG-2 video), *instead of* "MPEG4VideoStreamFramer" or "MPEG1or2VideoStreamFramer". Also, as noted above, you don't need to write any new parsing code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vapier.adi at gmail.com Wed Feb 13 22:48:11 2008 From: vapier.adi at gmail.com (Mike Frysinger) Date: Thu, 14 Feb 2008 01:48:11 -0500 Subject: [Live-devel] new config for bfin-linux-uclibc targets Message-ID: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> please include the attached file so people can run: ./genMakefiles bfin-linux-uclibc also, can the file "config.bfin_uclinux" please be renamed to "config.bfin-uclinux" -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: config.bfin-linux-uclibc Type: application/octet-stream Size: 690 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20080213/d90ee3ab/attachment.obj From rvanherk at aht-international.com Thu Feb 14 07:59:07 2008 From: rvanherk at aht-international.com (Ron van Herk) Date: Thu, 14 Feb 2008 16:59:07 +0100 Subject: [Live-devel] live streaming to our HDTV STB Message-ID: Hi, I am new to this list so forgive me if this kind of question has been asked before. My name is Ron van Herk (from the Netherlands, Europe), and also just joined on this list is my colleague from the US, Neel Pahlajani. We have developed a HDTV hybrid STB, using the STMicroelectronics single-chip H264 1080i decoder, running on a Linux operating system. We already succesfully run live555 as a unicast rtsp streamer and broadcast to one or multiple of our devices without any problem. The next step, however is that we want to play live feeds over live555 to the boxes, coming from either a dvb source somewhere or a camera. Can anyone tell us how to do this, or point us in the right direction please? Best regards, Ron ? Ron van Herk ceo / AHT Holding BV Satijnbloem 57 3068 JP Rotterdam Phone +3110 4512440 Fax +3110 2095471 Mobile +31 6 14327235 rvanherk at aht-international.com ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080214/8f02f9a7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: onbekend.jpg Type: image/jpeg Size: 1835 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20080214/8f02f9a7/attachment-0002.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: onbekend.jpg Type: image/jpeg Size: 1590 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20080214/8f02f9a7/attachment-0003.jpg From bgranger at verivue.com Thu Feb 14 08:04:02 2008 From: bgranger at verivue.com (Brett Granger) Date: Thu, 14 Feb 2008 11:04:02 -0500 Subject: [Live-devel] RTSPClientSession and Range: header? Message-ID: <47B46672.8070007@verivue.com> I have a question about the RTSPServer::RTSPClientSession class with regards to the Range: header. In the RTSP 1.0 RFC (2326), under the PLAY request it says: "If no range is specified in the request, the current position is returned in the reply." It's not entirely clear whether this applies only to on-demand streams. Regardless, I interpret this to mean that if there is a PLAY request with no range header, the response will still have a range header indicating the current position? However, in the RTSPClientSession class, there is a comment in the handleCmd_PLAY() method that states "Because we didn't see a Range: header, don't send one back". I'm trying to figure out ways in which I might determine what the current position in an MPEG-2 TS stream is (e.g. VLC doesn't currently do this), and one thought that occurred to me was to issue a PLAY request with no Range or Scale header . If there is an index file for the TS, it seems like this should be feasible, particularly with the recent getNormalPlayTime method? Thanks for any thoughts, --Brett From belloni at imavis.com Thu Feb 14 08:49:24 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Thu, 14 Feb 2008 17:49:24 +0100 Subject: [Live-devel] [Live-develop] Problems with delete in MediaSink.cpp Message-ID: <47B47114.8080705@imavis.com> Hi, I'm streaming videos from an RTSP on demand server with LiveMedia. I wrote my own "FramedSource" subclass and my own "OnDemandServerMediaSubsession" subclass in order to stream frames acquired from my live source, rather than from a file. This solution streams correctly, but when I close my client and it sends a TEARDOWN message to the server, the server crashes with SIGABRT and a message of "rtspServer: munmap_chunk(): invalid pointer: 0x08193dc0 ***". Further investigation leads me to locate the offending instruction in MediaSink.cpp OutPacketBuffer::~OutPacketBuffer() method. In particular, the signal is generated when I try to execute the instruction delete[] fBuf; The method is called respectively by ~H263plusVideoRTPSink destroyer function, called by MediaLookupTable::remove method. Why does it happen? the only interaction I have with H263plusVideoRTPSink is when i create it in createNewRTPSink, defined in my OnDemandServerMediaSubsession subclass, like this: RTPSink* EncH263plusVideoFileServerMediaSubsession:: createNewRTPSink(Groupsock* rtpGroupsock, unsigned char rtpPayloadTypeIfDynamic, FramedSource* inputSource) { return H263plusVideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); } Is it the correct way to create the sink? And what could cause the corrupt or double-delete in ~OutPacketBuffer? Thanks in advance, Best Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From ralf.buhlrich at rheinmetall.com Fri Feb 15 05:02:26 2008 From: ralf.buhlrich at rheinmetall.com (Ralf Buhlrich) Date: Fri, 15 Feb 2008 14:02:26 +0100 Subject: [Live-devel] LGPL version ? Message-ID: <1203080546.19038.12.camel@ftlxwks003.defence-elec.de> Hi list, under which version of the LGPL is the liveMedia, v3 or v2.1 ? Best Regards Ralf Buhlrich -- Geschäftsführung/Management Board Rheinmetall Defence Electronics GmbH: Dipl.-Wirtsch.-Ing. Georg Morawitz Dipl.-Ing. Luitjen Ennenga Dipl.-Ing.Ulrich Sasse Sitz der Gesellschaft/Registered Office: Bremen Register/Commercial Register: Amtsgericht Bremen, HRB 9659 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. The statements contained in this message are not legally binding unless confirmed in writing. This message may contain confidential information. If you are not the intended recipient, or if this message and its annexes contains information which is apparently not meant for you, please notify us immediately and - to the extent you are not the intended recipient - please delete this message and all its attachments from your system and destroy any copy made therefrom. Any unauthorized review, delivery, distribution, transmission, storage, printing or otherwise making use of the message and its attachments are strictly prohibited. In case your systems have been infected by virus or otherwise negatively affected by this message, we will not be liable for any damage resulting therefrom unless in case of gross negligence or wilful misconduct. Geschäftsführung/Management Board Rheinmetall Technical Publications GmbH: Dipl.-Ing. Jörg Daniel Sitz der Gesellschaft/Registered Office: Bremen Register/Commercial Register: Amtsgericht Bremen, HRB 24359 HB From finlayson at live555.com Fri Feb 15 13:06:22 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Feb 2008 07:06:22 +1000 Subject: [Live-devel] live streaming to our HDTV STB In-Reply-To: References: Message-ID: >We already succesfully run live555 as a unicast rtsp streamer and >broadcast to one or multiple of our devices without any problem. > >The next step, however is that we want to play live feeds over >live555 to the boxes, coming from either a dvb source somewhere or a >camera. > >Can anyone tell us how to do this, or point us in the right direction please? Ron, The best starting point is our FAQ: http://www.live555.com/liveMedia/faq.html -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Feb 15 13:30:01 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Feb 2008 07:30:01 +1000 Subject: [Live-devel] new config for bfin-linux-uclibc targets In-Reply-To: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> References: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> Message-ID: >please include the attached file so people can run: >./genMakefiles bfin-linux-uclibc > >also, can the file "config.bfin_uclinux" please be renamed to >"config.bfin-uclinux" What is the intended difference between "bfin-linux-uclibc" (which you provided) and "bfin-uclinux" (which someone else provided a few weeks ago)? Should there be only one such configuration file, or is there a reason to have both? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Feb 15 13:50:55 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Feb 2008 07:50:55 +1000 Subject: [Live-devel] [Live-develop] Problems with delete in MediaSink.cpp In-Reply-To: <47B47114.8080705@imavis.com> References: <47B47114.8080705@imavis.com> Message-ID: Cristiano, What you're doing looks OK. Perhaps the first thing you could look into is to check whether your RTPSink (subclass)'s destructor is somehow getting called more than once (for each instance of the class). Obviously this shouldn't be happening, but it would explain the symptoms that you're seeing. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Feb 15 14:05:57 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Feb 2008 08:05:57 +1000 Subject: [Live-devel] RTSPClientSession and Range: header? In-Reply-To: <47B46672.8070007@verivue.com> References: <47B46672.8070007@verivue.com> Message-ID: >I'm trying to figure out ways in which I might determine what the >current position in an MPEG-2 TS stream is (e.g. VLC doesn't currently >do this) The best way to do this - in your case - is to just look at the PCR timestamps that are embedded within the Transport Stream data. This is what the decoder will be doing anyway, so you might as well use the same information (which you get without doing anything related to RTP or RTSP). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vapier.adi at gmail.com Fri Feb 15 16:02:58 2008 From: vapier.adi at gmail.com (Mike Frysinger) Date: Fri, 15 Feb 2008 19:02:58 -0500 Subject: [Live-devel] new config for bfin-linux-uclibc targets In-Reply-To: References: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> Message-ID: <8bd0f97a0802151602o73a973b3tf38446b341098fa@mail.gmail.com> On Fri, Feb 15, 2008 at 4:30 PM, Ross Finlayson wrote: > >please include the attached file so people can run: > >./genMakefiles bfin-linux-uclibc > > > >also, can the file "config.bfin_uclinux" please be renamed to > >"config.bfin-uclinux" > > What is the intended difference between "bfin-linux-uclibc" (which > you provided) and "bfin-uclinux" the two toolchains produce different binary object formats. > (which someone else provided a few weeks ago)? i know, a co-worker of mine sent it over. > Should there be only one such configuration file, or is > there a reason to have both? since the binary object format needs to be specified to the linker, it is not possible to do one configuration file. unless you want to force people to (in addition to running the genMakefiles script) explicitly set the required linker flags on the command line. -mike From finlayson at live555.com Fri Feb 15 19:06:14 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Feb 2008 13:06:14 +1000 Subject: [Live-devel] new config for bfin-linux-uclibc targets In-Reply-To: <8bd0f97a0802151602o73a973b3tf38446b341098fa@mail.gmail.com> References: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> <8bd0f97a0802151602o73a973b3tf38446b341098fa@mail.gmail.com> Message-ID: > > What is the intended difference between "bfin-linux-uclibc" (which >> you provided) and "bfin-uclinux" > >the two toolchains produce different binary object formats. OK, thanks for the explanation. My next question, then is: Are those the best names? Will it be obvious to a prospective developer what the difference is between "bfin-linux-uclibc" and "bfin-uclinux"? If not, then can you suggest clearer names? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Feb 15 19:13:42 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Feb 2008 13:13:42 +1000 Subject: [Live-devel] LGPL version ? In-Reply-To: <1203080546.19038.12.camel@ftlxwks003.defence-elec.de> References: <1203080546.19038.12.camel@ftlxwks003.defence-elec.de> Message-ID: >under which version of the LGPL is the liveMedia, v3 or v2.1 ? 2.1. (A reference to the LGPL is included - as a comment - at the top of each of our source files.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vapier.adi at gmail.com Fri Feb 15 19:18:32 2008 From: vapier.adi at gmail.com (Mike Frysinger) Date: Fri, 15 Feb 2008 22:18:32 -0500 Subject: [Live-devel] new config for bfin-linux-uclibc targets In-Reply-To: References: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> <8bd0f97a0802151602o73a973b3tf38446b341098fa@mail.gmail.com> Message-ID: <8bd0f97a0802151918y6a5b5b87ma3b3ef73e6f60552@mail.gmail.com> On Feb 15, 2008 10:06 PM, Ross Finlayson wrote: > > > What is the intended difference between "bfin-linux-uclibc" (which > >> you provided) and "bfin-uclinux" > > > >the two toolchains produce different binary object formats. > > OK, thanks for the explanation. My next question, then is: Are those > the best names? Will it be obvious to a prospective developer what > the difference is between "bfin-linux-uclibc" and "bfin-uclinux"? If > not, then can you suggest clearer names? the tuples exactly match the toolchains. so if people are not familiar with those two tuples, they arent familiar with compiling for the Blackfin processor :) they also wont be mixing the two toolchains as any attempt to do so will result in a link error so the short answer: there are no better names :) -mike From finlayson at live555.com Fri Feb 15 19:34:30 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 16 Feb 2008 13:34:30 +1000 Subject: [Live-devel] new config for bfin-linux-uclibc targets In-Reply-To: <8bd0f97a0802151918y6a5b5b87ma3b3ef73e6f60552@mail.gmail.com> References: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> <8bd0f97a0802151602o73a973b3tf38446b341098fa@mail.gmail.com> <8bd0f97a0802151918y6a5b5b87ma3b3ef73e6f60552@mail.gmail.com> Message-ID: OK, thanks. The new config file (and the renamed old one) will appear in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Sat Feb 16 03:58:23 2008 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Sat, 16 Feb 2008 15:58:23 +0400 Subject: [Live-devel] Problems "seeking" in MPEG2 TS? In-Reply-To: <479A2AA3.2080800@verivue.com> References: <4797B63B.3070504@verivue.com> <4798C452.4070401@verivue.com> <479A2AA3.2080800@verivue.com> Message-ID: <3cc3561f0802160358u318cfc6t562e7380e32b9ec6@mail.gmail.com> I have seen the same "problem" by jumping between GOPs. If I drop showing one GOP, and go directly to the next, then a black image is shown (or a still image) until the point where the new GOP is supposed to go. I guess VLC uses the DTS or PTS in the PES packets to decide when to show a frame. Since I set the discontinuity bit in the transport stream packet, it should have reset that timer, which it seems that it does not do. I guess that the same thing happens here, that it somehow gets data about the start time of the stream, and since the PTS timestap is 15s in the future, it waits 15s before showing the frame. Mplayer does not do this. -Morgan- On 25/01/2008, Brett Granger wrote: > Ross Finlayson wrote: > >> However, I have now exposed a second issue, which I believe is a bug in > >> VLC (unless it's an issue with the 2006.03.16 release of liveMedia > >> against which VLC is built) > > > > I'm interested only in LIVE555-related bugs that occur when VLC is > > built with the *latest* version of the "LIVE555 Streaming Media" code. > > Fair enough. I've rebuilt VLC against the latest live555 code and the > bug still occurs (at least, I consider it to be a bug to have to wait 15 > seconds to see video again after having issued a "seek +15" command). > I'll take it to the VLC list. > > Thanks again for the support and the great software, > --Brett > > > > > > Bugs in VLC (rather than the "LIVE555 Streaming Media" code) should > > be reported to the "vlc at videolan.org" mailing list. > > -- > > > > 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 morgan.torvolt at gmail.com Sat Feb 16 04:14:47 2008 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Sat, 16 Feb 2008 16:14:47 +0400 Subject: [Live-devel] RE : Re: bug found and corrected In-Reply-To: <477156.16791.qm@web25912.mail.ukl.yahoo.com> References: <200802012202.m11M205H024053@ns.live555.com> <477156.16791.qm@web25912.mail.ukl.yahoo.com> Message-ID: <3cc3561f0802160414q5a2fb8b8t17ac89053eb78e18@mail.gmail.com> May I suggest setting the duration so that every package is sent instantly? The DVB-T and other DVB standards demand PCR withing 500ns accuracy, which is probably better than you will ever be able to get. I think it is safe to assume that the timing of what you receive is more than good enough, and just drop the MPEG2TransportStreamFramer code alltogether. For the RTP timestamps to behave you have to set the durationPerPacket to something sane though, and that will almost certainly go wrong after a while due to rounding errors. As I have suggested before, the BasicUDPSink (and others) should be allowed to receive a timestamp instead of an duration per packet number so that one can choose the time to be "current time" for every packet, in effect sending it instantly. I have done this with great success myself. This completely removes the need for any PCR compensation, gives no problems with insane VBR streams (like some of those hundreds of still-image sex-hotline channels out there. Is it just me or are most of them from italy? In practise they only sends an I frame from time to time), and releaves the CPU of doing the PCR calculations. -Morgan- On 06/02/2008, roor0735-ml at yahoo.fr wrote: > I agree, it is not really a bug. In fact, your library is used to stream > live DVB-T MPEG2 Transport stream in real-time over the network. So, I think > it will be hard to calculate indexes before streaming the recording TS > files. > Concerning the proposed changes, I try to find a better way to correct the > packet duration estimation issues. Normally, the PCR should be annouced with > a quite regular periodicity. If the packet interval between two PCR > annoucement is too low compared to the mean periodiciy of the PCR, then the > PCR must be ignored in order to not introduce errors in the packet duration > estimation. So, I introduce a > new constant called PCR_PERIOD_VARIATION_RATIO that adjusts the minimum and > tolerated packet interval from the mean PCR announcement period. > > For instance, in my sequence, the mean period of PCR announcement converges > to around 47. The ratio is set to 50%, so the minimum packet interval > between two PCR is 23. I think this method is less arbitrary than the "20" > value. > > I hope this can help people that wants to broadcast VBR multiplexed > dataflows. > Regards, > Romain > > > Ross Finlayson a ?crit : > Thanks. However, the existing code is not really a 'bug', although > your suggested change is (arguably) an improvement. > > As you noticed, the current per-transport-packet duration estimation > code has trouble converging on a stable estimate for streams - such > as yours - that are wildly VBR. Your suggested change will probably > help things (although I can also imagine streams for which it might > make things worse by taking longer to converge to the 'correct' > average duration). I am also a bit concerned about the arbitrariness > of the constant "20" that you use. > > Nonetheless, I'll add your change to the next release of the library. > > (Looking longer-term, a better solution for streaming prerecorded > files (but not live streams) will be to extend the existing "index > file" mechanism to include accurate durations - which could be > computed in advance when generating the index file.) > > > Ross Finlayson > Live Networks, Inc. (LIVE555.COM) > > > > > ________________________________ > Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! > Mail > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > From vapier.adi at gmail.com Sat Feb 16 04:21:32 2008 From: vapier.adi at gmail.com (Mike Frysinger) Date: Sat, 16 Feb 2008 07:21:32 -0500 Subject: [Live-devel] new config for bfin-linux-uclibc targets In-Reply-To: References: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> <8bd0f97a0802151602o73a973b3tf38446b341098fa@mail.gmail.com> <8bd0f97a0802151918y6a5b5b87ma3b3ef73e6f60552@mail.gmail.com> Message-ID: <8bd0f97a0802160421l455efc38g82bf09c29ef54ed4@mail.gmail.com> On Feb 15, 2008 10:34 PM, Ross Finlayson wrote: > OK, thanks. The new config file (and the renamed old one) will > appear in the next release of the software. thanks! is there an announce list i could subscribe to ? -mike From morgan.torvolt at gmail.com Sat Feb 16 04:31:40 2008 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Sat, 16 Feb 2008 16:31:40 +0400 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications Message-ID: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> Hi all I am having some weird problems at the moment. I am running a server and a laptop with the exact same kernel and software (obviously different hardware), and having some strange problems with that. On my laptop, starting the testOnDemandRTSPServer takes no time at all. On my server, the application uses a few seconds to start. Running valgrind and killing the process while in this "waiting state" at the beginning tells me: ==26912== Process terminating with default action of signal 2 (SIGINT) ==26912== at 0x568D053: select (in /lib/libc-2.6.1.so) ==26912== by 0x448116: readSocket(UsageEnvironment&, int, unsigned char*, unsigned, sockaddr_in&, timeval*) (in /home/mt/live/testProgs/testOnDemandRTSPServer) ==26912== by 0x44868B: ourSourceAddressForMulticast(UsageEnvironment&) (in /home/mt/live/testProgs/testOnDemandRTSPServer) ==26912== by 0x428EC0: RTSPServer::rtspURLPrefix(int) const (in /home/mt/live/testProgs/testOnDemandRTSPServer) ==26912== by 0x428EEC: RTSPServer::rtspURL(ServerMediaSession const*, int) const (in /home/mt/live/testProgs/testOnDemandRTSPServer) ==26912== by 0x40223A: announceStream(RTSPServer*, ServerMediaSession*, char const*, char const*) (in /home/mt/live/testProgs/testOnDemandRTSPServer) ==26912== by 0x4023AE: main (in /home/mt/live/testProgs/testOnDemandRTSPServer) Since "readSocket(UsageEnvironment" only exists in GroupsockHelper.cpp and GroupsockHelper.hh, and there is only one select in the entire file, I am pretty sure the delay happens at line 229 in GroupsockHelper.cpp. The server seems to also output a different IP address than the laptop as well, laptop using eth0, while the server uses... eh, some other address: "mpeg4ESVideoTest" stream, from the file "test.m4e" Play this stream using the URL "rtsp://127.0.1.1:8554/mpeg4ESVideoTest" It seems from the trace that the ourSourceAddressForMulticast is the sinner. Firstly, what does multicast have to do with the RTSP server? Is that not purely unicast? Secondly, how can I remove this delay? It is not critical, but quite annoying, especially the fact that my lousy laptop "performs better" from the client point of view =) As mentioned, running the exact same kernel, so multicast support should be the same in both. They are the latest realtime kernels from Ubuntu. Thanks for any help with this. -Morgan Torvolt- From morgan.torvolt at gmail.com Sat Feb 16 04:54:00 2008 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Sat, 16 Feb 2008 16:54:00 +0400 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications In-Reply-To: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> References: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> Message-ID: <3cc3561f0802160454o6cec662aw2f03d45df96d5c95@mail.gmail.com> Having done some more research, I am lead to believe that the problem could be that my server eth0 interface is connected to a cheap-ass broadband router, which may or more probably may not support multicast. I also have a firewall on that interface which might eat the packet. It is also natural to use that packet as the default route is trough there =) As the server has two interfaces, and the eth1 interface is the one I want the server running at, is there a way a can specify this when creating the RTSPserver? It seems to me that this is not possible. I get the 127.0.1.1 address anyway. If this address is nessesary to have in things like SIP announce or other things that I know too little about, I can see the use of using this method. For my part, I already know the IP of the server, so I see no real reason for me to try to figure it out. A quick-fix for me is to reduce the timeout time to something like 100ms, but the way this is done seems sub-optimal to me. Would you be interested in me rewriting this ourSourceAddressForMulticast function Ross, doing things a bit differently (i.e testing on all interfaces except 127 in parallel, choosing the fastest interface, and if no success use the lo 127 interface address? I cannot test this on anything but amd64 linux though. Regards Morgan T?rvolt On 16/02/2008, Morgan T?rvolt wrote: > Hi all > > I am having some weird problems at the moment. I am running a server > and a laptop with the exact same kernel and software (obviously > different hardware), and having some strange problems with that. > > On my laptop, starting the testOnDemandRTSPServer takes no time at > all. On my server, the application uses a few seconds to start. > Running valgrind and killing the process while in this "waiting state" > at the beginning tells me: > > > ==26912== Process terminating with default action of signal 2 (SIGINT) > ==26912== at 0x568D053: select (in /lib/libc-2.6.1.so) > ==26912== by 0x448116: readSocket(UsageEnvironment&, int, unsigned > char*, unsigned, sockaddr_in&, timeval*) (in > /home/mt/live/testProgs/testOnDemandRTSPServer) > ==26912== by 0x44868B: > ourSourceAddressForMulticast(UsageEnvironment&) (in > /home/mt/live/testProgs/testOnDemandRTSPServer) > ==26912== by 0x428EC0: RTSPServer::rtspURLPrefix(int) const (in > /home/mt/live/testProgs/testOnDemandRTSPServer) > ==26912== by 0x428EEC: RTSPServer::rtspURL(ServerMediaSession > const*, int) const (in /home/mt/live/testProgs/testOnDemandRTSPServer) > ==26912== by 0x40223A: announceStream(RTSPServer*, > ServerMediaSession*, char const*, char const*) (in > /home/mt/live/testProgs/testOnDemandRTSPServer) > ==26912== by 0x4023AE: main (in > /home/mt/live/testProgs/testOnDemandRTSPServer) > > > Since "readSocket(UsageEnvironment" only exists in GroupsockHelper.cpp > and GroupsockHelper.hh, and there is only one select in the entire > file, I am pretty sure the delay happens at line 229 in > GroupsockHelper.cpp. > > The server seems to also output a different IP address than the laptop > as well, laptop using eth0, while the server uses... eh, some other > address: > > "mpeg4ESVideoTest" stream, from the file "test.m4e" > Play this stream using the URL "rtsp://127.0.1.1:8554/mpeg4ESVideoTest" > > It seems from the trace that the ourSourceAddressForMulticast is the > sinner. Firstly, what does multicast have to do with the RTSP server? > Is that not purely unicast? Secondly, how can I remove this delay? It > is not critical, but quite annoying, especially the fact that my lousy > laptop "performs better" from the client point of view =) > > As mentioned, running the exact same kernel, so multicast support > should be the same in both. They are the latest realtime kernels from > Ubuntu. > > Thanks for any help with this. > > -Morgan Torvolt- > From finlayson at live555.com Sat Feb 16 15:57:57 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 17 Feb 2008 09:57:57 +1000 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications In-Reply-To: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> References: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> Message-ID: >It seems from the trace that the ourSourceAddressForMulticast is the >sinner. Firstly, what does multicast have to do with the RTSP server? >Is that not purely unicast? The name of that function is an anachronism; I should rename it to "ourSourceAddress()"... Apart from perhaps renaming it, I have no current plans to change this function. (A reminder: Serious professionals do not use "@gmail.com" email addresses :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Feb 16 16:59:37 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 17 Feb 2008 10:59:37 +1000 Subject: [Live-devel] new config for bfin-linux-uclibc targets In-Reply-To: <8bd0f97a0802160421l455efc38g82bf09c29ef54ed4@mail.gmail.com> References: <8bd0f97a0802132248x7179748bvafa8043435d70668@mail.gmail.com> <8bd0f97a0802151602o73a973b3tf38446b341098fa@mail.gmail.com> <8bd0f97a0802151918y6a5b5b87ma3b3ef73e6f60552@mail.gmail.com> <8bd0f97a0802160421l455efc38g82bf09c29ef54ed4@mail.gmail.com> Message-ID: >is there an announce list i could subscribe to ? No, but that's a good idea; I'll look into it. For now, just keep checking -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Feb 16 17:03:52 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 17 Feb 2008 11:03:52 +1000 Subject: [Live-devel] Problems "seeking" in MPEG2 TS? In-Reply-To: <3cc3561f0802160358u318cfc6t562e7380e32b9ec6@mail.gmail.com> References: <4797B63B.3070504@verivue.com> <4798C452.4070401@verivue.com> <479A2AA3.2080800@verivue.com> <3cc3561f0802160358u318cfc6t562e7380e32b9ec6@mail.gmail.com> Message-ID: Once again: Bugs in VLC (rather than the "LIVE555 Streaming Media" code) should be reported to the "vlc at videolan.org" mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From DEASTA at aol.com Sun Feb 17 11:19:35 2008 From: DEASTA at aol.com (DEASTA at aol.com) Date: Sun, 17 Feb 2008 14:19:35 EST Subject: [Live-devel] Problems "seeking" in MPEG2 TS? Message-ID: In my experience, problems with VLC playing back a TS streamed by Live555 have ended up being that the TS is not up to specification (bad timing or protocol errors) that are not handled by Live555 nor VLC. A suggestion would be to verify the quality of the TS before looking into bugs with either software. In a message dated 2/16/2008 6:13:04 P.M. US Mountain Standard Time, finlayson at live555.com writes: Once again: Bugs in VLC (rather than the "LIVE555 Streaming Media" code) should be reported to the "vlc at videolan.org" mailing list. -- 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 **************Ideas to please picky eaters. Watch video on AOL Living. (http://living.aol.com/video/how-to-please-your-picky-eater/rachel-campos-duffy/ 2050827?NCID=aolcmp00300000002598) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080217/f920867a/attachment-0001.html From belloni at imavis.com Mon Feb 18 02:41:31 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Mon, 18 Feb 2008 11:41:31 +0100 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications In-Reply-To: References: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> Message-ID: <47B960DB.40908@imavis.com> Ross Finlayson wrote: > (A reminder: Serious professionals do not use "@gmail.com" email addresses :-) > I'm curious about that. Why? :) -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From morgan.torvolt at gmail.com Mon Feb 18 03:53:20 2008 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Mon, 18 Feb 2008 15:53:20 +0400 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications In-Reply-To: References: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> Message-ID: <3cc3561f0802180353j50f6d409ob026572ed1c2eed4@mail.gmail.com> On 17/02/2008, Ross Finlayson wrote: > >It seems from the trace that the ourSourceAddressForMulticast is the > >sinner. Firstly, what does multicast have to do with the RTSP server? > >Is that not purely unicast? > > The name of that function is an anachronism; I should rename it to > "ourSourceAddress()"... > > Apart from perhaps renaming it, I have no current plans to change > this function. > > (A reminder: Serious professionals do not use "@gmail.com" email addresses :-) > -- Ross, we had this discussion before, both in the mailing list and outside of it I believe ;-) As for the real issue, do you not see the fact that it slows down the startup process as a real problem? What about the part where it is resolving a "wrong" IP address? It seems obvious to me that the hardcoded test IP and port numbers is a unfortunate way of doing this IP check. I suggest checking the routing table, seeing which interface gets the default route, and then getting the IP of that interface. If you do not bother though, fine. I will keep my little "temporary" fix =) -Morgan- From belloni at imavis.com Mon Feb 18 09:02:33 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Mon, 18 Feb 2008 18:02:33 +0100 Subject: [Live-devel] [Live-develop] Problems with delete in MediaSink.cpp In-Reply-To: References: <47B47114.8080705@imavis.com> Message-ID: <47B9BA29.9060401@imavis.com> Ross Finlayson wrote: > Cristiano, > > What you're doing looks OK. Perhaps the first thing you could look > into is to check whether your RTPSink (subclass)'s destructor is > somehow getting called more than once (for each instance of the > class). Obviously this shouldn't be happening, but it would explain > the symptoms that you're seeing. > I did a little debug, and discovered my OnDemandServerMediaSubsession subclass gets created twice when a stream is requested. It consequently creates two H263plusVideoRTPSink instances. May this be the the problem? Here it is a snippet of my debug results: Play this stream using the URL "rtsp://192.168.1.77/video" (stream request by VLC) Started a new EncH263plusVideoFileServerMediaSubsession Done Creating new sink Started a new EncH263plusVideoFileServerMediaSubsession Done Creating new sink (creates two EncH263plusVideoFileServerMediaSubsession and two sinks) H263FramedSource: Calling deliverFrame() (starts delivering frames) Frame 0 long 5302 I create the media session etc like that in the main(): ServerMediaSession* sms = ServerMediaSession::createNew(*env, streamName, streamName, descriptionString); EncH263plusVideoFileServerMediaSubsession* mss = EncH263plusVideoFileServerMediaSubsession::createNew(*env, inputSink, reuseFirstSource); sms->addSubsession(mss); rtspServer->addServerMediaSession(sms); announceStream(rtspServer, sms, streamName, inputSink); Am I doing something wrong? Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From belloni at imavis.com Mon Feb 18 09:27:03 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Mon, 18 Feb 2008 18:27:03 +0100 Subject: [Live-devel] [Live-develop] Problems with delete in MediaSink.cpp In-Reply-To: <47B9BA29.9060401@imavis.com> References: <47B47114.8080705@imavis.com> <47B9BA29.9060401@imavis.com> Message-ID: <47B9BFE7.4080503@imavis.com> Cristiano Belloni wrote: > Ross Finlayson wrote: > >> Cristiano, >> >> What you're doing looks OK. Perhaps the first thing you could look >> into is to check whether your RTPSink (subclass)'s destructor is >> somehow getting called more than once (for each instance of the >> class). Obviously this shouldn't be happening, but it would explain >> the symptoms that you're seeing. >> >> > I did a little debug, and discovered my OnDemandServerMediaSubsession > subclass gets created twice when a stream is requested. It consequently > creates two H263plusVideoRTPSink instances. May this be the the problem? > > Here it is a snippet of my debug results: > > Play this stream using the URL "rtsp://192.168.1.77/video" > (stream request by VLC) > Started a new EncH263plusVideoFileServerMediaSubsession > Done > Creating new sink > Started a new EncH263plusVideoFileServerMediaSubsession > Done > Creating new sink > (creates two EncH263plusVideoFileServerMediaSubsession and two sinks) > H263FramedSource: Calling deliverFrame() > (starts delivering frames) > Frame 0 long 5302 > > I create the media session etc like that in the main(): > > ServerMediaSession* sms > = ServerMediaSession::createNew(*env, streamName, streamName, > descriptionString); > > EncH263plusVideoFileServerMediaSubsession* mss = > EncH263plusVideoFileServerMediaSubsession::createNew(*env, inputSink, > reuseFirstSource); > > sms->addSubsession(mss); > rtspServer->addServerMediaSession(sms); > announceStream(rtspServer, sms, streamName, inputSin