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: