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, inputSink); > > Am I doing something wrong? > > Regards, > > Cristiano. > > Seems i found the problem: I was creating also a H263plusVideoStreamFramer in the subclass, other than my custom source. Don't know why, maybe the line of code survived a mindless copy-paste :) -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From finlayson at live555.com Mon Feb 18 13:27:58 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Feb 2008 07:27:58 +1000 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications In-Reply-To: <3cc3561f0802180353j50f6d409ob026572ed1c2eed4@mail.gmail.com> References: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> <3cc3561f0802180353j50f6d409ob026572ed1c2eed4@mail.gmail.com> Message-ID: I've found that the existing approach - send a multicast packet, receive it, and look at the source address - is the most reliable way, for most people's systems, to find their source address. If that fails, we try calling gethostname()+gethostbyname(). The combination of those two methods seems to work for most people. (Remember also that we want code that will work on Windoze systems as well as Unix.) Those rare people who have weird systems for which this doesn't work are welcome to write their own implementation, of course. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Feb 18 13:26:33 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 19 Feb 2008 07:26:33 +1000 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications In-Reply-To: <47B960DB.40908@imavis.com> References: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> <47B960DB.40908@imavis.com> Message-ID: > > (A reminder: Serious professionals do not use "@gmail.com" email >addresses :-) >> >I'm curious about that. Why? :) Because they will want their email address to indicate the name of their company or school, to show that they have one. Otherwise (if they just use a "@gmail.com", "@yahoo.com", "@hotmail.com" etc. address), most people (including I) will assume that they are simply a casual hobbyist, not affiliated with an Internet-savvy company or school). (Not that there's anything wrong with being a casual hobbyist; they are welcome on this mailing list, but they risk not getting as much attention as professionals.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From cupery at sina.com Wed Feb 20 01:23:29 2008 From: cupery at sina.com (cupery at sina.com) Date: Wed, 20 Feb 2008 17:23:29 +0800 Subject: [Live-devel] Streaming live MPEG4 stream Message-ID: <20080220092329.71025.qmail@mail3-32.sinamail.sina.com.cn> hi Ross, I want to use livemedia rtsp server to stream live MPEG4 video. I read the testOndemandServerRTSPServer, it uses FramedFileSource as source, the program will first open the source file, read as many bytes as it can to fill in the buffer, call parser to parse and get some info, then start play and re-open the file and read again from the file head into another buffer, and during the play, it will call the parser to parse the data many times. My question is, is my description above right? And in my program, I write my own MPEG4LiveServerMediaSubsession(from ServerMediaSubsession) and MPEG4FramedLiveSource(from Framed Souce), the live source send one frame each time, but I found the parser can't find enough info in one frame. Do I need to save them in a big buffer all the time so that the parser can parse rightly? If the frames data are not enough, can I break the parser and wait more frames? Is there some other live framedsource code I can read in the livemedia codes? Best reguards. cupery ------------------------------------------------------------------- ??????????"???? ????"( http://d1.sina.com.cn/sina/limeng3/mail_zhuiyu/2008/mail_zhuiyu_20080218.html ) =================================================================== ??????????????????????http://bbs.bj.sina.com.cn/tableforum/App/index.php?bbsid=143&subid=0&ismain=1? From luen_2 at hotmail.com Wed Feb 20 05:18:37 2008 From: luen_2 at hotmail.com (fung ka luen) Date: Wed, 20 Feb 2008 13:18:37 +0000 Subject: [Live-devel] A network problem Message-ID: Dear All, I have a network problem when doing the streaming from a server to my client PCs. When both server and clients run under same private, everything OK. But, under the following setup, not OK. The Live555MediaServer is hosted on a linux machine with a real IP like (66.147.231.80, out of my school). I am using OpenRTSP as a client and run in my private network (192.168.100.101 and 192.168.100.102). My router is a Linksys with real IP like (144.214.45.50, my school's IP). When I run the OpenRTSP with ¡°-V ¨CQ rtsp://66.147.231.80/video.mpg¡±, the RTSP¡¯s text shows on the screen. However, the Qos shows the not data was streamed from the server. (all items show unavailable or 0) Did anyone have similar experience and any solution of this case? Thank you very much -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080220/157a0e56/attachment.html From ferruccio.fiorucci at gmail.com Wed Feb 20 06:12:47 2008 From: ferruccio.fiorucci at gmail.com (Ferruccio Fiorucci) Date: Wed, 20 Feb 2008 15:12:47 +0100 Subject: [Live-devel] Axis camera Message-ID: <2830135d0802200612i7017bf6ch2396258324246bc4@mail.gmail.com> Hello, I'm trying to use the openrtsp program in order to connect to an Axis camera ( axis 207 ) unsuccesful!!! All seems to go well, I sand to camera all the right commands ( DESCRIBE, PLAY, and so on..) but when i can see in the shell "Receiving streamed data", I cant save the data in a file. The program creates the file, but it's empty ( its dimension is 30 Byte ). The parameters I use are: openRTSP -d 10 -S 54 -n -F prova rtsp://192.168.3.140/mpeg4/media.amp I tried to use it also without -S option and with -4 option, but the result is the same. There is someone can help me, please? thanks Best Regards Ferruccio -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080220/30bf6f4a/attachment-0001.html From s.boschi at totalwire.it Wed Feb 20 06:38:50 2008 From: s.boschi at totalwire.it (Sigismondo Boschi) Date: Wed, 20 Feb 2008 15:38:50 +0100 Subject: [Live-devel] Axis camera In-Reply-To: <2830135d0802200612i7017bf6ch2396258324246bc4@mail.gmail.com> References: <2830135d0802200612i7017bf6ch2396258324246bc4@mail.gmail.com> Message-ID: <47BC3B7A.9080605@totalwire.it> Ferruccio Fiorucci wrote: > Hello, > > I'm trying to use the openrtsp program in order to connect to an Axis > camera ( axis 207 ) unsuccesful!!! > All seems to go well, I sand to camera all the right commands ( > DESCRIBE, PLAY, and so on..) but when i can see in the shell "Receiving > streamed data", I cant save the data in a file. > The program creates the file, but it's empty ( its dimension is 30 Byte ). > The parameters I use are: > > openRTSP -d 10 -S 54 -n -F prova rtsp://192.168.3.140/mpeg4/media.amp > Hi, I can do it successfully, with an Axis camera. However I have slightly different options (maybe older/newer version... openRTSP.exe -e 10 -F test rtsp://192.168.0.42/mpeg4/media.amp ). Be careful with firewalls (I mean Windows or Linux ones), because the client is working as an UDP server. Try with the "-t" option - it lets the RTP communication take place over the estabilished TCP connection. Ciao, Sigismondo -- ------------------------------------------------------------------ Sigismondo Boschi, PhD TotalWire S.r.l. s.boschi at totalwire.it http://www.totalwire.it cell: +39 346 7911896 tel: +39 051 302696 -------------- next part -------------- A non-text attachment was scrubbed... Name: s_boschi.vcf Type: text/x-vcard Size: 275 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20080220/bc1b24d1/attachment.vcf From xcsmith at rockwellcollins.com Wed Feb 20 09:14:54 2008 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 20 Feb 2008 11:14:54 -0600 Subject: [Live-devel] Axis camera In-Reply-To: <2830135d0802200612i7017bf6ch2396258324246bc4@mail.gmail.com> Message-ID: > I'm trying to use the openrtsp program in order to connect to an > Axis camera ( axis 207 ) unsuccesful!!! > All seems to go well, I sand to camera all the right commands ( > DESCRIBE, PLAY, and so on..) but when i can see in the shell > "Receiving streamed data", I cant save the data in a file. > The program creates the file, but it's empty ( its dimension is 30 Byte ). > The parameters I use are: > > openRTSP -d 10 -S 54 -n -F prova rtsp://192.168.3.140/mpeg4/media.amp > > I tried to use it also without -S option and with -4 option, but the > result is the same. > > There is someone can help me, please? > I worked on a Linux system and had a similar symptom for a couple different problems. 1. The first problem was the multicast configuration of the network. On my system it worked if we enabled IP forwarding and also enabled multicast specifically. I combined all the suggestions I'd seen on this list and websites, and this combination of commands solved the problem on my system. (Although there could(?) be some security issues with enabling IP forwarding; I couldn't really say whether or not it's a "good idea.") $> su root $> /sbin/route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1 $> echo 1 > /proc/sys/net/ipv4/ip_forward $> /sbin/ifconfig eth1 multicast $> netstat -r -n 2. The second problem was that after a software update, the "camera" I had began sending RTP packets which indicated they were RTP version 1.0 packets and not version 2.0 packets. The RTP packets were being discarded because they were mis-labeled. (I'm not sure if this was LIVE555 behavior or the behavior of some other part of our system now. It's been awhile.) Good Luck! xo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080220/1f88fe06/attachment.html From matteo.trotti at elsagdatamat.com Wed Feb 20 09:20:13 2008 From: matteo.trotti at elsagdatamat.com (Trotti Matteo) Date: Wed, 20 Feb 2008 18:20:13 +0100 Subject: [Live-devel] unicast streaming file size Message-ID: <2C40B6677517864290A75239797ED67804CB5D7E@ELS00WMX01.elsag.it> Hi all, I am developing a server application which uses live555 in order to stream via unicast mp4 ES video files. Till now, my approach is very similar to TestOnDemandRTSPServer. I am facing some problems in server architecture implementation: I need to perform file seeking and we know that live555 doesn't support this kind of server-side operation yet (for m4e files). I read FAQ about the proper way to support seeking: implement virtual functions duration() and seekStreamSource() in ServerMediaSubsession. By the way, I was just wondering about doing something a little easier. Looking at testMpeg4VideoStreamer (which is multicast streaming solution), I noticed that I can ask for ByteStreamFileSource::fileSize and with this information in my hands, it would be simple to insert a seek function based on file dimension. So my question is: can I use OnDemandRTSPserver approach and have access to file size, being able to perform a seek operation on that file before streaming (as I can do in testMpeg4VideoStreamer)? Any other ideas? Thank you in advance Matteo Trotti -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080220/522054d8/attachment.html From ferruccio.fiorucci at gmail.com Thu Feb 21 01:31:30 2008 From: ferruccio.fiorucci at gmail.com (Ferruccio Fiorucci) Date: Thu, 21 Feb 2008 10:31:30 +0100 Subject: [Live-devel] Axis camera In-Reply-To: <47BC3B7A.9080605@totalwire.it> References: <2830135d0802200612i7017bf6ch2396258324246bc4@mail.gmail.com> <47BC3B7A.9080605@totalwire.it> Message-ID: <2830135d0802210131w25fc2249uc4e12ea324858ef2@mail.gmail.com> Hi, I think I'm using a different version of openRTSP( the last version I found in the server ), and I can't use the -e option, it's not foreseen. Anyway I found a solution using the -t opion ( i.e. using the RTP over TCP ). With this option i can save a mpeg4 file, but at this moment I have a strange problem with this feature: when I try to save the file coming from the camera, the openRTSP program sometimes creates a good file, sometimes creates an useless bad file very small. The problem is that I don't know why this problem happens, it seems random??. Do you have any idea to solve this problem? Thanks Best Regards 2008/2/20 Sigismondo Boschi : > Ferruccio Fiorucci wrote: > > Hello, > > > > I'm trying to use the openrtsp program in order to connect to an Axis > > camera ( axis 207 ) unsuccesful!!! > > All seems to go well, I sand to camera all the right commands ( > > DESCRIBE, PLAY, and so on..) but when i can see in the shell "Receiving > > streamed data", I cant save the data in a file. > > The program creates the file, but it's empty ( its dimension is 30 Byte > ). > > The parameters I use are: > > > > openRTSP -d 10 -S 54 -n -F prova rtsp://192.168.3.140/mpeg4/media.amp > > > Hi, > I can do it successfully, with an Axis camera. However I have slightly > different options (maybe older/newer version... openRTSP.exe -e 10 -F > test rtsp://192.168.0.42/mpeg4/media.amp ). Be careful with firewalls (I > mean Windows or Linux ones), because the client is working as an UDP > server. Try with the "-t" option - it lets the RTP communication take > place over the estabilished TCP connection. > > Ciao, > Sigismondo > > -- > ------------------------------------------------------------------ > Sigismondo Boschi, PhD TotalWire S.r.l. > s.boschi at totalwire.it http://www.totalwire.it > cell: +39 346 7911896 tel: +39 051 302696 > > _______________________________________________ > 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/20080221/d4711cd7/attachment.html From eric.flickner at gmail.com Thu Feb 21 05:05:58 2008 From: eric.flickner at gmail.com (Eric Flickner) Date: Thu, 21 Feb 2008 08:05:58 -0500 Subject: [Live-devel] Axis camera In-Reply-To: <2830135d0802210131w25fc2249uc4e12ea324858ef2@mail.gmail.com> References: <2830135d0802200612i7017bf6ch2396258324246bc4@mail.gmail.com> <47BC3B7A.9080605@totalwire.it> <2830135d0802210131w25fc2249uc4e12ea324858ef2@mail.gmail.com> Message-ID: <72ab2a680802210505g70da363aj33712ba6a0dd2f2@mail.gmail.com> We need a better description of the problem to be able to help. It sounds like you are on the right track that it works sometimes. I recommend to try and debug the problem more using the following tips: 1. Use packet capture software to see if the data is being transmitted and/or received. I usually see an ICMP packet for each RTP packet that is sent if there isn't a socket receiving the data. 2. Place some strategic printf statements in openRTSP program or LIVE555 library to provide yourself with more information. Thanks, Eric 2008/2/21 Ferruccio Fiorucci : > Hi, > > I think I'm using a different version of openRTSP( the last version I > found in the server ), and I can't use the -e option, it's not foreseen. > > Anyway I found a solution using the -t opion ( i.e. using the RTP over TCP > ). > > With this option i can save a mpeg4 file, but at this moment I have a > strange problem with this feature: > > when I try to save the file coming from the camera, the openRTSP program > sometimes creates a good file, sometimes creates an useless bad file very > small. The problem is that I don't know why this problem happens, it seems > random??. > > > > Do you have any idea to solve this problem? > > > > Thanks > > > Best Regards > > 2008/2/20 Sigismondo Boschi : > > > Ferruccio Fiorucci wrote: > > > Hello, > > > > > > I'm trying to use the openrtsp program in order to connect to an Axis > > > camera ( axis 207 ) unsuccesful!!! > > > All seems to go well, I sand to camera all the right commands ( > > > DESCRIBE, PLAY, and so on..) but when i can see in the shell > > "Receiving > > > streamed data", I cant save the data in a file. > > > The program creates the file, but it's empty ( its dimension is 30 > > Byte ). > > > The parameters I use are: > > > > > > openRTSP -d 10 -S 54 -n -F prova rtsp://192.168.3.140/mpeg4/media.amp > > > > > Hi, > > I can do it successfully, with an Axis camera. However I have slightly > > different options (maybe older/newer version... openRTSP.exe -e 10 -F > > test rtsp://192.168.0.42/mpeg4/media.amp ). Be careful with firewalls (I > > mean Windows or Linux ones), because the client is working as an UDP > > server. Try with the "-t" option - it lets the RTP communication take > > place over the estabilished TCP connection. > > > > Ciao, > > Sigismondo > > > > -- > > ------------------------------------------------------------------ > > Sigismondo Boschi, PhD TotalWire S.r.l. > > s.boschi at totalwire.it http://www.totalwire.it > > cell: +39 346 7911896 tel: +39 051 302696 > > > > _______________________________________________ > > 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 > > -- Eric Flickner -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080221/1ba1c206/attachment-0001.html From aravind.account at gmail.com Thu Feb 21 16:50:48 2008 From: aravind.account at gmail.com (Aravind K) Date: Thu, 21 Feb 2008 19:50:48 -0500 Subject: [Live-devel] H.264 Streaming Help Message-ID: Hi friends, has anyone developed a H.264 program to stream via RTP.I have an encoder that delivers discrete NAL units .It would be of great help if someone could help me in this regard. Thanks Aravind -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080221/e9ca1d0c/attachment.html From finlayson at live555.com Thu Feb 21 17:41:14 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Feb 2008 11:41:14 +1000 Subject: [Live-devel] A network problem In-Reply-To: References: Message-ID: >The Live555MediaServer is hosted on a linux machine with a real IP >like (66.147.231.80, out of my school). > > > >I am using OpenRTSP as a client and run in my private network >(192.168.100.101 and 192.168.100.102). In general, you cannot expect RTSP/RTP to work over a NAT. However, because your server is really on the Internet, then you might be able to get RTP-over-TCP streaming to work, even though your client is not really on the Internet. I.e., try adding the "-t" option to "openRTSP". -- 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/20080221/e1fa0e61/attachment.html From finlayson at live555.com Thu Feb 21 17:55:46 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Feb 2008 11:55:46 +1000 Subject: [Live-devel] Axis camera In-Reply-To: <2830135d0802200612i7017bf6ch2396258324246bc4@mail.gmail.com> References: <2830135d0802200612i7017bf6ch2396258324246bc4@mail.gmail.com> Message-ID: >I'm trying to use the openrtsp program in order to connect to an >Axis camera ( axis 207 ) unsuccesful!!! >All seems to go well, I sand to camera all the right commands ( >DESCRIBE, PLAY, and so on..) but when i can see in the shell >"Receiving streamed data", I cant save the data in a file. >The program creates the file, but it's empty ( its dimension is 30 Byte ). You probably have a firewall somewhere that's blocking RTP/UDP packets. Try adding the "-t" option to "openRTSP", to request RTP-over-TCP streaming. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Feb 21 20:24:51 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Feb 2008 14:24:51 +1000 Subject: [Live-devel] Streaming live MPEG4 stream In-Reply-To: <20080220092329.71025.qmail@mail3-32.sinamail.sina.com.cn> References: <20080220092329.71025.qmail@mail3-32.sinamail.sina.com.cn> Message-ID: >And in my program, I write my own >MPEG4LiveServerMediaSubsession(from ServerMediaSubsession) and >MPEG4FramedLiveSource(from Framed Souce), the live source send one >frame each time Then you should use "MPEG4VideoStreamDiscreteFramer" rather than "MPEG4VideoStreamFramer". This makes the parsing much simpler. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ralf.buhlrich at rheinmetall.com Thu Feb 21 23:25:43 2008 From: ralf.buhlrich at rheinmetall.com (Ralf Buhlrich) Date: Fri, 22 Feb 2008 08:25:43 +0100 Subject: [Live-devel] H.264 Streaming Help In-Reply-To: References: Message-ID: <1203665143.24696.14.camel@ftlxwks003.defence-elec.de> Hi Aravind, I just enhanced the MPEG2TransportStreamFromESSource and the MPEG2TransportStreamMultiplexor to embedded H.264 in a MPEG2TS to stream stream it via RTP. Please specify your problem, so that I might help you. Best regards Ralf -- 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 brianmarete at gmail.com Fri Feb 22 03:13:25 2008 From: brianmarete at gmail.com (Brian Gitonga Marete) Date: Fri, 22 Feb 2008 14:13:25 +0300 Subject: [Live-devel] H.264 Streaming Help In-Reply-To: References: Message-ID: <6dd519ae0802220313mcd27a48t875fff6689ab7f2a@mail.gmail.com> Hello, I am currently testing streaming of an RFC 3984 RTP session from an .mp4 file. (I ignore/discard the audio.) I am using ffmpeg's libavformat to read the .mp4 file. As source, I have sub-classed H264StreamFramer. As sink, I am using the ready-made H264RTPSink. I then multicast the result.. It works, but there is a caveat: You need to supply the client with an SDP file that has the sprop-patameters entry, since H264 RTP packets are not self-describing. Alternatively, you can extract the SPS from the .mp4 file (again with the help of ffmpeg) and transmit them at regular intervals. VLC plays the multicasted stream fine when given the SDP file. The idea is to eventually use all this in a subclass of OnDemandServerMediaSubsession so that H264 Streams can be served via RTSP. It is still pretty rudimentary proof-of-concept work, but it works so far and I can send/post the sources for you if this sounds like the sort of thing you want to do. Regards, BGM. 2008/2/22 Aravind K : > Hi friends, > has anyone developed a H.264 program to stream via RTP.I have an encoder > that delivers discrete NAL units .It would be of great help if someone > could help me in this regard. > > Thanks > Aravind > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > -- B. Gitonga Marete Tel: +254-722-151-590 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080222/a3e31f67/attachment.html From Chad_Ata at Brightcom.com Fri Feb 22 17:56:26 2008 From: Chad_Ata at Brightcom.com (Chad Ata) Date: Fri, 22 Feb 2008 17:56:26 -0800 Subject: [Live-devel] NAT traversal with DarwinInjector Message-ID: Hi All, I've looked through the forum archives regarding this topic and the answer seems to be that currently NAT traversal is not "reliably" supported by the client. I also looked through some of the DarwinInjector code, and it doesn't look like it supports it either (unless I'm missing something). Soo.. does anybody know for sure - can DarwinInjector traverse NATs? Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080222/c13821d8/attachment.html From surendar4u at gmail.com Fri Feb 22 20:01:15 2008 From: surendar4u at gmail.com (surendar gupta) Date: Sat, 23 Feb 2008 09:31:15 +0530 Subject: [Live-devel] problem with output streamed data Message-ID: <90245b6e0802222001m4f8d1588i6fbfab5f6ca57b1a@mail.gmail.com> Hi All, I am using quicktime v7.4.1 to watch output of a mpeg4 file streamed using live555 streamer. It does not show any error but output video is not shown(although time keeps on running as if it is playing). I know that the framesize is 16 in live but i am not able to find the one in quicktime player(the header format which it processes). I tried changing the header information by comparing my file with some other mpeg4 files which quicktime is playing. I doubt if i have some problem with the header of the file or may be some other problem. The file is saved in mediaserver folder, i am doing this for experimentation so that i can do live streaming later(by saving data in files and streaming it). A quick reply will be highly appreciated. Yours Surendar Gupta Ph:+91-9990001618 Embedded engineer e-con Infotech pvt. ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080222/a8b178ae/attachment.html From rumrunner439 at yahoo.com Fri Feb 22 21:42:45 2008 From: rumrunner439 at yahoo.com (cody bedford) Date: Fri, 22 Feb 2008 21:42:45 -0800 (PST) Subject: [Live-devel] cant get live to load on my linux redhat at all down to last file to load"make" and wont go Message-ID: <84585.74738.qm@web63904.mail.re1.yahoo.com> ok i have a linux box redhat running a video and music share and i was getting major configure.log said over and over to get latest version of livemedia.hh and that it couldnt find this file anywhere over and over everytime i go to upload on my site it starts to upload and then before it ever gets a chance to upload i see a server internal error goes all the way thru looks like its uploading but never makes it to the server at all and all ports are open any listening any ideas would be great thanks Cody 18:39:05 raven11p0:/usr/lib$ cd live 18:39:30 raven11p0:/usr/lib/live$ ./configure Whoa! This software distribution does NOT use the normal Unix "configure" mechanism for generating a Makefile. For instructions on how to build this software, see . Also, please make sure that you're using the most up-to-date version of the source code - available from . 18:39:38 raven11p0:/usr/lib/live$ ./genMakefiles Usage: ./genMakefiles 18:40:28 raven11p0:/usr/lib/live$ make make: *** No targets specified and no makefile found. Stop. 18:41:16 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:42:54 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:43:51 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:46:57 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:47:20 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:56:44 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:57:10 raven11p0:/usr/lib/live$ ./genMakefile bash: ./genMakefile: No such file or directory 18:57:37 raven11p0:/usr/lib/live$ ./Makefile bash: syntax error near unexpected token `newline' 19:03:00 raven11p0:/usr/lib/live$ ./genMakefiles bash: syntax error near unexpected token `newline' 19:04:48 raven11p0:/usr/lib/live$ ./genMakefiles bash: syntax error near unexpected token `newline' 19:05:20 raven11p0:/usr/lib/live$ --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080222/767dda12/attachment-0001.html From morgan.torvolt at gmail.com Fri Feb 22 22:32:22 2008 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Sat, 23 Feb 2008 10:32:22 +0400 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications In-Reply-To: References: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> <47B960DB.40908@imavis.com> Message-ID: <3cc3561f0802222232k685dbe58g8ddbec9f8a22d225@mail.gmail.com> > Because they will want their email address to indicate the name of > their company or school, to show that they have one. Otherwise (if > they just use a "@gmail.com", "@yahoo.com", "@hotmail.com" etc. > address), most people (including I) will assume that they are simply > a casual hobbyist, not affiliated with an Internet-savvy company or > school). (Not that there's anything wrong with being a casual > hobbyist; they are welcome on this mailing list, but they risk not > getting as much attention as professionals.) So, let me get this straight. If you got an e-mail from nrkbeta at gmail.com, you would possibly not help those people out very much if they had a strange problem? You see, these guys are the testing and development bunch at NRK, Norway's stately owned and run media company. They have three country wide terrestrial coverage TV channels, a whole bunch of radio channels (analogue and digital) as well as having satellite coverage of most of Europe north of Italy and Spain. Possibly one of the best TV and Radio production offices in the world audio and video quality vice ). This gmail address is their official address. You will find it if you go to www.nrkbeta.no (www.nrk.no is the main page). If my first assessment was right, you are actually to some extent disregarding any smaller and obviously a few larger companies requests just because they choose to not run their email services themselves, but rather use a free online service? In my opinion that could prove to be bad for business. I believe more and more technological companies, especially smaller ones (which possibly could be your biggest user group), woud rather spend time developing than maintaining a email service. Also, even you must admit that gmail is pretty sweet from a business point of view, calendar, office tools and all =) -Morgan- From cody at xeleven59.com Fri Feb 22 22:42:10 2008 From: cody at xeleven59.com (Cody wilson) Date: Sat, 23 Feb 2008 00:42:10 -0600 Subject: [Live-devel] cant seem to get live to configure "genMakefiles" Message-ID: <7f2429310802222242s4a7ab3c9ue12a5f19b7e0af25@mail.gmail.com> ok i cant seem to get live to load in my linux redhat server regular command ./configure theirs genMakefiles but nothing seems to work this all started when i went to configure my codecs and it gave errors get latest version livemedia.hh2006.03.03 and said no file livemedia.hh over and over so i uploaded and unzipped created dir just like asked and now im stuck and we will be getting around 200thousand people on my site tommorow and my video and music share is broke it wont upload it throws server 500 internal server errors it never makes it to the sever though www.xeleven59.com then videos link if anyone has any good videos please send me some im looking for some comedy or pranks any thing good to put up on the main page :) thanks Cody xeleven59 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080222/412badd7/attachment.html From maherry at yeah.net Fri Feb 22 23:32:35 2008 From: maherry at yeah.net (maherry) Date: Sat, 23 Feb 2008 15:32:35 +0800 (CST) Subject: [Live-devel] again need help of special video and audio data Message-ID: <17152478.710511203751955013.JavaMail.coremail@yeahapp3.yeah.net> Hi,again. In the early letters we wrote like following: >The stream contain mepg4 video >and mpeg1 layer2 audio.they are consisted like this: > >one frame mpeg1 audio element stream >one frame mpeg1 audio element stream >...... >one frame mpeg4 video element stream >one frame mpeg4 video element stream >...... >one frame mpeg1 audio element stream >one frame mpeg1 audio element stream > >it is not a ts stream.Just the element stream. >Ross write >You will need to write your own demultipexor, to split this single >stream into its component audio and video elementary streams, and >then stream each of those. >But my encoded stream has the is special header and tailor.like this. >one frame >************************************************ >the chanel number**the frame type**the frame size >************************************************* >MPEG4 encoded data >************************************************* >0000000000000000000000000000000000000000000000000 >************************************************* >the frame size is defined 512*N byte, if the real frame size is not 512*N then the left >data is ox00. >so if I want to stream this format element stream, what should I do? >Perhaps I can modify the MPEG4 parse()program or I can implement the row data parse in >the Demux program. Could you please give me some advice? Thank you very much! >your reply is: >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. I think out a method to solve the problem,but I don't know whether it is right.So ask you some advice. In the FAQ I see the typical control flow is 'source1' -> 'source2' (a filter) -> 'source3' (a filter) -> 'sink' so if I can program a filter to abstract the standard video data and standard audio data than the server receive the standard data from the filer. Will this be OK? Thank you very much! If it will works, could you please give some example of the filer? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080222/16aa2293/attachment.html From renard.nicolas at gmail.com Sat Feb 23 03:54:30 2008 From: renard.nicolas at gmail.com (Nicolas Renard) Date: Sat, 23 Feb 2008 12:54:30 +0100 Subject: [Live-devel] cant get live to load on my linux redhat at all down to last file to load"make" and wont go In-Reply-To: <84585.74738.qm@web63904.mail.re1.yahoo.com> References: <84585.74738.qm@web63904.mail.re1.yahoo.com> Message-ID: Just try: ./genMakefiles linux 2008/2/23, cody bedford : > > ok i have a linux box redhat running a video and music share and i was > getting major configure.log said over and over to get latest version of > livemedia.hh and that it couldnt find this file anywhere over and over > everytime i go to upload on my site it starts to upload and then before it > ever gets a chance to upload i see a server internal error goes all the way > thru looks like its uploading but never makes it to the server at all and > all ports are open any listening any ideas would be great > thanks Cody > > 18:39:05 raven11p0:/usr/lib$ cd live > 18:39:30 raven11p0:/usr/lib/live$ ./configure > Whoa! This software distribution does NOT use the normal Unix "configure" > mechanism for generating a Makefile. For instructions on how to build this > software, see . > Also, please make sure that you're using the most up-to-date version of > the source code - available from >. > 18:39:38 raven11p0:/usr/lib/live$ ./genMakefiles > Usage: ./genMakefiles > 18:40:28 raven11p0:/usr/lib/live$ make > make: *** No targets specified and no makefile found. Stop. > 18:41:16 raven11p0:/usr/lib/live$ ./genMakefile > bash: syntax error near unexpected token `newline' > 18:42:54 raven11p0:/usr/lib/live$ ./genMakefile > bash: syntax error near unexpected token `newline' > 18:43:51 raven11p0:/usr/lib/live$ ./genMakefile > bash: syntax error near unexpected token `newline' > 18:46:57 raven11p0:/usr/lib/live$ ./genMakefile > bash: syntax error near unexpected token `newline' > 18:47:20 raven11p0:/usr/lib/live$ ./genMakefile > bash: syntax error near unexpected token `newline' > 18:56:44 raven11p0:/usr/lib/live$ ./genMakefile > bash: syntax error near unexpected token `newline' > 18:57:10 raven11p0:/usr/lib/live$ ./genMakefile > bash: ./genMakefile: No such file or directory > 18:57:37 raven11p0:/usr/lib/live$ ./Makefile > bash: syntax error near unexpected token `newline' > 19:03:00 raven11p0:/usr/lib/live$ ./genMakefiles > bash: syntax error near unexpected token `newline' > 19:04:48 raven11p0:/usr/lib/live$ ./genMakefiles > bash: syntax error near unexpected token `newline' > 19:05:20 raven11p0:/usr/lib/live$ > > ------------------------------ > Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it > now. > > > _______________________________________________ > 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/20080223/ffd49557/attachment.html From rumrunner439 at yahoo.com Sat Feb 23 04:30:09 2008 From: rumrunner439 at yahoo.com (cody bedford) Date: Sat, 23 Feb 2008 04:30:09 -0800 (PST) Subject: [Live-devel] cant get live to load on my linux redhat at all down to last file to load"make" and wont go In-Reply-To: Message-ID: <911605.55034.qm@web63903.mail.re1.yahoo.com> ok thanks ill try to do it that way right now im still trying to find a list on whats needed to make a codecs file do a ./configure make then make install got to where it failed was looking for a lib type files cant seem to find a complete list anywhere for a codecs im getting ready to copy my mplayer to the /usr/local/lib since it seems to have all the needed lib folders and files in it and im going to try and do a ./configure again and see if it does that without any more errors so i can do a make then make install and hope to get my video and music share working thanks for any info ! Cody www.xeleven59.com then video link Nicolas Renard wrote: Just try: ./genMakefiles linux 2008/2/23, cody bedford : ok i have a linux box redhat running a video and music share and i was getting major configure.log said over and over to get latest version of livemedia.hh and that it couldnt find this file anywhere over and over everytime i go to upload on my site it starts to upload and then before it ever gets a chance to upload i see a server internal error goes all the way thru looks like its uploading but never makes it to the server at all and all ports are open any listening any ideas would be great thanks Cody 18:39:05 raven11p0:/usr/lib$ cd live 18:39:30 raven11p0:/usr/lib/live$ ./configure Whoa! This software distribution does NOT use the normal Unix "configure" mechanism for generating a Makefile. For instructions on how to build this software, see . Also, please make sure that you're using the most up-to-date version of the source code - available from . 18:39:38 raven11p0:/usr/lib/live$ ./genMakefiles Usage: ./genMakefiles 18:40:28 raven11p0:/usr/lib/live$ make make: *** No targets specified and no makefile found. Stop. 18:41:16 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:42:54 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:43:51 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:46:57 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:47:20 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:56:44 raven11p0:/usr/lib/live$ ./genMakefile bash: syntax error near unexpected token `newline' 18:57:10 raven11p0:/usr/lib/live$ ./genMakefile bash: ./genMakefile: No such file or directory 18:57:37 raven11p0:/usr/lib/live$ ./Makefile bash: syntax error near unexpected token `newline' 19:03:00 raven11p0:/usr/lib/live$ ./genMakefiles bash: syntax error near unexpected token `newline' 19:04:48 raven11p0:/usr/lib/live$ ./genMakefiles bash: syntax error near unexpected token `newline' 19:05:20 raven11p0:/usr/lib/live$ --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. _______________________________________________ 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 --------------------------------- Looking for last minute shopping deals? Find them fast with Yahoo! Search. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080223/4e90fdb0/attachment-0001.html From rtc_ru at mail.ru Sat Feb 23 08:53:58 2008 From: rtc_ru at mail.ru (=?windows-1251?B?wO3g8u7r6Okg0OXs7eXi?=) Date: Sat, 23 Feb 2008 22:53:58 +0600 Subject: [Live-devel] tsx playing Message-ID: <1838720864.20080223225358@mail.ru> Hi, all! Help me please: which changes needs in Live555 media server for making possible playing tsx files? If you have "live" sample - I'll be very pleased of it. There is a demo sample in source packet - but I can't understand how to integrate in base server code. Thanks. With best regards, Anatoliy From rtc_ru at mail.ru Sat Feb 23 09:03:40 2008 From: rtc_ru at mail.ru (=?windows-1251?B?wO3g8u7r6Okg0OXs7eXi?=) Date: Sat, 23 Feb 2008 23:03:40 +0600 Subject: [Live-devel] Trickplay problem Message-ID: <1024537635.20080223230340@mail.ru> And another one question :) Does network peak level problem when trickplay mode is started has been solved? With best regards, A.R. From finlayson at live555.com Fri Feb 22 22:48:13 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 22 Feb 2008 20:48:13 -1000 Subject: [Live-devel] NAT traversal with DarwinInjector In-Reply-To: References: Message-ID: >I've looked through the forum archives regarding this topic and the >answer seems to be that currently NAT traversal is not "reliably" >supported by the client. >I also looked through some of the DarwinInjector code, and it >doesn't look like it supports it either (unless I'm missing >something). > >Soo.. does anybody know for sure - can DarwinInjector traverse NATs? I don't know. It uses a single TCP connection (for both RTSP and RTP/RTCP), so it's possible that it works across a NAT, but, as always for NAT, there's no guarantee. -- 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/20080223/75a694f8/attachment.html From finlayson at live555.com Sat Feb 23 19:24:25 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 23 Feb 2008 17:24:25 -1000 Subject: [Live-devel] cant get live to load on my linux redhat at all down to last file to load"make" and wont go In-Reply-To: <84585.74738.qm@web63904.mail.re1.yahoo.com> References: <84585.74738.qm@web63904.mail.re1.yahoo.com> Message-ID: >18:39:38 raven11p0:/usr/lib/live$ ./genMakefiles >Usage: ./genMakefiles >18:40:28 raven11p0:/usr/lib/live$ make >make: *** No targets specified and no makefile found. Stop. >18:41:16 raven11p0:/usr/lib/live$ ./genMakefile >bash: syntax error near unexpected token `newline' It's "genMakefiles" - with a trailing "s" - not "genMakefile"! -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Feb 23 19:31:25 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 23 Feb 2008 17:31:25 -1000 Subject: [Live-devel] GroupsockHelper.cpp and weird problems with long startuptimes for applications In-Reply-To: <3cc3561f0802222232k685dbe58g8ddbec9f8a22d225@mail.gmail.com> References: <3cc3561f0802160431w68f2f6b5l877fbdd7c39bedbd@mail.gmail.com> <47B960DB.40908@imavis.com> <3cc3561f0802222232k685dbe58g8ddbec9f8a22d225@mail.gmail.com> Message-ID: >If my first assessment was right, you are actually to some extent >disregarding any smaller and obviously a few larger companies requests >just because they choose to not run their email services themselves, >but rather use a free online service? I didn't say that serious professionals don't outsource their email - I said that serious professionals don't use "@gmail.com" email addresses. And I stand by that, and I'll continue to use such addresses as a first-level 'bozo filter'. (Note that it's possible to use GMail with an email address that uses your own company's (or school's) domain name.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Feb 23 20:30:34 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 23 Feb 2008 18:30:34 -1000 Subject: [Live-devel] problem with output streamed data In-Reply-To: <90245b6e0802222001m4f8d1588i6fbfab5f6ca57b1a@mail.gmail.com> References: <90245b6e0802222001m4f8d1588i6fbfab5f6ca57b1a@mail.gmail.com> Message-ID: >I am using quicktime v7.4.1 to watch output of a mpeg4 file streamed >using live555 streamer. Note that the "LIVE555 Media Server" can stream MPEG-4 video elementary stream files, which are *not* what are normally considered to be "MPEG-4" files. Note that a file with filename suffix ".mp4" is almost certainly *not* a MPEG-4 Video Elementary Stream file. -- 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/20080223/9b628f83/attachment.html From finlayson at live555.com Sat Feb 23 20:34:55 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 23 Feb 2008 18:34:55 -1000 Subject: [Live-devel] tsx playing In-Reply-To: <1838720864.20080223225358@mail.ru> References: <1838720864.20080223225358@mail.ru> Message-ID: >Help me please: which changes needs in Live555 media server for >making possible >playing tsx files? You don't 'play' .tsx files. The server streams ".ts" files, which (optionally) each have index files (with filename suffix ".tsx".) No changes need to be made to the LIVE555 Media Server for this; it already works. Please read the online documentation. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From cody at xeleven59.com Sun Feb 24 11:30:10 2008 From: cody at xeleven59.com (Cody wilson) Date: Sun, 24 Feb 2008 13:30:10 -0600 Subject: [Live-devel] ok i got my videos to upload wont play on home page Message-ID: <7f2429310802241130t1ec21643l525ff594c9c0e88f@mail.gmail.com> ok i got my videos to upload at www.xeleven59.com click the videos link the videos are there they just wont play will a improperly loaded codecs on my server do this? i have live and codecs on the server? in the admin side i can see the videos and can even play it in the area where i can preview the video or edit them. but on the page i cant seem to get it to play any ideas? thanks Cody -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080224/d0841c22/attachment.html From rumrunner439 at yahoo.com Sun Feb 24 16:58:35 2008 From: rumrunner439 at yahoo.com (cody bedford) Date: Sun, 24 Feb 2008 16:58:35 -0800 (PST) Subject: [Live-devel] cant get live to load on my linux redhat at all down to last file to load"make" and wont go In-Reply-To: Message-ID: <491227.43117.qm@web63909.mail.re1.yahoo.com> ok i got it to do the ./genMakefiles linux but it would not do the find . -name 'Makefile' -exec fix-makefile {} \; so i cant get it to make or make install thanks cody www.xeleven59.com Ross Finlayson wrote: >18:39:38 raven11p0:/usr/lib/live$ ./genMakefiles >Usage: ./genMakefiles >18:40:28 raven11p0:/usr/lib/live$ make >make: *** No targets specified and no makefile found. Stop. >18:41:16 raven11p0:/usr/lib/live$ ./genMakefile >bash: syntax error near unexpected token `newline' It's "genMakefiles" - with a trailing "s" - not "genMakefile"! -- 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 --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080224/1fdb3d31/attachment.html From cody at xeleven59.com Sun Feb 24 18:15:01 2008 From: cody at xeleven59.com (Cody wilson) Date: Sun, 24 Feb 2008 20:15:01 -0600 Subject: [Live-devel] any one know how to do a command line test Message-ID: <7f2429310802241815h78434cfaja8be96694f4f64ac@mail.gmail.com> I cant get my videos to play on my site they play in the admin edit area but not on the opening page im stumped, www.xeleven59.com/VideoShare i was told to do a command line test for mencoder and for live i dont really understand what they are asking? they said do it in ssh im in putty but never heard of it. any help be great Cody www.xeleven59.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080224/a460ba50/attachment.html From finlayson at live555.com Sun Feb 24 18:37:52 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 24 Feb 2008 16:37:52 -1000 Subject: [Live-devel] any one know how to do a command line test In-Reply-To: <7f2429310802241815h78434cfaja8be96694f4f64ac@mail.gmail.com> References: <7f2429310802241815h78434cfaja8be96694f4f64ac@mail.gmail.com> Message-ID: >I cant get my videos to play on my site they play in the admin edit >area but not on the opening page im stumped, >www.xeleven59.com/VideoShare i >was told to do a command line test for mencoder and for live i dont >really understand what they are asking? they said do it in ssh im in >putty but never heard of it. >any help be great This mailing list is for discussion of our "LIVE555 Streaming Media" software. I don't totally understand your question, but if it is not about our software, then this is not the right maling list for it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080224/b6db8bc4/attachment-0001.html From finlayson at live555.com Sun Feb 24 18:46:38 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 24 Feb 2008 16:46:38 -1000 Subject: [Live-devel] cant get live to load on my linux redhat at all down to last file to load"make" and wont go In-Reply-To: <491227.43117.qm@web63909.mail.re1.yahoo.com> References: <491227.43117.qm@web63909.mail.re1.yahoo.com> Message-ID: >ok i got it to do the ./genMakefiles linux >but it would not do the find . -name 'Makefile' -exec >fix-makefile {} \; None of our released "config.*" files even mention "fix-makefile". Where did you get this code??? You must use the official source code release: http://www.live555.com/liveMedia/public/live555-latest.tar.gz Please follow the instructions at http://www.live555.com/liveMedia/ , and stop wasting our time! -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From luen_2 at hotmail.com Mon Feb 25 01:10:57 2008 From: luen_2 at hotmail.com (fung ka luen) Date: Mon, 25 Feb 2008 09:10:57 +0000 Subject: [Live-devel] A network problem Message-ID: Dear Ross Thank you very much for your help! I have tried to use the "-t" for the connection. However, it is very very slow. it almost only 1/3 packets arrived. is there any other possible solutions? Thank you Luen ================================================== Message: 2Date: Fri, 22 Feb 2008 11:41:14 +1000From: Ross Finlayson Subject: Re: [Live-devel] A network problemTo: LIVE555 Streaming Media - development & useMessage-ID: Content-Type: text/plain; charset="us-ascii" >The Live555MediaServer is hosted on a linux machine with a real IP >like (66.147.231.80, out of my school).>>>>I am using OpenRTSP as a client and run in my private network >(192.168.100.101 and 192.168.100.102). In general, you cannot expect RTSP/RTP to work over a NAT. However, because your server is really on the Internet, then you might be able to get RTP-over-TCP streaming to work, even though your client is not really on the Internet. I.e., try adding the "-t" option to "openRTSP".-- Ross FinlaysonLive Networks, Inc.http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080225/051dd49a/attachment.html From mahmoud.mhiri at gmail.com Mon Feb 25 01:54:12 2008 From: mahmoud.mhiri at gmail.com (Mahmoud M'HIRI) Date: Mon, 25 Feb 2008 10:54:12 +0100 Subject: [Live-devel] [openRTSP] Output file not found!! Message-ID: <6c56bfad0802250154s63000c1cj9def78d418985cae@mail.gmail.com> Hi! I noticed that VLC have troubles with reading my rtsp streams (rtsp://xx.xx.xx.xx/xx.sdp), so I tried to read them by openRTSP. I have this output text: Receiving streamed data (signal with "kill -HUP 7313" or "kill -USR1 7313" to terminate)... But nothing appears and no file has been created in the openSTSP folder, so I tried to specify the output file: ./openRTSP -F ~/mm.avi rtsp://xx.xx.xx.xx:xx/xx.sdp but I have the same text (after a long log texts) without my file creation. I noticed that openRTSP have opened my SDP file. PS: Tell me if you want that I paste the openRTSP output. Thanks a lot -- Mahmoud M'HIRI mhiri at ieee.org Phone: Under request -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080225/c31b4198/attachment.html From mahmoud.mhiri at gmail.com Mon Feb 25 02:34:54 2008 From: mahmoud.mhiri at gmail.com (Mahmoud M'HIRI) Date: Mon, 25 Feb 2008 11:34:54 +0100 Subject: [Live-devel] [openRTSP] Output file not found!! In-Reply-To: <6c56bfad0802250154s63000c1cj9def78d418985cae@mail.gmail.com> References: <6c56bfad0802250154s63000c1cj9def78d418985cae@mail.gmail.com> Message-ID: <6c56bfad0802250234v2f153266h70105632312d02b8@mail.gmail.com> I found some files named like this: audio-MP4A-LATM-2 but they are empty.. any idea?? -- Mahmoud M'HIRI mhiri at ieee.org Phone: Under request On 2/25/08, Mahmoud M'HIRI wrote: > > Hi! > > I noticed that VLC have troubles with reading my rtsp streams > (rtsp://xx.xx.xx.xx/xx.sdp), so I tried to read them by openRTSP. > > I have this output text: Receiving streamed data (signal with "kill -HUP > 7313" or "kill -USR1 7313" to terminate)... > > But nothing appears and no file has been created in the openSTSP folder, > so I tried to specify the output file: ./openRTSP -F ~/mm.avi > rtsp://xx.xx.xx.xx:xx/xx.sdp but I have the same text (after a long log > texts) without my file creation. > > I noticed that openRTSP have opened my SDP file. > > PS: Tell me if you want that I paste the openRTSP output. > > Thanks a lot > > -- > Mahmoud M'HIRI > mhiri at ieee.org > Phone: Under request -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080225/630fc9ef/attachment.html From surendar4u at gmail.com Mon Feb 25 03:23:20 2008 From: surendar4u at gmail.com (surendar gupta) Date: Mon, 25 Feb 2008 16:53:20 +0530 Subject: [Live-devel] problem with output streamed data In-Reply-To: References: <90245b6e0802222001m4f8d1588i6fbfab5f6ca57b1a@mail.gmail.com> Message-ID: <90245b6e0802250323l12e50c1bl2252f57583fa71cc@mail.gmail.com> Hi, Thanks for the reply. I am using file with suffix ".m4e" which is a MPEG-4 video elementary stream files. So can you please help me further. Thanks and regards, Surendar 2008/2/24 Ross Finlayson : > I am using quicktime v7.4.1 to watch output of a mpeg4 file streamed > using live555 streamer. > > > Note that the "LIVE555 Media Server" can stream MPEG-4 video elementary > stream files, which are *not* what are normally considered to be "MPEG-4" > files. Note that a file with filename suffix ".mp4" is almost certainly > *not* a MPEG-4 Video Elementary Stream file. > > -- > > > 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/20080225/7c6db0f6/attachment.html From belloni at imavis.com Mon Feb 25 09:26:31 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Mon, 25 Feb 2008 18:26:31 +0100 Subject: [Live-devel] My MPEG4 Source does not make MPEG4ESVideoRTPSink set marker bits. Message-ID: <47C2FA47.8050601@imavis.com> Hi, I'm streaming MPEG4 and use FFMPEG library to encode MPEG4 frames from my own live source. I wrote my own FramedSource subclass and that does the trick. The problem is, MPEG4ESVideoRTPSink does not set the marker bits at all. I took a look at the code in the MPEG4ESVideoRTPSink.cpp file and it goes like that: 00066 // Set the RTP 'M' (marker) bit iff this frame ends a VOP 00067 // (and there are no fragments remaining). 00068 // This relies on the source being a "MPEG4VideoStreamFramer". 00069 MPEG4VideoStreamFramer* framerSource = (MPEG4VideoStreamFramer*)fSource; 00070 if (framerSource != NULL && framerSource->pictureEndMarker() 00071 && numRemainingBytes == 0) { 00072 setMarkerBit(); 00073 framerSource->pictureEndMarker() = False; 00074 } This means I should instead subclass MPEG4VideoStreamFramer and set the pictureEndMarker everytime I have a complete frame? Is there no way to have my marker bits set just subclassing FramedSource, just like I did with H263 streaming? Thanks and regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From belloni at imavis.com Tue Feb 26 00:38:09 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Tue, 26 Feb 2008 09:38:09 +0100 Subject: [Live-devel] My MPEG4 Source does not make MPEG4ESVideoRTPSink set marker bits. In-Reply-To: <47C2FA47.8050601@imavis.com> References: <47C2FA47.8050601@imavis.com> Message-ID: <47C3CFF1.3010501@imavis.com> Cristiano Belloni wrote: > Hi, I'm streaming MPEG4 and use FFMPEG library to encode MPEG4 frames > from my own live source. > > I wrote my own FramedSource subclass and that does the trick. > > The problem is, MPEG4ESVideoRTPSink does not set the marker bits at > all. I took a look at the code in the MPEG4ESVideoRTPSink.cpp file and > it goes like that: > > 00066 // Set the RTP 'M' (marker) bit iff this frame ends a VOP > 00067 // (and there are no fragments remaining). > 00068 // This relies on the source being a "MPEG4VideoStreamFramer". > 00069 MPEG4VideoStreamFramer* framerSource = > (MPEG4VideoStreamFramer*)fSource; > 00070 if (framerSource != NULL && framerSource->pictureEndMarker() > 00071 && numRemainingBytes == 0) { > 00072 setMarkerBit(); > 00073 framerSource->pictureEndMarker() = False; > 00074 } > > This means I should instead subclass MPEG4VideoStreamFramer and set > the pictureEndMarker everytime I have a complete frame? Is there no > way to have my marker bits set just subclassing FramedSource, just > like I did with H263 streaming? > > Thanks and regards, > > Cristiano. > Pardon, I think I just figured it out. Should I do something like that in my createNewStreamSource?: // Creating a video source MyFramedSource* encoderSource = MyFramedSource::createNew(envir(), params); if (encoderSource == NULL) { //Problems creating encoder return NULL; } //Encoder created successfully! if (toServe == H263) { return H263plusVideoStreamFramer::createNew(envir(), encoderSource); } else if (toServe == MPEG4) { return MPEG4VideoStreamFramer::createNew(envir(), encoderSource); } else { //Invalide encoding type! return NULL; } (Class MyFramedSource handles H263 and MPEG4 video, depending on params) And then, in createNewRTPSink(): if (toServe == H263) { //Creating new H263 sink. return H263plusVideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); } else if (toServe == MPEG4) { //Creating new MPEG4 sink. return MPEG4ESVideoRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadTypeIfDynamic); } else { std::cout << "WTF? Unknown type?" << std::endl; } Is this approach correct? Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From bebeto at gmail.com Tue Feb 26 09:20:51 2008 From: bebeto at gmail.com (Stefan Braicu) Date: Tue, 26 Feb 2008 19:20:51 +0200 Subject: [Live-devel] redirect output of openrtsp to the input of streaming server Message-ID: <22dfb9720802260920y482808f2k572f67a7ea8ac622@mail.gmail.com> Hi all, I would like to make a RTSP stack server capable of working as a RTSP relay/proxy, that is being able to connect to my server and then receive an external rtsp stream through this server: client<-mycustom server<-rtsp stream One of the reasons is that for example client is only allowed to connect to my custom server, and not to the internet. What would be the good approach to do this using live555: -modify testOnDemandRTSPServer in order to take streams from openrtsp(used wityh -r)? -testOnDemandRTSPServer is not able to stream 3gp files. by using the output of openrtsp will it be able to do it? Thanks in advance for any advice. Regards Stef -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080226/6fb27f1c/attachment-0001.html From weiyutao36 at 163.com Tue Feb 26 19:30:07 2008 From: weiyutao36 at 163.com (Yutao Wei) Date: Wed, 27 Feb 2008 11:30:07 +0800 (CST) Subject: [Live-devel] the computation of RTP timestamp Message-ID: <32628149.1524811204083007233.JavaMail.coremail@bj163app72.163.com> Hello everyone, In live555 library, in the file RTPSink.cpp, and in the function convertToRTPTimestamp: RTPSink::convertToRTPTimestamp(struct timeval tv) { // Begin by converting from "struct timeval" units to RTP timestamp units: (1)u_int32_t timestampIncrement = (fTimestampFrequency*tv.tv_sec); (2)timestampIncrement += (u_int32_t)((2.0*fTimestampFrequency*tv.tv_usec + 1000000.0)/2000000); // note: rounding I found the (2) statement is some strange. In fact, it is equal to 90000*(tv.tv_usec) + 0.5 Can anyone tell me why it compute the timestamp this way? Why there is a 0.5? Thank in advance. Austin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080226/74bf281d/attachment.html From maherry at yeah.net Tue Feb 26 23:57:04 2008 From: maherry at yeah.net (maherry) Date: Wed, 27 Feb 2008 15:57:04 +0800 (CST) Subject: [Live-devel] the problem of testMPEG4VideoStream Message-ID: <31557278.1171091204099024331.JavaMail.coremail@yeahapp4.yeah.net> When I run the testMPEG4VideoStream program to transfer the mpeg4 video element stream the program print the error: Not enough bits in VOL header: 41/8 >= 3 MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 'short vid eo header', which we current don't support Not enough bits in VOL header: 41/8 >= 3 MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 'short vid eo header', which we current don't support Not enough bits in VOL header: 41/8 >= 3 MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 'short vid eo header', which we current don't support Not enough bits in VOL header: 41/8 >= 3 MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 'short vid eo header', which we current don't support Not enough bits in VOL header: 41/8 >= 3 MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be a 'short vid eo header', which we current don't support Not enough bits in VOL header: 41/8 >= 3 what's the problem? Thank you for you help! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080226/a00d8b70/attachment.html From brianmarete at gmail.com Thu Feb 28 05:33:05 2008 From: brianmarete at gmail.com (Brian Gitonga Marete) Date: Thu, 28 Feb 2008 16:33:05 +0300 Subject: [Live-devel] ISO/IEC 13818-1:2007 Message-ID: <6dd519ae0802280533p1e6c1012o81fb8ac13dd66e7d@mail.gmail.com> Hello, Anyone with a copy of ISO/IEC 13818-1:2007 that they can send me? ;) Even a usable draft of the (2007) version would be fine. I know the 2001 version is available on the net, but it does not contain information for muxing AVC into the TS. Thanks. -- B. Gitonga Marete Tel: +254-722-151-590 From ralf.buhlrich at rheinmetall.com Thu Feb 28 06:01:34 2008 From: ralf.buhlrich at rheinmetall.com (Ralf Buhlrich) Date: Thu, 28 Feb 2008 15:01:34 +0100 Subject: [Live-devel] ISO/IEC 13818-1:2007 In-Reply-To: <6dd519ae0802280533p1e6c1012o81fb8ac13dd66e7d@mail.gmail.com> References: <6dd519ae0802280533p1e6c1012o81fb8ac13dd66e7d@mail.gmail.com> Message-ID: <1204207294.3776.8.camel@ftlxwks003.defence-elec.de> Hi List, I need one, too. I need information for muxing h264 VBI data, and private data into TS. Thanks in advance Ralf Buhlrich Am Donnerstag, den 28.02.2008, 16:33 +0300 schrieb Brian Gitonga Marete: > Hello, > > Anyone with a copy of ISO/IEC 13818-1:2007 that they can send me? ;) > > Even a usable draft of the (2007) version would be fine. I know the > 2001 version is available on the net, but it does not contain > information for muxing AVC into the TS. > > Thanks. > > > -- 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 Wed Feb 27 21:40:35 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 27 Feb 2008 21:40:35 -0800 Subject: [Live-devel] My MPEG4 Source does not make MPEG4ESVideoRTPSink set marker bits. In-Reply-To: <47C2FA47.8050601@imavis.com> References: <47C2FA47.8050601@imavis.com> Message-ID: >Hi, I'm streaming MPEG4 and use FFMPEG library to encode MPEG4 frames >from my own live source. ... >This means I should instead subclass MPEG4VideoStreamFramer and set the >pictureEndMarker everytime I have a complete frame? No, because the parser in "MPEG4VideoStreamFramer" should automatically do that for you. If your input is a byte stream, containing MPEG-4 Elementary Stream Video frames, then you don't need to write any new parsing code; "MPEG4VideoStreamFramer" will do it all for you. However, if your encoding library is generating one frame at a time, rather than a byte stream, then it will be more efficient for you to use "MPEG4VideoStreamDiscreteFramer" (taking as input one frame at a time) rather than "MPEG4VideoStreamFramer". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Feb 27 21:49:17 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 27 Feb 2008 21:49:17 -0800 Subject: [Live-devel] the computation of RTP timestamp In-Reply-To: <32628149.1524811204083007233.JavaMail.coremail@bj163app72.163.com> References: <32628149.1524811204083007233.JavaMail.coremail@bj163app72.163.com> Message-ID: >Can anyone tell me why it compute the timestamp this way? Why there is a 0.5? We add 0.5 so that values whose integer fraction is >= 0.5 get rounded up, and values whose integer fraction is < 0.5 get rounded down - when the value is converted to an integer. In any case, you shouldn't care about the RTP timestamp computation. Instead, you should treat it as a 'black box', into which you feed presentation times (at the sender end), and get back presentation times (at the receiver end). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Feb 27 21:54:45 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 27 Feb 2008 21:54:45 -0800 Subject: [Live-devel] the problem of testMPEG4VideoStream In-Reply-To: <31557278.1171091204099024331.JavaMail.coremail@yeahapp4.yeah.net> References: <31557278.1171091204099024331.JavaMail.coremail@yeahapp4.yeah.net> Message-ID: > When I run the testMPEG4VideoStream program to transfer the mpeg4 >video element stream the program print the error: > >Not enough bits in VOL header: 41/8 >= 3 >MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be >a 'short vid >eo header', which we current don't support >Not enough bits in VOL header: 41/8 >= 3 >MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be >a 'short vid >eo header', which we current don't support >Not enough bits in VOL header: 41/8 >= 3 >MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be >a 'short vid >eo header', which we current don't support >Not enough bits in VOL header: 41/8 >= 3 >MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be >a 'short vid >eo header', which we current don't support >Not enough bits in VOL header: 41/8 >= 3 >MPEG4VideoStreamParser::parseVideoObjectLayer(): This appears to be >a 'short vid >eo header', which we current don't support >Not enough bits in VOL header: 41/8 >= 3 > >what's the problem? This (your data) appears to be a 'short video header', which we currently don't support :-) (Are you *sure* that your input data is MPEG-4 Video Elementary Stream data (not H.264, not H.263, not H.263+, not a MPEG-4-format file (combining audio and video)?) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Etienne.Bomcke at uclouvain.be Fri Feb 29 08:48:04 2008 From: Etienne.Bomcke at uclouvain.be (=?ISO-8859-1?Q?Etienne_B=F6mcke?=) Date: Fri, 29 Feb 2008 17:48:04 +0100 Subject: [Live-devel] Attach sink to multiple sources Message-ID: <9D46CF5F-CDD4-4969-97A9-5075FB677E9A@uclouvain.be> Hello, My name's Etienne B?mcke and I'm a PhD. student in a belgian university. I'm working currently on a software using the liveMedia streaming library, and I've been confronted to a problem I can't solve by myself for now. So I thought I could post the problem here and ask for your opinion. Here's the thing : I have videos encoded using the H.264 codec which I'd like to stream with the liveMedia library. These videos are encoded in a specific way (using custom-defined slices) in order to allow one to replace completely a part of the sequence by a whole different video ("part" is used here in its spatial meaning, not temporal. For example consider a 176x144 pixels sized sequence, the objective would be to remove a bottom chunk, let's say the last 77 lines, and replace it by a 176x77 pixels sized sequence). The given replacement is achieved by switching parts of the sequence bitstream, i.e. without any decoding process. As the original sequence comes from a streaming server, and the replacement should be done inside the software using liveMedia, I was wondering if it was theoretically possible to design a custom Sink class, which instances could be attached to various sources. I'm new to this library, you'll have to forgive me if my question is stupid or has already been answered many times, I just couldn't find any information about that specific problem anywhere. Any feedback will be really appreciated. Cheers, Etienne -- Etienne B?mcke UCL - Laboratoire TELE etienne.bomcke at uclouvain.be From belloni at imavis.com Fri Feb 29 09:47:09 2008 From: belloni at imavis.com (Cristiano Belloni) Date: Fri, 29 Feb 2008 18:47:09 +0100 Subject: [Live-devel] How to implement non-blocking fashion in custom doGetNextFrame() Message-ID: <47C8451D.8040109@imavis.com> Hi to all, In my custom FramedSource, documentation recommends that doGetNextFrame should not call deliverFrame() if there is no frame ready. So, I do something like that in doGetNextFrame. isAwaitingData() functions checks if my real-time source has new encoded data (It's crafted in a way that it will always return the last frame, even if it's not a new one and it has been already used. isAwaitingData returns true if there's a new frame ready, false if there's an already returned frame): if (!isAwaitingData()) { // We're not ready for the data yet return; } deliverFrame(); // If, for some reason, the source device stops being readable // (e.g., it gets closed), then you do the following: if (isClosed) { handleClosure(this); return; if there's new data, deliverFrame will be called and will set the correct "out" values for the frame (fFrameSize and so on). If there's no new data, we return immediately leaving the parameters untouched. The problem is, deliverFrame returns the very first frame OK, then doGetNextFrame is called again before a new frame is captured, and I return immediately. Then, I don't know why, liveMedia never calls doGetNextFrame again. It just stays stuck and apparently does nothing. Why? What I'm doing wrong? If I remove that block of code, conversely, doGetNextFrame never blocks and always return "old" frames until the next frame is acquired, filling rapidly the CPU resources. Thanks. Regards, Cristiano. -- Belloni Cristiano Imavis Srl. www.imavis.com belloni at imavis.com From finlayson at live555.com Fri Feb 29 17:36:41 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Feb 2008 17:36:41 -0800 Subject: [Live-devel] Attach sink to multiple sources In-Reply-To: <9D46CF5F-CDD4-4969-97A9-5075FB677E9A@uclouvain.be> References: <9D46CF5F-CDD4-4969-97A9-5075FB677E9A@uclouvain.be> Message-ID: >I was >wondering if it was theoretically possible to design a custom Sink >class, which instances could be attached to various sources. The best way to do this would not be to define a new type of sink, but instead define a new type of source - i.e., a subclass of "FramedSource" - that would, as usual, feed into a single sink, but would read from multiple sources, as desired. More specifically, your new "FramedSource" subclass would perhaps take the (multiple) input sources as parameters to its constructor (and its "createNew()" function), and would implement the "doGetNextFrame()" virtual function by reading from the appropriate input source. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Feb 29 20:50:00 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Feb 2008 20:50:00 -0800 Subject: [Live-devel] How to implement non-blocking fashion in custom doGetNextFrame() In-Reply-To: <47C8451D.8040109@imavis.com> References: <47C8451D.8040109@imavis.com> Message-ID: >The problem is, deliverFrame returns the very first frame OK, then >doGetNextFrame is called again before a new frame is captured, and I >return immediately. Then, I don't know why, liveMedia never calls >doGetNextFrame again. It just stays stuck and apparently does nothing. > >Why? Because you are not delivering data to the downstream caller, and then calling "FramedSource::afterGetting(this);". Note that every incoming call to "doGetNextFrame()" must *eventually* result in (i) delivering data to the caller, and (ii) a call to "FramedSource::afterGetting(this);", to tell the downstream caller that delivery has been completed. The arrival (capture) of new frame data needs to be signalled (somehow) within the event loop, so that your implementation can notice it, and then call your "deliverFrame()" function. If your capture device is a socket, then you can easily do this using "TaskScheduler::turnOnBackgroundReadHandling()". If, however, your capture device is not a socket, then you can instead signal the arrival of new data by writing a new event loop (e.g., by subclassing "TaskScheduler"), or perhaps more simply by using the existing "watchVariable" feature (see the FAQ). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From brainlai at gmail.com Fri Feb 29 22:40:29 2008 From: brainlai at gmail.com (Brain Lai) Date: Sat, 1 Mar 2008 14:40:29 +0800 Subject: [Live-devel] Consider TCP connection with timeout in RTSPClient::describeURL(). Message-ID: Dear Sir: connect() in RTSPClient::openConnectionFromURL() is blocking. A practical application may not accept such a behavior. The following functions provide connect() with timeout setting on Windows(maybe work on Linux). Not very elegant but work. Please take them into consideration. Boolean makeSocketBlocking(int sock) { #if defined(__WIN32__) || defined(_WIN32) || defined(IMN_PIM) unsigned long arg = 0; return ioctlsocket(sock, FIONBIO, &arg) == 0; #elif defined(VXWORKS) int arg = 1; return ioctl(sock, FIONBIO, (int)&arg) == 0; #else int curFlags = fcntl(sock, F_GETFL, 0); return fcntl(sock, F_SETFL, curFlags|O_NONBLOCK) >= 0; #endif } int connect(SOCKET sock, const sockaddr *name, int namelen, int timeout) { if(!makeSocketNonBlocking(sock)) { fprintf("[connect()] fail to set socket non-blocking\n"); return -1; } struct timeval tv; tv.tv_sec = timeout; tv.tv_usec = 0; fd_set rfds, wfds; FD_ZERO(&rfds); int ret = connect(sock, name, namelen); do { if(ret == SOCKET_ERROR) { #if defined(__WIN32__) || defined(_WIN32) || defined(IMN_PIM) if(WSAGetLastError() != WSAEWOULDBLOCK) { fprintf(stderr, "[connect()] WSAGetLastError() %d\n", WSAGetLastError()); ret = -1; break; } else // need select #endif { FD_SET(sock, &rfds); wfds = rfds; ret = select(sock + 1, &rfds, &wfds, 0, &tv); if(ret == 0) { fprintf(stderr, "[connect()] timeout in %ds\n", timeout); ret = -1; break; } if(FD_ISSET(sock, &rfds) || FD_ISSET(sock, &wfds)) { int error; int size = sizeof(error); if(getsockopt(sock, SOL_SOCKET, SO_ERROR, (char*)&error, &size) != 0 || error != 0) { fprintf(stderr, "[connect()] getsockopt() error %d\n", error); ret = -1; break; } } else { fprintf(stderr, "[connect()] unknown error\n"); ret = -1; break; } } ret = 0; } else ret = 0; } while(false); if(!makeSocketBlocking(sock)) { fprintf("[connect()] fail to set socket blocking\n"); ret = -1; } return ret; } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20080229/18d145e7/attachment.html From finlayson at live555.com Fri Feb 29 23:02:15 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 29 Feb 2008 23:02:15 -0800 Subject: [Live-devel] Consider TCP connection with timeout in RTSPClient::describeURL(). In-Reply-To: References: Message-ID: >connect() in RTSPClient::openConnectionFromURL() is blocking. Yes. Our RTSP client implementation needs to be reimplemented to do non-blocking I/O. This is on our 'to do' list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/