From finlayson at live555.com Sun Jan 2 14:45:21 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 2 Jan 2011 14:45:21 -0800 Subject: [Live-devel] Porting to other OS, such as uC/OS, FreeRTOS, etc In-Reply-To: References: Message-ID: >What are the major issues for porting LIVE555 to other light-weight >RTOS, such as uC/OS, FreeRTOS, etc.? Has anybody tried yet? Any >experimental results available? We are considering to port LIVE555 >to STM32 ARM Cortex M3 with uC/OS. Is it possible at all? I don't know much about those particular OSs, but the "LIVE555 Streaming Media" code has been run on many embedded systems - especially Linux-based systems, but also some others. The main requirements seem to be: - A C++ compiler (obviously). - Support for the 'POSIX' API. - Support for the 'Berkeley sockets' API, including the "select()" call. "select()" is used by the "BasicTaskScheduler" implementation to implement an event loop. In principle, some other mechanism - not using "select()" - could be used to implement an event loop, by defining and implementing your own subclass of "TaskScheduler". In any case, though, other 'Berkeley sockets' calls - including "accept()", "connect()" and "bind()" - must be supported. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jan 2 20:58:30 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 2 Jan 2011 20:58:30 -0800 Subject: [Live-devel] Buffering incoming data with openRTSP? In-Reply-To: References: Message-ID: >After looking at the source code, playCommon.cpp > >Function:- >void continueAfterDESCRIBE(RTSPClient*, int resultCode, char* resultString) > >unsigned const thresh = 1000000; // 1 second >subsession->rtpSource()->setPacketReorderingThresholdTime(thresh); Note that this code affects *only* the application's behavior when packets happen to be reordered in the network - a situation that rarely happens. It is something that you almost certainly don't need to change. Perhaps you should start by explaining *specifically* what problem(s) you think you are seeing with the current code, and what you want to do? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jan 2 21:01:22 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 2 Jan 2011 21:01:22 -0800 Subject: [Live-devel] Buffering incoming data with openRTSP? Message-ID: You should also read http://www.live555.com/liveMedia/faq.html#packet-loss once again. I suspect that it is relevant to your question. (I say "once again", because this is part of the FAQ, which you were asked to read before posting to the mailing list :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Utkarsh.Nimesh at maxim-ic.com Sun Jan 2 21:51:09 2011 From: Utkarsh.Nimesh at maxim-ic.com (Utkarsh Nimesh) Date: Sun, 2 Jan 2011 23:51:09 -0600 Subject: [Live-devel] Buffering incoming data with openRTSP? In-Reply-To: References: Message-ID: Thanks for your inputs. The problem I am seeing in my use case is at 1.5 Mbps the video of the stored file gets "bursty" some times and is ok when bit rate is 500Kbps. So I am trying to check on source side to rule out any n/w loss or b/w issues. Decoder seems to be catching up as the data is always arriving late. The network has enough b/w (does it matter if it's TCP or UDP?) in my case. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, January 03, 2011 10:29 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Buffering incoming data with openRTSP? >After looking at the source code, playCommon.cpp > >Function:- >void continueAfterDESCRIBE(RTSPClient*, int resultCode, char* resultString) > >unsigned const thresh = 1000000; // 1 second >subsession->rtpSource()->setPacketReorderingThresholdTime(thresh); Note that this code affects *only* the application's behavior when packets happen to be reordered in the network - a situation that rarely happens. It is something that you almost certainly don't need to change. Perhaps you should start by explaining *specifically* what problem(s) you think you are seeing with the current code, and what you want to do? -- 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 Utkarsh.Nimesh at maxim-ic.com Sun Jan 2 21:54:15 2011 From: Utkarsh.Nimesh at maxim-ic.com (Utkarsh Nimesh) Date: Sun, 2 Jan 2011 23:54:15 -0600 Subject: [Live-devel] Buffering incoming data with openRTSP? In-Reply-To: References: Message-ID: Thanks, increasing buffer size will create latency in start of the playback like in case if VLC. I am only interested in error recovery in case of data loss. Looks like the code I mentioned in my mail has no impact on amount of buffering but only on the time we want to wait on the packets to arrive from n/w. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, January 03, 2011 10:31 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Buffering incoming data with openRTSP? You should also read http://www.live555.com/liveMedia/faq.html#packet-loss once again. I suspect that it is relevant to your question. (I say "once again", because this is part of the FAQ, which you were asked to read before posting to the 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 From satram at juniper.net Sun Jan 2 22:28:18 2011 From: satram at juniper.net (satheesh Ramalingam) Date: Mon, 3 Jan 2011 11:58:18 +0530 Subject: [Live-devel] Buffering incoming data with openRTSP? In-Reply-To: References: Message-ID: Hi, To check whether packets gets dropped at network, you can add debug prints in liveMedia/MultiFramedRTPSource.cpp void MultiFramedRTPSource::doGetNextFrame1() // Check whether we're part of a multi-packet frame, and whether // there was packet loss that would render this packet unusable: if (fCurrentPacketBeginsFrame) { if (packetLossPrecededThis || fPacketLossInFragmentedFrame) { // We didn't get all of the previous frame. // Forget any data that we used from it: fTo = fSavedTo; fMaxSize = fSavedMaxSize; fFrameSize = 0; } fPacketLossInFragmentedFrame = False; } else if (packetLossPrecededThis) { // We're in a multi-packet frame, with preceding packet loss fPacketLossInFragmentedFrame = True; } if (fPacketLossInFragmentedFrame) { // This packet is unusable; reject it: fReorderingBuffer->releaseUsedPacket(nextPacket); fNeedDelivery = True; break; } -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Utkarsh Nimesh Sent: Monday, January 03, 2011 11:21 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Buffering incoming data with openRTSP? Thanks for your inputs. The problem I am seeing in my use case is at 1.5 Mbps the video of the stored file gets "bursty" some times and is ok when bit rate is 500Kbps. So I am trying to check on source side to rule out any n/w loss or b/w issues. Decoder seems to be catching up as the data is always arriving late. The network has enough b/w (does it matter if it's TCP or UDP?) in my case. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, January 03, 2011 10:29 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Buffering incoming data with openRTSP? >After looking at the source code, playCommon.cpp > >Function:- >void continueAfterDESCRIBE(RTSPClient*, int resultCode, char* resultString) > >unsigned const thresh = 1000000; // 1 second >subsession->rtpSource()->setPacketReorderingThresholdTime(thresh); Note that this code affects *only* the application's behavior when packets happen to be reordered in the network - a situation that rarely happens. It is something that you almost certainly don't need to change. Perhaps you should start by explaining *specifically* what problem(s) you think you are seeing with the current code, and what you want to do? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Sun Jan 2 22:37:52 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 2 Jan 2011 22:37:52 -0800 Subject: [Live-devel] Buffering incoming data with openRTSP? In-Reply-To: References: Message-ID: >To check whether packets gets dropped at network, you can add debug prints in >liveMedia/MultiFramedRTPSource.cpp Or you could just run "openRTSP" with the "-Q" option, which will tell you this (and a lot more) without needing to modify the code at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From warren at etr-usa.com Mon Jan 3 11:58:43 2011 From: warren at etr-usa.com (Warren Young) Date: Mon, 03 Jan 2011 12:58:43 -0700 Subject: [Live-devel] Sysclock sanity check causes slow-motion MPEG-2 TS playback from live555MediaServer In-Reply-To: References: <4D1D076B.1010000@etr-usa.com> Message-ID: <4D222A73.3070404@etr-usa.com> On 12/31/2010 3:17 AM, Ross Finlayson wrote: > > If you're really seeing a problem with this new version, > then you're going to have to identify specifically what is causing it. I thought I had. I got it down to just one variable, the OS I ran the live555MediaServer binary on. I believe I controlled for all other variables. If you think I missed one, I'm open to hearing it. "The OS" is a big variable, I'll grant, but since the binary was statically linked to liblivemedia, that means the only other code that varies are things like libc, libstdc++, and the kernel, all of which I'd need a lot of evidence to blame. I think it's also significant that the problem is in the older OS, rather than the newer. It wouldn't be the first time that new code was tested and released, only to find that it breaks when run on an older platform that was once considered mainstream, but is no longer due purely to its age. >> Was this patch just "looks like a good idea" sort of patch, or does it >> fix something else, and reverting it breaks that? > > The latter. See > http://lists.live555.com/pipermail/live-devel/2010-November/012840.html I don't see a reply from the OP saying the change fixed his problem. And if it did, are you certain it doesn't just work around a problem with his media source? Are negative time values always bad? If it's small, gets added to a future time value that's greater than the difference between the packet scheduler's notion of "now" and the negative delta, the result is still a future time. If that's not it, then maybe timeNow isn't always a "sane" value here. Maybe your check for negative times is correct, but there's a better value to force when that happens. > Does this happen with all of your MPEG-2 TS video files, or only with > some of them? We have not yet found a file for which it does not happen. There are too many files to test them all. (Tens of thousands.) Even if we could isolate an encoding problem, we have little to no control over that. We've tried remuxing the files being tested with multiple remuxers, to no avail. No reprocessing more resource-intensive than remuxing will be practical, due to the number of files involved. > My current suspicion is that something strange about your TS file(s) > is (somehow) causing the duration estimate computation in > "MPEG2TransportStreamFramer" to go negative. Why blame the TS file when the only variable that changed is the OS? Same server binary, same source file. > It might be useful to see an example of a TS file that illustrates > the problem. I'll send you some URLs off-list. From finlayson at live555.com Mon Jan 3 18:52:52 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 3 Jan 2011 18:52:52 -0800 Subject: [Live-devel] Sysclock sanity check causes slow-motion MPEG-2 TS playback from live555MediaServer In-Reply-To: <4D222A73.3070404@etr-usa.com> References: <4D1D076B.1010000@etr-usa.com> <4D222A73.3070404@etr-usa.com> Message-ID: >>If you're really seeing a problem with this new version, >>then you're going to have to identify specifically what is causing it. > >I thought I had. I got it down to just one variable, the OS I ran >the live555MediaServer binary on. I meant: You're going to have to identify specifically what *in our code* is causing it, and why. However, I think I might have now done this (except for the "why" part :-). See below... >Are negative time values always bad? Yes, because the task scheduler code thinks it's seeing 'unsigned' (i.e., non-negative) values. (If negative values get passed to it, then the code may have still worked, but that would just be by accident.) >If that's not it, then maybe timeNow isn't always a "sane" value here. Yes, I've realized that the assignment fNextSendTime = timeNow; that we added at line 395 of "MultiFramedRTPSink.cpp" (as part of the 'sanity check' patch) isn't really right, because it might lead to small delays accumulating over time. (However, this doesn't explain the differences between OSs that you are apparently seeing.) In any case, could you try commenting out that statement, and let us know if it improves things (on the problematic OS)? >>It might be useful to see an example of a TS file that illustrates >>the problem. > >I'll send you some URLs off-list. Thanks. Those helped confirm that the 'sanity check' code was really being hit (due to some very small inter-packet durations being computed by the "MPEG2TransportStreamFramer"). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 3 19:11:13 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 3 Jan 2011 19:11:13 -0800 Subject: [Live-devel] Memory leak in BasicTaskScheduler0::scheduleDelayedTask In-Reply-To: <70903c2e66d71608dcdaa0f1888b6b85@tweb14-2.nm> References: <70903c2e66d71608dcdaa0f1888b6b85@tweb14-2.nm> Message-ID: >It seems to be memory leak in BasicTaskScheduler0::scheduleDelayedTask. No there's not. > AlarmHandler* alarmHandler = new AlarmHandler(proc, clientData, >timeToDelay); // here! where is 'delete' It gets deleted later, when the handler gets called. (Note the "delete this" in the implementation of "DelayQueueEntry::handleTimeout()".) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 4 01:16:15 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Jan 2011 01:16:15 -0800 Subject: [Live-devel] Why no file testH264VideoToDarwin. cpp In-Reply-To: <6e3ecce7.eebc.12d503a91f4.Coremail.13861333891@126.com> References: <6e3ecce7.eebc.12d503a91f4.Coremail.13861333891@126.com> Message-ID: >Why no file testH264VideoToDarwin. cpp ? Because our support for streaming from raw H.264 video files is very recent, but the "test*toDarwin" demo applications were developed several years ago. Also, as we note clearly in comments near the top of the file "testMPEG4VideoToDarwin.cpp": ////////// NOTE ////////// // This demo software is provided only as a courtesy to those developers who - for whatever reason - wish // to send outgoing streams through a separate Darwin Streaming Server. However, it is not necessary to use // a Darwin Streaming Server in order to serve streams using RTP/RTSP. Instead, the "LIVE555 Streaming Media" // includes its own RTSP/RTP server implementation, which you should use instead. For tips on using our // RTSP/RTP server implementation, see the "testOnDemandRTSPServer" demo application, and/or the // "live555MediaServer" application (in the "mediaServer") directory. ////////////////////////// -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From edi87 at fibertel.com.ar Tue Jan 4 08:17:11 2011 From: edi87 at fibertel.com.ar (edi87 at fibertel.com.ar) Date: Tue, 04 Jan 2011 13:17:11 -0300 Subject: [Live-devel] StreamState and afterPlayingStreamState function Message-ID: Hello, I'm now fighting with this. I added some debug information on afterPlayingStreamState static function: if( streamState->mediaSource()->isMPEG1or2VideoStreamFramer() == True ){ fprintf(stdout, "TEST: streamState->mediaSource()->isMPEG1or2VideoStreamFramer() = True\n"); }else{ fprintf(stdout, "TEST: streamState->mediaSource()->isMPEG1or2VideoStreamFramer() = False\n"); } I'm playing an Audio+Video MPEG and I found that this function just got executed by one of those frames, never both. I mean, I start playing the MPEG, when it ends, it just prints: "TEST: streamState->mediaSource()->isMPEG1or2VideoStreamFramer() = False" Appear that only the audio frame call the function when it ends, but the video frame never call it... is that something fine? it shouldn't got executed by both framers? Thanks in advance, Jonathan From warren at etr-usa.com Tue Jan 4 20:00:46 2011 From: warren at etr-usa.com (Warren Young) Date: Tue, 04 Jan 2011 21:00:46 -0700 Subject: [Live-devel] Sysclock sanity check causes slow-motion MPEG-2 TS playback from live555MediaServer In-Reply-To: References: <4D1D076B.1010000@etr-usa.com> <4D222A73.3070404@etr-usa.com> Message-ID: <4D23ECEE.7000000@etr-usa.com> On 1/3/2011 7:52 PM, Ross Finlayson wrote: >> If that's not it, then maybe timeNow isn't always a "sane" value here. [snip] > could you try commenting out that statement, and let us > know if it improves things (on the problematic OS)? Yes, that returns performance to the pre-2010.12.05 state. Thanks! > this doesn't explain the differences between OSs that you are apparently seeing [shrug] gettimeofday() is not a simple thing. I just re-read Chapter 6 in Bovet and Cesati, and in kernel 2.6, there are three different tick sources for this syscall, depending on available hardware and things like whether the CPU can throttle down to save power. Toss on top of that tick interpolation and the non-realtime nature of stock Linux... There's plenty of room for randomness. Would more files help you to understand what's going on here? As I said, we have plenty to choose from. From stu at nosnilmot.com Tue Jan 4 13:10:55 2011 From: stu at nosnilmot.com (Stu Tomlinson) Date: Tue, 04 Jan 2011 21:10:55 +0000 Subject: [Live-devel] openRTSP Quicktime compatibility Message-ID: <1294175455.4623.12960.camel@espresso.gravel> Hello, I have been trying to use openRTSP (from liveMedia dated 2010.12.05) to record clips from an IP camera that supports RTSP streaming of MPEG-4 clips, but the recorded clips would not play back in Quicktime 7.6.8 (1675) on Windows. For .mov files (recorded with -q) the clip would appear to play (progress bar would move) but the video content is a blank/white image, for .mp4 files (recorded with -4) Quicktime would refuse to load the clip reporting "Error -2010: the movie contains some invalid data ()". I discovered that simply "re-packaging" the clip without any re-encoding of the actual stream using "mencoder" resulted in files that would play without issue. After analyzing the differences in the files produced by openRTSP & mencoder I have been able to come up with the attached minimal patch to change the "magic bytes" recorded in the esds atom, and with this patch applied openRTSP will record files (.mov or .mp4) that Quicktime is able to play without any further changes. One other difference I noticed is that the mencoded file does not seem to have the 0-word in the file after the esds atom, but I saw no difference in compatibility with Quicktime when removing that from QuickTimeFileSink.cpp (line 1929), so this patch does not touch that. Regards, Stu. -------------- next part -------------- A non-text attachment was scrubbed... Name: liveMedia-2010.12.31-quicktime.patch Type: text/x-patch Size: 684 bytes Desc: not available URL: From finlayson at live555.com Tue Jan 4 22:28:34 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Jan 2011 22:28:34 -0800 Subject: [Live-devel] openRTSP Quicktime compatibility In-Reply-To: <1294175455.4623.12960.camel@espresso.gravel> References: <1294175455.4623.12960.camel@espresso.gravel> Message-ID: >I have been trying to use openRTSP (from liveMedia dated 2010.12.05) to >record clips from an IP camera that supports RTSP streaming of MPEG-4 >clips, but the recorded clips would not play back in Quicktime 7.6.8 >(1675) on Windows. I hope you used the "-w ", "-h " and "-f " options. >After analyzing the differences in the files produced by openRTSP & >mencoder I have been able to come up with the attached minimal patch to >change the "magic bytes" recorded in the esds atom, and with this patch >applied openRTSP will record files (.mov or .mp4) that Quicktime is able >to play without any further changes. Thanks. I must confess that I have no idea what these values in the "esds" atom are supposed to mean, but because the modified values seem to work for you, I'll (somewhat reluctantly) include this patch in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 4 22:57:33 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 4 Jan 2011 22:57:33 -0800 Subject: [Live-devel] Sysclock sanity check causes slow-motion MPEG-2 TS playback from live555MediaServer In-Reply-To: <4D23ECEE.7000000@etr-usa.com> References: <4D1D076B.1010000@etr-usa.com> <4D222A73.3070404@etr-usa.com> <4D23ECEE.7000000@etr-usa.com> Message-ID: >>could you try commenting out that statement, and let us >>know if it improves things (on the problematic OS)? > >Yes, that returns performance to the pre-2010.12.05 state. Thanks! OK, I've now installed a new version (2011.01.05) of the code that removes this statement. Thanks for alerting us to the issue. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From christophe at lemoine-fr.com Wed Jan 5 01:29:16 2011 From: christophe at lemoine-fr.com (Christophe Lemoine) Date: Wed, 05 Jan 2011 11:29:16 +0200 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: References: Message-ID: <4D2439EC.5050407@lemoine-fr.com> Hi Ross, This is really great news. Thanks a lot for your work. Now: I'm trying to stream a TS file containing H.264 video (encoded with x264) and tried many encoding parameters, but cannot get a decent quality (lots of jittering, VLC as a client complains about audio drifts, late frames, .....). Do you have a sample file or encoding parameters that works fine for you ? Thanks Christophe On 12/31/2010 05:13 PM, Ross Finlayson wrote: > Happy New Year (for some of you). > > I have now installed a new version (2010.12.31) of the "LIVE555 > Streaming Media" code that supports 'trick play' operations (seeking, > fast-forward, reverse play) on MPEG Transport Stream files that > contain H.264 video (rather than just MPEG-2 video, as in previous > versions). > > To support this, the index file format has been extended in a > backwards-compatible way, so that your existing index files - for > MPEG-2 video Transport Streams - will continue to work as before. > > To create an index file for H.264 Transport Streams - and to act as a > server for such streams - you will, of course, need to download the > new code. I have also released new binary versions of the > "MPEG2TransportStreamIndexer" and "testMPEG2TransportStreamTrickPlay" > utilities, and the "live555MediaServer" - for Windows, MacOS/Intel, > FreeBSD, and Linux/Intel. > > The new code has been tested for only a few H.264 Transport Stream > files, and might not work properly for all such files. (In > particular, it relies upon a SPS (Sequence Parameter Set) NAL unit > appearing shortly before each 'I-frame'.) As always, if you have an > example of a Transport Stream file for which the indexing (or > subsequent trick play) does *not* work, then please put the file on a > web server, and send a link to the file (*not* the file itself) to the > mailing list, and we'll examine it to see if we can figure out the > problem. From finlayson at live555.com Wed Jan 5 01:50:38 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Jan 2011 01:50:38 -0800 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: <4D2439EC.5050407@lemoine-fr.com> References: <4D2439EC.5050407@lemoine-fr.com> Message-ID: >Do you have a sample file or encoding parameters that works fine for you ? You can find a couple of files - that I used for testing - in http://www.live555.com/liveMedia/public/h264-in-mp2t/ (I got these from somewhere else; I didn't encode any files myself.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From amadorim at vdavda.com Wed Jan 5 02:04:52 2011 From: amadorim at vdavda.com (Marco Amadori) Date: Wed, 5 Jan 2011 11:04:52 +0100 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: References: Message-ID: <201101051104.53102.amadorim@vdavda.com> In data Friday 31 December 2010 16:13:36, Ross Finlayson ha scritto: > Happy New Year (for some of you). Happy new year to you too! > I have now installed a new version (2010.12.31) of the "LIVE555 > Streaming Media" code that supports 'trick play' operations (seeking, > fast-forward, reverse play) on MPEG Transport Stream files that > contain H.264 video (rather than just MPEG-2 video, as in previous > versions). Great achievement! Congratulations and thanks! I'll report if it does not work on some content. -- ESC:wq -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vincenzo.terracciano at its.na.it Wed Jan 5 04:10:51 2011 From: vincenzo.terracciano at its.na.it (Vincenzo Terracciano) Date: Wed, 5 Jan 2011 13:10:51 +0100 Subject: [Live-devel] R: New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: <4D2439EC.5050407@lemoine-fr.com> References: <4D2439EC.5050407@lemoine-fr.com> Message-ID: I have a lot of problems (audio silence) with testOnDemandRTSP and a TS file containing H.264 video and MPEG2 audio that I have recorded dumping a live streaming. Below you can see some of the VLC messages: main warning: buffer is 89744 in advance, triggering downsampling main debug: auto hidding mouse main warning: resampling stopped after 891613 usec (drift: 9469) main warning: buffer is 62239 in advance, triggering downsampling main warning: audio drift is too big (-145371), clearing out main warning: timing screwed, stopping resampling main warning: mixer start isn't output start (-39870) main debug: audio output is starving (265217), playing silence main warning: buffer is 40509 late, triggering upsampling main warning: resampling stopped after 2447308 usec (drift: 69709) main warning: buffer is 68604 in advance, triggering downsampling main warning: audio drift is too big (-125407), clearing out main warning: timing screwed, stopping resampling main warning: mixer start isn't output start (-43800) main debug: audio output is starving (285006), playing silence main warning: buffer is 41024 in advance, triggering downsampling main warning: timing screwed, stopping resampling main warning: buffer is 65964 in advance, triggering downsampling main warning: timing screwed, stopping resampling main warning: buffer is 99078 in advance, triggering downsampling main warning: audio drift is too big (-123122), clearing out main warning: timing screwed, stopping resampling main warning: mixer start isn't output start (-31543) main debug: audio output is starving (157370), playing silence main warning: buffer is 44203 in advance, triggering downsampling If I play the recorded file with VLC it is ok. Do you have any suggestions? Thanks. ------------------------------------------------------------------ ITS S.p.A. Vincenzo Terracciano, Via Terragneta 90, 80058 Torre Annunziata(NA) +39 081 5353392 -----Messaggio originale----- Da: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Per conto di Christophe Lemoine Inviato: mercoled? 5 gennaio 2011 10.29 A: LIVE555 Streaming Media - development & use Oggetto: Re: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files Hi Ross, This is really great news. Thanks a lot for your work. Now: I'm trying to stream a TS file containing H.264 video (encoded with x264) and tried many encoding parameters, but cannot get a decent quality (lots of jittering, VLC as a client complains about audio drifts, late frames, .....). Do you have a sample file or encoding parameters that works fine for you ? Thanks Christophe On 12/31/2010 05:13 PM, Ross Finlayson wrote: > Happy New Year (for some of you). > > I have now installed a new version (2010.12.31) of the "LIVE555 > Streaming Media" code that supports 'trick play' operations (seeking, > fast-forward, reverse play) on MPEG Transport Stream files that > contain H.264 video (rather than just MPEG-2 video, as in previous > versions). > > To support this, the index file format has been extended in a > backwards-compatible way, so that your existing index files - for > MPEG-2 video Transport Streams - will continue to work as before. > > To create an index file for H.264 Transport Streams - and to act as a > server for such streams - you will, of course, need to download the > new code. I have also released new binary versions of the > "MPEG2TransportStreamIndexer" and "testMPEG2TransportStreamTrickPlay" > utilities, and the "live555MediaServer" - for Windows, MacOS/Intel, > FreeBSD, and Linux/Intel. > > The new code has been tested for only a few H.264 Transport Stream > files, and might not work properly for all such files. (In > particular, it relies upon a SPS (Sequence Parameter Set) NAL unit > appearing shortly before each 'I-frame'.) As always, if you have an > example of a Transport Stream file for which the indexing (or > subsequent trick play) does *not* work, then please put the file on a > web server, and send a link to the file (*not* the file itself) to the > mailing list, and we'll examine it to see if we can figure out the > problem. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From vincenzo.terracciano at its.na.it Wed Jan 5 07:26:34 2011 From: vincenzo.terracciano at its.na.it (Vincenzo Terracciano) Date: Wed, 5 Jan 2011 16:26:34 +0100 Subject: [Live-devel] R: R: New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: References: <4D2439EC.5050407@lemoine-fr.com> Message-ID: I posted on an HTTP server the ts file related to previous email. The url is http://88.53.98.64:8090/test008.ts. I hope that you can help me. ------------------------------------------------------------------ ITS S.p.A. Vincenzo Terracciano, Via Terragneta 90, 80058 Torre Annunziata(NA) +39 081 5353392 -----Messaggio originale----- Da: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Per conto di Vincenzo Terracciano Inviato: mercoled? 5 gennaio 2011 13.11 A: 'LIVE555 Streaming Media - development & use' Oggetto: [Live-devel] R: New LIVE555 version,now supports 'trick play' on H.264 Transport Stream files I have a lot of problems (audio silence) with testOnDemandRTSP and a TS file containing H.264 video and MPEG2 audio that I have recorded dumping a live streaming. Below you can see some of the VLC messages: main warning: buffer is 89744 in advance, triggering downsampling main debug: auto hidding mouse main warning: resampling stopped after 891613 usec (drift: 9469) main warning: buffer is 62239 in advance, triggering downsampling main warning: audio drift is too big (-145371), clearing out main warning: timing screwed, stopping resampling main warning: mixer start isn't output start (-39870) main debug: audio output is starving (265217), playing silence main warning: buffer is 40509 late, triggering upsampling main warning: resampling stopped after 2447308 usec (drift: 69709) main warning: buffer is 68604 in advance, triggering downsampling main warning: audio drift is too big (-125407), clearing out main warning: timing screwed, stopping resampling main warning: mixer start isn't output start (-43800) main debug: audio output is starving (285006), playing silence main warning: buffer is 41024 in advance, triggering downsampling main warning: timing screwed, stopping resampling main warning: buffer is 65964 in advance, triggering downsampling main warning: timing screwed, stopping resampling main warning: buffer is 99078 in advance, triggering downsampling main warning: audio drift is too big (-123122), clearing out main warning: timing screwed, stopping resampling main warning: mixer start isn't output start (-31543) main debug: audio output is starving (157370), playing silence main warning: buffer is 44203 in advance, triggering downsampling If I play the recorded file with VLC it is ok. Do you have any suggestions? Thanks. ------------------------------------------------------------------ ITS S.p.A. Vincenzo Terracciano, Via Terragneta 90, 80058 Torre Annunziata(NA) +39 081 5353392 -----Messaggio originale----- Da: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Per conto di Christophe Lemoine Inviato: mercoled? 5 gennaio 2011 10.29 A: LIVE555 Streaming Media - development & use Oggetto: Re: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files Hi Ross, This is really great news. Thanks a lot for your work. Now: I'm trying to stream a TS file containing H.264 video (encoded with x264) and tried many encoding parameters, but cannot get a decent quality (lots of jittering, VLC as a client complains about audio drifts, late frames, .....). Do you have a sample file or encoding parameters that works fine for you ? Thanks Christophe On 12/31/2010 05:13 PM, Ross Finlayson wrote: > Happy New Year (for some of you). > > I have now installed a new version (2010.12.31) of the "LIVE555 > Streaming Media" code that supports 'trick play' operations (seeking, > fast-forward, reverse play) on MPEG Transport Stream files that > contain H.264 video (rather than just MPEG-2 video, as in previous > versions). > > To support this, the index file format has been extended in a > backwards-compatible way, so that your existing index files - for > MPEG-2 video Transport Streams - will continue to work as before. > > To create an index file for H.264 Transport Streams - and to act as a > server for such streams - you will, of course, need to download the > new code. I have also released new binary versions of the > "MPEG2TransportStreamIndexer" and "testMPEG2TransportStreamTrickPlay" > utilities, and the "live555MediaServer" - for Windows, MacOS/Intel, > FreeBSD, and Linux/Intel. > > The new code has been tested for only a few H.264 Transport Stream > files, and might not work properly for all such files. (In > particular, it relies upon a SPS (Sequence Parameter Set) NAL unit > appearing shortly before each 'I-frame'.) As always, if you have an > example of a Transport Stream file for which the indexing (or > subsequent trick play) does *not* work, then please put the file on a > web server, and send a link to the file (*not* the file itself) to the > mailing list, and we'll examine it to see if we can figure out the > problem. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Wed Jan 5 09:02:19 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Jan 2011 09:02:19 -0800 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: References: <4D2439EC.5050407@lemoine-fr.com> Message-ID: (Note that this particular problem has nothing to do with 'trick play'; your streaming problem happens even if no index file is created. It probably also doesn't have anything specifically to do with H.264 (see below).) Problems like this (VLC being able to play a file OK, but 'stuttering' if the same file is streamed from our RTSP server) are usually caused by a problem with the PCR timestamps in the file. (The server's "MPEG2TransportStreamFramer" object - which regulates the rate at which the data is output - uses the file's PCR timestamps to dynamically compute an estimate of the 'duration' of each Transport Stream packet, which in turn is used by the server to dynamically compute the rate at which data should be sent.) I suspect that perhaps your file is highly 'VBR' (variable bit rate), and the PCR timestamps are not occurring in the file frequently enough for our "MPEG2TransportStreamFramer" to properly adapt to it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From gbonneau at miranda.com Wed Jan 5 09:32:53 2011 From: gbonneau at miranda.com (BONNEAU Guy) Date: Wed, 5 Jan 2011 17:32:53 +0000 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: References: <4D2439EC.5050407@lemoine-fr.com> Message-ID: <24665DDC0D7CF047BD6471A56E615EA602A94E@CA-OPS-MAILBOX.miranda.com> Ross, I am not sure if this has been already done but can I suggest that you scale the timer resolution of the testOnDemandRTSP application to 1 ms . This would help to lower the jitter of the RTP packets sent. Under Windows you can use TimeBeginPeriod(1) to do this. With Linux I guess there must me a mean to do it. I have been able to fix cases similar to the one described about VLC when streaming Mpeg2 TS with testOnDemandRTSP by lowering the timer resolution. http://www.mail-archive.com/live-devel at lists.live555.com/msg05507.html GB |-----Original Message----- |From: live-devel-bounces at ns.live555.com [mailto:live-devel- |bounces at ns.live555.com] On Behalf Of Ross Finlayson |Sent: Wednesday, January 5, 2011 12:02 |To: LIVE555 Streaming Media - development & use |Subject: Re: [Live-devel] New LIVE555 version, now supports 'trick play' on |H.264 Transport Stream files | |(Note that this particular problem has nothing to do with 'trick play'; your |streaming problem happens even if no index file is created. It probably also |doesn't have anything specifically to do with H.264 (see below).) | |Problems like this (VLC being able to play a file OK, but 'stuttering' if the same |file is streamed from our RTSP server) are usually caused by a problem with |the PCR timestamps in the file. |(The server's "MPEG2TransportStreamFramer" object - which regulates the |rate at which the data is output - uses the file's PCR timestamps to dynamically |compute an estimate of the 'duration' of each Transport Stream packet, which |in turn is used by the server to dynamically compute the rate at which data |should be sent.) | |I suspect that perhaps your file is highly 'VBR' (variable bit rate), and the PCR |timestamps are not occurring in the file frequently enough for our |"MPEG2TransportStreamFramer" to properly adapt to it. |-- | |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 maciej at axiaaudio.com Wed Jan 5 09:18:32 2011 From: maciej at axiaaudio.com (Maciej Szlapka) Date: Wed, 05 Jan 2011 12:18:32 -0500 Subject: [Live-devel] VLC Player and RTP 24-bit PCM audio Message-ID: I would like to be able to use VLC player to play audio streams which are IP multicast RTP 24-bit PCM at 48kHz. I learned VLC uses live555 plugin to play RTP audio described by an .sdp. Unfortunately L24 is not working. The format can be described using such SDP file: v=0 o=Node 1 1 IN IP4 192.168.2.121 s=TestSine t=0 0 a=type:multicast c=IN IP4 239.192.4.187 m=audio 5004 RTP/AVP 96 a=rtpmap:96 L24/48000/2 What can we do to have that working? Regards, Maciej From finlayson at live555.com Wed Jan 5 16:35:39 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 5 Jan 2011 16:35:39 -0800 Subject: [Live-devel] VLC Player and RTP 24-bit PCM audio In-Reply-To: References: Message-ID: >I would like to be able to use VLC player to play audio streams which are >IP multicast RTP 24-bit PCM at 48kHz. I learned VLC uses live555 plugin to >play RTP audio described by an .sdp. Unfortunately L24 is not working. Thanks for the note. Previously the LIVE555 libraries did not handle receiving the RTP payload formats "audio/L20", "audio/L24" and "audio/DAT12", which are defined in RFC 3190. However, I have now installed a new version (2011.01.06) of the libraries that will recognize these. So now, to get VLC to handle your stream, you will need to contact the VLC developers (on a VLC mailing list), telling them that: 1/ The latest version (2011.01.06) of the "LIVE555 Streaming Media" libraries now supports receiving the RTP payload formats "audio/L20", "audio/L24" and "audio/DAT12" (as defined in RFC 3190). 2/ If VLC is able to decode these audio formats (20-bit linear, 24-bit linear, and 12-bit nonlinear, respectively), then they should update their LIVE555 interface code ("modules_demux_live555.cpp") to recognize whichever of these formats they can decode. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Paul.Corke at datatote.co.uk Thu Jan 6 02:05:19 2011 From: Paul.Corke at datatote.co.uk (Paul Corke) Date: Thu, 6 Jan 2011 10:05:19 -0000 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files Message-ID: <72D9E13A8FC8994794D448E91198AE07020D6876@mail.sys.internal> On 05 January 2011 17:02, Ross Finlayson wrote: > 'stuttering' if the same file is streamed from our RTSP server) are > usually caused by a problem with the PCR timestamps in the file. > (The server's "MPEG2TransportStreamFramer" object - which regulates > the rate at which the data is output - uses the file's PCR timestamps > to dynamically compute an estimate of the 'duration' of each > Transport Stream packet, which in turn is used by the server to We had a similar problem with MPEG2 files that are hardware encoded with a Hauppauge PVR-150 card (CBR file). The PCR timestamps increase regularly but infrequently. I fully understand that the liveMedia code should not be modified but in case it's helpful to anyone, our workaround was to change MPEG2TransportStreamFramer.cpp so that: #define NEW_DURATION_WEIGHT 0.05 also due to the size of the jitter buffer on the receiver we have: #define MAX_PLAYOUT_BUFFER_DURATION 0.25 Regards, Paul. From finlayson at live555.com Thu Jan 6 08:00:25 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 6 Jan 2011 08:00:25 -0800 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: <72D9E13A8FC8994794D448E91198AE07020D6876@mail.sys.internal> References: <72D9E13A8FC8994794D448E91198AE07020D6876@mail.sys.internal> Message-ID: >We had a similar problem with MPEG2 files that are hardware >encoded with a Hauppauge PVR-150 card (CBR file). The PCR >timestamps increase regularly but infrequently. > >I fully understand that the liveMedia code should not be modified >but in case it's helpful to anyone, our workaround was to change >MPEG2TransportStreamFramer.cpp so that: > >#define NEW_DURATION_WEIGHT 0.05 > >also due to the size of the jitter buffer on the receiver we have: > >#define MAX_PLAYOUT_BUFFER_DURATION 0.25 Yes, setting values for those 4 parameters in "MPEG2TransportStreamFramer.cpp" is, unfortunately, somewhat of a 'black art'; it's going to be hard - if not impossible - to find values that will work well for everybody. Note, though, that each of these definitions is enclosed by #if !defined( ... ) #endif So it's possible to change these values without changing the file "MPEG2TransportStreamFramer.cpp" itself. (E.g., you could define your new values on the command line when you compile the file.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vincenzo.terracciano at its.na.it Mon Jan 10 01:51:40 2011 From: vincenzo.terracciano at its.na.it (Vincenzo Terracciano) Date: Mon, 10 Jan 2011 10:51:40 +0100 Subject: [Live-devel] R: New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: References: <72D9E13A8FC8994794D448E91198AE07020D6876@mail.sys.internal> Message-ID: <98EAECEBA1684E0F910ECA435383A2B1@its.na.it> Dear all, changing the values of the constants NEW_DURATION_WEIGHT MAX_PLAYOUT_BUFFER_DURATION I solved a lot of the problems that I said in the last e-mail (rtsp on ts file that contains H264 video). Audio starving remains only related to the discontinuities in the transmission. Below I report the VLC messages. ts warning: discontinuity received 0x6 instead of 0x0 (pid=224) ts debug: PMTCallBack called ts debug: PATCallBack called main warning: audio drift is too big (-178823), clearing out main warning: mixer start isn't output start (-58466) main debug: audio output is starving (248354), playing silence The file has been recorded on the same host of the encoder component. Do you think that I can have errors on the encoder side? Thank you so much. ------------------------------------------------------------------ ITS S.p.A. Vincenzo Terracciano, Via Terragneta 90, 80058 Torre Annunziata(NA) +39 081 5353392 -----Messaggio originale----- Da: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] Per conto di Ross Finlayson Inviato: gioved? 6 gennaio 2011 17.00 A: LIVE555 Streaming Media - development & use Oggetto: Re: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files >We had a similar problem with MPEG2 files that are hardware >encoded with a Hauppauge PVR-150 card (CBR file). The PCR >timestamps increase regularly but infrequently. > >I fully understand that the liveMedia code should not be modified >but in case it's helpful to anyone, our workaround was to change >MPEG2TransportStreamFramer.cpp so that: > >#define NEW_DURATION_WEIGHT 0.05 > >also due to the size of the jitter buffer on the receiver we have: > >#define MAX_PLAYOUT_BUFFER_DURATION 0.25 Yes, setting values for those 4 parameters in "MPEG2TransportStreamFramer.cpp" is, unfortunately, somewhat of a 'black art'; it's going to be hard - if not impossible - to find values that will work well for everybody. Note, though, that each of these definitions is enclosed by #if !defined( ... ) #endif So it's possible to change these values without changing the file "MPEG2TransportStreamFramer.cpp" itself. (E.g., you could define your new values on the command line when you compile the 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 From EugeneUshakov at yandex.ru Sun Jan 9 12:31:47 2011 From: EugeneUshakov at yandex.ru (Eugene Ushakov) Date: Sun, 09 Jan 2011 23:31:47 +0300 Subject: [Live-devel] Please consult me about live555 issue with mp4v streaming playback Message-ID: <4D2A1B33.3050303@yandex.ru> Ross, Could you please give me some information about my trouble. I use vlc to recive streaming media feed from RTSP source. I can see following issue.. When i run rtsp://remote:ViewNow1 at 80.179.197.53/live.sdp with VLC it some times plays well but sometimes(once per about three launches) it starts with green screen. Video of this feed encoded with mp4v. Also i can play rtsp://root:pass at 213.8.59.59:22335/ch0_unicast_firststream vedeo is encoded with h264 and it's play perfectly without greenscreen all time. I tried debug VLC but seems that green screen appeared when live555 libs's methods are called. What do you think about this issue, do you think that getting of lates version of live555 lib will help to fix this? Where similar issues with live555? Regards, Eugene. From finlayson at live555.com Mon Jan 10 02:28:48 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Jan 2011 02:28:48 -0800 Subject: [Live-devel] Please consult me about live555 issue with mp4v streaming playback In-Reply-To: <4D2A1B33.3050303@yandex.ru> References: <4D2A1B33.3050303@yandex.ru> Message-ID: >Could you please give me some information about my trouble. Sorry, no - because VLC is not our application, and the problem that you describe seems to have nothing to do with VLC's use of the LIVE555 libraries. (Instead, it seems to be an issue with decoding, which we have nothing to do with.) You should ask about this on a VLC mailing list instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From satram at juniper.net Mon Jan 10 02:50:05 2011 From: satram at juniper.net (satheesh Ramalingam) Date: Mon, 10 Jan 2011 16:20:05 +0530 Subject: [Live-devel] Please consult me about live555 issue with mp4v streaming playback In-Reply-To: <4D2A1B33.3050303@yandex.ru> References: <4D2A1B33.3050303@yandex.ru> Message-ID: Hi Eugene, I had seen similar issue before. In my implementation using Live555, for mpeg4 video streaming, VLC starts with green screen and it corrects with the arrival of subsequent I-frame. Have you observed the green screen going off after VLC received subsequent i-frame in the sequence? If that happens, pls check whether you are transmitting all necessary info for decoding the first i-frame (like VOP, VOL)? -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Eugene Ushakov Sent: Monday, January 10, 2011 2:02 AM To: live-devel at ns.live555.com Subject: [Live-devel] Please consult me about live555 issue with mp4v streaming playback Ross, Could you please give me some information about my trouble. I use vlc to recive streaming media feed from RTSP source. I can see following issue.. When i run rtsp://remote:ViewNow1 at 80.179.197.53/live.sdp with VLC it some times plays well but sometimes(once per about three launches) it starts with green screen. Video of this feed encoded with mp4v. Also i can play rtsp://root:pass at 213.8.59.59:22335/ch0_unicast_firststream vedeo is encoded with h264 and it's play perfectly without greenscreen all time. I tried debug VLC but seems that green screen appeared when live555 libs's methods are called. What do you think about this issue, do you think that getting of lates version of live555 lib will help to fix this? Where similar issues with live555? Regards, Eugene. _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From christophe at lemoine-fr.com Mon Jan 10 04:54:31 2011 From: christophe at lemoine-fr.com (Christophe Lemoine) Date: Mon, 10 Jan 2011 14:54:31 +0200 Subject: [Live-devel] TS file with high VBR Message-ID: <4D2B0187.7030608@lemoine-fr.com> Hi, I'm still trying to properly encode a TS file containing H264 video (HD) in order to be able to stream it. The file has a quite high VBR as B and P frames are very often much much smaller than I frames (quite expected with H264). I then get lots of jittering, especially when the image is not changing a lot (P and B frames are very small). When muxing in CBR, I get much smoother streaming, but, obviously, the file becomes huge and the network usage higher (in CBR I might also be loosing some packets as I sometime have decoding errors in the client). The muxing itself should be ok (PCR is based on frame DTS - a fixed delay. This is the way ffmpeg mux for VBR. So, I think that if packets are sent on time, the player should get them before it must decode it). Maybe I'm wrong, but, by reading the code of the media server, it looks likes it relies on an average BR to determine when to send the packets (based on past packets). The PCR is used to compute this average, but not to determine when to actually send the packets. (I might be totally wrong here as I must admit that the code is quite complex and I probably have missed something.....). Now, if I'm not totally wrong, would there be a way to either: - Rely on PCR to determine when to send packets (something like: get the next PCR, determine BR from first packet till this PCR packet, send packets in a way where the packet containing the PCR is sent on time). - Or: use the index file to store current frame BR (so use the actual BR of a frame instead of an average based on past frames) Thanks for your help Christophe From finlayson at live555.com Mon Jan 10 06:44:20 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 10 Jan 2011 06:44:20 -0800 Subject: [Live-devel] TS file with high VBR In-Reply-To: <4D2B0187.7030608@lemoine-fr.com> References: <4D2B0187.7030608@lemoine-fr.com> Message-ID: >Maybe I'm wrong, but, by reading the code of the media server, it >looks likes it relies on an average BR to determine when to send the >packets (based on past packets). Yes. (This is done in "MPEG2TransportStreamFramer".) > The PCR is used to compute this average, but not to determine when >to actually send the packets. (I might be totally wrong here as I >must admit that the code is quite complex and I probably have missed >something.....). >Now, if I'm not totally wrong, would there be a way to either: > - Rely on PCR to determine when to send packets (something >like: get the next PCR, determine BR from first packet till this PCR >packet, send packets in a way where the packet containing the PCR is >sent on time). The "MPEG2TransportStreamFramer" code is intended to work when streaming arbitrary Transport Stream data - including Transport Stream data that might come 'live' from an encoder. It therefore has no knowledge of 'the next PCR' (because it doesn't look ahead in time). However... > - Or: use the index file to store current frame BR (so use >the actual BR of a frame instead of an average based on past frames) Yes, for Transport Stream files for which we have pre-computed an index file, we do - in principle - have enough 'future' information (using PCR values) from which we could compute a more accurate 'duration' for each outgoing Transport Stream packet. In the past I had considered modifying "MPEG2TransportStreamFramer" to use this information, but didn't (because such a solution would work only for Transport Stream files for which we have index files, whereas the existing code works for any Transport Stream data). However, because - as you noted - excessively VBR streams are more likely to be a problem with H.264 Transport Streams, I think I'll take another look at this, to see if we can use the index file - when present - to generate more accurate Transport Stream 'durations'. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From christophe at lemoine-fr.com Tue Jan 11 00:22:31 2011 From: christophe at lemoine-fr.com (Christophe Lemoine) Date: Tue, 11 Jan 2011 10:22:31 +0200 Subject: [Live-devel] TS file with high VBR In-Reply-To: References: <4D2B0187.7030608@lemoine-fr.com> Message-ID: <4D2C1347.4050804@lemoine-fr.com> Hi Ross, Thanks a lot for your answer: that would be great to have better support for high VBR TS file. I get your point regarding streaming of live encoder. Maybe the code could be different depending on the stream source. While testing different muxers, I'm getting confused by some results..... I use tsreport to get the Transport Stream bit rate. - ffmpeg gives files with very high VBR. Basically, it justs add the PCR based on the video frame DTS when VBR is requested. Here is an example report. .. PCR 17010342 Mean byterate 5114089 byterate 5113793 .. PCR 19440250 Mean byterate 5114313 byterate 5115882 .. PCR 21870158 Mean byterate 4739385 byterate 1740110 .. PCR 24300066 Mean byterate 4265636 byterate 2088 .. PCR 26730960 Mean byterate 3878453 byterate 8352 - TSMuxer gives similar results. - Some (commercial muxers), while still generating VBR TS file (no null packets to make it CBR), have a CBR when looking at the PCR time and number of packets between PCRs (time between packets remains constant). I still trying to understand the details, but my guess is that the number of packets between 2 I frames should not vary by a lot. Then, it might be possible to play with the delay between the PCR and the frames DTS to make the stream looks like CBR. The player buffer will then have to cope with it. But, obviously, the algorithm in the muxer must be quite complex to determine the proper PCRs, without getting the difference between PCR and DTS drifting... Example report (same source video file as with ffmpeg, result ts file size very similar) .. PCR 5013968 Mean byterate 1313100 byterate 1313100 .. PCR 6015175 Mean byterate 1313099 byterate 1313099 .. PCR 7016381 Mean byterate 1313100 byterate 1313100 .. PCR 8017587 Mean byterate 1313100 byterate 1313100 .. PCR 9018794 Mean byterate 1313099 byterate 1313099 .. PCR 10020000 Mean byterate 1313100 byterate 1313100 .. PCR 11021206 Mean byterate 1313100 byterate 1313100 .. PCR 12022413 Mean byterate 1313099 byterate 1313099 BR Christophe On 01/10/2011 04:44 PM, Ross Finlayson wrote: >> Maybe I'm wrong, but, by reading the code of the media server, it >> looks likes it relies on an average BR to determine when to send the >> packets (based on past packets). > > Yes. (This is done in "MPEG2TransportStreamFramer".) > > >> The PCR is used to compute this average, but not to determine when >> to actually send the packets. (I might be totally wrong here as I >> must admit that the code is quite complex and I probably have missed >> something.....). >> Now, if I'm not totally wrong, would there be a way to either: >> - Rely on PCR to determine when to send packets (something >> like: get the next PCR, determine BR from first packet till this PCR >> packet, send packets in a way where the packet containing the PCR is >> sent on time). > > The "MPEG2TransportStreamFramer" code is intended to work when > streaming arbitrary Transport Stream data - including Transport Stream > data that might come 'live' from an encoder. It therefore has no > knowledge of 'the next PCR' (because it doesn't look ahead in time). > However... > > >> - Or: use the index file to store current frame BR (so use the >> actual BR of a frame instead of an average based on past frames) > > Yes, for Transport Stream files for which we have pre-computed an > index file, we do - in principle - have enough 'future' information > (using PCR values) from which we could compute a more accurate > 'duration' for each outgoing Transport Stream packet. In the past I > had considered modifying "MPEG2TransportStreamFramer" to use this > information, but didn't (because such a solution would work only for > Transport Stream files for which we have index files, whereas the > existing code works for any Transport Stream data). > > However, because - as you noted - excessively VBR streams are more > likely to be a problem with H.264 Transport Streams, I think I'll take > another look at this, to see if we can use the index file - when > present - to generate more accurate Transport Stream 'durations'. From christophe at lemoine-fr.com Tue Jan 11 03:06:34 2011 From: christophe at lemoine-fr.com (Christophe Lemoine) Date: Tue, 11 Jan 2011 13:06:34 +0200 Subject: [Live-devel] TS file with high VBR In-Reply-To: <4D2C1347.4050804@lemoine-fr.com> References: <4D2B0187.7030608@lemoine-fr.com> <4D2C1347.4050804@lemoine-fr.com> Message-ID: <4D2C39BA.8060705@lemoine-fr.com> Sorry.... my mistake: the commercial muxer is adding null packets to create a CBR transport stream...... it manages to keep the file not too big by maybe having a better H264 compression. Christophe On 01/11/2011 10:22 AM, Christophe Lemoine wrote: > Hi Ross, > > Thanks a lot for your answer: that would be great to have better > support for high VBR TS file. > I get your point regarding streaming of live encoder. Maybe the code > could be different depending on the stream source. > > While testing different muxers, I'm getting confused by some > results..... I use tsreport to get the Transport Stream bit rate. > - ffmpeg gives files with very high VBR. Basically, it justs add > the PCR based on the video frame DTS when VBR is requested. Here is an > example report. > .. PCR 17010342 Mean byterate 5114089 byterate 5113793 > .. PCR 19440250 Mean byterate 5114313 byterate 5115882 > .. PCR 21870158 Mean byterate 4739385 byterate 1740110 > .. PCR 24300066 Mean byterate 4265636 byterate 2088 > .. PCR 26730960 Mean byterate 3878453 byterate 8352 > > - TSMuxer gives similar results. > > - Some (commercial muxers), while still generating VBR TS file > (no null packets to make it CBR), have a CBR when looking at the PCR > time and number of packets between PCRs (time between packets remains > constant). I still trying to understand the details, but my guess is > that the number of packets between 2 I frames should not vary by a > lot. Then, it might be possible to play with the delay between the PCR > and the frames DTS to make the stream looks like CBR. The player > buffer will then have to cope with it. But, obviously, the algorithm > in the muxer must be quite complex to determine the proper PCRs, > without getting the difference between PCR and DTS drifting... > Example report (same source video file as with ffmpeg, result ts file > size very similar) > .. PCR 5013968 Mean byterate 1313100 byterate 1313100 > .. PCR 6015175 Mean byterate 1313099 byterate 1313099 > .. PCR 7016381 Mean byterate 1313100 byterate 1313100 > .. PCR 8017587 Mean byterate 1313100 byterate 1313100 > .. PCR 9018794 Mean byterate 1313099 byterate 1313099 > .. PCR 10020000 Mean byterate 1313100 byterate 1313100 > .. PCR 11021206 Mean byterate 1313100 byterate 1313100 > .. PCR 12022413 Mean byterate 1313099 byterate 1313099 > > > BR > Christophe > > On 01/10/2011 04:44 PM, Ross Finlayson wrote: >>> Maybe I'm wrong, but, by reading the code of the media server, it >>> looks likes it relies on an average BR to determine when to send the >>> packets (based on past packets). >> >> Yes. (This is done in "MPEG2TransportStreamFramer".) >> >> >>> The PCR is used to compute this average, but not to determine when >>> to actually send the packets. (I might be totally wrong here as I >>> must admit that the code is quite complex and I probably have missed >>> something.....). >>> Now, if I'm not totally wrong, would there be a way to either: >>> - Rely on PCR to determine when to send packets (something >>> like: get the next PCR, determine BR from first packet till this PCR >>> packet, send packets in a way where the packet containing the PCR is >>> sent on time). >> >> The "MPEG2TransportStreamFramer" code is intended to work when >> streaming arbitrary Transport Stream data - including Transport >> Stream data that might come 'live' from an encoder. It therefore has >> no knowledge of 'the next PCR' (because it doesn't look ahead in >> time). However... >> >> >>> - Or: use the index file to store current frame BR (so use >>> the actual BR of a frame instead of an average based on past frames) >> >> Yes, for Transport Stream files for which we have pre-computed an >> index file, we do - in principle - have enough 'future' information >> (using PCR values) from which we could compute a more accurate >> 'duration' for each outgoing Transport Stream packet. In the past I >> had considered modifying "MPEG2TransportStreamFramer" to use this >> information, but didn't (because such a solution would work only for >> Transport Stream files for which we have index files, whereas the >> existing code works for any Transport Stream data). >> >> However, because - as you noted - excessively VBR streams are more >> likely to be a problem with H.264 Transport Streams, I think I'll >> take another look at this, to see if we can use the index file - when >> present - to generate more accurate Transport Stream 'durations'. > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From nishizawa23 at gmail.com Thu Jan 13 00:30:33 2011 From: nishizawa23 at gmail.com (doherty pete) Date: Thu, 13 Jan 2011 16:30:33 +0800 Subject: [Live-devel] help rtsp vlc Message-ID: i write rtsp server myself,and play with vlc: vlc -vvv rtsp://192.168.0.107:5554/TestSession and log is Sending request: OPTIONS rtsp://192.168.0.107:5554/TestSession RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 1 Server:Vstream Streaming Server V1.0 Public:DESCRIBE,SETUP,TEARDOWN,PLAY Sending request: DESCRIBE rtsp://192.168.0.107:5554/TestSession RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Server: RTSP Service Content-Base: rtsp://192.168.0.107:5554/TestSession Content-Type: application/sdp Content-Length: 363 Need to read 363 extra bytes Read 363 extra bytes: v=0 o=- 2231677159 2231677159 IN IP4 192.168.0.107 s=TestSession c=IN IP4 192.168.0.100 t=0 0 a=control:* m=video 0 RTP/AVP 96 b=AS:0 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=000064;sprop-parameter-sets=AAABZ2QADKw07BQfsBEAAAMAAAQAAAwAejxQpOA==,AAABao6csiw==; packetization-mode=1; a=cliprect:0,0,240,320 a=mpeg4-esid:201 a=control:trackID=1 [0x90b3e40] live555 demux debug: RTP subsession 'video/H264' Sending request: SETUP rtsp://192.168.0.107:5554/TestSession/trackID=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=48228-48229 User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Received SETUP response: RTSP/1.0 200 OK CSeq: 3 Session: 2231770760 Transport: RTP/AVP;unicast;source=192.168.0.107;server_port=8000-8001;client_port=48228-48229;ssrc:2231769018 [0x8e6a5a0] main input debug: selecting program id=0 [0x90b3e40] live555 demux debug: setup start: 0.000000 stop:0.000000 Sending request: PLAY rtsp://192.168.0.107:5554/TestSession RTSP/1.0 CSeq: 4 Session: 2231770760 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Received PLAY response: RTSP/1.0 200 OK CSeq: 4 Session:2231770760 RTP-Info:url=rtsp://192.168.0.107:5554/TestSession/trackID=1 [0x90b3e40] live555 demux debug: play start: 0.000000 stop:0.000000 [0x90b3e40] main demux debug: using access_demux module "live555" [0x90b3e40] main demux debug: TIMER module_need() : 15.626 ms - Total 15.626 ms / 1 intvls (Avg 15.626 ms) [0x90b4b08] main decoder debug: looking for decoder module: 31 candidates [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x90b4b08] avcodec decoder debug: libavcodec initialized (interface 0x341401) [0x90b4b08] avcodec decoder debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) started [0x90b4b08] main decoder debug: using decoder module "avcodec" [0x90b4b08] main decoder debug: TIMER module_need() : 276.835 ms - Total 276.835 ms / 1 intvls (Avg 276.835 ms) [0x90cd650] main packetizer debug: looking for packetizer module: 21 candidates [0x90cd650] packetizer_h264 packetizer debug: found NAL_PPS (pps_id=0 sps_id=0) [0x90cd650] packetizer_h264 packetizer debug: found NAL_SPS (sps_id=0) [0x90cd650] main packetizer debug: using packetizer module "packetizer_h264" [0x90cd650] main packetizer debug: TIMER module_need() : 8.889 ms - Total 8.889 ms / 1 intvls (Avg 8.889 ms) [0x90b4b08] main decoder debug: thread (decoder) created at priority 0 (input/decoder.c:315) [0x90b4b08] main decoder debug: thread started [0x8e6a5a0] main input debug: `rtsp://192.168.0.107:5554/TestSession' successfully opened [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x90b3e40] live555 demux warning: no data received in 10s. Switching to TCP [0x90b4b08] avcodec decoder debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) stopped opped [0x90b4b08] main decoder debug: removing module "avcodec" [0x90b4b08] main decoder debug: killing decoder fourcc `h264', 0 PES in FIFO [0x90cd650] main packetizer debug: removing module "packetizer_h264" [0x8e6a5a0] main input debug: Program doesn't contain anymore ES Sending request: TEARDOWN rt sp://192.168.0.107:5554/TestSession RTSP/1.0 CSeq: 5 Session: 2231770760 User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) [0x90b3e40] live555 demux warning: no data received in 10s. Switching to TCP i got the client port 48228-48229,48228 is the rtp port and 48299 is the rtcp port, right? i have send the rtp data to port 48288,but why vlc said no data received? is the RTP not cerrect? -- pete_doherty -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jan 13 00:51:36 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 13 Jan 2011 00:51:36 -0800 Subject: [Live-devel] help rtsp vlc In-Reply-To: References: Message-ID: >i write rtsp server myself Are you using our RTSP server implementation (and if not, why not? :-) >[0x90b3e40] live555 demux warning: no data received in 10s. Switching to TCP > >i got the client port 48228-48229,48228 is the rtp port and 48299 is >the rtcp port, right? >i have send the rtp data to port 48288,but why vlc said no data received? >is the RTP not cerrect? Possibly (especially if you didn't use our RTSP server implementation :-). Another possibility is that you have a firewall somewhere between your server and your client that is blocking UDP packets. In any case, I suggest that you start by using "openRTSP" as your client, instead of VLC. It may help you better understand what is going wrong. If you have a firewall that is blocking UDP packets, you should run "openRTSP" with the "-t" flag, so that it tunnels the incoming RTP and RTCP packets over the RTSP (TCP) connection. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Randy.Roberts at flir.com Thu Jan 13 08:53:38 2011 From: Randy.Roberts at flir.com (Roberts, Randy) Date: Thu, 13 Jan 2011 08:53:38 -0800 Subject: [Live-devel] help rtsp vlc In-Reply-To: References: Message-ID: <9FF07362A2BFD446B95FC028D0B7B4D006B4D069@coral.sba.flir.net> Double check the SPS and PPS ? If they are wrong, you won't see video... From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of doherty pete Sent: Thursday, January 13, 2011 12:31 AM To: live-devel at ns.live555.com Subject: [Live-devel] help rtsp vlc i write rtsp server myself,and play with vlc: vlc -vvv rtsp://192.168.0.107:5554/TestSession and log is Sending request: OPTIONS rtsp://192.168.0.107:5554/TestSession RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 1 Server:Vstream Streaming Server V1.0 Public:DESCRIBE,SETUP,TEARDOWN,PLAY Sending request: DESCRIBE rtsp://192.168.0.107:5554/TestSession RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Server: RTSP Service Content-Base: rtsp://192.168.0.107:5554/TestSession Content-Type: application/sdp Content-Length: 363 Need to read 363 extra bytes Read 363 extra bytes: v=0 o=- 2231677159 2231677159 IN IP4 192.168.0.107 s=TestSession c=IN IP4 192.168.0.100 t=0 0 a=control:* m=video 0 RTP/AVP 96 b=AS:0 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=000064;sprop-parameter-sets=AAABZ2QADKw07BQfsBEAAAMAAAQ AAAwAejxQpOA==,AAABao6csiw==; packetization-mode=1; a=cliprect:0,0,240,320 a=mpeg4-esid:201 a=control:trackID=1 [0x90b3e40] live555 demux debug: RTP subsession 'video/H264' Sending request: SETUP rtsp://192.168.0.107:5554/TestSession/trackID=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=48228-48229 User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Received SETUP response: RTSP/1.0 200 OK CSeq: 3 Session: 2231770760 Transport: RTP/AVP;unicast;source=192.168.0.107;server_port=8000-8001;client_port=4 8228-48229;ssrc:2231769018 [0x8e6a5a0] main input debug: selecting program id=0 [0x90b3e40] live555 demux debug: setup start: 0.000000 stop:0.000000 Sending request: PLAY rtsp://192.168.0.107:5554/TestSession RTSP/1.0 CSeq: 4 Session: 2231770760 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) Received PLAY response: RTSP/1.0 200 OK CSeq: 4 Session:2231770760 RTP-Info:url=rtsp://192.168.0.107:5554/TestSession/trackID=1 [0x90b3e40] live555 demux debug: play start: 0.000000 stop:0.000000 [0x90b3e40] main demux debug: using access_demux module "live555" [0x90b3e40] main demux debug: TIMER module_need() : 15.626 ms - Total 15.626 ms / 1 intvls (Avg 15.626 ms) [0x90b4b08] main decoder debug: looking for decoder module: 31 candidates [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x90b4b08] avcodec decoder debug: libavcodec initialized (interface 0x341401) [0x90b4b08] avcodec decoder debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) started [0x90b4b08] main decoder debug: using decoder module "avcodec" [0x90b4b08] main decoder debug: TIMER module_need() : 276.835 ms - Total 276.835 ms / 1 intvls (Avg 276.835 ms) [0x90cd650] main packetizer debug: looking for packetizer module: 21 candidates [0x90cd650] packetizer_h264 packetizer debug: found NAL_PPS (pps_id=0 sps_id=0) [0x90cd650] packetizer_h264 packetizer debug: found NAL_SPS (sps_id=0) [0x90cd650] main packetizer debug: using packetizer module "packetizer_h264" [0x90cd650] main packetizer debug: TIMER module_need() : 8.889 ms - Total 8.889 ms / 1 intvls (Avg 8.889 ms) [0x90b4b08] main decoder debug: thread (decoder) created at priority 0 (input/decoder.c:315) [0x90b4b08] main decoder debug: thread started [0x8e6a5a0] main input debug: `rtsp://192.168.0.107:5554/TestSession ' successfully opened [0x8e64278] qt4 interface debug: Updating the geometry [0x8e64278] qt4 interface debug: Updating the geometry [0x90b3e40] live555 demux warning: no data received in 10s. Switching to TCP [0x90b4b08] avcodec decoder debug: ffmpeg codec (H264 - MPEG-4 AVC (part 10)) stopped opped [0x90b4b08] main decoder debug: removing module "avcodec" [0x90b4b08] main decoder debug: killing decoder fourcc `h264', 0 PES in FIFO [0x90cd650] main packetizer debug: removing module "packetizer_h264" [0x8e6a5a0] main input debug: Program doesn't contain anymore ES Sending request: TEARDOWN rt sp://192.168.0.107:5554/TestSession RTSP/1.0 CSeq: 5 Session: 2231770760 User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10) [0x90b3e40] live555 demux warning: no data received in 10s. Switching to TCP i got the client port 48228-48229,48228 is the rtp port and 48299 is the rtcp port, right? i have send the rtp data to port 48288,but why vlc said no data received? is the RTP not cerrect? -- pete_doherty -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffin at ermes-cctv.com Fri Jan 14 05:48:46 2011 From: raffin at ermes-cctv.com (Mario Raffin) Date: Fri, 14 Jan 2011 14:48:46 +0100 Subject: [Live-devel] testH264Videostreamer to VLC crashes the VLC player Message-ID: <4D30543D.3000102@ermes-cctv.com> Hi All, I am using testH264Videostreamer to stream H.264. I use VLC to capture and decode but it does not work, or it works only sometimes while the most of times it crashes the player. Quicktime does not show anything. When I open the file directly with VLC the playback is fine. I encode the file in an embedded system putting SPS and PPS each 25 frames. Moreover when I send the encoded packet via UDP (not RTP) to an embedded decoder this decodes the stream without any problem so I am sure about the integrity of the data. Some idea would be very appreciated. Maybe the problem is in the VLC player. Can someone suggest a way to test the validity of the stream? thank you, mario -------------- next part -------------- A non-text attachment was scrubbed... Name: raffin.vcf Type: text/x-vcard Size: 266 bytes Desc: not available URL: From finlayson at live555.com Fri Jan 14 09:18:16 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 14 Jan 2011 09:18:16 -0800 Subject: [Live-devel] testH264Videostreamer to VLC crashes the VLC player In-Reply-To: <4D30543D.3000102@ermes-cctv.com> References: <4D30543D.3000102@ermes-cctv.com> Message-ID: > I am using testH264Videostreamer to stream H.264. I use VLC to >capture and decode but it does not work, or it works only sometimes >while the most of times it crashes the player. Quicktime does not >show anything. That's likely a problem with QuickTime Player. It apparently can play only a limited subset of H.264. >Some idea would be very appreciated. Maybe the problem is in the VLC player. Yes, perhaps. (Though not necessarily.) > Can someone suggest a way to test the validity of the stream? Please put an example ".264" file online, and send us the URL, so I can download and test it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From zdenek at next-stream.com Fri Jan 14 13:54:00 2011 From: zdenek at next-stream.com (Zdenek Bouresh) Date: Fri, 14 Jan 2011 23:54:00 +0200 Subject: [Live-devel] OnDemandServerMediaSubsession and FramedSource subclassing In-Reply-To: <8CD7A9204779214D9FDC255DE48B95211DE2CCC2@EXPMBX105-1.exch.logostech.net> References: <8CD7A9204779214D9FDC255DE48B95211DE2C9D9@EXPMBX105-1.exch.logostech.net> <8CD7A9204779214D9FDC255DE48B95211DE2CCC2@EXPMBX105-1.exch.logostech.net> Message-ID: Hello, I have done what you are describing. Extended on demand server to stream on demand from unicast or multicast to unicast or multicast clients any UDP or RTP TS stream. Its rather simple once you get the hang of it. Stared at it for a month then came up with working code in 1-2 days. Contact me, perhaps we can exchange knowledge. Zed On Fri, Dec 10, 2010 at 3:23 PM, Wiser, Tyson wrote: > Ross, > > Thanks for the help. After doing a quick test it appears that making the > suggested modifications to my subclass of "OnDemandServerMediaSubsession" > does work as expected. I appreciate your great work on this library. > > Tyson > > -----Original Message----- > From: live-devel-bounces at ns.live555.com [mailto: > live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson > Sent: Friday, December 10, 2010 3:10 AM > To: LIVE555 Streaming Media - development & use > Subject: Re: [Live-devel] OnDemandServerMediaSubsession and FramedSource > subclassing > > >Basically, I need a server that streams data on demand from a live > >source to a client. The stream needs to be able to be sent using > >either unicast or multicast to an address and port combination > >dictated by the client in the SETUP message. > > It's usually the server, not the client, that decides whether or not > the stream is unicast or multicast. The usual way for a server to > support both kinds of stream is to have both a > "OnDemandServerMediaSubsession" and a "PassiveServerMediaSubsession" > - with different names, of course. The client could use the stream > name to choose between unicast and multicast. > > In principle this would work, but in your case you'd have a problem: > The 'reuseFirstSource' mechanism has been implemented only for > "OnDemandServerMediaSubsession"s; not for > "PassiveServerMediaSubsession". Furthernore, there's no way for > those two separate classes to share the same input source. So, to > have both the unicast and multicast streams reading from the same > source, you'd need to modify the code. > > A simpler alternative is to do what you seem to be doing: Allow the > client to specify the destination address (i.e., unicast or > multicast), using a "destination=" parameter in the RTSP "SETUP" > message. To support this, you'll need to define > RTSP_ALLOW_CLIENT_DESTINATION_SETTING > before you compile "RTSPServer.cpp"; I presume that you've done this. > > > >First, if I wanted to subclass OnDemandServerMediaSubsession to > >handle multicast as well as unicast, is it sufficient to change > >getStreamParameters() so that it doesn't automatically set > >isMulticast to False, but instead sets it based on the destination > >address? > > I haven't tested this, but yes, I believe so. It should be easy: > Your subclass could redefine the "getStreamParameters()" virtual > function to do this: > > void mySubclass::getStreamParameters( ...parameters... ) { > OnDemandServerMediaSubsession::getStreamParameters( ...parameters... > ); > if (IsMulticastAddress(destinationAddress) isMulticast = True; > } > > > >The problem, when using OnDemandServerMediaSubsession, is that I > >don't know how to get a reference to my source object. That object, > >as the name of the class implies, is created on demand and I have > >not found any functions that return to me a FramedSource* or a > >RTPSink*. I have made sure that I set reuseFirstSource to True when > >creating the OnDemandServerMediaSubsession subclass, which I > >understand to mean that there will only ever be one source. Is > >there a way to get a reference to that source? > > Yes, when your "OnDemandServerMediaSubsession " subclass creates a > source object - in your implementation of the > "createNewStreamSource()" virtual function - you can store a pointer > to the source object (e.g., in a global variable). (Because > "reuseFirstSource" is true, "createNewStreamSource()" should be > called just once, so there will be only one such source object.) > -- > > 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 > -- Zdenek Bouresh NextStream LTD. The information contained within this email transmission and any attachments is confidential and intended solely for the attention and use of the named individual addressee(s) or entity. It may not be legally revealed or be disclosed to any other person or third party without the express authority (prior written approval) of NextStream LTD and/or the original recipient, or the intended recipients, or both. If you are not the intended recipient, you must not disclose, copy, distribute, print, rely on or retain this message or any part of it. The information contained within is strictly prohibited. If you have received this email in error please notify the sender by reply, and delete this message from your email system(s). Any hard copies must also be destroyed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi87 at fibertel.com.ar Sat Jan 15 11:31:52 2011 From: edi87 at fibertel.com.ar (Jonathan Granade) Date: Sat, 15 Jan 2011 16:31:52 -0300 Subject: [Live-devel] Continuos Stream, finally done In-Reply-To: References: <8CD7A9204779214D9FDC255DE48B95211DE2C9D9@EXPMBX105-1.exch.logostech.net> <8CD7A9204779214D9FDC255DE48B95211DE2CCC2@EXPMBX105-1.exch.logostech.net> Message-ID: <4D31F628.8040506@fibertel.com.ar> Ross and dev list, I finally done the continuos stream patch. I needed to do some subclasses, but it works exactly as expected, anyway I'm not sure if it's "correctly" done. I would really appreciate anyone who check it and guide me if I made something weird. I will be sending a tar.gz when I got some time in my house. Thanks for the help! Jonathan From smerchan at gruposamtel.com Sun Jan 16 11:47:05 2011 From: smerchan at gruposamtel.com (=?iso-8859-1?Q?Santiago_Merch=E1n?=) Date: Sun, 16 Jan 2011 20:47:05 +0100 Subject: [Live-devel] Problem using MPEG2TransportStreamFramer Message-ID: <8365C632-E9D1-4BB1-9472-E4015DC2FA8E@gruposamtel.com> Good morning, my name is Santiago and I am an Android developer. I am trying to write a RTSP server for Android to stream TS files to a SagemCom STB. The RTSP server is working very well, but I have some problems playing some files in the STB. I?m reading 7 TS packets (1316 bytes) from the file, sending them to the STB, sleeping some time and then back to read. I have ported class MPEG2TransportStreamFramer to Java to be able to estimate by the TS PCRs how much time my sending thread has to sleep to give the STB time to play what I last sent. Some TS files containing MPEG2 video Streams and MPEG1 audio streams are played quite fast and files containing H264 video streams and MPEG1 audio streams are played very slow. Also the image gets frozen periodically (I don?t know if this is because the WiFi latency) and I can?t play TS files containing MP3 streams, while I know for sure that the STB can play them. Anyone can help me with this please? Thank you very much. Kind Regards Santiago Fdo: Santiago Merch?n Grupo Samtel Telf: 91 426 48 75 Fax: 91 431 05 73 La informaci?n incluida en el presente correo electr?nico es CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jan 16 12:46:37 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Jan 2011 12:46:37 -0800 Subject: [Live-devel] Problem using MPEG2TransportStreamFramer In-Reply-To: <8365C632-E9D1-4BB1-9472-E4015DC2FA8E@gruposamtel.com> References: <8365C632-E9D1-4BB1-9472-E4015DC2FA8E@gruposamtel.com> Message-ID: >I am trying to write a RTSP server for Android >to stream TS files to a SagemCom STB. The RTSP >server is working very well, but I have some >problems playing some files in the STB. > >I?m reading 7 TS packets (1316 bytes) from the >file, sending them to the STB, sleeping some >time and then back to read. I have ported class >MPEG2TransportStreamFramer to Java I'm not sure what it means to 'port' C++ code to Java. (Does 'Android' not support C++ applications at all?) Perhaps you meant to say "I have rewritten class MPEG2TransportStreamFramer in Java"? > to be able to estimate by the TS PCRs how much >time my sending thread has to sleep to give the >STB time to play what I last sent. Some TS files >containing MPEG2 video Streams and MPEG1 audio >streams are played quite fast and files >containing H264 video streams and MPEG1 audio >streams are played very slow. Also the image >gets frozen periodically (I don?t know if this >is because the WiFi latency) and I can?t play TS >files containing MP3 streams, while I know for >sure that the STB can play them. Anyone can help >me with this please? Probably not, unless you are using our software 'as is' - i.e., without modification or rewriting. This mailing list is for discussion of the "LIVE555 Streaming Media" software, which is written in C++. If you want to use this code as a model for your own code that uses another programming language, then that's fine. However, we won't be able to help you at all with this. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jingke2000 at gmail.com Thu Jan 13 15:12:21 2011 From: jingke2000 at gmail.com (Ke Yu) Date: Thu, 13 Jan 2011 18:12:21 -0500 Subject: [Live-devel] live555 streaming TS over RTP/RTSP question Message-ID: Hi All, I've built a TS over RTSP streaming solution based on "MPEG2TransportFileServerMediaSubsession". The a/v codec types in my TS are MP4a and MP4v respectively. It plays back nicely in VLC player. However, my client (an Android 2.2 device with OpenCore based media player) doesn't support the RTP media type 33. During RTSP handshaking stage, the client never issued the "SETUP" RTSP command to the server. It closed the client cocket once the SDP was received. Now, I've found out this Android client likes the RTP/RTSP data streamed by VLC (command line: "vlc my.ts :sout=#rtp{sdp=rtsp://xxx.xxx.xxx.xxx:xxxx/myts.sdp}"). After inspecting the network traffic, I realized the VLC demuxed my TS into MP4V-ES and MP4a, then used dynamic RTP media types for the a/v streams. My question is how I can do the same thing with Live555 libraries? Thanks in advance! From kidjan at gmail.com Fri Jan 14 10:45:26 2011 From: kidjan at gmail.com (Jeremy Noring) Date: Fri, 14 Jan 2011 10:45:26 -0800 Subject: [Live-devel] Symbian Client having issues with Live555 based server Message-ID: We run an RTSP server based around Live555 on our embedded device; normally, it's configured with two sessions: LowResolutionVideo and HighResolutionVideo, both of which are H264/AAC. This works well for the most part--it's broadly compatible with VLC, Quicktime and our own openRTSP based client. However, I got this report from one of our users: -------------------------------------------------------------------------------- I am able to stream to my Nokia N8 phone just by creating "txt file" named live.ram and it has content like: rtsp://192.168.2.2/LowResolutionVideo Then placing that file to phone and click it from file manager. It will stream ~30s nicely and once buffer should happen difficulties started. This is something i have figured out from network packet capture: These ping-pong (keep-alive) packets or heart beats are formatted somewhat like this: SET_PARAMETER * RTSP/1.0 CSeq: 6 Ping: Pong Where ?*? denotes the url, from the packet capture dump it seems camera RTSP -server is not ignoring that url when Nokia phone has a ?ping? parameter in the header. And hence it sends 404 url not found and resets connection. In such cases server should just respond by OK 200 or 451 RTSP/1.0 451 Parameter Not Understood CSeq: 6 Date: Wed, 11 Dec 2002 12:50:56 GMT And should not reset or finish the session. -------------------------------------------------------------------------------- I'm not familiar with these ping-pong packets (are these a valid part of the RTSP protocol?) or streaming to symbian devices; does anyone have any idea what the problem may be? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jan 16 14:42:49 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Jan 2011 14:42:49 -0800 Subject: [Live-devel] live555 streaming TS over RTP/RTSP question In-Reply-To: References: Message-ID: >I've built a TS over RTSP streaming solution based on >"MPEG2TransportFileServerMediaSubsession". The a/v codec types in my >TS are MP4a and MP4v respectively. It plays back nicely in VLC player. >However, my client (an Android 2.2 device with OpenCore based media >player) doesn't support the RTP media type 33. A standards-compliant RTP client should support the static payload types defined in RFC 3551, section 6 (including the static payload type 33, for MPEG Transport Stream "MP2T" data). It should not be expecting that all streams are described using dynamic payload types only. Therefore, please contact the authors of your client's software, asking them to fix their code so that it understands static RTP payload types (for the media types that it supports). >After >inspecting the network traffic, I realized the VLC demuxed my TS into >MP4V-ES and MP4a, then used dynamic RTP media types for the a/v >streams. My question is how I can do the same thing with Live555 >libraries? Yes, you could do this by changing the implementation of "MPEG2TransportFileServerMediaSubsession::createNewRTPSink()" ("liveMedia/MPEG2TransportFileServerMediaSubsession.cpp", line 220) to use the "rtpPayloadTypeIfDynamic" parameter, and to pass this - instead of 33 - to the call to "SimpleRTPSink::createNew()". Note, however, that we will *not* be making this change in any future versions of our code. The 'right' solution is to fix your client to understand static payload types. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jan 16 15:31:04 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 16 Jan 2011 15:31:04 -0800 Subject: [Live-devel] Symbian Client having issues with Live555 based server In-Reply-To: References: Message-ID: >We run an RTSP server based around Live555 on our embedded device Do "we" not have our own domain name? :-) >This is something i have figured out from network packet capture: > >These ping-pong (keep-alive) packets or heart beats are formatted >somewhat like this: > >SET_PARAMETER * RTSP/1.0 > >CSeq: 6 > >Ping: Pong > >Where "*" denotes the url, from the packet capture dump it seems >camera RTSP -server is not ignoring that url when Nokia phone has a >'ping' parameter in the header. > >And hence it sends 404 url not found and resets connection. Thanks for the report. > In such cases server should just respond by OK 200 or 451 > >RTSP/1.0 451 Parameter Not Understood Hmmm. The RTSP 1.0 spec lists "451" as being an error code only for "SETUP", although the RTSP 2.0 spec lists it as being an error code only for "SET_PARAMETER". (The latter is actually a mistake; it should also be an error code for "GET_PARAMETER", at least according to the remainder of the spec.) To be on the safe side, I should probably change the code to respond to "SET_PARAMETER" with "OK 200", but not actually do anything. I'll make this change in the next release of the software. (If you wanted to actually *handle* the "SET_PARAMETER" command - i.e., not just have it be a no-op - then you would do this by subclassing "RTSPServer" and "RTSPServer::RTSPClientSession", and reimplementing the virtual function "RTSPServer::RTSPClientSession ::handleCmd_SET_PARAMETER()" in your subclass.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jemicheng at gmail.com Sun Jan 16 20:04:45 2011 From: jemicheng at gmail.com (Cheng James) Date: Mon, 17 Jan 2011 12:04:45 +0800 Subject: [Live-devel] wis-streamer can't play raw 16khz PCM sample Message-ID: Hi, I am doing a little experiment. I record a single channel 16khz raw PCM sample for 3 seconds as a file and then I modify wis-streamer codes for playing this raw sample as audio source. Here is the code which I have modified. void copypcm(char *to) { int fd; printf("copypcm\n"); char buf[96000]; fd = open("/tmp/wav", O_RDWR); if (fd < 0) return ; memset(buf,0,96000); read(fd, buf, sizeof(buf)); memcpy(to,buf,96000); close(fd); printf("copydone\n"); } void WISAudioOpenFileSource::readFromFile() { // Read available audio data: int timeinc; //int ret = read(fInput.fOurAudioFileNo, fTo, fMaxSize); //my modification from here copypcm(fTo); fFrameSize = (unsigned)96000; gettimeofday(&fPresentationTime, NULL); /* PR#2665 fix from Robin * Assuming audio format = AFMT_S16_LE * Get the current time * Substract the time increment of the audio oss buffer, which is equal to * buffer_size / channel_number / sample_rate / sample_size ==> 400+ millisec */ timeinc = fFrameSize * 1000 / audioNumChannels / (audioSamplingFrequency/1000) / 2; while (fPresentationTime.tv_usec < timeinc) { fPresentationTime.tv_sec -= 1; timeinc -= 1000000; } fPresentationTime.tv_usec -= timeinc; } The audio can't be played by VLC and VLC complains about PTS is out of range. Is there any thing wrong with my modification? By the way, I saw VLC drops a lot of audio buffers. Here is the RTSP negotiation detail of my experiment. 192.168.1.168 is the wis-streamer IP. DESCRIBE rtsp://192.168.1.168:7777/audio RTSP/1.0 CSeq: 3 User-Agent: LibVLC/1.1.5 (LIVE555 Streaming Media v2010.09.25) Accept: application/sdp RTSP/1.0 200 OK CSeq: 3 Date: Sat, Jan 01 2000 02:17:21 GMT Content-Base: rtsp://192.168.1.168:7777/audio/ Content-Type: application/sdp Content-Length: 341 v=0 o=- 946692776958225 1 IN IP4 192.168.1.30 s=PCM raw source experiment i=audio t=0 0 a=tool:LIVE555 Streaming Media v2011.01.06 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:RTSP/RTP stream a=x-qt-text-inf:audio m=audio 0 RTP/AVP 96 c=IN IP4 0.0.0.0 b=AS:128 a=rtpmap:96 L16/16000 a=control:track1 SETUP rtsp://192.168.1.168:7777/audio/track1 RTSP/1.0 CSeq: 4 User-Agent: LibVLC/1.1.5 (LIVE555 Streaming Media v2010.09.25) Transport: RTP/AVP;unicast;client_port=3650-3651 RTSP/1.0 200 OK CSeq: 4 Date: Sat, Jan 01 2000 02:17:21 GMT Transport: RTP/AVP;unicast;destination=192.168.1.99;source=192.168.1.168;client_port=3650-3651;server_port=6970-6971 Session: 04632C22 PLAY rtsp://192.168.1.168:7777/audio/ RTSP/1.0 CSeq: 5 User-Agent: LibVLC/1.1.5 (LIVE555 Streaming Media v2010.09.25) Session: 04632C22 Range: npt=0.000- RTSP/1.0 200 OK CSeq: 5 Date: Sat, Jan 01 2000 02:17:21 GMT Range: npt=0.000- Session: 04632C22 RTP-Info: url=rtsp:// 192.168.1.168:7777/audio/track1;seq=6548;rtptime=292484997 GET_PARAMETER rtsp://192.168.1.168:7777/audio/ RTSP/1.0 CSeq: 6 User-Agent: LibVLC/1.1.5 (LIVE555 Streaming Media v2010.09.25) Session: 04632C22 RTSP/1.0 200 OK CSeq: 6 Date: Sat, Jan 01 2000 02:17:21 GMT Session: 04632C22 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffin at ermes-cctv.com Mon Jan 17 01:06:05 2011 From: raffin at ermes-cctv.com (Mario Raffin) Date: Mon, 17 Jan 2011 10:06:05 +0100 Subject: [Live-devel] Contents of live-devel digest live-devel Digest, Vol 87, Issue 3, topic 3 In-Reply-To: References: Message-ID: <4D34067D.2070502@ermes-cctv.com> Thank you very much for the support. Regarding this: >> > Can someone suggest a way to test the validity of the stream? > Please put an example ".264" file online, and send us the URL, so I > can download and test it. the 5MB sequence can be downloaded here: https://storageuk11.transferbigfiles.com/files/7e481a21-566f-4584-84b5-4c4c48145c9c?rid=2MTttgc0mbrtXQ1k0Nxuqw%3d%3d as you probably know the files test.264 must be renamed test.h264 to be played on VLC and it plays fine. When I stream the file with testH264Video streamer, on the contrary, VLC con't decode it (not always sometimes it do it). Regards, Mario -- *Mario Raffin * Development Engineer Ermes Elettronica s.r.l. via Verri, 87/B 31010 Mareno di Piave (TV) Italy (Map ) Mail: raffin at ermes-cctv.com Web:http://www.ermes-cctv.com/ /Tel. +39 0438 308470/ /Fax. +39 0438 492340/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MARCHIO ERMES.jpg Type: image/jpeg Size: 6559 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: raffin.vcf Type: text/x-vcard Size: 266 bytes Desc: not available URL: From finlayson at live555.com Mon Jan 17 02:20:26 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Jan 2011 02:20:26 -0800 Subject: [Live-devel] testH264Videostreamer to VLC crashes the VLC player In-Reply-To: <4D34067D.2070502@ermes-cctv.com> References: <4D34067D.2070502@ermes-cctv.com> Message-ID: >the 5MB sequence can be downloaded here: >https://storageuk11.transferbigfiles.com/files/7e481a21-566f-4584-84b5-4c4c48145c9c?rid=2MTttgc0mbrtXQ1k0Nxuqw%3d%3d Thanks. >as you probably know the files test.264 must be renamed test.h264 to >be played on VLC and it plays fine. >When I stream the file with testH264Video streamer, on the contrary, >VLC con't decode it (not always sometimes it do it). I turned on the debugging code in "liveMedia/H264VideoStreamFramer.cpp" (by adding "#define DEBUG 1"), to see how it was interpreting the file. The problem, I think, arises from the fact that the SPS ("Sequence Parameter Set") NAL unit in your file is rather unusual (e.g. it includes a "scaling_list"). Our code is supposed to be able to parse this SPS NAL unit, but I think there might be a bug somewhere in our parser, because it ends up deducing that "time_scale" is 150, giving a frame rate of 75 fps, which - I think - is 3 times too high. Unfortunately it wasn't immediately obvious to me where there might be a bug in our H.264 SPS parsing code, so I'm going to have to ask you (and/or anyone else who might be familiar with the H.264 SPS syntax) to take a look at the code ("liveMedia/H264VideoStreamFramer.cpp"), and see if you can see a problem. FYI, the debugging output from parsing the SPS NAL unit is as follows: ---------- Parsed 116-byte NAL-unit (nal_ref_idc: 3, nal_unit_type: 7 ("Sequence parameter set")) profile_idc: 100 constraint_setN_flag: 0 level_idc: 40 seq_parameter_set_id: 0 chroma_format_idc: 1 seq_scaling_matrix_present_flag: 1 i: 0 seq_scaling_list_present_flag: 1 j: 0 nextScale: 8 delta_scale: 15 lastScale: 23 j: 1 nextScale: 23 delta_scale: 9 lastScale: 32 j: 2 nextScale: 32 delta_scale: 0 lastScale: 32 j: 3 nextScale: 32 delta_scale: 9 lastScale: 41 j: 4 nextScale: 41 delta_scale: 0 lastScale: 41 j: 5 nextScale: 41 delta_scale: 0 lastScale: 41 j: 6 nextScale: 41 delta_scale: 9 lastScale: 50 j: 7 nextScale: 50 delta_scale: 0 lastScale: 50 j: 8 nextScale: 50 delta_scale: 0 lastScale: 50 j: 9 nextScale: 50 delta_scale: 0 lastScale: 50 j: 10 nextScale: 50 delta_scale: 9 lastScale: 59 j: 11 nextScale: 59 delta_scale: 0 lastScale: 59 j: 12 nextScale: 59 delta_scale: 0 lastScale: 59 j: 13 nextScale: 59 delta_scale: 9 lastScale: 68 j: 14 nextScale: 68 delta_scale: 0 lastScale: 68 j: 15 nextScale: 68 delta_scale: 13 lastScale: 81 i: 1 seq_scaling_list_present_flag: 1 j: 0 nextScale: 8 delta_scale: 15 lastScale: 23 j: 1 nextScale: 23 delta_scale: 9 lastScale: 32 j: 2 nextScale: 32 delta_scale: 0 lastScale: 32 j: 3 nextScale: 32 delta_scale: 9 lastScale: 41 j: 4 nextScale: 41 delta_scale: 0 lastScale: 41 j: 5 nextScale: 41 delta_scale: 0 lastScale: 41 j: 6 nextScale: 41 delta_scale: 9 lastScale: 50 j: 7 nextScale: 50 delta_scale: 0 lastScale: 50 j: 8 nextScale: 50 delta_scale: 0 lastScale: 50 j: 9 nextScale: 50 delta_scale: 0 lastScale: 50 j: 10 nextScale: 50 delta_scale: 9 lastScale: 59 j: 11 nextScale: 59 delta_scale: 0 lastScale: 59 j: 12 nextScale: 59 delta_scale: 0 lastScale: 59 j: 13 nextScale: 59 delta_scale: 9 lastScale: 68 j: 14 nextScale: 68 delta_scale: 0 lastScale: 68 j: 15 nextScale: 68 delta_scale: 13 lastScale: 81 i: 2 seq_scaling_list_present_flag: 1 j: 0 nextScale: 8 delta_scale: 15 lastScale: 23 j: 1 nextScale: 23 delta_scale: 9 lastScale: 32 j: 2 nextScale: 32 delta_scale: 0 lastScale: 32 j: 3 nextScale: 32 delta_scale: 9 lastScale: 41 j: 4 nextScale: 41 delta_scale: 0 lastScale: 41 j: 5 nextScale: 41 delta_scale: 0 lastScale: 41 j: 6 nextScale: 41 delta_scale: 9 lastScale: 50 j: 7 nextScale: 50 delta_scale: 0 lastScale: 50 j: 8 nextScale: 50 delta_scale: 0 lastScale: 50 j: 9 nextScale: 50 delta_scale: 0 lastScale: 50 j: 10 nextScale: 50 delta_scale: 9 lastScale: 59 j: 11 nextScale: 59 delta_scale: 0 lastScale: 59 j: 12 nextScale: 59 delta_scale: 0 lastScale: 59 j: 13 nextScale: 59 delta_scale: 9 lastScale: 68 j: 14 nextScale: 68 delta_scale: 0 lastScale: 68 j: 15 nextScale: 68 delta_scale: 13 lastScale: 81 i: 3 seq_scaling_list_present_flag: 1 j: 0 nextScale: 8 delta_scale: 15 lastScale: 23 j: 1 nextScale: 23 delta_scale: 9 lastScale: 32 j: 2 nextScale: 32 delta_scale: 0 lastScale: 32 j: 3 nextScale: 32 delta_scale: 9 lastScale: 41 j: 4 nextScale: 41 delta_scale: 0 lastScale: 41 j: 5 nextScale: 41 delta_scale: 0 lastScale: 41 j: 6 nextScale: 41 delta_scale: 9 lastScale: 50 j: 7 nextScale: 50 delta_scale: 0 lastScale: 50 j: 8 nextScale: 50 delta_scale: 0 lastScale: 50 j: 9 nextScale: 50 delta_scale: 0 lastScale: 50 j: 10 nextScale: 50 delta_scale: 9 lastScale: 59 j: 11 nextScale: 59 delta_scale: 0 lastScale: 59 j: 12 nextScale: 59 delta_scale: 0 lastScale: 59 j: 13 nextScale: 59 delta_scale: 9 lastScale: 68 j: 14 nextScale: 68 delta_scale: 0 lastScale: 68 j: 15 nextScale: 68 delta_scale: 13 lastScale: 81 i: 4 seq_scaling_list_present_flag: 1 j: 0 nextScale: 8 delta_scale: 15 lastScale: 23 j: 1 nextScale: 23 delta_scale: 9 lastScale: 32 j: 2 nextScale: 32 delta_scale: 0 lastScale: 32 j: 3 nextScale: 32 delta_scale: 9 lastScale: 41 j: 4 nextScale: 41 delta_scale: 0 lastScale: 41 j: 5 nextScale: 41 delta_scale: 0 lastScale: 41 j: 6 nextScale: 41 delta_scale: 9 lastScale: 50 j: 7 nextScale: 50 delta_scale: 0 lastScale: 50 j: 8 nextScale: 50 delta_scale: 0 lastScale: 50 j: 9 nextScale: 50 delta_scale: 0 lastScale: 50 j: 10 nextScale: 50 delta_scale: 9 lastScale: 59 j: 11 nextScale: 59 delta_scale: 0 lastScale: 59 j: 12 nextScale: 59 delta_scale: 0 lastScale: 59 j: 13 nextScale: 59 delta_scale: 9 lastScale: 68 j: 14 nextScale: 68 delta_scale: 0 lastScale: 68 j: 15 nextScale: 68 delta_scale: 13 lastScale: 81 i: 5 seq_scaling_list_present_flag: 1 j: 0 nextScale: 8 delta_scale: 15 lastScale: 23 j: 1 nextScale: 23 delta_scale: 9 lastScale: 32 j: 2 nextScale: 32 delta_scale: 0 lastScale: 32 j: 3 nextScale: 32 delta_scale: 9 lastScale: 41 j: 4 nextScale: 41 delta_scale: 0 lastScale: 41 j: 5 nextScale: 41 delta_scale: 0 lastScale: 41 j: 6 nextScale: 41 delta_scale: 9 lastScale: 50 j: 7 nextScale: 50 delta_scale: 0 lastScale: 50 j: 8 nextScale: 50 delta_scale: 0 lastScale: 50 j: 9 nextScale: 50 delta_scale: 0 lastScale: 50 j: 10 nextScale: 50 delta_scale: 9 lastScale: 59 j: 11 nextScale: 59 delta_scale: 0 lastScale: 59 j: 12 nextScale: 59 delta_scale: 0 lastScale: 59 j: 13 nextScale: 59 delta_scale: 9 lastScale: 68 j: 14 nextScale: 68 delta_scale: 0 lastScale: 68 j: 15 nextScale: 68 delta_scale: 13 lastScale: 81 i: 6 seq_scaling_list_present_flag: 1 j: 0 nextScale: 8 delta_scale: 15 lastScale: 23 j: 1 nextScale: 23 delta_scale: 3 lastScale: 26 j: 2 nextScale: 26 delta_scale: 0 lastScale: 26 j: 3 nextScale: 26 delta_scale: 3 lastScale: 29 j: 4 nextScale: 29 delta_scale: 4 lastScale: 33 j: 5 nextScale: 33 delta_scale: 3 lastScale: 36 j: 6 nextScale: 36 delta_scale: 3 lastScale: 39 j: 7 nextScale: 39 delta_scale: 0 lastScale: 39 j: 8 nextScale: 39 delta_scale: 0 lastScale: 39 j: 9 nextScale: 39 delta_scale: 0 lastScale: 39 j: 10 nextScale: 39 delta_scale: 3 lastScale: 42 j: 11 nextScale: 42 delta_scale: 0 lastScale: 42 j: 12 nextScale: 42 delta_scale: 0 lastScale: 42 j: 13 nextScale: 42 delta_scale: 0 lastScale: 42 j: 14 nextScale: 42 delta_scale: 0 lastScale: 42 j: 15 nextScale: 42 delta_scale: 3 lastScale: 45 j: 16 nextScale: 45 delta_scale: 0 lastScale: 45 j: 17 nextScale: 45 delta_scale: 0 lastScale: 45 j: 18 nextScale: 45 delta_scale: 0 lastScale: 45 j: 19 nextScale: 45 delta_scale: 0 lastScale: 45 j: 20 nextScale: 45 delta_scale: 0 lastScale: 45 j: 21 nextScale: 45 delta_scale: 3 lastScale: 48 j: 22 nextScale: 48 delta_scale: 0 lastScale: 48 j: 23 nextScale: 48 delta_scale: 0 lastScale: 48 j: 24 nextScale: 48 delta_scale: 0 lastScale: 48 j: 25 nextScale: 48 delta_scale: 0 lastScale: 48 j: 26 nextScale: 48 delta_scale: 0 lastScale: 48 j: 27 nextScale: 48 delta_scale: 0 lastScale: 48 j: 28 nextScale: 48 delta_scale: 3 lastScale: 51 j: 29 nextScale: 51 delta_scale: 0 lastScale: 51 j: 30 nextScale: 51 delta_scale: 0 lastScale: 51 j: 31 nextScale: 51 delta_scale: 0 lastScale: 51 j: 32 nextScale: 51 delta_scale: 0 lastScale: 51 j: 33 nextScale: 51 delta_scale: 0 lastScale: 51 j: 34 nextScale: 51 delta_scale: 0 lastScale: 51 j: 35 nextScale: 51 delta_scale: 0 lastScale: 51 j: 36 nextScale: 51 delta_scale: 3 lastScale: 54 j: 37 nextScale: 54 delta_scale: 0 lastScale: 54 j: 38 nextScale: 54 delta_scale: 0 lastScale: 54 j: 39 nextScale: 54 delta_scale: 0 lastScale: 54 j: 40 nextScale: 54 delta_scale: 0 lastScale: 54 j: 41 nextScale: 54 delta_scale: 0 lastScale: 54 j: 42 nextScale: 54 delta_scale: 0 lastScale: 54 j: 43 nextScale: 54 delta_scale: 3 lastScale: 57 j: 44 nextScale: 57 delta_scale: 0 lastScale: 57 j: 45 nextScale: 57 delta_scale: 0 lastScale: 57 j: 46 nextScale: 57 delta_scale: 0 lastScale: 57 j: 47 nextScale: 57 delta_scale: 0 lastScale: 57 j: 48 nextScale: 57 delta_scale: 0 lastScale: 57 j: 49 nextScale: 57 delta_scale: 3 lastScale: 60 j: 50 nextScale: 60 delta_scale: 0 lastScale: 60 j: 51 nextScale: 60 delta_scale: 0 lastScale: 60 j: 52 nextScale: 60 delta_scale: 0 lastScale: 60 j: 53 nextScale: 60 delta_scale: 0 lastScale: 60 j: 54 nextScale: 60 delta_scale: 5 lastScale: 65 j: 55 nextScale: 65 delta_scale: 0 lastScale: 65 j: 56 nextScale: 65 delta_scale: 0 lastScale: 65 j: 57 nextScale: 65 delta_scale: 0 lastScale: 65 j: 58 nextScale: 65 delta_scale: 5 lastScale: 70 j: 59 nextScale: 70 delta_scale: 0 lastScale: 70 j: 60 nextScale: 70 delta_scale: 0 lastScale: 70 j: 61 nextScale: 70 delta_scale: 5 lastScale: 75 j: 62 nextScale: 75 delta_scale: 0 lastScale: 75 j: 63 nextScale: 75 delta_scale: 5 lastScale: 80 i: 7 seq_scaling_list_present_flag: 1 j: 0 nextScale: 8 delta_scale: 15 lastScale: 23 j: 1 nextScale: 23 delta_scale: 3 lastScale: 26 j: 2 nextScale: 26 delta_scale: 0 lastScale: 26 j: 3 nextScale: 26 delta_scale: 3 lastScale: 29 j: 4 nextScale: 29 delta_scale: 4 lastScale: 33 j: 5 nextScale: 33 delta_scale: 3 lastScale: 36 j: 6 nextScale: 36 delta_scale: 3 lastScale: 39 j: 7 nextScale: 39 delta_scale: 0 lastScale: 39 j: 8 nextScale: 39 delta_scale: 0 lastScale: 39 j: 9 nextScale: 39 delta_scale: 0 lastScale: 39 j: 10 nextScale: 39 delta_scale: 3 lastScale: 42 j: 11 nextScale: 42 delta_scale: 0 lastScale: 42 j: 12 nextScale: 42 delta_scale: 0 lastScale: 42 j: 13 nextScale: 42 delta_scale: 0 lastScale: 42 j: 14 nextScale: 42 delta_scale: 0 lastScale: 42 j: 15 nextScale: 42 delta_scale: 3 lastScale: 45 j: 16 nextScale: 45 delta_scale: 0 lastScale: 45 j: 17 nextScale: 45 delta_scale: 0 lastScale: 45 j: 18 nextScale: 45 delta_scale: 0 lastScale: 45 j: 19 nextScale: 45 delta_scale: 0 lastScale: 45 j: 20 nextScale: 45 delta_scale: 0 lastScale: 45 j: 21 nextScale: 45 delta_scale: 3 lastScale: 48 j: 22 nextScale: 48 delta_scale: 0 lastScale: 48 j: 23 nextScale: 48 delta_scale: 0 lastScale: 48 j: 24 nextScale: 48 delta_scale: 0 lastScale: 48 j: 25 nextScale: 48 delta_scale: 0 lastScale: 48 j: 26 nextScale: 48 delta_scale: 0 lastScale: 48 j: 27 nextScale: 48 delta_scale: 0 lastScale: 48 j: 28 nextScale: 48 delta_scale: 3 lastScale: 51 j: 29 nextScale: 51 delta_scale: 0 lastScale: 51 j: 30 nextScale: 51 delta_scale: 0 lastScale: 51 j: 31 nextScale: 51 delta_scale: 0 lastScale: 51 j: 32 nextScale: 51 delta_scale: 0 lastScale: 51 j: 33 nextScale: 51 delta_scale: 0 lastScale: 51 j: 34 nextScale: 51 delta_scale: 0 lastScale: 51 j: 35 nextScale: 51 delta_scale: 0 lastScale: 51 j: 36 nextScale: 51 delta_scale: 3 lastScale: 54 j: 37 nextScale: 54 delta_scale: 0 lastScale: 54 j: 38 nextScale: 54 delta_scale: 0 lastScale: 54 j: 39 nextScale: 54 delta_scale: 0 lastScale: 54 j: 40 nextScale: 54 delta_scale: 0 lastScale: 54 j: 41 nextScale: 54 delta_scale: 0 lastScale: 54 j: 42 nextScale: 54 delta_scale: 0 lastScale: 54 j: 43 nextScale: 54 delta_scale: 3 lastScale: 57 j: 44 nextScale: 57 delta_scale: 0 lastScale: 57 j: 45 nextScale: 57 delta_scale: 0 lastScale: 57 j: 46 nextScale: 57 delta_scale: 0 lastScale: 57 j: 47 nextScale: 57 delta_scale: 0 lastScale: 57 j: 48 nextScale: 57 delta_scale: 0 lastScale: 57 j: 49 nextScale: 57 delta_scale: 3 lastScale: 60 j: 50 nextScale: 60 delta_scale: 0 lastScale: 60 j: 51 nextScale: 60 delta_scale: 0 lastScale: 60 j: 52 nextScale: 60 delta_scale: 0 lastScale: 60 j: 53 nextScale: 60 delta_scale: 0 lastScale: 60 j: 54 nextScale: 60 delta_scale: 5 lastScale: 65 j: 55 nextScale: 65 delta_scale: 0 lastScale: 65 j: 56 nextScale: 65 delta_scale: 0 lastScale: 65 j: 57 nextScale: 65 delta_scale: 0 lastScale: 65 j: 58 nextScale: 65 delta_scale: 5 lastScale: 70 j: 59 nextScale: 70 delta_scale: 0 lastScale: 70 j: 60 nextScale: 70 delta_scale: 0 lastScale: 70 j: 61 nextScale: 70 delta_scale: 5 lastScale: 75 j: 62 nextScale: 75 delta_scale: 0 lastScale: 75 j: 63 nextScale: 75 delta_scale: 5 lastScale: 80 log2_max_frame_num_minus4: 0 pic_order_cnt_type: 2 max_num_ref_frames: 2 gaps_in_frame_num_value_allowed_flag: 0 pic_width_in_mbs_minus1: 44 pic_height_in_map_units_minus1: 17 frame_mbs_only_flag: 0 frame_cropping_flag: 0 vui_parameters_present_flag: 1 BEGIN vui_parameters aspect_ratio_info_present_flag: 1 aspect_ratio_idc: 1 overscan_info_present_flag: 0 video_signal_type_present_flag: 1 colour_description_present_flag: 0 chroma_loc_info_present_flag: 0 timing_info_present_flag: 1 num_units_in_tick: 1 time_scale: 150 fixed_frame_rate_flag: 0 Set frame rate to 75.000000 fps WARNING: "fixed_frame_rate_flag" was not set ---------- -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From smerchan at gruposamtel.com Mon Jan 17 11:12:04 2011 From: smerchan at gruposamtel.com (=?iso-8859-1?Q?Santiago_Merch=E1n?=) Date: Mon, 17 Jan 2011 20:12:04 +0100 Subject: [Live-devel] Problem using MPEG2TransportStreamFramer Message-ID: <518660E9-978C-48C9-BEC1-9E6701B59E12@gruposamtel.com> Hello again, Thank you very much for your fast reply. I will try to explain better what we have done. We had to rewrite the class MPEG2TransportStreamFramer because Android doesn?t support C++ applications. We could have tried a JNI wrapper to the c++ class but as it was only a class, we decided to rewrite it. Our code in JAVA is exactly the same as yours in C++, except the things JAVA does not support, as unsigned types and so on. Anyway, our simple question is about the behaviour of your code. If we understood well, this code tries to estimate the duration of a packet, so you know the duration for the 7 packets you are sending, but we don?t know what do you do with that number. Do you sleep your sending thread that amount of time? How do you wait for the player to receive the packets? Is this in the afterGetting function? This is your code : struct timeval tvNow; gettimeofday(&tvNow, NULL); double timeNow = tvNow.tv_sec + tvNow.tv_usec/1000000.0; for (unsigned i = 0; i < numTSPackets; ++i) { updateTSPacketDurationEstimate(&fTo[i*TRANSPORT_PACKET_SIZE], timeNow); } fDurationInMicroseconds = numTSPackets * (unsigned)(fTSPacketDurationEstimate*1000000); // Complete the delivery to our client: afterGetting(this); We checked that changing the value of MAX_PLAYOUT_BUFFER_DURATION from 0.1 to 0.001 made the video and audio work smoother in the STB. But we have a lot of differences playing ts files with different codecs. We suspect we should take the file bitrate into account, but we don?t know how to relate this to the ts PCRs. Please provide us some help to be able to finish our project. Kind Regards. Fdo: Santiago Merch?n Grupo Samtel Telf: 91 426 48 75 Fax: 91 431 05 73 La informaci?n incluida en el presente correo electr?nico es CONFIDENCIAL, siendo para el uso exclusivo del destinatario arriba mencionado. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jan 17 15:01:03 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Jan 2011 15:01:03 -0800 Subject: [Live-devel] Problem using MPEG2TransportStreamFramer In-Reply-To: <518660E9-978C-48C9-BEC1-9E6701B59E12@gruposamtel.com> References: <518660E9-978C-48C9-BEC1-9E6701B59E12@gruposamtel.com> Message-ID: >Anyway, our simple question is about the >behaviour of your code. If we understood well, >this code tries to estimate the duration of a >packet, so you know the duration for the 7 >packets you are sending, but we don?t know what >do you do with that number. The "fDurationInMicroseconds" parameter ends up getting passed to the "MultiFramedRTPSink" class (via its subclass "SimpleRTPSink" in this case). This class uses this duration to figure out how long to delay - after it sends the RTP packet - before it asks the "MPEG2TransportStreamFramer" for more data. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From komal.dhote at gmail.com Mon Jan 17 02:24:31 2011 From: komal.dhote at gmail.com (Komal Dhote) Date: Mon, 17 Jan 2011 15:54:31 +0530 Subject: [Live-devel] About openRTSP Message-ID: Hi All, I have observed one point in the openRTSP. When i use openRTSP as it is it works fine, but when i introduces delay in void FileSink::afterGettingFrame1 (lets say 50 ms) i will miss some frame. why? Can anybody explain me why this is happening?As 50 ms is not that much big, in large application it may be the case. some task may take 50 ms. Please resolve this issues. Thanks and Regards, Komal Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From abc.bhaskar at gmail.com Mon Jan 17 02:39:55 2011 From: abc.bhaskar at gmail.com (Bhaskar) Date: Mon, 17 Jan 2011 16:09:55 +0530 Subject: [Live-devel] Live555 DirectShow Source Filter for Win CE Message-ID: Hi, I downloaded Live555 Streaming Media source code around 4 months back. It included folders 1. BasicUsageEnvironment, 2. groupsock, 3. liveMedia, 4. mediaServer, 5. UsageEnvironment, 6. Win32, 7. WinCE (for CoShipC866SDK (ARMV4I)). The latest release has the first five folders in common, but the latter two were changed to testprograms folder. The last two folders provided a starting point for developing rtsp directshow source filters. Could somebody provide a pointer about live555 directshow source filter sample for Win CE in the latest release. Regards. From mts.doredevelopment at gmail.com Mon Jan 17 06:58:07 2011 From: mts.doredevelopment at gmail.com (Morten Svendsen) Date: Mon, 17 Jan 2011 15:58:07 +0100 Subject: [Live-devel] bug, 1. rtp package lost when Media Server is running under windows Message-ID: Hi I am running LIVE555 Media Server version 0.65 (LIVE555 Streaming Media library version 2011.01.06). If the server is running on windows (7 pro) and serving a small wav file. The first rtp packet is not send out on the network and therefore the client newer recives the first 882 bytes of pcm data. Running tcpdump on the router and then analyzing the network traffic in wireshark, reveals that the final RTCP sender report contains a "Sender's packet count of 78", but the number of RTP packages seen on the network is only 77. Looking at a dump of the audio on the receiver shows 882 bytes missing data at the beginning. All remaining RTP packages is transmitted and received, verified by a look on the RTP sequence numbers and the audio data received. When serving the same wav file on Linux (ubuntu 10.10) running the Media Server, the number of RTP packages send out from the server is 78 as it should be and no audio data is missing When runnning the windows version of the Media Server through Wine (v1.2.1) on Linux, the bug is also present. From tonelli.francesco82 at gmail.com Mon Jan 17 07:38:27 2011 From: tonelli.francesco82 at gmail.com (Francesco Tonelli) Date: Mon, 17 Jan 2011 16:38:27 +0100 Subject: [Live-devel] trying openRTSP Message-ID: Hi, I'm Francesco, I'm a beginner of live555 Streaming Media and I would like to start playing with the RTSP server and openRTSP client. I have installed live555MediaServer on a Server DVB with Ubuntu 8.04 which address is 147.83.113.48 and I have installed the openRTSP client on my laptop (Ubuntu 10.04), which address is 147.83.113.46 I tried to use the application testOnDemandRTSPServer, I created the MPEG-2 TS test.ts file and saved it on the server. Then I tried to use (MANY TIMES) openRTSP from client in this way: openRTSP rtsp://147.83.113.48:8554/mpeg2TransportStreamTest *Just in few cases the response from server was ok, but all the other times it returns:* *Failed to get a SDP description from URL "rtsp:// 147.83.113.48:8554/mpeg2TransportStreamTest": connect() failed: Connection refused *I have no firewall between server and client...even because everything worked well at least in one case! Any help? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jan 17 16:54:17 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Jan 2011 16:54:17 -0800 Subject: [Live-devel] About openRTSP In-Reply-To: References: Message-ID: >I have observed one point in the openRTSP. When i use openRTSP as it >is it works fine, but when i introduces delay in void >FileSink::afterGettingFrame1 (lets say 50 ms) i will miss some >frame. why? Probably because your operating system has insufficient large socket reception buffering. (If you stop reading packets from a datagram socket, the operating system will buffer incoming packets, but will drop subsequent packets once its buffer fills up.) See http://www.live555.com/liveMedia/faq.html#packet-loss -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 17 16:56:18 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Jan 2011 16:56:18 -0800 Subject: [Live-devel] Live555 DirectShow Source Filter for Win CE In-Reply-To: References: Message-ID: >The last two folders provided a starting point for developing rtsp >directshow source filters. Could somebody provide a pointer about >live555 directshow source filter sample for Win CE in the latest release. We have never supplied this ourselves. You must have orginally gotten this from somewhere else. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 17 19:57:44 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 17 Jan 2011 19:57:44 -0800 Subject: [Live-devel] trying openRTSP In-Reply-To: References: Message-ID: >Just in few cases the response from server was ok, but all the other >times it returns: > >Failed to get a SDP description from URL >"rtsp://147.83.113.48:8554/mpeg2TransportStreamTest": >connect() failed: Connection refused The "Connection refused" error usually means that the server has stopped running. When you get this error, you should make sure that the server (i.e., the "testOnDemandRTSPServer" application) is still running. (If it *is* still running, then I can't explain the error, unfortunately...) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtebcherani at awox.com Tue Jan 18 02:41:57 2011 From: jtebcherani at awox.com (Jacques Tebcherani) Date: Tue, 18 Jan 2011 11:41:57 +0100 Subject: [Live-devel] Packet loss when receiving streamed data via TCP Message-ID: Hi, I have developed a PCM audio Server/Client based on "LIVE555 Streaming Media" library (v2010.04.09). I have configured my server to stream in unicast mode. I have configured my client to receive the stream via TCP (setupMediaSubsession() is called with streamUsingTCP parameter set to True). I need to receive data without packet loss and the received data are not processed in real time. I have checked that the server sends each frame with a timestamp that is incremented by 8ms. But on the client side, which is playing the stream in Wi-Fi, I have noticed that some frames are lost. When I dumped the presentation time in OssSink::afterGettingFrame1() method, each 1 or 2 seconds, I have some "holes" in the received presentation time. I mean that some presentation times are not equal to the last one + 8 ms. Is this a problem which you already encountered? Does live555 can discards some frames? Perhaps that the last version of "LIVE555 Streaming Media" library can solve this issue? Regards, Jacques Tebcherani __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 5795 (20110117) __________ Le message a ?t? v?rifi? par ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jan 18 03:26:43 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Jan 2011 03:26:43 -0800 Subject: [Live-devel] Packet loss when receiving streamed data via TCP In-Reply-To: References: Message-ID: >I have developed a PCM audio Server/Client based on "LIVE555 >Streaming Media" library (v2010.04.09). Sorry, but absolutely no support is given for old versions of the code. >Does live555 can discards some frames? No. Our code simply runs in a loop, sending frames (if it's a server), or receiving frames (if it's a client) sequentially. It never 'discards' frames. If data is getting lost, and you're streaming over TCP, then the problem must be that data is overflowing your operating system's internal buffers (at the server and/or the client ends), which suggests that your stream's data rate is simply too high for your network. >Perhaps that the last version of "LIVE555 Streaming Media" library >can solve this issue? Personally, I doubt it - but you should upgrade to the latest version anyway. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe at lemoine-fr.com Tue Jan 18 07:50:31 2011 From: christophe at lemoine-fr.com (Christophe Lemoine) Date: Tue, 18 Jan 2011 16:50:31 +0100 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: References: <72D9E13A8FC8994794D448E91198AE07020D6876@mail.sys.internal> Message-ID: <4D35B6C7.1090801@lemoine-fr.com> Hi, I finally managed to encode my H264 videos for streaming (but it is not a very good solution as I need to have a CBR TS file, with about 40% NULL packets.....) Tried the new index file: it works perfectly. Thanks a lot Ross for this !!!! Just one small detail: when I seek, the stream seems to be stopped immediately, and then the player start to buffer the new frames. During that time, the video is of course frozen, and display is a little "broken" with some artifacts. Would it be possible to pause the stream at the end of a frame ? Thanks Christophe Global Tech Management SARL 360 route de Navilly 74930 Pers-Jussy France t: +41 79 212 91 81 e: christophe at lemoine-fr.com On 01/06/2011 05:00 PM, Ross Finlayson wrote: >> We had a similar problem with MPEG2 files that are hardware >> encoded with a Hauppauge PVR-150 card (CBR file). The PCR >> timestamps increase regularly but infrequently. >> >> I fully understand that the liveMedia code should not be modified >> but in case it's helpful to anyone, our workaround was to change >> MPEG2TransportStreamFramer.cpp so that: >> >> #define NEW_DURATION_WEIGHT 0.05 >> >> also due to the size of the jitter buffer on the receiver we have: >> >> #define MAX_PLAYOUT_BUFFER_DURATION 0.25 > > Yes, setting values for those 4 parameters in > "MPEG2TransportStreamFramer.cpp" is, unfortunately, somewhat of a > 'black art'; it's going to be hard - if not impossible - to find > values that will work well for everybody. > > Note, though, that each of these definitions is enclosed by > > #if !defined( ... ) > #endif > > So it's possible to change these values without changing the file > "MPEG2TransportStreamFramer.cpp" itself. (E.g., you could define your > new values on the command line when you compile the file.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jan 18 18:52:07 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Jan 2011 18:52:07 -0800 Subject: [Live-devel] bug, 1. rtp package lost when Media Server is running under windows In-Reply-To: References: Message-ID: Many thanks for the bug report. This bug has apparently been around for a while, but hadn't been noticed until now, because it apparently manifests itself only on Windows. A new version of the "LIVE555 Streaming Media" code - and a new version (0.66) of the "LIVE555 Media Server" - have now been released that fixes this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kidjan at gmail.com Tue Jan 18 08:43:05 2011 From: kidjan at gmail.com (Jeremy Noring) Date: Tue, 18 Jan 2011 08:43:05 -0800 Subject: [Live-devel] Symbian Client having issues with Live555 based server In-Reply-To: References: Message-ID: On Sun, Jan 16, 2011 at 3:31 PM, Ross Finlayson wrote: > In such cases server should just respond by OK 200 or 451 >> >> RTSP/1.0 451 Parameter Not Understood >> > > Hmmm. The RTSP 1.0 spec lists "451" as being an error code only for > "SETUP", although the RTSP 2.0 spec lists it as being an error code only for > "SET_PARAMETER". (The latter is actually a mistake; it should also be an > error code for "GET_PARAMETER", at least according to the remainder of the > spec.) > > To be on the safe side, I should probably change the code to respond to > "SET_PARAMETER" with "OK 200", but not actually do anything. I'll make this > change in the next release of the software. > > (If you wanted to actually *handle* the "SET_PARAMETER" command - i.e., not > just have it be a no-op - then you would do this by subclassing "RTSPServer" > and "RTSPServer::RTSPClientSession", and reimplementing the virtual function > "RTSPServer::RTSPClientSession ::handleCmd_SET_PARAMETER()" in your > subclass.) > Thanks--I won't have time to test this change for a couple weeks (I need to get a symbian phone, and busy with other junk at the moment), but I'll let you know the outcome when I do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jan 18 21:01:28 2011 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 18 Jan 2011 21:01:28 -0800 Subject: [Live-devel] New LIVE555 version, now supports 'trick play' on H.264 Transport Stream files In-Reply-To: <4D35B6C7.1090801@lemoine-fr.com> References: <72D9E13A8FC8994794D448E91198AE07020D6876@mail.sys.internal> <4D35B6C7.1090801@lemoine-fr.com> Message-ID: >I finally managed to encode my H264 videos for streaming (but it is >not a very good solution as I need to have a CBR TS file, with about >40% NULL packets.....) >Tried the new index file: it works perfectly. Thanks a lot Ross for this !!!! >Just one small detail: when I seek, the stream seems to be stopped >immediately, and then the player start to buffer the new frames. >During that time, the video is of course frozen, and display is a >little "broken" with some artifacts. Would it be possible to pause >the stream at the end of a frame ? No, it would be difficult (requiring a major modification/disruption to the server code) to have the server delay handling an incoming 'seek' ("PLAY") command until it has completed streaming an entire frame. It would be simpler to update your player client to not display partially-decoded frame data until it knows that it has received the start of the next frame. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mts.doredevelopment at gmail.com Wed Jan 19 03:10:12 2011 From: mts.doredevelopment at gmail.com (Morten Svendsen) Date: Wed, 19 Jan 2011 12:10:12 +0100 Subject: [Live-devel] bug, 1. rtp package lost when Media Server is running under windows In-Reply-To: References: Message-ID: On Wed, Jan 19, 2011 at 03:52, Ross Finlayson wrote: > A new version of the "LIVE555 Streaming Media" code - and a new version > (0.66) of the "LIVE555 Media Server" - have now been released that fixes > this problem. Thanks for the fix. Unfortunately it do not solve the bug for me. My client (gstreamer 0.10.31) do not start to recive RTP packages before receiving the RTSP OK message, send in reply to the RTSP PLAY. The new relased 0.66 windows Media server sends the first RTP packacket before the RTSP OK, the 0.65 linux version sends the first RTP package after the RTSP OK. This behavior is consistence and seen in several net-dumps. Dump of some selected lines in wireshark using windows and then linux Media server below. Wireshark summary dump of live555MediaServer.exe version 0.66 Media library version 2011.01.19. WINDOWS No. Time Source Destination Protocol Info 10 0.021750 192.168.17.72 192.168.18.39 RTSP SETUP rtsp://192.168.18.39:8554/22-16-M-short.wav/track1 RTSP/1.0 11 0.023679 192.168.18.39 192.168.17.72 RTSP Reply: RTSP/1.0 200 OK 12 0.061095 192.168.17.72 192.168.18.39 TCP 38021 > rtsp-alt [ACK] Seq=414 Ack=966 18 0.073468 192.168.17.72 192.168.18.39 RTSP PLAY rtsp://192.168.18.39:8554/22-16-M-short.wav RTSP/1.0 19 0.074308 192.168.18.39 192.168.17.72 RTP PT=DynamicRTP-Type-96, SSRC=0x80006A08, Seq=1495, Time=31077 20 0.074336 192.168.18.39 192.168.17.72 RTSP Reply: RTSP/1.0 200 OK 21 0.074705 192.168.17.72 192.168.18.39 TCP 38021 > rtsp-alt [ACK] Seq=555 Ack=1164 22 0.094731 192.168.18.39 192.168.17.72 RTP PT=DynamicRTP-Type-96, SSRC=0x80006A08, Seq=1496, Time=31079 Wireshark summary dump of live555MediaServer version 0.65 Media library version 2011.01.06. LINUX No. Time Source Destination Protocol Info 10 0.020887 192.168.17.72 192.168.18.39 RTSP SETUP rtsp://192.168.18.39:8554/22-16-M-short.wav/track1 RTSP/1.0 11 0.021643 192.168.18.39 192.168.17.72 RTSP Reply: RTSP/1.0 200 OK 12 0.059858 192.168.17.72 192.168.18.39 TCP 55645 > rtsp-alt [ACK] Seq=414 Ack=966 18 0.071351 192.168.17.72 192.168.18.39 RTSP PLAY rtsp://192.168.18.39:8554/22-16-M-short.wav RTSP/1.0 19 0.071969 192.168.18.39 192.168.17.72 RTSP Reply: RTSP/1.0 200 OK 20 0.072046 192.168.18.39 192.168.17.72 RTP PT=DynamicRTP-Type-96, SSRC=0x3C39117C, Seq=49912, Time=957175847 21 0.072213 192.168.17.72 192.168.18.39 TCP 55645 > rtsp-alt [ACK] Seq=555 Ack=1169 22 0.092267 192.168.18.39 192.168.17.72 RTP PT=DynamicRTP-Type-96, SSRC=0x3C39117C, Seq=49913, Time=957176288 From finlayson at live555.com Wed Jan 19 03:59:17 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Jan 2011 03:59:17 -0800 Subject: [Live-devel] bug, 1. rtp package lost when Media Server is running under windows In-Reply-To: References: Message-ID: >On Wed, Jan 19, 2011 at 03:52, Ross Finlayson wrote: >> A new version of the "LIVE555 Streaming Media" code - and a new version >> (0.66) of the "LIVE555 Media Server" - have now been released that fixes >> this problem. > >Thanks for the fix. > >Unfortunately it do not solve the bug for me. Well, it fixed the bug that you described originally: That of the initial RTP packet not being sent over the network. > My client (gstreamer >0.10.31) do not start to recive RTP packages before receiving the RTSP >OK message, send in reply to the RTSP PLAY. Then this is a bug in your client. A RTSP/RTP client should be prepared to start receiving incoming RTP packets immediately after it sends the "PLAY" request. It should not wait until it receives the "OK" response before it starts listening for incoming RTP packets. The reason for this is that - in general - the RTP (UDP) data channel is distinct from the RTSP (TCP) control channel. Even if the server sends back the first RTP packet after it sends back the RTSP "OK", there's no guarantee that they will subsequently arrive at the client in that same order. (For example, the RTSP "OK" - being part of a TCP connection - might be delayed in the server OS's output buffer before being sent over the network, and/or might be delayed in the client OS's input buffer before being delivered to the client application. During which time the RTP packet (UDP) might already have been delivered to the client OS, which will drop it if the client application is not already prepared to receive it.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dli at Cernium.com Wed Jan 19 06:53:45 2011 From: dli at Cernium.com (Dunling Li) Date: Wed, 19 Jan 2011 09:53:45 -0500 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream Message-ID: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local> Hello, I'm a beginner of live555 Streaming Media and I would like to convert H.264 video files to TS files. One of live555 test examples, testMPEG1or2ProgramToTransportStream.cpp, show how to convert MPEG2 file to TS file using functions in MPEG2TransportStreamFromPESSource. Can anyone point me how to convert H.264 to TS using live555 functions? Many thanks in advance Dunling Cernium Corporation 1925 Isaac Newton Square, suite 300 Reston, VA 20190 Email: dli at cernium.com Phone: (703) 483-3387 Fax: (703) 483-3380 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtebcherani at awox.com Wed Jan 19 10:11:00 2011 From: jtebcherani at awox.com (Jacques Tebcherani) Date: Wed, 19 Jan 2011 19:11:00 +0100 Subject: [Live-devel] Packet loss when receiving streamed data via TCP In-Reply-To: References: Message-ID: Hi, Thank you for the response. I have another small question. To synchronize my clients, I do some calculations based on the presentation time. Is it possible that the presentation time contained in the frame send by the server can be modified by live555 library on the client side? Thanks in advance. Regards, Jacques Tebcherani _____ From: Ross Finlayson [mailto:finlayson at live555.com] Sent: mardi 18 janvier 2011 12:27 To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Packet loss when receiving streamed data via TCP I have developed a PCM audio Server/Client based on "LIVE555 Streaming Media" library (v2010.04.09). Sorry, but absolutely no support is given for old versions of the code. Does live555 can discards some frames? No. Our code simply runs in a loop, sending frames (if it's a server), or receiving frames (if it's a client) sequentially. It never 'discards' frames. If data is getting lost, and you're streaming over TCP, then the problem must be that data is overflowing your operating system's internal buffers (at the server and/or the client ends), which suggests that your stream's data rate is simply too high for your network. Perhaps that the last version of "LIVE555 Streaming Media" library can solve this issue? Personally, I doubt it - but you should upgrade to the latest version anyway. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 5796 (20110118) __________ Le message a ?t? v?rifi? par ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jan 19 16:50:56 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Jan 2011 16:50:56 -0800 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local> Message-ID: >I'm a beginner of live555 Streaming Media and I would like to >convert H.264 video files to TS files. One of live555 test examples, >testMPEG1or2ProgramToTransportStream.cpp, show how to convert MPEG2 >file to TS file using functions in >MPEG2TransportStreamFromPESSource. Can anyone point me how to >convert H.264 to TS using live555 functions? Yes, we can now convert H.264 video elementary stream files into Transport Stream files. I have now released a new version (2011.01.20) of the "LIVE555 Streaming Media" code that now includes a new demo application (in the "testProgs" directory) named "testH264VideoToTransportStream". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jan 19 16:54:01 2011 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 19 Jan 2011 16:54:01 -0800 Subject: [Live-devel] Packet loss when receiving streamed data via TCP In-Reply-To: References: Message-ID: >I have another small question. >To synchronize my clients, I do some calculations based on the >presentation time. >Is it possible that the presentation time contained in the frame >send by the server can be modified by live555 library on the client >side? Yes, see http://www.live555.com/liveMedia/faq.html#separate-rtp-streams and http://www.live555.com/liveMedia/faq.html#rtcp-synchronization-issue -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From suneets at gmail.com Thu Jan 20 01:27:16 2011 From: suneets at gmail.com (Suneet Shah) Date: Thu, 20 Jan 2011 01:27:16 -0800 Subject: [Live-devel] Rebroadcast an RTP stream as an RTSP stream with Live555? Message-ID: Hello, I'm wondering if Live555 media server can help me accomplish the following: - I'm using gstreamer to create a live video feed encoded in H264, and then transmitted as RTP packets. - I need to rebroadcast this stream as RTSP with a properly generated SDP file, so that it can be viewed on Android Can Live555 accomplish this? From the website, I couldn't tell if it works well with live streams, or only with recorded files. If so, can someone share an example SDP file or provide more instructions on how to do so? Thanks in advance, Suneet -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jan 20 01:52:14 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 01:52:14 -0800 Subject: [Live-devel] Rebroadcast an RTP stream as an RTSP stream with Live555? In-Reply-To: References: Message-ID: >I'm wondering if Live555 media server can help me accomplish the following: > >I'm using gstreamer to create a live video feed encoded in H264, and >then transmitted as RTP packets. >I need to rebroadcast this stream as RTSP with a properly generated >SDP file, so that it can be viewed on Android > >Can Live555 accomplish this? From the website, I couldn't tell if it >works well with live streams, or only with recorded files. The supplied code includes demo applications that stream from files; however, these can be adapted to stream from a live source instead. See http://www.live555.com/liveMedia/faq.html#liveInput-unicast Because your input data is a RTP stream, you could use a "H264VideoRTPSource" as your 'input device'. BTW, if you wished, you could also use our code (instead of 'gstreamer') to stream encoded H.264 video via RTP. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dli at Cernium.com Thu Jan 20 08:02:06 2011 From: dli at Cernium.com (Dunling Li) Date: Thu, 20 Jan 2011 11:02:06 -0500 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: References: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local> Message-ID: <03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig.Cernium.local> Dear Ross, Thank you so much for releasing the new version of LIVE555 so quick. I tested the demo "testH264VideoToTransportStream" using 4 second h264 video clip, the program stucked at endless loop and didn't write any data to the output file. When I stepped into the codes, it got into the following conditions 1. "return 0; // the parsing got interrupted" in function H264VideoStreamParser::parse() 2. acquiredFrameSize=0 in MPEGVideoStreamFramer::continueReadProcessing // We were unable to parse a complete frame from the input, because: // - we had to read more data from the source stream, or // - the source stream has ended. This happened when I reduced BANK_SIZE to 15000 which is larger than size of my video clip. Could you help me or guide me to fix this? Many thanks Dunling Li Cernium Corporation 1925 Isaac Newton Square, suite 300 Reston, VA 20190 Email: dli at cernium.com Phone: (703) 483-3387 Fax: (703) 483-3380 -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, January 19, 2011 7:51 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream >I'm a beginner of live555 Streaming Media and I would like to >convert H.264 video files to TS files. One of live555 test examples, >testMPEG1or2ProgramToTransportStream.cpp, show how to convert MPEG2 >file to TS file using functions in >MPEG2TransportStreamFromPESSource. Can anyone point me how to >convert H.264 to TS using live555 functions? Yes, we can now convert H.264 video elementary stream files into Transport Stream files. I have now released a new version (2011.01.20) of the "LIVE555 Streaming Media" code that now includes a new demo application (in the "testProgs" directory) named "testH264VideoToTransportStream". -- 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 dli at Cernium.com Thu Jan 20 09:28:16 2011 From: dli at Cernium.com (Dunling Li) Date: Thu, 20 Jan 2011 12:28:16 -0500 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: <03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig.Cernium.local> Message-ID: <03A2FA9E0D3DC841992E682BF528771802C0B4C7@lipwig.Cernium.local> The demo program testH264VideoToTransportStream is stuck at the line "(void)bv.get_expGolomb(); // frame_crop_right_offset" in H264VideoStreamParser::analyze_seq_parameter_set_data, because get1Bit always return 0 due to fCurBitIndex >= fTotNumBits. The beginning bits of my video clip is 00 00 00 01 67 42 80 1e da 05 87 c4 00 00 00 0168 ce.... The video clip can be displayed in VLC player. Could you point me how to fix this? Thanks Dunling -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Dunling Li Sent: Thursday, January 20, 2011 11:02 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream Dear Ross, Thank you so much for releasing the new version of LIVE555 so quick. I tested the demo "testH264VideoToTransportStream" using 4 second h264 video clip, the program stucked at endless loop and didn't write any data to the output file. When I stepped into the codes, it got into the following conditions 1. "return 0; // the parsing got interrupted" in function H264VideoStreamParser::parse() 2. acquiredFrameSize=0 in MPEGVideoStreamFramer::continueReadProcessing // We were unable to parse a complete frame from the input, because: // - we had to read more data from the source stream, or // - the source stream has ended. This happened when I reduced BANK_SIZE to 15000 which is larger than size of my video clip. Could you help me or guide me to fix this? Many thanks Dunling Li Cernium Corporation 1925 Isaac Newton Square, suite 300 Reston, VA 20190 Email: dli at cernium.com Phone: (703) 483-3387 Fax: (703) 483-3380 -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Wednesday, January 19, 2011 7:51 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream >I'm a beginner of live555 Streaming Media and I would like to >convert H.264 video files to TS files. One of live555 test examples, >testMPEG1or2ProgramToTransportStream.cpp, show how to convert MPEG2 >file to TS file using functions in >MPEG2TransportStreamFromPESSource. Can anyone point me how to >convert H.264 to TS using live555 functions? Yes, we can now convert H.264 video elementary stream files into Transport Stream files. I have now released a new version (2011.01.20) of the "LIVE555 Streaming Media" code that now includes a new demo application (in the "testProgs" directory) named "testH264VideoToTransportStream". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Jan 20 12:38:49 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 12:38:49 -0800 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: <03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig.Cernium.local> Message-ID: >Thank you so much for releasing the new version of LIVE555 so quick. I >tested the demo "testH264VideoToTransportStream" using 4 second h264 >video clip, the program stucked at endless loop and didn't write any >data to the output file. http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Please put your "test.h264" file on a web server, and send us the URL, so we can download it and test it for ourselves. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dli at Cernium.com Thu Jan 20 12:56:40 2011 From: dli at Cernium.com (Dunling Li) Date: Thu, 20 Jan 2011 15:56:40 -0500 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: References: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local><03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig.Cernium.local> Message-ID: <03A2FA9E0D3DC841992E682BF528771802C0B57A@lipwig.Cernium.local> We don't have any web server working now. The file size is about 138KB. Can I send you the file by email? Thanks Dunling -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, January 20, 2011 3:39 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream >Thank you so much for releasing the new version of LIVE555 so quick. I >tested the demo "testH264VideoToTransportStream" using 4 second h264 >video clip, the program stucked at endless loop and didn't write any >data to the output file. http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Please put your "test.h264" file on a web server, and send us the URL, so we can download it and test it for ourselves. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Jan 20 13:08:58 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 13:08:58 -0800 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: <03A2FA9E0D3DC841992E682BF528771802C0B4C7@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771802C0B4C7@lipwig.Cernium.local> Message-ID: >The demo program testH264VideoToTransportStream is stuck at the line >"(void)bv.get_expGolomb(); // frame_crop_right_offset" in >H264VideoStreamParser::analyze_seq_parameter_set_data, because get1Bit >always return 0 due to fCurBitIndex >= fTotNumBits. Yes, this is happening because our H.264 parser is running past the end of a SPS NAL unit in your file. Most likely this is because of a bug in how we're parsing/interpreting the SPS data (in the function "analyze_seq_parameter_set_data()" in "liveMedia/H264VideoStreamFramer.cpp"). As I noted earlier, I'd like to see an example of a "test.264" file that's failing, so I can track down and fix the bug. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jan 20 13:09:50 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 13:09:50 -0800 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: <03A2FA9E0D3DC841992E682BF528771802C0B57A@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local><03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig .Cernium.local> <03A2FA9E0D3DC841992E682BF528771802C0B57A@lipwig.Cernium.local> Message-ID: >We don't have any web server working now. The file size is about 138KB. >Can I send you the file by email? Yes, 138 kBytes is fine. Please email the file. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dli at Cernium.com Thu Jan 20 13:22:49 2011 From: dli at Cernium.com (Dunling Li) Date: Thu, 20 Jan 2011 16:22:49 -0500 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: References: <03A2FA9E0D3DC841992E682BF528771802C0B1FC@lipwig.Cernium.local><03A2FA9E0D3DC841992E682BF528771802C0B474@lipwig.Cernium.local> <03A2FA9E0D3DC841992E682BF528771802C0B57A@lipwig.Cernium.local> Message-ID: <03A2FA9E0D3DC841992E682BF528771802C0B590@lipwig.Cernium.local> I sent the file to finlayson at live555.com. Please let me know if you didn't get it. Thanks Dunling -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, January 20, 2011 4:10 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream >We don't have any web server working now. The file size is about 138KB. >Can I send you the file by email? Yes, 138 kBytes is fine. Please email the 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 From finlayson at live555.com Thu Jan 20 16:06:38 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 16:06:38 -0800 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream Message-ID: I've fixed a bug in "H264VideoStreamFramer" (which affected only the new "testH264VideoToTransportStream" demo application), and have now installed a new version (2011.01.21) of the "LIVE555 Streaming Media" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From suneets at gmail.com Thu Jan 20 09:31:27 2011 From: suneets at gmail.com (Suneet Shah) Date: Thu, 20 Jan 2011 09:31:27 -0800 Subject: [Live-devel] Rebroadcast an RTP stream as an RTSP stream with Live555? In-Reply-To: References: Message-ID: Thanks a lot Ross. Can you confirm that others have had success streaming to Android with H264? Android seems extremely particular about RTSP implementations. I'm using gstreamer to capture a desktop as live video. I can feed it to Live as raw video or encoded-- my goal is to get very low latency so I will try both. I can also use ffmpeg to create the video stream if others have had success with the combo of ffmpeg and live. Sent from my mobile device, please excuse poor speling On Jan 20, 2011, at 1:52 AM, Ross Finlayson wrote: > >> I'm wondering if Live555 media server can help me accomplish the following: > >> > >> I'm using gstreamer to create a live video feed encoded in H264, and then transmitted as RTP packets. >> I need to rebroadcast this stream as RTSP with a properly generated SDP file, so that it can be viewed on Android > >> > >> Can Live555 accomplish this? From the website, I couldn't tell if it works well with live streams, or only with recorded files. > > The supplied code includes demo applications that stream from files; however, these can be adapted to stream from a live source instead. See > http://www.live555.com/liveMedia/faq.html#liveInput-unicast > > Because your input data is a RTP stream, you could use a "H264VideoRTPSource" as your 'input device'. > > BTW, if you wished, you could also use our code (instead of 'gstreamer') to stream encoded H.264 video via RTP. > -- > > 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: From dli at Cernium.com Thu Jan 20 17:06:31 2011 From: dli at Cernium.com (Dunling Li) Date: Thu, 20 Jan 2011 20:06:31 -0500 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: References: Message-ID: <03A2FA9E0D3DC841992E682BF528771802C0B5FC@lipwig.Cernium.local> Ross, I tested the new version (2011.01.21) of testh264VideoToTransportStream using the video clip which I sent to you. The generated output TS file is good, but misses the last part of video. If I run testprogs.exe in command line, it didn't show any error message. However, when I run it on VC 2005 debug mode, I got "Unhandled exception at 0x1024f221 in testProgs.exe: 0XC00000FD: Stack overflow". The program stop right after addData(fBuffer, frameSize, presentationTime); in FileSink::afterGettingFrame1. Could you help me to fix it? Many thanks Dunling -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, January 20, 2011 7:07 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream I've fixed a bug in "H264VideoStreamFramer" (which affected only the new "testH264VideoToTransportStream" demo application), and have now installed a new version (2011.01.21) of the "LIVE555 Streaming Media" code. -- 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 dli at Cernium.com Thu Jan 20 17:17:15 2011 From: dli at Cernium.com (Dunling Li) Date: Thu, 20 Jan 2011 20:17:15 -0500 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: <03A2FA9E0D3DC841992E682BF528771802C0B5FC@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771802C0B5FC@lipwig.Cernium.local> Message-ID: <03A2FA9E0D3DC841992E682BF528771802C0B5FD@lipwig.Cernium.local> If BANK_SIZE is reduced from 150000 to 70000 in the file StreamParser.cpp, then the program works perfectly. Thanks Dunling -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Dunling Li Sent: Thursday, January 20, 2011 8:07 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream Ross, I tested the new version (2011.01.21) of testh264VideoToTransportStream using the video clip which I sent to you. The generated output TS file is good, but misses the last part of video. If I run testprogs.exe in command line, it didn't show any error message. However, when I run it on VC 2005 debug mode, I got "Unhandled exception at 0x1024f221 in testProgs.exe: 0XC00000FD: Stack overflow". The program stop right after addData(fBuffer, frameSize, presentationTime); in FileSink::afterGettingFrame1. Could you help me to fix it? Many thanks Dunling -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Thursday, January 20, 2011 7:07 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream I've fixed a bug in "H264VideoStreamFramer" (which affected only the new "testH264VideoToTransportStream" demo application), and have now installed a new version (2011.01.21) of the "LIVE555 Streaming Media" code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Jan 20 17:26:35 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 17:26:35 -0800 Subject: [Live-devel] Conversion from H.264 to MPEG2 Transport Stream In-Reply-To: <03A2FA9E0D3DC841992E682BF528771802C0B5FC@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771802C0B5FC@lipwig.Cernium.local> Message-ID: >I tested the new version (2011.01.21) of testh264VideoToTransportStream >using the video clip which I sent to you. The generated output TS file >is good, but misses the last part of video. >If I run testprogs.exe in command line, it didn't show any error >message. However, when I run it on VC 2005 debug mode, I got "Unhandled >exception at 0x1024f221 in testProgs.exe: 0XC00000FD: Stack overflow". >The program stop right after addData(fBuffer, frameSize, >presentationTime); in FileSink::afterGettingFrame1. Could you help me to >fix it? Sorry, no; I have no idea what's going on. I suggest that you recompile everything from scratch, and try again. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jan 20 18:06:07 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 18:06:07 -0800 Subject: [Live-devel] Rebroadcast an RTP stream as an RTSP stream with Live555? In-Reply-To: References: Message-ID: >Can you confirm that others have had success streaming to Android with H264? No, it's up to 'others' to report any problems that they may have had with Android clients playing streaming from LIVE555 servers. The only such report that I've seen so far was one - last Sunday - that claimed that an Android RTSP/RTP client did not handle the static RTP payload type 33 (meaning: MPEG Transport Stream data). I responded, pointing out that this client was not standards-compliant, and needed to be fixed. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From anders_chen at huntelec.com.tw Thu Jan 20 22:08:29 2011 From: anders_chen at huntelec.com.tw (HUNT_Anders Chen) Date: Fri, 21 Jan 2011 14:08:29 +0800 Subject: [Live-devel] Responding GET_PARAMETER causes VCL stop receiving data Message-ID: <793EC1F8A6474933AFB6ECE1153E1A03@huntelec.com.tw> Hello, I'm testing a RTSP Server by VLC via RTP/TCP. When I enable "GET_PARAMETER" in OPTION response, VLC will use it for keep-alive. In TCP mode, command and streaming data use the same socket. I found the response of GET_PARAMETER will be included in the packet of streaming data. And VLC will stop receiving data after few packets. Thank you. Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders_chen at huntelec.com.tw Thu Jan 20 22:24:24 2011 From: anders_chen at huntelec.com.tw (HUNT_Anders Chen) Date: Fri, 21 Jan 2011 14:24:24 +0800 Subject: [Live-devel] When send() failed, the return value of send() - EAGAIN Message-ID: <92FC22DFD35C46C7AEE8E28AFF58C691@huntelec.com.tw> Hello, I'm wondering, why LIVE555 project doesn't care about the return value of send(). I'm facing a problem these days. My RTSP Server was connected via a low speed network in RTP/TCP mode, and the client couldn't get any complete image. I check the return value of send(): on Linux : "errno" will be 11 -> EAGAIN on Windows : "GetLastError()" will be 10035 -> WSAEWOULDBLOCK Ignore the error, and try to send() again, it works. Is there any reason why does LIVE555 not check the return value of send()? Thank you. Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jan 20 23:21:36 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 23:21:36 -0800 Subject: [Live-devel] Responding GET_PARAMETER causes VCL stop receiving data In-Reply-To: <793EC1F8A6474933AFB6ECE1153E1A03@huntelec.com.tw> References: <793EC1F8A6474933AFB6ECE1153E1A03@huntelec.com.tw> Message-ID: > I'm testing a RTSP Server by VLC via RTP/TCP. Just to clarify: Are you using VLC as a RTSP server, or a RTSP client? (Note that VLC - when run as a RTSP server - does *not* use our software.) If you're running VLC as a RTSP client, then what are you using as your RTSP server? (Is the server implemented using our software?) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jan 20 23:42:51 2011 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 20 Jan 2011 23:42:51 -0800 Subject: [Live-devel] When send() failed, the return value of send() - EAGAIN In-Reply-To: <92FC22DFD35C46C7AEE8E28AFF58C691@huntelec.com.tw> References: <92FC22DFD35C46C7AEE8E28AFF58C691@huntelec.com.tw> Message-ID: > I'm wondering, why LIVE555 project doesn't care about the return >value of send(). Because there's usually nothing meaningful we can do if "send()" fails. > I'm facing a problem these days. > My RTSP Server was connected via a low speed network in RTP/TCP >mode, and the client couldn't get any complete image. Sorry, but if you're streaming over TCP, and "send()"s are failing, then it must be because your OS buffers are overflowing, because your stream's bitrate exceeding the capacity of your network. In that case, you lose. End of story. Don't stream over TCP. Stream over UDP instead. Yes, you'll still lose data, but at least the data loss will be on RTP packet boundaries. > I check the return value of send(): > on Linux : "errno" will be 11 -> EAGAIN > on Windows : "GetLastError()" will be 10035 -> WSAEWOULDBLOCK > Ignore the error, and try to send() again, it works. > > Is there any reason why does LIVE555 not check the return value of send()? Because, as I said before, there's nothing meaningful we could do. It sounds like you're talking about trying to implement some sort of 'reliable retransmission' protocol on top of TCP. Sorry, but that's completely brain damaged. TCP is already a reliable protocol. If it's failing, then your network must be inadequate for your stream's bitrate. You'll need a slower stream, or a faster network. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From suneets at gmail.com Fri Jan 21 02:35:02 2011 From: suneets at gmail.com (Suneet Shah) Date: Fri, 21 Jan 2011 02:35:02 -0800 Subject: [Live-devel] Rebroadcast an RTP stream as an RTSP stream with Live555? In-Reply-To: References: Message-ID: Nevermind-- apparently I was using a video resolution that would not work with Android. I tried again using a new .264 file with a lower resolution (320 x 240)--- and it works. On Fri, Jan 21, 2011 at 2:19 AM, Suneet Shah wrote: > Hi Ross, > > So I setup Live555 and put two files into the media folder: > > > - .264 file (stream plays in VLC) > - .m4e file (stream plays in VLC) > > Neither of these play on Android. Unfortunately, Android only supports H264 > in an MP4 or 3GPP container. > > Is there a way to stream this with Live555? When I tried streaming an mp4 > file (e.g. H264 In MPEG4), it did not work.. Unfortunately, Android only has > native support for H.263/264 in MPEG4/3GPP. > > Thanks, > Suneet > > On Thu, Jan 20, 2011 at 6:06 PM, Ross Finlayson wrote: > >> Can you confirm that others have had success streaming to Android with >>> H264? >>> >> >> No, it's up to 'others' to report any problems that they may have had with >> Android clients playing streaming from LIVE555 servers. >> >> The only such report that I've seen so far was one - last Sunday - that >> claimed that an Android RTSP/RTP client did not handle the static RTP >> payload type 33 (meaning: MPEG Transport Stream data). I responded, >> pointing out that this client was not standards-compliant, and needed to be >> fixed. >> >> -- >> >> Ross Finlayson >> Live Networks, Inc. >> http://www.live555.com/ >> _______________________________________________ >> live-devel mailing list >> live-devel at lists.live555.com >> http://lists.live555.com/mailman/listinfo/live-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jemicheng at gmail.com Fri Jan 21 07:47:55 2011 From: jemicheng at gmail.com (Cheng James) Date: Fri, 21 Jan 2011 23:47:55 +0800 Subject: [Live-devel] Quicktime player 7.6.9 can't play x.264 bit stream file Message-ID: Hi, I use the prebuilt live555 server binary and a .264 sample file which is downloaded from live555 web site for testing h.264 streaming. I found that quicktime player version 7.6.9 can't play the stream. After quicktime sucessfully connects to the live 555 server, the quicktime only displays a scrolling bar and shows nothing. Is it a problem for quicktime or live555? BR, Joey -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jan 21 10:47:58 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 21 Jan 2011 10:47:58 -0800 Subject: [Live-devel] Quicktime player 7.6.9 can't play x.264 bit stream file In-Reply-To: References: Message-ID: >I use the prebuilt live555 server binary and a .264 sample file >which is downloaded from live555 web site for testing h.264 >streaming. >I found that quicktime player version 7.6.9 can't play the stream. >After quicktime sucessfully connects to the live 555 server, the >quicktime >only displays a scrolling bar and shows nothing. Is it a problem for >quicktime or live555? Quicktime. QuickTime Player apparently does not support the 'profile' of H.264 video that was used to encode the ".264" file that you used. If, however, you use the VLC client - http://www.videolan.org/vlc - you'll find that it can play the stream OK. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From w at uter.be Sun Jan 23 06:10:27 2011 From: w at uter.be (Wouter Verhelst) Date: Sun, 23 Jan 2011 15:10:27 +0100 Subject: [Live-devel] Custom RTSP options Message-ID: <20110123141027.GA4100@celtic.nixsys.be> Hi, I'm working on dvswitch[1], where we're changing the architecture from using a piped dvgrab command that writes directly to a TCP socket to properly encapsulating DV in RTSP. The liveMedia libraries have been changed a while back to make that possible (there was no DV encapsulation previously); thanks for that. One feature that the current implementation of dvswitch has, but which the new one doesn't have yet, is support of tally lights[2]. In looking for how to implement this using the liveMedia library, I found that there didn't seem to be a possibility. What I think we'd need is some way to (1) advertise (from the server side) that a particular RTSP server would understand our custom tally light command, (2) the possibility to send a tally command from the client side, and (3) register a callback on the server that gets called when that custom command has arrived. Am I mistaken in believing that isn't available? If so, could anyone point me towards the necessary parts of the code that I should be looking at? If not, I'll probably look into implementing this myself, but it'd be nice to get some input on that first, so that I don't end up writing something which would be refused. Thanks, [1] http://dvswitch.alioth.debian.org [2] In case you haven't heard of them, tally lights are those lights shown on most professional TV cameras that tell the camera operator (and people in front of the camera) which camera stream is 'live' on the broadcast. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html From finlayson at live555.com Sun Jan 23 14:34:26 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 23 Jan 2011 14:34:26 -0800 Subject: [Live-devel] Custom RTSP options In-Reply-To: <20110123141027.GA4100@celtic.nixsys.be> References: <20110123141027.GA4100@celtic.nixsys.be> Message-ID: >What I think we'd need is some way to (1) advertise (from the server >side) that a particular RTSP server would understand our custom tally >light command, (2) the possibility to send a tally command from the >client side, and (3) register a callback on the server that gets called >when that custom command has arrived. > >Am I mistaken in believing that isn't available? The RTSP protocol does, indeed, have a mechanism to support the querying and/or setting of custom server parameters - namely, the "GET_PARAMETER" and "SET_PARAMETER" commands. You should use those, instead of trying to extend the RTSP protocol in a way that no standard client or server would understand. I.e., rather than trying to customize (modify) the RTSP *protocol*, you would instead be leaving the standard RTSP protocol 'as is', but instead defining custom *parameters* that clients could query and/or set using the standard "GET_PARAMETER" and "SET_PARAMETER" commands. Our default RTSP server implementation - which we distribute in our released source code - implementes "GET_PARAMETER" and "SET_PARAMETER" as 'no-op's. I.e., it responds to them with a "200 OK" response, but doesn't actually do anything. To change this, you should not modify the supplied source code, but instead *extend* it, using C++ subclassing. Specifically, you would define your own subclass of "RTSPServer" and "RTSPClientSession", and reimplement the virtual function "createNewClientSession()" so that it creates and returns an object of your "RTSPClientSession" subclass. Then, in your "RTSPClientSession" subclass, you would reimplement the virtual functions "handleCmd_GET_PARAMETER()" and "handleCmd_SET_PARAMETER()". > If so, could anyone >point me towards the necessary parts of the code that I should be >looking at? If not, I'll probably look into implementing this myself, >but it'd be nice to get some input on that first, so that I don't end up >writing something which would be refused. As I noted above, you should be thinking about extending the existing library via C++ subclassing, rather than modifying it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From w at uter.be Sun Jan 23 15:11:07 2011 From: w at uter.be (Wouter Verhelst) Date: Mon, 24 Jan 2011 00:11:07 +0100 Subject: [Live-devel] Custom RTSP options In-Reply-To: References: <20110123141027.GA4100@celtic.nixsys.be> Message-ID: <20110123231107.GA25585@celtic.nixsys.be> On Sun, Jan 23, 2011 at 02:34:26PM -0800, Ross Finlayson wrote: > >What I think we'd need is some way to (1) advertise (from the server > >side) that a particular RTSP server would understand our custom tally > >light command, (2) the possibility to send a tally command from the > >client side, and (3) register a callback on the server that gets called > >when that custom command has arrived. > > > >Am I mistaken in believing that isn't available? > > The RTSP protocol does, indeed, have a mechanism to support the > querying and/or setting of custom server parameters - namely, the > "GET_PARAMETER" and "SET_PARAMETER" commands. You should use those, > instead of trying to extend the RTSP protocol in a way that no > standard client or server would understand. > > I.e., rather than trying to customize (modify) the RTSP *protocol*, > you would instead be leaving the standard RTSP protocol 'as is', but > instead defining custom *parameters* that clients could query and/or > set using the standard "GET_PARAMETER" and "SET_PARAMETER" commands. Right -- I was aware that there is a way to extend RTSP compatibly, I was just not entirely clear on the specifics. So it's parameters that we want to use rather than commands, okay. > Our default RTSP server implementation - which we distribute in our > released source code - implementes "GET_PARAMETER" and > "SET_PARAMETER" as 'no-op's. I.e., it responds to them with a "200 > OK" response, but doesn't actually do anything. To change this, you > should not modify the supplied source code, but instead *extend* it, > using C++ subclassing. > > Specifically, you would define your own subclass of "RTSPServer" and > "RTSPClientSession", and reimplement the virtual function > "createNewClientSession()" so that it creates and returns an object > of your "RTSPClientSession" subclass. > > Then, in your "RTSPClientSession" subclass, you would reimplement > the virtual functions "handleCmd_GET_PARAMETER()" and > "handleCmd_SET_PARAMETER()". Great, thanks; that seems to be straightforward enough. > > If so, could anyone > >point me towards the necessary parts of the code that I should be > >looking at? If not, I'll probably look into implementing this myself, > >but it'd be nice to get some input on that first, so that I don't end up > >writing something which would be refused. > > As I noted above, you should be thinking about extending the > existing library via C++ subclassing, rather than modifying it. Note that I was only offering to implement anything if it wasn't supported yet :-) -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html From anders_chen at huntelec.com.tw Sun Jan 23 17:04:02 2011 From: anders_chen at huntelec.com.tw (HUNT_Anders Chen) Date: Mon, 24 Jan 2011 09:04:02 +0800 Subject: [Live-devel] Responding GET_PARAMETER causes VCL stop Message-ID: >> I'm testing a RTSP Server by VLC via RTP/TCP. > >Just to clarify: Are you using VLC as a RTSP server, or a RTSP >client? (Note that VLC - when run as a RTSP server - does *not* use >our software.) > >If you're running VLC as a RTSP client, then what are you using as >your RTSP server? (Is the server implemented using our software?) >-- Sorry, I didn't say it clearly. I impliemented a LIVE555 RTSP server, and connected it by VLC as a client. Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From nishizawa23 at gmail.com Sun Jan 23 20:33:45 2011 From: nishizawa23 at gmail.com (doherty pete) Date: Mon, 24 Jan 2011 12:33:45 +0800 Subject: [Live-devel] mediaserver can use wav? Message-ID: in live555.com it write A WAV (PCM) audio file (with file name suffix ".wav") i convert mp3 file to wav file withe software ,and it can play with vlc but i convert to adpcm_ima_wav ,it can play,it's different form wav and adpcm-ima_wav? -- pete_doherty -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jan 23 21:56:44 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 23 Jan 2011 21:56:44 -0800 Subject: [Live-devel] mediaserver can use wav? In-Reply-To: References: Message-ID: http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work Please put your WAV file on a web server, and send us the URL, so we can download it and test it for ourselves. (Or you can send it by email if it's reasonably small.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jan 23 22:11:29 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 23 Jan 2011 22:11:29 -0800 Subject: [Live-devel] Responding GET_PARAMETER causes VCL stop In-Reply-To: References: Message-ID: >I impliemented a LIVE555 RTSP server, and connected it by VLC as a client. Our RTSP server will keep streaming to a client (and keep its RTSP connection open) as long as it keeps receiving an indication that the client is 'alive'. A client is considered to be 'alive' if the server receives a RTCP packet from the client, and/or receives any RTSP command (including "GET_PARAMETER"). VLC - as a RTSP/RTP client - does both of these: it frequently sends RTCP RR (Reception Report) packets (because RTCP is a manditory part of the RTP/RTCP protocol), and it also periodically sends "GET_PARAMETER" commands. Therefore, if a VLC client communicates with a LIVE555 RTSP server, the connection should not end prematurely. (If it does, then the cause must be something unrelated to VLC or LIVE555 - perhaps a network or firewall problem.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nishizawa23 at gmail.com Sun Jan 23 22:30:55 2011 From: nishizawa23 at gmail.com (doherty pete) Date: Mon, 24 Jan 2011 14:30:55 +0800 Subject: [Live-devel] mediaserver can use wav? In-Reply-To: References: Message-ID: this is my test file 2011/1/24 Ross Finlayson > http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work > > Please put your WAV file on a web server, and send us the URL, so we can > download it and test it for ourselves. > > (Or you can send it by email if it's reasonably small.) > -- > > 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 > -- pete_doherty -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Sweet By And By.wav Type: audio/x-wav Size: 1341500 bytes Desc: not available URL: From jemicheng at gmail.com Sun Jan 23 22:52:24 2011 From: jemicheng at gmail.com (Cheng James) Date: Mon, 24 Jan 2011 14:52:24 +0800 Subject: [Live-devel] Quicktime player 7.6.9 can't play x.264 bit stream file Message-ID: >I use the prebuilt live555 server binary and a .264 sample file >which is downloaded from live555 web site for testing h.264 >streaming. >I found that quicktime player version 7.6.9 can't play the stream. >After quicktime sucessfully connects to the live 555 server, the >quicktime >only displays a scrolling bar and shows nothing. Is it a problem for >quicktime or live555? >Quicktime. QuickTime Player apparently does not support the >'profile' of H.264 video that was used to encode the ".264" file that >you used. >If, however, you use the VLC client - http://www.videolan.org/vlc - >you'll find that it can play the stream OK. Thanks for the information. Accroding to my understanding, there are only 3 profiles of H.264 (high, main and baseline)but none of them could be played by quicktime. I have also posted this question to the quicktime forum but no answer returned. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jan 24 02:58:36 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 24 Jan 2011 02:58:36 -0800 Subject: [Live-devel] mediaserver can use wav? In-Reply-To: References: Message-ID: >i convert mp3 file to wav file withe software ,and it can play with vlc >but i convert to adpcm_ima_wav ,it can play,it's different form wav >and adpcm-ima_wav? Sorry, but we don't currently support streaming from WAV files that contain IMA ADPCM-format (or "DVA4") audio. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From raberasturi at gmail.com Tue Jan 25 07:41:49 2011 From: raberasturi at gmail.com (Ramiro Aberasturi) Date: Tue, 25 Jan 2011 12:41:49 -0300 Subject: [Live-devel] Support for QoS DSCP based Message-ID: Ross First all, thanks you and all the people who has contributed for being developed such a nice piece of software. Now, I would like to know, if it?s possible marking packets using QoS DSCP based, RFC2474, (I think so) in live555mediaserver implementation RTP-UDP or RTP-TCP. According to good practices for DSCP QoS documentation: for RTSP DSCP would be CS4 -> 32 Dec -> 100000 for RTP DSCP would be AF31 -> 26 Dec -> 011010 I was digging into the code (specifically MultiFramedRTPSink.cpp) and can see you?re inserting frames and packing into RTP packets (not founded where you?re handling RTSP packets yet), so and I?m trying to understand where would be the best place to insert the code for proper DSCP marking. Thanks in advance Rama -------------- next part -------------- An HTML attachment was scrubbed... URL: From edi87 at fibertel.com.ar Wed Jan 26 05:00:37 2011 From: edi87 at fibertel.com.ar (edi87 at fibertel.com.ar) Date: Wed, 26 Jan 2011 10:00:37 -0300 Subject: [Live-devel] testOnDemandRTSPServer always stream audio/MPA and video/MPV ? Message-ID: Hello, I'm seeing something that I consider weird. I downloaded a lot of .mpg files which I'm streaming using testOnDemandRTSPServer. I run it and then launch openRTSP with '-q' arg to obtain a mov file. When openRTSP open the stream I see: Created receiver for "video/MPV" subsession (client ports 53502-53503) Created receiver for "audio/MPA" subsession (client ports 42830-42831) Setup "video/MPV" subsession (client ports 53502-53503) Setup "audio/MPA" subsession (client ports 42830-42831) Warning: We don't implement a QuickTime Video Media Data Type for the "MPV" track, so we'll insert a dummy "????" Media Data Atom instead. A separate, codec-specific editing pass will be needed before this track can be played. Warning: We don't implement a QuickTime Audio Media Data Type for the "MPA" track, so we'll insert a dummy "????" Media Data Atom instead. A separate, codec-specific editing pass will be needed before this track can be played. Started playing session Receiving streamed data (signal with "kill -HUP 22469" or "kill -USR1 22469" to terminate)... Which result in a .mov file that cannot be playable, afaik because openRTSP insert a dummy media atom instead correct one. This happen with ALL mpg files I tried. If I do a ffmpeg -i test.mpg: FFmpeg version SVN-r0.5.1-4:0.5.1-1ubuntu1, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --extra-version=4:0.5.1-1ubuntu1 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --disable-stripping --disable-vhook --enable-runtime-cpudetect --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --enable-shared --disable-static libavutil 49.15. 0 / 49.15. 0 libavcodec 52.20. 1 / 52.20. 1 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter 0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on Mar 4 2010 12:35:30, gcc: 4.4.3 Input #0, mpegvideo, from 'test.mpg': Duration: 00:00:00.00, bitrate: 104867 kb/s Stream #0.0: Video: mpeg1video, yuv420p, 400x400 [PAR 1:1 DAR 1:1], 104857 kb/s, 30 tbr, 1200k tbn, 30 tbc This happen with a lot of mpg that I tried. My question is, what do I need to do to stream a mpg file and then be able to open it with openRTSP and obtain a valid .mov file? Thanks in advance, Jonathan -------------- next part -------------- Ross First all, thanks you and all the people who has contributed for being developed such a nice piece of software. Now, I would like to know, if it?s possible marking packets using QoS DSCP based, RFC2474, (I think so) in live555mediaserver implementation RTP-UDP or RTP-TCP. According to good practices for DSCP QoS documentation: for RTSP DSCP would be CS4 -> 32 Dec -> 100000 for RTP DSCP would be AF31 -> 26 Dec -> 011010 I was digging into the code (specifically MultiFramedRTPSink.cpp) and can see you?re inserting frames and packing into RTP packets (not founded where you?re handling RTSP packets yet), so and I?m trying to understand where would be the best place to insert the code for proper DSCP marking. Thanks in advance Rama -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Fri Jan 28 16:43:33 2011 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 28 Jan 2011 16:43:33 -0800 Subject: [Live-devel] TS file with high VBR Message-ID: >> - Or: use the index file to store current frame BR (so use >>the actual BR of a frame instead of an average based on past frames) > >Yes, for Transport Stream files for which we have pre-computed an >index file, we do - in principle - have enough 'future' information >(using PCR values) from which we could compute a more accurate >'duration' for each outgoing Transport Stream packet. In the past I >had considered modifying "MPEG2TransportStreamFramer" to use this >information, but didn't (because such a solution would work only for >Transport Stream files for which we have index files, whereas the >existing code works for any Transport Stream data). > >However, because - as you noted - excessively VBR streams are more >likely to be a problem with H.264 Transport Streams, I think I'll >take another look at this, to see if we can use the index file - >when present - to generate more accurate Transport Stream >'durations'. As promised, I looked into whether it would be feasible to do this (use the index file to compute more accurate 'durations' for each outgoing RTP packet, when streaming an indexed Transport Stream file. (When streaming from a non-indexed file, or a live stream, the existing code would continue to be used.) I came up with a solution that would work, but decided not to check it in, because I'm not convinced that it would be a good idea, for several reasons: 1/ My solution changes the format of the index file (to add a new 'duration per transport packet' field). Old index files would no longer work, which means that everyone would have to reindex all of their Transport Stream files. (Also, index files would become about 36% bigger.) 2/ While streaming a Transport Stream file, the server would also need to read the whole of its corresponding index file, leading to an almost 10% overhead in file system reads. 3/ Although we would now know more accurate 'durations' for each outgoing packet, we would still need to adjust these using some 'fudge factors' (tuning parameters), because otherwise we'd often end up seeing 'buffer underflow' at the receivers (due to network jitter, for example). (So the new scheme would not eliminate the 'fudge factors' present in the current scheme.) 4/ For highly VBR files, this new solution - by computing more accurate 'durations' for each outgoing packet - would end up generating an output network packet stream that's more bursty than the current scheme (which works by computing a weighted average duration). This would potentially lead to more network congestion (and possibly more packet loss). Therefore, my current thinking is that it's probably best to retain the existing scheme, even though its tuning parameters ('fudge factors') sometimes need to be tweaked in special circumstances. (I could potentially still be convinced otherwise, though. But right now I don't plan to change the existing "MPEG2TransportStreamFramer" implementation.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tonelli.francesco82 at gmail.com Thu Jan 27 03:55:07 2011 From: tonelli.francesco82 at gmail.com (Francesco Tonelli) Date: Thu, 27 Jan 2011 12:55:07 +0100 Subject: [Live-devel] rtp retransmission? Message-ID: Hi, I'm playing with live555 RTSP server and trying some its test applications. I have looked at the code of the server and openRTSP client, but I'm a beginner of C++, so it's not easy.. I would like to implement (in C++) an RTP retransmission mechanism of loss packets between the server and the client. I explain better my scenario: I would like that the stream arrive in *unicast* mode to the client and *at the same time* arrive to a fixed size buffer (retransmission buffer) that store all the packets (the retransmission buffer should be phisically located in the same place as the RTSP server, so I suppose to have no losses between the streaming server and the retransmission buffer..) When the client (which also has got its own buffer) detects a loss in the stream, sends a NACK to the retransmission buffer asking for the retransmission using a separate channel from the original one.. *I thought to implement it in this way: - Create the buffer using a simple circular buffer: I have created a simple queue with two pointers to store the "elements", that are the RTP packets defined with an appropriate class.. - Create a server-client socket that communicate each other and then creating a "thread" that allow the communication between the socket and the buffer, both on the server side and client side of course..* *I would like to know if there is the possibility to do all this just modifying somehow the RTSPserver and openRTSP* instead of creating everything from scratch... I hope I was clear and someone can help me.. Any suggestion is very appreciated, thanks! Francesco -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sat Jan 29 00:16:02 2011 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 29 Jan 2011 00:16:02 -0800 Subject: [Live-devel] testOnDemandRTSPServer always stream audio/MPA and video/MPV ? In-Reply-To: References: Message-ID: >I'm seeing something that I consider weird. There's nothing "weird" about this. The diagnostic output is quite clear about what the software is doing (or more precisely, is not doing) in this case. >Warning: We don't implement a QuickTime Video Media Data Type for >the "MPV" track, so we'll insert a dummy "????" Media Data Atom >instead. A separate, codec-specific editing pass will be needed >before this track can be played. Our "QuickTimeFileSink" code (which implements the writing of ".mov" and ".mp4" files) currently doesn't include a mechanism for properly storing MPEG-1 or 2 video or audio tracks. (It supports several other codecs - including MPEG-4 and H.264 video, and MPEG-4 (AAC), PCM, GSM and QCELP audio - but not (yet) MPEG-1 or 2 video or audio. >My question is, what do I need to do to stream a mpg file and then >be able to open it with openRTSP and obtain a valid .mov file? You would need to update the "QuickTimeFileSink" code to implement MPEG-1 or 2 video and audio. If you do this, feel free to contribute a patch. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From korpal28 at gmail.com Mon Jan 31 01:25:36 2011 From: korpal28 at gmail.com (korpal) Date: Mon, 31 Jan 2011 10:25:36 +0100 Subject: [Live-devel] RTSP H264 frame inversion Message-ID: Hi Live555 Team, I have some problems with the H264 and RTSP streaming. In fact, I acquire videos from some cameras, I compress them in H264 with the CUDA encoder (CQP rate control), and then I stream them in RTSP through the Live555 lib. My problem is that the result stream looks disturbed in VLC. I think that P and B frames are inverted, or in other word that the video is played in DTS order instead of PTS order ( IPBBIPBB... instead of IBBPIBBP...). I do some tests that will confirm my idea. Notably, I try to set the IDR period in the encoding part to 1 (I frame only), and so it works good. If I save my ES in a video container with ffmpeg (avi, mks,...), my video is OK, so I think that my NAL packets are OK too. I join to this email a test.x264 file to give you an example. I worked all the last week on this problem, and I didn't find an acceptable solution. It would be great if you can help me. Regards, St?phane -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.264 Type: application/octet-stream Size: 2048902 bytes Desc: not available URL: From finlayson at live555.com Mon Jan 31 02:23:07 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 31 Jan 2011 02:23:07 -0800 Subject: [Live-devel] RTSP H264 frame inversion In-Reply-To: References: Message-ID: >I join to this email a test.x264 file to give you an example. I notice that VLC cannot play this file at all (i.e., just reading it as a file, not as a stream). Therefore, I think your first step should be to figure out why VLC can't play this file. (Only then should you worry about why VLC's having trouble playing the stream.) Unfortunately this is not something that we can help you with. Instead, you should ask about this using the "vlc at vldeolan.org" mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From edi87 at fibertel.com.ar Mon Jan 31 06:20:02 2011 From: edi87 at fibertel.com.ar (edi87 at fibertel.com.ar) Date: Mon, 31 Jan 2011 11:20:02 -0300 Subject: [Live-devel] RTSP H264 frame inversion Message-ID: <23e3d76d1d1d.4d469ae2@fibertel.com.ar> Ross, Thanks for your answer. I understand what you say, after sending that mail I start checking the 'stream process' and I found the codecs problems and also why it's using always MPA/MPV. My question now changes, I need to stream a video+audio file, I have a .mpg file but I can convert it to any other format with any codec that fit the QuickTimeFileSink object. You mentioned MPEG4 video and AAC audio, suppose I convert my video to use those codecs, then how can I stream that video+audio file? I ask this because testOnDemandRTSPServer will not help, and also testMPEG4VideoStreamer too. So, is there any way to stream a MPEG4+AAC file with live555? and should openRTSP open that stream and create a .mov file correctly? I will start reading about add MPEG-1 or 2 support to QuickTimeFileSink. Thanks in advance, Jonathan ----- Mensaje original ----- De: Ross Finlayson Fecha: Lunes, Enero 31, 2011 7:23 am Asunto: Re: [Live-devel] RTSP H264 frame inversion > >I join to this email a test.x264 file to give you an example. > > I notice that VLC cannot play this file at all (i.e., just reading > it > as a file, not as a stream). Therefore, I think your first step > should be to figure out why VLC can't play this file. (Only then > should you worry about why VLC's having trouble playing the stream.) > > Unfortunately this is not something that we can help you with. > Instead, you should ask about this using the "vlc at vldeolan.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 > From edi87 at fibertel.com.ar Mon Jan 31 06:21:07 2011 From: edi87 at fibertel.com.ar (edi87 at fibertel.com.ar) Date: Mon, 31 Jan 2011 11:21:07 -0300 Subject: [Live-devel] RTSP H264 frame inversion Message-ID: <26fd60f34231.4d469b23@fibertel.com.ar> Guys, sorry about the mail sent before, my webmail client just mess up the mails and replied wrong one. Please sorry! ----- Mensaje original ----- De: Ross Finlayson Fecha: Lunes, Enero 31, 2011 7:23 am Asunto: Re: [Live-devel] RTSP H264 frame inversion > >I join to this email a test.x264 file to give you an example. > > I notice that VLC cannot play this file at all (i.e., just reading > it > as a file, not as a stream). Therefore, I think your first step > should be to figure out why VLC can't play this file. (Only then > should you worry about why VLC's having trouble playing the stream.) > > Unfortunately this is not something that we can help you with. > Instead, you should ask about this using the "vlc at vldeolan.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 > From edi87 at fibertel.com.ar Mon Jan 31 06:24:43 2011 From: edi87 at fibertel.com.ar (edi87 at fibertel.com.ar) Date: Mon, 31 Jan 2011 11:24:43 -0300 Subject: [Live-devel] testOnDemandRTSPServer always stream audio/MPA and video/MPV ? Message-ID: <394a0507358c.4d469bfb@fibertel.com.ar> Ross, Thanks for your answer. I understand what you say, after sending that mail I start checking the 'stream process' and I found the codecs problems and also why it's using always MPA/MPV. My question now changes, I need to stream a video+audio file, I have a .mpg file but I can convert it to any other format with any codec that fit the QuickTimeFileSink object. You mentioned MPEG4 video and AAC audio, suppose I convert my video to use those codecs, then how can I stream that video+audio file? I ask this because testOnDemandRTSPServer will not help, neither testMPEG4VideoStreamer. So, is there any way to stream a MPEG4+AAC file with live555? and should openRTSP open that stream and create a .mov file correctly? I will start reading about add MPEG-1 or 2 support to QuickTimeFileSink. Thanks in advance, Jonathan >I'm seeing something that I consider weird. There's nothing "weird" about this. The diagnostic output is quite clear about what the software is doing (or more precisely, is not doing) in this case. >Warning: We don't implement a QuickTime Video Media Data Type for >the "MPV" track, so we'll insert a dummy "????" Media Data Atom >instead. A separate, codec-specific editing pass will be needed >before this track can be played. Our "QuickTimeFileSink" code (which implements the writing of ".mov" and ".mp4" files) currently doesn't include a mechanism for properly storing MPEG-1 or 2 video or audio tracks. (It supports several other codecs - including MPEG-4 and H.264 video, and MPEG-4 (AAC), PCM, GSM and QCELP audio - but not (yet) MPEG-1 or 2 video or audio. >My question is, what do I need to do to stream a mpg file and then >be able to open it with openRTSP and obtain a valid .mov file? You would need to update the "QuickTimeFileSink" code to implement MPEG-1 or 2 video and audio. If you do this, feel free to contribute a patch. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 31 07:17:14 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 31 Jan 2011 07:17:14 -0800 Subject: [Live-devel] testOnDemandRTSPServer always stream audio/MPA and video/MPV ? In-Reply-To: <394a0507358c.4d469bfb@fibertel.com.ar> References: <394a0507358c.4d469bfb@fibertel.com.ar> Message-ID: >So, is there any way to stream a MPEG4+AAC file with live555? No, we currently do not have code for demultiplexing a ".mp4" or ".mov"-format file. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From sven.wasmer at gmail.com Mon Jan 31 04:06:45 2011 From: sven.wasmer at gmail.com (Sven Wasmer) Date: Mon, 31 Jan 2011 13:06:45 +0100 Subject: [Live-devel] RTSP H264 frame inversion In-Reply-To: References: Message-ID: 2011/1/31 Ross Finlayson : >> I join to this email a test.x264 file to give you an example. [...] > I notice that VLC cannot play this file at all (i.e., just reading it as a > file, not as a stream). [...] ... VLC does not recognize the filesuffix ".x264" it has to be ".h264". changing the filename and trying again should work. But I have the same problems when streaming h264 to VLC. It looks pretty much like a bug in their part. I have written the display part myself and it works. VLC doesn't. cheers Sven From korpal28 at gmail.com Mon Jan 31 04:33:00 2011 From: korpal28 at gmail.com (korpal) Date: Mon, 31 Jan 2011 13:33:00 +0100 Subject: [Live-devel] RTSP H264 frame inversion In-Reply-To: References: Message-ID: Hi Ross, Thanks for this fast answer. For me, it's correct that VLC cannot read the file, the file I sent you contains only NAL paquets (See joined screenshot with details), and so is not readable by VLC, correct me if I'm wrong. About DTS/PTS, is it possible that the presentation time is wrong? In regards of my code, I never give a presentation time from my device source (encoder in fact). But in debug, I saw that a presentation time is computed by the Live555 stream framer. Maybe did I forget to code something? Regards St?phane 2011/1/31 Ross Finlayson > I join to this email a test.x264 file to give you an example. >> > > I notice that VLC cannot play this file at all (i.e., just reading it as a > file, not as a stream). Therefore, I think your first step should be to > figure out why VLC can't play this file. (Only then should you worry about > why VLC's having trouble playing the stream.) > > Unfortunately this is not something that we can help you with. Instead, you > should ask about this using the "vlc at vldeolan.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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nal.png Type: image/png Size: 18377 bytes Desc: not available URL: From finlayson at live555.com Mon Jan 31 07:46:34 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 31 Jan 2011 07:46:34 -0800 Subject: [Live-devel] RTSP H264 frame inversion In-Reply-To: References: Message-ID: >2011/1/31 Ross Finlayson : >>> I join to this email a test.x264 file to give you an example. >[...] >> I notice that VLC cannot play this file at all (i.e., just reading it as a >> file, not as a stream). >[...] > >... VLC does not recognize the filesuffix ".x264" it has to be ".h264". >changing the filename and trying again should work. No, in this case it didn't (I checked). >But I have the same problems when streaming h264 to VLC. It looks >pretty much like a bug in their part. >I have written the display part myself and it works. VLC doesn't. A reminder once again: VLC decoding/displaying problems need to be reported on the "vlc at videolan.org" mailing list, not this one. We have nothing to do with how VLC decodes and displays incoming data. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From edi87 at fibertel.com.ar Mon Jan 31 07:53:13 2011 From: edi87 at fibertel.com.ar (edi87 at fibertel.com.ar) Date: Mon, 31 Jan 2011 12:53:13 -0300 Subject: [Live-devel] testOnDemandRTSPServer always stream audio/MPA and video/MPV ? Message-ID: <25c0a0902b0d.4d46b0b9@fibertel.com.ar> I see, so I'm not able to almost modify the rtspserver to use MPEG4ES and MPEG4GENERIC? I mean to take testMPEG4ESVideoTest and aacAudioTest to make one stream that openRTSP can convert to .mov? ----- Mensaje original ----- De: Ross Finlayson Fecha: Lunes, Enero 31, 2011 12:17 pm Asunto: Re: [Live-devel] testOnDemandRTSPServer always stream audio/MPA and video/MPV ? > >So, is there any way to stream a MPEG4+AAC file with live555? > > No, we currently do not have code for demultiplexing a ".mp4" or > ".mov"-format 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 > From finlayson at live555.com Mon Jan 31 11:09:11 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 31 Jan 2011 11:09:11 -0800 Subject: [Live-devel] RTSP H264 frame inversion In-Reply-To: References: Message-ID: >Thanks for this fast answer. For me, it's correct that VLC cannot >read the file, the file I sent you contains only NAL paquets (See >joined screenshot with details), and so is not readable by VLC, >correct me if I'm wrong. I don't know why your file is not readable by VLC. You'll need to ask a VLC mailing list about that. >About DTS/PTS, is it possible that the presentation time is wrong? >In regards of my code, I never give a presentation time from my >device source (encoder in fact). But in debug, I saw that a >presentation time is computed by the Live555 stream framer. Maybe >did I forget to code something? Yes, your input device object should be setting the "fPresentationTime" field in its implementation of "doGetNextFrame()", when it delivers each NAL unit. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From dli at Cernium.com Mon Jan 31 15:23:14 2011 From: dli at Cernium.com (Dunling Li) Date: Mon, 31 Jan 2011 18:23:14 -0500 Subject: [Live-devel] iPhone CAN"T play the TS files generated by testH264VideoToTransportStream Message-ID: <03A2FA9E0D3DC841992E682BF528771802C9A7D1@lipwig.Cernium.local> Dear all, I use testH264VideoToTransportStream to generate some TS files. None of them can be played in iPhone. The live streaming validator shows the following error: ERROR: Invalid media segment: The validator helper exited due to a fatal error: segment duration is not finite. Can anyone point me how to fix this problem? Thanks Dunling Cernium Corporation 1925 Isaac Newton Square, suite 300 Reston, VA 20190 Email: dli at cernium.com Phone: (703) 483-3387 Fax: (703) 483-3380 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michalk at awpi.com Mon Jan 31 15:05:40 2011 From: michalk at awpi.com (Brian Michalk) Date: Mon, 31 Jan 2011 17:05:40 -0600 Subject: [Live-devel] Simple Filter leading to a CODEC Message-ID: <4D474044.4030806@awpi.com> I want to eventually write a codec, which actually is the easiest part about getting something running. It works in MATLAB for still frames. I figure the first step is to figure out how to integrate into someone elses framework. I've looked at GStreamer, and it seems simple enough, but I just can't seem to get a new node working there. So, I'm looking into the Live framework, mostly because I want to encode and send data over RTP, which appears to have a lot of support here. My code takes a YUV image and filters that image (works in MATLAB), then I hope to encode that and send it via RTP to a client that does the reverse. For a simple proof of concept, I would like to just take in a video stream, increment the chrominance plane and plop that back out to a file. If I can do this much in source code, I know I can implement the rest of my codec. Is there an example for this? I've started down the path of using the MPEG1or2VideoRTPSink* files as a reference. Is this the right path to take, or is there a better way? From finlayson at live555.com Mon Jan 31 17:28:46 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 31 Jan 2011 17:28:46 -0800 Subject: [Live-devel] iPhone CAN"T play the TS files generated by testH264VideoToTransportStream In-Reply-To: <03A2FA9E0D3DC841992E682BF528771802C9A7D1@lipwig.Cernium.local> References: <03A2FA9E0D3DC841992E682BF528771802C9A7D1@lipwig.Cernium.local> Message-ID: >I use testH264VideoToTransportStream to generate some TS files. None >of them can be played in iPhone. The live streaming validator shows >the following error: > >ERROR: Invalid media segment: The validator helper exited due to a >fatal error: segment duration is not finite. > >Can anyone point me how to fix this problem? That seems unlikely, considering that: 1/ You didn't provide (or post a link to) a single ".264" file that illustrates your problem. 2/ You didn't say what software (on the iPhone) you are using to try to play the resulting TS file. 3/ Perhaps you meant to say that you are trying to *stream* the TS file to the iPhone (rather than trying to play the file on the iPhone)? If that's the case, you didn't say what software you are using as a server (to stream your file). 4/ You didn't say what "the live streaming validator" is. 5/ You didn't say what "the live streaming validator"s documentation (or online support forums or mailing lists) had to say about the meaning of the error message that you saw. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 31 18:38:56 2011 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 31 Jan 2011 18:38:56 -0800 Subject: [Live-devel] Simple Filter leading to a CODEC In-Reply-To: <4D474044.4030806@awpi.com> References: <4D474044.4030806@awpi.com> Message-ID: You're getting a little ahead of yourself here. First, you need to tell us what codec you wish to stream (via RTP). This will tell us whether or not there is a RTP payload format defined for that codec, and whether or not we already implement that RTP payload format. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/