From havthanh at gmail.com Tue Jul 1 00:41:50 2008 From: havthanh at gmail.com (Hannah) Date: Tue, 1 Jul 2008 15:41:50 +0800 Subject: [Live-devel] Queries about live555 Streaming Media Message-ID: Hi I'm trying to compile the live555 Streaming Media packet on Linux. I have 2 problems and can't find the solution in the FAQ. So I wrote to ask. Hope you will reply to me :) 1. When I compile the source code package, I follow the instructions that : - extract the package to a folder, then type the command : *cd home/hannah/Documents* . This is the folder contains the "live". - After that I create the makefile by the command : *./genMakefiles linux. * But I got the error *"new line".* So I can't proceed further. (can't * "make"* ) What's the problem when I create Makefile? I search google to find answer, but can't find it. Any modifications I should make before compiling the package? (I have the gcc compiler already). 2. I have one idea that, like the Bittorrent, I will have a server (tracker) and clients connect together, but I will not need to wait for it to finish downloading, but I just wait for it to buffer, then play. - Can I use live555 Streaming Media package to do that? - If yes, it means I will need to create a database for server, to track down which client got which file and need which file? How can I create database? - Can I let 2 clients connect together? Like client 1 got file A, client 2 need that file, can I let the 2 clients connect and take the file it need? (for example use openRSTP client). If yes, how can I connect them? This is just the idea. But I don't know how to implement. Hope you will reply to me. Thank you very much Have a nice day. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 1 01:04:28 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 1 Jul 2008 01:04:28 -0700 Subject: [Live-devel] Queries about live555 Streaming Media In-Reply-To: References: Message-ID: >1. When I compile the source code package, I follow the instructions that : > - extract the package to a folder, then type the command : >cd home/hannah/Documents . This is the folder contains the "live". You need to cd *into* the "live" directory itself. Then run "./genMakefiles linus", and then "make". >2. I have one idea that, like the Bittorrent, I will have a server >(tracker) and clients connect together, but I will not need to wait >for it to finish downloading, but I just wait for it to buffer, then >play. > - Can I use live555 Streaming Media package to do that? I'm sorry, I don't understand your question, but I suspect that you might not fully understand what our software does. After buildng the software, you should first familiarize yourself with the various demo applications (in the "testProgs" directory). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.bala at DSP-Weuffen.de Tue Jul 1 01:58:15 2008 From: kumar.bala at DSP-Weuffen.de (Kumar Bala (DSP-Weuffen GmbH)) Date: Tue, 01 Jul 2008 10:58:15 +0200 Subject: [Live-devel] Stream errors with MPEG 4 ES In-Reply-To: <3060C4D2411C46EAB765785D7E8FB407@DSPWeuffen.local> References: <48691F5D.1030609@larus.com> <3060C4D2411C46EAB765785D7E8FB407@DSPWeuffen.local> Message-ID: <4869F1A7.6020108@dsp-weuffen.de> Hello, I use the testOnDemandRTSPServer to stream live video (captured using an analog camera and encoded to MPEG 4 ES using a co-processor). I use ByteFileStreamSource.cpp in (ASYNCHRONOUS mode) as a base model for my device. I have modified doReadFromFile in such a way that it reurns an MPEG 4 frame from the "codec engine"(capture device + mpeg 4 encoder). I am having problems with the BANK_SIZE defined in StreamParser.cpp. Since I keep on reading from the codec engine and filling data untill BANK_SIZE (am I right ???) . When I reach the boundary (around BANK_SIZE) and I read X bytes and if adding X bytes would exceeed BANK_SIZE I end up with an error (and a visible glitch) at the decoder (mplayer compiled with LIVE555 support and MAX_RTP_FRAME_SIZE increased to 100000). Here is the output at the mplayer end: [mpeg4 @ 0x889a290]Error at MB: 89 [mpeg4 @ 0x889a290]concealing 1584 DC, 1584 AC, 1584 MV errors [mpeg4 @ 0x889a290]ac-tex damaged at 20 17 [mpeg4 @ 0x889a290]Error at MB: 802 [mpeg4 @ 0x889a290]concealing 884 DC, 884 AC, 884 MV errors [mpeg4 @ 0x889a290]ac-tex damaged at 12 22 Here is the debug output(newly added) at the Server end, ---------------------- ByteCount exceeded ---------------------- bufferSize = 79020 byteCount = 9954316 ---------------------- ByteCount exceeded ---------------------- bufferSize = 13086 byteCount = 999549 and the explanation: bufferSize - size of frame returned by the codec engine. byteCount - current amount of bytes I have filled into "fTo" buffer What should I do to ignore the last frames since they exceed BANK_SIZE ? or my understanding of the problem is flawed ?. I can stream videos with really low latency using live555 server. The only glitch I have now is there error happening once in 30 sec or so. Any suggestion on how to fix this would be of great help. Mit freundlichen Gr??en / Best regards Kumar Bala From ferreat at gmail.com Tue Jul 1 01:44:21 2008 From: ferreat at gmail.com (=?ISO-8859-1?Q?Fernando_Re=E1tegui_del_Aguila?=) Date: Tue, 1 Jul 2008 10:44:21 +0200 Subject: [Live-devel] MPEG4 not elementary Message-ID: Hello, I wanted to ask if there is anyone who have managed to write some code for streamming (like the example testMPEG4Streammer) MPEG4 files (not the elementary) and wouldn't mind to share. I have tried the example with the elementary files and it works fine, but I would like to stream normal mp4 files. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 1 02:58:13 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 1 Jul 2008 02:58:13 -0700 Subject: [Live-devel] Stream errors with MPEG 4 ES In-Reply-To: <4869F1A7.6020108@dsp-weuffen.de> References: <48691F5D.1030609@larus.com> <3060C4D2411C46EAB765785D7E8FB407@DSPWeuffen.local> <4869F1A7.6020108@dsp-weuffen.de> Message-ID: >I use the testOnDemandRTSPServer to stream live video (captured using >an analog camera and encoded to MPEG 4 ES using a co-processor). I use >ByteFileStreamSource.cpp in (ASYNCHRONOUS mode) as a base model for my >device. I have modified doReadFromFile in such a way that it reurns an >MPEG 4 frame from the "codec engine"(capture device + mpeg 4 encoder). Because your input device returns discrete MPEG-4 video frames, rather than a byte stream, it'd be better if you used "MPEG4VideoStreamDiscreteFramer", rather than "MPEG4VideoStreamFramer". However, your first test should have been using the *unmodified* source code - to stream from a MPEG-4 Video Elementary Stream *file*. I.e., you should have first created a file "test.m4e" - from the output of your encoder - and then tried streaming this, using the *unmodified* "testOnDemandRTSPServer" (or "testMPEG4VideoStreamer") application. (In general, once you've modified the supplied code, you can't expect to get much support on this mailing list.) I suspect that perhaps the output from your encoder is not in the proper form - i.e., not a true MPEG-4 Video Elementary Stream. If you this may be true, then please put your "test.m4e" file on a web server, and send us the URL, so we can download and test this for ourselves. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jul 1 03:04:25 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 1 Jul 2008 03:04:25 -0700 Subject: [Live-devel] Stream errors with MPEG 4 ES In-Reply-To: References: <48691F5D.1030609@larus.com> <3060C4D2411C46EAB765785D7E8FB407@DSPWeuffen.local> <4869F1A7.6020108@dsp-weuffen.de> Message-ID: Oops, I omitted a word from my previous answer: >I suspect that perhaps the output from your encoder is not in the >proper form - i.e., not a true MPEG-4 Video Elementary Stream. If >you think >this may be true, then please put your "test.m4e" file on a web >server, and send us the URL, so we can download and test this for >ourselves. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From lroels at hotmail.com Tue Jul 1 03:15:31 2008 From: lroels at hotmail.com (Luc Roels) Date: Tue, 1 Jul 2008 10:15:31 +0000 Subject: [Live-devel] client disconnect Message-ID: Hi, I would like to be able to let the client survive a 15 second ethernet cable disconnect when streaming over TCP! Where exactly in the code would I have to make modifications to make this happen? I suspect the problem lies with trying to send RTCP packets? best regards, Luc _________________________________________________________________ Start een boeiend online leven...helemaal gratis! http://get.live.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 1 03:27:58 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 1 Jul 2008 03:27:58 -0700 Subject: [Live-devel] client disconnect In-Reply-To: References: Message-ID: >Hi, > >I would like to be able to let the client survive a 15 second >ethernet cable disconnect when streaming over TCP! Where exactly in >the code would I have to make modifications to make this happen? I >suspect the problem lies with trying to send RTCP packets? No, I suspect the problem lies with your operating system - it's probably responsible for closing the TCP connection in this case. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kumar.bala at DSP-Weuffen.de Tue Jul 1 06:08:51 2008 From: kumar.bala at DSP-Weuffen.de (Kumar Bala (DSP-Weuffen GmbH)) Date: Tue, 01 Jul 2008 15:08:51 +0200 Subject: [Live-devel] Stream errors with MPEG 4 ES In-Reply-To: <5C69458A5E3E432BA079B216625DCB33@DSPWeuffen.local> References: <48691F5D.1030609@larus.com><3060C4D2411C46EAB765785D7E8FB407@DSPWeuffen.local><4869F1A7.6020108@dsp-weuffen.de> <5C69458A5E3E432BA079B216625DCB33@DSPWeuffen.local> Message-ID: <486A2C63.5040906@dsp-weuffen.de> >> Because your input device returns discrete MPEG-4 video frames, rather than a byte stream, it'd be better if you used "MPEG4VideoStreamDiscreteFramer", rather than "MPEG4VideoStreamFramer". That did the trick, I streamed for 30 min without one single error !!! Thanks a ton. Mit freundlichen Gr??en / Best regards Kumar Bala (Software Developer and System Designer) DSP-Weuffen Software/Hardware f?r DSP- und MCP-Konzeption und Optimierung ihres Systems DSP-Weuffen GmbH Schomburger Strasse 11 88279 Amtzell Tel: +49 7520 / 96673 - 146 Fax: +49 7520 / 96673 - 124 Mail: kumar.bala at dsp-weuffen.de Web: http://www.dsp-weuffen.de Gesch?ftsf?hrer: Dieter Weuffen | Amtsgericht 89014 ULM | HR-NR: HRB621135 Bitte beachten Sie, dass diese E-Mail einschlie?lich aller eventuell angeh?ngten Dokumente vertrauliche und/oder rechtlich gesch?tzte Informationen enthalten kann. Der Inhalt ist ausschlie?lich f?r den bezeichneten Adressaten bestimmt. Wenn Sie nicht der richtige Adressat oder dessen Vertreter sind, setzen Sie sich bitte mit dem Absender der E-Mail in Verbindung und l?schen Sie die E-Mail sofort. Jede Form der Verwendung, Ver?ffentlichung, Vervielf?ltigung oder Weitergabe des Inhalts fehlgeleiteter E-Mails ist unzul?ssig. Ross Finlayson wrote: >> I use the testOnDemandRTSPServer to stream live video (captured using >> an analog camera and encoded to MPEG 4 ES using a co-processor). I use >> ByteFileStreamSource.cpp in (ASYNCHRONOUS mode) as a base model for my >> device. I have modified doReadFromFile in such a way that it reurns an >> MPEG 4 frame from the "codec engine"(capture device + mpeg 4 encoder). > > Because your input device returns discrete MPEG-4 video frames, rather > than a byte stream, it'd be better if you used > "MPEG4VideoStreamDiscreteFramer", rather than "MPEG4VideoStreamFramer". > > However, your first test should have been using the *unmodified* > source code - to stream from a MPEG-4 Video Elementary Stream *file*. > I.e., you should have first created a file "test.m4e" - from the > output of your encoder - and then tried streaming this, using the > *unmodified* "testOnDemandRTSPServer" (or "testMPEG4VideoStreamer") > application. (In general, once you've modified the supplied code, you > can't expect to get much support on this mailing list.) > > I suspect that perhaps the output from your encoder is not in the > proper form - i.e., not a true MPEG-4 Video Elementary Stream. If you > this may be true, then please put your "test.m4e" file on a web > server, and send us the URL, so we can download and test this for > ourselves. From erik at hovland.org Tue Jul 1 08:49:16 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 1 Jul 2008 08:49:16 -0700 Subject: [Live-devel] [patch] places where unsigned causes code to do nothing Message-ID: <20080701154915.GA8561@hovland.org> Sometimes the type can do funny things. In this patch using unsigned as a type means that testing against less then zero or >= 0 has no effect. E --- liveMedia/InputFile.cpp | 2 +- liveMedia/OnDemandServerMediaSubsession.cpp | 2 +- liveMedia/SIPClient.cpp | 2 +- liveMedia/include/InputFile.hh | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/liveMedia/InputFile.cpp b/liveMedia/InputFile.cpp index bf92ab1..39ab953 100644 --- a/liveMedia/InputFile.cpp +++ b/liveMedia/InputFile.cpp @@ -78,7 +78,7 @@ u_int64_t GetFileSize(char const* fileName, FILE* fid) { return fileSize; } -u_int64_t SeekFile64(FILE *fid, int64_t offset, int whence) { +int64_t SeekFile64(FILE *fid, int64_t offset, int whence) { clearerr(fid); fflush(fid); #if (defined(__WIN32__) || defined(_WIN32)) && !defined(_WIN32_WCE) diff --git a/liveMedia/OnDemandServerMediaSubsession.cpp b/liveMedia/OnDemandServerMediaSubsession.cpp index 4ef058e..b95bd00 100644 --- a/liveMedia/OnDemandServerMediaSubsession.cpp +++ b/liveMedia/OnDemandServerMediaSubsession.cpp @@ -313,7 +313,7 @@ void OnDemandServerMediaSubsession::deleteStream(unsigned clientSessionId, } // Delete the "StreamState" structure if it's no longer being used: - if (streamState != NULL && streamState->referenceCount() >= 0) { + if (streamState != NULL) { if (streamState->referenceCount() > 0) --streamState->referenceCount(); if (streamState->referenceCount() == 0) { delete streamState; diff --git a/liveMedia/SIPClient.cpp b/liveMedia/SIPClient.cpp index 73db7c0..a6cb8c3 100644 --- a/liveMedia/SIPClient.cpp +++ b/liveMedia/SIPClient.cpp @@ -458,7 +458,7 @@ unsigned SIPClient::getResponseCode() { char* firstLine = NULL; char* nextLineStart = NULL; unsigned bytesRead = getResponse(readBuf, readBufSize); - if (bytesRead < 0) break; + if (bytesRead == 0) break; if (fVerbosityLevel >= 1) { envir() << "Received INVITE response: " << readBuf << "\n"; } diff --git a/liveMedia/include/InputFile.hh b/liveMedia/include/InputFile.hh index 3f4207a..905905f 100644 --- a/liveMedia/include/InputFile.hh +++ b/liveMedia/include/InputFile.hh @@ -31,7 +31,7 @@ void CloseInputFile(FILE* fid); u_int64_t GetFileSize(char const* fileName, FILE* fid); // 0 means zero-length, unbounded, or unknown -u_int64_t SeekFile64(FILE *fid, int64_t offset, int whence); +int64_t SeekFile64(FILE *fid, int64_t offset, int whence); // A platform-independent routine for seeking within (possibly) large files u_int64_t TellFile64(FILE *fid); -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From erik at hovland.org Tue Jul 1 08:51:50 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 1 Jul 2008 08:51:50 -0700 Subject: [Live-devel] [patch] add name to typedef and reveal function parameter Message-ID: <20080701155150.GB8561@hovland.org> When using typedef it is not required that the typedef be given a name. But the compiler doesn't have to work as hard if you do. Also, a function parameter can be hidden by a declaration within the function itself. The two attached patches address these problems. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- A non-text attachment was scrubbed... Name: missing-typedef-name.patch Type: text/x-diff Size: 572 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: function-parameter-hidden.patch Type: text/x-diff Size: 1076 bytes Desc: not available URL: From finlayson at live555.com Tue Jul 1 14:36:20 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 1 Jul 2008 14:36:20 -0700 Subject: [Live-devel] [patch] add name to typedef and reveal function parameter In-Reply-To: <20080701155150.GB8561@hovland.org> References: <20080701155150.GB8561@hovland.org> Message-ID: Thanks. These fixes (and the ones in your previous message) will be included in the next release of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ratin3 at gmail.com Tue Jul 1 15:18:43 2008 From: ratin3 at gmail.com (Ratin) Date: Tue, 1 Jul 2008 15:18:43 -0700 Subject: [Live-devel] Windows media player Message-ID: <5c70701a0807011518g7bd84d6bq656100c98cd6b7a8@mail.gmail.com> Did anybody have any success streaming and playing mpeg4 files streamed via live555's mediaserver? -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at hovland.org Tue Jul 1 16:21:40 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 1 Jul 2008 16:21:40 -0700 Subject: [Live-devel] [patch] null check before dereferencing Message-ID: <20080701232140.GA10475@hovland.org> In the member function SIPClient::getResponseCode the pointer nextLineStart might be null when it is assigned to bodyStart, then bodyStart might be used in an equation (where the calculated value will now be off). E --- liveMedia/SIPClient.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/liveMedia/SIPClient.cpp b/liveMedia/SIPClient.cpp index a6cb8c3..91a34ef 100644 --- a/liveMedia/SIPClient.cpp +++ b/liveMedia/SIPClient.cpp @@ -549,7 +549,7 @@ unsigned SIPClient::getResponseCode() { // the "Content-length:" header (if any) that we saw. We may need to // read more data, or we may have extraneous data in the buffer. char* bodyStart = nextLineStart; - if (contentLength >= 0) { + if (bodyStart != NULL && contentLength >= 0) { // We saw a "Content-length:" header unsigned numBodyBytes = &readBuf[bytesRead] - bodyStart; if (contentLength > (int)numBodyBytes) { -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From erik at hovland.org Tue Jul 1 16:23:38 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 1 Jul 2008 16:23:38 -0700 Subject: [Live-devel] [patch] remove some unused code in qtfilesink Message-ID: <20080701232338.GB10475@hovland.org> The qt file sink class has some unused code in it. This patch removes it. --- liveMedia/QuickTimeFileSink.cpp | 9 --------- 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/liveMedia/QuickTimeFileSink.cpp b/liveMedia/QuickTimeFileSink.cpp index 6e4c997..29bef25 100644 --- a/liveMedia/QuickTimeFileSink.cpp +++ b/liveMedia/QuickTimeFileSink.cpp @@ -529,7 +529,6 @@ Boolean SubsessionIOState::setQTstate() { char const* noCodecWarning1 = "Warning: We don't implement a QuickTime "; char const* noCodecWarning2 = " Media Data Type for the \""; char const* noCodecWarning3 = "\" 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.\n"; - Boolean supportPartiallyOnly = False; do { fQTEnableTrack = True; // enable this track in the movie by default @@ -622,14 +621,6 @@ Boolean SubsessionIOState::setQTstate() { break; } - if (supportPartiallyOnly) { - envir() << "Warning: We don't have sufficient codec-specific information (e.g., sample sizes) to fully generate the \"" - << fOurSubsession.mediumName() << "/" - << fOurSubsession.codecName() - << "\" track, so we'll disable this track in the movie. A separate, codec-specific editing pass will be needed before this track can be played\n"; - fQTEnableTrack = False; // disable this track in the movie - } - return True; } while (0); -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From erik at hovland.org Tue Jul 1 16:25:28 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 1 Jul 2008 16:25:28 -0700 Subject: [Live-devel] [patch] remove unused null check and delete in JPEGVideoRTPSource.cpp Message-ID: <20080701232528.GC10475@hovland.org> The function JPEGVideoRTPSource has a null check and delete for qtables. But qtables is guaranteed to be null at this point. So the check and the delete are not necessary. --- liveMedia/JPEGVideoRTPSource.cpp | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/liveMedia/JPEGVideoRTPSource.cpp b/liveMedia/JPEGVideoRTPSource.cpp index 6a63a03..25e4981 100644 --- a/liveMedia/JPEGVideoRTPSource.cpp +++ b/liveMedia/JPEGVideoRTPSource.cpp @@ -394,8 +394,6 @@ Boolean JPEGVideoRTPSource if (packetSize < resultSpecialHeaderSize + Length) return False; - if (qtables) delete [] qtables; - qtlen = Length; qtables = &headerStart[resultSpecialHeaderSize]; -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From finlayson at live555.com Tue Jul 1 16:27:46 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 1 Jul 2008 16:27:46 -0700 Subject: [Live-devel] [patch] null check before dereferencing In-Reply-To: <20080701232140.GA10475@hovland.org> References: <20080701232140.GA10475@hovland.org> Message-ID: Thanks. I'm curious - how are you finding all of these issues/bugs? Are you running some tool (like "valgrind") that reports them, or have you just been inspecting the code by hand? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From SRawling at pelco.com Wed Jul 2 10:42:53 2008 From: SRawling at pelco.com (Rawling, Stuart) Date: Wed, 02 Jul 2008 10:42:53 -0700 Subject: [Live-devel] Dynamic Server URL's In-Reply-To: Message-ID: Hi Guys, I am making great progress on my dynamic rtsp server, but had a question regarding the url format. My server parses the url (overriding the lookupServerMediaSession) when a connection comes in, and if necessary bootstraps a new stream. The stream comes from a network camera or network video recorder. I would like to use advanced urls such as: rtsp://serverip:port/stream?deviceId=3&startTime=t1&endTime=t2 Reading through the RTSP RFC it seems that the standard should allow me to do this: ? The path components of the RTSP URL are opaque to the client and do not imply any particular file system structure for the server. This decoupling also allows presentation descriptions to be used with non-RTSP media control protocols simply by replacing the scheme in the URL.? I believe the track control would be done by appending the trackid at the end: rtsp://serverip:port/stream?deviceId=3&startTime=t1&endTime=t2/track1 Do you know if live555 allow me to use urls in this format? Stuart - ------------------------------------------------------------------------------ Confidentiality Notice: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual(s) or entities named above. This email and any files transmitted with it are the property of Pelco. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you receive this communication in error, please notify us immediately by telephone call to +1-559-292-1981 or forward the e-mail to administrator at pelco.com and then permanently delete the e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation. - ------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 2 14:56:41 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 2 Jul 2008 14:56:41 -0700 Subject: [Live-devel] Dynamic Server URL's In-Reply-To: References: Message-ID: >Do you know if live555 allow me to use urls in this format? Yes, the code will pass the complete URL suffix (including the 'parameter' parts) to "lookupServerMediaSession()", so your implementation of that routine can do what it likes with that string. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From chordis at getwellnetwork.com Wed Jul 2 17:51:52 2008 From: chordis at getwellnetwork.com (Charles R. Hordis) Date: Wed, 2 Jul 2008 20:51:52 -0400 Subject: [Live-devel] server-initiated messages in RTSP client Message-ID: <200807022051.52245.chordis@getwellnetwork.com> I'm looking for a way to handle server-initiated RTSP messages such as GET_PARAMETER in VLC using Live555 for it's RTSP client. As far as I can tell from looking at the code, Live555 only handles server responses, but I could easily have missed something among the the client-initiated GET_PARAMETER code. Does Live555 client handle any server-initiated messages? If it does, could you point me to some of the code that handles it? If it doesn't, are there any hints you could give me about where I could start on implementing it? Thanks, Charles Hordis P.S. It's an RTSP standard. (RFC2326, sec 1.1, "Both an RTSP server and client can issue requests.", in the list of differences from HTTP; also see GET_PARAMETER example). -- GetWellNetwork, Inc. Charles Hordis * Senior Software Engineer 7920 Norfolk Avenue * 10th Floor * Bethesda, MD ?20814 mobile 267-992-2328 chordis at getwellnetwork.com www.getwellnetwork.com From finlayson at live555.com Wed Jul 2 20:11:16 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 2 Jul 2008 20:11:16 -0700 Subject: [Live-devel] server-initiated messages in RTSP client In-Reply-To: <200807022051.52245.chordis@getwellnetwork.com> References: <200807022051.52245.chordis@getwellnetwork.com> Message-ID: >I'm looking for a way to handle server-initiated RTSP messages such as >GET_PARAMETER in VLC using Live555 for it's RTSP client. As far as I can >tell from looking at the code, Live555 only handles server responses, but I >could easily have missed something among the the client-initiated >GET_PARAMETER code. > >Does Live555 client handle any server-initiated messages? No (and such functionality could not be added until the RTSP client implementation is rewritten to use asynchrous I/O). >P.S. It's an RTSP standard. (RFC2326, sec 1.1, "Both an RTSP server and >client can issue requests." Yes, however having a client handle server-initiated requests is optional functionality, and few - if any - RTSP client implementations actually handle this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yamini.s at europlex.in Thu Jul 3 02:09:38 2008 From: yamini.s at europlex.in (Yamini S. [EPLX - DCC]) Date: Thu, 3 Jul 2008 14:39:38 +0530 Subject: [Live-devel] (no subject) References: Message-ID: <6872DF21E3D09046BDF172721037F4FB3F04DE@SBTEXCHANGEDB.sbtdats.com> Hi, I am trying to develop my own player to stream RTP using vlc and Can one let me know I to compile and debug the source code in VC++ Thanks & Regards, S.Yamini Programmer R&D Siemens Building Technologies Pvt. Ltd. This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. You may not copy, disclose or use the contents in any way. SBTPL does not guarantee integrity of this communication nor is that this communication free of issues, interceptions or interference. This communication does not create or modify any contract, and unless otherwise stated, is not intended to be contractually binding. Views or opinions expressed in this e-mail message are those of the author only. From yamini.s at europlex.in Thu Jul 3 02:11:23 2008 From: yamini.s at europlex.in (Yamini S. [EPLX - DCC]) Date: Thu, 3 Jul 2008 14:41:23 +0530 Subject: [Live-devel] Need help in streaming RTP References: Message-ID: <6872DF21E3D09046BDF172721037F4FB3F04DF@SBTEXCHANGEDB.sbtdats.com> Hi, I am trying to develop my own player to stream RTP using vlc and Can one let me know I to compile and debug the source code in VC++ Thanks & Regards, S.Yamini Programmer R&D Siemens Building Technologies Pvt. Ltd. This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. You may not copy, disclose or use the contents in any way. SBTPL does not guarantee integrity of this communication nor is that this communication free of issues, interceptions or interference. This communication does not create or modify any contract, and unless otherwise stated, is not intended to be contractually binding. Views or opinions expressed in this e-mail message are those of the author only. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 3 03:22:20 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 3 Jul 2008 03:22:20 -0700 Subject: [Live-devel] Need help in streaming RTP In-Reply-To: <6872DF21E3D09046BDF172721037F4FB3F04DF@SBTEXCHANGEDB.sbtdats.com> References: <6872DF21E3D09046BDF172721037F4FB3F04DF@SBTEXCHANGEDB.sbtdats.com> Message-ID: Please do not send the same question to the mailing list more than once! Questions about compiling VLC should be sent to a VLC mailing list! (Note, BTW, that the VLC web site has pre-built binary versions of VLC for many platforms - including Windows - so you can just download that, instead of trying to build your own version.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From 47manzoor at niit.edu.pk Thu Jul 3 03:52:13 2008 From: 47manzoor at niit.edu.pk (47manzoor at niit.edu.pk) Date: Thu, 3 Jul 2008 15:52:13 +0500 (PKT) Subject: [Live-devel] H.264VideoReceiver Message-ID: <43829.202.125.157.194.1215082333.squirrel@webmail.niit.edu.pk> I have modified the testMPEG1or2VideoReceiver to H.264VideoReceiver and it works i.e receives H.264 RTP packets and dumps to a file. but i want to store the received data in a buffer so that my decoder decodes it. Can some one guide me in doing so? i want just a rough idea. Thank You ----------- --Help save paper - do you really need to print this email? This message is for the use of the intended recipient(s) only. If you have received this message in error, please notify the sender and delete it. The NUST School of Electrical Engg and Computer Science accepts no liability for loss or damage caused by software viruses and you are advised to carry out a virus check on any attachments contained in this message. NUST School of Electrical Engg and Computer Science (Formerly NIIT) is constituent institution of National University of Sciences and Technology, Pakistan. ------- From yamini.s at europlex.in Thu Jul 3 04:08:16 2008 From: yamini.s at europlex.in (Yamini S. [EPLX - DCC]) Date: Thu, 3 Jul 2008 16:38:16 +0530 Subject: [Live-devel] Need help in streaming RTP References: <6872DF21E3D09046BDF172721037F4FB3F04DF@SBTEXCHANGEDB.sbtdats.com> Message-ID: <6872DF21E3D09046BDF172721037F4FB3F0526@SBTEXCHANGEDB.sbtdats.com> Thanks for ur reply. I use openRTSP to receive the RTP data and store in mpeg4 file but That file does not play in any player. Can I know How to play that mpeg4 file Thanks & Regards, S.Yamini Programmer R&D Siemens Building Technologies Pvt. Ltd. -----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, July 03, 2008 3:52 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Need help in streaming RTP Please do not send the same question to the mailing list more than once! Questions about compiling VLC should be sent to a VLC mailing list! (Note, BTW, that the VLC web site has pre-built binary versions of VLC for many platforms - including Windows - so you can just download that, instead of trying to build your own version.) -- 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 This message (including attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. You may not copy, disclose or use the contents in any way. SBTPL does not guarantee integrity of this communication nor is that this communication free of issues, interceptions or interference. This communication does not create or modify any contract, and unless otherwise stated, is not intended to be contractually binding. Views or opinions expressed in this e-mail message are those of the author only. From ferreat at gmail.com Thu Jul 3 06:35:51 2008 From: ferreat at gmail.com (=?ISO-8859-1?Q?Fernando_Re=E1tegui_del_Aguila?=) Date: Thu, 3 Jul 2008 15:35:51 +0200 Subject: [Live-devel] Regarding RTP, UDP and MPEG4 Message-ID: Hello, I have sniffered the test program testMPEG4VideoStreamer and have realized that the video packets are encapsulated in UDP packets, or at least in that way they are showed in the Sniffer. When I sniffer a Siemens Video camera which multiplexes MPEG4 video into RTP packets, I see in the sniffer them in the sniffer info like RTP packets. I was wondering about why the difference. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 3 10:16:33 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 3 Jul 2008 10:16:33 -0700 Subject: [Live-devel] H.264VideoReceiver In-Reply-To: <43829.202.125.157.194.1215082333.squirrel@webmail.niit.edu.pk> References: <43829.202.125.157.194.1215082333.squirrel@webmail.niit.edu.pk> Message-ID: >I have modified the testMPEG1or2VideoReceiver to H.264VideoReceiver and it >works i.e receives H.264 RTP packets and dumps to a file. > >but i want to store the received data in a buffer so that my decoder >decodes it. Can some one guide me in doing so? i want just a rough idea. Write a new "MediaSink" subclass, and use that instead of "FileSink". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 3 10:50:11 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 3 Jul 2008 10:50:11 -0700 Subject: [Live-devel] Regarding RTP, UDP and MPEG4 In-Reply-To: References: Message-ID: > I have sniffered the test program testMPEG4VideoStreamer and have >realized that the video packets are encapsulated in UDP packets, or >at least in that way they are showed in the Sniffer. When I sniffer >a Siemens Video camera which multiplexes MPEG4 video into RTP >packets, I see in the sniffer them in the sniffer info like RTP >packets. I was wondering about why the difference. All of our "test*Streamer" applications transmit RTP packets, each of which is also a UDP packet. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From silvain.beriault at larus.com Thu Jul 3 13:09:04 2008 From: silvain.beriault at larus.com (Silvain Beriault) Date: Thu, 03 Jul 2008 16:09:04 -0400 Subject: [Live-devel] Proper cleanup of live555 instances Message-ID: <486D31E0.7050306@larus.com> Hello, I have written an application similar to testMPEG1or2VideoStreamer.cpp but within a larger application. Therefore, I need to perform some cleanup to avoid memory leaks. Here is what I currently allocate (in that same order): TaskScheduler *scheduler; BasicUsageEnvironment *env; RTPSink *sink; RTCPInstance *rtcp; FramedSource *framedSource; here is currently how I currently cleanup: sink->stopPlaying(); Medium::close(framedSource); Medium::close(sink); <== crashes env->reclaim(); Here are my questions: 1. Overall what should be the full cleanup sequence for that example? 2. Do I need to "delete scheduler" or env->reclaim() does that 3. Why Medium::close(sink) crashes? (is it already being cleaned up by Medium::close(framedSource) ?) 4. How to cleanup RTCPInstance ? Thank you Silvain From finlayson at live555.com Thu Jul 3 16:16:20 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 3 Jul 2008 16:16:20 -0700 Subject: [Live-devel] Proper cleanup of live555 instances In-Reply-To: <486D31E0.7050306@larus.com> References: <486D31E0.7050306@larus.com> Message-ID: >here is currently how I currently cleanup: > >sink->stopPlaying(); >Medium::close(framedSource); >Medium::close(sink); <== crashes >env->reclaim(); > >Here are my questions: > >1. Overall what should be the full cleanup sequence for that example? I'm not sure why you got a crash, but try closing the sink *before* closing the source. >2. Do I need to "delete scheduler" or env->reclaim() does that Yes, you should also call delete scheduler; just before calling env->reclaim(); >3. Why Medium::close(sink) crashes? I don't know. > (is it already being cleaned up by Medium::close(framedSource) ?) No. >4. How to cleanup RTCPInstance ? Call Medum::close(rtcp); just before closing the sink. Note that, in general, you should destroy objects in the reverse order from that in which you create them. So try: sink->stopPlaying(); Medum::close(rtcp); Medium::close(sink); Medium::close(framedSource); delete scheduler; env->reclaim(); -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kumar.bala at DSP-Weuffen.de Fri Jul 4 00:36:26 2008 From: kumar.bala at DSP-Weuffen.de (Kumar Bala (DSP-Weuffen GmbH)) Date: Fri, 04 Jul 2008 09:36:26 +0200 Subject: [Live-devel] Need help in streaming RTP In-Reply-To: <658C678C5ABF498C840971E6F4C9CFCF@DSPWeuffen.local> References: <6872DF21E3D09046BDF172721037F4FB3F04DF@SBTEXCHANGEDB.sbtdats.com> <658C678C5ABF498C840971E6F4C9CFCF@DSPWeuffen.local> Message-ID: <486DD2FA.5030301@dsp-weuffen.de> Hello Yamini, You can play that using mplayer. http://www.mplayerhq.hu/design7/dload.html I am assuming the file name would look like video-MP4V-ES Or you can play it using vnc, but just rename the file filename.m4v f you intention is to play the file and dump it tinto a file you can do that by using mplayer Mit freundlichen Gr??en / Best regards Kumar Bala From silvain.beriault at larus.com Fri Jul 4 08:33:32 2008 From: silvain.beriault at larus.com (Silvain Beriault) Date: Fri, 04 Jul 2008 11:33:32 -0400 Subject: [Live-devel] Proper cleanup of live555 instances In-Reply-To: References: <486D31E0.7050306@larus.com> Message-ID: <486E42CC.1040706@larus.com> Ross Finlayson wrote: >> here is currently how I currently cleanup: >> >> sink->stopPlaying(); >> Medium::close(framedSource); >> Medium::close(sink); <== crashes >> env->reclaim(); >> >> Here are my questions: >> >> 1. Overall what should be the full cleanup sequence for that example? > > I'm not sure why you got a crash, but try closing the sink *before* > closing the source. > > >> 2. Do I need to "delete scheduler" or env->reclaim() does that > > Yes, you should also call > delete scheduler; > just before calling > env->reclaim(); > > >> 3. Why Medium::close(sink) crashes? > > I don't know. > >> (is it already being cleaned up by Medium::close(framedSource) ?) > > No. > > >> 4. How to cleanup RTCPInstance ? > > Call > Medum::close(rtcp); > just before closing the sink. > > Note that, in general, you should destroy objects in the reverse order > from that in which you create them. So try: > sink->stopPlaying(); > Medum::close(rtcp); > Medium::close(sink); > Medium::close(framedSource); > delete scheduler; > env->reclaim(); Thank you, This cleanup sequence is working fine. From erik at hovland.org Fri Jul 4 13:27:37 2008 From: erik at hovland.org (Erik Hovland) Date: Fri, 4 Jul 2008 13:27:37 -0700 Subject: [Live-devel] [patch] getc returns int, using char truncates value Message-ID: <20080704202737.GA6873@hovland.org> Getc and all of the char I/O calls return an int. When a char is used to store that return value then the return value is truncated. Since all it takes to get the true value is to change the variable type that is storing the returned value, that is what this patch does. E --- liveMedia/WAVAudioFileSource.cpp | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/liveMedia/WAVAudioFileSource.cpp b/liveMedia/WAVAudioFileSource.cpp index 595cff6..e80d5c7 100644 --- a/liveMedia/WAVAudioFileSource.cpp +++ b/liveMedia/WAVAudioFileSource.cpp @@ -78,7 +78,7 @@ unsigned char WAVAudioFileSource::getAudioFormat() { #define ucEOF ((unsigned char)EOF) static Boolean get4Bytes(FILE* fid, unsigned& result) { // little-endian - unsigned char c0, c1, c2, c3; + int c0, c1, c2, c3; if ((c0 = nextc) == ucEOF || (c1 = nextc) == ucEOF || (c2 = nextc) == ucEOF || (c3 = nextc) == ucEOF) return False; result = (c3<<24)|(c2<<16)|(c1<<8)|c0; @@ -86,7 +86,7 @@ static Boolean get4Bytes(FILE* fid, unsigned& result) { // little-endian } static Boolean get2Bytes(FILE* fid, unsigned short& result) {//little-endian - unsigned char c0, c1; + int c0, c1; if ((c0 = nextc) == ucEOF || (c1 = nextc) == ucEOF) return False; result = (c1<<8)|c0; return True; @@ -157,7 +157,7 @@ WAVAudioFileSource::WAVAudioFileSource(UsageEnvironment& env, FILE* fid) if (!skipBytes(fid, formatLength - 16)) break; // FACT chunk (optional): - unsigned char c = nextc; + int c = nextc; if (c == 'f') { if (nextc != 'a' || nextc != 'c' || nextc != 't') break; unsigned factLength; -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From erik at hovland.org Fri Jul 4 13:30:03 2008 From: erik at hovland.org (Erik Hovland) Date: Fri, 4 Jul 2008 13:30:03 -0700 Subject: [Live-devel] [patch] minor mem leaks in RTSP client and server (and qtfilesink) Message-ID: <20080704203003.GB6873@hovland.org> These patches only fix corner cases of memory leaks. But they should be fairly non-invasive. So please consider them. Thanks E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- A non-text attachment was scrubbed... Name: rtspclient-mem-leaks.patch Type: text/x-diff Size: 2032 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rtspserver-mem-leaks.patch Type: text/x-diff Size: 1606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qtfilesink-mem-leak.patch Type: text/x-diff Size: 583 bytes Desc: not available URL: From finlayson at live555.com Fri Jul 4 21:07:57 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 4 Jul 2008 21:07:57 -0700 Subject: [Live-devel] [patch] minor mem leaks in RTSP client and server (and qtfilesink) In-Reply-To: <20080704203003.GB6873@hovland.org> References: <20080704203003.GB6873@hovland.org> Message-ID: >These patches only fix corner cases of memory leaks. But they should be >fairly non-invasive. So please consider them. Thanks. I have now released a new version (2008.07.05) of the software that includes all of your recent suggestions. If possible, please rerun your testing tools on this new version. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From erik at hovland.org Fri Jul 4 22:52:56 2008 From: erik at hovland.org (Erik Hovland) Date: Fri, 4 Jul 2008 22:52:56 -0700 Subject: [Live-devel] [patch] minor mem leaks in RTSP client and server (and qtfilesink) In-Reply-To: References: <20080704203003.GB6873@hovland.org> Message-ID: <20080705055256.GE6873@hovland.org> On Fri, Jul 04, 2008 at 09:07:57PM -0700, Ross Finlayson wrote: >> These patches only fix corner cases of memory leaks. But they should be >> fairly non-invasive. So please consider them. > > Thanks. I have now released a new version (2008.07.05) of the software > that includes all of your recent suggestions. If possible, please rerun > your testing tools on this new version. Will do. Thanks E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From erik at hovland.org Sat Jul 5 12:18:35 2008 From: erik at hovland.org (Erik Hovland) Date: Sat, 5 Jul 2008 12:18:35 -0700 Subject: [Live-devel] [patch] minor mem leaks in RTSP client and server (and qtfilesink) In-Reply-To: <20080705055256.GE6873@hovland.org> References: <20080704203003.GB6873@hovland.org> <20080705055256.GE6873@hovland.org> Message-ID: <20080705191835.GA9096@hovland.org> On Fri, Jul 04, 2008 at 10:52:56PM -0700, Erik Hovland wrote: > On Fri, Jul 04, 2008 at 09:07:57PM -0700, Ross Finlayson wrote: > >> These patches only fix corner cases of memory leaks. But they should be > >> fairly non-invasive. So please consider them. > > > > Thanks. I have now released a new version (2008.07.05) of the software > > that includes all of your recent suggestions. If possible, please rerun > > your testing tools on this new version. > > Will do. Did do. For some reason the RTSPServer memory leaks fix did not quite get in. Here is the same patch against 2008.07.05. E --- liveMedia/RTSPServer.cpp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/liveMedia/RTSPServer.cpp b/liveMedia/RTSPServer.cpp index 24b5c34..65b8830 100644 --- a/liveMedia/RTSPServer.cpp +++ b/liveMedia/RTSPServer.cpp @@ -809,8 +809,8 @@ void RTSPServer::RTSPClientSession break; } } - delete[] destAddrStr; delete[] sourceAddrStr; delete[] streamingModeString; } + delete[] destAddrStr; delete[] sourceAddrStr; delete[] streamingModeString; } void RTSPServer::RTSPClientSession -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From nomiya at galaxy.dti.ne.jp Sun Jul 6 00:02:36 2008 From: nomiya at galaxy.dti.ne.jp (Masaru Nomiya) Date: Sun, 06 Jul 2008 16:02:36 +0900 Subject: [Live-devel] compile error under openSUSE 11.0 Message-ID: <874p73fqb7.wl%nomiya@galaxy.dti.ne.jp> Hello, Since I upgraded to openSUSE 11.0, I get an error message; [...] c++ -olive555MediaServer -L. live555MediaServer.o DynamicRTSPServer.o ../liveMedia/libliveMedia.a ../groupsock/libgroupsock.a ../UsageEnvironment/libUsageEnvironment.a ../BasicUsageEnvironment/libBasicUsageEnvironment.a /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: error in ../liveMedia/libliveMedia.a(.eh_frame); no .eh_frame_hdr table will be created. make[1]: Leaving directory `/tmp/source/live/mediaServer' How can I solve this problem? [My environment] 1. OS : openSUSE 11.0 Linux linux-rc0h 2.6.25.5-1.1-default #1 SMP 2008-06-07 01:55:22 +0200 x86_64 x86_64 x86_64 GNU/Linux 2. libc : /lib64/libc-2.8.so 3. gcc : gcc (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] 4. ld : GNU ld (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1 5. as : GNU assembler (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1 6. make : GNU Make 3.81 7. sed : GNU sed version 4.1.5 8. awk : GNU Awk 3.1.5h Thanks in adavance, Regards, --- Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp "Bill! You married with Computers. Not with Me!" "No..., with money." From AidenYuan at coomosoft.com Sun Jul 6 20:33:48 2008 From: AidenYuan at coomosoft.com (Aiden_Coomo) Date: Mon, 7 Jul 2008 11:33:48 +0800 Subject: [Live-devel] H.264VideoReceiver In-Reply-To: References: <43829.202.125.157.194.1215082333.squirrel@webmail.niit.edu.pk> Message-ID: <001901c8dfe2$4496de00$9909a8c0@shuweiyuan> HI, Ross! I joined in live555 several days ago, Just now, I saw http://www.live555.com/liveMedia/doxygen/html/classMedium.html. It seems that I can write a new "MediaSink" if I want to add new receiver in client. if I try to support new media type in server, How about? Add a MultiFramedRTPSink,right? Would you mind introducing steps simply about how to support a new media type in server? Thanks. -----????----- ???: Ross Finlayson [mailto:finlayson at live555.com] ????: 2008?7?4? 1:17 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] H.264VideoReceiver >I have modified the testMPEG1or2VideoReceiver to H.264VideoReceiver and it >works i.e receives H.264 RTP packets and dumps to a file. > >but i want to store the received data in a buffer so that my decoder >decodes it. Can some one guide me in doing so? i want just a rough idea. Write a new "MediaSink" subclass, and use that instead of "FileSink". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From AidenYuan at coomosoft.com Sun Jul 6 20:33:48 2008 From: AidenYuan at coomosoft.com (Aiden_Coomo) Date: Mon, 7 Jul 2008 11:33:48 +0800 Subject: [Live-devel] H.264VideoReceiver In-Reply-To: References: <43829.202.125.157.194.1215082333.squirrel@webmail.niit.edu.pk> Message-ID: <001901c8dfe2$4496de00$9909a8c0@shuweiyuan> HI, Ross! I joined in live555 several days ago, Just now, I saw http://www.live555.com/liveMedia/doxygen/html/classMedium.html. It seems that I can write a new "MediaSink" if I want to add new receiver in client. if I try to support new media type in server, How about? Add a MultiFramedRTPSink,right? Would you mind introducing steps simply about how to support a new media type in server? Thanks. -----????----- ???: Ross Finlayson [mailto:finlayson at live555.com] ????: 2008?7?4? 1:17 ???: LIVE555 Streaming Media - development & use ??: Re: [Live-devel] H.264VideoReceiver >I have modified the testMPEG1or2VideoReceiver to H.264VideoReceiver and it >works i.e receives H.264 RTP packets and dumps to a file. > >but i want to store the received data in a buffer so that my decoder >decodes it. Can some one guide me in doing so? i want just a rough idea. Write a new "MediaSink" subclass, and use that instead of "FileSink". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From AidenYuan at coomosoft.com Sun Jul 6 22:47:24 2008 From: AidenYuan at coomosoft.com (Aiden_Coomo) Date: Mon, 7 Jul 2008 13:47:24 +0800 Subject: [Live-devel] Maybe two bugs exist Message-ID: <001a01c8dff4$ee548570$9909a8c0@shuweiyuan> 1 live555MediaServer crashed when parsing .mpg I downloaded live.2008.06.05.tar.gz., and Compiled in Linux. Run "live/mediaServer/live555MediaServer", when I use .mpg to test live555MediaServer, it crashed. Test clients are QuickTime and Realplay 11 I add -DDEBUG macro, and get some logs "StreamParser internal error (85384+ 65541 > 150000)", it seems that the error happened in the StreamParser::ensureValidBytes1 2 In live\config.armlinux Line 7: CPLUSPLUS_COMPILER = $(CROSS_COMPILE)gcc -------> CPLUSPLUS_COMPILER = $(CROSS_COMPILE)g++ Line 10: LINK = $(CROSS_COMPILE)gcc -o ------> LINK = $(CROSS_COMPILE)g++ -o -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 6 22:57:49 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 6 Jul 2008 22:57:49 -0700 Subject: [Live-devel] H.264VideoReceiver In-Reply-To: <001901c8dfe2$4496de00$9909a8c0@shuweiyuan> References: <43829.202.125.157.194.1215082333.squirrel@webmail.niit.edu.pk> <001901c8dfe2$4496de00$9909a8c0@shuweiyuan> Message-ID: >Would you mind introducing steps simply about how to support a new media >type in server? You will need: 1/ A new subclass of "MultiFramedRTPSink" for the particular RTP payload format that you wish to support 2/ A new class (or perhaps a chain of classes (source class + 'framer' (filter) class) that delivers discrete media frames (of the desired type) from some input source, setting an appropriate presentation time ("fPresentationTime") and frame duration ("fDurationInMicroseconds") for each frame. 3/ A new subclass of "ServerMediaSubsession" that creates, on demand, instances of 1/ and 2/ Note the several existing examples (for existing media types) in the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 7 00:01:37 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 7 Jul 2008 00:01:37 -0700 Subject: [Live-devel] Maybe two bugs exist In-Reply-To: <001a01c8dff4$ee548570$9909a8c0@shuweiyuan> References: <001a01c8dff4$ee548570$9909a8c0@shuweiyuan> Message-ID: >1 live555MediaServer crashed when parsing .mpg >I downloaded live.2008.06.05.tar.gz., and >Compiled in Linux. Run >"live/mediaServer/live555MediaServer", >when I use .mpg to test live555MediaServer, it >crashed. Test clients are QuickTime and Realplay >11 >I add -DDEBUG macro, and get some logs >"StreamParser internal error (85384+ 65541 > >150000)", it seems that the error happened in >the StreamParser::ensureValidBytes1 Pplease put your file on a web site, and send us the URL, so we can download and test it for ourselves. >2 In live\config.armlinux >Line 7: CPLUSPLUS_COMPILER = >$(CROSS_COMPILE)gcc -----? CPLUSPLUS_COMPILER = >$(CROSS_COMPILE)g++ >Line 10: LINK = >$(CROSS_COMPILE)gcc -o ----? LINK = >$(CROSS_COMPILE)g++ -o I see no bug report there. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From onramp123 at yahoo.com Mon Jul 7 14:18:32 2008 From: onramp123 at yahoo.com (Steve DeLaney) Date: Mon, 7 Jul 2008 14:18:32 -0700 Subject: [Live-devel] lightweight RTSP proxy server Message-ID: <00ed01c8e077$033a46a0$6b03a8c0@sdelaney2> First off, being new to liveMedia, I wanted to say what a great job was done on the design and code. Now on to the topic at hand. I am adapting testOnDemandRTSPServer to make a lightweight rtsp proxy. We already have ffmpeg streaming multicast MPEG4 over RTP, and generating an SDP file. Now all we need is an RTSP proxy to serve the SDP file. In this case it does not have to start the stream, since it is already present, nor is any port translation needed. So you can think of this as a RTSP control plane only proxy. initially it doesn't even need trick play control. the idea is to serve client DESCRIBE by opening the existing SDP file and returning it. I've looked over the RTSPServer.cpp and this looks like the likely place to make a patch. it appears *Subsession* components are dataplane oriented. So I assume changes at this level will probably not be needed, but maybe a stub Subsession type "stub" would be needed for addSubsession(stub...) I wanted to see if there was anything I might have overlooked that would simplify the task, and if we are headed down the right path here. I would appreciate your suggestions, comments, recommendations. Regards, Steve From laifa at astri.org Mon Jul 7 23:36:41 2008 From: laifa at astri.org (Fang Laifa) Date: Tue, 8 Jul 2008 14:36:41 +0800 Subject: [Live-devel] About RTSP over UDP behind firewall. Message-ID: Dear all, I am now studying RTSP playback the content from m.youtube.com using Mplayer/Live555. This is my testing environment: Ubuntu 7.0.4, Mplayer-1.0rc2, live.2008.07.06. rtsp-stream-over-tcp is enabled at first when trying to play rtsp://bfug.rtsp-youtube.l.google.com/Ci4LENy73wIaJQlajfjZ7w0SCxMYDSANFE IJbXYtZ29vZ2xlSARSB2RldGFpbHMM/0/0/0/video.3gp. However Mplayer reported "Unsupported Transport". It seems that the server from m.youtube.com could not support RTP over TCP. So rtsp-stream-over-tcp is disabled instead. Then Mplayer also failed to play the rtsp using RTP over UDP since my testing PC is behind my company's firewall. But the problem is that the real player can play the same rtsp without any problem, which is also on another pc behind the firewall. Both Mplayer and realplayer packets are captured using wireshark while playing the rtsp. The captured files realplayer_rtsp_m_youtube.cap and mplayer_rtsp_m_youtube.cap are attached FYR. From the captured packets, the real player also uses RTP over UDP. But it can actually go through the firewall. Also from realplayer_rtsp_m_youtube.cap, there are two RTP packets which are sent from my local PC (10.6.64.218) to m.youtube.com (72.14.209.177) before actual RTP/UDP packets receiving from youtube server. It seems that these two RTP packets with empty content triggered the firewall bypass. From mplayer_rtsp_m_youtube.cap, there are no such kind of triggered packets. So by my estimation, this is probably the reason that realplayer can bypass the firewall but mplayer cannot. So my question is that whether live55 have any plan to support similar mechanism with RTP over UDP to bypass the firewall? Another question regarding the packets from wireshark. I can find such warnings "Checksum: 0x65bf [incorrect, should be 0x60a6 (maybe caused by "TCP checksum offload"?)]" for some rtsp/tcp packets. Does anybody know what's the problem? Thanks. Rgds, Laifa ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: mplayer_rtsp_m_youtube.cap Type: application/octet-stream Size: 6138 bytes Desc: mplayer_rtsp_m_youtube.cap URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: realplayer_rtsp_m_youtube.cap Type: application/octet-stream Size: 13080 bytes Desc: realplayer_rtsp_m_youtube.cap URL: From havthanh at gmail.com Tue Jul 8 00:38:41 2008 From: havthanh at gmail.com (Hannah) Date: Tue, 8 Jul 2008 15:38:41 +0800 Subject: [Live-devel] Asking about live555 Media server Message-ID: Hi, I have some questions to ask. Hope someone answer me something. 1. I've built the live555MediaServer. It says that to stream from this server, simply type the URL like : rtsp://172.18.75.202:8554/ where is a file present in the current directory. Because I can't type the address rstp:// into the web browser, also don't have any server keep media files, so it means I must put a file with the supported file type in the same directory with live555MediaServer? I've tried a .mp3 file but the output is just a "<", nothing happens. 2. Stream from this server also means that, the server will play by itself, too? I don't need any client to play it? Because I see the openRSTP client and RSTP server in the streaming media source code, too. So what are the difference between live555MediaServer and RSTP server? 3.After I built the Streaming Media source code, how can I run the test programs? Sorry for asking those questions, just because I'm stuck in compiling and test the source code. Thanks a lot Hope to see your reply Hannah -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 8 00:10:59 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2008 00:10:59 -0700 Subject: [Live-devel] About RTSP over UDP behind firewall. In-Reply-To: References: Message-ID: > So my question is that whether live55 have any plan to support >similar mechanism with RTP over UDP to bypass the firewall? Yes, the IETF is currently working to standardize such a mechanism, and I plan on supporting this in our software once the standardization is complete (or close to complete). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jul 8 02:48:26 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2008 02:48:26 -0700 Subject: [Live-devel] Asking about live555 Media server In-Reply-To: References: Message-ID: >Because I can't type the address rstp:// into the web browser You can't play "rtsp://" URLs from (most) web browsers. Instead, you need a separate RTSP client application, like VLC >, also don't have any server keep media files, so it means I must >put a file with the supported file type in the same directory with >live555MediaServer? Yes. (Sorry, but I don't understand the rest of your questions.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ferreat at gmail.com Tue Jul 8 03:04:54 2008 From: ferreat at gmail.com (=?ISO-8859-1?Q?Fernando_Re=E1tegui_del_Aguila?=) Date: Tue, 8 Jul 2008 12:04:54 +0200 Subject: [Live-devel] MPEG4 hinted file for RTP Message-ID: Hello, I wanted to ask one question regarding RTP. I was able to get a file of a MPEG4 video already hinted for RTP. I wanted to ask how could I stream this file. Fernando. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 8 07:09:37 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2008 07:09:37 -0700 Subject: [Live-devel] MPEG4 hinted file for RTP In-Reply-To: References: Message-ID: >I wanted to ask one question regarding RTP. I was able to get a file >of a MPEG4 video already hinted for RTP. I wanted to ask how could I >stream this file. You need to use Apple's "Darwin Streaming Server". Our RTSP server implementation cannot currently stream such a file. (Note, once again, BTW, that 'hinting' is an Apple-specific hack, used only for streaming by the "Darwin Streaming Server".) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From erik at hovland.org Tue Jul 8 09:03:35 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 8 Jul 2008 09:03:35 -0700 Subject: [Live-devel] [patch] use const_cast instead of C casting Message-ID: <20080708160335.GA7110@hovland.org> In C++ it is preferred to control constness by using const_cast instead of the C casting syntax. This patch does that in a couple of places. E --- liveMedia/QuickTimeGenericRTPSource.cpp | 2 +- liveMedia/SimpleRTPSource.cpp | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/liveMedia/QuickTimeGenericRTPSource.cpp b/liveMedia/QuickTimeGenericRTPSource.cpp index eff16ea..4bbe5d3 100644 --- a/liveMedia/QuickTimeGenericRTPSource.cpp +++ b/liveMedia/QuickTimeGenericRTPSource.cpp @@ -74,7 +74,7 @@ QuickTimeGenericRTPSource QuickTimeGenericRTPSource::~QuickTimeGenericRTPSource() { delete[] qtState.sdAtom; - delete[] (char*)fMIMEtypeString; + delete[] const_cast(fMIMEtypeString); } Boolean QuickTimeGenericRTPSource diff --git a/liveMedia/SimpleRTPSource.cpp b/liveMedia/SimpleRTPSource.cpp index fcfdfb5..d41fe0b 100644 --- a/liveMedia/SimpleRTPSource.cpp +++ b/liveMedia/SimpleRTPSource.cpp @@ -49,7 +49,7 @@ SimpleRTPSource } SimpleRTPSource::~SimpleRTPSource() { - delete[] (char*)fMIMEtypeString; + delete[] const_cast(fMIMEtypeString); } Boolean SimpleRTPSource -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From erik at hovland.org Tue Jul 8 09:06:57 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 8 Jul 2008 09:06:57 -0700 Subject: [Live-devel] [patch] initialized member variables in ctor Message-ID: <20080708160657.GB7110@hovland.org> OK, now I am really starting to run out of issues. How do I know? Well, I am starting to produce the member variable initialization in constructor patches. These defects are just because it is good C++ practice to initialize member variables in the ctor of the class to make sure that these member variables are in a known state at instantiation. But they rarely turn into full blown bugs. So they usually come last in any audit of the code base. Next step after this is the compiler warnings patch (which I have also worked up). Anyhow, here is a patch which initializes member variables in the class ctor. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- A non-text attachment was scrubbed... Name: uninit-in-ctor.patch Type: text/x-diff Size: 23803 bytes Desc: not available URL: From erik at hovland.org Tue Jul 8 09:09:24 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 8 Jul 2008 09:09:24 -0700 Subject: [Live-devel] [patch] make sure string storage has enough room for the null char Message-ID: <20080708160924.GC7110@hovland.org> This patch is the one I am least comfortable with. I have no idea if the strings that are being created require a null char to terminate them. But to stimulate discussion I am posting the patches that do make sure there is room for the null char in a few strings where it seems it was no accounted for. Please let me know if I got this one wrong. I am happy to drop this patch. E --- liveMedia/RTSPClient.cpp | 4 ++-- liveMedia/ServerMediaSession.cpp | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/liveMedia/RTSPClient.cpp b/liveMedia/RTSPClient.cpp index 3d9eab1..b5bde5d 100644 --- a/liveMedia/RTSPClient.cpp +++ b/liveMedia/RTSPClient.cpp @@ -100,7 +100,7 @@ void RTSPClient::setUserAgentString(char const* userAgentStr) { // Change the existing user agent header string: char const* const formatStr = "User-Agent: %s\r\n"; - unsigned headerSize = strlen(formatStr) + strlen(userAgentStr); + unsigned headerSize = strlen(formatStr) + strlen(userAgentStr) + 1; delete[] fUserAgentHeaderStr; fUserAgentHeaderStr = new char[headerSize]; sprintf(fUserAgentHeaderStr, formatStr, userAgentStr); @@ -1979,7 +1979,7 @@ RTSPClient::createAuthenticatorString(Authenticator const* authenticator, sprintf(usernamePassword, "%s:%s", authenticator->username(), authenticator->password()); char* response = base64Encode(usernamePassword, usernamePasswordLength); - unsigned authBufSize = strlen(authFmt) + strlen(response); + unsigned authBufSize = strlen(authFmt) + strlen(response) + 1; authenticatorStr = new char[authBufSize]; sprintf(authenticatorStr, authFmt, response); delete[] response; delete[] usernamePassword; diff --git a/liveMedia/ServerMediaSession.cpp b/liveMedia/ServerMediaSession.cpp index be1efc7..cfe9ef3 100644 --- a/liveMedia/ServerMediaSession.cpp +++ b/liveMedia/ServerMediaSession.cpp @@ -195,7 +195,7 @@ char* ServerMediaSession::generateSDPDescription() { "a=source-filter: incl IN IP4 * %s\r\n" "a=rtcp-unicast: reflection\r\n"; unsigned sourceFilterFmtSize = strlen(sourceFilterFmt) - + ipAddressStrSize; + + ipAddressStrSize + 1; sourceFilterLine = new char[sourceFilterFmtSize]; sprintf(sourceFilterLine, sourceFilterFmt, -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From finlayson+mobile at live555.com Tue Jul 8 09:24:39 2008 From: finlayson+mobile at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2008 09:24:39 -0700 Subject: [Live-devel] [patch] use const_cast instead of C casting In-Reply-To: <20080708160335.GA7110@hovland.org> References: <20080708160335.GA7110@hovland.org> Message-ID: This is one patch that I won't be adding, because I want the code to work even with older compilers that might not understand "const_char" ( or even templates). Ross. ---------- Sent from my jesusPhone On Jul 8, 2008, at 9:03 AM, Erik Hovland wrote: > In C++ it is preferred to control constness by using const_cast > instead > of the C casting syntax. This patch does that in a couple of places. > > E > > --- > > liveMedia/QuickTimeGenericRTPSource.cpp | 2 +- > liveMedia/SimpleRTPSource.cpp | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/liveMedia/QuickTimeGenericRTPSource.cpp b/liveMedia/ > QuickTimeGenericRTPSource.cpp > index eff16ea..4bbe5d3 100644 > --- a/liveMedia/QuickTimeGenericRTPSource.cpp > +++ b/liveMedia/QuickTimeGenericRTPSource.cpp > @@ -74,7 +74,7 @@ QuickTimeGenericRTPSource > > QuickTimeGenericRTPSource::~QuickTimeGenericRTPSource() { > delete[] qtState.sdAtom; > - delete[] (char*)fMIMEtypeString; > + delete[] const_cast(fMIMEtypeString); > } > > Boolean QuickTimeGenericRTPSource > diff --git a/liveMedia/SimpleRTPSource.cpp b/liveMedia/ > SimpleRTPSource.cpp > index fcfdfb5..d41fe0b 100644 > --- a/liveMedia/SimpleRTPSource.cpp > +++ b/liveMedia/SimpleRTPSource.cpp > @@ -49,7 +49,7 @@ SimpleRTPSource > } > > SimpleRTPSource::~SimpleRTPSource() { > - delete[] (char*)fMIMEtypeString; > + delete[] const_cast(fMIMEtypeString); > } > > Boolean SimpleRTPSource > > -- > Erik Hovland > mail: erik at hovland.org > web: http://hovland.org/ > PGP/GPG public key available on request > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From erik at hovland.org Tue Jul 8 10:47:30 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 8 Jul 2008 10:47:30 -0700 Subject: [Live-devel] [patch] fix or suppress compiler warnings In-Reply-To: <20080708161301.GD7110@hovland.org> References: <20080708161301.GD7110@hovland.org> Message-ID: <20080708174730.GA16877@hovland.org> On Tue, Jul 08, 2008 at 09:13:01AM -0700, Erik Hovland wrote: > A lot of const char* = "" calls means that g++ complains about how that > feature is deprecated. As well as some casting and some changing of > function declarations (socketErr). This patch has been checked for > memory leaks since it almost always heap allocates a duplicate string > instead of the = "". But that doesn't mean I didn't screw it up. > > Anyhow, big patch. Any feedback is welcome. Too big of a patch. Resent after compressing. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler-warnings.patch.bz2 Type: application/octet-stream Size: 8706 bytes Desc: not available URL: From erik at hovland.org Tue Jul 8 10:48:13 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 8 Jul 2008 10:48:13 -0700 Subject: [Live-devel] [patch] use const_cast instead of C casting In-Reply-To: References: <20080708160335.GA7110@hovland.org> Message-ID: <20080708174813.GB16877@hovland.org> On Tue, Jul 08, 2008 at 09:24:39AM -0700, Ross Finlayson wrote: > This is one patch that I won't be adding, because I want the code to > work even with older compilers that might not understand "const_char" ( > or even templates). Not a problem. Thanks for the quick feedback. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From finlayson at live555.com Tue Jul 8 17:31:59 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2008 17:31:59 -0700 Subject: [Live-devel] [patch] fix or suppress compiler warnings In-Reply-To: <20080708174730.GA16877@hovland.org> References: <20080708161301.GD7110@hovland.org> <20080708174730.GA16877@hovland.org> Message-ID: >This patch has been checked for > > memory leaks since it almost always heap allocates a duplicate string > > instead of the = "". I see no reason not to continue to use static string constants. Copying them into heap-allocated memory instead (using "strDup()") is inefficient and pointless. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jul 8 18:06:32 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2008 18:06:32 -0700 Subject: [Live-devel] [patch] make sure string storage has enough room for the null char In-Reply-To: <20080708160924.GC7110@hovland.org> References: <20080708160924.GC7110@hovland.org> Message-ID: >This patch is the one I am least comfortable with. I have no idea if the >strings that are being created require a null char to terminate them. >But to stimulate discussion I am posting the patches that do make sure >there is room for the null char in a few strings where it seems it was >no accounted for. The existing code in each case was actually OK, because the format string contained sufficient extra characters (e.g., "%s") to allow sufficient space for the trailing '\0' character when you do the "sprintf()". However, because this still triggered your checking tools (and is a bit of a hack anyway), I went ahead and made your suggested changes (to add 1 to the buffer size). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From erik at hovland.org Tue Jul 8 19:20:26 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 8 Jul 2008 19:20:26 -0700 Subject: [Live-devel] [patch] fix or suppress compiler warnings In-Reply-To: References: <20080708161301.GD7110@hovland.org> <20080708174730.GA16877@hovland.org> Message-ID: <20080709022026.GA25786@hovland.org> On Tue, Jul 08, 2008 at 05:31:59PM -0700, Ross Finlayson wrote: >> This patch has been checked for >> > memory leaks since it almost always heap allocates a duplicate string >> > instead of the = "". > > I see no reason not to continue to use static string constants. Copying > them into heap-allocated memory instead (using "strDup()") is > inefficient and pointless. Understood. I'll submit a new patch that doesn't fix that. When gcc 4.4 and the feature is truly deprecated I can rework it. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From finlayson at live555.com Tue Jul 8 21:56:45 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 8 Jul 2008 21:56:45 -0700 Subject: [Live-devel] [patch] fix or suppress compiler warnings In-Reply-To: <20080709022026.GA25786@hovland.org> References: <20080708161301.GD7110@hovland.org> <20080708174730.GA16877@hovland.org> <20080709022026.GA25786@hovland.org> Message-ID: >On Tue, Jul 08, 2008 at 05:31:59PM -0700, Ross Finlayson wrote: >>> This patch has been checked for >>> > memory leaks since it almost always heap allocates a duplicate string >>> > instead of the = "". >> >> I see no reason not to continue to use static string constants. Copying >> them into heap-allocated memory instead (using "strDup()") is >> inefficient and pointless. > >Understood. I'll submit a new patch that doesn't fix that. When gcc 4.4 >and the feature is truly deprecated I can rework it. Perhaps what your compiler is really complaining about is the fact that these string constants are declared char* instead of char const* or char const* const Perhaps that's all that's needed to satisfy it? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From julien.savarese at dcnsgroup.com Wed Jul 9 05:39:19 2008 From: julien.savarese at dcnsgroup.com (julien.savarese at dcnsgroup.com) Date: Wed, 9 Jul 2008 14:39:19 +0200 Subject: [Live-devel] TestOnDemandeRTSP and live source Message-ID: <20080709123148.CBFD5804063@smtp-out2.dcn.fr> Hello, I want to stream a raw video comming from a live source. I have read on the FAQ, that I must modifie the OnDemandServerMediaSubsession , and in particular two pure virtual functions "createNewStreamSource()" and "createNewRTPSink()". I don't know what must I modifie and what is reusable to be able to stream a byteflow comming from my acqusition card. Thx. _________________________ Julien Savarese Apprenti ing?nieur. Division SIS/DPM/RMS/MIE. --------------------------------------------- Pensez a l'environnement : avez-vous besoin d'imprimer ce message Think Environment : Do you need to print message ? Ce courrier ?lectronique, et ?ventuellement ses pi?ces jointes, peuvent contenir des informations confidentielles et/ou personnelles et a ?t? envoy? uniquement ? l'usage de la personne ou de l'entit? cit?e ci-dessus. Si vous receviez ce courrier ?lectronique par erreur, merci de bien vouloir en avertir l'exp?diteur imm?diatement par la r?ponse en retour ? ce courrier et effacer l'original et d?truire toute copie enregistr?e dans un ordinateur, ou imprim?e ou encore sauvegard?e sur un disque . Toute revue, retransmission ou toute autre forme d'utilisation de ce courrier ?lectronique par toute autre personne que le destinataire pr?vue est strictement interdite. L'internet ne permettant pas d'assurer l'int?grit? de ce message, l'exp?diteur d?cline toute responsabilit? au cas o? il aurait ?t? intercept? ou modifi? par quiconque. This e-mail and possibly any attachment may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above. If you have received it in error, please advise the sender immediately by reply e-mail and delete and destroy all copies including all copies stored in the recipient's computer, printed or saved to disk. . Any review , retransmission, or further use of this e-mail by by persons or entities other than the intended recipient is strictly prohibited. Because of the nature of the Internet the sender is not in a position to ensure the integrity of this message, therefore the sender disclaims any liability whatsoever, in the event of this message having been intercepted and/or altered. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 9 05:59:56 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 9 Jul 2008 05:59:56 -0700 Subject: [Live-devel] TestOnDemandeRTSP and live source In-Reply-To: <20080709123148.CBFD5804063@smtp-out2.dcn.fr> References: <20080709123148.CBFD5804063@smtp-out2.dcn.fr> Message-ID: >Hello, > >I want to stream a raw video comming from a live source. >I have read on the FAQ, that I must modifie the >OnDemandServerMediaSubsession >, and in particular two pure virtual functions >"createNewStreamSource()" and "createNewRTPSink()". >I don't know what must I modifie and what is reusable to be able to >stream a byteflow comming from my acqusition card. What codec (i.e., video format) does your card generate? Also, are you sure that the device is not accessible as an open file? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.savarese at dcnsgroup.com Wed Jul 9 06:20:58 2008 From: julien.savarese at dcnsgroup.com (julien.savarese at dcnsgroup.com) Date: Wed, 9 Jul 2008 15:20:58 +0200 Subject: [Live-devel] TestOnDemandeRTSP and live source In-Reply-To: Message-ID: <20080709131327.30E0F804063@smtp-out2.dcn.fr> My card is not a encoding card, just a grabing card, so the byte are RGB data. So i don't think that any test*Stream passing /dev/video like input name works. _________________________ Julien Savarese Apprenti ing?nieur. Division SIS/DPM/RMS/MIE. --------------------------------------------- Ross Finlayson Envoy? par : live-devel-bounces at ns.live555.com 09/07/2008 14:59 Veuillez r?pondre ? LIVE555 Streaming Media - development & use A LIVE555 Streaming Media - development & use cc Objet Re: [Live-devel] TestOnDemandeRTSP and live source Hello, I want to stream a raw video comming from a live source. I have read on the FAQ, that I must modifie the OnDemandServerMediaSubsession , and in particular two pure virtual functions "createNewStreamSource()" and "createNewRTPSink()". I don't know what must I modifie and what is reusable to be able to stream a byteflow comming from my acqusition card. What codec (i.e., video format) does your card generate? Also, are you sure that the device is not accessible as an open 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 Pensez a l'environnement : avez-vous besoin d'imprimer ce message Think Environment : Do you need to print message ? Ce courrier ?lectronique, et ?ventuellement ses pi?ces jointes, peuvent contenir des informations confidentielles et/ou personnelles et a ?t? envoy? uniquement ? l'usage de la personne ou de l'entit? cit?e ci-dessus. Si vous receviez ce courrier ?lectronique par erreur, merci de bien vouloir en avertir l'exp?diteur imm?diatement par la r?ponse en retour ? ce courrier et effacer l'original et d?truire toute copie enregistr?e dans un ordinateur, ou imprim?e ou encore sauvegard?e sur un disque . Toute revue, retransmission ou toute autre forme d'utilisation de ce courrier ?lectronique par toute autre personne que le destinataire pr?vue est strictement interdite. L'internet ne permettant pas d'assurer l'int?grit? de ce message, l'exp?diteur d?cline toute responsabilit? au cas o? il aurait ?t? intercept? ou modifi? par quiconque. This e-mail and possibly any attachment may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above. If you have received it in error, please advise the sender immediately by reply e-mail and delete and destroy all copies including all copies stored in the recipient's computer, printed or saved to disk. . Any review , retransmission, or further use of this e-mail by by persons or entities other than the intended recipient is strictly prohibited. Because of the nature of the Internet the sender is not in a position to ensure the integrity of this message, therefore the sender disclaims any liability whatsoever, in the event of this message having been intercepted and/or altered. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at hovland.org Wed Jul 9 09:45:24 2008 From: erik at hovland.org (Erik Hovland) Date: Wed, 9 Jul 2008 09:45:24 -0700 Subject: [Live-devel] [patch] fix or suppress compiler warnings In-Reply-To: References: <20080708161301.GD7110@hovland.org> <20080708174730.GA16877@hovland.org> <20080709022026.GA25786@hovland.org> Message-ID: <20080709164524.GA25518@hovland.org> On Tue, Jul 08, 2008 at 09:56:45PM -0700, Ross Finlayson wrote: >> On Tue, Jul 08, 2008 at 05:31:59PM -0700, Ross Finlayson wrote: >>>> This patch has been checked for >>>> > memory leaks since it almost always heap allocates a duplicate string >>>> > instead of the = "". >>> >>> I see no reason not to continue to use static string constants. Copying >>> them into heap-allocated memory instead (using "strDup()") is >>> inefficient and pointless. >> >> Understood. I'll submit a new patch that doesn't fix that. When gcc 4.4 >> and the feature is truly deprecated I can rework it. > > Perhaps what your compiler is really complaining about is the fact that > these string constants are declared > char* > instead of > char const* > or > char const* const > > Perhaps that's all that's needed to satisfy it? Yeah, 90% of the time this is true. Here is a new patch that doesn't do strDup(). Instead it does the const/char* combo that is not deprecated (and it includes the change because of the deprecated strstream). There are still warnings because of the const/char* combo. But they are not has easily fixed. For these few would strDup() be accepted? For example in liveMedia/RTSPClient.cpp at or about line 849 there is the line: char* transportFmt; And then an if clause that has this a couple of times: transportFmt = "Transport: RAW/RAW/UDP%s%s%s=%d-%d\r\n"; This throws a compiler warning because this sort of assignment has been marked deprecated in C99 and C++. Thanks for the hint, the compiler warning patch is much more reasonable now. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- A non-text attachment was scrubbed... Name: compiler-warnings.patch Type: text/x-diff Size: 16533 bytes Desc: not available URL: From finlayson at live555.com Wed Jul 9 10:58:11 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 9 Jul 2008 10:58:11 -0700 Subject: [Live-devel] TestOnDemandeRTSP and live source In-Reply-To: <20080709131327.30E0F804063@smtp-out2.dcn.fr> References: <20080709131327.30E0F804063@smtp-out2.dcn.fr> Message-ID: >My card is not a encoding card, just a grabing card, so the byte are RGB data. So you would first need a filter class (a subclass of "FramedFilter") that encodes (compresses) each video frame using some appropriate codec. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From laifa at astri.org Wed Jul 9 19:13:08 2008 From: laifa at astri.org (Fang Laifa) Date: Thu, 10 Jul 2008 10:13:08 +0800 Subject: [Live-devel] About RTSP over UDP behind firewall. Message-ID: Dear Ross, Thanks for your reply. These days I have a google on such kind of technique. It seems that it was called "UDP hole punch". Could you please tell me which RFC is in progress on such kind of mechanism? Are there any draft standard now? I just wonder why youtube and realplayer can works well under no standards on that. Thanks. >> So my question is that whether live555 have any plan to support >> similar mechanism with RTP over UDP to bypass the firewall? > Yes, the IETF is currently working to standardize such a mechanism, > and I plan on supporting this in our software once the > standardization is complete (or close to complete). > -- > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ Rgds, Laifa ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From finlayson at live555.com Wed Jul 9 21:24:29 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 9 Jul 2008 21:24:29 -0700 Subject: [Live-devel] About RTSP over UDP behind firewall. In-Reply-To: References: Message-ID: > Thanks for your reply. These days I have a google on such kind of >technique. It seems that it was called "UDP hole punch". Could you >please tell me which RFC is in progress on such kind of mechanism? Are >there any draft standard now? I just wonder why youtube and realplayer >can works well under no standards on that. Thanks. This is still in a bit of flux. Various Internet Drafts have been submitted, but it's not clear yet what's going to go on the standards track. This work is being done in the IETF's "MMUSIC" working group, so any follow-up questions should go to that group's mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From soumya.patra at lge.com Thu Jul 10 03:17:17 2008 From: soumya.patra at lge.com (soumya patra) Date: Thu, 10 Jul 2008 15:47:17 +0530 Subject: [Live-devel] H264 SDP generation Message-ID: <20080710101717.AD60C558009@LGEMRELSE6Q.lge.com> Hi, I have created a h.264 unicast streamer using live555 streaming library. I have created my own H.264 video stream framer. Some issue is there with this approach, I have developed VideoServerMediaSubsession. In this when I am streaming without SDP it's streaming which I can receive with VLC client. But in another case when SDP line is there that is as follows: char const* H264VideoServerMediaSubsession ::getAuxSDPLine(RTPSink* rtpSink, FramedSource* inputSource) { fDummyRTPSink = rtpSink; fDummyRTPSink->startPlaying(*inputSource, afterPlayingDummy, this); checkForAuxSDPLine(this); envir().taskScheduler().doEventLoop(&fDoneFlag); char const* auxSDPLine = fDummyRTPSink->auxSDPLine(); return auxSDPLine; } Then it is not streaming and VLC can't understand the SDP , so the VLC player crashes. Error is coming. Here is the TCP flow of H.264 Unicast streamer without SDPLine when we return NULL. OPTIONS rtsp://172.24.2.192:8554/h264ESVideoTest RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 OK CSeq: 1 Date: Sun, Feb 01 2004 12:12:55 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE DESCRIBE rtsp://172.24.2.192:8554/h264ESVideoTest RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 OK CSeq: 2 Date: Sun, Feb 01 2004 12:12:55 GMT Content-Base: rtsp://172.24.2.192:8554/h264ESVideoTest/ Content-Type: application/sdp Content-Length: 353 v=0 o=- 1075637543441356 1 IN IP4 172.24.2.192 s=LIVE555 Streaming Media v i=h264ESVideoTest t=0 0 a=tool:LIVE555 Streaming Media v2008.02.08 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:LIVE555 Streaming Media v a=x-qt-text-inf:h264ESVideoTest m=video 0 RTP/AVP 97 c=IN IP4 0.0.0.0 a=rtpmap:97 H264/90000 a=control:track1 SETUP rtsp://172.24.2.192:8554/h264ESVideoTest/track1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=1662-1663 User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 OK CSeq: 3 Date: Sun, Feb 01 2004 12:12:55 GMT Transport: RTP/AVP;unicast;destination=172.24.3.51;source=172.24.2.192;client_port=1662 -1663;server_port=6970-6971 Session: 1 PLAY rtsp://172.24.2.192:8554/h264ESVideoTest/ RTSP/1.0 CSeq: 4 Session: 1 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2007.02.20) RTSP/1.0 200 OK CSeq: 4 Date: Sun, Feb 01 2004 12:12:55 GMT Range: npt=0.000- Session: 1 RTP-Info: url=rtsp://172.24.2.192:8554/h264ESVideoTest/track1;seq=44038;rtptime=176349 5655 Can someone please help me to inform me the SDP parameters for H.264 RTP transmission over RTSP including Profile-Level-Id & sprop-parameter-set. Regards Soumya LGSI -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 10 03:40:20 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 10 Jul 2008 03:40:20 -0700 Subject: [Live-devel] H264 SDP generation In-Reply-To: <20080710101717.AD60C558009@LGEMRELSE6Q.lge.com> References: <20080710101717.AD60C558009@LGEMRELSE6Q.lge.com> Message-ID: > Can someone please help me to inform me the SDP parameters for >H.264 RTP transmission over RTSP including Profile-Level-Id & >sprop-parameter-set. The full SDP description for the stream is computed automatically by "H264VideoRTPSink", so you don't need to worry about this. Just make sure that you pass the correct "profile_level_id" and "sprop_parameter_sets_str" parameters to "H264VideoRTPSink::createNew()". (See RFC 3984 for details about these parameters.) Also, of course, the "H264VideoRTPSink" must be fed by a "H264VideoStreamFramer" subclass - that you will write. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From soumya.patra at lge.com Thu Jul 10 03:41:25 2008 From: soumya.patra at lge.com (soumya patra) Date: Thu, 10 Jul 2008 16:11:25 +0530 Subject: [Live-devel] H264 SDP generation Message-ID: <20080710104126.27AE6558006@LGEMRELSE6Q.lge.com> Hi, I have developed a H.264 unicast streamer over RTSP using LIVE555 streaming library. I've developed my own H264VideoStreamFramer. Here are the following SDP information, RTP Payload Type = 97 Profile-Level-Id = 66 sprop-parameter-sets =Z0Ligqwewo3FkkBaHsuG,aMOOOOKCrA== But VLC player is not able to play the stream. If I am streaming it without SDPLine then it's streaming to a single VLC client. But I want to stream it to multiple client. Can someone help me to tell me whether the SDPLine is ok or I have to modify it . If anybody has any information regarding this please let me informed. . Here is my mail id soumya.patra at lge.com Bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 10 06:46:59 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 10 Jul 2008 06:46:59 -0700 Subject: [Live-devel] H264 SDP generation In-Reply-To: <20080710104126.27AE6558006@LGEMRELSE6Q.lge.com> References: <20080710104126.27AE6558006@LGEMRELSE6Q.lge.com> Message-ID: >But I want to stream it to multiple client. Are you remembering to set the "reuseFirstSource" parameter (to your "ServerMediaSubsession"s) to "True"? That's important if you are streaming from a single input source (as you are). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From k_dal2 at hotmail.com Thu Jul 10 09:55:48 2008 From: k_dal2 at hotmail.com (Karl Dalen) Date: Thu, 10 Jul 2008 16:55:48 +0000 Subject: [Live-devel] Streaming a live audio source (stdin) over unicast Message-ID: Hi, I would like to stream a live audio source readable from stdin over unicast and I have modified the test program testWAVAudioStreamer so I can successfully stream multicast: % audiorecord -p mic -T wav | testWAVAudioStreamer I was wondering is it possible to modify testWAVAudioStreamer to stream unicast and what would be the procdure for doing that ? I'm aware of the preferred model for unicast, testOnDemandRTSPServer. However, it didn't seem to work with continuous streaming from stdin. On the other hand streaming wav files works fine with testOnDemandRTSPServer. Simply modifying testOnDemandRTSPServer to read from stdin did not work for: % audiorecord -p mic -T wav | testOnDemandRTSPServer This gives audio overflow error and: % cat test.wav | testOnDemandRTSPServer did not work either. Any advice would be greatly appreciated, /Karl D _________________________________________________________________ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcel at marcelgagne.com Thu Jul 10 10:35:46 2008 From: marcel at marcelgagne.com (Marcel =?iso-8859-1?q?Gagn=E9?=) Date: Thu, 10 Jul 2008 13:35:46 -0400 Subject: [Live-devel] Stream from a Panasonic BL-C131A network camera Message-ID: <200807101335.46531.marcel@marcelgagne.com> Hello everyone, I have a Panasonic BL-C131A network camera that can stream video and audio. There are a couple of ways to do this. One is to use MJPEG output and another streaming MPEG4. Both support sound and (sigh) sound comes through if you view the camera using Internet Explorer. Firefox under Linux, VLC, ffmpeg, and mplayer, all display video, but no sound. The audio portion is g726. The camera does stream video using RTSP and RTP and Panasonic tells me they support openRTSP. So I decided to try to capture the output using openRTSP and things 'seem' to work, but all I get are two empty files in my current working directory. They are called audio-G726-32-1 and video-MP4V-ES-2. I'm frankly stumped as to how I a) watch this combined audio and video stream and, more importantly, b) how I capture the stream so that I can save the captured video for archival reasons. I've tried several variations on the openRTSP command, all, so far, with the same results. An example follows . . . openRTSP -v -c -n -w 320 -h 240 -f 30 -u myuser mypass 'rtsp://192.168.1.253/nphMpeg4/g726-320x240' Any help and/or suggestions would be gratefully accepted. Take care out there. -- Marcel (Writer and Free Thinker at Large) Gagn? Note: This massagee wos nat speel or gramer-checkered. Mandatory home page reference - http://www.marcelgagne.com/ Author of the "Moving to Linux" series of books Follow me : http://twitter.com/wftl Join the WFTL-LUG : http://www.wftl-lug.org -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From finlayson at live555.com Thu Jul 10 13:10:15 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 10 Jul 2008 13:10:15 -0700 Subject: [Live-devel] Stream from a Panasonic BL-C131A network camera In-Reply-To: <200807101335.46531.marcel@marcelgagne.com> References: <200807101335.46531.marcel@marcelgagne.com> Message-ID: >So I decided to try to capture the output using openRTSP and >things 'seem' to work, but all I get are two empty files in my current working >directory. Have you read the FAQ?? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 10 13:16:58 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 10 Jul 2008 13:16:58 -0700 Subject: [Live-devel] Streaming a live audio source (stdin) over unicast In-Reply-To: References: Message-ID: >I'm aware of the preferred model for unicast, testOnDemandRTSPServer. >However, it didn't seem to work with continuous streaming >from stdin. On the other hand streaming wav files works fine with >testOnDemandRTSPServer. > >Simply modifying testOnDemandRTSPServer to read from stdin Remember that - because you're reading from a single input source - you must also change "reuseFirstSource" to "True". > did not work for: >% audiorecord -p mic -T wav | testOnDemandRTSPServer >This gives audio overflow error and: >% cat test.wav | testOnDemandRTSPServer >did not work either. > >Any advice would be greatly appreciated, The problem is probably that the output from your audio input device - unlike ".wav" files - does not begin with WAV file headers. Therefore the "WAVAudioFileSource" code can't set the appropriate parameters (number of channels, samplng frequency, bit rate) for the audio stream. The easiest way to overcome this would be to (somehow) hack your audio input device so that the first data it outputs is an appropriate set of WAV file headers. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From k_dal2 at hotmail.com Thu Jul 10 20:17:59 2008 From: k_dal2 at hotmail.com (Karl Dalen) Date: Fri, 11 Jul 2008 03:17:59 +0000 Subject: [Live-devel] Streaming a live audio source (stdin) over unicast In-Reply-To: References: Message-ID: Thanks a lot for your help > > Remember that - because you're reading from a single input source - > you must also change "reuseFirstSource" to "True". > I have modified that in testOnDemandRTSPServer without any change in the results. Is it possible that testOnDemandRTSPServer does some fseek, ftell that may not work for stdin. By adding some diagnostics output I noticed in WAVAudioFileSource.cpp that function: WAVAudioFileSource* WAVAudioFileSource::createNew() gets called twice when using testOnDemandRTSPServer and it just hangs after the second call when reading from stdin. Could it be that since this is stdin and the header can only be read once it doesn't get the expected wav stream. Using testWAVAudioStreamer causes only a single call to the the above function. > > The problem is probably that the output from your audio input device > - unlike ".wav" files - does not begin with WAV file headers. > Therefore the "WAVAudioFileSource" code can't set the appropriate > parameters (number of channels, samplng frequency, bit rate) for the > audio stream. > I think I have taken care of that. I did modify the header output of audiorecord to match with the wav header format that WAVAudioFileSource.cpp expects and I can run testWAVAudioStreamer (multicast) successfully: % audiorecord -p mic -T wav | testWAVAudioStreamer and I can run: % audiorecord -p mic -T wav > tmp.wav % cat tmp.wav | testWAVAudioStreamer and listen to it using: mplayer rtsp://192.168.1.101:8554/testStream -vo null -af volume=13.1:0 So I believe it may not be a wav header format issue. I suppose it's not as simple as just changing the IP in destinationAddress.s_addr to make testWAVAudioStreamer unicast ? Thanks, Karl > -- > > 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 _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE -------------- next part -------------- An HTML attachment was scrubbed... URL: From soumya.patra at lge.com Thu Jul 10 22:17:20 2008 From: soumya.patra at lge.com (soumya patra) Date: Fri, 11 Jul 2008 10:47:20 +0530 Subject: [Live-devel] H264 SDP Message-ID: <20080711051721.1596F558004@LGEMRELSE6Q.lge.com> Hi, I have implemented the H264VideoStreamer subclass and am able to successfully unicast stream to a single VLC client. For this I had modified the live sdp generation code to exclude the fmtp:... line from the returned describe response for H264. In this case I am able to play the streamed content using MPlayer or VLC client. If I pass the profile level id "profile_level_id" and "sprop_parameter_sets_str" parameters to "H264VideoRTPSink::createNew()" as suggested and ensure that the sdp returned contains the correct fmtp: line -"a=fmtp:97 packetization-mode=1;profile-level-id=000042;sprop-parameter-sets=Z0Ligqwewo 3FkkBaHsuG,aMOOOOKCrA==" then my vlc client is not able to play the stream.(I am also unable to play using MPlayer) I have extracted the profile level id and sps and pps and using h264analyzer tool. Also I have base64 encoded the sps and pps as stated in the rfc-3984. I suspect that the vlc client is able to play the h264 stream when it extracts the decoder parameters from the rtp stream itself (in band; we are transmitting NAL units 7 and 8 (sps and pps) also over RTP). But if we try to provide the profile id and sprop_parameters over sdp (while also streaming the NAL packets 7 and 8 over rtp as before) then even a single requesting client is unable to play the stream. Maybe the presence of the fmtp: line stops the client from looking for this information within the stream. But the fmtp: line provided by us is not intelligible enough to the client to successfully play the stream. As our actual requirement is to unicast stream to multiple clients (reuseFirstSource is set to True) and also stream multicast we need to communicate using the sdp, the in band mechanism is not sufficient and also not reliable. I have attached our sdp and NAL frame (contains NAL units 7 and 8) alongwith the mail. We may be missing some needed information in sdp or we might be communicating it in the wrong format or I might be totally mistaken:-). Could you tell us the correct sdp fmtp line to generate or any pointers to missing or incorrect information in our sdp? I have attached ethereal extracted sdp description and NAL packet extracted from h264 analyzer.Please check the attached text file. Regards Soumya LGSI -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sdph264.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: NAL packet.txt URL: From babitha at oneviewsystems.com Thu Jul 10 22:48:44 2008 From: babitha at oneviewsystems.com (Babitha) Date: Fri, 11 Jul 2008 11:18:44 +0530 Subject: [Live-devel] Create openRTSP.exe in windows Message-ID: <4876F43C.6030301@oneviewsystems.com> Hi all, I'm new to live555.I need to compile and build openrtsp program in windows.I have created libBasicUsageEnvironment.lib,libUsageEnvironment.lib,libliveMedia.lib and libgroupsock.lib and linked these.I'm using VC6 platform.I'm able to comile the openRTSP program without any errors, but build produces the following errors.Can anyone please help me to solve this?Do anyone have a compiled windows version of openRTSP.If so, it would be appreciated if you could please mail that exe to me. Thanks in advance, Babitha. _Error report_ LINK : warning LNK4098: defaultlib "LIBCD" conflicts with use of other libs; use /NODEFAULTLIB:library libBasicUsageEnvironment.lib(BasicUsageEnvironment.obj) : error LNK2001: unresolved external symbol __imp____iob_func libBasicUsageEnvironment.lib(BasicUsageEnvironment0.obj) : error LNK2001: unresolved external symbol __imp____iob_func libliveMedia.lib(OutputFile.obj) : error LNK2001: unresolved external symbol __imp____iob_func libBasicUsageEnvironment.lib(BasicTaskScheduler0.obj) : error LNK2001: unresolved external symbol __alldvrm libgroupsock.lib(Groupsock.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(MP3Internals.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(MP3InternalsHuffman.obj) : error LNK2001: unresolved external symbol ___security_cookie libgroupsock.lib(GroupsockHelper.obj) : error LNK2001: unresolved external symbol ___security_cookie libgroupsock.lib(inet.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(JPEGVideoRTPSource.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(BasicUDPSource.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(MultiFramedRTPSource.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(our_md5.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(QuickTimeFileSink.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(RTPInterface.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(DigestAuthentication.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(our_md5hl.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(RTSPClient.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(MediaSession.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(RTCP.obj) : error LNK2001: unresolved external symbol ___security_cookie libliveMedia.lib(AMRAudioFileSink.obj) : error LNK2001: unresolved external symbol ___security_cookie libgroupsock.lib(Groupsock.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(MP3Internals.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(MP3InternalsHuffman.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libgroupsock.lib(GroupsockHelper.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libgroupsock.lib(inet.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(JPEGVideoRTPSource.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(BasicUDPSource.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(MultiFramedRTPSource.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(our_md5.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(QuickTimeFileSink.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(RTPInterface.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(DigestAuthentication.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(our_md5hl.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(RTSPClient.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(MediaSession.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(RTCP.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(AMRAudioFileSink.obj) : error LNK2001: unresolved external symbol @__security_check_cookie at 4 libliveMedia.lib(RTCP.obj) : error LNK2001: unresolved external symbol __ftol2_sse libgroupsock.lib(GroupsockHelper.obj) : error LNK2001: unresolved external symbol __imp___ctime64 Debug/openRtsp.exe : fatal error LNK1120: 6 unresolved externals Error executing link.exe. openRtsp.exe - 41 error(s), 63 warning(s) -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Thu Jul 10 23:12:53 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 10 Jul 2008 23:12:53 -0700 Subject: [Live-devel] H264 SDP In-Reply-To: <20080711051721.1596F558004@LGEMRELSE6Q.lge.com> References: <20080711051721.1596F558004@LGEMRELSE6Q.lge.com> Message-ID: >I have attached our sdp and NAL frame (contains NAL units 7 and 8) >alongwith the mail. We may be missing some needed information in sdp >or we might be communicating it in the wrong format or I might be >totally mistakenJ. Could you tell us the correct sdp fmtp line to >generate No I can't, because only you know the details of your H.264 stream. Are you sure you are encoding the sps and pps NAL units correctly using Base64 (for the "sprop_parameter_sets_str" parameter)? I suggest that you go through VLC's LIVE555 interface code (in "modules/demux/live555.cpp") to make sure that the SDP fmtp string is decoded into the correct NAL unit data (see the function "parseH264ConfigStr()"). If you're still having problems, then you may need to make your RTSP stream publically available, and post to the VLC mailing list, asking them why VLC cannot play it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From havthanh at gmail.com Fri Jul 11 05:23:38 2008 From: havthanh at gmail.com (Hannah) Date: Fri, 11 Jul 2008 20:23:38 +0800 Subject: [Live-devel] live555 Test Programs Message-ID: Hello, Could I ask you this question? I compiled the source code already and now testing the test programs. I try the MP3 Audio test programs as first example. + For the testMP3Streamer, the output receiver is "Unable to open file "test.mp3" as a MP3 file source" + For testMP3Receiver, output is "Beginning receiving multicast stream..." The other test programs have the same output, I can't stream or play any file. What's the problem and how to solve? *Secondly*, I run the testOnDemandRTSPServer, and it returns me the URL links of the audio/video test files, for example : "mpeg4ESVideoTest" stream, from the file "test.m4e" Play this stream using the URL "rtsp://10.10.10.103:8554/mpeg4ESVideoTest" "mpeg1or2AudioVideoTest" stream, from the file "test.mpg" Play this stream using the URL "rtsp:// 10.10.10.103:8554/mpeg1or2AudioVideoTest" Is it the URL link to use with openRTSP client, that I ask below? *Thirdly*, I run the RTSP client, by the command : *./openRTSP,* and I see the usage instructions : Usage : ./openRTSP [-p ] [-r|-q|-4|-i] [-a|-v] [-V] [-d ] [-D [-c] [-S ] [-n] [-O] [-t|-T ] [-u ] [-s ] [-z ] [-w -h ] [-f ] [-y] [-H] [-Q []] [-F ] [-b ] [-B ] [-I ] [-m] *(or ./openRTSP -o [-V] ) * I have tried to use the bold part, for instance *./openRTSP -o [-V] rtsp://10.10.10.103:8554/mpeg1or2AudioVideoTest *But I received nothing. The terminal screen return the usage instructions again. Did I do wrongly? Or do I misunderstand any part? Is there any solutions or how to solve the situation? Thanks a lot for your help on this. Hannah -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jerry.Johns at nuvation.com Fri Jul 11 06:44:31 2008 From: Jerry.Johns at nuvation.com (Jerry Johns) Date: Fri, 11 Jul 2008 06:44:31 -0700 Subject: [Live-devel] H264 SDP Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB17@mailguy3.skynet.nuvation.com> Are you sure you're creating your SDP properly? We've managed to get our streams working with VLC/Quicktime using proper SDP params Is your profile-level-id correct? Check the RFC spec on exact details As for Base64, try using this site to check your vals: http://www.paulschou.com/tools/xlate/ is your format type (97) correct? We use 96 Hope it helps, Jerry Johns Design Engineer Nuvation Research Corp - Canada Tel: (519) 746-2304 ext. 225 www.nuvation.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 11 07:12:17 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 11 Jul 2008 07:12:17 -0700 Subject: [Live-devel] live555 Test Programs In-Reply-To: References: Message-ID: >+ For the testMP3Streamer, the output receiver is "Unable to open >file "test.mp3" as a MP3 file source" Do you have a MP3 file named "test.mp3" in the same directory? >+ For testMP3Receiver, output is "Beginning receiving multicast stream..." Note that "testMP3Receiver" outputs its received (MP3) data to 'stdout'. (If you don't understand what 'stdout' means, then this software is probably not for you.) >Secondly, I run the testOnDemandRTSPServer, and it returns me the >URL links of the audio/video test files, for example : > >"mpeg4ESVideoTest" stream, from the file "test.m4e" >Play this stream using the URL >"rtsp://10.10.10.103:8554/mpeg4ESVideoTest" > >"mpeg1or2AudioVideoTest" stream, from the file "test.mpg" >Play this stream using the URL >"rtsp://10.10.10.103:8554/mpeg1or2AudioVideoTest" > >Is it the URL link to use with openRTSP client, that I ask below? Yes, but you need to have the appropriate file - e.g., a MPEG-1 or 2 Program Stream file named "test.mpg" - in the same directory. > >Thirdly, I run the RTSP client, by the command : ./openRTSP, and I >see the usage instructions : > >Usage : ./openRTSP [-p ] [-r|-q|-4|-i] [-a|-v] [-V] >[-d ] [-D [-c] [-S ] >[-n] [-O] [-t|-T ] [-u ] [-s >] [-z ] [-w -h ] [-f >] [-y] [-H] [-Q []] [-F >] [-b ] [-B >] [-I ] [-m] > (or ./openRTSP -o [-V] ) > > I have tried to use the bold part, for instance ./openRTSP -o [-V] >rtsp://10.10.10.103:8554/mpeg1or2AudioVideoTest No, just run ./openRTSP rtsp://10.10.10.103:8554/mpeg1or2AudioVideoTest See the "openRTSP" instructions to understand the command-line options. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 11 07:14:30 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 11 Jul 2008 07:14:30 -0700 Subject: [Live-devel] H264 SDP In-Reply-To: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB17@mailguy3.skynet.nuvation.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB17@mailguy3.skynet.nuvation.com> Message-ID: >is your format type (97) correct? >We use 96 Either is correct (provided that it doesn't clash with another substream (e.g., audio) that you're also sending. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryanwalklin at gmail.com Fri Jul 11 15:52:11 2008 From: ryanwalklin at gmail.com (Ryan Walklin) Date: Sat, 12 Jul 2008 10:52:11 +1200 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card Message-ID: Hi, I'm using an Elgato DVB-T USB tuner (EyeTV for DTT) in combination with the livemedia library to stream a MPEG2-TS stream containing h264 video and AAC audio (LATM encapsulation) via RTSP over my LAN. I've based my streaming server on the testMPEG2TransportStreamer sample. The EyeTV plugin SDK provides a callback which is activated when ~100 or so packets have arrived, and sends the raw TS data via a pipe to the server code, running in another thread. I've modified the code to read from the other end of the pipe I created. I've also removed the MPEG2Framer from the chain as I presumed the packet stream was already in this format. This done, I'm able to launch VLC and see the stream for 1-2 seconds, however VLC proceeds to crash with the console errors: MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (48). 1388 bytes of trailing data will be dropped! MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (112). 1324 bytes of trailing data will be dropped! MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (60). 1376 bytes of trailing data will be dropped! MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (8). 1428 bytes of trailing data will be dropped! From my reading of the mailing list archives, I understand that somewhere along the encoding chain (Presumably in ByteStreamFileSource (MultiFramedRTPSource) a buffer is being over-run, but I cannot fathom where. All the buffers seem to default to ~50-60kb, however from those errors it seems to be under 100 bytes most of the time. I note the sum of the streamed+dropped packets is 1440, so presumably this has something to do with network framing. I've been playing with this all week and ended up more and more confused reading the source. I'd apprecitate it if anyone is able to shed light. I've attached my server thread source for your perusal. (createRTSPserver is essentially main() from testtMPEG2TransportStreamer.cpp with my tweaks). Regards, Ryan Walklin -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2RTSPServer.cpp Type: application/octet-stream Size: 6079 bytes Desc: not available URL: -------------- next part -------------- - stream structure - using pipe to copy packets - raw off card - how to relay mpeg2 ts as live to rtsp - buffer size From finlayson at live555.com Fri Jul 11 17:28:53 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 11 Jul 2008 17:28:53 -0700 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: Message-ID: >I'm using an Elgato DVB-T USB tuner (EyeTV for DTT) in combination >with the livemedia library to stream a MPEG2-TS stream containing >h264 video and AAC audio (LATM encapsulation) via RTSP over my LAN. >I've based my streaming server on the testMPEG2TransportStreamer >sample. Does the unchanged "testMPEG3TransportStreamer" demo application work correctly when you stream a Transport Stream *file* that you previously recorded from your capture device? It should, but if - for some reason - it doesn't, then do not proceed to step 2 :-) >The EyeTV plugin SDK provides a callback which is activated when >~100 or so packets have arrived, and sends the raw TS data via a >pipe to the server code, running in another thread. I've modified >the code to read from the other end of the pipe I created. I've also >removed the MPEG2Framer from the chain as I presumed the packet >stream was already in this format. No, the "MPEG2TransportStreamFramer" also has the job of (1) accumulates the incoming Transport Stream packets into groups of 7, so that they end up getting packed into outgoing RTP packets efficiently, and (2) computing the presentation time and duration of each Transport Packet, so that the outgoing RTP packets get transmitted with appropriate spacing between them. You should continue to use the MPEG2TransportStreamFramer" object. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ryanwalklin at gmail.com Fri Jul 11 19:16:04 2008 From: ryanwalklin at gmail.com (Ryan Walklin) Date: Sat, 12 Jul 2008 14:16:04 +1200 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: Message-ID: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> > Hi Ross, thanks for your quick reply. > >I'm using an Elgato DVB-T USB tuner (EyeTV for DTT) in combination > >with the livemedia library to stream a MPEG2-TS stream containing > >h264 video and AAC audio (LATM encapsulation) via RTSP over my LAN. > >I've based my streaming server on the testMPEG2TransportStreamer > >sample. > > Does the unchanged "testMPEG3TransportStreamer" demo application work > correctly when you stream a Transport Stream *file* that you > previously recorded from your capture device? It should, but if - > for some reason - it doesn't, then do not proceed to step 2 :-) It does indeed. > > > >The EyeTV plugin SDK provides a callback which is activated when > >~100 or so packets have arrived, and sends the raw TS data via a > >pipe to the server code, running in another thread. I've modified > >the code to read from the other end of the pipe I created. I've also > >removed the MPEG2Framer from the chain as I presumed the packet > >stream was already in this format. > > No, the "MPEG2TransportStreamFramer" also has the job of (1) > accumulates the incoming Transport Stream packets into groups of 7, > so that they end up getting packed into outgoing RTP packets > efficiently, and (2) computing the presentation time and duration of > each Transport Packet, so that the outgoing RTP packets get > transmitted with appropriate spacing between them. You should > continue to use the MPEG2TransportStreamFramer" object. > -- OK, I understand that now, and have re-enabled the framer object. This solves the buffer errors I was getting, and both openRTSP and libnemesi (another RTSP client) show the stream has been successfully created. However, VLC is still unable to play the stream. Things look ok in the message log though: main debug: CPU has capabilities 486 586 MMX 3DNow! MMXEXT SSE SSE2 FPU main debug: looking for memcpy module: 4 candidates main debug: using memcpy module "memcpymmxext" main debug: waiting for thread completion main debug: thread 2953318400 (playlist) created at priority -47 (playlist/playlist.c:184) main debug: waiting for thread completion main debug: thread 2953850880 (preparser) created at priority -47 (playlist/playlist.c:210) main debug: looking for interface module: 1 candidate main debug: using interface module "hotkeys" main debug: thread 2954383360 (interface) created at priority -47 (interface/interface.c:198) main debug: looking for interface module: 3 candidates main debug: using interface module "macosx" main debug: thread 2955448320 (manage) created at priority -47 (interface/interface.c:164) main debug: adding playlist item `testStream' ( rtsp://192.168.1.5:8554/testStream ) main debug: creating new input thread main debug: waiting for thread completion main debug: thread 2957705216 (input) created at priority 37 (input/ input.c:265) main debug: creating statistics handler main debug: `rtsp://192.168.1.5:8554/testStream' gives access `rtsp' demux `' path `192.168.1.5:8554/testStream' main debug: creating demux: access='rtsp' demux='' path='192.168.1.5:8554/testStream' main debug: looking for access_demux module: 1 candidate macosx debug: input has changed, refreshing interface live555 debug: RTP subsession 'video/MP2T' main debug: creating demux: access='' demux='ts' path='' main debug: thread 2958237696 (stream out) created at priority 37 (input/demux.c:341) main debug: using access_demux module "live555" main debug: `rtsp://192.168.1.5:8554/testStream' successfully opened Here is openRTSP's output (sorry for the long paste..) Sending request: OPTIONS rtsp://192.168.1.5:8554/testStream RTSP/1.0 CSeq: 1 User-Agent: ./openRTSP (LIVE555 Streaming Media v2008.07.05) Received OPTIONS response: RTSP/1.0 200 OK CSeq: 1 Date: Sat, Jul 12 2008 02:13:17 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE Sending request: DESCRIBE rtsp://192.168.1.5:8554/testStream RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: ./openRTSP (LIVE555 Streaming Media v2008.07.05) Received DESCRIBE response: RTSP/1.0 200 OK CSeq: 2 Date: Sat, Jul 12 2008 02:13:17 GMT Content-Base: rtsp://192.168.1.5:8554/testStream/ Content-Type: application/sdp Content-Length: 405 Need to read 405 extra bytes Read 405 extra bytes: v=0 o=- 1215828411688060 1 IN IP4 192.168.1.5 s=Session streamed by "testMPEG2TransportStreamer" i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2008.07.05 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "testMPEG2TransportStreamer" a=x-qt-text-inf:LIVE555 Streaming Media v m=video 1234 RTP/AVP 33 c=IN IP4 239.255.42.42/7 a=control:track1 Opened URL "rtsp://192.168.1.5:8554/testStream", returning a SDP description: v=0 o=- 1215828411688060 1 IN IP4 192.168.1.5 s=Session streamed by "testMPEG2TransportStreamer" i=LIVE555 Streaming Media v t=0 0 a=tool:LIVE555 Streaming Media v2008.07.05 a=type:broadcast a=control:* a=range:npt=0- a=x-qt-text-nam:Session streamed by "testMPEG2TransportStreamer" a=x-qt-text-inf:LIVE555 Streaming Media v m=video 1234 RTP/AVP 33 c=IN IP4 239.255.42.42/7 a=control:track1 Created receiver for "video/MP2T" subsession (client ports 1234-1235) Sending request: SETUP rtsp://192.168.1.5:8554/testStream/track1 RTSP/ 1.0 CSeq: 3 Transport: RTP/AVP;multicast;client_port=1234-1235 User-Agent: ./openRTSP (LIVE555 Streaming Media v2008.07.05) Received SETUP response: RTSP/1.0 200 OK CSeq: 3 Date: Sat, Jul 12 2008 02:13:17 GMT Transport: RTP/ AVP ;multicast ;destination=239.255.42.42;source=192.168.1.5;port=1234-1235;ttl=7 Session: 4 Setup "video/MP2T" subsession (client ports 1234-1235) Created output file: "video-MP2T-1" Sending request: PLAY rtsp://192.168.1.5:8554/testStream/ RTSP/1.0 CSeq: 4 Session: 4 Range: npt=0.000- User-Agent: ./openRTSP (LIVE555 Streaming Media v2008.07.05) Received PLAY response: RTSP/1.0 200 OK CSeq: 4 Date: Sat, Jul 12 2008 02:13:17 GMT Range: npt=0.000- Session: 4 RTP-Info: url=rtsp://192.168.1.5:8554/testStream/track1;seq=60417;rtptime=2653845066 Started playing session Receiving streamed data (signal with "kill -HUP 23285" or "kill -USR1 23285" to terminate)... Again this all looks ok. Thanks for your help so far, I'm sure it's just something silly I haven't done. Regards. Ryan > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ From soumya.patra at lge.com Fri Jul 11 20:57:58 2008 From: soumya.patra at lge.com (soumya patra) Date: Sat, 12 Jul 2008 09:27:58 +0530 Subject: [Live-devel] live-devel Digest, Vol 57, Issue 13 In-Reply-To: Message-ID: <20080712035802.24901558005@LGEMRELSE7Q.lge.com> Hi Ross, Thanks for the concern, now I am able to stream h.264 with correct SDP. I've corrected the SDP. Now it's streaming. Regards, Soumya LGSI -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of live-devel-request at ns.live555.com Sent: Saturday, July 12, 2008 4:25 AM To: live-devel at ns.live555.com Subject: live-devel Digest, Vol 57, Issue 13 Send live-devel mailing list submissions to live-devel at lists.live555.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.live555.com/mailman/listinfo/live-devel or, via email, send a message with subject or body 'help' to live-devel-request at lists.live555.com You can reach the person managing the list at live-devel-owner at lists.live555.com When replying, please edit your Subject line so it is more specific than "Re: Contents of live-devel digest..." Today's Topics: 1. Re: H264 SDP (Ross Finlayson) 2. live555 Test Programs (Hannah) 3. Re: H264 SDP (Jerry Johns) 4. Re: live555 Test Programs (Ross Finlayson) 5. Re: H264 SDP (Ross Finlayson) 6. Creating a RTSP stream from DVB-T hardware card (Ryan Walklin) ---------------------------------------------------------------------- Message: 1 Date: Thu, 10 Jul 2008 23:12:53 -0700 From: Ross Finlayson Subject: Re: [Live-devel] H264 SDP To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed" >I have attached our sdp and NAL frame (contains NAL units 7 and 8) >alongwith the mail. We may be missing some needed information in sdp >or we might be communicating it in the wrong format or I might be >totally mistakenJ. Could you tell us the correct sdp fmtp line to >generate No I can't, because only you know the details of your H.264 stream. Are you sure you are encoding the sps and pps NAL units correctly using Base64 (for the "sprop_parameter_sets_str" parameter)? I suggest that you go through VLC's LIVE555 interface code (in "modules/demux/live555.cpp") to make sure that the SDP fmtp string is decoded into the correct NAL unit data (see the function "parseH264ConfigStr()"). If you're still having problems, then you may need to make your RTSP stream publically available, and post to the VLC mailing list, asking them why VLC cannot play it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Fri, 11 Jul 2008 20:23:38 +0800 From: Hannah Subject: [Live-devel] live555 Test Programs To: live-devel at ns.live555.com Message-ID: Content-Type: text/plain; charset="iso-8859-1" Hello, Could I ask you this question? I compiled the source code already and now testing the test programs. I try the MP3 Audio test programs as first example. + For the testMP3Streamer, the output receiver is "Unable to open file "test.mp3" as a MP3 file source" + For testMP3Receiver, output is "Beginning receiving multicast stream..." The other test programs have the same output, I can't stream or play any file. What's the problem and how to solve? *Secondly*, I run the testOnDemandRTSPServer, and it returns me the URL links of the audio/video test files, for example : "mpeg4ESVideoTest" stream, from the file "test.m4e" Play this stream using the URL "rtsp://10.10.10.103:8554/mpeg4ESVideoTest" "mpeg1or2AudioVideoTest" stream, from the file "test.mpg" Play this stream using the URL "rtsp:// 10.10.10.103:8554/mpeg1or2AudioVideoTest" Is it the URL link to use with openRTSP client, that I ask below? *Thirdly*, I run the RTSP client, by the command : *./openRTSP,* and I see the usage instructions : Usage : ./openRTSP [-p ] [-r|-q|-4|-i] [-a|-v] [-V] [-d ] [-D [-c] [-S ] [-n] [-O] [-t|-T ] [-u ] [-s ] [-z ] [-w -h ] [-f ] [-y] [-H] [-Q []] [-F ] [-b ] [-B ] [-I ] [-m] *(or ./openRTSP -o [-V] ) * I have tried to use the bold part, for instance *./openRTSP -o [-V] rtsp://10.10.10.103:8554/mpeg1or2AudioVideoTest *But I received nothing. The terminal screen return the usage instructions again. Did I do wrongly? Or do I misunderstand any part? Is there any solutions or how to solve the situation? Thanks a lot for your help on this. Hannah -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Fri, 11 Jul 2008 06:44:31 -0700 From: "Jerry Johns" Subject: Re: [Live-devel] H264 SDP To: Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB17 at mailguy3.skynet.nuvation.com> Content-Type: text/plain; charset="us-ascii" Are you sure you're creating your SDP properly? We've managed to get our streams working with VLC/Quicktime using proper SDP params Is your profile-level-id correct? Check the RFC spec on exact details As for Base64, try using this site to check your vals: http://www.paulschou.com/tools/xlate/ is your format type (97) correct? We use 96 Hope it helps, Jerry Johns Design Engineer Nuvation Research Corp - Canada Tel: (519) 746-2304 ext. 225 www.nuvation.com -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Fri, 11 Jul 2008 07:12:17 -0700 From: Ross Finlayson Subject: Re: [Live-devel] live555 Test Programs To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed" >+ For the testMP3Streamer, the output receiver is "Unable to open >file "test.mp3" as a MP3 file source" Do you have a MP3 file named "test.mp3" in the same directory? >+ For testMP3Receiver, output is "Beginning receiving multicast stream..." Note that "testMP3Receiver" outputs its received (MP3) data to 'stdout'. (If you don't understand what 'stdout' means, then this software is probably not for you.) >Secondly, I run the testOnDemandRTSPServer, and it returns me the >URL links of the audio/video test files, for example : > >"mpeg4ESVideoTest" stream, from the file "test.m4e" >Play this stream using the URL >"rtsp://10.10.10.103:8554/mpeg4E SVideoTest" > >"mpeg1or2AudioVideoTest" stream, from the file "test.mpg" >Play this stream using the URL >"rtsp://10.10.10.103:8554/ mpeg1or2AudioVideoTest" > >Is it the URL link to use with openRTSP client, that I ask below? Yes, but you need to have the appropriate file - e.g., a MPEG-1 or 2 Program Stream file named "test.mpg" - in the same directory. > >Thirdly, I run the RTSP client, by the command : ./openRTSP, and I >see the usage instructions : > >Usage : ./openRTSP [-p ] [-r|-q|-4|-i] [-a|-v] [-V] >[-d ] [-D [-c] [-S ] >[-n] [-O] [-t|-T ] [-u ] [-s >] [-z ] [-w -h ] [-f >] [-y] [-H] [-Q []] [-F >] [-b ] [-B >] [-I ] [-m] > (or ./openRTSP -o [-V] ) > > I have tried to use the bold part, for instance ./openRTSP -o [-V] >rtsp://10.10.10.103:8554/m peg1or2AudioVideoTest No, just run ./openRTSP rtsp://10.10.10.103:8554/mp eg1or2AudioVideoTest See the "openRTSP" instructions to understand the command-line options. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Fri, 11 Jul 2008 07:14:30 -0700 From: Ross Finlayson Subject: Re: [Live-devel] H264 SDP To: LIVE555 Streaming Media - development & use Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed" >is your format type (97) correct? >We use 96 Either is correct (provided that it doesn't clash with another substream (e.g., audio) that you're also sending. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 6 Date: Sat, 12 Jul 2008 10:52:11 +1200 From: Ryan Walklin Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card To: live-devel at ns.live555.com Message-ID: Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Hi, I'm using an Elgato DVB-T USB tuner (EyeTV for DTT) in combination with the livemedia library to stream a MPEG2-TS stream containing h264 video and AAC audio (LATM encapsulation) via RTSP over my LAN. I've based my streaming server on the testMPEG2TransportStreamer sample. The EyeTV plugin SDK provides a callback which is activated when ~100 or so packets have arrived, and sends the raw TS data via a pipe to the server code, running in another thread. I've modified the code to read from the other end of the pipe I created. I've also removed the MPEG2Framer from the chain as I presumed the packet stream was already in this format. This done, I'm able to launch VLC and see the stream for 1-2 seconds, however VLC proceeds to crash with the console errors: MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (48). 1388 bytes of trailing data will be dropped! MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (112). 1324 bytes of trailing data will be dropped! MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (60). 1376 bytes of trailing data will be dropped! MultiFramedRTPSource::doGetNextFrame1(): The total received frame size exceeds the client's buffer size (8). 1428 bytes of trailing data will be dropped! From my reading of the mailing list archives, I understand that somewhere along the encoding chain (Presumably in ByteStreamFileSource (MultiFramedRTPSource) a buffer is being over-run, but I cannot fathom where. All the buffers seem to default to ~50-60kb, however from those errors it seems to be under 100 bytes most of the time. I note the sum of the streamed+dropped packets is 1440, so presumably this has something to do with network framing. I've been playing with this all week and ended up more and more confused reading the source. I'd apprecitate it if anyone is able to shed light. I've attached my server thread source for your perusal. (createRTSPserver is essentially main() from testtMPEG2TransportStreamer.cpp with my tweaks). Regards, Ryan Walklin -------------- next part -------------- A non-text attachment was scrubbed... Name: MPEG2RTSPServer.cpp Type: application/octet-stream Size: 6079 bytes Desc: not available URL: -------------- next part -------------- - stream structure - using pipe to copy packets - raw off card - how to relay mpeg2 ts as live to rtsp - buffer size ------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel End of live-devel Digest, Vol 57, Issue 13 ****************************************** From finlayson at live555.com Fri Jul 11 21:32:33 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 11 Jul 2008 21:32:33 -0700 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: >>Does the unchanged "testMPEG3TransportStreamer" demo application work >>correctly when you stream a Transport Stream *file* that you >>previously recorded from your capture device? It should, but if - >>for some reason - it doesn't, then do not proceed to step 2 :-) >It does indeed. OK, now: 1/ Can VLC play this same file (directly; not via a stream)? 2/ If you enable "testMPEG2TransportStreamer"s built-in RTSP server (by uncommenting the line #define IMPLEMENT_RTSP_SERVER 1 ), then can VLC play the stream? >>No, the "MPEG2TransportStreamFramer" also has the job of (1) >>accumulates the incoming Transport Stream packets into groups of 7, >>so that they end up getting packed into outgoing RTP packets >>efficiently, and (2) computing the presentation time and duration of >>each Transport Packet, so that the outgoing RTP packets get >>transmitted with appropriate spacing between them. You should >>continue to use the MPEG2TransportStreamFramer" object. >>-- >OK, I understand that now, and have re-enabled the framer object. >This solves the buffer errors I was getting, and both openRTSP and >libnemesi (another RTSP client) show the stream has been >successfully created. However, VLC is still unable to play the >stream. Try receiving the stream using the "openRTSP" client instead. Check whether you receive a proper Transport Stream file (that you can play, directly, using VLC). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ryanwalklin at gmail.com Fri Jul 11 22:03:32 2008 From: ryanwalklin at gmail.com (Ryan Walklin) Date: Sat, 12 Jul 2008 17:03:32 +1200 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: On Jul 12, 2008, at 4:32 PM, Ross Finlayson wrote: >>> Does the unchanged "testMPEG3TransportStreamer" demo application >>> work >>> correctly when you stream a Transport Stream *file* that you >>> previously recorded from your capture device? It should, but if - >>> for some reason - it doesn't, then do not proceed to step 2 :-) >> It does indeed. > > OK, now: > 1/ Can VLC play this same file (directly; not via a stream)? Yes, TS filed saved from EyeTV stream fine. > > 2/ If you enable "testMPEG2TransportStreamer"s built-in RTSP server > (by uncommenting the line > #define IMPLEMENT_RTSP_SERVER 1 > ), then can VLC play the stream? > I have already enabled the RTSP server in my code. > >>> No, the "MPEG2TransportStreamFramer" also has the job of (1) >>> accumulates the incoming Transport Stream packets into groups of 7, >>> so that they end up getting packed into outgoing RTP packets >>> efficiently, and (2) computing the presentation time and duration of >>> each Transport Packet, so that the outgoing RTP packets get >>> transmitted with appropriate spacing between them. You should >>> continue to use the MPEG2TransportStreamFramer" object. >>> -- >> OK, I understand that now, and have re-enabled the framer object. >> This solves the buffer errors I was getting, and both openRTSP and >> libnemesi (another RTSP client) show the stream has been >> successfully created. However, VLC is still unable to play the >> stream. > > Try receiving the stream using the "openRTSP" client instead. Check > whether you receive a proper Transport Stream file (that you can > play, directly, using VLC). This isn't working either, i get a zero-length file. I've emailed Elgato as well, as changing some of the parameters in the server code affects the plugin code (Which shouldn't happen!) Thanks for your ongoing help. Regards, Ryan > > -- > > 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 ryanwalklin at gmail.com Fri Jul 11 22:07:30 2008 From: ryanwalklin at gmail.com (Ryan Walklin) Date: Sat, 12 Jul 2008 17:07:30 +1200 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: <053F0E16-D8C4-4481-B8EE-64338293908F@gmail.com> A couple of other points, here is the structure of a transport packet as given by EyeTV: typedef struct { unsigned long sync_byte : 8, transport_error_indicator : 1, payload_unit_start_indicator : 1, transport_priority : 1, PID : 13, transport_scrambling_control : 2, adaptation_field_control : 2, continuity_counter : 4; unsigned char data[188-4]; } TransportStreamPacket; And here is the code I'm currently using to access it: static long PlexTVServerPacketsArrived(PlexTVServerGlobals *globals, EyeTVPluginDeviceID deviceID, long **packets, long packetsCount) { long result = 0; int i, j, isNewPID; TransportStreamPacket *packet; if (globals) { DeviceInfo *deviceInfo = GetDeviceInfo(globals, deviceID); if (deviceInfo) { char packetBuffer[sizeof(TransportStreamPacket)]; for (i = 0; i < packetsCount; i++) { packet = (TransportStreamPacket*)packets[i]; isNewPID = 1; /* * search for PID */ for (j = 0; j < deviceInfo->pidsCount; j++) { if (packet->PID == deviceInfo->pids[j]) { isNewPID = 0; break; } } /* * add new PIDs to the DeviceInfo */ if (isNewPID) { #ifdef TVDBG_VERBOSE printf ("PlexTVServer: SamplePacketsArrived, newPID = %6li\n", packet->PID); #endif if (deviceInfo->pidsCount < MAX_PIDS) { deviceInfo->pids[deviceInfo->pidsCount++] = packet->PID; } } //stream packets to RTSP server memcpy(packetBuffer, packet, sizeof(TransportStreamPacket)); write(streamfd[STREAM_INPUT], packetBuffer, sizeof(TransportStreamPacket)); } //void *packetBuffer = malloc(packetsCount * sizeof(TransportStreamPacket)); //memcpy(packetBuffer, packets, sizeof(TransportStreamPacket) * packetsCount); //write(streamfd[STREAM_INPUT], packetBuffer, sizeof(TransportStreamPacket) * packetsCount); //free(packetBuffer); globals->packetCount+=packetsCount; #ifdef TVDBG_VERBOSE printf("Packetcount: %lli\n", globals->packetCount); #endif } } return result; } According to the EyeTV documentation, the **packets array is the actual data coming from the card, rather than a copy, so it seems to be quite sensitive to interference, hence copying the packets before piping them to the server. From finlayson at live555.com Fri Jul 11 22:09:19 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 11 Jul 2008 22:09:19 -0700 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: >>2/ If you enable "testMPEG2TransportStreamer"s built-in RTSP server >>(by uncommenting the line >> #define IMPLEMENT_RTSP_SERVER 1 >>), then can VLC play the stream? >> > >I have already enabled the RTSP server in my code. I wasn't asking about your code; I was asking about mine :-) You should check to see whether the original "testMPEG2TransportStreamer" application - modified *only* by enabling the built-in RTSP server - can stream to VLC (by opening the "rtsp://" URL). >>Try receiving the stream using the "openRTSP" client instead. >>Check whether you receive a proper Transport Stream file (that you >>can play, directly, using VLC). >This isn't working either, i get a zero-length file. Assuming that there's no firewall between "openRTSP" and your server, then the problem is that your server is not streaming any data. Because this is your code, you're going to have to figure this out for yourself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ryanwalklin at gmail.com Fri Jul 11 22:42:47 2008 From: ryanwalklin at gmail.com (Ryan Walklin) Date: Sat, 12 Jul 2008 17:42:47 +1200 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: <47F54226-C9D9-4697-A464-D2A8E17A9921@gmail.com> On Jul 12, 2008, at 5:09 PM, Ross Finlayson wrote: >>> 2/ If you enable "testMPEG2TransportStreamer"s built-in RTSP >>> server (by uncommenting the line >>> #define IMPLEMENT_RTSP_SERVER 1 >>> ), then can VLC play the stream? >>> >> >> I have already enabled the RTSP server in my code. > > I wasn't asking about your code; I was asking about mine :-) Fair enough ;) There certainly is a wealth of sample code, which is nice. > > > You should check to see whether the original > "testMPEG2TransportStreamer" application - modified *only* by > enabling the built-in RTSP server - can stream to VLC (by opening > the "rtsp://" URL). > It can save a TS file i've saved using EyeTV, but not when streaming live from stdin. > >>> Try receiving the stream using the "openRTSP" client instead. >>> Check whether you receive a proper Transport Stream file (that you >>> can play, directly, using VLC). >> This isn't working either, i get a zero-length file. > > Assuming that there's no firewall between "openRTSP" and your > server, then the problem is that your server is not streaming any > data. Because this is your code, you're going to have to figure this > out for yourself. > -- Yeah I think so, although all my tests of the plugin code indicate it is writing the packets to the pipe correctly. Thanks again, I'll keep working on it. Ryan > > > 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 ryanwalklin at gmail.com Fri Jul 11 23:58:07 2008 From: ryanwalklin at gmail.com (Ryan Walklin) Date: Sat, 12 Jul 2008 18:58:07 +1200 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: OK, I promise this will be the last time i write ;) I'm not convinced my code is the problem now (although it most likely still is). I've rewritten my plugin code to simply write packets to stdout, then piped it into a file (temp.ts). This plays back fine in VLC. However, using either testMPEG2TransportStreamer or live555MediaServer to stream it to VLC doesn't work. testMPEG2TransportStreamer dumps a stream of "Missing Sync Byte" errors to the console until killed, whereas live555MediaServer allows the stream to load in VLC, however doesn't play, and examining the VLC info window shows the incoming stream has 16 streams (the file has only a single audio and video stream). Strangely ts files saved using the EyeTV interface stream fine. My hypotheses then are either the raw stream coming from my card is not entirely spec-compliant, or EyeTV is presenting me incorrect data; or that the liveMedia library does not entirely support NZ's DVB format. I'll keep working on it, but I think I might need to get Elgato to shed some light. Regards, Ryan On Jul 12, 2008, at 5:09 PM, Ross Finlayson wrote: >>> 2/ If you enable "testMPEG2TransportStreamer"s built-in RTSP >>> server (by uncommenting the line >>> #define IMPLEMENT_RTSP_SERVER 1 >>> ), then can VLC play the stream? >>> >> >> I have already enabled the RTSP server in my code. > > I wasn't asking about your code; I was asking about mine :-) > > You should check to see whether the original > "testMPEG2TransportStreamer" application - modified *only* by > enabling the built-in RTSP server - can stream to VLC (by opening > the "rtsp://" URL). > > >>> Try receiving the stream using the "openRTSP" client instead. >>> Check whether you receive a proper Transport Stream file (that you >>> can play, directly, using VLC). >> This isn't working either, i get a zero-length file. > > Assuming that there's no firewall between "openRTSP" and your > server, then the problem is that your server is not streaming any > data. Because this is your code, you're going to have to figure this > out for yourself. > -- > > 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 Sat Jul 12 00:27:33 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 12 Jul 2008 00:27:33 -0700 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: >However, using either testMPEG2TransportStreamer or >live555MediaServer to stream it to VLC doesn't work. >testMPEG2TransportStreamer dumps a stream of "Missing Sync Byte" >errors to the console That means exactly what it says: That your file is not starting with a Transport Stream 'sync byte' (0x47), presumably because it begins in the middle of a Transport Stream packet. If you make sure that your encoder's output begins with the start of a 188-byte Transport Stream packet (i.e., beginning with a sync byte (0x47)), then you probably won't have this problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ryanwalklin at gmail.com Sat Jul 12 01:58:04 2008 From: ryanwalklin at gmail.com (Ryan Walklin) Date: Sat, 12 Jul 2008 20:58:04 +1200 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: A quick hex-edit of the file confirms that the first and 189th byte are both 0x47. I've been over the encoder's frame generation, and each packet sent to the encoder via the pipe to the server code is prefaced by the sync byte. Is there any debugging switches with the livemedia library I can enable to further explore this? Regards, Ryan On Jul 12, 2008, at 7:27 PM, Ross Finlayson wrote: >> However, using either testMPEG2TransportStreamer or >> live555MediaServer to stream it to VLC doesn't work. >> testMPEG2TransportStreamer dumps a stream of "Missing Sync Byte" >> errors to the console > > That means exactly what it says: That your file is not starting with > a Transport Stream 'sync byte' (0x47), presumably because it begins > in the middle of a Transport Stream packet. > > If you make sure that your encoder's output begins with the start of > a 188-byte Transport Stream packet (i.e., beginning with a sync byte > (0x47)), then you probably won't have this problem. > > -- > > 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 Sat Jul 12 04:24:59 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 12 Jul 2008 04:24:59 -0700 Subject: [Live-devel] Creating a RTSP stream from DVB-T hardware card In-Reply-To: References: <9AD6002D-DDD6-47C0-84E5-7CF75E87E40D@gmail.com> Message-ID: >A quick hex-edit of the file confirms that the first and 189th byte >are both 0x47. I've been over the encoder's frame generation, and >each packet sent to the encoder via the pipe to the server code is >prefaced by the sync byte. Nonetheless, the error message - printed by "MPEG2TransportStreamFramer" - means exactly what it says. Sorry, but I don't have amy more time to help someone who uses a "@gmail.com" email address. However, "Remember, You Have Complete Source Code". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From qiujianshu at cnc-labs.com Sat Jul 12 16:46:55 2008 From: qiujianshu at cnc-labs.com (choujs) Date: Sun, 13 Jul 2008 07:46:55 +0800 Subject: [Live-devel] TS indexer not support video codecs except mpeg1 and mpeg2 Message-ID: <004c01c8e479$91181730$622efea9@cnc.intra> Hi, The tool program MPEG2TransportStreamIndexer can not create index file for TS file that include video ES of codec such as MEPG4 and H.264. I think the reason is in file MPEG2IndexFromTransportStream.cpp, line 309(function MPEG2IFrameIndexFromTransportStream ::analyzePMT): if (stream_type == 1 || stream_type == 2 ) { fVideo_PID = elementary_PID; return; } That means the indexer can accept only MPEG1 and MPEG2. To deal with this program, I have modified these lines as below. if (stream_type == 1 || stream_type == 2 || // mpeg1, mpeg2 stream_type == 16 || stream_type == 27 || // mpeg4, h264 stream_type == 66 || stream_type == 234 ) // Chinese AVS, VC1 { fVideo_PID = elementary_PID; return; } Now the MPEG2TransportStreamIndexer can create index file for TS file of H.264 successfully. But just 'create', I have not check whether the created index file is correct or not. From finlayson at live555.com Sat Jul 12 17:24:04 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 12 Jul 2008 17:24:04 -0700 Subject: [Live-devel] TS indexer not support video codecs except mpeg1 and mpeg2 In-Reply-To: <004c01c8e479$91181730$622efea9@cnc.intra> References: <004c01c8e479$91181730$622efea9@cnc.intra> Message-ID: >The tool program MPEG2TransportStreamIndexer can not create index >file for TS file that include video ES of codec such as MEPG4 and >H.264. That's correct > I think the reason is No, the reason is described here: http://lists.live555.com/pipermail/live-devel/2008-May/008722.html -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From havthanh at gmail.com Sun Jul 13 03:07:01 2008 From: havthanh at gmail.com (Hannah) Date: Sun, 13 Jul 2008 18:07:01 +0800 Subject: [Live-devel] Re : live555 Test Programs Message-ID: Hi, Thanks for your reply. According to your last reply that : + For the testMP3Streamer, the output receiver is "Unable to open file "test.mp3" as a MP3 file source" * Do you have a MP3 file named "test.mp3" in the same directory? *Is the file named "test.mp3" (and other test files) in the live directory after compiling? I recompiled the source code and don't see the "test.mp3". If not available after compiling, I'll have to go and download it and put it in the server's directory? Secondly, I run the RTSP client : ./openRTSP rtsp://10.10.10.101:8554/mpeg1or2AudioVideoTest Output is: *Sending request: .... Received .. .... * * Failed to get a SDP description from URL "rtsp:// 10.10.10.101:8554/mpeg1or2AudioVideoTest": cannot handle DESCRIBE response: RTSP/1.0 404 File Not Found, Or In Incorrect Format* How do I deal with this? Regards, Hannah -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 13 06:04:44 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 13 Jul 2008 06:04:44 -0700 Subject: [Live-devel] Re : live555 Test Programs In-Reply-To: References: Message-ID: >Do you have a MP3 file named "test.mp3" in the same directory? > >Is the file named "test.mp3" (and other test files) in the live >directory after compiling? No, the file "test.mp3" should be in the "testProgs" directory. > Failed to get a SDP description from URL >"rtsp://10.10.10.101:8554/mpeg1or2AudioVideoTest": >cannot handle DESCRIBE response: RTSP/1.0 404 File Not Found, Or In >Incorrect Format > >How do I deal with this? Sheesh.... Now, does everyone understand why I discriminate against people who use "@gmail.com" email addresses? :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From snk4ever at gmail.com Mon Jul 14 00:12:28 2008 From: snk4ever at gmail.com (Benoit) Date: Mon, 14 Jul 2008 15:12:28 +0800 Subject: [Live-devel] Export a video file from a network capture Message-ID: <487AFC5C.2090101@gmail.com> Hello, My company is developing software for analyzing network traffic, especially from mobile phone operators. We provide them a way to know the quality of service they are providing to their customers. One of the products is analyzing video streaming sessions and we would like to export from a network capture (typical tcpdump file) a video file on our computer's filesystem. I tried the openRTSP client combined to the mediaLive server and it is close to what we want to do. Your software openRTSP already implements the RTSP/RTP protocols and can write a correct media file, 2 functions that we need for our goal. We have some RTSP based streaming sessions in a network capture file and we would like to extract the videos from this capture files. Basically, what differs from the openRTSP program is that I would need to read from a data capture file instead of from a network and to be a listener of an existing RTSP session instead of the client for this RTSP session. Could you give me some hints about what files in the source code I need to change ? I spent some time on the Doxygen documentation and in the source code files : - openRTSP.cpp - RTSPClient.cpp - playCommon.cpp I guess that there is no API and I need to reuse the code of live555 ? Any help would be greatly appreciated. Benoit BEGUE From finlayson at live555.com Mon Jul 14 00:20:19 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 14 Jul 2008 00:20:19 -0700 Subject: [Live-devel] Export a video file from a network capture In-Reply-To: <487AFC5C.2090101@gmail.com> References: <487AFC5C.2090101@gmail.com> Message-ID: >Basically, what differs from the openRTSP program is that I would >need to read from a data capture file instead of from a network and >to be a listener of an existing RTSP session instead of the client >for this RTSP session. Because you have an existing RTSP client application (and data already captured from RTSP/RTP sessions), it seems unlikely that our software could provide much more of what you want. (The most significant part of our software is our RTSP/RTP protocol implementation, which apparently you do not need.) Instead, I suggest just modifying your own RTSP client application, and/or writing your own simple application to read through your "tcpdump" files. (This would probably involve mostly just parsing RTP packets, and stripping off RTP headers, etc.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From silvain.beriault at larus.com Mon Jul 14 08:30:03 2008 From: silvain.beriault at larus.com (Silvain Beriault) Date: Mon, 14 Jul 2008 11:30:03 -0400 Subject: [Live-devel] Live555 with ffmpeg's MJPEG codec Message-ID: <487B70FB.2060804@larus.com> Hello, I am trying to stream real-time video data over RTP using live555 library with MJPEG format. To to so, I created a derived class of JPEGVideoSource. Within the derived class, I have implemented the following methods: a) The doGetNextFrame() method which dequeue an RGB video frame, converts it to YUV420 and then perform JPEG video compression. b) The type() method returns 1 (based on Elphel example) c) The width() and height() methods returns the frame width and height as per JPEG header computed in (a) d) The qFactor() parameter was determined by scaling the ffmpeg's quantizer parameter [0..31] to a jpeg quality factor in the range [0..100]. I am less sure about (d). However, I could observe that when ffmpeg quantizer=4, setting qFactor() = 100-(4/31*100) = 87 gives "proper color" on the receiving side. However, it is still not right. The received video is very jumpy and, typically, the first 100 pixels or so appears at the end of each line of video. I wonder what is going wrong. I know my JPEG encoder/decoder works fine as I did perform the following tests: 1) encode -> decode -> display without using live555 2) encode -> save to jpeg file -> open with any image viewer Also I should add that I am only writing the JPEG payload (not the 623 words header) to fTo buffer. and therefore I set fFrameSize = size-623 On the receiving end (when I combine live555 with ffmpeg jpeg codec), here is the errors returned by ffmpeg decoder: [mjpeg @ 6BEA47E0]mjpeg_decode_dc: bad vlc: 0:0 (003DBEE0) [mjpeg @ 6BEA47E0]error dc [mjpeg @ 6BEA47E0]error y=29 x=34 [mjpeg @ 6BEA47E0]mjpeg_decode_dc: bad vlc: 0:0 (003DBEE0) [mjpeg @ 6BEA47E0]error dc [mjpeg @ 6BEA47E0]error y=29 x=35 [mjpeg @ 6BEA47E0]mjpeg_decode_dc: bad vlc: 0:0 (003DBEE0) [mjpeg @ 6BEA47E0]error dc [mjpeg @ 6BEA47E0]error y=29 x=34 [mjpeg @ 6BEA47E0]mjpeg_decode_dc: bad vlc: 0:0 (003DBEE0) [mjpeg @ 6BEA47E0]error dc [mjpeg @ 6BEA47E0]error y=29 x=34 [mjpeg @ 6BEA47E0]mjpeg_decode_dc: bad vlc: 0:0 (003DBEE0) [mjpeg @ 6BEA47E0]error dc [mjpeg @ 6BEA47E0]error y=29 x=34 [mjpeg @ 6BEA47E0]mjpeg_decode_dc: bad vlc: 0:0 (003DBEE0) [mjpeg @ 6BEA47E0]error dc [mjpeg @ 6BEA47E0]error y=29 x=35 [mjpeg @ 6BEA47E0]mjpeg_decode_dc: bad vlc: 0:0 (003DBEE0) [mjpeg @ 6BEA47E0]error dc [mjpeg @ 6BEA47E0]error y=29 x=37 Any help on that issue would be greatly appreciated Silvain From finlayson at live555.com Mon Jul 14 10:38:46 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 14 Jul 2008 10:38:46 -0700 Subject: [Live-devel] Live555 with ffmpeg's MJPEG codec In-Reply-To: <487B70FB.2060804@larus.com> References: <487B70FB.2060804@larus.com> Message-ID: >I am trying to stream real-time video data over RTP using live555 >library with MJPEG format. To to so, I created a derived class of >JPEGVideoSource. Within the derived class, I have implemented the >following methods: > >a) The doGetNextFrame() method which dequeue an RGB video frame, >converts it to YUV420 and then perform JPEG video compression. Don't forget to also set "fPresentationTime". >On the receiving end (when I combine live555 with ffmpeg jpeg >codec), here is the errors returned by ffmpeg decoder I can't help you with codec (or VLC) problems. However, I suggest that you first use "openRTSP" with the "-m" option to receive each frame as a separate file. If your server code is correct, then each such received file should be a single JPEG image, which you can try viewing with image viewing software. That may help you debug your problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From silvain.beriault at larus.com Mon Jul 14 12:21:36 2008 From: silvain.beriault at larus.com (Silvain Beriault) Date: Mon, 14 Jul 2008 15:21:36 -0400 Subject: [Live-devel] Live555 with ffmpeg's MJPEG codec In-Reply-To: References: <487B70FB.2060804@larus.com> Message-ID: <487BA740.4080704@larus.com> > Don't forget to also set "fPresentationTime". Ok I am setting it properly now, using gettimeofday(), however why is it needed in the case of a jpeg frame? Also, since my code runs on a windows platform, I had to download a custom implementation of this function. > I can't help you with codec (or VLC) problems. However, I suggest > that you first use "openRTSP" with the "-m" option to receive each > frame as a separate file. If your server code is correct, then each > such received file should be a single JPEG image, which you can try > viewing with image viewing software. That may help you debug your > problem. If I don't use live555 it works just fine: i.e. encode to a memory block, decode from a memory block. I tried comparing the original jpeg compressed data with the received data and it seems that the jpeg header is broken. Could it be that JPEGVideoRTPSink fails to reconstruct the original JPEG header for some reason? I'll try running openRTSP now. Silvain From finlayson at live555.com Mon Jul 14 14:59:05 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 14 Jul 2008 14:59:05 -0700 Subject: [Live-devel] Live555 with ffmpeg's MJPEG codec In-Reply-To: <487BA740.4080704@larus.com> References: <487B70FB.2060804@larus.com> <487BA740.4080704@larus.com> Message-ID: >>Don't forget to also set "fPresentationTime". >Ok I am setting it properly now, using gettimeofday(), however why >is it needed in the case of a jpeg frame? Because you're not streaming just one frame; you're streaming a sequence of frames, and the receiver needs to know when to display each one. >>I can't help you with codec (or VLC) problems. However, I suggest >>that you first use "openRTSP" with the "-m" option to receive each >>frame as a separate file. If your server code is correct, then >>each such received file should be a single JPEG image, which you >>can try viewing with image viewing software. That may help you >>debug your problem. > >If I don't use live555 it works just fine: i.e. encode to a memory >block, decode from a memory block. I tried comparing the original >jpeg compressed data with the received data and it seems that the >jpeg header is broken. Could it be that JPEGVideoRTPSink fails to >reconstruct the original JPEG header for some reason? "JPEGVideoRTPSink" (which is used by the RTP sender) doesn't reconstruct the JPEG header. (Remember that the JPEG header is not sent in the RTP packet.) It's the RTP *receiver* ("JPEGVideoRTPSource" in our case) that reconstructs a JPEG header (from the parameters in the RTP payload format header). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From qiujianshu at cnc-labs.com Mon Jul 14 22:43:10 2008 From: qiujianshu at cnc-labs.com (choujs) Date: Tue, 15 Jul 2008 13:43:10 +0800 Subject: [Live-devel] bug report Message-ID: <012001c8e63d$aa9f0180$7685020a@cnc.intra> Hi, I think there is an error in function MPEG2TransportStreamIndexFile::readIndexRecord(). The line: ++fCurrentIndexRecordNum; should be: fCurrentIndexRecordNum = indexRecordNum; is it? From finlayson at live555.com Mon Jul 14 22:56:44 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 14 Jul 2008 22:56:44 -0700 Subject: [Live-devel] bug report In-Reply-To: <012001c8e63d$aa9f0180$7685020a@cnc.intra> References: <012001c8e63d$aa9f0180$7685020a@cnc.intra> Message-ID: >Hi, > >I think there is an error in function >MPEG2TransportStreamIndexFile::readIndexRecord(). >The line: > >++fCurrentIndexRecordNum; > >should be: > >fCurrentIndexRecordNum = indexRecordNum; > >is it? No, the current code is correct. "readIndexRecord(indexRecordNum)" starts by seeking to "indexRecordNum", if we're not already there. In doing so, it sets "fCurrentIndexRecordNum" to "indexRecordNum". The code then reads that record, which means that the next record that would be read (without seeking) would be ""indexRecordNum+1". Therefore, we end by setting "fCurrentIndexRecordNum" to that value. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From qiujianshu at cnc-labs.com Mon Jul 14 23:13:15 2008 From: qiujianshu at cnc-labs.com (choujs) Date: Tue, 15 Jul 2008 14:13:15 +0800 Subject: [Live-devel] bug report References: <012001c8e63d$aa9f0180$7685020a@cnc.intra> Message-ID: <012d01c8e641$de7e6ff0$7685020a@cnc.intra> You are right. Thank you. > >Hi, >> >>I think there is an error in function >>MPEG2TransportStreamIndexFile::readIndexRecord(). >>The line: >> >>++fCurrentIndexRecordNum; >> >>should be: >> >>fCurrentIndexRecordNum = indexRecordNum; >> >>is it? > > No, the current code is correct. "readIndexRecord(indexRecordNum)" > starts by seeking to "indexRecordNum", if we're not already there. > In doing so, it sets "fCurrentIndexRecordNum" to "indexRecordNum". > The code then reads that record, which means that the next record > that would be read (without seeking) would be ""indexRecordNum+1". > Therefore, we end by setting "fCurrentIndexRecordNum" to that value. > -- > > 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 snk4ever at gmail.com Tue Jul 15 02:02:06 2008 From: snk4ever at gmail.com (Benoit) Date: Tue, 15 Jul 2008 17:02:06 +0800 Subject: [Live-devel] Export a video file from a network capture In-Reply-To: References: Message-ID: <487C678E.1000006@gmail.com> > > >/Basically, what differs from the openRTSP program is that I would > />/need to read from a data capture file instead of from a network and > />/to be a listener of an existing RTSP session instead of the client > />/for this RTSP session. > / > Because you have an existing RTSP client application (and data > already captured from RTSP/RTP sessions), it seems unlikely that our > software could provide much more of what you want. (The most > significant part of our software is our RTSP/RTP protocol > implementation, which apparently you do not need.) > > Instead, I suggest just modifying your own RTSP client application, > and/or writing your own simple application to read through your > "tcpdump" files. (This would probably involve mostly just parsing > RTP packets, and stripping off RTP headers, etc.) > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > Actually, I don't have access to the client RTSP application. This RTSP client is embedded in phones like a Nokia with streaming capabilities or any other phone (so I have no access to those phones). So I'm interested by both the RTSP/RTP protocol implementation and by the means to write a compliant video file, by getting the good parameters from the SDP description and building headers of an AVI file so that it can be correctly read afterwards by a media player such as VLC. My application can already export the binary from a RTP packet but if I just do that (and aggregate the packets' payloads of a same RTP session), the resulting binary file is unplayable in any video player. My application already can extract the SDP parameters and can isolate the payloads from the packets but I have no idea how to export a correct video file, this is why I wanted to learn about an API of a hint at how to use this function of the LiveMedia library. Benoit BEGUE From finlayson at live555.com Tue Jul 15 04:55:24 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 15 Jul 2008 04:55:24 -0700 Subject: [Live-devel] Export a video file from a network capture In-Reply-To: <487C678E.1000006@gmail.com> References: <487C678E.1000006@gmail.com> Message-ID: >So I'm interested by both the RTSP/RTP protocol implementation and >by the means to write a compliant video file, by getting the good >parameters from the SDP description and building headers of an AVI >file so that it can be correctly read afterwards by a media player >such as VLC. Note the "-i" option to the "openRTSP" client: . Youc an use this code (for which you have complete source code) as the basis of your application. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From silvain.beriault at larus.com Tue Jul 15 06:35:14 2008 From: silvain.beriault at larus.com (Silvain Beriault) Date: Tue, 15 Jul 2008 09:35:14 -0400 Subject: [Live-devel] Live555 with ffmpeg's MJPEG codec In-Reply-To: References: <487B70FB.2060804@larus.com> <487BA740.4080704@larus.com> Message-ID: <487CA792.1030409@larus.com> >> If I don't use live555 it works just fine: i.e. encode to a memory >> block, decode from a memory block. I tried comparing the original >> jpeg compressed data with the received data and it seems that the >> jpeg header is broken. Could it be that JPEGVideoRTPSink fails to >> reconstruct the original JPEG header for some reason? > > "JPEGVideoRTPSink" (which is used by the RTP sender) doesn't > reconstruct the JPEG header. (Remember that the JPEG header is not > sent in the RTP packet.) It's the RTP *receiver* > ("JPEGVideoRTPSource" in our case) that reconstructs a JPEG header > (from the parameters in the RTP payload format header). JPEGVideoRTPSource is what I meant... Anyhow, I'll continue investigate the problem and if i find the solution, I'll post it to the mailing list. From aligokalppeker at hotmail.com Tue Jul 15 07:34:59 2008 From: aligokalppeker at hotmail.com (=?windows-1254?Q?Ali_G=F6kalp_Peker?=) Date: Tue, 15 Jul 2008 17:34:59 +0300 Subject: [Live-devel] Live 555 RTSP client Problem Message-ID: We use Live 555 in a RTSP client.As a RTSP client we fetch video data (MPEG4 ES ) decode it(with Intel UMC compiler) and send it to other network area and also to disk.We serve an MPEG4ES file using MediaServer.Also we serve video by using axis Video server.These two server is not executed mean-while. While decoding MPEG4 ES frame, decoding part crashes.But in the mean time,when we decode same served m4e file without serving it , it's decoded properly. I set receive buffer to 1024 * 1024 *2 byte and frame reordering threshold to 2 ms. But it has no affect on crashing. Crashing happens randomly. All code written by me is reviewed and any it seems as there is no problem. What can be the error ? Can a data or packet loss cause this? Or anything else? _________________________________________________________________ Windows Live Spaces ? hayat?n?z, Alan?n?z. Daha fazlas?n? ??renmek i?in buraya t?klay?n. http://get.live.com/spaces/overview -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.savarese at dcnsgroup.com Tue Jul 15 07:54:43 2008 From: julien.savarese at dcnsgroup.com (julien.savarese at dcnsgroup.com) Date: Tue, 15 Jul 2008 16:54:43 +0200 Subject: [Live-devel] Have LIVE555 a codec module ? In-Reply-To: Message-ID: <20080715144626.8EAE380401E@smtp-out2.dcn.fr> Helo, I wonder to know if LIVE555 have some CODEC, or just work it with data which just send and receive ?? Thx. _________________________ Julien Savarese Apprenti ing?nieur. Division SIS/DPM/RMS/MIE. --------------------------------------------- Pensez a l'environnement : avez-vous besoin d'imprimer ce message Think Environment : Do you need to print message ? Ce courrier ?lectronique, et ?ventuellement ses pi?ces jointes, peuvent contenir des informations confidentielles et/ou personnelles et a ?t? envoy? uniquement ? l'usage de la personne ou de l'entit? cit?e ci-dessus. Si vous receviez ce courrier ?lectronique par erreur, merci de bien vouloir en avertir l'exp?diteur imm?diatement par la r?ponse en retour ? ce courrier et effacer l'original et d?truire toute copie enregistr?e dans un ordinateur, ou imprim?e ou encore sauvegard?e sur un disque . Toute revue, retransmission ou toute autre forme d'utilisation de ce courrier ?lectronique par toute autre personne que le destinataire pr?vue est strictement interdite. L'internet ne permettant pas d'assurer l'int?grit? de ce message, l'exp?diteur d?cline toute responsabilit? au cas o? il aurait ?t? intercept? ou modifi? par quiconque. This e-mail and possibly any attachment may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above. If you have received it in error, please advise the sender immediately by reply e-mail and delete and destroy all copies including all copies stored in the recipient's computer, printed or saved to disk. . Any review , retransmission, or further use of this e-mail by by persons or entities other than the intended recipient is strictly prohibited. Because of the nature of the Internet the sender is not in a position to ensure the integrity of this message, therefore the sender disclaims any liability whatsoever, in the event of this message having been intercepted and/or altered. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 15 11:31:17 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 15 Jul 2008 11:31:17 -0700 Subject: [Live-devel] Have LIVE555 a codec module ? In-Reply-To: <20080715144626.8EAE380401E@smtp-out2.dcn.fr> References: <20080715144626.8EAE380401E@smtp-out2.dcn.fr> Message-ID: >Helo, I wonder to know if LIVE555 have some CODEC No. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at hovland.org Tue Jul 15 12:08:55 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 15 Jul 2008 12:08:55 -0700 Subject: [Live-devel] obtaining old versions of live555.tar.gz Message-ID: <20080715190855.GA9666@hovland.org> I am likely to freshen the liveMedia tree in the MythTV svn repo whenever Ross puts out the next version of live555. I am hoping I can get a leg up on this by getting a hold of the version of live555 that MythTV originally committed. It looks to be a version circa 2006-06-21. Is it possible to get the tarball that was release before that date? Thanks E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From finlayson at live555.com Tue Jul 15 12:15:14 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 15 Jul 2008 12:15:14 -0700 Subject: [Live-devel] obtaining old versions of live555.tar.gz In-Reply-To: <20080715190855.GA9666@hovland.org> References: <20080715190855.GA9666@hovland.org> Message-ID: >I am likely to freshen the liveMedia tree in the MythTV svn repo >whenever Ross puts out the next version of live555. I am hoping I can >get a leg up on this by getting a hold of the version of live555 that >MythTV originally committed. It looks to be a version circa 2006-06-21. >Is it possible to get the tarball that was release before that date? Sorry no. We do not make available - and do not support - old versions of the source code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From erik at hovland.org Tue Jul 15 12:36:03 2008 From: erik at hovland.org (Erik Hovland) Date: Tue, 15 Jul 2008 12:36:03 -0700 Subject: [Live-devel] obtaining old versions of live555.tar.gz In-Reply-To: References: <20080715190855.GA9666@hovland.org> Message-ID: <20080715193603.GB9666@hovland.org> On Tue, Jul 15, 2008 at 12:15:14PM -0700, Ross Finlayson wrote: >> I am likely to freshen the liveMedia tree in the MythTV svn repo >> whenever Ross puts out the next version of live555. I am hoping I can >> get a leg up on this by getting a hold of the version of live555 that >> MythTV originally committed. It looks to be a version circa 2006-06-21. >> Is it possible to get the tarball that was release before that date? > > Sorry no. We do not make available - and do not support - old versions > of the source code. Thanks for answering. Turns out the wayback machine has a link to it: http://web.archive.org/web/20060329202134/http://www.live555.com/liveMedia/public/ I'll give that a try. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From aligokalppeker at hotmail.com Wed Jul 16 00:26:14 2008 From: aligokalppeker at hotmail.com (=?windows-1254?Q?Ali_G=F6kalp_Peker?=) Date: Wed, 16 Jul 2008 10:26:14 +0300 Subject: [Live-devel] Live 555 RTSP client problem Message-ID: Same issue is mentioned before but any answer is given. What can be the problem ? A network setting ? [Live-devel] live stream problems Gbzbz Gbzbz Wed, 04 Jun 2008 02:57:26 -0700 Hi, We try to stream MPEG4 via RTSP with live555. Our flow is like this DVD -> capture 1 frame (v4l2) ->MPEG4 encoding -> Write_mpeg4_frame to myvideo.v -> send_mpeg4_frame_to_live555 -> MPEG4 decoding -> Display on TV 1. when streaming the file myvideo.v with live555's testOnDemandRTSPServer, VLC shows smooth and great video. 2. TV displays smooth and great video. 3. live streaming from send_mpeg4_frame_to_live555 step shows jitters and errors, we got video, but the quality is crappy from vlc and mplayer. mplayer prints the following [mpeg4 @ 0x3c95184]Error at MB: 312 [mpeg4 @ 0x3c95184]concealing 1097 DC, 1097 AC, 1097 MV errors [mpeg4 @ 0x3c95184]ac-tex damaged at 5 12 [mpeg4 @ 0x3c95184]Error at MB: 557 [mpeg4 @ 0x3c95184]concealing 859 DC, 859 AC, 859 MV errors [mpeg4 @ 0x3c95184]1. marker bit missing in 3. esc [mpeg4 @ 0x3c95184]Error at MB: 364 [mpeg4 @ 0x3c95184]concealing 1043 DC, 1043 AC, 1043 MV errors [mpeg4 @ 0x3c95184]slice end not reached but screenspace end (13352 left 0ABB06, score= -319) [mpeg4 @ 0x3c95184]concealing 1350 DC, 1350 AC, 1350 MV errors [mpeg4 @ 0x3c95184]1. marker bit missing in 3. esc [mpeg4 @ 0x3c95184]Error at MB: 108 [mpeg4 @ 0x3c95184]concealing 1294 DC, 1294 AC, 1294 MV errors [mpeg4 @ 0x3c95184]ac-tex damaged at 0 4 [mpeg4 @ 0x3c95184]Error at MB: 184 [mpeg4 @ 0x3c95184]concealing 1226 DC, 1226 AC, 1226 MV errors [mpeg4 @ 0x3c95184]slice end not reached but screenspace end (10462 left 132915, score= -320) [mpeg4 @ 0x3c95184]concealing 1350 DC, 1350 AC, 1350 MV errors [mpeg4 @ 0x3c95184]cbpc damaged at 17 9 [mpeg4 @ 0x3c95184]Error at MB: 431 [mpeg4 @ 0x3c95184]concealing 979 DC, 979 AC, 979 MV errors [mpeg4 @ 0x3c95184]slice end not reached but screenspace end (3571 left 0A7BE8, score= -320) [mpeg4 @ 0x3c95184]concealing 1350 DC, 1350 AC, 1350 MV errors [mpeg4 @ 0x3c95184]dc marker bit missing [mpeg4 @ 0x3c95184]Error at MB: 255 [mpeg4 @ 0x3c95184]concealing 1153 DC, 1153 AC, 1153 MV errors [mpeg4 @ 0x3c95184]slice end not reached but screenspace end (10368 left 7F1D5E, score= -322) [mpeg4 @ 0x3c95184]concealing 1350 DC, 1350 AC, 1350 MV errors [mpeg4 @ 0x3c95184]concealing 3 DC, 3 AC, 3 MV errors [mpeg4 @ 0x3c95184]ac-tex damaged at 8 9 [mpeg4 @ 0x3c95184]Error at MB: 422 [mpeg4 @ 0x3c95184]concealing 992 DC, 992 AC, 992 MV errors [mpeg4 @ 0x3c95184]ac-tex damaged at 10 2 [mpeg4 @ 0x3c95184]Error at MB: 102 [mpeg4 @ 0x3c95184]concealing 1312 DC, 1312 AC, 1312 MV errors [mpeg4 @ 0x3c95184]concealing 28 DC, 28 AC, 28 MV errors [mpeg4 @ 0x3c95184]illegal dc vlc0 [mpeg4 @ 0x3c95184]Error at MB: 928 [mpeg4 @ 0x3c95184]concealing 497 DC, 497 AC, 497 MV errors [mpeg4 @ 0x3c95184]1. marker bit missing in 3. esc [mpeg4 @ 0x3c95184]Error at MB: 211 [mpeg4 @ 0x3c95184]concealing 1207 DC, 1207 AC, 1207 MV errors [mpeg4 @ 0x3c95184]slice end not reached but screenspace end (1118 left 110469, score= -329) [mpeg4 @ 0x3c95184]concealing 1350 DC, 1350 AC, 1350 MV errors Anyone can help me? I am not familiar with MPEG stuff at all, still learning..... Thanks! _________________________________________________________________ ?imdi aileye kat?lman?n tam zaman? - Yeni nesil ?cretsiz Windows Live Hizmetlerini ?imdi edinin! http://get.live.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.savarese at dcnsgroup.com Wed Jul 16 01:02:26 2008 From: julien.savarese at dcnsgroup.com (julien.savarese at dcnsgroup.com) Date: Wed, 16 Jul 2008 10:02:26 +0200 Subject: [Live-devel] datagramme structure of LIVE555 In-Reply-To: Message-ID: <20080716075404.19F11804029@smtp-out2.dcn.fr> Hello, Is there a datagramme structure of LIVE555 , to show what is the general structure of LIVE555 ??? Thx. _________________________ Julien Savarese Apprenti ing?nieur. Division SIS/DPM/RMS/MIE. --------------------------------------------- Pensez a l'environnement : avez-vous besoin d'imprimer ce message Think Environment : Do you need to print message ? Ce courrier ?lectronique, et ?ventuellement ses pi?ces jointes, peuvent contenir des informations confidentielles et/ou personnelles et a ?t? envoy? uniquement ? l'usage de la personne ou de l'entit? cit?e ci-dessus. Si vous receviez ce courrier ?lectronique par erreur, merci de bien vouloir en avertir l'exp?diteur imm?diatement par la r?ponse en retour ? ce courrier et effacer l'original et d?truire toute copie enregistr?e dans un ordinateur, ou imprim?e ou encore sauvegard?e sur un disque . Toute revue, retransmission ou toute autre forme d'utilisation de ce courrier ?lectronique par toute autre personne que le destinataire pr?vue est strictement interdite. L'internet ne permettant pas d'assurer l'int?grit? de ce message, l'exp?diteur d?cline toute responsabilit? au cas o? il aurait ?t? intercept? ou modifi? par quiconque. This e-mail and possibly any attachment may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above. If you have received it in error, please advise the sender immediately by reply e-mail and delete and destroy all copies including all copies stored in the recipient's computer, printed or saved to disk. . Any review , retransmission, or further use of this e-mail by by persons or entities other than the intended recipient is strictly prohibited. Because of the nature of the Internet the sender is not in a position to ensure the integrity of this message, therefore the sender disclaims any liability whatsoever, in the event of this message having been intercepted and/or altered. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRawling at pelco.com Wed Jul 16 13:57:39 2008 From: SRawling at pelco.com (Rawling, Stuart) Date: Wed, 16 Jul 2008 13:57:39 -0700 Subject: [Live-devel] RTSP REDIRECT Message-ID: Does anybody know if it is possible to send a REDIRECT rtsp message from the RTSPServer? My custom Rtsp Server implementation process raw meg4 element streams from other network devices, and presents these streams through the Live555. Some of the network devices implement a custom initiation protocol (for which I am streaming successfully from), and some also present a rtsp service (also based on live555). For this second scenario I would like to return with a REDIRECT message when the device source has a RTSP server running. I read here: that I might just be able to respond to the request with a 302 message on the describe. If this is the case, are there any suggestions on how to implement this in Live555? Thanks Stuart - ------------------------------------------------------------------------------ Confidentiality Notice: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual(s) or entities named above. This email and any files transmitted with it are the property of Pelco. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you receive this communication in error, please notify us immediately by telephone call to +1-559-292-1981 or forward the e-mail to administrator at pelco.com and then permanently delete the e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation. - ------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 16 14:31:27 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 16 Jul 2008 14:31:27 -0700 Subject: [Live-devel] RTSP REDIRECT In-Reply-To: References: Message-ID: >Does anybody know if it is possible to send a REDIRECT rtsp message >from the RTSPServer? Our RTSP server implementation currently does not implement any server->client requests (including "REDIRECT"). Implementing such requests is a low priority (in part because I think that server->client requests are generally a bad idea). >My custom Rtsp Server implementation process raw meg4 element >streams from other network devices, and presents these streams >through the Live555. Some of the network devices implement a custom >initiation protocol (for which I am streaming successfully from), >and some also present a rtsp service (also based on live555). For >this second scenario I would like to return with a REDIRECT message >when the device source has a RTSP server running. A better (cleaner and more portable) solution for your second case would be for your server to simply relay the initial RTSP "DESCRIBE" request on to your back-end server, and let it handle this request (and all subsequent requests, which would also get relayed). If you do this, then the client will be able to treat this like a normal RTSP protocol exchange (and therefore will not need to implement "REDIRECT" either). To do this, you would need to modify our RTSP server implementation (in particular the "RTSPClientSession" class) to handle the TCP relaying. The only drawback with this approach is that you would end up with two TCP connections for each client session: one connection between the client and the front-end server, and another connection between the front-end and back-end server. In your case, this is probably OK, though, because the front-end server is going to stay in existence at least as long as the back-end server. (The actual RTP/RTCP UDP packets can come directly from the back-end server, and would not need to be relayed, unless you're doing RTP-over-TCP.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tua57044 at temple.edu Wed Jul 16 14:32:56 2008 From: tua57044 at temple.edu (Grae Cullen) Date: Wed, 16 Jul 2008 17:32:56 -0400 (EDT) Subject: [Live-devel] setMediaSessionParameter Response Message-ID: <20080716173256.CLF95734@po-a.temple.edu> Hi all, I am trying write program to track switching on mp4 files. Like switch resolutions on the fly. My current plan is to add a parameter called track, and set it with the setMediaSessionParamter() function. However, I would like to see the response message sent by the server. This is because, I want the server to respond with the time or position code. (I haven't defined that yet.) This would allow the client to interpolate the right frame. It also might allow the server to respond with new media information for the other track, such as, picture parameter set (PPS), and sequence parameter set (SPS) in mp4. I think having the response send tell that information will lower latency in the switch. I guess the simple answer would be there is a way to access the response through live555 already. Otherwise, does anyone have any advice how this might be done. Thanks, Grae From finlayson at live555.com Wed Jul 16 15:11:14 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 16 Jul 2008 15:11:14 -0700 Subject: [Live-devel] setMediaSessionParameter Response In-Reply-To: <20080716173256.CLF95734@po-a.temple.edu> References: <20080716173256.CLF95734@po-a.temple.edu> Message-ID: > I am trying write program to track switching on mp4 files. > Like switch resolutions on the fly. My current plan is to >add a parameter called track, and set it with the >setMediaSessionParamter() function. > > However, I would like to see the response message sent by >the server. This is because, I want the server to respond >with the time or position code. (I haven't defined that yet.) > This would allow the client to interpolate the right frame. > It also might allow the server to respond with new media >information for the other track, such as, picture parameter >set (PPS), and sequence parameter set (SPS) in mp4. I'm not totally sure I understand your question, but once a stream has begun, any changes in codec parameters are best conveyed within the media stream itself - and therefore, of course, the client's decoder has to be able to handle any such dynamic changes. In particular, changes to PPS and SPS are best handled by having the server just send new NAL units (in-band) that contain the new values. It's not a good idea to expect the server to signal such changes back to the client (in the 'control channel'). Even if this were possible (which it's probably not), you couldn't expect many clients to be able to handle this anyway. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tua57044 at temple.edu Wed Jul 16 18:27:04 2008 From: tua57044 at temple.edu (Grae Cullen) Date: Wed, 16 Jul 2008 21:27:04 -0400 (EDT) Subject: [Live-devel] setMediaSessionParameter Response Message-ID: <20080716212704.CLH09009@po-a.temple.edu> Hello, Thanks, a lot for the very quick response. >I'm not totally sure I understand your question, but once a stream >has begun, any changes in codec parameters are best conveyed within >the media stream itself - and therefore, of course, the client's >decoder has to be able to handle any such dynamic changes. In >particular, changes to PPS and SPS are best handled by having the >server just send new NAL units (in-band) that contain the new values. > I kind of agree with you about the SPS and PPS. It does makes sense to send them in band. I am by no means an expert at this kind of thing. >It's not a good idea to expect the server to signal such changes back >to the client (in the 'control channel'). I guess I still would like some sort of signal back from the server out of band. This is because the client would have a hard time telling when the changes were to take effect, without the some sort of control message. I guess I could maybe parse each NAL unit to see if it a new different SPS or PPS. Is it very hard to rewrite setMediaSessionParameter()? I haven't looked at the code, but imagine you having to read the response data anyway, and then the program just chooses to drop it. > you couldn't expect many clients to be >able to handle this anyway. My group has to rewrite the live555 module in vlc, and the video on demand rtsp code in vlc. I am not sure which module that is in the code. However, since we only have two and half weeks left, and still have to write paper and make website, I doubt I will have time to finish all I want to. That being say, I would like to leave some kind of clear information for the remaining students, and the group coming in next summer. (It is summer research.) Anyway, thanks for you help. If you have anything else you think I should know, please do tell me, it will probably help me or them. Thanks, Grae Cullen God Bless you From finlayson at live555.com Wed Jul 16 18:37:43 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 16 Jul 2008 18:37:43 -0700 Subject: [Live-devel] setMediaSessionParameter Response In-Reply-To: <20080716212704.CLH09009@po-a.temple.edu> References: <20080716212704.CLH09009@po-a.temple.edu> Message-ID: > I guess I still would like some sort of signal back from >the server out of band. This is because the client would have >a hard time telling when the changes were to take effect, >without the some sort of control message. Why? I don't understand. Your decoder is receiving/decoding/displaying MPEG-4 (H.264?) data. At some point, during the stream, the data parameters change (in some way). But these data parameters are already represented (or can be represented) in-band - i.e., within the encoded data. So why can't your decoder just recognize and handle the change of parameters, when this occurs? If you just make sure that your decoder can handle in-band parameter changes, then you won't need to change any RTSP server or client code, and your application will be more portable (to different servers and clients). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From tua57044 at temple.edu Wed Jul 16 20:17:01 2008 From: tua57044 at temple.edu (Grae Cullen) Date: Wed, 16 Jul 2008 23:17:01 -0400 (EDT) Subject: [Live-devel] setMediaSessionParameter Response Message-ID: <20080716231701.CLH14940@po-a.temple.edu> >Why? I don't understand. Your decoder is >receiving/decoding/displaying MPEG-4 (H.264?) data. At some point, >during the stream, the data parameters change (in some way). But >these data parameters are already represented (or can be represented) >in-band - i.e., within the encoded data. So why can't your decoder >just recognize and handle the change of parameters, when this occurs? > That really is a much better way of doing it. Your way is much more modular. I think, it will much easier to test, also; the decoder could decode the files locally. > >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ Thank You, Mr. Finlayson you have been very helpful. God Bless you, Grae Cullen From silvain.beriault at larus.com Thu Jul 17 11:42:59 2008 From: silvain.beriault at larus.com (Silvain Beriault) Date: Thu, 17 Jul 2008 14:42:59 -0400 Subject: [Live-devel] Live555 with ffmpeg's MJPEG codec In-Reply-To: <487CA792.1030409@larus.com> References: <487B70FB.2060804@larus.com> <487BA740.4080704@larus.com> <487CA792.1030409@larus.com> Message-ID: <487F92B3.5020207@larus.com> > >> >> "JPEGVideoRTPSink" (which is used by the RTP sender) doesn't >> reconstruct the JPEG header. (Remember that the JPEG header is not >> sent in the RTP packet.) It's the RTP *receiver* >> ("JPEGVideoRTPSource" in our case) that reconstructs a JPEG header >> (from the parameters in the RTP payload format header). > If I don't use live555 it works just fine: i.e. encode to a memory > block, decode from a memory block. I tried comparing the original > jpeg compressed data with the received data and it seems that the jpeg > header is broken. Could it be that JPEGVideoRTPSink fails to > reconstruct the original JPEG header for some reason? > > > JPEGVideoRTPSource is what I meant... Anyhow, I'll continue > investigate the problem and if i find the solution, I'll post it to > the mailing list. Ok I have performed additional tests and it seems that not all JPEG images can be transferred with RFC 2435 (which is what is implemented in the JPEGVideoRTPSink/JPEGVideoRTPSource). To demonstrate this, I am submitting test1_in.jpg and test2_in.jpg which are two valid JPEG image (which can be displayed using any jpeg viewer). test1_in.jpg was encoded using ffmpeg's mjpeg encoder (with quantizer = 4). and test2_in.jpg correspond to the same scene but encoded using Microsoft Photo Editor (with quality factor = 74). test1_in.jpg and test2_in.jpg are inputs to a JPEGVideoSource derived class. On the other hand, test1_out.jpg and test2_out.jpg corresponds to the data received and reconstructed by a JPEGVideoRTPSource. We can see that test2_out.jpg is perfectly reconstructed (even if there are minor differences between the jpeg header from test2_in.jpg and test2_out.jpg). Howerver, test1_out.jpg is not reconstructed correctly. Major differences can be observed between the 623 bytes of JPEG header of test1_in.jpg and test1_out.jpg. Visually the test1_out.jpg is shifted horizontally and the colors are off. The color/luminance problem may be attributed to the conversion from the 0..31 quantizer value (ffmpeg mjpeg parameter) to the more conventional JPEG's quality factor. However, this does not explain why the image is shifted. All images can be downloaded here: http://www.larus.com/~sberiault/ Any help on that issue is highly appreciated! Silvain PS. I am also including "hex" dump of each jpeg file (need to right-click and do a "save-as") From finlayson at live555.com Thu Jul 17 23:09:32 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 17 Jul 2008 23:09:32 -0700 Subject: [Live-devel] Live555 with ffmpeg's MJPEG codec In-Reply-To: <487F92B3.5020207@larus.com> References: <487B70FB.2060804@larus.com> <487BA740.4080704@larus.com> <487CA792.1030409@larus.com> <487F92B3.5020207@larus.com> Message-ID: >Ok I have performed additional tests and it seems that not all JPEG >images can be transferred with RFC 2435 That's correct. As the RFC explains, this payload format handles only a subset of the full JPEG standard. >We can see that test2_out.jpg is perfectly reconstructed (even if >there are minor differences between the jpeg header from >test2_in.jpg and test2_out.jpg). Howerver, test1_out.jpg is not >reconstructed correctly. Major differences can be observed between >the 623 bytes of JPEG header of test1_in.jpg and test1_out.jpg. >Visually the test1_out.jpg is shifted horizontally and the colors >are off. The color/luminance problem may be attributed to the >conversion from the 0..31 quantizer value (ffmpeg mjpeg parameter) >to the more conventional JPEG's quality factor. You may be able to overcome this by providing your own (i.e., non-default) quantization tables. You can do this by implementing your own version of the virtual function quantizationTables() in your "JPEGVideoSource" subclass. (See "liveMedia/include/JPEGVideoSource.hh") > However, this does not explain why the image is shifted. No, I can't explain this either. As you've discovered, JPEG is a poor codec for video streaming, if only because its frames are much larger - on average - than those generated by other, video-specific codecs. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kumar.bala at DSP-Weuffen.de Fri Jul 18 01:01:51 2008 From: kumar.bala at DSP-Weuffen.de (Kumar Bala) Date: Fri, 18 Jul 2008 10:01:51 +0200 Subject: [Live-devel] Windows vs Linux RTSP/RTP/UDP difference Message-ID: <48804DEF.2060507@dsp-weuffen.de> Hello All, I am facing a bizarre platform dependent problem in streaming real time Mpeg 4 (Standard and High Definition). I have an embedded linux where I capture a live video and convert it into MPEG4 frames (using a hardware encoder). I use MPEG4DiscreteStreamFramer to stream these frames using modified testOnDemandRTSP example. I have almost negligible latency when my client (mplayer) runs on a linux platform. But the same sources (at least rtp relevant part) when compiled on windows using mingw shows a huge latency of about 2 to 2.5 sec. Has anyone else faced these problems before ? Are they related to lower level protocol implementation ? Any suggestion would of great help. From babitha at oneviewsystems.com Fri Jul 18 03:44:26 2008 From: babitha at oneviewsystems.com (Babitha) Date: Fri, 18 Jul 2008 16:14:26 +0530 Subject: [Live-devel] Help with openRTSP - windows Message-ID: <4880740A.304@oneviewsystems.com> Hi all, I have compiled openRTSP in windows.On executing the openRTSP.exe, I get an error The ordinal 1346 could not be located in the dynamic link library COREDLL.dll.Can anybody help me? Thanks in Advance, Babitha From marco.breviario at eletechsrl.it Fri Jul 18 03:48:17 2008 From: marco.breviario at eletechsrl.it (Breviario Marco) Date: Fri, 18 Jul 2008 12:48:17 +0200 Subject: [Live-devel] session state Message-ID: <001101c8e8c3$c985b930$c1d8a8c0@emdomain.local> Using the testOnDemandRTSPServer example I request media to server and I can start and stop the streaming. >From the server point of view, after the calls to "doEventLoop()" how can I get information about the state of the session (INIT, READY or PLAY states)? Thanks in advance, Marco From finlayson at live555.com Fri Jul 18 05:20:32 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 18 Jul 2008 05:20:32 -0700 Subject: [Live-devel] session state In-Reply-To: <001101c8e8c3$c985b930$c1d8a8c0@emdomain.local> References: <001101c8e8c3$c985b930$c1d8a8c0@emdomain.local> Message-ID: >From the server point of view, after the calls to "doEventLoop()" how can I >get information about the state of the session (INIT, READY or PLAY states)? There's really no way to do this with the current code. The 'session state' that you are looking for would be a property of each "RTSPServer::RTSPClientSession" object, so you'd first need to modify the code to (somehow) get pointers to those objects. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From otavio.ramos at gmail.com Fri Jul 18 05:51:33 2008 From: otavio.ramos at gmail.com (Otavio Rodrigues) Date: Fri, 18 Jul 2008 09:51:33 -0300 Subject: [Live-devel] how can I listen the musics? Message-ID: Hi, I downloaded live555 and started the server properly, but I can't find out how to listen to the musics that I stream. How do I listen to them, what is the adress? thanks best regards otavio From wangmeimeikimo at yahoo.com.tw Fri Jul 18 08:10:29 2008 From: wangmeimeikimo at yahoo.com.tw (wangmeimeikimo) Date: Fri, 18 Jul 2008 23:10:29 +0800 (CST) Subject: [Live-devel] a problem about RTSP for Wince Message-ID: <424841.58619.qm@web72206.mail.tp2.yahoo.com> First, Live555?that it seems no config.wince or config.ppc or else and I want to use live to VLC(a mediaplayer). so I download VLC and use VLC offical cross-compiler. this portion had been done (I can use VLC on Wince) Second, I want to use RTSP on VLC,and the live555 says"If no "config." file exists for your target platform, then try using one of the existing files as a template". I generate a config.wince file. I solve the error(the cross-compiler generate errors), and?in the testProg I openRTSP?had been produced. I transmit the file to Wince, but?I get error report So,?I hope someone can help me, please. Because I try some many way, but it still?does not work I hope?someone help me. thank?you!? _______________________________________________________________________________________________________ ????????????????? ???????? http://sev.search.yahoo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Fri Jul 18 10:02:42 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 18 Jul 2008 10:02:42 -0700 Subject: [Live-devel] a problem about RTSP for Wince In-Reply-To: <424841.58619.qm@web72206.mail.tp2.yahoo.com> References: <424841.58619.qm@web72206.mail.tp2.yahoo.com> Message-ID: >First, Live555 that it seems no config.wince or config.ppc or else >and I want to use live to VLC(a mediaplayer). so I download VLC and >use VLC offical cross-compiler. this portion had been done (I can >use VLC on Wince) Questions about compiling VLC should be sent to a VLC mailing list. I think that when people build VLC for Windows, they usually use Cygwin. I'm not sure about WinCE though... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From manuel at iopenermedia.com Mon Jul 21 00:01:52 2008 From: manuel at iopenermedia.com (Manuel Rejen) Date: Mon, 21 Jul 2008 00:01:52 -0700 Subject: [Live-devel] Streaming live telemetry data Message-ID: <634479B79F7BFC408235EAF9195758050123D19BABD1@EXVMBX016-1.exch016.msoutlookonline.net> Hi all, I am new here and have a question about streaming non multimedia data. I want to stream live telemetry data (so no video or audio) over the internet (bandwidth for each stream 2kbps) to thousands of connected clients simultaneously. I think RTSP(T) is the right protocol for this because the clients can be behind firewalls etc. I understand that I need a custom client to receive the RTSP(T) stream to visualize it. Is this scenario possible with Live555 Media Server and openRTSP ? If not can anyone please point me in the right direction for a possible solution ? Thanks, Manuel Rejen -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatomauro at libero.it Mon Jul 21 04:49:30 2008 From: renatomauro at libero.it (Renato MAURO (Libero)) Date: Mon, 21 Jul 2008 13:49:30 +0200 Subject: [Live-devel] Max limit for RTSPClientSession instances? Message-ID: <003001c8eb27$d694ff80$2e020a0a@CSystemDev> Hi. I wrote an RTSPServer application using Live555. I have 36 different sessions, each with one video subsession. It works and have one limit only: it seems to be impossible to serve more than 32 client requests at a time(no difference between 32 clients on the same session or one client on 32 out of 36 sessions). On the client side, the , rtspClient->sendOptionsCmd(url) methos fails. I will debug my application more deeply in order to understand where, on the server side, the client request is not satisfied; by now my "high level analysis" question is: is there any max limit for RTSPClientSession instances? Thank you very much, Renato MAURO -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Mon Jul 21 04:58:14 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 21 Jul 2008 04:58:14 -0700 Subject: [Live-devel] Streaming live telemetry data In-Reply-To: <634479B79F7BFC408235EAF9195758050123D19BABD1@EXVMBX016-1.exch016.msoutloo konline.net> References: <634479B79F7BFC408235EAF9195758050123D19BABD1@EXVMBX016-1.exch016.msoutloo konline.net> Message-ID: >I am new here and have a question about streaming non multimedia data. > >I want to stream live telemetry data (so no video or audio) over the >internet (bandwidth for each stream 2kbps) to thousands of connected >clients simultaneously. >I think RTSP(T) is the right protocol for this because the clients >can be behind firewalls etc. >I understand that I need a custom client to receive the RTSP(T) >stream to visualize it. > >Is this scenario possible with Live555 Media Server and openRTSP ? Yes - however, because you want to use a RTP payload format that we don't already implement, you will need to implement your own subclasses of "MultiFramedRTPSink" (for sending) and "MultiFramedRTPSource" (for receiving). (Look at the many existing examples in the code.) Also, at the RTSP server end, you will need to implement your own subclass of "ServerMediaSubsession" (that uses your "MultiFramedRTPSink" subclass, and your input source). Once again, there are several examples in the code of ""ServerMediaSubsession" subsessions. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 21 04:56:52 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 21 Jul 2008 04:56:52 -0700 Subject: [Live-devel] Max limit for RTSPClientSession instances? In-Reply-To: <003001c8eb27$d694ff80$2e020a0a@CSystemDev> References: <003001c8eb27$d694ff80$2e020a0a@CSystemDev> Message-ID: > I wrote an RTSPServer application using Live555. I have 36 >different sessions, each with one video subsession. It works and >have one limit only: it seems to be impossible to serve more than 32 >client requests at a time(no difference between 32 clients on the >same session or one client on 32 out of 36 sessions). On the client >side, the , rtspClient->sendOptionsCmd(url) methos fails. > > I will debug my application more deeply in order to understand >where, on the server side, the client request is not satisfied; by >now my "high level analysis" question is: is there any max limit for >RTSPClientSession instances? Not in our code; however, you may have run into a limit - in your operating system - of how many open files it can have (for each process) at a time. Depending on your OS, there should be a way to increase that limit. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatomauro at libero.it Mon Jul 21 07:05:15 2008 From: renatomauro at libero.it (Renato MAURO (Libero)) Date: Mon, 21 Jul 2008 16:05:15 +0200 Subject: [Live-devel] Max limit for RTSPClientSession instances? References: <003001c8eb27$d694ff80$2e020a0a@CSystemDev> Message-ID: <00d301c8eb3a$cdada940$2e020a0a@CSystemDev> Re: [Live-devel] Max limit for RTSPClientSession instances>you may have run into a limit - in your operating system - of how many open files it can have; Thank you for your fast response. I'm not reading data from files; my application receives data from a custom HW and uses Live555 to receive the streams from the HW and offer them through RSTPServer. I found that the 36 input streams are well received. The first 32 (and just now I reached 34) clients are well accepted. Using TcpView, I see 210 active sockets, i.e. (36 in + 34 out)*(1 rtp + 2 UDP) = 210; besides there is one RTP socket opened and closed due to the 35th client's periodic attempt to get its stream. For your information, I have 37 environments, each with its own doEventLoop thread; one is for the unique RTSPServer instance and the others for the 36 RTSPClient instances. The RSTPServer has 36 session instances, which are fed via circular buffer (a new DeviceSource). Do you think I run into an "max open socket" limit (even if 210 is much less than 65535)? Thank you very much, Renato MAURO ----- Original Message ----- From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Monday, July 21, 2008 1:56 PM Subject: Re: [Live-devel] Max limit for RTSPClientSession instances? I wrote an RTSPServer application using Live555. I have 36 different sessions, each with one video subsession. It works and have one limit only: it seems to be impossible to serve more than 32 client requests at a time(no difference between 32 clients on the same session or one client on 32 out of 36 sessions). On the client side, the , rtspClient->sendOptionsCmd(url) methos fails. I will debug my application more deeply in order to understand where, on the server side, the client request is not satisfied; by now my "high level analysis" question is: is there any max limit for RTSPClientSession instances? Not in our code; however, you may have run into a limit - in your operating system - of how many open files it can have (for each process) at a time. Depending on your OS, there should be a way to increase that limit. -- 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 icotoi at rolabs.com Mon Jul 21 07:53:28 2008 From: icotoi at rolabs.com (Ionut Cotoi) Date: Mon, 21 Jul 2008 17:53:28 +0300 Subject: [Live-devel] PES to Transport Stream Framer Message-ID: <4884A2E8.7030301@rolabs.com> Hi, I am trying to write a little application that reads an Program Elementary Stream from a file, puts it trough a transport stream multiplexer and sends it over UDP. My problem is that instead of sending with the right bitrate, this will stream as fast as it can to the network and overflow VLC. If I feed the MPEG2TransportStreamFramer from a ts file everything works ok. Can anyone give me a hint on what I am not doing right? What I do is basically this: { ByteStreamFileSource* fileSource = ByteStreamFileSource::createNew(*env, inputFileName); if (fileSource == NULL) { *env << "Unable to open file \"" << inputFileName << "\" as a byte-stream file source\n"; exit(1); } MPEG2TransportStreamFromPESSource* tsFrames; MPEG2TransportStreamFramer* tsFramer; FramedSource* esVideoSource; MPEG1or2Demux* baseDemultiplexor = MPEG1or2Demux::createNew(*env, fileSource); MPEG1or2DemuxedElementaryStream *videoES = baseDemultiplexor->newRawPESStream(); tsFrames = MPEG2TransportStreamFromPESSource::createNew(*env, videoES); tsFramer = MPEG2TransportStreamFramer::createNew(*env, tsFrames); // Finally, start playing: *env << "Beginning to read from file...\n"; videoSink->startPlaying(*tsFramer, afterPlaying, videoSink); } Best regards, Ionut Cotoi From hartman at videolan.org Mon Jul 21 13:23:41 2008 From: hartman at videolan.org (Derk-Jan Hartman) Date: Mon, 21 Jul 2008 22:23:41 +0200 Subject: [Live-devel] hang on connect() of sendOptionsCmd with invalid address Message-ID: He Ross, This is about https://trac.videolan.org/vlc/ticket/1730 It takes a long while before an invalid/non-present address is rejected. For instance we use: rtsp://10.90.33.109 Now if live555 starts working on that, it hangs on connect() in the sendOptionsCmd(). The describeURL does not have this problem. It returns quite quickly with: DESCRIBE failed with 0: connect() failed: Operation timed out DJ From finlayson at live555.com Mon Jul 21 15:06:37 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 21 Jul 2008 15:06:37 -0700 Subject: [Live-devel] hang on connect() of sendOptionsCmd with invalid address In-Reply-To: References: Message-ID: >This is about https://trac.videolan.org/vlc/ticket/1730 >It takes a long while before an invalid/non-present address is rejected. > >For instance we use: rtsp://10.90.33.109 > >Now if live555 starts working on that, it hangs on connect() in the >sendOptionsCmd(). The describeURL does not have this problem. It >returns quite quickly with: DESCRIBE failed with 0: connect() >failed: Operation timed out Actually, both "sendOptionsCmd()" and "describeURL()" should do the same thing (call "connect()"), so I'm surprised that they behave the same way in your case. But anyway, if the call to connect() hangs - as it is apparently doing here - then there's not much we can do. (There's no 'timeout' parameter to connect().) I'm not sure why the connect() call is hanging when given an invalid address, though; that's the real problem... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 21 15:16:18 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 21 Jul 2008 15:16:18 -0700 Subject: [Live-devel] PES to Transport Stream Framer In-Reply-To: <4884A2E8.7030301@rolabs.com> References: <4884A2E8.7030301@rolabs.com> Message-ID: >My problem is that instead of sending with the right bitrate, this >will stream as fast as it can to the network When this happens, it's usually because your 'framer' object is not able to compute the duration of each Transport Packet (and so, each packet gets the default duration of 0). The reason for this is probably that your "MPEG2TransportStreamFramer" is not finding PCRs in the Transport Stream data. >What I do is basically this: >{ > ByteStreamFileSource* fileSource > = ByteStreamFileSource::createNew(*env, inputFileName); > if (fileSource == NULL) { > *env << "Unable to open file \"" << inputFileName > << "\" as a byte-stream file source\n"; > exit(1); > } > MPEG2TransportStreamFromPESSource* tsFrames; > MPEG2TransportStreamFramer* tsFramer; > FramedSource* esVideoSource; > > MPEG1or2Demux* baseDemultiplexor = MPEG1or2Demux::createNew(*env, >fileSource); > > MPEG1or2DemuxedElementaryStream *videoES = >baseDemultiplexor->newRawPESStream(); > > tsFrames = MPEG2TransportStreamFromPESSource::createNew(*env, videoES); > > tsFramer = MPEG2TransportStreamFramer::createNew(*env, tsFrames); This looks good. However, you should first try just converting the Program Stream file into a Transport Stream file, e.g., using our "testMPEG1or2ProgramToTransportStream" demo application (whose code you have adapted). I.e., first try to generate a Transport Stream file from your Program Stream file. Then, try to stream that file. That may give you some insight into what is going wrong. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jul 21 16:49:14 2008 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 21 Jul 2008 16:49:14 -0700 Subject: [Live-devel] Max limit for RTSPClientSession instances? In-Reply-To: <00d301c8eb3a$cdada940$2e020a0a@CSystemDev> References: <003001c8eb27$d694ff80$2e020a0a@CSystemDev> <00d301c8eb3a$cdada940$2e020a0a@CSystemDev> Message-ID: >Do you think I run into an "max open socket" limit (even if 210 is >much less than 65535)? I don't know. But in any case, there's no preset limit in our code, so you must be running into some limit in your OS. (Because you are running multiple threads, perhaps you are running into a limit in the number of threads per process. Perhaps you could instead try running your clients as separate processes?) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aahmoud at paraxip.com Mon Jul 21 18:08:29 2008 From: aahmoud at paraxip.com (ahmoud alkassoum) Date: Mon, 21 Jul 2008 18:08:29 -0700 (PDT) Subject: [Live-devel] Re : Max limit for RTSPClientSession instances? Message-ID: <216587.31767.qm@web703.biz.mail.mud.yahoo.com> Hi Mauro, If you are running your application under windows you might have the same problem i had few months ago. My problem was due to an windows OS limitation on the number of sockets that can be open at any one time. On windows the FD_SETSIZE parameter have a default value of 64, so with that default value, the server can only handle 64/2 = 32 clients at the same time ( 2 sockets per client). So to solve my problem i only had to increase the FD_SETSIZE parameter. Hope that this information did help you. Alkassoum ----- Message d'origine ---- De : Renato MAURO (Libero) ? : LIVE555 Streaming Media - development & use Envoy? le : Lundi, 21 Juillet 2008, 16h05mn 15s Objet : Re: [Live-devel] Max limit for RTSPClientSession instances? Re: [Live-devel] Max limit for RTSPClientSession instances >you may have run into a limit - in your operating system - of how many open files it can have; Thank you for your fast response. I'm not reading data from files; my application receives data from a custom HW and uses Live555 to receive the streams from the HW and offer them through RSTPServer. I found that the 36 input streams are well received. The first 32 (and just now I reached 34) clients are well accepted. Using TcpView, I see 210 active sockets, i.e. (36 in + 34 out)*(1 rtp + 2 UDP) = 210; besides there is one RTP socket opened and closed due to the 35th client's periodic attempt to get its stream. For your information, I have 37 environments, each with its own doEventLoop thread; one is for the unique RTSPServer instance and the others for the 36 RTSPClient instances. The RSTPServer has 36 session instances, which are fed via circular buffer (a new DeviceSource). Do you think I run into an "max open socket" limit (even if 210 is much less than 65535)? Thank you very much, Renato MAURO ----- Original Message ----- From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Monday, July 21, 2008 1:56 PM Subject: Re: [Live-devel] Max limit for RTSPClientSession instances? I wrote an RTSPServer application using Live555. I have 36 different sessions, each with one video subsession. It works and have one limit only: it seems to be impossible to serve more than 32 client requests at a time(no difference between 32 clients on the same session or one client on 32 out of 36 sessions). On the client side, the , rtspClient->sendOptionsCmd(url) methos fails. I will debug my application more deeply in order to understand where, on the server side, the client request is not satisfied; by now my "high level analysis" question is: is there any max limit for RTSPClientSession instances? Not in our code; however, you may have run into a limit - in your operating system - of how many open files it can have (for each process) at a time. Depending on your OS, there should be a way to increase that limit. -- 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 icotoi at rolabs.com Tue Jul 22 00:53:51 2008 From: icotoi at rolabs.com (Ionut Cotoi) Date: Tue, 22 Jul 2008 10:53:51 +0300 Subject: [Live-devel] PES to Transport Stream Framer In-Reply-To: References: <4884A2E8.7030301@rolabs.com> Message-ID: <4885920F.50202@rolabs.com> Thanks for the quick response, you are right. It seems that the filter MPEG2TransportStreamFromPESSource does not generate correct PCR data, as the ts file generated with the sample overflows vlc also. If I open the out.ts file with VLC , the messages window fills with "main debug: waiting decoder fifos to empty" messages. Also, if i stream the ts file with testMpeg2TransportStreamFramer the result is the same, it sends with about 50Mbps instead of 6Mbps which is the correct bitrate. If I pass a ts file created with a third party muxer to testMpeg2TransportStreamFramer it seems to work ok. Regards, Ionut Cotoi Ross Finlayson wrote: >> My problem is that instead of sending with the right bitrate, this >> will stream as fast as it can to the network > > When this happens, it's usually because your 'framer' object is not > able to compute the duration of each Transport Packet (and so, each > packet gets the default duration of 0). The reason for this is > probably that your "MPEG2TransportStreamFramer" is not finding PCRs in > the Transport Stream data. > >> What I do is basically this: >> { >> ByteStreamFileSource* fileSource >> = ByteStreamFileSource::createNew(*env, inputFileName); >> if (fileSource == NULL) { >> *env << "Unable to open file \"" << inputFileName >> << "\" as a byte-stream file source\n"; >> exit(1); >> } >> MPEG2TransportStreamFromPESSource* tsFrames; >> MPEG2TransportStreamFramer* tsFramer; >> FramedSource* esVideoSource; >> >> MPEG1or2Demux* baseDemultiplexor = MPEG1or2Demux::createNew(*env, >> fileSource); >> >> MPEG1or2DemuxedElementaryStream *videoES = >> baseDemultiplexor->newRawPESStream(); >> >> tsFrames = MPEG2TransportStreamFromPESSource::createNew(*env, >> videoES); >> >> tsFramer = MPEG2TransportStreamFramer::createNew(*env, tsFrames); > > This looks good. However, you should first try just converting the > Program Stream file into a Transport Stream file, e.g., using our > "testMPEG1or2ProgramToTransportStream" demo application (whose code > you have adapted). > > I.e., first try to generate a Transport Stream file from your Program > Stream file. Then, try to stream that file. That may give you some > insight into what is going wrong. From hanmin at hisense.com Tue Jul 22 00:55:17 2008 From: hanmin at hisense.com (hanmin) Date: Tue, 22 Jul 2008 15:55:17 +0800 Subject: [Live-devel] problem with testMPEG4VideoStreamer Message-ID: <003701c8ebd0$646a1d60$431a10ac@hanmin> I downloaded the wwe.m4e file from live555 website. I changed the destinationAddress to my ip address,rptPortNum to my port. When I ran testMPEG4VideoStreamer, vlc can use rtsp to show the video right, but when I changed the net source to udp://@:8888, vlc can't show the video. Could you give me some tips about why the rtp unicast don't work? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 22 01:02:49 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 22 Jul 2008 01:02:49 -0700 Subject: [Live-devel] PES to Transport Stream Framer In-Reply-To: <4885920F.50202@rolabs.com> References: <4884A2E8.7030301@rolabs.com> <4885920F.50202@rolabs.com> Message-ID: >Thanks for the quick response, >you are right. It seems that the filter >MPEG2TransportStreamFromPESSource does not generate correct PCR data For some reason, the "MPEGProgramStreamParser" code is not finding/parsing the SCR timestamps in your Program Stream File. Could you please put your original Program Stream file on a web server, and send us the URL, so we can download and test it for ourselves, to help track down the problem. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kumar.bala at DSP-Weuffen.de Tue Jul 22 01:25:31 2008 From: kumar.bala at DSP-Weuffen.de (Kumar Bala) Date: Tue, 22 Jul 2008 10:25:31 +0200 Subject: [Live-devel] Windows vs Linux RTSP/RTP/UDP difference In-Reply-To: <0883400D15254E839A5F790A703D4C07@DSPWeuffen.local> References: <0883400D15254E839A5F790A703D4C07@DSPWeuffen.local> Message-ID: <4885997B.5030403@dsp-weuffen.de> Any one has any ideas on why this couldd be ? Has any one seen this issue in openSIP related application ? Kumar Bala wrote: > Hello All, > I am facing a bizarre platform dependent problem in streaming real > time Mpeg 4 (Standard and High Definition). > > I have an embedded linux where I capture a live video and convert it > into MPEG4 frames (using a hardware encoder). I use > MPEG4DiscreteStreamFramer to stream these frames using modified > testOnDemandRTSP example. > I have almost negligible latency when my client (mplayer) runs on a > linux platform. But the same sources (at least rtp relevant part) when > compiled on windows using mingw shows a huge latency of about 2 to 2.5 > sec. > > Has anyone else faced these problems before ? Are they related to > lower level protocol implementation ? Any suggestion would of great help. > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From laifa at astri.org Tue Jul 22 02:31:47 2008 From: laifa at astri.org (Fang Laifa) Date: Tue, 22 Jul 2008 17:31:47 +0800 Subject: [Live-devel] About RTSP over UDP behind firewall. Message-ID: Dear Ross, Recently I have come out a simple implementation based on live.2008.07.06.tar.gz so that UDP packets could traverse firewall. The diff file is attached. Actually only source file RTSPClient.hh and RTSPClient.cpp are changed. This is a simple UDP hole punch mechanism. It works fine while accessing m.youtube.com behind firewall using mplayer. However I just wonder that my experience on C++ is not enough. So any comments or any suggestions are much appreciated! Thanks. > > Thanks for your reply. These days I have a google on such kind of > >technique. It seems that it was called "UDP hole punch". Could you > >please tell me which RFC is in progress on such kind of mechanism? Are > >there any draft standard now? I just wonder why youtube and realplayer > >can works well under no standards on that. Thanks. > > This is still in a bit of flux. Various Internet Drafts have been > submitted, but it's not clear yet what's going to go on the standards > track. > > This work is being done in the IETF's "MMUSIC" working group, so any > follow-up questions should go to that group's mailing list. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > Rgds, Laifa ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: live_udp_hole_punch.diff Type: application/octet-stream Size: 6236 bytes Desc: live_udp_hole_punch.diff URL: From icotoi at rolabs.com Tue Jul 22 03:08:25 2008 From: icotoi at rolabs.com (Ionut Cotoi) Date: Tue, 22 Jul 2008 13:08:25 +0300 Subject: [Live-devel] PES to Transport Stream Framer In-Reply-To: References: <4884A2E8.7030301@rolabs.com> <4885920F.50202@rolabs.com> Message-ID: <4885B199.5050607@rolabs.com> You can find it here http://www.semaca.co.uk/icotoi/ All the best, Ionut Cotoi Ross Finlayson wrote: >> Thanks for the quick response, >> you are right. It seems that the filter >> MPEG2TransportStreamFromPESSource does not generate correct PCR data > > For some reason, the "MPEGProgramStreamParser" code is not > finding/parsing the SCR timestamps in your Program Stream File. > > Could you please put your original Program Stream file on a web > server, and send us the URL, so we can download and test it for > ourselves, to help track down the problem. > From rajeshkumar.r at imimobile.com Tue Jul 22 03:22:30 2008 From: rajeshkumar.r at imimobile.com (rajesh) Date: Tue, 22 Jul 2008 15:52:30 +0530 Subject: [Live-devel] Can we text overlay while streaming from live555 RTSP server Message-ID: <49F321C9FCCE47BDBA59EE2277E57CF3@imidomain.com> Hi Ross , Can we add text over video frames transnmitted through Live555 RTSP server . if text overlay feature is not there , kindly guide me that how should i approach or any supporting document . I will be obliged if u reply. Thanks in advance. Thanks and Regards Rajesh Kumar Sr. Software Engineer R & D - Network Group ImiMobile Pvt Ltd +91 40 23555945 - 235 +91 99084 00027 www.imimobile.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From renatomauro at libero.it Tue Jul 22 04:36:42 2008 From: renatomauro at libero.it (Renato MAURO (Libero)) Date: Tue, 22 Jul 2008 13:36:42 +0200 Subject: [Live-devel] Re : Max limit for RTSPClientSession instances? References: <216587.31767.qm@web703.biz.mail.mud.yahoo.com> Message-ID: <00c501c8ebef$374e5250$2e020a0a@CSystemDev> Re: [Live-devel] Max limit for RTSPClientSession instancesHi Alkassoum, hi Ross. Alkassoum, thank you very much, you solved my problem. Ross, thank you for your suggestion. Renato MAURO ----- Original Message ----- From: ahmoud alkassoum To: LIVE555 Streaming Media - development & use Sent: Tuesday, July 22, 2008 3:08 AM Subject: [Norton AntiSpam] [Live-devel] Re : Max limit for RTSPClientSession instances? Hi Mauro, If you are running your application under windows you might have the same problem i had few months ago. My problem was due to an windows OS limitation on the number of sockets that can be open at any one time. On windows the FD_SETSIZE parameter have a default value of 64, so with that default value, the server can only handle 64/2 = 32 clients at the same time ( 2 sockets per client). So to solve my problem i only had to increase the FD_SETSIZE parameter. Hope that this information did help you. Alkassoum ----- Message d'origine ---- De : Renato MAURO (Libero) ? : LIVE555 Streaming Media - development & use Envoy? le : Lundi, 21 Juillet 2008, 16h05mn 15s Objet : Re: [Live-devel] Max limit for RTSPClientSession instances? >you may have run into a limit - in your operating system - of how many open files it can have; Thank you for your fast response. I'm not reading data from files; my application receives data from a custom HW and uses Live555 to receive the streams from the HW and offer them through RSTPServer. I found that the 36 input streams are well received. The first 32 (and just now I reached 34) clients are well accepted. Using TcpView, I see 210 active sockets, ie. (36 in + 34 out)*(1 rtp + 2 UDP) = 210; besides there is one RTP socket opened and closed due to the 35th client's periodic attempt to get its stream. For your information, I have 37 environments, each with its own doEventLoop thread; one is for the unique RTSPServer instance and the others for the 36 RTSPClient instances. The RSTPServer has 36 session instances, which are fed via circular buffer (a new DeviceSource). Do you think I run into an "max open socket" limit (even if 210 is much less than 65535)? Thank you very much, Renato MAURO ----- Original Message ----- From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Monday, July 21, 2008 1:56 PM Subject: Re: [Live-devel] Max limit for RTSPClientSession instances? I wrote an RTSPServer application using Live555. I have 36 different sessions, each with one video subsession. It works and have one limit only: it seems to be impossible to serve more than 32 client requests at a time(no difference between 32 clients on the same session or one client on 32 out of 36 sessions). On the client side, the , rtspClient->sendOptionsCmd(url) methos fails. I will debug my application more deeply in order to understand where, on the server side, the client request is not satisfied; by now my "high level analysis" question is: is there any max limit for RTSPClientSession instances? Not in our code; however, you may have run into a limit - in your operating system - of how many open files it can have (for each process) at a time. Depending on your OS, there should be a way to increase that limit. -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 22 05:15:09 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 22 Jul 2008 05:15:09 -0700 Subject: [Live-devel] problem with testMPEG4VideoStreamer In-Reply-To: <003701c8ebd0$646a1d60$431a10ac@hanmin> References: <003701c8ebd0$646a1d60$431a10ac@hanmin> Message-ID: >I downloaded the wwe.m4e file from live555 website. >I changed the destinationAddress to my ip address,rptPortNum to my port. >When I ran testMPEG4VideoStreamer, vlc can use rtsp to show the video right, >but when I changed the net source to udp://@:8888, vlc can't show the video. "udp://" URLs are a non-standard hack. Don't use them. Instead, use RTSP. Either use the *unmodified* "testMPEG4VideoStreamer" application (to stream via multicast), or else use "testOnDemandRTSPServer" or "live555MediaServer" (to stream via unicast), and use the "rtsp://" URL (that the application will display) to access your stream. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 22 05:21:51 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 22 Jul 2008 05:21:51 -0700 Subject: [Live-devel] About RTSP over UDP behind firewall. In-Reply-To: References: Message-ID: Thanks for the contribution. Although the 'hole punching' mechanism that you implemented is non-standard, it probably would not break anything, so - pending the adoption of a real standard for this - I will likely add this to a future revision of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jul 22 05:25:35 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 22 Jul 2008 05:25:35 -0700 Subject: [Live-devel] Can we text overlay while streaming from live555 RTSP server In-Reply-To: <49F321C9FCCE47BDBA59EE2277E57CF3@imidomain.com> References: <49F321C9FCCE47BDBA59EE2277E57CF3@imidomain.com> Message-ID: >Can we add text over video frames transnmitted through Live555 RTSP server . > >if text overlay feature is not there , kindly guide me >that how should i approach or any supporting document . You would need to implement (for both senders and receivers) the "RTP Payload Format for Text Conversation", defined by RFC 4103. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 22 06:40:21 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 22 Jul 2008 06:40:21 -0700 Subject: [Live-devel] PES to Transport Stream Framer In-Reply-To: <4885B199.5050607@rolabs.com> References: <4884A2E8.7030301@rolabs.com> <4885920F.50202@rolabs.com> <4885B199.5050607@rolabs.com> Message-ID: OK, thanks for providing an example file that illustrated your problem. I have now installed a new version - 2008.07.22 - of the "LIVE555 Streaming Media" code that fixes the problem. Your generated Transport Streams should now contain proper PCR timestamps. Please let me know if this new version works OK for you. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From icotoi at rolabs.com Tue Jul 22 08:07:57 2008 From: icotoi at rolabs.com (Ionut Cotoi) Date: Tue, 22 Jul 2008 18:07:57 +0300 Subject: [Live-devel] PES to Transport Stream Framer In-Reply-To: References: <4884A2E8.7030301@rolabs.com> <4885920F.50202@rolabs.com> <4885B199.5050607@rolabs.com> Message-ID: <4885F7CD.3020400@rolabs.com> Thanks allot, it works great!! Thank you very very much! Ionut Ross Finlayson wrote: > OK, thanks for providing an example file that illustrated your problem. > > I have now installed a new version - 2008.07.22 - of the "LIVE555 > Streaming Media" code that fixes the problem. Your generated > Transport Streams should now contain proper PCR timestamps. > > Please let me know if this new version works OK for you. From Jerry.Johns at nuvation.com Tue Jul 22 11:55:41 2008 From: Jerry.Johns at nuvation.com (Jerry Johns) Date: Tue, 22 Jul 2008 11:55:41 -0700 Subject: [Live-devel] Multi Packet Frames Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB5C@mailguy3.skynet.nuvation.com> Hello, I have an H264 transmission, that is sent in FU-A mode - I have a receiver that connects to the stream at arbitrary moments; during these times, when it does connect, there are chances that it will start receiving the stream halfway through a multi-packet frame. Do you know how I can ensure that I discard all such packets until I get a clean, fCurrentPacketBeginsFrame packet? Jerry Johns Design Engineer Nuvation Research Corp - Canada Tel: (519) 746-2304 ext. 225 www.nuvation.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Tue Jul 22 13:35:30 2008 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 22 Jul 2008 13:35:30 -0700 Subject: [Live-devel] Multi Packet Frames In-Reply-To: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB5C@mailguy3.skynet.nuvation.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB5C@mailguy3.skynet.nuvation.com> Message-ID: > I have an H264 transmission, that is sent in FU-A mode - I >have a receiver that connects to the stream at arbitrary moments; >during these times, when it does connect, there are chances that it >will start receiving the stream halfway through a multi-packet >frame. Do you know how I can ensure that I discard all such packets >until I get a clean, fCurrentPacketBeginsFrame packet? Our implementation of H.264/RTP reception already handles this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangmeimeikimo at yahoo.com.tw Tue Jul 22 23:32:43 2008 From: wangmeimeikimo at yahoo.com.tw (wangmeimeikimo) Date: Wed, 23 Jul 2008 14:32:43 +0800 (CST) Subject: [Live-devel] LIVE555 on Wince Message-ID: <148854.97293.qm@web72210.mail.tp2.yahoo.com> I use this cross-compiler(wince-arm-gcc4.0.0-cvs-linux-crosscompiler-20050517.tar.bz2) compile live ,but I solve the compile error and link error, and the openRTSP does not work on Wince anyone use the same compiler compile live? I already solve error, but it does work my point is RTSP function, and I execute openRTSP on Wince, but I get sorry message anyone can help me thank you in advance _______________________________________________________________________________________________________ ????????????????? ???????? http://sev.search.yahoo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From prbhagwat at gmail.com Wed Jul 23 04:32:17 2008 From: prbhagwat at gmail.com (Pramod Bhagwat) Date: Wed, 23 Jul 2008 17:02:17 +0530 Subject: [Live-devel] too many open files error Message-ID: Hi Ross, it looks there is a bug in QuickTimeFileSink. The QuickTimeFileSink::completeOutputFile() is not closing the file handle. (This error will come if user uses different files for saving the stream other than stdout, stderr) Because of the above bug, creating new file using "OpenOutputFile" function calls fails. The Linux is giving "too many open files" error. To over come the problem we need to add CloseOutputFile( fOutFid ) ; function call in the QuickTimeFileSink::completeOutputFile() function just before setting fHaveCompletedOutputFile = True. Similarly this needs to be corrected in AVIFileSink::completeOutputFile(). Please let me know if the suggestions are correct. Warm Regards, prb -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 23 05:05:37 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 23 Jul 2008 05:05:37 -0700 Subject: [Live-devel] too many open files error In-Reply-To: References: Message-ID: Thanks for the bug report. This will be fixed in the next released version of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Jerry.Johns at nuvation.com Wed Jul 23 07:40:14 2008 From: Jerry.Johns at nuvation.com (Jerry Johns) Date: Wed, 23 Jul 2008 07:40:14 -0700 Subject: [Live-devel] Multi Packet Frames Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB60@mailguy3.skynet.nuvation.com> I'm not seeing this behaviour as you describe in my test environment - perhaps I wasn't clear on how I stated my question: My stream chunks a H264 NAL Unit into multiple FU-A packets (1st packet with the start bit set, many follow and finally last with the end bit set) I want to safeguard my H264VideoRTPSource'd receiver to ensure that when it first latches onto this stream, that it does not start to process packets till it gets one with the start bit set That way, I ensure that my FileSink (or whatever sink after) will not get half-complete NAL frames. To ensure its not a legacy problem, I checked out a latest build of liveMedia just now and compiled it, had a simple test file that instantiated a H264VideoRTPSource and a FileSink. After latching onto the stream, I observe that it does indeed pass these halfway frames onto the FileSink I confirmed this by inspecting the file that it produced. Jerry Johns Design Engineer Nuvation Research Corp - Canada Tel: (519) 746-2304 ext. 225 www.nuvation.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From i at iii.dontexist.com Wed Jul 23 09:37:38 2008 From: i at iii.dontexist.com (i at iii.dontexist.com) Date: Wed, 23 Jul 2008 19:37:38 +0300 Subject: [Live-devel] Axis IP Camera AAC audio stream Message-ID: <48875E52.1040201@iii.dontexist.com> Hello, I'm trying to use OpenRTSP for grabbing Video and Audio of an Axis IP Camera. the Video is: "video/MP4V-ES" "a=rtpmap:96 MP4V-ES/90000" the Audio according to the Camera, is set to "AAC", it can be perfectly played via RealPlayer. Audio according to the log: "mode=AAC-hbr;" "a=rtpmap:97 mpeg4-generic/8000/1". The problem is... OpenRTSP always exports the Audio stream, but its not always can be parsed/converted. (Video is always fine.) about 1 out of 5-6 attempts its actually 'works', and then mplayer can play it with few little errors... and mencoder can convert it. but most of the times, it just can't be processed, I've tried MPlayer, MEncoder, FFMpeg, MKVMERGE. (MPlayer i've tried both stable source, and latest SVN) I just can't seem to get the exported AAC useable most of the times. I've tried to: set framerate, export only audio, export to avi, set width/height, "-s 5" "-b 1000000" , "-y" ... just couldn't make it work. I'm using CentOS 5, tried one of the latest sources.... and the very latest of 22/07/08 Any help or information regards this behavior, will be highly appreciated. Thanks, Shai. From finlayson at live555.com Wed Jul 23 15:28:47 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 23 Jul 2008 15:28:47 -0700 Subject: [Live-devel] Axis IP Camera AAC audio stream In-Reply-To: <48875E52.1040201@iii.dontexist.com> References: <48875E52.1040201@iii.dontexist.com> Message-ID: >I'm trying to use OpenRTSP for grabbing Video and Audio of an Axis IP Camera. > >the Video is: "video/MP4V-ES" "a=rtpmap:96 MP4V-ES/90000" > >the Audio according to the Camera, is set to "AAC", it can be >perfectly played via RealPlayer. Out of curiosity, have you also tried playing the stream using VLC? >Audio according to the log: "mode=AAC-hbr;" "a=rtpmap:97 >mpeg4-generic/8000/1". > > >The problem is... OpenRTSP always exports the Audio stream, but its >not always can be parsed/converted. (Video is always fine.) > >about 1 out of 5-6 attempts its actually 'works', and then mplayer >can play it with few little errors... and mencoder can convert it. You didn't say so explicitly, but I assume you're using the "-4" or "-q" options to "openRTSP". Unfortunately, I don't have any good answers for you here. Outputting to a MPEG-4-format or ".mov"-format file is often flaky. Part of the reason for this is that this file format happens to be ill-suited for recording incoming network audio/video. But it's also quite likely that there are remaining bugs in our code ("QuickTimeFileSink"), but I don't have the resources right now to debug this. If you are able, I suggest that you dive into the (open source) code for VLC or MPlayer, to try to figure out exactly why it is not able to play the audio from one of the buggy recorded files, and why it *is* able to play the audio from one of the good recorded files. This may tell you what - if anything - needs to be changed in our code to make it more reliable. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From i at iii.dontexist.com Wed Jul 23 16:20:42 2008 From: i at iii.dontexist.com (i at iii.dontexist.com) Date: Thu, 24 Jul 2008 02:20:42 +0300 Subject: [Live-devel] Axis IP Camera AAC audio stream In-Reply-To: References: <48875E52.1040201@iii.dontexist.com> Message-ID: <4887BCCA.5010203@iii.dontexist.com> Thank you for the very fast response. Ross Finlayson wrote: >> the Audio according to the Camera, is set to "AAC", it can be >> perfectly played via RealPlayer. > Out of curiosity, have you also tried playing the stream using VLC? Tried the win32 version of VLC, and its just fine. >> Audio according to the log: "mode=AAC-hbr;" "a=rtpmap:97 >> mpeg4-generic/8000/1". > You didn't say so explicitly, but I assume you're using the "-4" or > "-q" options to "openRTSP". Note I actually used everything documented about OpenRTSP.. tried -4 , -q , -i ..... tried saving to the 2 seperate files and then use the audio stream. tried using "-a" to STDOUT .... all gave me pretty much the same issue.... most of the time it just couldn't be parsed. Notice that i quoted: "AAC-HBR" ... while VLC claims: "AAC-SBR", it might be the cause? is it even adjustable? Shai. From finlayson at live555.com Wed Jul 23 18:36:10 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 23 Jul 2008 18:36:10 -0700 Subject: [Live-devel] Multi Packet Frames In-Reply-To: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB60@mailguy3.skynet.nuvation.com> References: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB60@mailguy3.skynet.nuvation.com> Message-ID: Aha! I had thought that we handled this case correctly, but it turns out that we didn't. (The code correctly discarded sequences of packets that were missing the start-of-frame packet, but not in the case when this happened beginning with the very first packet that we received.) I have now installed a new version (2008.07.24) of the code that should fix this problem (it now treats the very first-received packet as if there were packet loss preceding it). Please let us know if it works OK for you. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ning.wan at nxp.com Wed Jul 23 19:04:18 2008 From: ning.wan at nxp.com (Ning Wan) Date: Thu, 24 Jul 2008 10:04:18 +0800 Subject: [Live-devel] Ning Wan is on holiday Message-ID: I will be out of the office starting 2008-07-24 and will not return until 2008-08-04. I will respond to your message when I return. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at hovland.org Wed Jul 23 19:30:39 2008 From: erik at hovland.org (Erik Hovland) Date: Wed, 23 Jul 2008 19:30:39 -0700 Subject: [Live-devel] [PATCH] rebased patches Message-ID: <20080724023039.GB7393@hovland.org> Resubmission of both the uninitialized ctor and compiler warning patches. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- A non-text attachment was scrubbed... Name: live555-2008-07-24-patchset.tar.bz2 Type: application/octet-stream Size: 9231 bytes Desc: not available URL: From peeyushduttamishra at gmail.com Wed Jul 23 21:28:57 2008 From: peeyushduttamishra at gmail.com (Peeyush Mishra) Date: Thu, 24 Jul 2008 09:58:57 +0530 Subject: [Live-devel] MJPEG streaming through LIVE APIs not working Message-ID: Hi, I am trying to grab x11 data and converted into MJPEG format with FFMPEG . Now when I stream the dumped file through LIVE555 its not working. RTSP server is created succefully but RTP module is not workin after SETUP . I simply referenced a testProg file , is there any thing special like parser or framer I need to write to make it working ??? Thanks Peeyush Mishra -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Wed Jul 23 21:35:26 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 23 Jul 2008 21:35:26 -0700 Subject: [Live-devel] MJPEG streaming through LIVE APIs not working In-Reply-To: References: Message-ID: >I am trying to grab x11 data and converted into MJPEG format with >FFMPEG . Now when I stream the dumped file through LIVE555 its not >working. RTSP server is created succefully but RTP module is not >workin after SETUP . >I simply referenced a testProg file , is there any thing special >like parser or framer I need to write to make it working ??? We don't yet support streaming from a MJPEG file. To support this, you would need to write a parser/framer - a subclass of "JPEGVideoSource" - that delivers JPEG frame data to a "JPEGVideoRTPSource". However, JPEG is a very poor (inefficient) codec for video streaming. Other codecs - e.g., MPEG-4 - are much better. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jul 23 21:42:48 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 23 Jul 2008 21:42:48 -0700 Subject: [Live-devel] [PATCH] rebased patches In-Reply-To: <20080724023039.GB7393@hovland.org> References: <20080724023039.GB7393@hovland.org> Message-ID: >Resubmission of both the uninitialized ctor and compiler warning >patches. Yes, I'll start making many (though probably not all) of these changes over the next few weeks (so, no need to resubmit them :-). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From prbhagwat at gmail.com Wed Jul 23 22:41:53 2008 From: prbhagwat at gmail.com (Pramod Bhagwat) Date: Thu, 24 Jul 2008 11:11:53 +0530 Subject: [Live-devel] too many open files error In-Reply-To: References: Message-ID: Hi Ross, i looked at the new code live.2008.07.24. i feel there is one issue. Now QuickTimeFileSink constructor is opening the file using OpenOutputFile but it is not checking the return value. If file open fails the filehandle will be NULL and may give core dump wherever filehandle is used. I feel previous interface (older live source base) was correct which used to return NULL to the user if file open fails. Similarly for AVIFileSink. Please let me know your opinion. Warm Regards, prb On Wed, Jul 23, 2008 at 5:35 PM, Ross Finlayson wrote: > Thanks for the bug report. This will be fixed in the next released version > of the software. > -- > > 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 finlayson at live555.com Wed Jul 23 22:53:47 2008 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 23 Jul 2008 22:53:47 -0700 Subject: [Live-devel] too many open files error In-Reply-To: References: Message-ID: >i looked at the new code live.2008.07.24. i feel there is one issue. >Now QuickTimeFileSink constructor is opening the file using >OpenOutputFile but it is not checking the return value. If file open >fails the filehandle will be NULL and may give core dump wherever >filehandle is used. >I feel previous interface (older live source base) was correct which >used to return NULL to the user if file open fails. >Similarly for AVIFileSink. >Please let me know your opinion. Yes, probably. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From peeyushduttamishra at gmail.com Thu Jul 24 01:27:17 2008 From: peeyushduttamishra at gmail.com (Peeyush Mishra) Date: Thu, 24 Jul 2008 13:57:17 +0530 Subject: [Live-devel] MPEG4 (divx) not working with LIVE Message-ID: Hi Ross , I am trying to stream MPEG4 (divx- AVI format) file (Encoded through FFMPEG) through testMPEG4ESvideoStreamer , it flushes logs like "saw unexpected marker" , when I receive that through vlc client , it shows zig-zag,random and partially decoded video . How to resolve this issue. What all changes I need to do to make it working . Thanks Peeyush Mishra -------------- next part -------------- An HTML attachment was scrubbed... URL: From i at iii.dontexist.com Thu Jul 24 01:53:06 2008 From: i at iii.dontexist.com (i at iii.dontexist.com) Date: Thu, 24 Jul 2008 11:53:06 +0300 Subject: [Live-devel] Axis IP Camera AAC Audio, RTSP. Message-ID: <488842F2.4040204@iii.dontexist.com> Just wanted to inform that i been trying the latest release.. and it didn't sort the AAC Audio stream. the vlc win32 version, handled the stream with no problem: "vlc rtsp:// --sout=stream.mp4", (while RealPlayer played it as well) while using vlc under linux, compiled from source with LIVE555 rtsp. ("--enable-live555") ".mp4" file extension caused the audio to be corrupted, while the video was fine. ".asf" file extension caused the video to be corrupted, while the audio was fine. but this setting sorted Video and Audio: vlc rtsp:// --sout "#standard{access=file,mux=ts,dst="stream.mp4"} so if anybody gets: RTSP AAC Audio streams issues with Axis IP Cameras, this might help you sort it out. (This was not documented in the mailing list, I thought it will help others who will stumble the subjet in the future) Shai From qiujianshu at cnc-labs.com Thu Jul 24 03:45:03 2008 From: qiujianshu at cnc-labs.com (choujs) Date: Thu, 24 Jul 2008 18:45:03 +0800 Subject: [Live-devel] TS stream not resumed correctly after paused Message-ID: <000d01c8ed7a$548e3ce0$7685020a@cnc.intra> Hi, I try to use media server to stream my TS file, and found that the stream can not be resumed correctly after paused. That is, when resume, the speed of packet transmit become very slow. I have traced into the code, and found the problem may be in the function MPEG2TransportStreamFramer::doStopGettingFrames(). In that function, fTSPacketCount is change to 0, but not fTSPCRCount. Then in MPEG2TransportStreamFramer::updateTSPacketDurationEstimate(), when caculate meanPCRPeriod, the value is always less than 1.0, because fTSPacketCount may less than fTSPCRCount at that time. I think this may be a bug, is it? From finlayson at live555.com Thu Jul 24 04:16:46 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2008 04:16:46 -0700 Subject: [Live-devel] MPEG4 (divx) not working with LIVE In-Reply-To: References: Message-ID: >I am trying to stream MPEG4 (divx- AVI format) file We don't currently support reading/streaming from 'AVI'-format files. >How to resolve this issue. What all changes I need to do to make it working . You would need to write appropriate parser/framer classes for AVI-format files. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jul 24 04:41:40 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2008 04:41:40 -0700 Subject: [Live-devel] TS stream not resumed correctly after paused In-Reply-To: <000d01c8ed7a$548e3ce0$7685020a@cnc.intra> References: <000d01c8ed7a$548e3ce0$7685020a@cnc.intra> Message-ID: >I try to use media server to stream my TS file, and found that >the stream can not be resumed correctly after paused. That is, >when resume, the speed of packet transmit become very slow. I >have traced into the code, and found the problem may be in the >function MPEG2TransportStreamFramer::doStopGettingFrames(). >In that function, fTSPacketCount is change to 0, but not fTSPCRCount. >Then in MPEG2TransportStreamFramer::updateTSPacketDurationEstimate(), >when caculate meanPCRPeriod, the value is always less than 1.0, because >fTSPacketCount may less than fTSPCRCount at that time. >I think this may be a bug, is it? Yes, quite possibly. Does adding fTSPCRCount = 0; to "MPEG2TransportStreamFramer::doStopGettingFrames()" overcome your problem? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From Jerry.Johns at nuvation.com Thu Jul 24 12:13:03 2008 From: Jerry.Johns at nuvation.com (Jerry Johns) Date: Thu, 24 Jul 2008 12:13:03 -0700 Subject: [Live-devel] Multi Packet Frames Message-ID: <274F7B50569A1B4C9D7BCAB17A9C7BE104AB6A@mailguy3.skynet.nuvation.com> Hey Ross, Just tested your latest version of the stack, and it works like a charm :-) - since I have an older version of the LiveMedia stack running on my embedded system, I will be porting the changes to my version - If I'm correct, I think the relevant changes were isolated to MultiFramedRTPSource.cpp, .hh; Ideally we would be syncing to the latest version soon, just don't have the time right now Thanks, Jerry Johns Design Engineer Nuvation Research Corp - Canada Tel: (519) 746-2304 ext. 225 www.nuvation.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From qiujianshu at cnc-labs.com Thu Jul 24 17:31:25 2008 From: qiujianshu at cnc-labs.com (choujs) Date: Fri, 25 Jul 2008 08:31:25 +0800 Subject: [Live-devel] TS stream not resumed correctly after paused References: <000d01c8ed7a$548e3ce0$7685020a@cnc.intra> Message-ID: <000a01c8eded$c5f6b150$7685020a@cnc.intra> > >I try to use media server to stream my TS file, and found that >>the stream can not be resumed correctly after paused. That is, >>when resume, the speed of packet transmit become very slow. I >>have traced into the code, and found the problem may be in the >>function MPEG2TransportStreamFramer::doStopGettingFrames(). >>In that function, fTSPacketCount is change to 0, but not fTSPCRCount. >>Then in MPEG2TransportStreamFramer::updateTSPacketDurationEstimate(), >>when caculate meanPCRPeriod, the value is always less than 1.0, because >>fTSPacketCount may less than fTSPCRCount at that time. >>I think this may be a bug, is it? > > Yes, quite possibly. > > Does adding > fTSPCRCount = 0; > to "MPEG2TransportStreamFramer::doStopGettingFrames()" overcome your problem? > -- > I have tried and it seems work well now. > 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 Jul 24 17:38:54 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2008 17:38:54 -0700 Subject: [Live-devel] TS stream not resumed correctly after paused In-Reply-To: <000a01c8eded$c5f6b150$7685020a@cnc.intra> References: <000d01c8ed7a$548e3ce0$7685020a@cnc.intra> <000a01c8eded$c5f6b150$7685020a@cnc.intra> Message-ID: > > Does adding >> fTSPCRCount = 0; >> to "MPEG2TransportStreamFramer::doStopGettingFrames()" overcome >>your problem? >> -- >> > >I have tried and it seems work well now. OK, I have now installed a new version (2008.07.25) of the code, that includes this fix. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From roland at wingmanteam.com Thu Jul 24 18:35:00 2008 From: roland at wingmanteam.com (Roland) Date: Thu, 24 Jul 2008 18:35:00 -0700 Subject: [Live-devel] Presentation timestamp - why wall clock? SR handling question too. Message-ID: <004001c8edf6$a7528540$f5f78fc0$@com> Hi there I'm working on a RTSP project, using live.2008.07.24.tar.gz. I'm receiving MPEG4ESVideo and MPEG4LATMAudio data streams. I've implemented two sinks right behind these media sources and store the incoming frames for playback, based on the 'presentationTime' given in _afterFrame(). The very first frames on each subsession always come back with 'wall clock' presentationTime (as filled in by code in RTPSource.cpp, lines 309-318). Then, once a SR packet has arrived, the presentationTime time jumps to the NTP time advertised by the source in the SR packet. I don't think this is correct behavior. My interpretation of the SR NTP information is that it can be used to synchronize *multiple* streams in respect to *each other*. It does *not* mean that the given NTP timestamp *is* the presentationTime for the given rtpTimestamp. The NTP timestamp is defined as the sender's wall clock when the SR packet got 'sent', not when the data contained at those rtp timestamps should be 'presented'. So, instead of overwriting the running presentation time (stored in RTPReceptionStats ::fSyncTime), the SR NTP time should be stored somewhere else (along with the SR RTP timestamp) and used to provide a delay measurement between subsessions. The main reason for this is what kind of SR reports I'm getting from YouTube: At time NTP+0.0 seconds, I get an RTP timestamp of 42.0 seconds. At time NTP+8.0 seconds, I get an RTP timestamp of 54.0 seconds. At time NTP+16.0 seconds, I get an RTP timestamp of 62.0 seconds. This shows that in RTP time, 12 seconds worth of data have been transmitted, however in real time (NTP time), only 8 seconds have elapsed. The NTP time cannot be used to calculate the presentation time of the data (12 seconds) worth of it, without severely backtracking by -4 seconds once the second SR packet arrives. Instead, the SR packets of Audio/Video should be compared against, and a delay/drift can be calculated, given enough SR packets for various subsessions: SR for Audio: NTP+0.0: Audio RTP at 42.0 SR for Video: NTP+0.1: Video RTP at 85.0 -> not enough data SR for Audio: NTP+8.0: Audio RTP at 54.0 (12.0 seconds elapsed) SR for Video: NTP+8.1: Video RTP at 97.1 (12.1 seconds elapsed) -> Video is drifting by 0.1 seconds ahead, slow down playback SR for Audio: NTP+16.0: Audio RTP at 62.0 (8.0 seconds elapsed) SR for Video: NTP+16.1: Video RTP at 105.0 (7.9 seconds elapsed) -> Video is drifting by 0.1 seconds behind, accelerate playback Does that make sense? Thanks for reading this far Roland From finlayson at live555.com Thu Jul 24 19:10:07 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 24 Jul 2008 19:10:07 -0700 Subject: [Live-devel] Presentation timestamp - why wall clock? SR handling question too. In-Reply-To: <004001c8edf6$a7528540$f5f78fc0$@com> References: <004001c8edf6$a7528540$f5f78fc0$@com> Message-ID: >The very first frames on each subsession always come back with 'wall clock' >presentationTime (as filled in by code in RTPSource.cpp, lines 309-318). >Then, once a SR packet has arrived, the presentationTime time jumps to the >NTP time advertised by the source in the SR packet. > >I don't think this is correct behavior. Yes it is. The key thing to realize is that the first few presentation times - before RTCP synchronization occurs - are just 'guesses' made by the receiving code (based on the receiver's 'wall clock' and the RTP timestamp). However, once RTCP synchronization occurs, all subsequent presentation times will be accurate, and will be THE SAME PRESENTATION TIMES that the server generated (i.e., they will be times that were computed from the server's clock). All this means is that a receiver should be prepared for the fact that the first few presentation times (until RTCP synchronization starts) will not be accurate. The code, however, can check this by calling "RTPSource:: hasBeenSynchronizedUsingRTCP()". If this returns False, then the presentation times are not accurate, and should be treated with 'a grain of salt'. However, once the call to returns True, then the presentation times (from then on) will be accurate. >The main reason for this is what kind of SR reports I'm getting from >YouTube: > >At time NTP+0.0 seconds, I get an RTP timestamp of 42.0 seconds. >At time NTP+8.0 seconds, I get an RTP timestamp of 54.0 seconds. >At time NTP+16.0 seconds, I get an RTP timestamp of 62.0 seconds. > >This shows that in RTP time, 12 seconds worth of data have been transmitted, >however in real time (NTP time), only 8 seconds have elapsed. All this means is the server is (apparently) streaming 20 seconds worth of data in 16 seconds, apparently to allow the client to pre-buffer the excess data (so it can ensure smooth playout). This means, therefore, that your receiving client needs to buffer this extra data, and play out each frame based on the *presentation time*, *not* at the time at which the frame actually arrives. Therefore, to use your example, you would: - play the frame whose presentation time is 42.0 at time 0 - play the frame whose presentation time is 54.0 at time 12 - play the frame whose presentation tme is 62 at time 20 *regardless* of the times at which these frames actually arrived. I really wish people would stop thinking that they need to do their own implementation of the RTP/RTCP protocol (e.g., look at RTP timestamps or sequence numbers, and/or RTCP reports). You don't - we already implement all of this! All you need to do is use the presentation times that are delivered to you (but be aware that the first few presentation times may not be accurate, as noted above). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From laifa at astri.org Thu Jul 24 23:28:52 2008 From: laifa at astri.org (Fang Laifa) Date: Fri, 25 Jul 2008 14:28:52 +0800 Subject: [Live-devel] About RTSP over UDP behind firewall. Message-ID: Hi, Ross, > Thanks for the contribution. Although the 'hole punching' mechanism > that you implemented is non-standard, it probably would not break > anything, so - pending the adoption of a real standard for this - I > will likely add this to a future revision of the code. > -- The implementation has the problem of "segmentation fault" when using RTP over TCP. The problem is from (serverAddressStr == NULL) under streamUsingTCP is true. This is fixed based on live.2008.07.25.tar.gz as attached. Laifa ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This message (including any attachments) is for the named addressee(s)'s use only. It may contain sensitive, confidential, private proprietary or legally privileged information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. Any use, disclosure, copying, or distribution of this message and/or any attachments is strictly prohibited. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: live_hole_punch.2008.07.25.diff Type: application/octet-stream Size: 5936 bytes Desc: live_hole_punch.2008.07.25.diff URL: From wangmeimeikimo at yahoo.com.tw Fri Jul 25 00:24:44 2008 From: wangmeimeikimo at yahoo.com.tw (wangmeimeikimo) Date: Fri, 25 Jul 2008 15:24:44 +0800 (CST) Subject: [Live-devel] libstdc++.a have problem? Message-ID: <255298.24239.qm@web72212.mail.tp2.yahoo.com> Hi: I downloaded the cross-compiler that vlc support( wince-arm-gcc4.0.0-cvs-linux-crosscompiler-20050517.tar.bz2) when I --enable-livedotcom, it always display many errors finally, I found when I include in .cpp file, then the?errors always exist I solve this problem is comment out this line(#include ) I?get vlc.exe?successfully, but the?RTSP function does not work? my question is?"is the cross-compiler is perfectible for Wince" I compile vlc 0.8.4 is OK, but RTSP function isn't( even the openRTSP function in the testProg does not work, and it display sorry on Wince) _______________________________________________________________________________________________________ ????????????????? ???????? http://sev.search.yahoo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogy_dogy at livemail.tw Fri Jul 25 02:57:53 2008 From: dogy_dogy at livemail.tw (J T) Date: Fri, 25 Jul 2008 09:57:53 +0000 Subject: [Live-devel] RTSP over HTTP ? Message-ID: Dear All, I would like to use live555 to capture the Video stream from a IP camera. I can use IE to get the video stream from the IP camera. But I find there are 3 HTTP sessions between IE and IP Camera. I would like to use openRTSP on it, but how to separate 3 different sessions by openRTSP ? Session 1 : >From IE : GET /server/Access HTTP/1.0 Accept: */* User-Agent: Client Host: 192.168.1.2 >From IP Camera : HTTP/1.1 401 Unauthorized Server: Tester Date: Sun Jan 9 22:06:14 2000 WWW-Authenticate: Digest realm="W_camera", domain="Wcam",qop="auth", nonce="c6e05c50a1a06c08f31c3ac367a9385a", opaque="5ccc069c403ebaf9f0171e9517f40e41", algorithm="MD5", stale="FALSE" Pragma: no-cache Cache-Control: no-cache Content-Type: text/html Document Error: Unauthorized Access Error: Unauthorized when trying to obtain /server/Access Access to this document requires a User ID Session 2 : >From IE : GET /server/Access HTTP/1.0 Accept: */* User-Agent: Client Host: 192.168.1.2 Authorization: Digest username="admin", realm="W_camera", algorithm="MD5", nonce="c6e05c50a1a06c08f31c3ac367a9385a", uri="/server/Access", nc=00000001, cnonce="0a4f113b", opaque="5ccc069c403ebaf9f0171e9517f40e41", response="4ffba70ec1d53c3252ff06652e1b6efe", qop="auth" >From IP Camera : HTTP/1.0 200 OK Server: Tester Pragma: no-cache Cache-control: no-cache Content-Type: text/html Connection: keep-alive Session: 31866 Video MP4V-ES/90000 Audio G.726-32/8000 RTSP/1.0 200 OK CSeq: 1 Server: Tester/0.1 Date: Sun, 09 Jan 2000 22:06:15 GMT Session: 31866 RTSP/1.0 200 OK CSeq: 2 Content-Length: 20 Content-Type: text/parameters video_framesize: 1 RTSP/1.0 200 OK CSeq: 3 Content-Length: 21 Content-Type: text/parameters video_bitrate: 1800 RTSP/1.0 200 OK CSeq: 4 Content-Length: 23 Content-Type: text/parameters video_framerate: 3000 RTSP/1.0 200 OK CSeq: 5 Server: Tester/0.1 Date: Sun, 09 Jan 2000 22:06:22 GMT Session: 5 RTSP/1.0 200 OK CSeq: 5 Server: Tester/0.1 Date: Sun, 09 Jan 2000 22:06:22 GMT Session: 5 Session 3 : >From IE : GET /server/output?session=31866 HTTP/1.0 Accept: */* User-Agent: Client Host: 192.168.1.2 Authorization: Digest username="admin", realm="W_camera", algorithm="MD5", nonce="c6e05c50a1a06c08f31c3ac367a9385a", uri="/server/output", nc=00000001, cnonce="0a4f113b", opaque="5ccc069c403ebaf9f0171e9517f40e41", response="1462e32baf95a981fef0b686ac38caec", qop="auth" >From IP Camera : HTTP/1.0 200 OK Server: Tester Pragma: no-cache Cache-control: no-cache Content-Type: video/quicktime Connection: keep-alive Setup Video Session OK ............ Video .................. ............ Video .................. _________________________________________________________________ ?? Windows Live Messenger 8.5 ??????????????????????????? ???? http://get.live.com/zh-cht-tw/betas/messenger_betas From max at videonext.net Fri Jul 25 07:16:14 2008 From: max at videonext.net (Maxim Petrov) Date: Fri, 25 Jul 2008 14:16:14 +0000 Subject: [Live-devel] H.264 and QuickTime client Message-ID: Hi Gents. The topic of this message is little bit off-topic, but because it's related to live555 software too I think I can describe my problem here. We have implemented rtsp server using live555 framework. Also we are using libx264 as encoder. Open source clients like VLC and mplayer can get and play H.264 stream w/o any problem. So I think our implementation of H264VideoStreamFramer is correct. However QuickTime(7.4.5) is seems different story. RTSP negotiation passed great, after PLAY command our server are sending stream to QuickTime, and I even see control bar with progress of streaming. But no video displayed. Even if I click on "pause" button, PAUSE command is sending to our server... As I understand there is no problem with network level, but for some reason QuickTime cannot decode stream. Of course I do not ask how to solve my problem. I just wondering if somehow had experience with QuickTime client and have problems like we? I've just subscribed to quicktime-users mail list and will send questions there too... Another question: anybody know about another (may be proprietary) clients (except vlc, mplayer, quicktime) which can play H.264 over RTSP/RTP. -- Bye, Maxim. We can solve any problem by introducing an extra level of indirection. From finlayson at live555.com Fri Jul 25 04:27:12 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 25 Jul 2008 04:27:12 -0700 Subject: [Live-devel] RTSP over HTTP ? In-Reply-To: References: Message-ID: Judging by what your IP camera sent, it is not using RTSP in any standard way, so it is unlikely that our software will be able to communicate with it. However, have you just tried running "openRTSP" with the "-T " option, as described in the online documentation? If that doesn't work, then you're out of luck - sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jul 25 04:31:24 2008 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 25 Jul 2008 04:31:24 -0700 Subject: [Live-devel] H.264 and QuickTime client In-Reply-To: References: Message-ID: >We have implemented rtsp server using live555 framework. Also we are >using libx264 as encoder. Open source clients like VLC and mplayer can >get and play H.264 stream w/o any problem. So I think our implementation >of H264VideoStreamFramer is correct. > >However QuickTime(7.4.5) is seems different story. RTSP negotiation >passed great, after PLAY command our server are sending stream to >QuickTime, and I even see control bar with progress of streaming. But no >video displayed. The problem is probably that QuickTime does not implement the same H.264 'profile' that your server's encoder generates. However, you should check on a QuickTime mailing list to confirm this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From max at videonext.net Fri Jul 25 08:20:36 2008 From: max at videonext.net (Maxim Petrov) Date: Fri, 25 Jul 2008 15:20:36 +0000 Subject: [Live-devel] H.264 and QuickTime client In-Reply-To: (Ross Finlayson's message of "Fri\, 25 Jul 2008 04\:31\:24 -0700") References: Message-ID: Ross Finlayson wrote: > The problem is probably that QuickTime does not implement the same > H.264 'profile' that your server's encoder generates. I'm not sure, because within .mov/.mp4 containers QuickTime can play video fine. > However, you should check on a QuickTime mailing list to confirm this. Yes. Thanks for reply! -- Bye, Maxim. We can solve any problem by introducing an extra level of indirection. From renatomauro at libero.it Fri Jul 25 10:15:13 2008 From: renatomauro at libero.it (Renato MAURO (Libero)) Date: Fri, 25 Jul 2008 19:15:13 +0200 Subject: [Live-devel] RTSPServer: redeclaration and one cycle only References: Message-ID: <019501c8ee7a$0100ce70$2e020a0a@CSystemDev> Hi Ross. Don't worry, this is not an help request, only an explanation one. Watching this code TSPServer* RTSPServer::createNew(UsageEnvironment& env, Port ourPort, UserAuthenticationDatabase* authDatabase, unsigned reclamationTestSeconds) { int ourSocket = -1; do { int ourSocket = setUpOurSocket(env, ourPort); if (ourSocket == -1) break; return new RTSPServer(env, ourSocket, ourPort, authDatabase, reclamationTestSeconds); } while (0); if (ourSocket != -1) ::closeSocket(ourSocket); return NULL; } we see that 'ourSocket' is redeclared in the do-while loop. 1) I'm wondering if the redeclaration is intentional or not and so if the last 'if' is useful or not. 2) Maybe it's my lack of knowledge: why write a single do-while cicle instead of use an if-else structure? Thank you very much, Renato MAURO From roland at wingmanteam.com Fri Jul 25 12:32:50 2008 From: roland at wingmanteam.com (Roland) Date: Fri, 25 Jul 2008 12:32:50 -0700 Subject: [Live-devel] Presentation timestamp - why wall clock? SR handling question too. In-Reply-To: References: <004001c8edf6$a7528540$f5f78fc0$@com> Message-ID: <001201c8ee8d$39ecd180$adc67480$@com> Hi Ross >I really wish people would stop thinking that they need to do their >own implementation of the RTP/RTCP protocol (e.g., look at RTP I'm thinking exactly the opposite, I'd love to use and contribute to a open source library that takes care of all the intricacies of RTP/RTCP. I'm just trying to make sense of the data that is being transmitted. I came to my conclusion after reading the paragraphs describing the SR reports in "RTP", Colin Perkins, 2003. Him, as well as RFC3550 (Section 6.4.1) refrain from associating the NTP timestamps with PresentationTime of payload... Initially, I was associating the two as well, but seeing the data I'm seeing, I'm trying to understand exactly what is going on under the hood and find a possible explanation... >Yes it is. The key thing to realize is that the first few >presentation times - before RTCP synchronization occurs - are just >'guesses' made by the receiving code (based on the receiver's 'wall >clock' and the RTP timestamp). However, once RTCP synchronization >occurs, all subsequent presentation times will be accurate, and will >be THE SAME PRESENTATION TIMES that the server generated (i.e., they >will be times that were computed from the server's clock). >All this means is that a receiver should be prepared for the fact >that the first few presentation times (until RTCP synchronization >starts) will not be accurate. The code, however, can check this by >calling "RTPSource:: hasBeenSynchronizedUsingRTCP()". If this >returns False, then the presentation times are not accurate, and >should be treated with 'a grain of salt'. However, once the call to >returns True, then the presentation times (from then on) will be >accurate. My mistake here, apologies, I missed the function 'hasBeenSynchronizedUsingRTCP()' - that takes care of trusting the presentationTime parameter given in _afterFrame(). I still have an issue though... >All this means is the server is (apparently) streaming 20 seconds >worth of data in 16 seconds, apparently to allow the client to >pre-buffer the excess data (so it can ensure smooth playout). This >means, therefore, that your receiving client needs to buffer this >extra data, and play out each frame based on the *presentation time*, >*not* at the time at which the frame actually arrives. >Therefore, to use your example, you would: >- play the frame whose presentation time is 42.0 at time 0 >- play the frame whose presentation time is 54.0 at time 12 >- play the frame whose presentation tme is 62 at time 20 >*regardless* of the times at which these frames actually arrived. This is exactly where my trouble is. I'm *not* measuring the time when I *receive* packets, I fully trust the 'presentationTime' parameter given when _afterFrame() is being called. Let me expand my example to illustrate the problem: * Type is the type of packet received (PL = RTP payload, SR = Sender Report) * ClientTime is my wall clock * RTPTS is the timestamp value in a given UDP packet (for simplicity let's assume a media frequency of 10 samples per second and a frame contains 2 samples worth of payload) * PresTS is the presentationTime value I receive as a parameter in _afterFrame * Sync is whether the stream has been synchronized (using the newly discovered function) For a client/player point of view (that's me), the only datapoints visible are 'PresTS' and 'Sync'. I gathered the other pieces of data using Wireshark. Type ClientTime RTPTS PresTS Sync PL 100.0 5000 100.0 No SR 100.1 NTP=200.1, RTP=5001 (1) PL 100.4 5004 200.4 Yes PL 100.6 5006 200.6 Yes ... PL 111.8 5118 211.8 Yes PL 112.0 5120 212.0 Yes SR 112.1 NTP=208.1!, RTP=5121 (2) PL 112.2 5122 >208.2< Yes (3) PL 112.4 5124 208.4 Yes ... PL 120.0 5200 216.0 Yes SR 120.1 NTP=216.1, RTP=5201 (4) PL 120.2 5202 216.2 Yes ... (1) PresTS jumps due to an incoming SR packet. I thought this was an issue, but now I have the means to take the previous '100.0' value with a grain of salt. (2) This is the one that freaks me out. The SR packet causes the PresTS times to go backwards in subsequent frames. If you compare the times in the NTP domain, 8 seconds have elapsed. But I get this report only after 12 seconds of ClientTime and 12 seconds worth of payload. (3) Now I'm utterly confused. I get frames, which should have been presented 4 seconds ago...What do I do with the fact that time went backwards within a fully synchronized stream? If it were just fractions of a second, that's one thing. But 4 seconds? (That's 60 video frames and 88200 audio samples in my case). Looking at the actual data, there is no jumping back in time. (4) After a while, another SR reports comes in. Compared to the SR report at (2), this one is correctly spaced in NTP as well as RTP. Hence subsequent calculations will give me a continuous PresTS. My dilemma is at (3). What does a client do if PresentationTime goes backwards by this much? I've been trying to come up with all sorts of explanations and the only ones that makes sense to me is that NTP time of SR packets is not necessarily PresentationTime (sustained by wording in my book and RFC), the other one that the server implementation is buggy (sustained by the irrationality of the data seen and the current implementation of live555)... Yours truly confused Roland PS: Quoting RFC3550: NTP timestamp: 64 bits Indicates the wallclock time (see Section 4) when this report was sent so that it may be used in combination with timestamps returned in reception reports from other receivers to measure round-trip propagation to those receivers. . From finlayson+mobile at live555.com Fri Jul 25 12:44:18 2008 From: finlayson+mobile at live555.com (Ross Finlayson) Date: Fri, 25 Jul 2008 12:44:18 -0700 Subject: [Live-devel] RTSPServer: redeclaration and one cycle only In-Reply-To: <019501c8ee7a$0100ce70$2e020a0a@CSystemDev> References: <019501c8ee7a$0100ce70$2e020a0a@CSystemDev> Message-ID: <4001D178-3653-4FDD-8698-6800BE648EC1@live555.com> Yes, you found a bug on the code. The second declaration of ourSocket was incorrect. This will get fixed in the next release of the code. Also, "do { ... } while (0);" is a common C++ idiom used to create a block of code that's easy to break out of (if an error occurs), without using exceptions (or goto). Ross. ---------- Sent from my jesusPhone On Jul 25, 2008, at 10:15 AM, "Renato MAURO \(Libero\)" wrote: > Hi Ross. > > Don't worry, this is not an help request, only an explanation one. > > Watching this code > > TSPServer* > RTSPServer::createNew(UsageEnvironment& env, Port ourPort, > UserAuthenticationDatabase* authDatabase, > unsigned reclamationTestSeconds) { > int ourSocket = -1; > > do { > int ourSocket = setUpOurSocket(env, ourPort); > if (ourSocket == -1) break; > > return new RTSPServer(env, ourSocket, ourPort, authDatabase, > reclamationTestSeconds); > } while (0); > > if (ourSocket != -1) ::closeSocket(ourSocket); > return NULL; > } > > we see that 'ourSocket' is redeclared in the do-while loop. > > 1) I'm wondering if the redeclaration is intentional or not and so > if the last 'if' is useful or not. > > 2) Maybe it's my lack of knowledge: why write a single do-while > cicle instead of use an if-else structure? > > Thank you very much, > > Renato MAURO > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From finlayson+mobile at live555.com Fri Jul 25 13:09:11 2008 From: finlayson+mobile at live555.com (Ross Finlayson) Date: Fri, 25 Jul 2008 13:09:11 -0700 Subject: [Live-devel] Presentation timestamp - why wall clock? SR handling question too. In-Reply-To: <001201c8ee8d$39ecd180$adc67480$@com> References: <004001c8edf6$a7528540$f5f78fc0$@com> <001201c8ee8d$39ecd180$adc67480$@com> Message-ID: <5AE8E8E7-6691-49CA-B1C5-827A1B0454F0@live555.com> It seems that your server is buggy. I've seen this before with some versions of Apple's QuickTime (aka. Darwin) Streaming Server. Therefore, receivers need to be on the lookout for unusual changes (decreases or large increases) in presentation time, and reset their internally-maintained offset between presentation time and 'wall- clock' time whenever they see this happen. (This is part of the Internet philosophy of "Be conservative in what you send, and liberal in what you accept.") Ross Finlayson Live Networks, Inc. From hartman at videolan.org Fri Jul 25 14:11:32 2008 From: hartman at videolan.org (Derk-Jan Hartman) Date: Fri, 25 Jul 2008 23:11:32 +0200 Subject: [Live-devel] Presentation timestamp - why wall clock? SR handling question too. In-Reply-To: <5AE8E8E7-6691-49CA-B1C5-827A1B0454F0@live555.com> References: <004001c8edf6$a7528540$f5f78fc0$@com> <001201c8ee8d$39ecd180$adc67480$@com> <5AE8E8E7-6691-49CA-B1C5-827A1B0454F0@live555.com> Message-ID: <20A76574-A728-4E81-A2FE-96D509EE265B@videolan.org> On 25 jul 2008, at 22:09, Ross Finlayson wrote: > It seems that your server is buggy. I've seen this before with some > versions of Apple's QuickTime (aka. Darwin) Streaming Server. > > Therefore, receivers need to be on the lookout for unusual changes > (decreases or large increases) in presentation time, and reset their > internally-maintained offset between presentation time and 'wall- > clock' time whenever they see this happen. (This is part of the > Internet philosophy of "Be conservative in what you send, and > liberal in what you accept.") I was just gonna say that this looks exactly like what i was seeing on this stream rtsp://a2047.v1411b.c1411.g.vq.akamaistream.net/5/2047/1411/1_h264_650/1a1a1ae454c430950065de4cbb2f94c226950c7ae655b61a48a91475e243acda3dac194879adde0f/080690210abcn_2a_650.mov that I was testing in VLC. I have been discussing this case with Ross on the vlc-devel mailinglist for the past day and we came to the conclusion that it was most likely the server that was incorrect. I haven't taken it to the QT mailinglist yet, but I think we should do that. As for approach to deal with it. I simply have NO idea Roland... The problem is that it basically affects all data between (in your sample 208 and 212) to go "bad" which is quite a large gap of course. I you have a briljant idea, i'll welcome it :D DJ From roland at wingmanteam.com Fri Jul 25 16:48:32 2008 From: roland at wingmanteam.com (Roland) Date: Fri, 25 Jul 2008 16:48:32 -0700 Subject: [Live-devel] Presentation timestamp - why wall clock? SR handling question too. In-Reply-To: <20A76574-A728-4E81-A2FE-96D509EE265B@videolan.org> References: <004001c8edf6$a7528540$f5f78fc0$@com> <001201c8ee8d$39ecd180$adc67480$@com> <5AE8E8E7-6691-49CA-B1C5-827A1B0454F0@live555.com> <20A76574-A728-4E81-A2FE-96D509EE265B@videolan.org> Message-ID: <001401c8eeb0$f26c55a0$d74500e0$@com> >As for approach to deal with it. I simply have NO idea Roland... The >problem is that it basically affects all data between (in your sample >208 and 212) to go "bad" which is quite a large gap of course. I you >have a briljant idea, i'll welcome it :D I'm taking Ross's advice and liberally distrust the presentationTime ;-) Algorithm goes as follows (pseudocode): sink::sink() { m_offset = 0; m_last = 0; } sink::onFrame(data, presentationTime, ...) { if(0 == m_offset) { m_offset = presentationTime; m_last = 0; } gap = (presentationTime - m_offset) - m_last; if((gap > one_second) || (gap < -one_second)) { m_offset += gap; } m_last = presentationTime - m_offset; StoreFrameInPlaybackBufferWithCorrectedTS(data, m_last); // assert(two consecutive timestamps are no more than 1 second apart) } The code above takes care of the -4 second shift I'm seeing in my streams. However, it is still possible for time to go backwards (although at most 1 second). I'm going to experiment with variations of the 2nd if() like this: if((gap > (1 second/rtpsink:: rtpTimestampFrequency()) || (gap < 0) // assert(consecutive frames are strictly ordered and at most 1 sample apart) It's not super nice, but it gets the job done. cheers, Roland From mdnpfa001 at uct.ac.za Sat Jul 26 06:45:32 2008 From: mdnpfa001 at uct.ac.za (PFARISO MADANDA) Date: Sat, 26 Jul 2008 15:45:32 +0200 Subject: [Live-devel] Displaying streamed video to a window Message-ID: <488B469D0200002D0008C108@gwiasmtp.uct.ac.za> Hi, I'm new at using live555. I have looked at the test programs, specifically the testMPEG1or2VideoStreamer/Receiver. I was able to get these to compile and run successfully. I now want to modify the Receiver to display the video in a window instead of writing the received data to stdout. From laterial at gmail.com Sun Jul 27 02:42:01 2008 From: laterial at gmail.com (Quanfeng Guo) Date: Sun, 27 Jul 2008 17:42:01 +0800 Subject: [Live-devel] Does the newest version support RFC 4585 Message-ID: <4152c390807270242ndb433ay22c2abc3130a72c2@mail.gmail.com> Hi, I'm using the libraries provided by live555 for streaming server development. I want to know whether the current version supports RFC 4585, in which an extended RTP profile for RTCP is defined. Thanks & Best Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangmeimeikimo at yahoo.com.tw Sun Jul 27 04:50:51 2008 From: wangmeimeikimo at yahoo.com.tw (wangmeimeikimo) Date: Sun, 27 Jul 2008 19:50:51 +0800 (CST) Subject: [Live-devel] compile live555 with crosscompiler(wince-arm-gcc4.0.0-cvs-linux-crosscompiler-20050517.tar.bz2) Message-ID: <12936.39518.qm@web72212.mail.tp2.yahoo.com> dear team: anyone have been compile live555 with this cross-compiler http://mirror.yandex.ru/mirrors/ftp.videolan.org//testing/wince/ I use this compiler?and I solve all the compile error and link error, but the openRTSP function is still not work if someone have done this project, please send email to me how to do( if you have more free time , please teach me more detail, let me know you how to do ) my email is wangmeimeikimo at yahoo.com.tw or meimei_chimchim at msn.com thanks in advance _______________________________________________________________________________________________________ ????????????????? ???????? http://sev.search.yahoo.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From finlayson at live555.com Sun Jul 27 05:28:15 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 27 Jul 2008 13:28:15 +0100 Subject: [Live-devel] Displaying streamed video to a window In-Reply-To: <488B469D0200002D0008C108@gwiasmtp.uct.ac.za> References: <488B469D0200002D0008C108@gwiasmtp.uct.ac.za> Message-ID: >I'm new at using live555. I have looked at the test programs, >specifically the testMPEG1or2VideoStreamer/Receiver. I was able to >get these to compile and run successfully. I now want to modify the >Receiver to display the video in a window instead of writing the >received data to stdout. Look at the source code of a media player application like VLC , which already does this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jul 27 05:28:41 2008 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 27 Jul 2008 13:28:41 +0100 Subject: [Live-devel] Does the newest version support RFC 4585 In-Reply-To: <4152c390807270242ndb433ay22c2abc3130a72c2@mail.gmail.com> References: <4152c390807270242ndb433ay22c2abc3130a72c2@mail.gmail.com> Message-ID: >I'm using the libraries provided by live555 for streaming server >development. I want to know whether the current version supports RFC >4585, in which an extended RTP profile for RTCP is defined. No. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From prbhagwat at gmail.com Sun Jul 27 23:48:04 2008 From: prbhagwat at gmail.com (Pramod Bhagwat) Date: Mon, 28 Jul 2008 12:18:04 +0530 Subject: [Live-devel] Regarding FileSink destructor Message-ID: Hi Ross, This may not be serious bug. The FileSink destructor present in FileSink.cpp is directly closing the fileHandle, Instead of this it is preferred if it calls "CloseOutputFile" which takes care of not closing stdout,stderr file handles. Warm Regards, prb -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.muzzaffar at verticity.com Mon Jul 28 21:58:49 2008 From: ali.muzzaffar at verticity.com (ali.muzzaffar at verticity.com) Date: Tue, 29 Jul 2008 00:58:49 -0400 (Eastern Daylight Time) Subject: [Live-devel] Live555 injector->setDestination() Message-ID: <.202.5.140.130.1217307529.squirrel@mail.verticity.com> Hello, ? I have installed the Live555 and Darwin Server v 5.5.5. ? I am trying to stream like this testMPEG4VideoToDarwin 192.168.2.63 ? But I am getting this error. I don’t understand what is the problem, if somebody has encountered similar type of problem then reply us and let us know how you have resolved the issue. ? ? injector->setDestination() failed: cannot handle ANNOUNCE response: RTSP/1.0 412 ?Precondition Failed ? It is working fine with testMPEG1&2VideoToDarwin but we are not able to receive the stream from Darwin Server. ? I will be thankful for the reply. ? Ali Muzzaffar Software Engineer Verticity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mamille1 at rockwellcollins.com Wed Jul 30 07:58:19 2008 From: mamille1 at rockwellcollins.com (mamille1 at rockwellcollins.com) Date: Wed, 30 Jul 2008 09:58:19 -0500 Subject: [Live-devel] Very large P-frames in a recording Message-ID: All We're working with an embedded system that receives an MPEG-2 transport stream from a TI DSP. We've built an application that uses the live555 libraries to write this stream out to disk. Every once in a while a very large P-frame, on the order of four times the size of a typical P-frame in the stream, is written out to the file. It's very intermittent -- it might happen once out of 6,000 frames. Has anyone else seen this happen? We're beginning to dig into this. We're concerned that our application might be mashing together several P-frames' worth of data, or that we are not using the live555 library correctly. I've reviewed the last several months of the mailing list, but didn't see anything that seemed relevant. Thanks for your help. -=- Mike Miller Rockwell Collins, Inc. Cedar Rapids, IA -------------- next part -------------- An HTML attachment was scrubbed... URL: From prbhagwat at gmail.com Wed Jul 30 23:19:43 2008 From: prbhagwat at gmail.com (Pramod Bhagwat) Date: Thu, 31 Jul 2008 11:49:43 +0530 Subject: [Live-devel] Regarding MP3 FileSource Message-ID: Hi Ross, following may be bug in the MP3FileSource present in MP3FileSource.cpp 1. MP3FileSource destructor is not closing the input file. It needs to call CloseInputFile here. 2. In MP3FileSource::createNew class before the final statement return NULL, call to CloseInputFile is required.(i.e. if newSource creation fails, it needs to close the already opened file) Warm Regards, prb -------------- next part -------------- An HTML attachment was scrubbed... URL: From kumar.bala at DSP-Weuffen.de Thu Jul 31 01:32:16 2008 From: kumar.bala at DSP-Weuffen.de (Kumar Bala) Date: Thu, 31 Jul 2008 10:32:16 +0200 Subject: [Live-devel] Benchmarking Live555 mpeg 4 streaming Message-ID: <48917890.1030603@dsp-weuffen.de> Hi, I would like to benchmark the Live555 implementation of RTSP protocl. I would like to understand the latency caused by the streaming layer in my system. Below is the system architecture ---------------------------- Live555 Streaming system RTSP/RTP/UDP ---------------------------- MPEG4 HD 720p Encoder (30 ms) ---------------------------- V4L2 Capture Driver (40 ms) ---------------------------- Device Specific Driver ---------------------------- HD CCD/CMOS Sensor (40ms) In the brackets are the latencies caused by the corresponding block. Assuming that the streaming is instantaneous, I would like to understand how much latency is caused by the Live555 streaming layer. Are there any existing instrumentation to measure this ? Is it possible to reduce the latency of the streaming protocol. What are the best points to probe to get a better understanding of the latency inside Live555 ? Thanks Kumar From finlayson at live555.com Thu Jul 31 09:57:34 2008 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 31 Jul 2008 17:57:34 +0100 Subject: [Live-devel] Benchmarking Live555 mpeg 4 streaming In-Reply-To: <20080724023039.GB7393@hovland.org> References: <20080724023039.GB7393@hovland.org> Message-ID: IMHO, the best way to measure the performance of a LIVE555-based system is to record the time taken to traverse each 'link' in the data chain - i.e., record the time at which each piece of data enters the chain (in its 'network reading' or after getting' function). Also, for RTP sinks, you should record the time that each packet gets sent. In particular, for "MultiFramedRTPSink", you would record the times at which "afterGettingFrame" gets called, and the times at which "sendPacket()" is called. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From roland at wingmanteam.com Thu Jul 31 11:24:03 2008 From: roland at wingmanteam.com (Roland) Date: Thu, 31 Jul 2008 11:24:03 -0700 Subject: [Live-devel] Very large P-frames in a recording In-Reply-To: References: Message-ID: <001501c8f33a$9c688f50$d539adf0$@com> Hi Mike Perhaps the P-frame is really that big when sent from the source? I've used Wireshark (http://www.wireshark.org/) to capture the raw network packets, then go to "Statistics", "RTP", "Analyse Streams..." to get an insight what the source is *really* sending... E.g. it turns out that my source was sending flawless audio, but the video stream had corrupted packets every now and then... Roland PS: One way to rule out the "mash-together" theory could be to have a look at the big P-frame with a hex-editor. Look for sequences like 00 00 01 xx. These are start markers for MPEG-2. Make a list of these markers and look them up in the MPEG-2 spec in regards to what they mean (e.g. xx==b3 is sequence_header, xx==00 is picture_start, xx==01-af is slice_start). If you see multiple picture starts or the same slice code repeat, then indeed the frame is mashed together. From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of mamille1 at rockwellcollins.com Sent: Wednesday, July 30, 2008 7:58 AM To: live-devel at ns.live555.com Subject: [Live-devel] Very large P-frames in a recording All We're working with an embedded system that receives an MPEG-2 transport stream from a TI DSP. We've built an application that uses the live555 libraries to write this stream out to disk. Every once in a while a very large P-frame, on the order of four times the size of a typical P-frame in the stream, is written out to the file. It's very intermittent -- it might happen once out of 6,000 frames. Has anyone else seen this happen? We're beginning to dig into this. We're concerned that our application might be mashing together several P-frames' worth of data, or that we are not using the live555 library correctly. I've reviewed the last several months of the mailing list, but didn't see anything that seemed relevant. Thanks for your help. -=- Mike Miller Rockwell Collins, Inc. Cedar Rapids, IA -------------- next part -------------- An HTML attachment was scrubbed... URL: