From TAYK0004 at ntu.edu.sg Mon Jan 1 14:01:33 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Tue, 2 Jan 2007 06:01:33 +0800 Subject: [Live-devel] H264VideoStreamFramer Message-ID: <438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg> Hi guys, i attempted to write the h.264videoframer. Can you guy help me take a look? I am super noivce in this area but thanks to the many help provided so far. // Additional Implementation for H264videostreamframer void H264VideoStreamFramer::doGetNextFrame() { // Try to read as many bytes as will fit in the buffer provided // (or "fPreferredFrameSize" if less) if (fPreferredFrameSize > 0 && fPreferredFrameSize < fMaxSize) { fMaxSize = fPreferredFrameSize; } fFrameSize = g_video_enc_rbuf->read(fTo,fMaxSize,0); //g_video_enc_rbuf is a ring buffer which contains the encoded video // Record the current time as the 'presentation time': gettimeofday(&fPresentationTime, NULL); } I have problem understanding and writing the "currentNALUnitEndsAccessUnit()". Can someone provide more information on this? Many thanks in advanced. Regards zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070101/2922a22d/attachment.html From finlayson at live555.com Mon Jan 1 16:07:44 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 1 Jan 2007 16:07:44 -0800 Subject: [Live-devel] H264VideoStreamFramer In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg> Message-ID: > fFrameSize = g_video_enc_rbuf->read(fTo,fMaxSize,0); >//g_video_enc_rbuf is a ring buffer which contains the encoded video This will work only if the 'read()' function returns only a complete NAL unit - nothing more and nothing less. Also, you should really be doing the read asynchronously - e.g., using TaskScheduler::turnOnBackgroundReadProcessing()". Otherwise your application won't be able to do any work while your 'read()' function is blocked waiting for data. >I have problem understanding and writing the >"currentNALUnitEndsAccessUnit()". Can someone provide more >information on this? An 'access unit' is a complete video frame (which is typically made up from several consecutive NAL units). Your "currentNALUnitEndsAccessUnit()" function returns True iff the NAL unit that you're currently delivering is the last NAL unit in an access unit (video frame). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070101/22d47252/attachment.html From mrnikhilagrawal at gmail.com Mon Jan 1 21:15:43 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Tue, 2 Jan 2007 10:45:43 +0530 Subject: [Live-devel] Regarding MPEG1or2AudioVideo Streaming Message-ID: <733cde3e0701012115y70c731e7q4f5e12545b369d8d@mail.gmail.com> Hi, In case of using testMPEG1or2AudioVideoStreamer , server starts broadcasting/unicasting data as soon as it gets started. I want to make it start unicasting , only when a request from client comes ( like Wav streaming is working) , so how can i proceed to do so? Regards, Nikhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070101/84a45fc4/attachment.html From nimesh.kanoth at gmail.com Mon Jan 1 23:01:28 2007 From: nimesh.kanoth at gmail.com (Nimesh Kanoth) Date: Tue, 2 Jan 2007 16:01:28 +0900 Subject: [Live-devel] Regarding the mpeg2-ts streaming Message-ID: Dear all , I have a mpeg2-ts file of size 2.4 GB. when I try to stream this file usin./testMPEG2TransportStreamer I am getting below error [main:60]destinationAddressStr-232.255.42.42 RTCPInstance[0x8a67598]::RTCPInstance() schedule(2.384201->1167721181.463044) Play this stream using the URL "rtsp://10.81.32.156/testStream" Beginning streaming... unable to open file Unable to open file "test.ts" as a byte-stream file source Please give me some suggestons.. Nimesh Kanoth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070101/99240f8a/attachment.html From ritsgenx at gmail.com Mon Jan 1 23:32:38 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Tue, 2 Jan 2007 13:02:38 +0530 Subject: [Live-devel] Query regarding video streaming of MPEG file Message-ID: Hi, I have been working on Live555 for around 4 days. Its really an interesting Open source media server. I have few queiries and it will be great if you can help me: 1. Using the testonDemandRTPServer.cpp i have been able to stream .MPEG files (MPEG1, MPEG-2) files. But there exist test code for a. // A MPEG-1 or 2 audio+video program stream b. // A MPEG-1 or 2 video elementary stream So, my question is what is the mail difference between MPEG program stream and MPEG elementary stream. 2. According to the documentaion of Live555 RTSP streaming is supported by the following clients : a. QuickTime b. VLC c. Real Player Can anyone suggest any other (either proprietary or free / open source or paid) media client that support rtsp stream from Live555 server. 3. I have personally tried streaming on following file extension: .mpeg, .dat. .wav, .mp3 My third question is on what other file extension Live555 support streaming. Specially i want to know about file .avi, .3gp and .mp4 4. Is this possible to inform the client machine that on which player this stream needs to be play. For examle it is possible to inform the client machine that this video stream should be played by Real Player. Can we make some changes in the source code of Live555 for the same. Thanks. I will be waiting for your reply. Regards, Ritesh Mittal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070101/43b5e63c/attachment.html From finlayson at live555.com Tue Jan 2 00:21:54 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 00:21:54 -0800 Subject: [Live-devel] Query regarding video streaming of MPEG file In-Reply-To: References: Message-ID: > So, my question is what is the mail difference between MPEG >program stream and MPEG elementary stream. The former has audio and video streams multiplexed together; the latter is just a single video (or audio) stream. See the MPEG specifications for more information. > > 2. According to the documentaion of Live555 RTSP streaming is >supported by the following clients : > > a. QuickTime > b. VLC > c. Real Player > > Can anyone suggest any other (either proprietary or free / open >source or paid) media client that support rtsp stream from Live555 >server. openRTSP The Amino set-top box (for playing MPEG-2 Transport Streams only) probably lots of other clients > >3. I have personally tried streaming on following file extension: > > .mpeg, .dat. .wav, .mp3 I have no idea what a ".dat" file is. > > My third question is on what other file extension Live555 support >streaming. Specially i want to know about file .avi, .3gp and .mp4 No, not yet. > >4. Is this possible to inform the client machine that on which >player this stream needs to be play. > For examle it is possible to inform the client machine that this >video stream should be played by Real Player. That makes no sense, because if RealPlayer is being used to access the stream, then it *is* the client (by definition). (If you are talking about launching a media player automatically from a web browser, then that is a question for some other mailing list.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 2 00:22:22 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 00:22:22 -0800 Subject: [Live-devel] Regarding MPEG1or2AudioVideo Streaming In-Reply-To: <733cde3e0701012115y70c731e7q4f5e12545b369d8d@mail.gmail.com> References: <733cde3e0701012115y70c731e7q4f5e12545b369d8d@mail.gmail.com> Message-ID: >Hi, > >In case of using testMPEG1or2AudioVideoStreamer , server starts >broadcasting/unicasting data as soon as it gets started. I want to >make it start unicasting , only when a request from client comes ( >like Wav streaming is working) , so how can i proceed to do so? Use "testOnDemandRTSPServer", or the "live555MediaServer". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 2 00:24:13 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 00:24:13 -0800 Subject: [Live-devel] Regarding the mpeg2-ts streaming In-Reply-To: References: Message-ID: >Dear all , > >I have a mpeg2-ts file of size 2.4 GB. when I try to stream this >file usin./testMPEG2TransportStreamer >I am getting below error > >[main:60]destinationAddressStr-232.255.42.42 >RTCPInstance[0x8a67598]::RTCPInstance() >schedule(2.384201->1167721181.463044) >Play this stream using the URL "rtsp://10.81.32.156/testStream" >Beginning streaming... >unable to open file >Unable to open file "test.ts" as a byte-stream file source Are you sure that the file "test.ts" exists in the "testProgs" directory (and that it's readable)? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/212a2bfa/attachment.html From armandopoulos at yahoo.fr Tue Jan 2 02:50:02 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Tue, 2 Jan 2007 10:50:02 +0000 (GMT) Subject: [Live-devel] (no subject) Message-ID: <20070102105003.79798.qmail@web86910.mail.ukl.yahoo.com> hallo all, i am a new user form the live555 but how can i modify the quantization value in with the source files ? thx and happy new yeah. Armando __________________________________________________ Do You Yahoo!? En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicit?s http://mail.yahoo.fr Yahoo! Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/b32dbfc8/attachment-0001.html From nimesh.kanoth at gmail.com Tue Jan 2 03:31:21 2007 From: nimesh.kanoth at gmail.com (Nimesh Kanoth) Date: Tue, 2 Jan 2007 03:31:21 -0800 Subject: [Live-devel] to Rossy Message-ID: Hi, yeah I am sure that is readable and present in testprog directory. Rgds nimesh >Dear all , > >I have a mpeg2-ts file of size 2.4 GB. when I try to stream this >file usin./testMPEG2TransportStreamer >I am getting below error > >[main:60]destinationAddressStr-232.255.42.42 >RTCPInstance[0x8a67598]::RTCPInstance() >schedule(2.384201->1167721181.463044) >Play this stream using the URL "rtsp://10.81.32.156/testStream" >Beginning streaming... >unable to open file >Unable to open file "test.ts" as a byte-stream file source Are you sure that the file "test.ts" exists in the "testProgs" directory (and that it's readable)? -- Nimesh Kanoth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/61e7f5ab/attachment.html From rishikerala at gmail.com Tue Jan 2 04:05:34 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Tue, 2 Jan 2007 04:05:34 -0800 Subject: [Live-devel] hi all need help for trickmode Message-ID: <4ba29cc0701020405p186db64cgda4b8c73958c7857@mail.gmail.com> Hi all, I want to give support for trickmode in mpeg2-ts streaming. any one have idea about this. Please help me to get some information. i am using live media library to stream media content to my board. still under intergartion.Please help me to get some information. I am using a hardware decoder based board. So how can i give trick mode support. rgds Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/f66c3c64/attachment.html From finlayson at live555.com Tue Jan 2 07:42:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 07:42:14 -0800 Subject: [Live-devel] to Rossy In-Reply-To: References: Message-ID: > >Hi, >yeah I am sure that is readable and present in testprog directory. Then you're going to have to trace through the call to "OpenInputFile()" (in "liveMedia/InputFile.cpp"), to figure out why the call to "fopen" is failing. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 2 07:43:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 07:43:20 -0800 Subject: [Live-devel] hi all need help for trickmode In-Reply-To: <4ba29cc0701020405p186db64cgda4b8c73958c7857@mail.gmail.com> References: <4ba29cc0701020405p186db64cgda4b8c73958c7857@mail.gmail.com> Message-ID: >I want to give support for trickmode in mpeg2-ts streaming. any one >have idea about this. See -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/b24050bc/attachment.html From rishikerala at gmail.com Tue Jan 2 17:16:49 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Tue, 2 Jan 2007 17:16:49 -0800 Subject: [Live-devel] to Rossy In-Reply-To: References: Message-ID: <4ba29cc0701021716w44cf24eev2c785e3b72642cba@mail.gmail.com> Hi Ross, I debug that file with a simple program. fd = fopen("test.ts","rb") if (fd == NULL) perror(Failed to open"); error it is givingas ./a.out Failed to open : File too large. How to slove this Rgds Rishi On 1/2/07, Ross Finlayson wrote: > > > > >Hi, > >yeah I am sure that is readable and present in testprog directory. > > Then you're going to have to trace through the call to > "OpenInputFile()" (in "liveMedia/InputFile.cpp"), to figure out why > the call to "fopen" is failing. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/17e4d90b/attachment.html From rishikerala at gmail.com Tue Jan 2 19:51:33 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Tue, 2 Jan 2007 19:51:33 -0800 Subject: [Live-devel] hi all need help for trickmode In-Reply-To: References: <4ba29cc0701020405p186db64cgda4b8c73958c7857@mail.gmail.com> Message-ID: <4ba29cc0701021951k64be9f3fk70484eb62b3f9ba1@mail.gmail.com> Hi Ross, I try to use the trick mode support.. MPEG2TransportStreamIndexer avc_css.ts Writing index file "avc_css.tsx" ............ done. It takes around 5 mins. then when i tried to check the size of file du -h avc_css.tsx 0 It is showing zero .. when I try to use testMPEG2TransportStreamTrickPlay avc_css.ts 0 8 avc_new.ts Warning: Size of the index file " Warning: Size of the index file "avc_css.tsx" (0) is not a multiple of the index record size (11) Writing output file "avc_new.ts" (start time 0.000000, scale 8)......done Please give me a suggestion thanks Nimesh On 1/2/07, Ross Finlayson wrote: > > I want to give support for trickmode in mpeg2-ts streaming. any one have > idea about this. > > > > See tml> > > -- > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/7126227c/attachment.html From finlayson at live555.com Tue Jan 2 19:57:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 19:57:07 -0800 Subject: [Live-devel] "fopen()" problem with large files on Fedora? In-Reply-To: <4ba29cc0701021948j1b794689k9778dfad30abf264@mail.gmail.com> References: <4ba29cc0701021716w44cf24eev2c785e3b72642cba@mail.gmail.com> <4ba29cc0701021948j1b794689k9778dfad30abf264@mail.gmail.com> Message-ID: Can anyone shed light on this guy's problem. He says he's using Fedora Core 5, but gets a "File too large" error when he tries to open a 2+ GByte file using "fopen()". I thought that all modern OSs could now handle files this large? Could he perhaps be using an out-of-date version of "libc" instead?? >I am using Fedora Core 5 here. >thanks >Rgds >Rishi > >On 1/3/07, Ross Finlayson ><finlayson at live555.com > wrote: > > >I debug that file with a simple program. >>fd = fopen("test.ts ","rb") >>if (fd == NULL) perror(Failed to open"); >> >> >>error it is givingas >>./a.out >>Failed to open >>: File too large. >> >>How to slove this > >You need to upgrade to a newer operating system (one that supports >files >2^31 bytes in size). >-- > >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/3197fba3/attachment.html From finlayson at live555.com Tue Jan 2 20:04:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 20:04:21 -0800 Subject: [Live-devel] hi all need help for trickmode In-Reply-To: <4ba29cc0701021951k64be9f3fk70484eb62b3f9ba1@mail.gmail.com> References: <4ba29cc0701020405p186db64cgda4b8c73958c7857@mail.gmail.com> <4ba29cc0701021951k64be9f3fk70484eb62b3f9ba1@mail.gmail.com> Message-ID: >I try to use the trick mode support.. > >MPEG2TransportStreamIndexer avc_css.ts >Writing index file "avc_css.tsx" ............ done. It takes around 5 mins. >then when i tried to check the size of file >du -h avc_css.tsx >0 > >It is showing zero .. Once again - You Have Complete Source Code. You're going to have to track down yourself what's going wrong on your system. I suspect that it is related to the problem that you are having opening your >2GByte file. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rishikerala at gmail.com Tue Jan 2 20:53:41 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Wed, 3 Jan 2007 13:53:41 +0900 Subject: [Live-devel] hi all need help for trickmode In-Reply-To: References: <4ba29cc0701020405p186db64cgda4b8c73958c7857@mail.gmail.com> <4ba29cc0701021951k64be9f3fk70484eb62b3f9ba1@mail.gmail.com> Message-ID: <4ba29cc0701022053u644c893dp13d9d2e38edef320@mail.gmail.com> Hi, I am now in confusion see this test.ts is playing good with mplayer. I just compiled mplayer and installed. It is playing properly. just wonder. I copied the out put of mplayer MPlayer 1.0rc1-4.1.0 (C) 2000-2006 MPlayer Team CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (Family: 15, Model: 4, Stepping: 1) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 Playing avc_csj.ts. TS file format detected. VIDEO H264(pid=481) AUDIO MPA(pid=482) NO SUBS (yet)! PROGRAM N. 1 FPS seems to be: 29.970030 ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264) ========================================================================== ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 224.0 kbit/14.58% (ratio: 28000->192000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== AO: [oss] 48000Hz 2ch s16le (2 bytes per sample) Starting playback... [h264 @ 0x87aa638]PAFF interlacing is not implemented [h264 @ 0x87aa638]PAFF interlacing is not implemented [h264 @ 0x87aa638]PAFF interlacing is not implemented [h264 @ 0x87aa638]PAFF interlacing is not implemented [h264 @ 0x87aa638]concealing 4080 DC, 4080 AC, 4080 MV errors VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 1920x1080 => 1920x1080 Planar YV12 [xv] Source image dimensions are too high: 1920x1080 (maximum is 1440x1080) Is it because the Source Image dimensions.. rgds rishi On 1/3/07, Ross Finlayson wrote: > > >I try to use the trick mode support.. > > > >MPEG2TransportStreamIndexer avc_css.ts > >Writing index file "avc_css.tsx" ............ done. It takes around 5 > mins. > >then when i tried to check the size of file > >du -h avc_css.tsx > >0 > > > >It is showing zero .. > > Once again - You Have Complete Source Code. You're going to have to > track down yourself what's going wrong on your system. > > I suspect that it is related to the problem that you are having > opening your >2GByte file. > > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/1f985a4d/attachment-0001.html From rishikerala at gmail.com Tue Jan 2 21:17:18 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Wed, 3 Jan 2007 14:17:18 +0900 Subject: [Live-devel] find problem in Large size Message-ID: <4ba29cc0701022117p3565d2b7l5c310841e88f851b@mail.gmail.com> Hi Ross, I fI use fopen64 and with some CFLAGS settings like CFLAGS+= -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE Now I can open this files. can You give some suggestions what we need change any thing other than this to support for Large files. Thank you for You kind coperation. One more Still I am not getting the trick mode problem , I am trying to solve that also. Any idea please pass to me Thanks Rgds Rishi n 1/3/07, Ross Finlayson wrote: > > Can anyone shed light on this guy's problem. He says he's using Fedora > Core 5, but gets a "File too large" error when he tries to open a 2+ GByte > file using "fopen()". I thought that all modern OSs could now handle files > this large? > > Could he perhaps be using an out-of-date version of "libc" instead?? > > > I am using Fedora Core 5 here. > thanks > Rgds > Rishi > > On 1/3/07,* Ross Finlayson* wrote: > > >I debug that file with a simple program. > >fd = fopen("test.ts ","rb") > >if (fd == NULL) perror(Failed to open"); > > > > > >error it is givingas > >./a.out > >Failed to open > >: File too large. > > > >How to slove this > > You need to upgrade to a newer operating system (one that supports > files >2^31 bytes in size). > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070102/896b397b/attachment.html From jackymaillist at gmail.com Tue Jan 2 22:43:29 2007 From: jackymaillist at gmail.com (Jacky Cheung) Date: Wed, 03 Jan 2007 14:43:29 +0800 Subject: [Live-devel] Device Source Message-ID: <459B5091.7020905@gmail.com> Hi, I've read the faq on how to stream live source instead of from a file. And now I am thinking how to implement the deviceSource.cpp. In my case, my device will stream out MPEG4 frame by frame via a socket. After reading the comment of deviceSource.cpp, seemed that I need to implement deliverFrame() and doGetNextFrame(). However, I've got confused with these functions. What I think is ::doGetNextFrame() is called by the parent class for streaming out the frame via RTP. And ::deliverFrame() is used to obtain a new frame from device. Am I right? If so, I think I need to add the deliverFrame() to envir().taskScheduler().turnOnBackgroundHandling(..) and pack the incoming frame to a buffer or queue. And one doGetNextFrame() is called, then it should prepare fTo, fFrameSize, etc . Am I right? Thanks a lot Regards, Jacky From morgan.torvolt at gmail.com Tue Jan 2 23:23:23 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Wed, 3 Jan 2007 11:23:23 +0400 Subject: [Live-devel] "fopen()" problem with large files on Fedora? In-Reply-To: References: <4ba29cc0701021716w44cf24eev2c785e3b72642cba@mail.gmail.com> <4ba29cc0701021948j1b794689k9778dfad30abf264@mail.gmail.com> Message-ID: <3cc3561f0701022323k482296c9q3a5436760b97ac5@mail.gmail.com> Hi folks. Experienced the same problem. I believe what we did was alter the first line of the config.linux file to this: COMPILE_OPTS = $(INCLUDES) -I. -O2 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 IIRC it was the file offset bits that did the trick. This needed to be done even on our AMD64 based computer running 64 bits linux. Don't ask why, I don't know... Best "new year" regards -Morgan- On 03/01/07, Ross Finlayson wrote: > > > Can anyone shed light on this guy's problem. He says he's using Fedora Core > 5, but gets a "File too large" error when he tries to open a 2+ GByte file > using "fopen()". I thought that all modern OSs could now handle files this > large? > > > Could he perhaps be using an out-of-date version of "libc" instead?? > > > > > I am using Fedora Core 5 here. > thanks > Rgds > Rishi > > On 1/3/07, Ross Finlayson wrote: > > >I debug that file with a simple program. > >fd = fopen("test.ts ","rb") > >if (fd == NULL) perror(Failed to open"); > > > > > >error it is givingas > >./a.out > >Failed to open > >: File too large. > > > >How to slove this > > You need to upgrade to a newer operating system (one that supports > files >2^31 bytes in size). > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > From finlayson at live555.com Tue Jan 2 23:25:52 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 23:25:52 -0800 Subject: [Live-devel] find problem in Large size In-Reply-To: <4ba29cc0701022117p3565d2b7l5c310841e88f851b@mail.gmail.com> References: <4ba29cc0701022117p3565d2b7l5c310841e88f851b@mail.gmail.com> Message-ID: >I fI use fopen64 and with some CFLAGS settings like CFLAGS+= >-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE >Now I can open this files. can You give some suggestions what we >need change any thing other than this to support for Large files. I've never heard of "fopen64()" before. And I've never heard of any (modern) operating system that can't open large files with the regular "fopen()" routine. It seems clear that you're not using the standard runtime libraries. You're on your own now - sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 2 23:39:18 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 2 Jan 2007 23:39:18 -0800 Subject: [Live-devel] "fopen()" problem with large files on Fedora? In-Reply-To: <3cc3561f0701022323k482296c9q3a5436760b97ac5@mail.gmail.com> References: <4ba29cc0701021716w44cf24eev2c785e3b72642cba@mail.gmail.com> <4ba29cc0701021948j1b794689k9778dfad30abf264@mail.gmail.com> <3cc3561f0701022323k482296c9q3a5436760b97ac5@mail.gmail.com> Message-ID: >Hi folks. > >Experienced the same problem. I believe what we did was alter the >first line of the config.linux file to this: > >COMPILE_OPTS = $(INCLUDES) -I. -O2 -DSOCKLEN_T=socklen_t >-D_LARGEFILE_SOURCE=1 -D_FILE_OFFSET_BITS=64 > >IIRC it was the file offset bits that did the trick. This needed to be >done even on our AMD64 based computer running 64 bits linux. Don't ask >why, I don't know... OK, so to be on the safe side I'll add - to the next release of the software - the flag -D_FILE_OFFSET_BITS=64 to the COMPILE_OPTS line in each of the "linux" config files. ("-D_LARGEFILE_SOURCE=1" is already there.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kurutepe at nue.tu-berlin.de Wed Jan 3 02:30:26 2007 From: kurutepe at nue.tu-berlin.de (Engin Kurutepe) Date: Wed, 03 Jan 2007 11:30:26 +0100 Subject: [Live-devel] h.264 media subsession implementation Message-ID: <459B85C2.6090206@nue.tu-berlin.de> Hello All, Are any implementations for H.264 media subsessions as defined in RFC 3984 available? Best wishes for the new year, Engin. From TAYK0004 at ntu.edu.sg Wed Jan 3 06:44:01 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Wed, 3 Jan 2007 22:44:01 +0800 Subject: [Live-devel] more help on h.264 References: <438567054C073949AEBE5A28B83E7DE133FC8D@MAIL21.student.main.ntu.edu.sg> Message-ID: <438567054C073949AEBE5A28B83E7DE133FC8E@MAIL21.student.main.ntu.edu.sg> Hi Ross, thanks for helping me with the h.264 framer. Few more questions before I test out the framer. 1) "currentNALUnitEndsAccessUnit()" - for this boolean function, how do we know whether a NAL unit is the last unit in a frame? How different is this NAL unit so that i can write a IF statement 2) My teammate is still working on the encoder so I can only test with a encoded file. The file is using Annex B file format. Do I have to amend the previous framer which i posted to take into account? // Additional Implementation for H264videostreamframer void H264VideoStreamFramer::doGetNextFrame() { // Try to read as many bytes as will fit in the buffer provided // (or "fPreferredFrameSize" if less) if (fPreferredFrameSize > 0 && fPreferredFrameSize < fMaxSize) { fMaxSize = fPreferredFrameSize; } fFrameSize = g_video_enc_rbuf->read(fTo,fMaxSize,0); //g_video_enc_rbuf is a ring buffer which contains the encoded video // Record the current time as the 'presentation time': gettimeofday(&fPresentationTime, NULL); } Many thanks again. Hopefully I can make it by dateline Regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070103/f46dc195/attachment.html From TAYK0004 at ntu.edu.sg Wed Jan 3 08:39:22 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Thu, 4 Jan 2007 00:39:22 +0800 Subject: [Live-devel] currentNALUnitEndsAccessUnit() Message-ID: <438567054C073949AEBE5A28B83E7DE133FC91@MAIL21.student.main.ntu.edu.sg> Hi guys, after reading more ont he encoder, I discovered that NAL unit of type 11 will declare end of stream. Is it the one which the currentNALUnitEndsAccessUnit will check? If the NAL unit that is read from the file or buffer belongs to this type, then return false, else retun true? // Is this correct? int currentNALUnitEndsAccessUnit() { if(nal_type ==11) return 1; else return 0; } Many thanks once again. zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070103/16379da8/attachment.html From xcsmith at rockwellcollins.com Wed Jan 3 08:59:07 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 3 Jan 2007 10:59:07 -0600 Subject: [Live-devel] Initial support for server 'trick play' operations on Transport Stream files Message-ID: >To support 'trick play' operations on a Transport Stream file, the >server must have a corresponding "index file". My server is doing transcoding from MPEG2 PS file to TS stream on the fly, exactly as described by you in recent posts. I can't use this implementation of trick mode then, can I? Xochitl From finlayson at live555.com Wed Jan 3 09:51:02 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Jan 2007 09:51:02 -0800 Subject: [Live-devel] Initial support for server 'trick play' operations on Transport Stream files In-Reply-To: References: Message-ID: > >To support 'trick play' operations on a Transport Stream file, the >>server must have a corresponding "index file". > >My server is doing transcoding from MPEG2 PS file to TS stream on the fly, >exactly as described by you in recent posts. I can't use this >implementation of trick mode then, can I? If you're streaming from a live source (regardless of the media type), then obviously you can't support 'trick play' operations at all. If your source data is a MPEG-2 Program Stream *file* - rather than a MPEG-2 Program Stream live source - then, to support 'trick play', you would need to convert your file, in advance, to a Transport Stream file. You could then create an index file from the Transport Stream file, as I described in my earlier message, and then stream from the Transport Stream file (plus the index file). I.e., don't convert from a Program to a Transport Stream file on the fly, but instead do it in advance. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From TAYK0004 at ntu.edu.sg Wed Jan 3 10:59:16 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Thu, 4 Jan 2007 02:59:16 +0800 Subject: [Live-devel] H.264 Message-ID: <438567054C073949AEBE5A28B83E7DE133FC94@MAIL21.student.main.ntu.edu.sg> Hi guys, found this reading ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Earlier video compression standards were always centered around the concept of a bit stream. Higher layer syntax elements were separated by start codes to allow re-synchronization to the bit stream in case of corruption-be it the result of an erasure or of bit errors. H.264, when employing its optional Annex B, also allows such a framing scheme, primarily to support a few legacy protocol environments such as H.320 or MPEG-2 transport. The RTP packetization, however, employs the native NAL interface that is based on NAL units (NALUs). ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// Does this mean that if my encoder employ Annex B file format, I can use the livemedia MPEG2VideoFramer and MPEG2VideoSink to send the h.264 data over? many thanks. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070103/eabbd191/attachment.html From finlayson at live555.com Wed Jan 3 11:11:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 3 Jan 2007 11:11:39 -0800 Subject: [Live-devel] H.264 In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FC94@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FC94@MAIL21.student.main.ntu.edu.sg> Message-ID: >Earlier video compression standards were always centered around the >concept of a bit stream. Higher layer syntax elements were separated >by start codes to allow re-synchronization to the bit stream in case >of corruption-be it the result of an erasure or of bit errors. > > > >H.264, when employing its optional Annex B, also allows such a >framing scheme, primarily to support a few legacy protocol >environments such as H.320 or MPEG-2 transport. The RTP >packetization, however, employs the native NAL interface that is >based on NAL units (NALUs). > >////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > > > >Does this mean that if my encoder employ Annex B file format, I can >use the livemedia MPEG2VideoFramer and MPEG2VideoSink to send the >h.264 data over? No. The text you quoted referred to the possibility of carrying H.264 video data within a MPEG-2 *Transport* Stream. If you were to do that, then you could stream the Transport Stream data using our Transport Stream-related classes. But to stream H.264/RTP data by itself, you must use "H264VideoRTPSink". I'm probably not going to be answering any more questions about streaming H.264 for a while; I'm getting sick of them... -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070103/42ef6c7b/attachment.html From TAYK0004 at ntu.edu.sg Wed Jan 3 11:35:40 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Thu, 4 Jan 2007 03:35:40 +0800 Subject: [Live-devel] Enquiries on H.264 Framer Message-ID: <438567054C073949AEBE5A28B83E7DE133FC95@MAIL21.student.main.ntu.edu.sg> Hi Ross, > fFrameSize = g_video_enc_rbuf->read(fTo,fMaxSize,0); >//g_video_enc_rbuf is a ring buffer which contains the encoded video > This will work only if the 'read()' function returns only a complete > NAL unit - nothing more and nothing less. for the below comment which u made, can I check with you further. I can set my encoder to produce one frame one slice (VCL NAL unit), and each NAL unit size is limited slightly less than the MTU for LAN. Therefore, my NAL unit will not be fragmented, as such can this statement work? SInce one frame one slice (VCL NAL unit), therefore I can simply write a currentNALUnitEndsAccessUnit() to always be true? int currentNALUnitEndsAccessUnit() { return 1 } Starting to get the hang of it. Just realised that the fPresentationTime will overwrite the time in SEI during decoding. Many thanks for all the help in getting me started on H.264 Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070103/ad18f029/attachment.html From zjuchenjun at hotmail.com Thu Jan 4 00:41:09 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Thu, 4 Jan 2007 16:41:09 +0800 Subject: [Live-devel] about h.264 streaming Message-ID: Hi all, I want to stream h.264 video from a live source using live555, and I have read the FAQ but still I feel it is difficulty to fill the member function. I list some codes I wrote myself below and I have not validate it. I should appreciate if you can give me some suggestions. void H264VideoStreamDiscreteFramer::doGetNextFrame() { //**************************non-blocking fashion**************************// while(1){ watchVariableforH264=0; env->tashScheduler().doEventLoop(&watchVariableforH264); deliverFrame(); } if (fFramsize==0 /* the source stops being readable */) { handleClosure(this); return; } } void H264VideoStreamDiscreteFramer::deliverFrame() { if (!isCurrentlyAwaitingData()) return; // we're not ready for the data yet fFrameSize=LenOfEncode; //LENOFENCODE is defined in another thread if (fFrameSize > fMaxSize) { fNumTruncatedBytes = fFrameSize - fMaxSize; fFrameSize = fMaxSize; } memcpy(fTo,Encode_data,fFrameSize); //Encode_data is defined in another thread //????????? I am not sure how to copy encoded data to the address point by fTo, especially how to deal with // data which be truncated (fNumTruncatedBytes). // Set the 'presentation time': if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0) { // This is the first frame, so use the current time: gettimeofday(&fPresentationTime, NULL); } else { // Increment by the play time of the previous frame (64ms), my encoder?s frame rate is 15.6fps unsigned uSeconds = fPresentationTime.tv_usec + 64000; fPresentationTime.tv_sec += uSeconds/1000000; fPresentationTime.tv_usec = uSeconds%1000000; } fDurationInMicroseconds = 64000; // each frame is 64 ms // Deliver the data here: // ????????? what does this mean? How to Deliver? // After delivering the data, inform the reader that it is now available: FramedSource::afterGetting(this); } Boolean H264VideoStreamDiscreteFramer::currentNALUnitEndsAccessUnit() { // How to know whether the NAL unit that you're currently delivering is the last NAL unit in an access unit (video frame). } _________________________________________________________________ Windows Live Safety Center ?????????????????? http://safety.live.com/site/ZH-CN/default.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/76e941af/attachment-0001.html From ritsgenx at gmail.com Thu Jan 4 01:58:41 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Thu, 4 Jan 2007 15:28:41 +0530 Subject: [Live-devel] regarding JPEG file streaming Message-ID: Hi, Can I directly stream a RTP stream containing JPEG2000 video codec data. I have another query Why cant i stream .avi and .jpeg files since the JPEGSink and AVIFileSink are provided with the source code of LIVE555 server. Thanks Regards, Ritesh Mittal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/9787ec44/attachment.html From ritsgenx at gmail.com Thu Jan 4 02:29:26 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Thu, 4 Jan 2007 15:59:26 +0530 Subject: [Live-devel] Can I stream a series of BMP images Message-ID: Hi, Can i stream a series of BMP images. if not directly is there any indirect method like converting them into some specific format..?? Thanks Regards, Ritesh Mittal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/d202dece/attachment.html From jackymaillist at gmail.com Thu Jan 4 02:39:32 2007 From: jackymaillist at gmail.com (Jacky Cheung) Date: Thu, 04 Jan 2007 18:39:32 +0800 Subject: [Live-devel] class MPEG4VideoStreamDiscreteFramer Message-ID: <459CD964.8000308@gmail.com> Hi Is that the following class is not in used when running mediaServer? class MPEG4VideoStreamDiscreteFramer If so, what is the purpose of this class? Thx a lot Regards, Jacky Cheung From shaswata at alumnux.com Thu Jan 4 03:20:39 2007 From: shaswata at alumnux.com (Shaswata Jash) Date: Thu, 4 Jan 2007 16:50:39 +0530 Subject: [Live-devel] Can I stream a series of BMP images References: Message-ID: <012b01c72ff2$5d02bc80$2e0aa8c0@NITU> Hi Ritesh, You can obviously change those series of BMP images to RGB frames and then encode those series of RGB frames to any video format like MPEG4 or H.263 etc. For that you have to use third party encoding libraries like ffmpeg. Now you can use Live to stream those encoded video. The whole process is possible in real time. With regards, Shaswata Jash --------------------------------------- Alumnus Software Ltd. Infinity, Tower II, 2nd Floor Plot A3, Block GP, Sector - V, Salt Lake City, Kolkata - 700 091, India Phone: (+91 33) 2357 5626/5627/5628 www.alumnux.com ----- Original Message ----- From: Ritesh Mittal To: live-devel at ns.live555.com Sent: Thursday, January 04, 2007 3:59 PM Subject: [Live-devel] Can I stream a series of BMP images Hi, Can i stream a series of BMP images. if not directly is there any indirect method like converting them into some specific format..?? Thanks Regards, Ritesh Mittal ------------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/8ce910ff/attachment.html From finlayson at live555.com Thu Jan 4 08:13:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Jan 2007 08:13:41 -0800 Subject: [Live-devel] class MPEG4VideoStreamDiscreteFramer In-Reply-To: <459CD964.8000308@gmail.com> References: <459CD964.8000308@gmail.com> Message-ID: >class MPEG4VideoStreamDiscreteFramer > >If so, what is the purpose of this class? Read the comment in the code, near the top of the file (under the copyright notice). Remember, You Have Complete Source Code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From the-bishop at rogers.com Thu Jan 4 11:49:56 2007 From: the-bishop at rogers.com (the-bishop at rogers.com) Date: Thu, 4 Jan 2007 11:49:56 -0800 (PST) Subject: [Live-devel] Frame truncation if network bandwidth is not enough Message-ID: <20070104194956.68812.qmail@web88113.mail.re2.yahoo.com> Hi Ross: I have the following problem. I stream videos using Unicast over the Internet using live555 library. The frames are provided by DirectShow streams. The frames are complete, so no framer class from live555 is used. Instead, I simply feed the DirectShow frames to my class derived from SimpleRTPSink. If the network bandwidth is not enough to deliver samples, they arrive truncated on the client side (in afterGettingFrame function). What can possibly be causing it? Is it a part of RTP standard- to truncate frames if they can't be delivered on time? I'd much prefer for samples to arrive late, then to arrive truncated... Any ideas? Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/b28dee63/attachment.html From finlayson at live555.com Thu Jan 4 14:16:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Jan 2007 14:16:40 -0800 Subject: [Live-devel] Frame truncation if network bandwidth is not enough In-Reply-To: <20070104194956.68812.qmail@web88113.mail.re2.yahoo.com> References: <20070104194956.68812.qmail@web88113.mail.re2.yahoo.com> Message-ID: >I have the following problem. I stream videos using Unicast over the >Internet using live555 library. The frames are provided by >DirectShow streams. The frames are complete, so no framer class from >live555 is used. Instead, I simply feed the DirectShow frames to my >class derived from SimpleRTPSink. Out of curiosity, what codec are you using? (Or are you trying to stream raw, uncompressed video data??) > If the network bandwidth is not enough to deliver samples, they >arrive truncated on the client side (in afterGettingFrame function). >What can possibly be causing it? I think you've answered your own question. If you don't have enough network bandwidth, then you're going to get packet loss. Therefore some frames (or parts of some frames, if frames span more than one RTP packet) are going to get lost. > Is it a part of RTP standard- to truncate frames if they can't be >delivered on time? RTP (by default) is an unreliable protocol, over UDP. if packets get lost, then yes, you're going to lose data (of course). > I'd much prefer for samples to arrive late, then to arrive truncated... That's not possible, for a UDP-based protocol. Your real problem is that you don't have enough network bandwidth. From PHarper at c-cor.com Thu Jan 4 14:26:35 2007 From: PHarper at c-cor.com (Harper, Paul) Date: Thu, 04 Jan 2007 14:26:35 -0800 Subject: [Live-devel] Patch to liveMedia for Consideration In-Reply-To: References: Message-ID: <1167949595.14617.17.camel@centos1.c-cor.com> I appreciate your position, thanks for taking a look. I have requested changes to our RTSP server to allow compatibility with liveMedia. -- Paul Harper pharper at c-cor.com 503.531.6438 On Mon, 2006-12-25 at 21:58 -0800, Ross Finlayson wrote: > > Attached is a patch file to liveMedia that I would like to submit > > for consideration. It allows liveMedia to initiate an RTSP session > > on an nCUBE/C-COR video server. The code that was added is similar > > to the code currently in place for Kasenna and Microsoft. > > > Thanks for the submission. Unfortunately, however, I'm getting > increasingly reluctant to keep adding ugly hacks to the RTSP client > code in order to support all sorts of different weird, non-standard > servers. (I realize that - for historical reasons - we already have > ugly code there to support Kasenna servers; however, I'd like to > remove this at some point in the future (as these broken old Kasenna > servers fade into irrelevance).) > > > Our installed base (in VLC, MPlayer, and other RTSP clients) is now > sufficiently large (far larger than the installed base of any > particular RTSP server implementation) that I believe it's now > reasonable and appropriate for us to put pressure on these server > implementors to clean up their implementations to make them more > compliant with standards, and with other existing implementations. > > > With this in mind, rather than add your patch to the code, I ask that > the implementors of the "nCUBE/C-COR" video server make the following > three simple changes to their implementation. If they do this, their > server should - I believe - work with the existing "LIVE555 Streaming > Media" RTSP client implementation - and the large existing installed > base of VLC (and MPlayer etc.) clients: > > > 1/ Change the SDP description returned in response to a RTSP > "DESCRIBE" command to say > RAW/RAW/UDP > instead of > RTP/AVP > (reporting "RTP/AVP" is very wrong, because the server is quite > clearly *not* sending RTP) > > > 2/ Accept "RAW/RAW/UDP" in the "Transport:" header of RTSP "SETUP" > commands (rather than requiring that the string "MP2T/DVBC/UDP" be > used). > > > 3/ Make whatever (presumably minor) fixes are necessary to the server > so that you don't need to modify the existing implementation of the > "constructSubsessionURL()" command. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > plain text document attachment (ATT92777.txt), "ATT92777.txt" > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From the-bishop at rogers.com Thu Jan 4 14:44:43 2007 From: the-bishop at rogers.com (the-bishop at rogers.com) Date: Thu, 4 Jan 2007 14:44:43 -0800 (PST) Subject: [Live-devel] Frame truncation if network bandwidth is not enough Message-ID: <20070104224443.91121.qmail@web88105.mail.re2.yahoo.com> I checked and this truncation seems to be caused by large packet loss. Is this the way UDP operates- if bandwidth is not enough it drops packets? How would it be possible to make sure server sends UDP packets only as fast as the network can let through, so that client gets all packets? I'm talking about the Unicast scenario... Cheers, Michael ----- Original Message ---- From: "the-bishop at rogers.com" To: live-devel at lists.live555.com Sent: Thursday, January 4, 2007 2:49:56 PM Subject: Frame truncation if network bandwidth is not enough Hi Ross: I have the following problem. I stream videos using Unicast over the Internet using live555 library. The frames are provided by DirectShow streams. The frames are complete, so no framer class from live555 is used. Instead, I simply feed the DirectShow frames to my class derived from SimpleRTPSink. If the network bandwidth is not enough to deliver samples, they arrive truncated on the client side (in afterGettingFrame function). What can possibly be causing it? Is it a part of RTP standard- to truncate frames if they can't be delivered on time? I'd much prefer for samples to arrive late, then to arrive truncated... Any ideas? Thanks, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/0ca63b96/attachment-0001.html From rahul.ray at gmail.com Thu Jan 4 15:01:23 2007 From: rahul.ray at gmail.com (Rahul Ray) Date: Thu, 4 Jan 2007 15:01:23 -0800 Subject: [Live-devel] encoding mpeg-4 or mpeg-2 Message-ID: Hi, It would be a great help if some of you can point me to the code of how to encode a sequence of jpg images into mpeg-4 or mpeg-2 ? Thanks in advance. -best, Rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/7b916509/attachment.html From jackymaillist at gmail.com Thu Jan 4 17:06:53 2007 From: jackymaillist at gmail.com (Jacky Cheung) Date: Fri, 05 Jan 2007 09:06:53 +0800 Subject: [Live-devel] class MPEG4VideoStreamDiscreteFramer In-Reply-To: References: <459CD964.8000308@gmail.com> Message-ID: <459DA4AD.4000007@gmail.com> An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/50d91c9e/attachment.html From finlayson at live555.com Thu Jan 4 17:09:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 4 Jan 2007 17:09:39 -0800 Subject: [Live-devel] class MPEG4VideoStreamDiscreteFramer In-Reply-To: <459DA4AD.4000007@gmail.com> References: <459CD964.8000308@gmail.com> <459DA4AD.4000007@gmail.com> Message-ID: >Thanks for your reply. > Is that mean if I have MPEG4 video and can be obtain the vidoe >frame-by-frame. Then I should use this class instead of another one? Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rishikerala at gmail.com Thu Jan 4 19:08:54 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Fri, 5 Jan 2007 12:08:54 +0900 Subject: [Live-devel] Help me for a buffering section from playCommon.cpp In-Reply-To: <4ba29cc0701041849m83df897ic5fe0b877cbf0d48@mail.gmail.com> References: <4ba29cc0701041849m83df897ic5fe0b877cbf0d48@mail.gmail.com> Message-ID: <4ba29cc0701041908t45b8f453h46eaaadfdb03f482@mail.gmail.com> Hi Ross, I know full source is here. I am jusr going through the source for Client module. I am not good in C++. I already written a client module with player I will just give the code below Here In player I am using a VLC stucture. static block_t *Block_New(RMuint32 i_size); static int Block_FifoPut(block_fifo_t*,block_t *); static block_t *Block_FifoGet(block_fifo_t *); static block_fifo_t *Block_FifoNew(); /****************************************************************** * ******************************************************************/ static block_t *BlockParseRTP(block_t *p_block); block_t *stream_Block(RMuint32 i_size,struct context_per_task *p_task); static int Stream_Read_Block(void *p_read, RMuint32 i_read,struct context_per_task *p_task); static block_t *Read_Block(struct context_per_task *); I just want to prebuffer .. to pass to the harware decoder. if(!pre_done){ for(;;){ if(p_task->p_sys == NULL){ printf("stream_sys_t null\n"); goto cleanup; } if(p_task->p_sys-> block.i_size > STREAM_CACHE_SIZE){//STREAM_CACHE_PREBUFFER_SIZE){ printf("[%s:%d] cache size(%lu) pre done\n",__FUNCTION__,__LINE__,p_task->p_sys->block.i_size ); pre_done = TRUE; break; } block_t *b; if((b = Read_Block(p_task)) == NULL){ perror("fetch error"); continue; } // while(b){ p_task->p_sys->block.i_size += b->i_buffer; *p_task->p_sys->block.pp_last = b; p_task->p_sys-> block.pp_last = &b->p_next; b = b->p_next; //} // Block_FifoPut(gp_fifo,b); } p_task->p_sys->block.p_current = p_task->p_sys->block.p_first; } p_block = stream_Block(UDP_PACKET_SIZE * 3,p_task); } static int Block_FifoPut(block_fifo_t *p_fifo, block_t *p_block) { RMuint32 i_size = 0; pthread_mutex_lock(&p_fifo->lock); // do{ i_size += p_block->i_buffer; *p_fifo->pp_last = p_block; p_fifo->pp_last = &p_block->p_next; p_fifo->i_depth++; p_fifo->i_size += p_block->i_buffer; p_block = p_block->p_next; //}while(p_block); pthread_cond_signal(&p_fifo->wait); pthread_mutex_unlock(&p_fifo->lock); return i_size; } I am trying to port the openRTSP module (Client) to my board. Here I have to pass the buffer like this. the player is written in c. so i need to avoid the header portion and pass data to the deoder. I am trying to make a api module from LiveMedia Client module. So that I can get the buffer to the player by calling this api. i am now concentrating on mpeg2-ts only. I just need to get the buffer ( which is skipped with all header). Please give me some idea and where I need to hack for this. this is a personal mail I am doing. If possible help me .. Rgds Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/730059b2/attachment.html From ritsgenx at gmail.com Thu Jan 4 20:37:44 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Fri, 5 Jan 2007 10:07:44 +0530 Subject: [Live-devel] encoding mpeg-4 or mpeg-2 In-Reply-To: References: Message-ID: Hi Rahul, I have the similar query but I want to encode a series of BMP images into mpeg encoding. One of the concept which i came across is first converting the BMP images into RGB format and this format can be converted into MPEG-4 encoding stream using ffmpeg library. And we can stream MPEG-4 encoding stream using LIVE555. Regards, Ritesh Mittal On 1/5/07, Rahul Ray wrote: > > Hi, > It would be a great help if some of you can point me to the code of > how to encode a sequence of jpg images into mpeg-4 or mpeg-2 ? > Thanks in advance. > -best, > Rahul > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/3e13267b/attachment.html From rajeshkumar.r at imimobile.com Thu Jan 4 23:08:42 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Fri, 5 Jan 2007 12:38:42 +0530 Subject: [Live-devel] Hi Message-ID: <002d01c73098$55281180$6902000a@imidomain.com> HI All wish u Happy new Year. I have made one RTSP client using live555 lib. RTSP client is able to recv the video-audio data from Helix server. The audio-video port on which i am recv the streaming content from Helix server is same as the port used to transfer Data to mobile using 3g-H324M protocol. 1)I run the Appl that is responsible to stream the content on mobile. 2)and started my client who is recv the streaming content from Helix server. both the application are running fine independently. both 1 and 2 are using the same port for video and same for audio. I did not recv any n/w event in application 1. Any clue.plz let me know. with Regards Rajesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070104/45bc8282/attachment-0001.html From finlayson at live555.com Fri Jan 5 00:07:25 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Jan 2007 00:07:25 -0800 Subject: [Live-devel] Hi In-Reply-To: <002d01c73098$55281180$6902000a@imidomain.com> References: <002d01c73098$55281180$6902000a@imidomain.com> Message-ID: >I have made one RTSP client using live555 lib. >RTSP client is able to recv the video-audio data from Helix server. >The audio-video port on which i am recv the streaming content from >Helix server >is same as the port used to transfer Data to mobile using 3g-H324M protocol. > >1)I run the Appl that is responsible to stream the content on mobile. >2)and started my client who is recv the streaming content from Helix server. > >both the application are running fine independently. > >both 1 and 2 are using the same port for video and same for audio. > >I did not recv any n/w event in application 1. > >Any clue.plz let me know. In general I can't help people with their custom code. However, have you tried running the supplied "openRTSP" client (preferably with the "-V" option, for verbose output). If it works correctly with your Helix server, but your own RTSP client does not, then that should give you a hint as to what you are doing wrong. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070105/38040b27/attachment.html From rishikerala at gmail.com Fri Jan 5 00:38:13 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Fri, 5 Jan 2007 17:38:13 +0900 Subject: [Live-devel] Hi In-Reply-To: References: <002d01c73098$55281180$6902000a@imidomain.com> Message-ID: <4ba29cc0701050038k73c3cdeal1608adbcb5afa4ec@mail.gmail.com> Hi Ross, In the case of mpeg2ts I can pass the content directly to hardware decoder. I just need to how I can get the buffer to the playComon.cpp appliaction. Instead of saving data. I need video-audio(buffer) data to be in playCommon application. How can I get. If possible give me where I need to see in source for that. i checked the source. it is going to MultiFramedRTPSource.cpp file. Got confused here. So i am asking.. thankyou Rgds Rishi In general I can't help people with their custom code. However, have you > tried running the supplied "openRTSP" client (preferably with the "-V" > option, for verbose output). If it works correctly with your Helix server, > but your own RTSP client does not, then that should give you a hint as to > what you are doing wrong. > > -- > > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070105/ba46ef37/attachment.html From asmundg at snap.tv Fri Jan 5 05:28:52 2007 From: asmundg at snap.tv (=?utf-8?q?=C3=85smund_Grammeltvedt?=) Date: Fri, 5 Jan 2007 14:28:52 +0100 Subject: [Live-devel] Busy waiting on file sources Message-ID: <200701051428.57061.asmundg@snap.tv> Hello. Playing around with the MediaServer, I noticed that cpu usage goes to 100% when streaming from files. It appears that after opening a ByteStreamFileSource and calling ByteStreamFileSource::doGetNextFrame, BasicTaskScheduler will always find that the file socket is ready for reading and will trigger the callback ByteStreamFileSource::fileReadableHandler. This function in turn concludes that we're not really waiting for any data and returns, leading to a new select, a new callback, and so on until the next source actually calls ByteStreamFileSource::doGetNextFrame, resetting fIsCurrentlyAwaitingData. This tight busy-waiting loop eats cpu, but doesn't appear to do anything useful with it. Is there any particular reason why fileReadableHandler cannot call stopGettingFrames, removing the file socket from the select list until the data is actually needed? Applying the attached patch does appear to reduce cpu usage significantly, without any nasty side effects. Is this a reasonable approach, or am I breaking something? -- ?smund Grammeltvedt Snap TV -------------- next part -------------- A non-text attachment was scrubbed... Name: bytestreamfilesource_busy_wait.patch Type: text/x-diff Size: 514 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070105/d900485c/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070105/d900485c/attachment-0001.bin From TAYK0004 at ntu.edu.sg Fri Jan 5 05:46:25 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Fri, 5 Jan 2007 21:46:25 +0800 Subject: [Live-devel] Parser and Framer Message-ID: <438567054C073949AEBE5A28B83E7DE133FC9C@MAIL21.student.main.ntu.edu.sg> Hi guys, I have some enquiries regarding parser and framer function. A parser is used when the video/ audio data is a file and to split the data into frames. If the encoder produces frames directly instead of writing to a file, the parser can be skipped when streaming. Is this true? A framer is to frame the frames produced by the encoder such that they contained information like fFramesize, fPresentationTime. Is this true. Thanks for any help in clarifying. Regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070105/4672b5e3/attachment.html From finlayson at live555.com Fri Jan 5 07:35:12 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Jan 2007 07:35:12 -0800 Subject: [Live-devel] Parser and Framer In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FC9C@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FC9C@MAIL21.student.main.ntu.edu.sg> Message-ID: >I have some enquiries regarding parser and framer function. > >A parser is used when the video/ audio data is a file and to split >the data into frames. If the encoder produces frames directly >instead of writing to a file, the parser can be skipped when >streaming. Is this true? Yes. This is the purpose of "MPEG1or2VideoStreamDiscreteFramer" and "MPEG4VideoStreamDiscreteFramer", for example. (In practice, these classes will do a small amount of 'parsing' within each frame, to get timing information that's used to compute presentation times. See the *DiscreteFramer classes for examples of this. However, they won't need to do any parsing to actually find the start and end of each frame; that information is already given to them. > >A framer is to frame the frames produced by the encoder such that >they contained information like fFramesize, fPresentationTime. Is >this true. Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070105/42e1a340/attachment.html From finlayson at live555.com Fri Jan 5 07:39:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Jan 2007 07:39:20 -0800 Subject: [Live-devel] Busy waiting on file sources In-Reply-To: <200701051428.57061.asmundg@snap.tv> References: <200701051428.57061.asmundg@snap.tv> Message-ID: >Is there any particular reason why fileReadableHandler cannot call >stopGettingFrames, removing the file socket from the select list until the >data is actually needed? Applying the attached patch does appear to reduce >cpu usage significantly, without any nasty side effects. Is this a reasonable >approach, or am I breaking something? No, your approach is OK. A fix, probably similar to this, will appear in the next release of the code. Thanks for the note. Out of curiosity, what kind of data are you streaming when you encounter this situation? (The problem that you noted will occur only for some media types; for others, "doGetNextFrame()" won't end up getting called until the downstream recipient is actually ready to get/handle new data.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From asmundg at snap.tv Fri Jan 5 08:27:28 2007 From: asmundg at snap.tv (=?utf-8?q?=C3=85smund_Grammeltvedt?=) Date: Fri, 5 Jan 2007 17:27:28 +0100 Subject: [Live-devel] Busy waiting on file sources In-Reply-To: References: <200701051428.57061.asmundg@snap.tv> Message-ID: <200701051727.32176.asmundg@snap.tv> On Friday 05 January 2007 16:39, Ross Finlayson wrote: > No, your approach is OK. A fix, probably similar to this, will > appear in the next release of the code. Thanks for the note. Thanks for the quick response! > Out of curiosity, what kind of data are you streaming when you > encounter this situation? (The problem that you noted will occur > only for some media types; for others, "doGetNextFrame()" won't end > up getting called until the downstream recipient is actually ready to > get/handle new data.) It's a TS file. I'm sure you know better than me what sources are used by MediaServer for those. :) -- ?smund Grammeltvedt Snap TV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070105/72a4343a/attachment.bin From xcsmith at rockwellcollins.com Fri Jan 5 13:00:11 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Fri, 5 Jan 2007 15:00:11 -0600 Subject: [Live-devel] DynamicRTSPServer is not part of the LIVE library. Message-ID: I am working on an RTSP server which is inherited from DynamicRTSPServer (I had to change some things from private to protected). I ran into trouble linking my new class, and eventually discovered this was because DynamicRTSPServer.o is not in put into the live555 library when the library is built. Because DynamicRTSPServer is a class which is used much like RTSPServer in the mediaServer application, should DynamicRTSPServer.cpp / .hh go into the liveMedia and liveMedia/include folders and be built as part of the library? It seems to me that programs besides mediaServer might want create objects of the DynamicRTSPServer class. (Maybe I have no reason to inherit from it other than to show that my server is the same kind of server, and I should just write a stand alone.) Thanks for considering! Xochitl From TAYK0004 at ntu.edu.sg Fri Jan 5 15:06:36 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Sat, 6 Jan 2007 07:06:36 +0800 Subject: [Live-devel] getNextFrame Variables Message-ID: <438567054C073949AEBE5A28B83E7DE133FCA0@MAIL21.student.main.ntu.edu.sg> Hi guys, once again, great thanks to Ross for helping me clear many doubts in RTP. I have some uncertainties regarding DoGetNextFrame() Variables, which I hope anyone can assist. fTO : a RTP buffer, we are to copy video data into this buffer for framing eg. g_video_enc_rbuf->read(fTo, fMaxSize, 0); //the read function will copy the data to fTo memcpy(fTo,g_video_enc_rbuf,fFrameSize); // using memcpy function fPresentationTime: give time information to each frame eg. gettimeofday(&fPresentationTime, NULL); //a simpler form // a more detailed form if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0) { // This is the first frame, so use the current time: gettimeofday(&fPresentationTime, NULL); } else { // Increment by the play time of the previous frame (50ms), my encoder's frame rate is 20fps unsigned uSeconds = fPresentationTime.tv_usec + 50000; fPresentationTime.tv_sec += uSeconds/1000000; fPresentationTime.tv_usec = uSeconds%1000000; fMaxSize: Setting the maximum size of a rtp frame. Not necessary if you have already set your encoder to limit the size of a frame. For truncation purpose. eg. Can anyone provide some examples on setting fMaxSize? fFrameSize: Determine the RTP frame size eg. Can anyone provide some examples on setting fFrameSize? That's all I can think of for the variables for DoGetNextFrame. If I miss out anything, pls kindly add in. I compiling all the emails which contains information on these information so that anyone in future can refer to them instead of asking again in the mailing list. I can share a file which I have done detailing on NAL units so that people doing h.264 framer can have a better understanding when writing the code. Many thanks and regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070105/60c29b71/attachment.html From finlayson at live555.com Fri Jan 5 15:26:37 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Jan 2007 15:26:37 -0800 Subject: [Live-devel] DynamicRTSPServer is not part of the LIVE library. In-Reply-To: References: Message-ID: >Because DynamicRTSPServer is a class which is used much like >RTSPServer in the mediaServer application, should DynamicRTSPServer.cpp / >.hh go into the liveMedia and liveMedia/include folders and be built as >part of the library? The "DynamicRTSPServer" class was written specifically for use by the "LIVE555 Media Server" application. Because this is application-specific rather than generic functionality, it probably won't get added to the "liveMedia" library. However you are, of course, free to use it within your own application(s). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jan 5 15:28:08 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Jan 2007 15:28:08 -0800 Subject: [Live-devel] getNextFrame Variables In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCA0@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCA0@MAIL21.student.main.ntu.edu.sg> Message-ID: >fTO : a RTP buffer, we are to copy video data into this buffer for framing > >eg. g_video_enc_rbuf->read(fTo, fMaxSize, 0); //the read function >will copy the data to fTo > > memcpy(fTo,g_video_enc_rbuf,fFrameSize); // using memcpy function OK, but don't forget to assign "fFrameSize" first. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070105/f25c3426/attachment.html From victor_l2000 at hotmail.com Fri Jan 5 22:10:37 2007 From: victor_l2000 at hotmail.com (Victor Lee) Date: Fri, 05 Jan 2007 22:10:37 -0800 Subject: [Live-devel] how to set RTSP Client use TCP instead of UDP Message-ID: Hi All, I have a RTSP Server built with LiveMedia on PC, and now I am trying to use TCP to transport streams between RTSP Server and RTSP Client. From what i read about LiveMedia, it support both UDP and TCP. I used the 2 examples provided by LiveMedia, testOnDemandRTSPServer and openRTSP, with the -t option. The the client sent the cmd with: Transport: RTP/AVP/TCP;unicast;interleaved=0-1 While the stream is transferring from the Server to the Client, using netstat, I still find the RTSP Server and Client each has 2 UDP connections, which is the same case as when i do not use the -t option. The 2 UDP connections use 2 continuous port numbers. The even one for RTP data and the odd one for RTCP control information (Please correct me if i am wrong). Could any one answer me the following questions or tell me where i can find further info? 1. Does the mean that actually UDP is still used? How can i be sure that TCP is used? 2. When not using -t option, UDP is used, there is still another TCP connection, established with the server's port 8554. I have no idea about what this one is for. 3. what is the correct way to set the RTSP Client using TCP instead of UDP? Thanks in advance! Victor _________________________________________________________________ Type your favorite song.  Get a customized station.  Try MSN Radio powered by Pandora. http://radio.msn.com/?icid=T002MSN03A07001 From rajeshkumar.r at imimobile.com Fri Jan 5 22:21:04 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Sat, 6 Jan 2007 11:51:04 +0530 Subject: [Live-devel] DynamicRTSPServer is not part of the LIVE library. References: Message-ID: <01a401c7315a$d839e900$6902000a@imidomain.com> Hi Ross RTSPCLIENT::playMediaSession is responsible for starting the play operation. which part of live media is listening on the port where the streaming data is coming. my aim is to store the recvd audio and video in different buffer. can i play the streaming content getting on some audio port and video port using any media player. I am waiting for ur response. with Regards Rajesh From finlayson at live555.com Fri Jan 5 22:32:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Jan 2007 22:32:20 -0800 Subject: [Live-devel] how to set RTSP Client use TCP instead of UDP In-Reply-To: References: Message-ID: RTSP uses a control channel - which is always TCP, using a standard RTSP TCP port number (554 or 8554). Then, for each data stream (audio and/or video), it uses a data channel (for sending RTP/RTCP packets from the server to the client). Normally (i.e., if you don't use the "-t" option to "openRTSP"), each data channel uses UDP. However, if the client requests it (using the "streamUsingTCP" parameter to "RTSPClient:: setupMediaSubsession()", or, using "openRTSP", the "-t" option), then each data channel will also use TCP - using *the same* TCP connection as the control channel. (The RTP/RTCP data is interleaved over the control channel TCP connection - from the server back to the client.) It turns out that in our implementation, we create UDP sockets even when the client requests streaming over TCP. However, in this case those UDP sockets don't get used; all data is sent over the TCP connection instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jan 5 22:38:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 5 Jan 2007 22:38:01 -0800 Subject: [Live-devel] DynamicRTSPServer is not part of the LIVE library. In-Reply-To: <01a401c7315a$d839e900$6902000a@imidomain.com> References: <01a401c7315a$d839e900$6902000a@imidomain.com> Message-ID: >Hi Ross >RTSPCLIENT::playMediaSession is responsible for starting the play operation. >which part of live media is listening on the port where the streaming data >is coming. >my aim is to store the recvd audio and video in different buffer. See the code for "openRTSP" - in particular "testProgs/playCommon.cpp". Note the use of a "FileSink" class on line 693. You can use your own 'sink' class instead to store the incoming data. > >can i play the streaming content getting on some audio port and video port >using any media player. Yes. See, for example, the code for the Open Source VLC media player - in particular, the file "live555.com". This media player uses our RTSP client code to receive and play incoming RTP data. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jackymaillist at gmail.com Sun Jan 7 23:01:27 2007 From: jackymaillist at gmail.com (Jacky Cheung) Date: Mon, 08 Jan 2007 15:01:27 +0800 Subject: [Live-devel] FramedSource Message-ID: <45A1EC47.6030205@gmail.com> Hi Ross, I am implementing a new class inherited from FramedSource. And it will be used along with MPEG4VideoStreamDiscreteFramer Assume I can receive the MPEG4 frame-by-frame. I am thinking what should I do in the NewFramedSource::doGetNextFrame, if the current frame size is bigger than the fMaxSize? Thanks a lot Regards, Jacky Cheung From rafi at evtt.com Mon Jan 8 05:00:34 2007 From: rafi at evtt.com (Rafael Buchbinder) Date: Mon, 8 Jan 2007 15:00:34 +0200 Subject: [Live-devel] streaming with Real Player/QuickTime player Message-ID: Hi, live555 mailing list! Is it possible to stream to Real Player from OnDemandRTSPServer? More precisely: is it possible to stream H.263+ using Real Player. I have OnDemandRTSPServer up and running. VLC opens the stream well. One of our functional requirements is the ability to open the stream using Real Player and/or QuickTime player. However, none of those proprietary players opens the stream. Real Player seems to simply drop the received frames. Can anybody confirm ability/disability to do it? Thanks Rafael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070108/4a6b920b/attachment.html From zjuchenjun at hotmail.com Mon Jan 8 06:22:49 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Mon, 8 Jan 2007 22:22:49 +0800 Subject: [Live-devel] getNextFrame Variables Message-ID: hi Zkunhui? Thanks for your works and your reply for my questions.I want to get the file you said about NAL units. Again, I want to ask a question which i refered in previous question: If the size of NAL unit is bigger than fMaxsize(should I set fMaxsize myself?), then fFrameSize=fMaxsize,fNumTruncatedBytes = fFrameSize - fMaxSize ,as the code below: ///////////////////////////////////////////////// if (fFrameSize > fMaxSize) { fNumTruncatedBytes = fFrameSize - fMaxSize; fFrameSize = fMaxSize; } memcpy(fTo,Encode_data,fFrameSize); //Encode_data is defined in another thread ////////////////////////////////////////////////// but how to deal with the fNumTruncatedBytes data? in H264VideoRTPSink.cpp , i see the clue below, should i do it like this in deliverFrame()? // We have NAL unit data in the buffer. There are three cases to consider: // 1. There is a new NAL unit in the buffer, and it's small enough to deliver // to the RTP sink (as is). // 2. There is a new NAL unit in the buffer, but it's too large to deliver to // the RTP sink in its entirety. Deliver the first fragment of this data, // as a FU-A packet, with one extra preceding header byte. // 3. There is a NAL unit in the buffer, and we've already delivered some // fragment(s) of this. Deliver the next fragment of this data, // as a FU-A packet, with two extra preceding header bytes. Thanks in advance. I am looking forward helps from anyone! Date: Sat, 6 Jan 2007 07:06:36 +0800From: TAYK0004 at ntu.edu.sgTo: live-devel at ns.live555.comSubject: [Live-devel] getNextFrame Variables Hi guys, once again, great thanks to Ross for helping me clear many doubts in RTP. I have some uncertainties regarding DoGetNextFrame() Variables, which I hope anyone can assist. fTO : a RTP buffer, we are to copy video data into this buffer for framing eg. g_video_enc_rbuf->read(fTo, fMaxSize, 0); //the read function will copy the data to fTo memcpy(fTo,g_video_enc_rbuf,fFrameSize); // using memcpy function fPresentationTime: give time information to each frame eg. gettimeofday(&fPresentationTime, NULL); //a simpler form // a more detailed form if (fPresentationTime.tv_sec == 0 && fPresentationTime.tv_usec == 0) { // This is the first frame, so use the current time: gettimeofday(&fPresentationTime, NULL); } else { // Increment by the play time of the previous frame (50ms), my encoder?s frame rate is 20fps unsigned uSeconds = fPresentationTime.tv_usec + 50000; fPresentationTime.tv_sec += uSeconds/1000000; fPresentationTime.tv_usec = uSeconds%1000000; fMaxSize: Setting the maximum size of a rtp frame. Not necessary if you have already set your encoder to limit the size of a frame. For truncation purpose. eg. Can anyone provide some examples on setting fMaxSize? fFrameSize: Determine the RTP frame size eg. Can anyone provide some examples on setting fFrameSize? That?s all I can think of for the variables for DoGetNextFrame. If I miss out anything, pls kindly add in. I compiling all the emails which contains information on these information so that anyone in future can refer to them instead of asking again in the mailing list. I can share a file which I have done detailing on NAL units so that people doing h.264 framer can have a better understanding when writing the code. Many thanks and regards. Zkunhui _________________________________________________________________ ?? Windows Live Messenger ?????? http://get.live.com/messenger/overview -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070108/4b424a3e/attachment.html From xcsmith at rockwellcollins.com Mon Jan 8 07:59:57 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 8 Jan 2007 09:59:57 -0600 Subject: [Live-devel] ForceMulticastOnUnspecified Message-ID: Ross & LIVE, How can I modify the RTSPServer class and related classes so that testOnDemandRTSPServer can accept transport parameters which force the stream to be multicast? RTSPClient --> Transport: RTP/AVP;multicast=224.0.1.2;client_port=12008-12009 testOnDemandServer response --> Transport: RTP/AVP;unicast;destination=127.0.0.1;client_port=12008-12009;server_port=6970-6971 Do I need to also add TTL to my Transport parameters? Thanks! Xochitl From drobbins at fsmlabs.com Mon Jan 8 09:08:41 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Mon, 08 Jan 2007 10:08:41 -0700 Subject: [Live-devel] Initial support for server 'trick play' operations on Transport Stream files In-Reply-To: References: Message-ID: <45A27A99.1030708@fsmlabs.com> Ross Finlayson wrote: > The latest version (2006.12.31) of the "LIVE555 Streaming Media" > software includes initial support for server 'trick play' operations > (seeking, fast forward, reverse play) on MPEG-2 Transport Stream > files. The actual RTSP server code itself does not yet support > Transport Stream 'trick play' operations; however, that will be added > probably for the next release - perhaps within a day or so. > Hi Ross, Do you have a realistic estimate for when MPEG-2 trick mode support will be completed, and do you expect it to be included in next release of the libraries? -Daniel From TAYK0004 at ntu.edu.sg Mon Jan 8 09:11:59 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Tue, 9 Jan 2007 01:11:59 +0800 Subject: [Live-devel] Playing back H.264 stream using PDA Message-ID: <438567054C073949AEBE5A28B83E7DE133FCA4@MAIL21.student.main.ntu.edu.sg> Hi guys, I got some questions regarding playback of H.264 streaming. Is there any software (free or purchase) that can playback H.264 streamed using Livemedia. I looking at Coreplayer 1.0. Found out it can play H.264 raw format and support streaming. However email, regarding whether it can support livemedia RTP H.264 streaming, to the staff was unreplied. Anyone can advise. I using DELL Axim (Windows Mobile 5) Regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070108/0ff5ad50/attachment-0001.html From finlayson at live555.com Mon Jan 8 10:16:31 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Jan 2007 10:16:31 -0800 Subject: [Live-devel] ForceMulticastOnUnspecified In-Reply-To: References: Message-ID: >How can I modify the RTSPServer class and related classes so that >testOnDemandRTSPServer can accept transport parameters which force the >stream to be multicast? You can't do this; it's the server that decides whether or not a stream is multicast or unicast. It specifies this in its response to the initial RTSP "DESCRIBE" command (and it's not something that the client can change in its subsequent "SETUP" command). If you want the client to chose between unicast and multicast, then you could support this by adding two different "ServerMediaSession" objects to your server: One that has "PassiveServerMediaSubsession" object(s) for subsession(s), and one that has "OnDemandServerMediaSubsession" (subclass) object(s) for subsession(s). These two "ServerMediaSession" objects would have different names, and each client could choose either multicast or unicast, depending on the name (which would be used at the end of the "rtsp://" URL.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 8 10:39:37 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Jan 2007 10:39:37 -0800 Subject: [Live-devel] getNextFrame Variables In-Reply-To: References: Message-ID: >hi Zkunhui?C > Thanks for your works and your reply for my >questions.I want to get the file you said about >NAL units. > Again, I want to ask a question which i >refered in previous question: If the size of NAL >unit is bigger than fMaxsize(should I set >fMaxsize myself?), > then fFrameSize=fMaxsize,fNumTruncatedBytes >= fFrameSize - fMaxSize ,as the code below: > >///////////////////////////////////////////////// > if (fFrameSize > fMaxSize) { > fNumTruncatedBytes = fFrameSize - fMaxSize; > fFrameSize = fMaxSize; > } > > memcpy(fTo,Encode_data,fFrameSize); >//Encode_data is defined in another thread >////////////////////////////////////////////////// > >but how to deal with the fNumTruncatedBytes data? Are you asking: How to *prevent* ending up with truncated bytes (i.e., discarded bytes at the end)? The only way to prevent this is to make sure that your downstream object(s) have enough buffer space when they are created. If your downstream object is a "FileSink" - i.e., you're saving data into a file - then use the "bufferSize" parameter to "FileSink::createNew()". If your downstream object is a "RTPSink" (subclass) - i.e., you're sending RTP packets - then assign "OutPacketBuffer::maxSize" to a new value, before creating the RTPSink. (You should see a warning message about this.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070108/3616eb1b/attachment.html From finlayson at live555.com Mon Jan 8 10:50:52 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Jan 2007 10:50:52 -0800 Subject: [Live-devel] Playing back H.264 stream using PDA In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCA4@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCA4@MAIL21.student.main.ntu.edu.sg> Message-ID: >Is there any software (free or purchase) that can playback H.264 >streamed using Livemedia. Any standards-compliant RTSP/RTP media player client (that supports H.264 decoding) should work. In particular VLC , and Apple's QuickTime Player. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070108/1f78bf1e/attachment.html From finlayson at live555.com Mon Jan 8 11:01:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Jan 2007 11:01:01 -0800 Subject: [Live-devel] streaming with Real Player/QuickTime player In-Reply-To: References: Message-ID: >Is it possible to stream to Real Player from OnDemandRTSPServer? This depends on the codec that your streaming. When RealNetworks came out with "Real Player version 10" a couple of years ago, its support for playing standard RTSP/RTP streams was badly broken. I found that it could now play only a few codecs; I'm not sure if H.263+ was one of them. For this reason, I no longer consider "Real Player" a credible client. QuickTime Player - on the other hand - is a lot more standards compliant. I have found that it plays H.263+ video streams OK, so I'm surprised that you have had problems with this. (Of course, to stream H.263 video, you will have needed to modify the existing "testOnDemandRTSPServer" code to use a "H263plusVideoFileServerMediaSubsession" (and to read from a H.263+ Elementary Steam video file).) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070108/d4834db5/attachment.html From xcsmith at rockwellcollins.com Mon Jan 8 12:45:40 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Mon, 8 Jan 2007 14:45:40 -0600 Subject: [Live-devel] ForceMulticastOnUnspecified Message-ID: It is the server that decides whether or not a stream is multicast or unicast. It specifies this in its response to the initial RTSP "DESCRIBE" command (and it's not something that the client can change in its subsequent "SETUP" command). Ross, Thank you for your reply. The SDP that I receive from testOnDemandRTSPServer has the following lines: m=video 0 RTP/AVP 33 c=IN IP4 0.0.0.0 In the SDP I don't see that the server specifies unicast. The sessions are set up ahead of time as unicast though, i see your point. I thought I could use multicast because of the parameter forceMulticastOnUnspecified in the function RTSPClient::setupMediaSubsession(). What is the meaning of this parameter then if I cannot force multicast on a session who's SDP has "0" in the address / port information? I want in the end to use mediaServer and have the sessions created dynamically as multicast sessions if the client transport string says multicast. I am confused about how to do this using PassiveServerMediaSubsession. In the examples of using PassiveServerMediaSubsession, the RTPSink is created ahead of time and sink->startPlaying() is called before the event loop is entered. Is it reasonable to use PassiveServerMediaSubsession with mediaServer? Will I have to modify anything so that handleCmd_PLAY() will set the stream playing? What I really need is an "on demand" multicast session. I implemented a class inherited from FileServerMediaSubsession with the 2 pure virtual functions done using the setup in testMPEG2TransportStreamer: FramedSource* mySub::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 5000; // kbps, estimate // Create the video source: unsigned const inputDataChunkSize = TRANSPORT_PACKETS_PER_NETWORK_PACKET*TRANSPORT_PACKET_SIZE; ByteStreamFileSource* fileSource = ByteStreamFileSource::createNew(envir(), fFileName, inputDataChunkSize); if (fileSource == NULL) return NULL; MPEG1or2Demux* demux = MPEG1or2Demux::createNew(mEnv, fileSource); MPEG1or2DemuxedElementaryStream* pesSource = demux->newRawPESStream(); FramedSource* tsFrames = MPEG2TransportStreamFromPESSource::createNew(mEnv, pesSource); // Create a framer for the Transport Stream: return MPEG2TransportStreamFramer::createNew(envir(), tsFrames); } RTPSink* mySub::createNewRTPSink(Groupsock* rtpGroupsock, unsigned char /*rtpPayloadTypeIfDynamic*/, FramedSource* /*inputSource*/) { return SimpleRTPSink::createNew(envir(), rtpGroupsock, rtpPayloadType, 90000, "video", "mp2t", 1, True, False /*no 'M' bit*/); } I have mediaServer DynamicRTSPServer create an instance of this class whenever there is a file with ".mpg" extension, and so far I think it works. Now I want to make it so the reformatted stream can be multicast. There aren't any functions similar to createNewRTPSink() and createNewStreamSource() in PassiveServerMediaSubsession, so I would have to do this setup somewhere else, and I don't know where to put the setup if I use mediaServer. Do you have advice on this? (And I think there was a mistake in the client transport line i posted earlier. I think it should be: " RTP/AVP;multicast;destination=224.0.1.2;client_port=12008-12009".) Thanks very much! Xochitl From finlayson at live555.com Mon Jan 8 14:28:35 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 8 Jan 2007 14:28:35 -0800 Subject: [Live-devel] ForceMulticastOnUnspecified In-Reply-To: References: Message-ID: >It is the server that decides whether or not a >stream is multicast or unicast. It specifies this in its response to >the initial RTSP "DESCRIBE" command (and it's not something that the >client can change in its subsequent "SETUP" command). > >Ross, > >Thank you for your reply. >The SDP that I receive from testOnDemandRTSPServer has the following lines: > >m=video 0 RTP/AVP 33 >c=IN IP4 0.0.0.0 > >In the SDP I don't see that the server specifies unicast. By convention, the "0.0.0.0" destination address (and the "0" port number) specifies that the stream will be unicast. The RTSP specification does, however, allow for this to be used even for a multicast stream (in which case the address and port could get assigned by the client during "SETUP"). This feature is not well supported, however. So far I've seen it only on some Axis servers (network cameras), but even they don't support this feature correctly (they assign the multicast address themselves during "SETUP", rather than letting the client assign the address). The optional "forceMulticastOnUnspecified" parameter to "RTSPClient::setupMediaSubsession()" was added as a hack just over a year ago, in response to someone who wanted to accommodate those weird servers. Because this feature is little understood and little implemented, I'm not going to try to support it at all in our RTSP *server* implementation. Instead, the server can specify alternative unicast and multicast "ServerMediaSession" objects, as I noted in my earlier message. >I want in the end to use mediaServer and have the sessions created >dynamically as multicast sessions if the client transport string says >multicast. I am confused about how to do this using >PassiveServerMediaSubsession. In the examples of using >PassiveServerMediaSubsession, the RTPSink is created ahead of time and >sink->startPlaying() is called before the event loop is entered. Is it >reasonable to use PassiveServerMediaSubsession with mediaServer? Will I >have to modify anything so that handleCmd_PLAY() will set the stream >playing? What I really need is an "on demand" multicast session. An 'on demand multicast session' doesn't really make a whole lot of sense. Sure, you could (somehow) arrange to start streaming multicast only after the first client arrives, but thereafter every other client will end up getting the same multicast stream, so what's the point? You might as well just stream multicast continuously - which is what "PassiveServerMediaSubsession" does. (Sending a multicast stream that noone is listening to is OK; in modern multicast routing protocols, such traffic will never get past the first hop.) So, just use separate "ServerMediaSession"s for unicast and multicast, as I noted earlier. That's the simplest and most standard solution. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From amit.awasthi at iptvlabs.biz Tue Jan 9 04:14:08 2007 From: amit.awasthi at iptvlabs.biz (Amit Alok Awasthi) Date: Tue, 9 Jan 2007 17:44:08 +0530 Subject: [Live-devel] Initial support for server 'trick play' operations on Transport Stream files In-Reply-To: Message-ID: <200701091214.l09CE5I5038205@ns.live555.com> Dear Mr. Finlayson, Thanks for the information on the latest version (2006.12.31). However, I also wish to know the following: 1. "RTSP server code itself does not yet support Transport Stream "trick play" operations". Has this change now been introduced in the latest Live's release? 2. I had been using 2006.12.08, downloaded from Live555's website to stream a MPEG2-TS. I set Live555 as the server on SuSE Linux 10.0 and VLC 0.8.6 as a client on Windows. However, I had the following observations: >>TS video comes after a 'long wait' from the start while audio goes well in track right from the beginning. Whenever video starts, it is however in sync with the audio. The TS is being streamed though it is not being paused. 'Play fast' functionality is not working thoroughly since after moving fast for a while, the video stops. 3. With the latest binary available (2006.12.31 with Live555's Trick Play support) and the same set up, I am getting the same set of observations as above. (I checked this using the two new utilities - MPEG2TransportStreamIndexer and testMPEG2TransportStreamTrickPlay - present in the "testProgs" directory using the instructions provided in the forum but didn't manage to get 'trick play' working) Please help us know the reason for the points mentioned above and how to rectify them. Happy New Year and Warm Regards, Amit Alok Awasthi iptv Business Analyst iptvLabs (India) Pvt. Ltd. Email: amit.awasthi at iptvlabs.biz Phone: +91-120-4352189 Cell: +09811177092 Company Site: www.iptvlabs.biz -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson Sent: Monday, January 01, 2007 7:02 AM To: live-devel at ns.live555.com Subject: [Live-devel] Initial support for server 'trick play' operations on Transport Stream files The latest version (2006.12.31) of the "LIVE555 Streaming Media" software includes initial support for server 'trick play' operations (seeking, fast forward, reverse play) on MPEG-2 Transport Stream files. The actual RTSP server code itself does not yet support Transport Stream 'trick play' operations; however, that will be added probably for the next release - perhaps within a day or so. To support 'trick play' operations on a Transport Stream file, the server must have a corresponding "index file". This index file describes the position - within the Transport Stream file - of video I-frames (i.e., key frames); these frames are used to produce a fast forward or reverse play stream. Each Transport Stream file that you wish to stream must have a corresponding "index file" (if it doesn't, the the server will still be able to stream the file, but without 'trick play' operations). The index files use the file name suffix ".tsx"; for example, if your Transport Stream file is named "foo.ts", then the corresponding index file will be named "foo.tsx". The current release of the "LIVE 555 Streaming Media" software includes a utility - called "MPEG2TransportStreamIndexer", in the "testProgs" directory - that you can use to generate index files for your Transport Stream files. To generate each index file, run MPEG2TransportStreamIndexer Be warned that this program is currently rather slow, so I suggest running it on the fastest computer that you have. Once you have generated your index files, you can try running a demo application called "testMPEG2TransportStreamTrickPlay" (also in the "testProgs" directory) to simulate the effect of 'trick play' operations on Transport Stream files. To run it: testMPEG2TransportStreamTrickPlay where is the original Transport Stream file name (which must end with ".ts"). There must also be a corresponding index file for this file. is the starting play time in seconds (use 0 to play from the start) is a non-zero integer, representing the playing speed (use a negative number for reverse play) Examples (assume that your original Transport Stream file is named "foo.ts", and that you have already generated an index file, named "too.tsx"): testMPEG2TransportStreamTrickPlay foo.ts 0 8 foo8.ts The output file "foo8.ts" is the original stream, sped up 8x testMPEG2TransportStreamTrickPlay foo.ts 30 -1 foo-1.ts The output file "foo-1.ts" is the original stream, played backwards (at 1x speed), starting from the 30 second point. testMPEG2TransportStreamTrickPlay foo.ts 30 -5 foo-5.ts The output file "foo-5.ts" is the original stream, played backwards (at 5x speed), starting from the 30 second point. If you have any problems with these programs, please let us know, including the URL of the original Transport Stream file, so we can take a look at it. A reminder once again that this 'trick play' functionality will be added to the RTSP server code shortly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From luk666 at wp.pl Tue Jan 9 05:39:08 2007 From: luk666 at wp.pl (Paul) Date: Tue, 09 Jan 2007 14:39:08 +0100 Subject: [Live-devel] streaming .mp4 Message-ID: <45a39afcb190b@wp.pl> Hi All, I am a newbie in multimedia programming. Is it possible to stream .mp4 file using live554 library? If not do you know some other c++ libraries which provide such functionality Thanks for any hint. Paul ---------------------------------------------------- Zuzia ma wielki k?opot - jak ubra? si? na bal? Zosta? stylist? Zuzi i wyszykuj j? na bal. http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd54.html&sid=986 From shaswata at alumnux.com Tue Jan 9 06:55:40 2007 From: shaswata at alumnux.com (Shaswata Jash) Date: Tue, 9 Jan 2007 20:25:40 +0530 Subject: [Live-devel] streaming .mp4 References: <45a39afcb190b@wp.pl> Message-ID: <005901c733fe$3ac30e80$2e0aa8c0@NITU> Hi Paul, Live555 yet doesn't support streaming from ISO base media file format (like .mp4 or .3gp). Apples's Darwin Streaming server (DSS) does so. DSS's source code is open too. With regards, Shaswata Jash ----- Original Message ----- From: "Paul" To: "LIVE555 Streaming Media - development & use" Sent: Tuesday, January 09, 2007 7:09 PM Subject: [Live-devel] streaming .mp4 > Hi All, > I am a newbie in multimedia programming. Is it possible to stream .mp4 file using live554 library? If not do you know some other c++ libraries which provide such functionality > Thanks for any hint. > Paul > > > ---------------------------------------------------- > Zuzia ma wielki k?opot - jak ubra? si? na bal? > Zosta? stylist? Zuzi i wyszykuj j? na bal. > http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd54.html&sid=986 > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From mrnikhilagrawal at gmail.com Tue Jan 9 09:49:05 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Tue, 9 Jan 2007 23:19:05 +0530 Subject: [Live-devel] streaming .mp4 In-Reply-To: <005901c733fe$3ac30e80$2e0aa8c0@NITU> References: <45a39afcb190b@wp.pl> <005901c733fe$3ac30e80$2e0aa8c0@NITU> Message-ID: <733cde3e0701090949l71221925vc79073e573ab84ce@mail.gmail.com> Hi, But the problem with Darwin Server is that it works only on TCP unlike Live555 Streaming Server. Thats the biggest drawback of using and i didn't find any support for UDP on Darwin Server. Regards, Nikhil Agrawal On 1/9/07, Shaswata Jash wrote: > > Hi Paul, > > Live555 yet doesn't support streaming from ISO base media file format > (like > .mp4 or .3gp). > Apples's Darwin Streaming server (DSS) does so. DSS's source code is open > too. > > With regards, > Shaswata Jash > > ----- Original Message ----- > From: "Paul" > To: "LIVE555 Streaming Media - development & use" > > Sent: Tuesday, January 09, 2007 7:09 PM > Subject: [Live-devel] streaming .mp4 > > > > Hi All, > > I am a newbie in multimedia programming. Is it possible to stream .mp4 > file using live554 library? If not do you know some other c++ libraries > which provide such functionality > > Thanks for any hint. > > Paul > > > > > > ---------------------------------------------------- > > Zuzia ma wielki k?opot - jak ubra? si? na bal? > > Zosta? stylist? Zuzi i wyszykuj j? na bal. > > > > http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd54.html&sid=986 > > > > > > _______________________________________________ > > live-devel mailing list > > live-devel at lists.live555.com > > http://lists.live555.com/mailman/listinfo/live-devel > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070109/d2714220/attachment.html From rahul.ray at gmail.com Tue Jan 9 11:08:33 2007 From: rahul.ray at gmail.com (Rahul Ray) Date: Tue, 9 Jan 2007 11:08:33 -0800 Subject: [Live-devel] video over IP Message-ID: Hi, I would like to stream real time MPEG-4 over IP so that it can be played using a quicktime by accessing the IP. Could you please tell me how to do this or is this at all possible using LIVE555 ? Thanks, Rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070109/2711feb8/attachment.html From finlayson at live555.com Tue Jan 9 12:09:09 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Jan 2007 12:09:09 -0800 Subject: [Live-devel] video over IP In-Reply-To: References: Message-ID: > I would like to stream real time MPEG-4 over IP so that it can >be played using a quicktime by accessing the IP. Could you please >tell me how to do this or is this at all possible using LIVE555 ? Of course it's possible. Examine the demo applications, and read the FAQ - in particular http://www.live555.com/liveMedia/faq.html#liveInput and http://www.live555.com/liveMedia/faq.html#liveInput-unicast -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070109/69d65d77/attachment.html From vd_mail_id at yahoo.com Tue Jan 9 12:13:53 2007 From: vd_mail_id at yahoo.com (vd mail_id) Date: Tue, 9 Jan 2007 12:13:53 -0800 (PST) Subject: [Live-devel] UsageEnvironment & TaskScheduler In-Reply-To: Message-ID: <549581.49721.qm@web59010.mail.re1.yahoo.com> I know I will get scolded for this from Ross, but I really need some quick pointers about what UsageEnvironment and TaskScheduler are doing and how? I would be glad if anyone can forward me any past email from mail list which might shed some light on these two classes. TIA --Vikram __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070109/4d49e75f/attachment.html From finlayson at live555.com Tue Jan 9 14:01:10 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 9 Jan 2007 14:01:10 -0800 Subject: [Live-devel] Initial support for server 'trick play' operations on Transport Stream files In-Reply-To: <200701091214.l09CE5I5038205@ns.live555.com> References: <200701091214.l09CE5I5038205@ns.live555.com> Message-ID: >1. "RTSP server code itself does not yet support Transport Stream "trick >play" operations". Has this change now been introduced in the latest Live's >release? Yes, as of the latest release (2007.01.09). I'll be documenting and saying more about this shortly. (In the meantime, I suggest reviewing my previous message about this - where I described the new 'Transport Stream index files'.) >2. I had been using 2006.12.08, downloaded from Live555's website to stream >a MPEG2-TS. I set Live555 as the server on SuSE Linux 10.0 and VLC 0.8.6 as >a client on Windows. However, I had the following observations: > >>>TS video comes after a 'long wait' from the start while audio goes well in >track right from the beginning. This may be a VLC issue - e.g., perhaps it takes a while to recognize the video stream... >The TS is being streamed though it is not being paused. >'Play fast' functionality is not working thoroughly since after moving fast >for a while, the video stops. Trick play functions (like 'fast forward') will work only with the latest release of the software, and only if you have an index file for each Transport File that you're streaming. (Also, the VLC client currently doesn't appear to perform the 'trick play' operations properly; the VLC people will need to fix this. However, other clients - such as the Amino set-top box - work OK.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From drobbins at fsmlabs.com Tue Jan 9 14:31:09 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Tue, 09 Jan 2007 15:31:09 -0700 Subject: [Live-devel] Initial support for server 'trick play' operations on Transport Stream files In-Reply-To: References: <200701091214.l09CE5I5038205@ns.live555.com> Message-ID: <45A417AD.3030503@fsmlabs.com> Ross Finlayson wrote: > Trick play functions (like 'fast forward') will work only with the > latest release of the software, and only if you have an index file > for each Transport File that you're streaming. (Also, the VLC client > currently doesn't appear to perform the 'trick play' operations > properly; the VLC people will need to fix this. However, other > clients - such as the Amino set-top box - work OK.) > Do you know of any Windows or Linux clients that properly support fast forward and rewind, that you would recommend for using to test the new trick play functionality? -Daniel From shaswata at alumnux.com Tue Jan 9 22:27:15 2007 From: shaswata at alumnux.com (Shaswata Jash) Date: Wed, 10 Jan 2007 11:57:15 +0530 Subject: [Live-devel] streaming .mp4 References: <45a39afcb190b@wp.pl> <005901c733fe$3ac30e80$2e0aa8c0@NITU> <733cde3e0701090949l71221925vc79073e573ab84ce@mail.gmail.com> Message-ID: <001601c73480$5f32a000$2e0aa8c0@NITU> Hi Nikhil, I'm extremely surprised from your observation. I can't really agree with your point of view - we have checked through ethereal that DSS streams over UDP. Please double check that your client is not sending 'channel' information instead of port as it should have been for UDP. I think, somehow DSS is detecting that the client is requesting streaming over TCP. With regards, Shaswata Jash ----- Original Message ----- From: Nikhil Agrawal To: LIVE555 Streaming Media - development & use Sent: Tuesday, January 09, 2007 11:19 PM Subject: Re: [Live-devel] streaming .mp4 Hi, But the problem with Darwin Server is that it works only on TCP unlike Live555 Streaming Server. Thats the biggest drawback of using and i didn't find any support for UDP on Darwin Server. Regards, Nikhil Agrawal On 1/9/07, Shaswata Jash wrote: Hi Paul, Live555 yet doesn't support streaming from ISO base media file format (like .mp4 or .3gp). Apples's Darwin Streaming server (DSS) does so. DSS's source code is open too. With regards, Shaswata Jash ----- Original Message ----- From: "Paul" < luk666 at wp.pl> To: "LIVE555 Streaming Media - development & use" Sent: Tuesday, January 09, 2007 7:09 PM Subject: [Live-devel] streaming .mp4 > Hi All, > I am a newbie in multimedia programming. Is it possible to stream .mp4 file using live554 library? If not do you know some other c++ libraries which provide such functionality > Thanks for any hint. > Paul > > > ---------------------------------------------------- > Zuzia ma wielki k?opot - jak ubra? si? na bal? > Zosta? stylist? Zuzi i wyszykuj j? na bal. > http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd54.html&sid=986 > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel ------------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070109/a8eff2b7/attachment-0001.html From mrnikhilagrawal at gmail.com Tue Jan 9 22:44:13 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Wed, 10 Jan 2007 12:14:13 +0530 Subject: [Live-devel] streaming .mp4 In-Reply-To: <001601c73480$5f32a000$2e0aa8c0@NITU> References: <45a39afcb190b@wp.pl> <005901c733fe$3ac30e80$2e0aa8c0@NITU> <733cde3e0701090949l71221925vc79073e573ab84ce@mail.gmail.com> <001601c73480$5f32a000$2e0aa8c0@NITU> Message-ID: <733cde3e0701092244n1f3b64e2n97fb695c39a5daf0@mail.gmail.com> Hi, I am also really surprised to know such facts from you . Thanks , I will check it from my side once again. But do tell me, do have the source code for DSS that is supporting UDP, because in the code I have , I saw support for TCP only , if you have any information (including code location site )regarding the same , please tell me. Thanks and Regards, Nikhil Agrawal On 1/10/07, Shaswata Jash wrote: > > Hi Nikhil, > > I'm extremely surprised from your observation. I can't really agree with > your point of view - we have checked through ethereal that DSS streams over > UDP. > Please double check that your client is not sending 'channel' information > instead of port as it should have been for UDP. I think, somehow DSS is > detecting that the client is requesting streaming over TCP. > > With regards, > Shaswata Jash > > > ----- Original Message ----- > *From:* Nikhil Agrawal > *To:* LIVE555 Streaming Media - development & use > *Sent:* Tuesday, January 09, 2007 11:19 PM > *Subject:* Re: [Live-devel] streaming .mp4 > > > Hi, > > But the problem with Darwin Server is that it works only on TCP unlike > Live555 Streaming Server. Thats the biggest drawback of using and i didn't > find any support for UDP on Darwin Server. > > Regards, > Nikhil Agrawal > > > On 1/9/07, Shaswata Jash wrote: > > > > Hi Paul, > > > > Live555 yet doesn't support streaming from ISO base media file format > > (like > > .mp4 or .3gp). > > Apples's Darwin Streaming server (DSS) does so. DSS's source code is > > open > > too. > > > > With regards, > > Shaswata Jash > > > > ----- Original Message ----- > > From: "Paul" < luk666 at wp.pl> > > To: "LIVE555 Streaming Media - development & use" > > > > Sent: Tuesday, January 09, 2007 7:09 PM > > Subject: [Live-devel] streaming .mp4 > > > > > > > Hi All, > > > I am a newbie in multimedia programming. Is it possible to stream .mp4 > > file using live554 library? If not do you know some other c++ libraries > > which provide such functionality > > > Thanks for any hint. > > > Paul > > > > > > > > > ---------------------------------------------------- > > > Zuzia ma wielki k?opot - jak ubra? si? na bal? > > > Zosta? stylist? Zuzi i wyszykuj j? na bal. > > > > > > > http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fd54.html&sid=986 > > > > > > > > > _______________________________________________ > > > live-devel mailing list > > > live-devel at lists.live555.com > > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > > > _______________________________________________ > > live-devel mailing list > > live-devel at lists.live555.com > > http://lists.live555.com/mailman/listinfo/live-devel > > > > ------------------------------ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070109/873f5bbb/attachment.html From mrnikhilagrawal at gmail.com Tue Jan 9 22:51:45 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Wed, 10 Jan 2007 12:21:45 +0530 Subject: [Live-devel] Regarding Windows Media Player as Client Message-ID: <733cde3e0701092251l3171c5m76a00cbfc6ae552e@mail.gmail.com> Hi, I want to use Windows Media Player as Client player with Live555 Media Streaming Server. Although everything is working fine with VLC , but according to my requirements at client end , I want WMP to be used as client. Also WMP doc says its sn RTSP complaint player so please tell me how can I use it at client player . Am i need to change in code related to negotiation part ( SET_UP , DESCRIBE , SDP lines..._). Regards, Nikhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070109/3422b340/attachment.html From finlayson at live555.com Wed Jan 10 00:31:54 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Jan 2007 00:31:54 -0800 Subject: [Live-devel] Regarding Windows Media Player as Client In-Reply-To: <733cde3e0701092251l3171c5m76a00cbfc6ae552e@mail.gmail.com> References: <733cde3e0701092251l3171c5m76a00cbfc6ae552e@mail.gmail.com> Message-ID: >I want to use Windows Media Player as Client player with Live555 >Media Streaming Server. Although everything is working fine with VLC >, but according to my requirements at client end , I want WMP to be >used as client. Also WMP doc says its sn RTSP complaint player They lie. The protocol that Windows Media Player speaks apparently does not conform to the RTSP standard. To my knowledge it cannot be used with our RTSP server. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jan 10 00:30:56 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Jan 2007 00:30:56 -0800 Subject: [Live-devel] streaming .mp4 In-Reply-To: <733cde3e0701092244n1f3b64e2n97fb695c39a5daf0@mail.gmail.com> References: <45a39afcb190b@wp.pl> <005901c733fe$3ac30e80$2e0aa8c0@NITU> <733cde3e0701090949l71221925vc79073e573ab84ce@mail.gmail.com> <001601c73480$5f32a000$2e0aa8c0@NITU> <733cde3e0701092244n1f3b64e2n97fb695c39a5daf0@mail.gmail.com> Message-ID: Of course the Darwin Streaming Server streams RTP over UDP (or over TCP, if the client requests it) - just as our RTSP server does. However, a discussion of the capabilities of the Darwin Streaming Server is off-topic for this mailing list. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From shaswata at alumnux.com Wed Jan 10 03:14:56 2007 From: shaswata at alumnux.com (Shaswata Jash) Date: Wed, 10 Jan 2007 16:44:56 +0530 Subject: [Live-devel] Regarding Windows Media Player as Client References: <733cde3e0701092251l3171c5m76a00cbfc6ae552e@mail.gmail.com> Message-ID: <002a01c734a8$8f436fe0$2e0aa8c0@NITU> Hi Nikhil, As Ross has already mentioned about inability of RTSP negotiation by WMP, but you can always write a DirectX Source filter which inturn understands RTSP. WMP would automatically select this source filter if it advertises itself for rtsp based url. With regards, Shaswata Jash ----- Original Message ----- From: Nikhil Agrawal To: live-devel at ns.live555.com Sent: Wednesday, January 10, 2007 12:21 PM Subject: [Live-devel] Regarding Windows Media Player as Client Hi, I want to use Windows Media Player as Client player with Live555 Media Streaming Server. Although everything is working fine with VLC , but according to my requirements at client end , I want WMP to be used as client. Also WMP doc says its sn RTSP complaint player so please tell me how can I use it at client player . Am i need to change in code related to negotiation part ( SET_UP , DESCRIBE , SDP lines..._). Regards, Nikhil Agrawal ------------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070110/f3ed278c/attachment.html From mr.prabin at gmail.com Wed Jan 10 04:07:40 2007 From: mr.prabin at gmail.com (Dahal, Prabin) Date: Wed, 10 Jan 2007 17:52:40 +0545 Subject: [Live-devel] i have two ethernet cards.. Message-ID: hi i am trying to implement LIVE555 as a library in my program. i am receiving a MPGE4 video through RTSP. I do not understand the two netAddressBits SendingInterfaceAddr and ReceivingInterfaceAddr. I have two ethernet cards and i want to use one ethernet as fixed for LIVE555. Please suggest me how to do it? is it not possible by changing the above variables INADDR_ANY in the groupsockHelper.cpp to my IP address. I am confused which to change. so that my LIVE555 works only on one ethernet card.. -- Best Regards, Prabin Dahal ------------------------------------- mr.prabin at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070110/bc3abb53/attachment-0001.html From info at dnastudios.it Wed Jan 10 14:07:53 2007 From: info at dnastudios.it (DNA STUDIOS s.r.l.) Date: Wed, 10 Jan 2007 23:07:53 +0100 (CET) Subject: [Live-devel] development request Message-ID: <61008.85.20.243.42.1168466873.squirrel@www.dnastudios.it> Hi, we have a business site of video on demand in Italy; we use Darwin Streaming Server and a reduced and recompiled version of VLC as player. The problem is that the seeking does not work fine, practically DSS is perfectly compatible with Quick Time but not with VLC. Personally we think that DSS (and QuickTime) does not follow the RFC of the RTP/RTSP protocol and this thing is intentional from Apple; we need to modify DSS or still better VLC in way that server and client dialogue perfectly like DSS and QuickTime. We would want know if someone can resolve the problem (modifying DSS or VLC) and how many would cost to us. Thanks in advance. -- ------------------------------------------------------------- Nicola DNA STUDIOS s.r.l. From vd_mail_id at yahoo.com Wed Jan 10 15:53:39 2007 From: vd_mail_id at yahoo.com (vd mail_id) Date: Wed, 10 Jan 2007 15:53:39 -0800 (PST) Subject: [Live-devel] problem obtaining ES using openrtsp In-Reply-To: <61008.85.20.243.42.1168466873.squirrel@www.dnastudios.it> Message-ID: <20070110235339.37950.qmail@web59007.mail.re1.yahoo.com> I am trying to obtain ES from rtsp://stream1.canal.qc.ca/puq/parolesConn/paroles1.mp4 following the instructions given in FAQ using openRTSP, but at all times I am getting only 33 bytes in video-MP4V-ES-1. With another mp4 file I am getting only 51 bytes. Does anyone know what I am doing wrong? Does any one know of any rtsp stream in public domain which I can use to obtain the elementary streams? --TIA Vikram __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070110/7b25d3f2/attachment.html From finlayson at live555.com Wed Jan 10 16:31:04 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Jan 2007 16:31:04 -0800 Subject: [Live-devel] problem obtaining ES using openrtsp In-Reply-To: <20070110235339.37950.qmail@web59007.mail.re1.yahoo.com> References: <20070110235339.37950.qmail@web59007.mail.re1.yahoo.com> Message-ID: >I am trying to obtain ES from >rtsp://stream1.canal.qc.ca/puq/parolesConn/paroles1.mp4 following >the instructions given in FAQ using openRTSP, but at all times I am >getting only 33 bytes in video-MP4V-ES-1. Running openRTSP -V rtsp://stream1.canal.qc.ca/puq/parolesConn/paroles1.mp4 works perfectly for me; it receives both audio and video. Perhaps you have a firewall somewhere that is blocking UDP traffic? If so, try adding the "-t" option, to request streaming over TCP. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vdham at vt.edu Wed Jan 10 17:04:48 2007 From: vdham at vt.edu (vdham at vt.edu) Date: Wed, 10 Jan 2007 19:04:48 -0600 Subject: [Live-devel] problem obtaining ES using openrtsp In-Reply-To: References: <20070110235339.37950.qmail@web59007.mail.re1.yahoo.com> Message-ID: thanks, you were right enabling -t worked and looks like office firewal lwas blocking udp traffic. --Vikram ----- Original Message ----- From: Ross Finlayson Date: Wednesday, January 10, 2007 6:31 pm Subject: Re: [Live-devel] problem obtaining ES using openrtsp To: LIVE555 Streaming Media - development & use > >I am trying to obtain ES from > >rtsp://stream1.canal.qc.ca/puq/parolesConn/paroles1.mp4 following > >the instructions given in FAQ using openRTSP, but at all times I > am > >getting only 33 bytes in video-MP4V-ES-1. > > Running > openRTSP -V rtsp://stream1.canal.qc.ca/puq/parolesConn/paroles1.mp4 > works perfectly for me; it receives both audio and video. > > Perhaps you have a firewall somewhere that is blocking UDP > traffic? > If so, try adding the "-t" option, to request streaming over TCP. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070110/d3256541/attachment.html From TAYK0004 at ntu.edu.sg Wed Jan 10 18:34:01 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Thu, 11 Jan 2007 10:34:01 +0800 Subject: [Live-devel] Functions to add Message-ID: <438567054C073949AEBE5A28B83E7DE133FCAB@MAIL21.student.main.ntu.edu.sg> Hi guys, anyone with experiences in this can help me? I trying to stream a .264 file using Annex B file format. Upon reading the decoder, I found the functions to remove the delimiter (0x00, 0x01). Where should I implement these functions? Isit in the framer.cpp or in the streamer.cpp? Any other relevent information will be welcomed. I getting closer and closer to streaming h.264, since mine is a academic project, I can share the file later. Thanks to Engin for sharing his file with me although his is using RTP packet format instead. Regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070110/ba62023a/attachment.html From finlayson at live555.com Wed Jan 10 18:49:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 10 Jan 2007 18:49:43 -0800 Subject: [Live-devel] Functions to add In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCAB@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCAB@MAIL21.student.main.ntu.edu.sg> Message-ID: >anyone with experiences in this can help me? I trying to stream a >.264 file using Annex B file format. Upon reading the decoder, I >found the functions to remove the delimiter (0x00, 0x01). Where >should I implement these functions? Isit in the framer.cpp or in the >streamer.cpp? The 0x00 0x00 0x01 (note: 3 bytes, not 2) prefix is *not* part of the NALu data that gets packed into RTP packets, and therefore must be stripped by your 'framer' object, before it gets passed to the "H264VideoRTPSink" object. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070110/1f8d518b/attachment.html From rishikerala at gmail.com Wed Jan 10 22:43:22 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Thu, 11 Jan 2007 15:43:22 +0900 Subject: [Live-devel] Hi any one sucess.. Message-ID: <4ba29cc0701102243v1304b778ub1a7994d9d6deb9a@mail.gmail.com> Hi all, I am trying to use the client player of Live. And try to Get Mpeg2-ts Stream . >From playCommon.cpp-- when it get MediaSession- mpeg2-ts- It is going to the SimpleRTPSource and MultiFrameRTPSource. I gone through the source. It is going to the MultiFrameRTPSource. and looping there. Actually I want to get the Bufferpackets in main() of playCommon.cpp, and do some processing..and again get the nextpackets from MultiFrameSouce. How I can schedule this .. Please give some suggestions. Ross give me some idea Rgds Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070110/d53c53b1/attachment.html From ritsgenx at gmail.com Thu Jan 11 02:57:40 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Thu, 11 Jan 2007 16:27:40 +0530 Subject: [Live-devel] Seeking while streaming elementary mpeg-1 video ? Message-ID: Hi Ross, I am trying to stream an elementary mpeg-1 video using the "testonDemandRTPServer". Also, I am using VLC and Real Player as a client programs. The problem is I am unable to seek while streaming. And the problem exist in both the palyers (VLC and Realplayer). Whereas when I stream "a MPEG-1 or 2 audio+video program stream" seeking is working fine with both the software clients. Can u suggest me any solution and reason? Thanks and Regards, Ritesh Mittal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/0ba1b4a7/attachment.html From yunjnz at yahoo.com Thu Jan 11 03:01:46 2007 From: yunjnz at yahoo.com (Sean) Date: Thu, 11 Jan 2007 03:01:46 -0800 (PST) Subject: [Live-devel] How to calculate a packet's duration in milliseconds for VOB format video? Message-ID: <20070111110146.21450.qmail@web35811.mail.mud.yahoo.com> Greetings, I want to streaming a VOB file(stereo MPEG1Layer2 Audio with MPEG2 video) in one RTP Stream, It seems that all the packets are 2048 bytes with a beginning of 0x000001BA, and I want to transfer one packet each time, Can you help me for how to calculate each packet's duration in milliseconds? I've tried to use the gap between the next packet's timestamp and the current packet's timestamp, and divide 45000(as the same as the TS format), but when I use my client to play the stream, it isn't continuous, and I can confirm that the vob file can be played normally by the client. Thanks a lot, Sean ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index From sid1337 at gmail.com Thu Jan 11 03:23:47 2007 From: sid1337 at gmail.com (Siddharth Agarwal) Date: Thu, 11 Jan 2007 16:53:47 +0530 Subject: [Live-devel] testWAVAudioStreamer: problem with playing in VLC Message-ID: <28961387.20070111165347@gmail.com> OK, please consider me a newbie. I've compiled everything using mingw (on windows), and now I want to test the wave audio streamer. I've put in a small 8-second wave file as test.wav, and then I run testWAVAudioStreamer.exe. I now open VLC, and try to play it using the RTSP address given. All VLC does is sit there for a second or two, and then stop playing. I don't hear any output. VLC can play other streams well. What could be the problem? -- Best regards, Sid From c00jz3r0 at gmail.com Thu Jan 11 05:21:17 2007 From: c00jz3r0 at gmail.com (Cool_Zer0) Date: Thu, 11 Jan 2007 13:21:17 +0000 Subject: [Live-devel] Compilation for Windows Mobile 5.0 Message-ID: <45A639CD.1000605@gmail.com> Hi there, I found out your library and I can't find some information. My main question is: - Can I compile your library to Windows Mobile 5.0? I have the following situation... I'm receiving RTP packets from network to my PDA. This packets contains H.263 frames. Can I use your library to decode the H.263 frames and transform them into BGR24 (Bitmap files)? Thanks From mrnikhilagrawal at gmail.com Thu Jan 11 05:40:33 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Thu, 11 Jan 2007 19:10:33 +0530 Subject: [Live-devel] testWAVAudioStreamer: problem with playing in VLC In-Reply-To: <28961387.20070111165347@gmail.com> References: <28961387.20070111165347@gmail.com> Message-ID: <733cde3e0701110540h572aec83g792bc60d02bd78e6@mail.gmail.com> Hi, Parser for Wav file that parses Wav file header ( in Class WAVAudioFileSource Constructor) is not generic that is, not compattible for all Wav files. For this you need to know Wav header details (available easily) and need to update function WAVAudioFileSource constructor that is parsing header. Many parameters in parsing like no. of channels (must be less than or equal to 2) , or format header length, blah blah blah..are extracted from input Wav file. Parsing is hard coded in this Class and you have to check the file you want to stream and code that is parsing it are compatible or not, and if not you need to do minor changes so that Live555 Server considers it as a valid streamable Wav file. May this will work for you....! . Regards, Nikhil Agrawal On 1/11/07, Siddharth Agarwal wrote: > > OK, please consider me a newbie. > > I've compiled everything using mingw (on windows), and now I want to > test the wave audio streamer. I've put in a small 8-second wave file as > test.wav, and then I run testWAVAudioStreamer.exe. I now open VLC, and > try to play it using the RTSP address given. All VLC does is sit there > for a second or two, and then stop playing. I don't hear any output. > > VLC can play other streams well. > > What could be the problem? > > -- > Best regards, > Sid > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/b156ca14/attachment.html From shaswata at alumnux.com Thu Jan 11 06:10:19 2007 From: shaswata at alumnux.com (Shaswata Jash) Date: Thu, 11 Jan 2007 19:40:19 +0530 Subject: [Live-devel] Compilation for Windows Mobile 5.0 References: <45A639CD.1000605@gmail.com> Message-ID: <000901c7358a$3a058df0$2e0aa8c0@NITU> Live555 is a library related to streaming only. So you can obviously extract h.263 frames from RTP packets using this library, but there after you have to use other third party library for decoding. One such decoding library may be ffmpeg, though you have to recompile it for Windows Mobile 5, which itself can be little bit complicated. For that you may take a look at CoreCodec project which has ported part of ffmpeg to Windows Mobile 5. With regards, Shaswata Jash --------------------------------------- Alumnus Software Ltd. Infinity, Tower II, 2nd Floor Plot A3, Block GP, Sector - V, Salt Lake City, Kolkata - 700 091, India Phone: (+91 33) 2357 5626/5627/5628 www.alumnux.com ----- Original Message ----- From: "Cool_Zer0" To: Sent: Thursday, January 11, 2007 6:51 PM Subject: [Live-devel] Compilation for Windows Mobile 5.0 > Hi there, > > I found out your library and I can't find some information. > My main question is: > - Can I compile your library to Windows Mobile 5.0? > > > I have the following situation... > I'm receiving RTP packets from network to my PDA. This packets contains > H.263 frames. Can I use your library to decode the H.263 frames and > transform them into BGR24 (Bitmap files)? > > > Thanks > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From TAYK0004 at ntu.edu.sg Thu Jan 11 09:51:21 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Fri, 12 Jan 2007 01:51:21 +0800 Subject: [Live-devel] Convert file into a bytestream Message-ID: <438567054C073949AEBE5A28B83E7DE133FCAC@MAIL21.student.main.ntu.edu.sg> Hi guys, thank you Ross for the clarification part on the parser. One other question I have is 1) To convert the .264 file into bytestream so that I can remove the 0x00, 0x01. Do I simply use the byteStreamFileSource* fileSource = ByteStreamFileSource::createNew(*env, inputFileName); // convert file to bytestream 2) Is there any customization required for byteStreamFileSource.cpp? I noticed byteStreamFIleSouce also contains doGetNextFrame and other functions, will it interfer with my functions in the framer? Many Thanks once again. Regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/66a884ec/attachment.html From finlayson at live555.com Thu Jan 11 10:00:08 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Jan 2007 10:00:08 -0800 Subject: [Live-devel] How to calculate a packet's duration in milliseconds for VOB format video? In-Reply-To: <20070111110146.21450.qmail@web35811.mail.mud.yahoo.com> References: <20070111110146.21450.qmail@web35811.mail.mud.yahoo.com> Message-ID: >I want to streaming a VOB file(stereo MPEG1Layer2 >Audio with MPEG2 video) in one RTP Stream, No, you don't want to do this - at least, if you want any standard client to be able to play your stream. Instead, stream audio and video as separate RTP streams. Because your VOB file contains MPEG-1 audio (rather than AC-3), it is just a regular MPEG Program Stream, and can be streamed using the existing "LIVE555 Media Server" (if you rename the file so that its name ends with ".mpg"), or "testOnDemandRTSPServer" (if you rename the file as "test.mpg"). You won't need to write any new code at all. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Jan 11 09:59:29 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Jan 2007 09:59:29 -0800 Subject: [Live-devel] Convert file into a bytestream In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCAC@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCAC@MAIL21.student.main.ntu.edu.sg> Message-ID: >1) To convert the .264 file into bytestream so that I can remove the >0x00, 0x01. Do I simply use the >byteStreamFileSource* fileSource = >ByteStreamFileSource::createNew(*env, inputFileName); // convert >file to bytestream > >2) Is there any customization required for byteStreamFileSource.cpp? >I noticed byteStreamFIleSouce also contains doGetNextFrame and other >functions, will it >interfer with my functions in the framer? No, a regular "ByteStreamFileSource" should work. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/6c958fa3/attachment.html From finlayson at live555.com Thu Jan 11 10:06:36 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Jan 2007 10:06:36 -0800 Subject: [Live-devel] Seeking while streaming elementary mpeg-1 video ? In-Reply-To: References: Message-ID: >I am trying to stream an elementary mpeg-1 video using the >"testonDemandRTPServer". >Also, I am using VLC and Real Player as a client programs. The >problem is I am unable to >seek while streaming. And the problem exist in both the palyers (VLC >and Realplayer). > >Whereas when I stream "a MPEG-1 or 2 audio+video program stream" >seeking is working >fine with both the software clients. > >Can u suggest me any solution and reason? Server support for seeking within MPEG Video Elementary Streams has not been implemented yet. (It would be very easy to do - just implement "duration()" and "seekStreamSource()" in "MPEG1or2VideoFileServerMediaSubsession" - but I havengt gotten around to doing this yet.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From vd_mail_id at yahoo.com Thu Jan 11 11:08:36 2007 From: vd_mail_id at yahoo.com (vd mail_id) Date: Thu, 11 Jan 2007 11:08:36 -0800 (PST) Subject: [Live-devel] http or rtsp streaming? In-Reply-To: <000901c7358a$3a058df0$2e0aa8c0@NITU> Message-ID: <2567.91963.qm@web59006.mail.re1.yahoo.com> Hello, I am trying to understand what is the advantage of using http or rtsp streaming in regards to streaming performance and end user perception. Which one is better and why? Thanks --Vikram --------------------------------- Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/54da601e/attachment.html From drobbins at fsmlabs.com Thu Jan 11 12:02:57 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Thu, 11 Jan 2007 13:02:57 -0700 Subject: [Live-devel] testing ff and rw MPEG-2 TS support Message-ID: <45A697F1.3070605@fsmlabs.com> Ross, I'm needing to test the new FF and RW MPEG-2 TS functionality included in live555 for a project that I'm working on. Could you let me know what clients you used for testing the FF and RW functionality so that I can validate the functionality of our compiled library on this end? Could you also let me know of any Linux or Windows clients that you know of that support FF and RW properly? Much thanks, Daniel Robbins From finlayson at live555.com Thu Jan 11 13:00:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Jan 2007 13:00:15 -0800 Subject: [Live-devel] Server 'trick play' support for MPEG Transport Stream files Message-ID: Our RTSP server implementation (and therefore the "LIVE555 Media Server", and the "testOnDemandRTSPServer" demo application) now supports 'trick mode' operations (seeking, fast forward, reverse play) when streaming MPEG Transport Stream files. For this to work, each Transport Stream file must have (in the same directory) a corresponding index file' (with name suffix ".tsx). You create these index files using the "MPEG2TransportStreamIndexer" application, whose code is distributed in the "testProgs" directory. NOTE: Before you run this application, please upgrade to the latest version (2007.01.11) of the "LIVE555 Streaming Media" code, and rebuild it. (Earlier versions of the code had a bug that prevented the application from working properly on some Transport Stream files.) To generate each index file, run MPEG2TransportStreamIndexer Be warned that this program is currently rather slow, so I suggest running it on the fastest computer that you have. Once you've generated an index file for each Transport Stream file that you wish to stream, our RTSP server implementation will now handle 'trick mode' operations on the file. Unfortunately, VLC's GUI currently doesn't handle the trick mode operations properly. (The "LIVE555 Streaming Media" code - which implement's the RTSP client protocol in VLC - has all the hooks for doing these trick mode operations; however, the VLC code above this does not yet use this properly.) I'll be working with the VLC developers to try to get this resolved ASAP, so we can have versions of VLC that perform trick play on Transport Streams properly. Unfortunately the only other client that I know of right now that supports 'trick play' operations on MPEG Transport Streams is the Amino set-top box (hardware). (This is what I have been using for testing, pending a resolution of the problems with VLC.) (If anyone knows of any other clients that work, please let us know. The 'trick mode' operations are all a standard part of the RTSP protocol, so there are likely to be other clients out there that support it.) In the meantime, once you have generated your index files, you can try running a demo application called "testMPEG2TransportStreamTrickPlay" (also in the "testProgs" directory) to simulate the effect of 'trick play' operations on Transport Stream files. To run it: testMPEG2TransportStreamTrickPlay where is the original Transport Stream file name (which must end with ".ts"). There must also be a corresponding index file for this file. is the starting play time in seconds (use 0 to play from the start) is a non-zero integer, representing the playing speed (use a negative number for reverse play) Examples (assume that your original Transport Stream file is named "foo.ts", and that you have already generated an index file, named "too.tsx"): testMPEG2TransportStreamTrickPlay foo.ts 0 8 foo8.ts The output file "foo8.ts" is the original stream, sped up 8x testMPEG2TransportStreamTrickPlay foo.ts 30 -1 foo-1.ts The output file "foo-1.ts" is the original stream, played backwards (at 1x speed), starting from the 30 second point. testMPEG2TransportStreamTrickPlay foo.ts 30 -5 foo-5.ts The output file "foo-5.ts" is the original stream, played backwards (at 5x speed), starting from the 30 second point. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From drobbins at fsmlabs.com Thu Jan 11 13:53:46 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Thu, 11 Jan 2007 14:53:46 -0700 Subject: [Live-devel] Server 'trick play' support for MPEG Transport Stream files In-Reply-To: References: Message-ID: <45A6B1EA.1000805@fsmlabs.com> This is exactly the information I needed. Thank you :) Regards, Daniel Robbins Ross Finlayson wrote: > Our RTSP server implementation (and therefore the "LIVE555 Media > Server", and the "testOnDemandRTSPServer" demo application) now > supports 'trick mode' operations (seeking, fast forward, reverse > play) when streaming MPEG Transport Stream files. > From vd_mail_id at yahoo.com Thu Jan 11 16:29:01 2007 From: vd_mail_id at yahoo.com (vd mail_id) Date: Thu, 11 Jan 2007 16:29:01 -0800 (PST) Subject: [Live-devel] problem obtaining ES using openrtsp In-Reply-To: Message-ID: <20070112002901.12391.qmail@web59007.mail.re1.yahoo.com> I have been able to obtain test.m4e file using the openRTSP and stream using onDemandRTSPServer. I have following questions: Is the file test.m4e a quicktime mov format file using atom structure? Does it have rtp hints? If it doesn't have rtp hints how are we able to generate the rtp traffic? Thanks --Vikram thanks, you were right enabling -t worked and looks like office firewal lwas blocking udp traffic. --Vikram ----- Original Message ----- From: Ross Finlayson Date: Wednesday, January 10, 2007 6:31 pm Subject: Re: [Live-devel] problem obtaining ES using openrtsp To: LIVE555 Streaming Media - development & use > >I am trying to obtain ES from > >rtsp://stream1.canal.qc.ca/puq/parolesConn/paroles1.mp4 following > >the instructions given in FAQ using openRTSP, but at all times I > am > >getting only 33 bytes in video-MP4V-ES-1. > > Running > openRTSP -V rtsp://stream1.canal.qc.ca/puq/parolesConn/paroles1.mp4 > works perfectly for me; it receives both audio and video. > > Perhaps you have a firewall somewhere that is blocking UDP > traffic? > If so, try adding the "-t" option, to request streaming over TCP. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/8044fe8e/attachment.html From rishikerala at gmail.com Thu Jan 11 16:56:16 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Thu, 11 Jan 2007 16:56:16 -0800 Subject: [Live-devel] hi anybody have idea about this Message-ID: <4ba29cc0701111656u59eca0ddoc190d52d9a28c521@mail.gmail.com> Hi all, I am trying to port live api to a client board. I am using MPlayer demux_rtp.cpp source. As a reference. actually I am using a hardware based player. I need to pass the buffer to hardware decoder. the stream is mpeg2ts. I gone through the source. Please give me some idea to get bufferpacket from MultiFramedRTPSource.cpp. to playComon.cpp file. How can i shedule this to get the bufferpacket in playCommon.cpp (main()) and block getting the packets. after processing unblock it. Please suggest the idea . bcoz I am not getting the actual flow of the Sheduler in client module. Rgds Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/171d73a8/attachment.html From finlayson at live555.com Thu Jan 11 17:06:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 11 Jan 2007 17:06:07 -0800 Subject: [Live-devel] problem obtaining ES using openrtsp In-Reply-To: <20070112002901.12391.qmail@web59007.mail.re1.yahoo.com> References: <20070112002901.12391.qmail@web59007.mail.re1.yahoo.com> Message-ID: >I have been able to obtain test.m4e file using the openRTSP and >stream using onDemandRTSPServer. I have following questions: > >Is the file test.m4e a quicktime mov format file using atom structure? No. It contains just MPEG-4 Video data, and nothing else. That's what "Elementary Stream" means. > Does it have rtp hints? No. 'Hinting' is a technique that is used only by Apple's Darwin Streaming Server. It is not applicable to our RTSP server. > If it doesn't have rtp hints how are we able to generate the rtp traffic? Because our RTSP server implementation has explicit knowledge of the structure of MPEG-4 Video Elementary Stream data (ditto for MPEG-1,2 audio/video, MPEG-4 AAC audio, MPEG Transort Stream files, WAV audio files, etc. etc.). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rishikerala at gmail.com Thu Jan 11 18:09:37 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Fri, 12 Jan 2007 11:09:37 +0900 Subject: [Live-devel] hi help me Message-ID: <4ba29cc0701111809i1e2a40afy565560214d9d9014@mail.gmail.com> Hi all, I am just going through the source in mplayer for live support. Please help to add support to get bufferpacket for mpeg2-ts. if (demux_is_multiplexed_rtp_stream(demuxer)) { Here how can I get the buffer in bufferQueue. for mpeg2ts. please help me to do that.. Rgds Rsihi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/8a3beb0a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: demux_rtp.cpp Type: text/x-c++src Size: 20771 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070111/8a3beb0a/attachment-0001.bin From ritsgenx at gmail.com Thu Jan 11 21:58:39 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Fri, 12 Jan 2007 11:28:39 +0530 Subject: [Live-devel] Seeking while streaming elementary mpeg-1 video ? In-Reply-To: References: Message-ID: I get the point that implementation of two functions "MPEG1or2VideoFileServerMediaSubsession" is needed. But the client software themselves do not show the seeking instrument and do not send the "PLAY" placket (according to RTSP). How did they get to know that for "elementary" video mpeg-1 file they dont have to provide seek facility ??? Regards, Ritesh Mittal On 1/11/07, Ross Finlayson wrote: > > >I am trying to stream an elementary mpeg-1 video using the > >"testonDemandRTPServer". > >Also, I am using VLC and Real Player as a client programs. The > >problem is I am unable to > >seek while streaming. And the problem exist in both the palyers (VLC > >and Realplayer). > > > >Whereas when I stream "a MPEG-1 or 2 audio+video program stream" > >seeking is working > >fine with both the software clients. > > > >Can u suggest me any solution and reason? > > Server support for seeking within MPEG Video Elementary Streams has > not been implemented yet. (It would be very easy to do - just > implement "duration()" and "seekStreamSource()" in > "MPEG1or2VideoFileServerMediaSubsession" - but I havengt gotten > around to doing this yet.) > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070111/1eaa4eb4/attachment.html From mr.nguyenhonghai at gmail.com Fri Jan 12 01:37:06 2007 From: mr.nguyenhonghai at gmail.com (Hong Hai Nguyen) Date: Fri, 12 Jan 2007 16:37:06 +0700 Subject: [Live-devel] Live555 output file format! Message-ID: <731203720701120137x4466dba1i5e79f165df963a72@mail.gmail.com> Hi all! I'm a PhD student in H.U.T and I'm new to Live555. I see that when grabbing the stream from Darwin Streaming Server, live555 export an output file for each sub session: audio-MPEG4-GENERIC-2 for audio and video-MPEG4-ES-1 for video. Could you so kindly take a little bit of your time to tell me which file formats are stored in those files. Best regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/02e22375/attachment.html From finlayson at live555.com Fri Jan 12 01:48:02 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 01:48:02 -0800 Subject: [Live-devel] Seeking while streaming elementary mpeg-1 video ? In-Reply-To: References: Message-ID: >I get the point that implementation of two functions >"MPEG1or2VideoFileServerMediaSubsession" is needed. But the client >software themselves do not show the seeking instrument Because the server does not implement the "duration()" function (for "MPEG1or2VideoFileServerMediaSubsession"), the stream's SDP description - returned in response to the RTSP "DESCRIBE" command - does not include an end time in the "a=range:" line. Because of this, the RTSP client player (quite correctly) concludes that the stream is not seekable. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jan 12 01:52:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 01:52:53 -0800 Subject: [Live-devel] Live555 output file format! In-Reply-To: <731203720701120137x4466dba1i5e79f165df963a72@mail.gmail.com> References: <731203720701120137x4466dba1i5e79f165df963a72@mail.gmail.com> Message-ID: >Hi all! > >I'm a PhD student in H.U.T and I'm new to Live555. I see that when >grabbing the stream from Darwin Streaming Server, live555 export an >output file for each sub session: audio-MPEG4-GENERIC-2 for audio >and video-MPEG4-ES-1 for video. Could you so kindly take a little >bit of your time to tell me which file formats are stored in those >files. The names should be self-explanatory. The audio stream uses the "audio/MPEG4-GENERIC" MIME type - i.e., AAC audio over RTP. The video stream uses the "video/MPEG4-ES" MIME type - i.e., MPEG-4 (Elementary Stream) video over RTP. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From info at dnastudios.it Fri Jan 12 02:41:05 2007 From: info at dnastudios.it (DNA STUDIOS s.r.l.) Date: Fri, 12 Jan 2007 11:41:05 +0100 (CET) Subject: [Live-devel] Server 'trick play' support for MPEG Transport Stream files In-Reply-To: References: Message-ID: <57106.85.20.243.42.1168598465.squirrel@www.dnastudios.it> from command line the seeking (trick play) in vlc media player work fine, the problem is in the gui... > Our RTSP server implementation (and therefore the "LIVE555 Media > Server", and the "testOnDemandRTSPServer" demo application) now > supports 'trick mode' operations (seeking, fast forward, reverse > play) when streaming MPEG Transport Stream files. > > For this to work, each Transport Stream file must have (in the same > directory) a corresponding index file' (with name suffix ".tsx). You > create these index files using the "MPEG2TransportStreamIndexer" > application, whose code is distributed in the "testProgs" directory. > > NOTE: Before you run this application, please upgrade to the latest > version (2007.01.11) of the "LIVE555 Streaming Media" code, and > rebuild it. (Earlier versions of the code had a bug that prevented > the application from working properly on some Transport Stream files.) > > To generate each index file, run > MPEG2TransportStreamIndexer > Be warned that this program is currently rather slow, so I suggest > running it on the fastest computer that you have. > > Once you've generated an index file for each Transport Stream file > that you wish to stream, our RTSP server implementation will now > handle 'trick mode' operations on the file. > > Unfortunately, VLC's GUI currently doesn't handle the trick mode > operations properly. (The "LIVE555 Streaming Media" code - which > implement's the RTSP client protocol in VLC - has all the hooks for > doing these trick mode operations; however, the VLC code above this > does not yet use this properly.) I'll be working with the VLC > developers to try to get this resolved ASAP, so we can have versions > of VLC that perform trick play on Transport Streams properly. > > Unfortunately the only other client that I know of right now that > supports 'trick play' operations on MPEG Transport Streams is the > Amino set-top box (hardware). (This is what I have been using for > testing, pending a resolution of the problems with VLC.) > > (If anyone knows of any other clients that work, please let us know. > The 'trick mode' operations are all a standard part of the RTSP > protocol, so there are likely to be other clients out there that > support it.) > > > In the meantime, once you have generated your index files, you can > try running a demo application called > "testMPEG2TransportStreamTrickPlay" (also in the "testProgs" > directory) to simulate the effect of 'trick play' operations on > Transport Stream files. To run it: > testMPEG2TransportStreamTrickPlay > > > where > is the original Transport > Stream file name (which must end with ".ts"). There must also be a > corresponding index file for this file. > is the starting play time in seconds (use 0 to > play from the start) > is a non-zero integer, representing the playing speed > (use a negative number for reverse play) > > Examples (assume that your original Transport Stream file is named > "foo.ts", and that you have already generated an index file, named > "too.tsx"): > > testMPEG2TransportStreamTrickPlay foo.ts 0 8 foo8.ts > The output file "foo8.ts" is the original stream, sped up 8x > > testMPEG2TransportStreamTrickPlay foo.ts 30 -1 foo-1.ts > The output file "foo-1.ts" is the original stream, played > backwards (at 1x speed), starting from the 30 second point. > > testMPEG2TransportStreamTrickPlay foo.ts 30 -5 foo-5.ts > The output file "foo-5.ts" is the original stream, played > backwards (at 5x speed), starting from the 30 second point. > -- > > 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 > -- ------------------------------------------------------------- Nicola Mettimano Production & Sales Manager DNA STUDIOS s.r.l. c/o Sviluppo Italia Abruzzo int. HT 5 64023 Mosciano Sant'Angelo (TE) Tel 085-9150020 Fax 085-9150021 From ritsgenx at gmail.com Fri Jan 12 02:47:53 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Fri, 12 Jan 2007 16:17:53 +0530 Subject: [Live-devel] Seeking while streaming elementary mpeg-1 video ? In-Reply-To: References: Message-ID: Thank you Ross. I have implemented both the functions mentioned by you and now i m capable of seeking MPEG-1 elementary video using VLC client. Thanks again. Ritesh On 1/12/07, Ross Finlayson wrote: > > >I get the point that implementation of two functions > >"MPEG1or2VideoFileServerMediaSubsession" is needed. But the client > >software themselves do not show the seeking instrument > > Because the server does not implement the "duration()" function (for > "MPEG1or2VideoFileServerMediaSubsession"), the stream's SDP > description - returned in response to the RTSP "DESCRIBE" command - > does not include an end time in the "a=range:" line. Because of > this, the RTSP client player (quite correctly) concludes that the > stream is not seekable. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/ec8b5ba4/attachment.html From ritsgenx at gmail.com Fri Jan 12 02:51:59 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Fri, 12 Jan 2007 16:21:59 +0530 Subject: [Live-devel] How to Stream multiple multiple media files at the same time ? Message-ID: Hi, I have used "testonDemandRTPServer" to stream one file at a time, i.e I can either stream a single mp3 file or a single mpeg-1 video file or a single .wav file. But if I want to stream multiple files (many .mp3, .wav. .mpeg files). so, Is this possible and how can we achive this ??? Regards, Ritesh Mittal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/0cd0b7a5/attachment.html From jackymaillist at gmail.com Fri Jan 12 03:11:29 2007 From: jackymaillist at gmail.com (Jacky Cheung) Date: Fri, 12 Jan 2007 19:11:29 +0800 Subject: [Live-devel] Avoid openning files when creating sdp format Message-ID: <45A76CE1.4000204@gmail.com> Hi Ross, I've noticed my file is being opened 2 to 3 times before actual streaming. After checking the code, the second open is for creating sdp format. Is there any ways that can avoid my files are being opened before actual streaming? It is not a problem for me to hard code the parameters. Thanks for your guidelines. Regards, Jacky From yunjnz at yahoo.com Fri Jan 12 04:49:51 2007 From: yunjnz at yahoo.com (Sean) Date: Fri, 12 Jan 2007 04:49:51 -0800 (PST) Subject: [Live-devel] How to calculate a packet's duration in milliseconds for VOB format video? In-Reply-To: Message-ID: <996542.74623.qm@web35801.mail.mud.yahoo.com> --- Ross Finlayson wrote: > >I want to streaming a VOB file(stereo MPEG1Layer2 > >Audio with MPEG2 video) in one RTP Stream, > > No, you don't want to do this - at least, if you > want any standard > client to be able to play your stream. > > Instead, stream audio and video as separate RTP > streams. Because > your VOB file contains MPEG-1 audio (rather than > AC-3), it is just a > regular MPEG Program Stream, and can be streamed > using the existing > "LIVE555 Media Server" (if you rename the file so > that its name ends > with ".mpg"), or "testOnDemandRTSPServer" (if you > rename the file as > "test.mpg"). You won't need to write any new code > at all. Actually I want to implement a customized server and client, and the client required the integrated stream. Can you help me for the issue? Appreciate. Sean > > -- > > 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 > ____________________________________________________________________________________ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com From glen at lincor.com Fri Jan 12 05:45:58 2007 From: glen at lincor.com (Glen Gray) Date: Fri, 12 Jan 2007 13:45:58 +0000 Subject: [Live-devel] Server 'trick play' support for MPEG Transport Stream files In-Reply-To: References: Message-ID: <45A79116.60305@lincor.com> Excellent stuff, thanks Ross. Ross Finlayson wrote: > Our RTSP server implementation (and therefore the "LIVE555 Media > Server", and the "testOnDemandRTSPServer" demo application) now > supports 'trick mode' operations (seeking, fast forward, reverse > play) when streaming MPEG Transport Stream files. > > For this to work, each Transport Stream file must have (in the same > directory) a corresponding index file' (with name suffix ".tsx). You > create these index files using the "MPEG2TransportStreamIndexer" > application, whose code is distributed in the "testProgs" directory. > > NOTE: Before you run this application, please upgrade to the latest > version (2007.01.11) of the "LIVE555 Streaming Media" code, and > rebuild it. (Earlier versions of the code had a bug that prevented > the application from working properly on some Transport Stream files.) > > To generate each index file, run > MPEG2TransportStreamIndexer > Be warned that this program is currently rather slow, so I suggest > running it on the fastest computer that you have. > > Once you've generated an index file for each Transport Stream file > that you wish to stream, our RTSP server implementation will now > handle 'trick mode' operations on the file. > > Unfortunately, VLC's GUI currently doesn't handle the trick mode > operations properly. (The "LIVE555 Streaming Media" code - which > implement's the RTSP client protocol in VLC - has all the hooks for > doing these trick mode operations; however, the VLC code above this > does not yet use this properly.) I'll be working with the VLC > developers to try to get this resolved ASAP, so we can have versions > of VLC that perform trick play on Transport Streams properly. > > Unfortunately the only other client that I know of right now that > supports 'trick play' operations on MPEG Transport Streams is the > Amino set-top box (hardware). (This is what I have been using for > testing, pending a resolution of the problems with VLC.) > > (If anyone knows of any other clients that work, please let us know. > The 'trick mode' operations are all a standard part of the RTSP > protocol, so there are likely to be other clients out there that > support it.) > > > In the meantime, once you have generated your index files, you can > try running a demo application called > "testMPEG2TransportStreamTrickPlay" (also in the "testProgs" > directory) to simulate the effect of 'trick play' operations on > Transport Stream files. To run it: > testMPEG2TransportStreamTrickPlay > > > where > is the original Transport > Stream file name (which must end with ".ts"). There must also be a > corresponding index file for this file. > is the starting play time in seconds (use 0 to > play from the start) > is a non-zero integer, representing the playing speed > (use a negative number for reverse play) > > Examples (assume that your original Transport Stream file is named > "foo.ts", and that you have already generated an index file, named > "too.tsx"): > > testMPEG2TransportStreamTrickPlay foo.ts 0 8 foo8.ts > The output file "foo8.ts" is the original stream, sped up 8x > > testMPEG2TransportStreamTrickPlay foo.ts 30 -1 foo-1.ts > The output file "foo-1.ts" is the original stream, played > backwards (at 1x speed), starting from the 30 second point. > > testMPEG2TransportStreamTrickPlay foo.ts 30 -5 foo-5.ts > The output file "foo-5.ts" is the original stream, played > backwards (at 5x speed), starting from the 30 second point. -- Glen Gray Digital Depot, Thomas Street Senior Software Engineer Dublin 8, Ireland Lincor Solutions Ltd. Ph: +353 (0) 1 4893682 From finlayson at live555.com Fri Jan 12 06:48:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 06:48:53 -0800 Subject: [Live-devel] Avoid openning files when creating sdp format In-Reply-To: <45A76CE1.4000204@gmail.com> References: <45A76CE1.4000204@gmail.com> Message-ID: >I've noticed my file is being opened 2 to 3 times before actual >streaming. After checking the code, the second open is for creating sdp >format. Is there any ways that can avoid my files are being opened >before actual streaming? Not really. However, if you're streaming from a live source, remember to set the "reuseFirstSource" parameter (to each "OnDemandServerMediaSubsession" subclass) to "True". If you do that, you'll only read from the input stream once (no matter how many clients you get for it). (The initial data that gets read in order to figure out the SDP description data will not get streamed.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jan 12 06:49:18 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 06:49:18 -0800 Subject: [Live-devel] How to calculate a packet's duration in milliseconds for VOB format video? In-Reply-To: <996542.74623.qm@web35801.mail.mud.yahoo.com> References: <996542.74623.qm@web35801.mail.mud.yahoo.com> Message-ID: > > >I want to streaming a VOB file(stereo MPEG1Layer2 >> >Audio with MPEG2 video) in one RTP Stream, >> >> No, you don't want to do this - at least, if you >> want any standard >> client to be able to play your stream. >> >> Instead, stream audio and video as separate RTP >> streams. Because >> your VOB file contains MPEG-1 audio (rather than >> AC-3), it is just a >> regular MPEG Program Stream, and can be streamed >> using the existing >> "LIVE555 Media Server" (if you rename the file so >> that its name ends >> with ".mpg"), or "testOnDemandRTSPServer" (if you >> rename the file as >> "test.mpg"). You won't need to write any new code >> at all. > >Actually I want to implement a customized server and >client, >and the client required the integrated stream. >Can you help me for the issue? No. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jan 12 06:50:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 06:50:07 -0800 Subject: [Live-devel] How to Stream multiple multiple media files at the same time ? In-Reply-To: References: Message-ID: >Hi, > >I have used "testonDemandRTPServer" to stream one file at a time, >i.e I can either stream a single mp3 file or a single mpeg-1 video >file or a single .wav file. But if I want to stream multiple files >(many .mp3, .wav. .mpeg files). so, Is this possible and how can we >achive this ??? Use the "LIVE555 Media Server" - . It was designed specifically to do this. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jackymaillist at gmail.com Fri Jan 12 07:18:49 2007 From: jackymaillist at gmail.com (Jacky) Date: Fri, 12 Jan 2007 23:18:49 +0800 Subject: [Live-devel] Avoid openning files when creating sdp format In-Reply-To: References: <45A76CE1.4000204@gmail.com> Message-ID: <95bd4800701120718h713733c7of00fd2884667fe5@mail.gmail.com> Hi Ross, Thanks for your reply. Yes, I am streaming from multiple live sources. And I've set the variable to True. I've created a class inherited from framedSource for receiving live sources. When a client, say for Real Player connect to the server, I found that an instance of my class is being constructed and destructed for getting frame, then it is recreated for rtp streaming. However, this flow will close my socket, as destructor is ran. So I am thinking if there is any ways to avoid it create and destroy for creating SDP ? I am thinking if I need to create socket outside of my class, do you think it is the only approach? Thanks for your guidelines. Regards, Jacky On 1/12/07, Ross Finlayson wrote: > > >I've noticed my file is being opened 2 to 3 times before actual > >streaming. After checking the code, the second open is for creating sdp > >format. Is there any ways that can avoid my files are being opened > >before actual streaming? > > Not really. However, if you're streaming from a live source, > remember to set the "reuseFirstSource" parameter (to each > "OnDemandServerMediaSubsession" subclass) to "True". If you do that, > you'll only read from the input stream once (no matter how many > clients you get for it). (The initial data that gets read in order > to figure out the SDP description data will not get streamed.) > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/eb43a13f/attachment.html From shishir at birmiwal.net Fri Jan 12 08:26:18 2007 From: shishir at birmiwal.net (Shishir Birmiwal) Date: Fri, 12 Jan 2007 21:56:18 +0530 Subject: [Live-devel] Compilation failure on cygwin (live-2007.01.11.tar.gz) Message-ID: Hi, I recently downloaded live-2007.01.11.tar.gz and tried to build it on cygwin (WinXP). After a ./genMakefile cygwin, I did a make. After spewing a lot of output on screen the build would give an error on groupsock/GroupsockHelper.cpp, complaining of inadequately defined structure ip_mreq_source. A little probing into the source revealed the reason to be IP_ADD_SOURCE_MEMBERSHIP defined for this platform. Moving the #endif above the ip_mreq_source solved the problem. 462 // The source-specific join/leave operations require special setsockopt() 463 // commands, and a special structure (ip_mreq_source). If the include files 464 // didn't define these, we do so here: 465 #ifndef IP_ADD_SOURCE_MEMBERSHIP 466 #ifdef LINUX 467 #define IP_ADD_SOURCE_MEMBERSHIP 39 468 #define IP_DROP_SOURCE_MEMBERSHIP 40 469 #else 470 #define IP_ADD_SOURCE_MEMBERSHIP 25 471 #define IP_DROP_SOURCE_MEMBERSHIP 26 472 #endif 473 #endif // moved up here 474 475 struct ip_mreq_source { 476 struct in_addr imr_multiaddr; /* IP multicast address of group */ 477 struct in_addr imr_sourceaddr; /* IP address of source */ 478 struct in_addr imr_interface; /* local IP address of interface */ 479 }; 480 // #endif // commented out here and moved up I guess this may be very specific to my platform (where IP_ADD_SOURCE_MEMBERSHIP is defined). I did not get much time to build it on a linux machine. In either case, moving the #endif up should fix the issue. Hope this helps anybody who comes across this problem. Regards Shishir PS: gcc -v output is Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) From TAYK0004 at ntu.edu.sg Fri Jan 12 09:05:24 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Sat, 13 Jan 2007 01:05:24 +0800 Subject: [Live-devel] Pocket PC software Message-ID: <438567054C073949AEBE5A28B83E7DE133FCAD@MAIL21.student.main.ntu.edu.sg> Hi guys, is there any pocket pc (windows Mobile 5.0) software that can playback h.264 streaming using RTP. VLC and Apple Quicktime recommended by Ross works only for PC. Thanks in advance Regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/1f8367ce/attachment.html From finlayson at live555.com Fri Jan 12 10:17:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 10:17:43 -0800 Subject: [Live-devel] Avoid openning files when creating sdp format In-Reply-To: <95bd4800701120718h713733c7of00fd2884667fe5@mail.gmail.com> References: <45A76CE1.4000204@gmail.com> <95bd4800701120718h713733c7of00fd2884667fe5@mail.gmail.com> Message-ID: >Yes, I am streaming from multiple live sources. And I've set the >variable to True. I've created a class inherited from framedSource >for receiving live sources. When a client, say for Real Player >connect to the server, I found that an instance of my class is being >constructed and destructed for getting frame, then it is recreated >for rtp streaming. If you have "reuseFirstSource" set to True, then yes, the input source class will be created/destroyed several times. However, it will be *read from* only once at a time - no matter how many clients have simultaneously requested playing the stream. Therefore, you need to modify your input class so that it can be created/destroyed several times, without affecting the actual underlying data source -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jan 12 10:29:22 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 10:29:22 -0800 Subject: [Live-devel] Compilation failure on cygwin (live-2007.01.11.tar.gz) In-Reply-To: References: Message-ID: This appears to be a problem with the header files distributed with/for Cygwin. It does not make sense for "IP_ADD_SOURCE_MEMBERSHIP" to be defined in the header files without "struct ip_mreq_source" also being defined in the header files - because that struct is intended to be used with the IP_ADD_SOURCE_MEMBERSHIP ioctl(). For every other environment that I'm aware of, either "IP_ADD_SOURCE_MEMBERSHIP" and "struct ip_mreq_source" are both defined in the header files, or neither of them are. Unfortunately, it's not possible to use the C/C++ preprocessor to do something like #ifndef struct ip_mreq_source so I can't modify the distributed code so that it will compile for both your Cygwin environment, and for every other environment out there (unless there's a Cygwin-specific compile-time #define that I can check?) The right solution is to fix the Cygwin distribution so that its header files define both "IP_ADD_SOURCE_MEMBERSHIP" and "struct ip_mreq_source" (or neither). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jan 12 10:46:17 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 10:46:17 -0800 Subject: [Live-devel] Pocket PC software In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCAD@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCAD@MAIL21.student.main.ntu.edu.sg> Message-ID: >is there any pocket pc (windows Mobile 5.0) software that can >playback h.264 streaming using RTP. > >VLC and Apple Quicktime recommended by Ross works only for PC. There is apparently a WinCE/PocketPC version of VLC http://www.videolan.org/vlc/download-wince.html (I'm not sure, though, whether or not it includes the "LIVE555 Streaming Media" software, which would be needed to play RTSP/RTP streams.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/6bc09af4/attachment.html From xcsmith at rockwellcollins.com Fri Jan 12 11:02:58 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Fri, 12 Jan 2007 13:02:58 -0600 Subject: [Live-devel] MPEG2TransportStreamFromESSource fix Message-ID: I am looking at the latest release notes and I see this: "Fixed a minor bug in "MPEG2TransportStreamFromESSource"." Curious, what was the bug? I don't remember seeing a mail list discussion of it. Thanks! Xochitl From finlayson at live555.com Fri Jan 12 11:54:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 11:54:40 -0800 Subject: [Live-devel] MPEG2TransportStreamFromESSource fix In-Reply-To: References: Message-ID: >I am looking at the latest release notes and I see this: >"Fixed a minor bug in "MPEG2TransportStreamFromESSource"." >Curious, what was the bug? It was line 200 of "MPEG2TransportStreamFromESSource.cpp": if (PES_packet_length > 0xFFFF) { Previously, this had said if (PES_packet_length > 0xFFFFFFFF) { which is incorrect. However, this bug probably didn't affect anyone in practice. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From wei.francois at gmail.com Fri Jan 12 19:53:57 2007 From: wei.francois at gmail.com (=?GB2312?B?s8K2q86w?=) Date: Sat, 13 Jan 2007 11:53:57 +0800 Subject: [Live-devel] multi-threads and multi-processes Message-ID: <503760b30701121953m443c70f0m78f1ec332dc30d09@mail.gmail.com> Hi, Alls When we develope the Live video streaming program, what is the advantages and disadvantages about multi-threads vs multi-processes? What method does the Live555 use? What about others ? -- Regards, francois_wei -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/7bc1a24f/attachment.html From finlayson at live555.com Fri Jan 12 22:18:58 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 22:18:58 -0800 Subject: [Live-devel] multi-threads and multi-processes In-Reply-To: <503760b30701121953m443c70f0m78f1ec332dc30d09@mail.gmail.com> References: <503760b30701121953m443c70f0m78f1ec332dc30d09@mail.gmail.com> Message-ID: >Hi, Alls > When we develope the Live video streaming program, what is the >advantages and disadvantages about multi-threads vs multi-processes? > What method does the Live555 use? Read the FAQ!!! -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rajeshkumar.r at imimobile.com Fri Jan 12 22:42:43 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Sat, 13 Jan 2007 12:12:43 +0530 Subject: [Live-devel] RTP packets recvd from Helix Server can be directly send to Vlc player ??? Message-ID: <016901c736de$071254f0$6902000a@imidomain.com> Hi Ross Once RTSP session is established and streaming started on specific audio and video ports .The Rtp Packets what I am receiving on these ports can be directly send to the Vlc or need to process this before sending this to Vlc.what are the algorithm that we need to apply.I tried to understand the same thru lib code ,but could not. plz give me some hints or some documents. with Regards Rajesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/d63bba00/attachment.html From finlayson at live555.com Fri Jan 12 22:48:41 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 12 Jan 2007 22:48:41 -0800 Subject: [Live-devel] RTP packets recvd from Helix Server can be directly send to Vlc player ??? In-Reply-To: <016901c736de$071254f0$6902000a@imidomain.com> References: <016901c736de$071254f0$6902000a@imidomain.com> Message-ID: >Hi Ross > >Once RTSP session is established and streaming started on specific >audio and video ports .The Rtp Packets what I am receiving on these >ports can be directly send to the Vlc or need to process this before >sending this to Vlc.what are the algorithm that we need to apply.I >tried to understand the same thru lib code ,but could not. Is VLC able to play your stream, or is it not? If VLC is able to play your stream, then you can figure out how this works. Remember, You Have Complete Source Code (for both VLC, and for the LIVE555 Streaming Media libraries that it uses). If VLC is not able to play your stream, then please post the stream's (publically accessible) "rtsp://" URL to the mailing list, so we can investigate. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070112/488d0f50/attachment.html From sid1337 at gmail.com Sat Jan 13 02:59:07 2007 From: sid1337 at gmail.com (Siddharth Agarwal) Date: Sat, 13 Jan 2007 16:29:07 +0530 Subject: [Live-devel] testWAVAudioStreamer: problem with playing in VLC In-Reply-To: <733cde3e0701110540h572aec83g792bc60d02bd78e6@mail.gmail.com> References: <28961387.20070111165347@gmail.com> <733cde3e0701110540h572aec83g792bc60d02bd78e6@mail.gmail.com> Message-ID: <1041885151.20070113162907@gmail.com> Hello Nikhil, Thursday, January 11, 2007, 7:10:33 PM, you wrote: > Hi, > ? > Parser for Wav file that parses Wav file header ( in Class > WAVAudioFileSource Constructor) is not generic that is, not > compattible for all Wav files. For this you need to know Wav header > details (available easily) and need to update function > WAVAudioFileSource constructor that is parsing header. Many > parameters in parsing like no. of channels (must be less than or > equal to 2) , or format header length, blah blah blah..are?extracted > from input Wav file.?Parsing is hard coded in this Class and you > have to check the file you want to stream and code that is parsing > it are compatible or not, and if not you need to do minor changes so > that Live555 Server considers it as a valid streamable Wav file. > ? > May this will work for you....! . In fact, the problem was with mingw. I just compiled it using VC++ 2005 and it works now. Just a heads up. Thanks for the help. Sid > > ? > Regards, > Nikhil Agrawal > > ? > On 1/11/07, Siddharth Agarwal wrote: > OK, please consider me a newbie. > I've compiled everything using mingw (on windows), and now I want to > test the wave audio streamer. I've put in a small 8-second wave file as > test.wav, and then I run testWAVAudioStreamer.exe. I now open VLC, and > try to play it using the RTSP address given. All VLC does is sit there > for a second or two, and then stop playing. I don't hear any output. > VLC can play other streams well. > What could be the problem? > -- > Best regards, > Sid > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -- Best regards, Siddharth mailto:sid1337 at gmail.com From sid1337 at gmail.com Sat Jan 13 04:16:35 2007 From: sid1337 at gmail.com (Siddharth Agarwal) Date: Sat, 13 Jan 2007 17:46:35 +0530 Subject: [Live-devel] Any way to capture *output* in Windows and stream it? In-Reply-To: References: <016901c736de$071254f0$6902000a@imidomain.com> Message-ID: <1004014231.20070113174635@gmail.com> Hello Ross and everybody else, Is there any way to capture the output (i.e. what I hear from the speaker) in Windows, and stream it over the network? Is it possible with some modifications to the WindowsAudioInputStream files? -- Best regards, Sid From stas at mer.co.il Sun Jan 14 09:43:59 2007 From: stas at mer.co.il (Stas Desyatnlkov) Date: Sun, 14 Jan 2007 19:43:59 +0200 Subject: [Live-devel] How to delete live objects Message-ID: <8F5A28107CB68247BB8E3D3EE626F54F0203C5FD@fs1.mertree.mer.co.il> Hi All, In my code I do the following: Groupsock* sock = new Groupsock(...); src = new MultiframedRTPSource(...); sink = new MediaSink(...); sink->startPlaying(*src, afterPlay, sink); void afterPlay(void* user) { MediaSink* sink = (MediaSink*)user; Medium::close(src); delete sock; } After the program is finished I got memory leaks. If I try to delete sink pointer it crashes. What is the right sequence of destruction here? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070114/68d6504e/attachment-0001.html From finlayson at live555.com Sun Jan 14 10:52:05 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 14 Jan 2007 10:52:05 -0800 Subject: [Live-devel] How to delete live objects In-Reply-To: <8F5A28107CB68247BB8E3D3EE626F54F0203C5FD@fs1.mertree.mer.co.il> References: <8F5A28107CB68247BB8E3D3EE626F54F0203C5FD@fs1.mertree.mer.co.il> Message-ID: >content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C73803.925BB9BE" > >Hi All, > >In my code I do the following: > >Groupsock* sock = new Groupsock(?); > >src = new MultiframedRTPSource(?); > >sink = new MediaSink(?); Presumably you really meant to say src = SomeSubclassOfMultiFramedRTPSource::createNew(...); sink = SomeSubclassOfMediaSink::createNew(...); > >sink->startPlaying(*src, afterPlay, sink); > >void afterPlay(void* user) > >{ > > MediaSink* sink = (MediaSink*)user; > > Medium::close(src); > >delete sock; > >} > >After the program is finished I got memory >leaks. If I try to delete sink pointer it >crashes. > >What is the right sequence of destruction here? Generally speaking, you should destroy objects in the opposite order from that in which they were created. Also, subclasses of "Medium" are destroyed using "Medium::close()", whereas "Groupsock" objects are destroyed using "delete". (This is historical ugliness...) Note, however, that if two or more source objects are chained together using subclasses of "FramedFilter" - e.g., src1 --> filter2 --> filter3 --> sink4 - then you explicitly destroy only "sink4" and "filter3"; "filter2" and "src1" will get destroyed automatically when you destroy "filter3". This doesn't apply in your case, so you should do: Medium::close(sink); Medium::close(src); delete sock; -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070114/015a6b27/attachment.html From jzaiter at magnasys.tv Sun Jan 14 15:15:45 2007 From: jzaiter at magnasys.tv (James Zaiter) Date: Mon, 15 Jan 2007 10:15:45 +1100 Subject: [Live-devel] help needed in getting started with libraries Message-ID: <001501c73831$eb7ab930$3c00a8c0@MagnaService> Hi I am new to the mailing list and to live555. I cant seem to open any of the mak files in vs2005, I built all apps using nmake from the command line. I have managed to build all the applications in the package for my windows xp system and all apps work fine. I need help in using these libraries for my own user interface applications that I want to develop. A how to get started / tutorial would be much appreciated. regards James Zaiter Support Engineer T. +61 2 94171111 F. +61 2 94172394 M. +61 423881361 E. jzaiter at magnasys.tv W. www.magnasys.tv -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070114/ff845508/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 4585 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070114/ff845508/attachment.jpe From rishikerala at gmail.com Sun Jan 14 19:38:21 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Sun, 14 Jan 2007 19:38:21 -0800 Subject: [Live-devel] help me ... Message-ID: <4ba29cc0701141938t8072a9fwfb0a3cbe6cb13949@mail.gmail.com> Dear all, Any one ported live media to Settopbox. Please help me. I am not getting the real architecture of the eventloop. please give me some suggestions. i need to get mpeg2-ts streams using live media. give me some suggestions. rgds Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070114/bf7e7173/attachment.html From ritsgenx at gmail.com Sun Jan 14 23:20:14 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Mon, 15 Jan 2007 12:50:14 +0530 Subject: [Live-devel] How to Stream multiple multiple media files at the same time ? In-Reply-To: References: Message-ID: Thanks Ross . I got my answer. On 1/12/07, Ross Finlayson wrote: > > >Hi, > > > >I have used "testonDemandRTPServer" to stream one file at a time, > >i.e I can either stream a single mp3 file or a single mpeg-1 video > >file or a single .wav file. But if I want to stream multiple files > >(many .mp3, .wav. .mpeg files). so, Is this possible and how can we > >achive this ??? > > Use the "LIVE555 Media Server" - > . It was designed specifically > to do this. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070114/c4c6b534/attachment.html From ritsgenx at gmail.com Sun Jan 14 23:58:16 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Mon, 15 Jan 2007 13:28:16 +0530 Subject: [Live-devel] Maximum number of client connections Live555 can handle ??? Message-ID: Hi, I tried to test live555 server on a dual processor machine. I streamed one mpeg-1 file using VLC and real player as clients. I tried to connect multiple clients (on different machines) to the same server (requestion for streaming of an mpeg file). But when the client count reaches 21 the LIVE555 server failed to response for the new connections. The CPU usage of the server machine was nominal (8 to 10 percent) . Is there any limitation in terms of maximum number of connections live555 can handle. Is there any technique to increase the number of client connections that the server can handle ???? Thanks and Regards, Ritesh Mittal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070114/8fd92711/attachment-0001.html From finlayson at live555.com Mon Jan 15 00:27:33 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jan 2007 00:27:33 -0800 Subject: [Live-devel] Maximum number of client connections Live555 can handle ??? In-Reply-To: References: Message-ID: >I tried to test live555 server on a dual processor machine. I >streamed one mpeg-1 file using VLC and real player as clients. >I tried to connect multiple clients (on different machines) to the >same server (requestion for streaming of an mpeg file). But when the >client count reaches 21 the LIVE555 server failed to response for >the new connections. The CPU usage of the server machine was nominal >(8 to 10 percent) . You appear to have run up against an operating system-imposed limit - most likely the number of open files. I.e., it is probably a limit of your operating system, not an inherent limit in the LIVE555 code. You may be able to increase this limit by reconfiguring your operating system in some way. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ritsgenx at gmail.com Mon Jan 15 02:13:03 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Mon, 15 Jan 2007 15:43:03 +0530 Subject: [Live-devel] Maximum number of client connections Live555 can handle ??? In-Reply-To: References: Message-ID: Hi Ross, I am performing this test on Windows 2000 Server (Standard Edition). The maximum limit of opening the same file (with "rb+") mode is 509 . This i have tested by writing a test application which returns NULL to fopen call when it has already opened the same file 509 times. Hence, I guess there is some another reason for my query. Regards, Ritesh Mittal On 1/15/07, Ross Finlayson wrote: > > >I tried to test live555 server on a dual processor machine. I > >streamed one mpeg-1 file using VLC and real player as clients. > >I tried to connect multiple clients (on different machines) to the > >same server (requestion for streaming of an mpeg file). But when the > >client count reaches 21 the LIVE555 server failed to response for > >the new connections. The CPU usage of the server machine was nominal > >(8 to 10 percent) . > > > You appear to have run up against an operating system-imposed limit - > most likely the number of open files. I.e., it is probably a limit > of your operating system, not an inherent limit in the LIVE555 code. > You may be able to increase this limit by reconfiguring your > operating system in some way. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070115/e054497c/attachment.html From marete at edgenet.co.ke Mon Jan 15 05:19:57 2007 From: marete at edgenet.co.ke (Brian Gitonga Marete) Date: Mon, 15 Jan 2007 16:19:57 +0300 Subject: [Live-devel] Live555 Media Server and the AmiNet 124 Message-ID: <1168867197.1568.36.camel@delta.local> Hello all, Using the latest live555 media server (live.2007.01.11.tar.gz) I have been able to successfully server VOD from .ts files to the AmiNet 124. With an index file for the .ts file, trick-play works fine -- up to a point: * First, rewind and ff. cause the current frame to pause, after which there is no indication about where the rewind of ff. has reached. Therefore, one cannot search for a scene. * Don't know whether any of you has run into problems rewinding of forwarding a VoD an Amino box for a long time, have you? Mine seems to freeze if this is done for about 10sec straight or so. Tried both "nCube" and "MediaBase" settings. Tried RTSP trick-play scale factor of 1, 2, 3, 6 and many values in between. I realize, of course, that this is probably nothing to do with the VoD server, but would appreciate assistance nonetheless. Thanks, -- Brian Gitonga Marete Software Developer Edgenet Limited Email: marete at edgenet.co.ke Tel: +254 20 242019 From finlayson at live555.com Mon Jan 15 06:17:35 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jan 2007 06:17:35 -0800 Subject: [Live-devel] Live555 Media Server and the AmiNet 124 In-Reply-To: <1168867197.1568.36.camel@delta.local> References: <1168867197.1568.36.camel@delta.local> Message-ID: >Using the latest live555 media server (live.2007.01.11.tar.gz) I have >been able to successfully server VOD from .ts files to the AmiNet 124. >With an index file for the .ts file, trick-play works fine -- up to a >point: > * First, rewind and ff. cause the current frame to pause That shouldn't happen > * Don't know whether any of you has run into problems rewinding of > forwarding a VoD an Amino box for a long time, have you? Mine > seems to freeze if this is done for about 10sec straight or so. Neither should that. >Tried both "nCube" and "MediaBase" settings. "MediaBase" mode will never work. >I realize, of course, that this is probably nothing to do with the VoD >server, but would appreciate assistance nonetheless. Please post the (publically accessible) URL of a Transport Stream that illustrates the problems that you are seeing, so that we can download it to investigate what might be going wrong. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From kurutepe at nue.tu-berlin.de Mon Jan 15 07:28:15 2007 From: kurutepe at nue.tu-berlin.de (Engin Kurutepe) Date: Mon, 15 Jan 2007 16:28:15 +0100 Subject: [Live-devel] ByteStreamFileSource afterGetting function problem Message-ID: <45AB9D8F.2000106@nue.tu-berlin.de> Hello all, I am working to make my H264RTPStreamFramer use asynchronous read operations. Here is a snippet of code that i'm using: void H264RTPStreamFramer::doGetNextFrame() { if ( ! isCurrentlyAwaitingData() ) return; char first_byte = packetBuffer[0]; * fInputSource->getNextFrame(packetBuffer, 20, afterGettingHeader, this, handleClosure, this); } void H264RTPStreamFramer::afterGettingHeader(void* clientdata, unsigned frameSize, unsigned numTruncatedBytes, struct timeval presentationTime, unsigned durationInMicroseconds ) { * H264RTPStreamFramer *framer = (H264RTPStreamFramer*)clientdata; if(framer == NULL) return; framer->afterGettingHeader1(); } fInputSource is a ByteStreamFileSource. There are two breakpoints at the lines marked with *. FramedSource::afterGetting(this) is called inside afterGettingHeader1(), which also does some parsing on the header. The Problem is that the second breakpoint is never reached. And the program quits with the following error message: BasicTaskScheduler::SingleStep(): select() fails: No error Does that mean that fInputSource never finishes reading the 20 bytes from the byte stream? Thanks a lot, Engin From info at dnastudios.it Mon Jan 15 09:30:45 2007 From: info at dnastudios.it (DNA Studios s.r.l.) Date: Mon, 15 Jan 2007 18:30:45 +0100 Subject: [Live-devel] Server 'trick play' support for MPEG Transport Stream files In-Reply-To: <45A79116.60305@lincor.com> References: <45A79116.60305@lincor.com> Message-ID: <45ABBA45.9030508@dnastudios.it> You can test here (Darwin streaming server): rtsp://85.18.216.107/sampleQT.mov Standard mov file in bundle with DSS (hinted with quicktime i think) rtsp://85.18.216.107/eltonjohn.mp4 Movie encoded with x264 (main profile) and hinted with mpeg4ip see you soon ;) Glen Gray ha scritto: > Excellent stuff, thanks Ross. > > Ross Finlayson wrote: > >> Our RTSP server implementation (and therefore the "LIVE555 Media >> Server", and the "testOnDemandRTSPServer" demo application) now >> supports 'trick mode' operations (seeking, fast forward, reverse >> play) when streaming MPEG Transport Stream files. >> >> For this to work, each Transport Stream file must have (in the same >> directory) a corresponding index file' (with name suffix ".tsx). You >> create these index files using the "MPEG2TransportStreamIndexer" >> application, whose code is distributed in the "testProgs" directory. >> >> NOTE: Before you run this application, please upgrade to the latest >> version (2007.01.11) of the "LIVE555 Streaming Media" code, and >> rebuild it. (Earlier versions of the code had a bug that prevented >> the application from working properly on some Transport Stream files.) >> >> To generate each index file, run >> MPEG2TransportStreamIndexer >> Be warned that this program is currently rather slow, so I suggest >> running it on the fastest computer that you have. >> >> Once you've generated an index file for each Transport Stream file >> that you wish to stream, our RTSP server implementation will now >> handle 'trick mode' operations on the file. >> >> Unfortunately, VLC's GUI currently doesn't handle the trick mode >> operations properly. (The "LIVE555 Streaming Media" code - which >> implement's the RTSP client protocol in VLC - has all the hooks for >> doing these trick mode operations; however, the VLC code above this >> does not yet use this properly.) I'll be working with the VLC >> developers to try to get this resolved ASAP, so we can have versions >> of VLC that perform trick play on Transport Streams properly. >> >> Unfortunately the only other client that I know of right now that >> supports 'trick play' operations on MPEG Transport Streams is the >> Amino set-top box (hardware). (This is what I have been using for >> testing, pending a resolution of the problems with VLC.) >> >> (If anyone knows of any other clients that work, please let us know. >> The 'trick mode' operations are all a standard part of the RTSP >> protocol, so there are likely to be other clients out there that >> support it.) >> >> >> In the meantime, once you have generated your index files, you can >> try running a demo application called >> "testMPEG2TransportStreamTrickPlay" (also in the "testProgs" >> directory) to simulate the effect of 'trick play' operations on >> Transport Stream files. To run it: >> testMPEG2TransportStreamTrickPlay >> >> >> where >> is the original Transport >> Stream file name (which must end with ".ts"). There must also be a >> corresponding index file for this file. >> is the starting play time in seconds (use 0 to >> play from the start) >> is a non-zero integer, representing the playing speed >> (use a negative number for reverse play) >> >> Examples (assume that your original Transport Stream file is named >> "foo.ts", and that you have already generated an index file, named >> "too.tsx"): >> >> testMPEG2TransportStreamTrickPlay foo.ts 0 8 foo8.ts >> The output file "foo8.ts" is the original stream, sped up 8x >> >> testMPEG2TransportStreamTrickPlay foo.ts 30 -1 foo-1.ts >> The output file "foo-1.ts" is the original stream, played >> backwards (at 1x speed), starting from the 30 second point. >> >> testMPEG2TransportStreamTrickPlay foo.ts 30 -5 foo-5.ts >> The output file "foo-5.ts" is the original stream, played >> backwards (at 5x speed), starting from the 30 second point. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070115/78e4a913/attachment.html From finlayson at live555.com Mon Jan 15 09:56:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jan 2007 09:56:50 -0800 Subject: [Live-devel] Server 'trick play' support for MPEG Transport Stream files In-Reply-To: <45ABBA45.9030508@dnastudios.it> References: <45A79116.60305@lincor.com> <45ABBA45.9030508@dnastudios.it> Message-ID: >You can test here (Darwin streaming server): >rtsp://85.18.216.107/sampleQT.mov >Standard mov file in bundle with DSS (hinted with quicktime i think) >rtsp://85.18.216.107/eltonjohn.mp4 >Movie encoded with x264 (main profile) and hinted with mpeg4ip I don't understand this message at all. The "rtsp://" URLs that you quoted are streams that are served by a Darwin Streaming Server. What on Earth does this have to do with the subject of this thread - which concerned trick play support within *our* RTSP server, and for a completely different media type??? Please keep messages to this mailing list on topic. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070115/c5d0ced4/attachment-0001.html From vd_mail_id at yahoo.com Mon Jan 15 12:58:31 2007 From: vd_mail_id at yahoo.com (vd mail_id) Date: Mon, 15 Jan 2007 12:58:31 -0800 (PST) Subject: [Live-devel] live 555 & mpeg4ip projects comparison In-Reply-To: Message-ID: <20070115205831.71233.qmail@web59007.mail.re1.yahoo.com> Hello, Does anyone know how they are different and which will should be better approach? Thanks Vikram --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070115/7c8c9058/attachment.html From drobbins at fsmlabs.com Mon Jan 15 15:47:05 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Mon, 15 Jan 2007 16:47:05 -0700 Subject: [Live-devel] trick play indexing on PowerPC Message-ID: <45AC1279.5090003@fsmlabs.com> Ross, I have tested the new trick play functionality on an Intel PC, and it works well. However, I've run into an issue on PowerPC, which is the key one for us. On PowerPC, testMPEG2TransportStreamTrickPlay is generating zero-length files. I think there may be some kind of endian issue going on somewhere with the new indexing functionality. Question: should a .tsx file generated on a little-endian Intel PC be identical to a .tsx file generated on a big-endian PowerPC? Using my test.ts file, the test.tsx index is the same size on both architectures but it contains different binary data. Any ideas where to look? Regards, Daniel From drobbins at fsmlabs.com Mon Jan 15 16:02:30 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Mon, 15 Jan 2007 17:02:30 -0700 Subject: [Live-devel] trick play indexing on PowerPC In-Reply-To: <45AC1279.5090003@fsmlabs.com> References: <45AC1279.5090003@fsmlabs.com> Message-ID: <45AC1616.8030908@fsmlabs.com> Some quick additional info: I copied over my .tsx file that was generated on i386 over to the PowerPC, and then testMPEG2TransportStreamTrickPlay was able to generate some data. So it appears that it may be an issue with the .tsx index *generation* code. Will now try to play back the generated .ts file... -Daniel Daniel Robbins wrote: > Ross, > > I have tested the new trick play functionality on an Intel PC, and it > works well. However, I've run into an issue on PowerPC, which is the key > one for us. > > On PowerPC, testMPEG2TransportStreamTrickPlay is generating zero-length > files. I think there may be some kind of endian issue going on > somewhere with the new indexing functionality. > > Question: should a .tsx file generated on a little-endian Intel PC be > identical to a .tsx file generated on a big-endian PowerPC? Using my > test.ts file, the test.tsx index is the same size on both architectures > but it contains different binary data. > > Any ideas where to look? > > Regards, > > Daniel > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From drobbins at fsmlabs.com Mon Jan 15 16:06:25 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Mon, 15 Jan 2007 17:06:25 -0700 Subject: [Live-devel] trick play indexing on PowerPC In-Reply-To: <45AC1279.5090003@fsmlabs.com> References: <45AC1279.5090003@fsmlabs.com> Message-ID: <45AC1701.2020008@fsmlabs.com> Ross, The Intel PC-generated index, when copied over to the PowerPC, allowed testMPEG2TransportStreamTrickPlay to function properly and generate a valid .ts output file containing a "fast forwarded" stream. So it looks like it is indeed some kind of issue with the index file generation. Regards, Daniel Daniel Robbins wrote: > Ross, > > I have tested the new trick play functionality on an Intel PC, and it > works well. However, I've run into an issue on PowerPC, which is the key > one for us. > > On PowerPC, testMPEG2TransportStreamTrickPlay is generating zero-length > files. I think there may be some kind of endian issue going on > somewhere with the new indexing functionality. > > Question: should a .tsx file generated on a little-endian Intel PC be > identical to a .tsx file generated on a big-endian PowerPC? Using my > test.ts file, the test.tsx index is the same size on both architectures > but it contains different binary data. > > Any ideas where to look? > > Regards, > > Daniel > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From finlayson at live555.com Mon Jan 15 13:31:38 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jan 2007 13:31:38 -0800 Subject: [Live-devel] ByteStreamFileSource afterGetting function problem In-Reply-To: <45AB9D8F.2000106@nue.tu-berlin.de> References: <45AB9D8F.2000106@nue.tu-berlin.de> Message-ID: >And the program >quits with the following error message: > > BasicTaskScheduler::SingleStep(): select() fails: No error This error is occurring because you're running Windows, and you're trying to read from open files asynchronously, which Windows does not support (at least, not using "select()"). You should upgrade to the latest version of the code, in which all file reading in Windows is done synchronously. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 15 16:49:37 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jan 2007 16:49:37 -0800 Subject: [Live-devel] trick play indexing on PowerPC In-Reply-To: <45AC1701.2020008@fsmlabs.com> References: <45AC1279.5090003@fsmlabs.com> <45AC1701.2020008@fsmlabs.com> Message-ID: >The Intel PC-generated index, when copied over to the PowerPC, allowed >testMPEG2TransportStreamTrickPlay to function properly and generate a >valid .ts output file containing a "fast forwarded" stream. So it looks >like it is indeed some kind of issue with the index file generation. Thanks for the update. The 'index file' format is, indeed, little-endian; however, the code that generates index files is supposed to work correctly regardless of the endian-ness of the computer that it's running on. But apparently that's not working properly. Unfortunately I don't currently have a big-endian computer available to test this on - so I'm going to need your help in tracking down this problem. Could you please do the following: 1/ Generate an index file on an Intel PC 2/ Generate an index file - from the *same* Transport Stream source - on a PowerPC 3/ Run "head -c 10000" on each file, to generate new files (the first 10000 bytes of each index file) 4/ Mail me these two (10000 byte) files, so I can compare them, to (hopefully) figure out why the index file generation is failing when done on a PowerPC. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From drobbins at fsmlabs.com Mon Jan 15 17:21:37 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Mon, 15 Jan 2007 18:21:37 -0700 Subject: [Live-devel] vlc trick mode options Message-ID: <45AC28A1.4080106@fsmlabs.com> Hi, Just wondering if anyone has found a way to use VLC with trick mode "scale" via the command-line? Ross has stated that the GUI doesn't support trick mode properly, but I'm wondering what options might be used over the command-line in the interim. Thanks, Daniel Robbins From drobbins at fsmlabs.com Mon Jan 15 17:26:52 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Mon, 15 Jan 2007 18:26:52 -0700 Subject: [Live-devel] trick play indexing on PowerPC In-Reply-To: References: <45AC1279.5090003@fsmlabs.com> <45AC1701.2020008@fsmlabs.com> Message-ID: <45AC29DC.4060106@fsmlabs.com> I will send these two files - in about 10 minutes - to your direct email to reduce list traffic. Regards, Daniel Ross Finlayson wrote: >> The Intel PC-generated index, when copied over to the PowerPC, allowed >> testMPEG2TransportStreamTrickPlay to function properly and generate a >> valid .ts output file containing a "fast forwarded" stream. So it looks >> like it is indeed some kind of issue with the index file generation. >> > > Thanks for the update. The 'index file' format is, indeed, > little-endian; however, the code that generates index files is > supposed to work correctly regardless of the endian-ness of the > computer that it's running on. But apparently that's not working > properly. > > Unfortunately I don't currently have a big-endian computer available > to test this on - so I'm going to need your help in tracking down > this problem. Could you please do the following: > 1/ Generate an index file on an Intel PC > 2/ Generate an index file - from the *same* Transport Stream > source - on a PowerPC > 3/ Run "head -c 10000" on each file, to generate new files > (the first 10000 bytes of each index file) > 4/ Mail me these two (10000 byte) files, so I can compare > them, to (hopefully) figure out why the index file generation is > failing when done on a PowerPC. > From zjuchenjun at hotmail.com Mon Jan 15 18:05:10 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Tue, 16 Jan 2007 10:05:10 +0800 Subject: [Live-devel] buffer overflow Message-ID: Hi ROSS, When i run "mplayer rtsp://10.13.72.88:8554/H264LiveVideoTest", It appears "librtsp:buffer overflow in rtsp_get" in client. What is the reason of the fault? Thanks. _________________________________________________________________ Windows Live Safety Center ?????????????????? http://safety.live.com/site/ZH-CN/default.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070115/d25c3906/attachment.html From finlayson at live555.com Mon Jan 15 18:35:47 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jan 2007 18:35:47 -0800 Subject: [Live-devel] vlc trick mode options In-Reply-To: <45AC28A1.4080106@fsmlabs.com> References: <45AC28A1.4080106@fsmlabs.com> Message-ID: >Hi, > >Just wondering if anyone has found a way to use VLC with trick mode >"scale" via the command-line? Ross has stated that the GUI doesn't >support trick mode properly, but I'm wondering what options might be >used over the command-line in the interim. No, because the problem is that the VLC code currently doesn't pass the "scale" parameter to the LIVE555 RTSP client library at all (so the default scale, 1, always gets used). I'm waiting for the VLC folks to fix this; it shouldn't be difficult. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 15 18:53:03 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jan 2007 18:53:03 -0800 Subject: [Live-devel] buffer overflow In-Reply-To: References: Message-ID: >Hi ROSS, > >When i run "mplayer rtsp://10.13.72.88:8554/H264LiveVideoTest", It >appears "librtsp:buffer overflow in rtsp_get" in client. > >What is the reason of the fault? I don't know. This is a MPlayer problem; you're going to have to ask them (or else figure it out yourself, because You Have Complete Source Code). I suggest using VLC or openRTSP instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From shishir at birmiwal.net Mon Jan 15 21:54:22 2007 From: shishir at birmiwal.net (Shishir Birmiwal) Date: Tue, 16 Jan 2007 11:24:22 +0530 Subject: [Live-devel] Compilation failure on cygwin (live-2007.01.11.tar.gz) In-Reply-To: References: Message-ID: Ross, I would agree to you on that. I see that in /usr/include/, I see that IP_ADD_SOURCE_MEMBERSHIP is defined in cygwin/sockets.h and cygwin/sockets.h is included from sys/sockets.h cygwin/sockets.h does NOT have ip_mreq_source structure defined. Additionally, I see w32api/ws2tcpip.h which has both IP_ADD_SOURCE_MEMBERSHIP and ip_mreq_source structures defined. Maybe this is something that the cygwin developers need to look into. :) Regards Shishir On 1/12/07, Ross Finlayson wrote: > This appears to be a problem with the header files distributed > with/for Cygwin. It does not make sense for > "IP_ADD_SOURCE_MEMBERSHIP" to be defined in the header files without > "struct ip_mreq_source" also being defined in the header files - > because that struct is intended to be used with the > IP_ADD_SOURCE_MEMBERSHIP ioctl(). > > For every other environment that I'm aware of, either > "IP_ADD_SOURCE_MEMBERSHIP" and "struct ip_mreq_source" are both > defined in the header files, or neither of them are. > > Unfortunately, it's not possible to use the C/C++ preprocessor to do > something like > #ifndef struct ip_mreq_source > so I can't modify the distributed code so that it will compile for > both your Cygwin environment, and for every other environment out > there (unless there's a Cygwin-specific compile-time #define that I > can check?) > > The right solution is to fix the Cygwin distribution so that its > header files define both "IP_ADD_SOURCE_MEMBERSHIP" and "struct > ip_mreq_source" (or neither). > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From morgan.torvolt at gmail.com Mon Jan 15 21:54:33 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Tue, 16 Jan 2007 09:54:33 +0400 Subject: [Live-devel] Maximum number of client connections Live555 can handle ??? In-Reply-To: References: Message-ID: <3cc3561f0701152154l1c521566wa18e9c6f0d6a2d1d@mail.gmail.com> Have you tried with more that 21 connections? What happens if you start 30 clients? You could script this by using the openRTSP client. -Morgan- On 15/01/07, Ritesh Mittal wrote: > Hi Ross, > > I am performing this test on Windows 2000 Server (Standard Edition). The > maximum limit of opening the same file (with "rb+") mode is 509 . This i > have tested by writing a test application which returns NULL to fopen call > when it has already opened the same file 509 times. > > Hence, I guess there is some another reason for my query. > > Regards, > Ritesh Mittal > > > > > On 1/15/07, Ross Finlayson wrote: > > >I tried to test live555 server on a dual processor machine. I > > >streamed one mpeg-1 file using VLC and real player as clients. > > >I tried to connect multiple clients (on different machines) to the > > >same server (requestion for streaming of an mpeg file). But when the > > >client count reaches 21 the LIVE555 server failed to response for > > >the new connections. The CPU usage of the server machine was nominal > > >(8 to 10 percent) . > > > > > > You appear to have run up against an operating system-imposed limit - > > most likely the number of open files. I.e., it is probably a limit > > of your operating system, not an inherent limit in the LIVE555 code. > > You may be able to increase this limit by reconfiguring your > > operating system in some way. > > -- > > > > Ross Finlayson > > Live Networks, Inc. > > http://www.live555.com/ > > _______________________________________________ > > live-devel mailing list > > live-devel at lists.live555.com > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > From jackymaillist at gmail.com Mon Jan 15 23:03:13 2007 From: jackymaillist at gmail.com (Jacky Cheung) Date: Tue, 16 Jan 2007 15:03:13 +0800 Subject: [Live-devel] Non-blocking socket Message-ID: <45AC78B1.4020003@gmail.com> Hi Ross If I would to use BackgroundReadHandling on one of my socket, do I need to set the socket as non-blocking mode? Thanks a lot Regards, Jacky From finlayson at live555.com Mon Jan 15 23:47:48 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 15 Jan 2007 23:47:48 -0800 Subject: [Live-devel] Non-blocking socket In-Reply-To: <45AC78B1.4020003@gmail.com> References: <45AC78B1.4020003@gmail.com> Message-ID: >If I would to use BackgroundReadHandling on one of my socket, do I need >to set the socket as non-blocking mode? I don't think it matters, because you're going to be reading from the socket only when new data is readable on it. But anyway, the default is non-blocking. I don't see any reason to change this, unless you plan to read from the socket synchronously, which you don't. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From marete at edgenet.co.ke Tue Jan 16 01:12:48 2007 From: marete at edgenet.co.ke (Brian Gitonga Marete) Date: Tue, 16 Jan 2007 12:12:48 +0300 Subject: [Live-devel] Live555 Media Server and the AmiNet 124 In-Reply-To: References: <1168867197.1568.36.camel@delta.local> Message-ID: <1168938768.1528.11.camel@delta.local> On Mon, 2007-01-15 at 06:17 -0800, Ross Finlayson wrote: > Please post the (publically accessible) URL of a Transport Stream > that illustrates the problems that you are seeing, so that we can > download it to investigate what might be going wrong. Hello all, Thanks Ross. I took your hint on the .ts files, and created a .ts file from an MPEG program file using the testMPEG1or2ProgramToTransportStream test program. I then indexed the .ts file and served it on-demand to the AmiNet 124 using your media server. Trick-play worked beautifully. So I guess the problem was with the .ts files, as you suspected. They contain copyrighted content, so I can't make them publicly available. But I can tell you how I created them. I used vlc-0.8.6 to access the main titles of DVDs, and used the "write to file" output, with the encapsulation format set to MPEG-TS and with no transcoding. The MPEG-TS options for VLC were unchanged from their defaults. Thanks, Brian. From finlayson at live555.com Tue Jan 16 01:22:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jan 2007 01:22:55 -0800 Subject: [Live-devel] Live555 Media Server and the AmiNet 124 In-Reply-To: <1168938768.1528.11.camel@delta.local> References: <1168867197.1568.36.camel@delta.local> <1168938768.1528.11.camel@delta.local> Message-ID: >So I guess the problem was with the .ts files, as you suspected. They >contain copyrighted content, so I can't make them publicly available. Unfortunately, if I can't see a specific example of a Transport Stream that is causing you difficulties, then I'm not going to be able to help you with your problem. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From marete at edgenet.co.ke Tue Jan 16 01:39:51 2007 From: marete at edgenet.co.ke (Brian Gitonga Marete) Date: Tue, 16 Jan 2007 12:39:51 +0300 Subject: [Live-devel] Live555 Media Server and the AmiNet 124 In-Reply-To: References: <1168867197.1568.36.camel@delta.local> <1168938768.1528.11.camel@delta.local> Message-ID: <1168940391.1528.15.camel@delta.local> On Tue, 2007-01-16 at 01:22 -0800, Ross Finlayson wrote: > Unfortunately, if I can't see a specific example of a Transport > Stream that is causing you difficulties, then I'm not going to be > able to help you with your problem. I understand this, and I am going to try and create some freely available TS that have the same problem and send you a link to them. Thanks, Brian. From zjuchenjun at hotmail.com Tue Jan 16 03:55:02 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Tue, 16 Jan 2007 19:55:02 +0800 Subject: [Live-devel] "createNewStreamSource()" member function Message-ID: Hi Ross,My new subclass of "ServerMediaSession"is H264VideoLiveServerMediaSubsession. Below is its implementation of the "createNewStreamSource()" member function. I create a new object of my data source class (H264VideoStreamDiscreteFramer is the subclass of ?H264VideoStreamFramer? which encapsulates my encoder.),but which 'framer' filter should I Feed it to? Is my code right? Thanks in advance! FramedSource* H264VideoLiveServerMediaSubsession ::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 320; // kbps, estimate ; see my notebook // Create the video source: H264VideoStreamDiscreteFramer *liveSource =H264VideoStreamDiscreteFramer::createNew(*env_H264, NULL, buffers_H264, length_H264, bufferhasitem_H264, mutex_H264); if (liveSource == NULL) return NULL; // Create a framer for the Video Elementary Stream: return H264VideoStreamFramer::createNew(envir(),liveSource); } _________________________________________________________________ ?? Windows Live Messenger ?????? http://get.live.com/messenger/overview -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070116/d0119ba5/attachment.html From shishir at birmiwal.net Tue Jan 16 04:37:25 2007 From: shishir at birmiwal.net (Shishir Birmiwal) Date: Tue, 16 Jan 2007 18:07:25 +0530 Subject: [Live-devel] Compilation failure on cygwin (live-2007.01.11.tar.gz) In-Reply-To: References: Message-ID: Hi, I sent a mail on the cygwin list (http://cygwin.com/ml/cygwin/2007-01/msg00516.html) and they have agreed to make a change for this. However, there is not commited date for the change. In the meanwhile, it may make sense to use a compile time #define to solve the problem. I generated a list of predefines with the following: $ touch foo.h $ cpp -dM foo.h > predefines.txt and I see that __CYGWIN__ and __CYGWIN32__ are both pre-defined. Replacing the following between lines 462-480 would help. // The source-specific join/leave operations require special setsockopt() // commands, and a special structure (ip_mreq_source). If the include files // didn't define these, we do so here: #if !defined(IP_ADD_SOURCE_MEMBERSHIP) || defined(__CYGWIN32__) struct ip_mreq_source { struct in_addr imr_multiaddr; /* IP multicast address of group */ struct in_addr imr_sourceaddr; /* IP address of source */ struct in_addr imr_interface; /* local IP address of interface */ }; #endif #ifndef IP_ADD_SOURCE_MEMBERSHIP #ifdef LINUX #define IP_ADD_SOURCE_MEMBERSHIP 39 #define IP_DROP_SOURCE_MEMBERSHIP 40 #else #define IP_ADD_SOURCE_MEMBERSHIP 25 #define IP_DROP_SOURCE_MEMBERSHIP 26 #endif #endif With this change, I was able to build the code successfully on cygwin (1.5.23) and on linux [gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52)] Hope this helps. Regards Shishir From finlayson at live555.com Tue Jan 16 06:13:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jan 2007 06:13:07 -0800 Subject: [Live-devel] "createNewStreamSource()" member function In-Reply-To: References: Message-ID: > return H264VideoStreamFramer::createNew(envir(),liveSource); You can't do this, because "H264VideoStreamFramer" is a virtual base class. Instead, you should define your own class "H263VideoStreamDiscreteFramer" to be a subclass of ""H264VideoStreamFramer". Then, your "H263VideoStreamDiscreteFramer" object can be the value returned by your implementation of "createNewStreamSource()". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070116/3149274d/attachment.html From phujka at gmail.com Tue Jan 16 06:14:24 2007 From: phujka at gmail.com (Hujka Petr) Date: Tue, 16 Jan 2007 15:14:24 +0100 Subject: [Live-devel] RTP player in browser Message-ID: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> Hi all, i need to make player of streamed content, which will work in IE, firefox and opera. I don't want to have it as plugin, because of safety reasons. So i think the best solution is to make it as an Java applet. I would like to use combination of JMF+Live (if you know better solution, please write it). I tried JMStudio, but it's not working, it looks like there is some problem in RTP implementation on Sun's library (RTSP seems to be working). I have this conclusion from JMStudio log: # # JMF Version 2.1.1e # ## Platform: Windows XP, x86, 5.1 ## Java VM: Sun Microsystems Inc., 1.5.0 ## Player created: com.sun.media.content.rtsp.Handler at 110c31 ## using DataSource: com.sun.media.protocol.rtsp.DataSource at 13f991 ## outgoing msg: ## DESCRIBE rtsp://172.31.149.238/test.mp3 RTSP/1.0 CSeq: 377 Accept: application/sdp User-Agent: JMF RTSP Player Version 2.1.1e ## incoming msg: ## RTSP/1.0 200 OK CSeq: 377 Date: Tue, Jan 16 2007 11:01:52 GMT Content-Base: rtsp://172.31.149.238/test.mp3/ Content-Type: application/sdp Content-Length: 302 v=0 o=- 5813127402 1 IN IP4 172.31.149.238 s=MPEG-1 or 2 Audio i=test.mp3 t=0 0 a=tool:LIVE555 Streaming Media v2006.11.15 a=type:broadcast a=control:* a=range:npt=0-300.769 a=x-qt-text-nam:MPEG-1 or 2 Audio a=x-qt-text-inf:test.mp3 m=audio 0 RTP/AVP 14 c=IN IP4 0.0.0.0 a=control:track1 ## outgoing msg: ## SETUP rtsp://172.31.149.238/test.mp3/track1 RTSP/1.0 CSeq: 378 Transport: RTP/AVP;unicast;client_port=46674-46675 User-Agent: JMF RTSP Player Version 2.1.1e ## incoming msg: ## RTSP/1.0 200 OK CSeq: 378 Date: Tue, Jan 16 2007 11:01:52 GMT Transport: RTP/AVP;unicast;destination=172.31.149.238 ;client_port=46674-46675;server_port=6972-6973 Session: 4 ## outgoing msg: ## PLAY rtsp://172.31.149.238/test.mp3 RTSP/1.0 CSeq: 379 Range: npt=0.0- Session: User-Agent: JMF RTSP Player Version 2.1.1e ## incoming msg: ## RTSP/1.0 200 OK CSeq: 379 Date: Tue, Jan 16 2007 11:01:52 GMT Range: npt=0.000- Session: 4 RTP-Info: url=rtsp://172.31.149.238/test.mp3/track1;seq=35049;rtptime=1277791466 ## RTP audio socket buffer size: 378 bytes. XX Failed to realize: Server is not responding $$ Profile: instantiation: 0 ms ## Player created: com.sun.media.content.unknown.Handler at 747fa2 ## using DataSource: com.sun.media.protocol.rtp.DataSource at 1be16f5 $$ Profile: parsing: 16 ms ## Building flow graph for: null ## Building Track: 0 ## Input: mpegaudio/rtp, 44100.0 Hz, 16-bit, Stereo, LittleEndian, Signed ## Here's the completed flow graph: com.sun.media.parser.RawBufferParser at 1ae90c connects to: com.sun.media.codec.audio.mpa.DePacketizer at ba4211 format: mpegaudio/rtp, 44100.0 Hz, 16-bit, Stereo, LittleEndian, Signed com.sun.media.codec.audio.mpa.DePacketizer at ba4211 connects to: com.sun.media.codec.audio.mpa.NativeDecoder at 47a0d4 format: mpegaudio, 44100.0 Hz, 16-bit, Stereo, Signed com.sun.media.codec.audio.mpa.NativeDecoder at 47a0d4 connects to: com.sun.media.renderer.audio.DirectAudioRenderer at 55bb93 format: LINEAR, 44100.0 Hz, 16-bit, Stereo, BigEndian, Signed $$ Profile: graph building: 125 ms $$ Profile: realize, post graph building: 16 ms -------------------------------------------------------------------------------------------------------------------------- Is there anyone who has an idea what must be corrected or is there anyone who dealed the same problem (browser rtp player+live server) and is able to share solution? Thanks for response. Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070116/c59fb1cb/attachment-0001.html From finlayson at live555.com Tue Jan 16 06:18:22 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jan 2007 06:18:22 -0800 Subject: [Live-devel] Compilation failure on cygwin (live-2007.01.11.tar.gz) In-Reply-To: References: Message-ID: >Hi, > >I sent a mail on the cygwin list >(http://cygwin.com/ml/cygwin/2007-01/msg00516.html) and they have >agreed to make a change for this. Thanks for following up on this. > However, there is not commited date >for the change. In the meanwhile, it may make sense to use a compile >time #define to solve the problem. Perhaps, although such a 'fix' will break in the future, when the Cygwin header files start defining "ip_mreq_source" themselves. I'll probably go ahead and do this, though, and add a comment asking people to notify us by email when it breaks :-) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From hartman at videolan.org Tue Jan 16 06:45:36 2007 From: hartman at videolan.org (Derk-Jan Hartman) Date: Tue, 16 Jan 2007 15:45:36 +0100 Subject: [Live-devel] [vlc-devel] VLC RTSP client support for Transport Stream 'trick play' operations In-Reply-To: References: Message-ID: On 12-jan-2007, at 21:14, Ross Finlayson wrote: > FYI, the LIVE555 RTSP server implementation now supports trick play > operations (seeking, fast forward, reverse play) on MPEG Transport > Stream files. Note, for example, our new 'media server' > application: http://www.live555.com/mediaServer/ > > However, VLC - when playing these streams as a RTSP client - > currently does not perform these trick play operations correctly > from its GUI. Note that the LIVE555 RTSP client library fully > supports trick play operations (note the optional "start", "end" > and "scale" parameters to "RTSPClient::playMediaSession()"); it's > just that VLC does not pass these parameters (in particular, > "scale") when calling the library. > > Could someone please take a look at this? I suspect that a fix > will be quite straightforward, and will give VLC important new > functionality - basically, client support for VOD with trick play. > > It's important to note that - apart from the GUI, and the > parameters passed to "RTSPClient::playMediaSession()" in the > LIVE555 library - the fact that the server is performing a 'trick > play' operation is completely transparent to the VLC client. I.e., > VLC's rendering code will continue to see what it thinks is a > regular Transport Stream - with no discontinuity in PCR timestamps > - so you won't need to make any changes there. can we please not use the term "trickplay" ?? it's too confusing, spans too many topics etc. To decode: We need to support the optional paramaters start,end,scale of playMediaSession start is only in use atm when you do seeking. (DEMUX_SET_POSITION) Just so i can get a few things clear. 1: if i set start=0, and the sdp specifies a starttime, is this still automatically taken into account? 2: scale: this corresponds to normal FFW, RW functionality correct? not to faster/slower (this would be speed?) 3: is there a way to know wether or not Scale is a supported option by the server ? VLC currently does FFW/RW by simply doing a seek. I need to put the scale func. as a preferred method over the current functionality in the core, which would be some simple additions. Glen Gray should already have some code to start this of as a matter of fact. DJ From glen at lincor.com Tue Jan 16 07:57:45 2007 From: glen at lincor.com (Glen Gray) Date: Tue, 16 Jan 2007 15:57:45 +0000 Subject: [Live-devel] [vlc-devel] Re: VLC RTSP client support for Transport Stream 'trick play' operations In-Reply-To: References: Message-ID: <45ACF5F9.9050905@lincor.com> Derk-Jan Hartman wrote: > > VLC currently does FFW/RW by simply doing a seek. I need to put the > scale func. as a preferred method over the current functionality in the > core, which would be some simple additions. Glen Gray should already > have some code to start this of as a matter of fact. My patches are rather out of date with the current branch and where very much specific to our own implementation requirements with regard to Kasenna servers. We control vlc via the rc interface, and as such most of our interface changes have been done from that perspective. My patches over-rode the rc versions of the fastforward and rewind command to allow you to pass over a speed, 6, 12, 30 for example. If no values where entered, the INPUT_RATE_MAX|MIN values where set based on if fastforward|rewind command was issues. I added a DEMUX_SET_RATE to the livedotcom.cpp Control function. The DEMUX_SET_RATE part of control would look for a passed in i_rate variable. If the i_rate variable was set to INPUT_RATE_MAX it would set a default of 30 (this is Kasenna specific). If it was INPUT_RATE_MIN, it would set a default of -30 (again, Kasenna specific). I also had to add some code to vlc/src/input.c where it deals with the INPUT_CONTROL_SET_RATE_SLOWER|FASTER. It could call demux2_Control with a DEMUX_SET_RATE and check for a return value. If we didn't get a VLC_SUCCESS, it would carry on with the normal RATE control code. In the liveMedia RTSP demuxer, using the media session, it would Pause the stream, set the scale value and offsets and resume playback to enter into Fastforward|Rewind mode. Here's a sample of my code.... case DEMUX_SET_RATE: i_rate = (int)va_arg( args, int ); if( i_rate == INPUT_RATE_MAX ) i_rate = 30; else if( i_rate == INPUT_RATE_MIN ) i_rate = -30; else if( i_rate == INPUT_RATE_DEFAULT || i_rate == 0 ) i_rate = 1; //First of all we need to Pause the stream if( !p_sys->rtsp->pauseMediaSession( *p_sys->ms ) ) { msg_Err( p_demux, "PAUSE failed %s", p_sys->env->getResultMsg() ); return VLC_EGENERIC; } //Passing -1 for the start and end time will mean liveMedia won't //create a Range: section for the RTSP message. Server should pick //up from current position. if( ( !p_sys->rtsp->playMediaSession( *p_sys->ms, -1, -1, i_rate ) ) ) { msg_Err( p_demux, "PLAY with Scale %d failed %s", i_rate, p_sys->env->getResultMsg() ); return VLC_EGENERIC; } /* Resync the stream */ p_sys->i_start = (mtime_t)(f * (double)p_sys->i_length); p_sys->i_pcr_start = 0; p_sys->i_pcr = 0; es_out_Control( p_demux->out, ES_OUT_RESET_PCR ); return VLC_SUCCESS; There was of course plenty of other pieces to the puzzle to get this to work, starting Dermot McGahon initially working with Derk-jan and Ross to get Kasenna playback and the foundations for the Scale support into liveMedia. All of which Ross has included in the liveMedia codebase as we've made submissions. As stated, my patches are against a rather old version of VLC trunk. Dermot had made a push before Xmas to get as many of our patches accepted upstream and it's been left to me to get our trickplay support upstream too. Although, recently I've had far too much on project wise to even attempt this, I'm in a position now where at least I can spend some personal time on it in the evenings if work is too loaded (which it usually is) We've been very keen to contribute this support back to VLC and liveMedia. -- Glen Gray Digital Depot, Thomas Street Senior Software Engineer Dublin 8, Ireland Lincor Solutions Ltd. Ph: +353 (0) 1 4893682 From armando at highseascs.com Tue Jan 16 09:29:31 2007 From: armando at highseascs.com (Armando de Oliveira Fortuna) Date: Tue, 16 Jan 2007 11:29:31 -0600 Subject: [Live-devel] rtsp live stream not playing? Message-ID: <002501c73993$e19a9ad0$6702a8c0@rudder> Hi, I am trying to use VLC and openRTSP to capture a live stream coming from our Darwin stream server. Although both programs apparently connect to the server and correctly identify the audio/video format, there appears to be no data flow (after the PLAY) between the server and either program. The messages from both programs are below. Would there be a reason why there is no flow of data between Darwin and the programs? The stream plays fine in Quicktime player. Thanks, Armando VLC: live555 warning: no data received in 10s. Switching to TCP live555 debug: RTP subsession 'audio/MPEG4-GENERIC' live555 debug: RTP subsession 'video/H264' live555 error: no data received in 10s, aborting main debug: EOF reached main debug: closing input main debug: removing module "live555" main debug: removing module "faad" main debug: thread times: real 0m11.316272s, kernel 0m0.000000s, user 0m0.000000s main debug: thread 4020 joined (input/decoder.c:191) main debug: killing decoder fourcc `mp4a', 0 PES in FIFO ffmpeg debug: ffmpeg codec (h264) stopped main debug: removing module "ffmpeg" main debug: thread times: real 0m11.306257s, kernel 0m0.000000s, user 0m0.000000s main debug: thread 4208 joined (input/decoder.c:191) main debug: killing decoder fourcc `h264', 0 PES in FIFO main debug: removing module "packetizer_h264" main debug: thread times: real 0m11.676790s, kernel 0m0.050072s, user 0m0.020028s main debug: thread 3952 joined (input/input.c:412) main: nothing to play Here is the verbose output of openRTSP: openRTSP: C:\Documents and Settings\Armando\Desktop>openRTSP.exe -V rtsp://rack.sansoft.co m/q7.sdp Sending request: OPTIONS rtsp://rack.sansoft.com/q7.sdp RTSP/1.0 CSeq: 1 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2007.01.11) Received OPTIONS response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD Sending request: DESCRIBE rtsp://rack.sansoft.com/q7.sdp RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: openRTSP.exe (LIVE555 Streaming Media v2007.01.11) Received DESCRIBE response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 2 Cache-Control: no-cache Content-length: 703 Date: Tue, 16 Jan 2007 17:23:49 GMT Expires: Tue, 16 Jan 2007 17:23:49 GMT Content-Type: application/sdp x-Accept-Retransmit: our-retransmit x-Accept-Dynamic-Rate: 1 Content-Base: rtsp://rack.sansoft.com/q7.sdp/ Need to read 703 extra bytes Read 703 extra bytes: v=0 o=- 8 2803373983 IN IP4 127.0.0.0 s=QuickTime c=IN IP4 0.0.0.0 t=0 0 a=x-qt-text-an?:iMac Camera a=x-qt-text-pc?:copyright a=x-qt-text-ua?:author a=x-qt-text-ni?:info a=range:npt=now- a=isma-compliance:2,2.0,2 a=control:* m=audio 0 RTP/AVP 96 b=AS:16 a=rtpmap:96 mpeg4-generic/8000/2 a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdelt alength=3;config=1590 a=mpeg4-esid:101 a=control:trackid=1 m=video 0 RTP/AVP 97 b=AS:300 a=rtpmap:97 H264/90000 a=fmtp:97 packetization-mode=1;profile-level-id=4D401E;sprop-parameter-sets=J01A HqkYFwe2ANQYBBrbCte98BA=,KN4JPoA= a=mpeg4-esid:201 a=cliprect:0,0,480,736 a=framesize:97 736-480 a=control:trackid=2 Opened URL "rtsp://rack.sansoft.com/q7.sdp", returning a SDP description: v=0 o=- 8 2803373983 IN IP4 127.0.0.0 s=QuickTime c=IN IP4 0.0.0.0 t=0 0 a=x-qt-text-an?:iMac Camera a=x-qt-text-pc?:copyright a=x-qt-text-ua?:author a=x-qt-text-ni?:info a=range:npt=now- a=isma-compliance:2,2.0,2 a=control:* m=audio 0 RTP/AVP 96 b=AS:16 a=rtpmap:96 mpeg4-generic/8000/2 a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdelt alength=3;config=1590 a=mpeg4-esid:101 a=control:trackid=1 m=video 0 RTP/AVP 97 b=AS:300 a=rtpmap:97 H264/90000 a=fmtp:97 packetization-mode=1;profile-level-id=4D401E;sprop-parameter-sets=J01A HqkYFwe2ANQYBBrbCte98BA=,KN4JPoA= a=mpeg4-esid:201 a=cliprect:0,0,480,736 a=framesize:97 736-480 a=control:trackid=2 Created receiver for "audio/MPEG4-GENERIC" subsession (client ports 1654-1655) Created receiver for "video/H264" subsession (client ports 1658-1659) Sending request: SETUP rtsp://rack.sansoft.com/q7.sdp/trackid=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=1654-1655 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2007.01.11) Received SETUP response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 3 Cache-Control: no-cache Session: 70514773096383 Date: Tue, 16 Jan 2007 17:23:49 GMT Expires: Tue, 16 Jan 2007 17:23:49 GMT Transport: RTP/AVP;unicast;source=72.3.245.197;client_port=1654-1655;server_port =6970-6971 Setup "audio/MPEG4-GENERIC" subsession (client ports 1654-1655) Sending request: SETUP rtsp://rack.sansoft.com/q7.sdp/trackid=2 RTSP/1.0 CSeq: 4 Transport: RTP/AVP;unicast;client_port=1658-1659 Session: 70514773096383 User-Agent: openRTSP.exe (LIVE555 Streaming Media v2007.01.11) Received SETUP response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 4 Session: 70514773096383 Cache-Control: no-cache Date: Tue, 16 Jan 2007 17:23:49 GMT Expires: Tue, 16 Jan 2007 17:23:49 GMT Transport: RTP/AVP;unicast;source=72.3.245.197;client_port=1658-1659;server_port =6970-6971 Setup "video/H264" subsession (client ports 1658-1659) Created output file: "audio-MPEG4-GENERIC-1" Created output file: "video-H264-2" Sending request: PLAY rtsp://rack.sansoft.com/q7.sdp/ RTSP/1.0 CSeq: 5 Session: 70514773096383 Range: npt=0.000- User-Agent: openRTSP.exe (LIVE555 Streaming Media v2007.01.11) Received PLAY response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 5 Session: 70514773096383 Range: npt=now- RTP-Info: url=rtsp://rack.sansoft.com/q7.sdp/trackid=1,url=rtsp://rack.sansoft.c om/q7.sdp/trackid=2 Started playing session Receiving streamed data... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070116/b97e7631/attachment-0001.html From finlayson at live555.com Tue Jan 16 10:30:06 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jan 2007 10:30:06 -0800 Subject: [Live-devel] RTP player in browser In-Reply-To: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> Message-ID: >## outgoing msg: >## PLAY rtsp://172.31.149.238/test.mp3 RTSP/1.0 >CSeq: 379 >Range: npt=0.0- >Session: >User-Agent: JMF RTSP Player Version 2.1.1e > > >## incoming msg: >## RTSP/1.0 200 OK >CSeq: 379 >Date: Tue, Jan 16 2007 11:01:52 GMT >Range: npt=0.000- >Session: 4 >RTP-Info: >url=rtsp://172.31.149.238/test.mp3/track1;seq=35049;rtptime=1277791466 > > >## RTP audio socket buffer size: 378 bytes. > >XX Failed to realize: Server is not responding That's odd - the RTSP protocol exchange looks perfect, but it seems that your JMF client is not receiving the RTP data from our server. Do you have a firewall somewhere between your client and server that could be blocking UDP packets? If so, either turn it off, or ask your JMF client to request RTP-over-TCP streaming. (I don't know anything about JMF, so I don't know how you would do this.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 16 10:35:30 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jan 2007 10:35:30 -0800 Subject: [Live-devel] rtsp live stream not playing? In-Reply-To: <002501c73993$e19a9ad0$6702a8c0@rudder> References: <002501c73993$e19a9ad0$6702a8c0@rudder> Message-ID: >Hi, > > I am trying to use VLC and openRTSP to capture a live >stream coming from our Darwin stream server. > > Although both programs apparently connect to the server >and correctly identify the audio/video format, there appears to be >no data flow (after the PLAY) between the server and either program. > >The messages from both programs are below. Would there be a reason >why there is no flow of data between Darwin and the programs? Do you have a firewall somewhere that could be blocking UDP packets (from the server to the client)? If so, try adding the "-t" option to "openRTSP"; this will request RTP-over-TCP streaming. However, that doesn't explain why VLC did not work for you, because VLC automatically switches to trying RTP-over-TCP streaming if it does not receive RTP-over-UDP packets within 10s. (Your log shows that VLC is doing this.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070116/484c71e7/attachment.html From ckuiper at cisco.com Tue Jan 16 13:23:22 2007 From: ckuiper at cisco.com (Chris Kuiper (ckuiper)) Date: Tue, 16 Jan 2007 13:23:22 -0800 Subject: [Live-devel] openRTSP changes: Capturing H.264 video streams into a file Message-ID: <1D224394D6F39A4AADBFE516AA0BDE660331F62F@xmb-sjc-227.amer.cisco.com> Hi, I am a developer at Cisco Systems and we have recently started using openRTSP to capture video streams into files for quality testing. While MPEG4 capture works well, H.264 captures didn't work as the tool wasn't putting a start_code (0x00000001) between NAL units (NALUs) when writing them to a file. After discussing this with Ross Finlayson, I added a new class 'H264VideoFileSink' to the code that handles inserting of the start_code before writing the frames to file. He suggested I share my code with this group. I attached a zip file with the new code and the touched files and diffs. The later was manually created since I am not using version control for this project (yet). The following files are provided: * H264VideoFileSink.cpp/hh - Implements the new class * playCommon.cpp - added code to use H264VideoFileSink for H.264 file capture * liveMedia.hh - added inclusion of 'H264VideoFileSink.hh' * liveMedia/Makefile.tail - added inclusion of H264VideoFileSink class * diff.txt - contains diffs for playCommon.cpp, liveMedia.hh, and Makefile.tail I am unclear if and how the changes can be added to the code base so it will be available in future openRTSP releases. But if this is going to happen, please keep me informed. Thanks, -- Chris Kuiper -------------- next part -------------- A non-text attachment was scrubbed... Name: changes2.zip Type: application/x-zip-compressed Size: 19155 bytes Desc: changes2.zip Url : http://lists.live555.com/pipermail/live-devel/attachments/20070116/9ef53bf8/attachment-0001.bin From finlayson at live555.com Tue Jan 16 13:33:17 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jan 2007 13:33:17 -0800 Subject: [Live-devel] openRTSP changes: Capturing H.264 video streams into a file In-Reply-To: <1D224394D6F39A4AADBFE516AA0BDE660331F62F@xmb-sjc-227.amer.cisco.com> References: <1D224394D6F39A4AADBFE516AA0BDE660331F62F@xmb-sjc-227.amer.cisco.com> Message-ID: >I am unclear if and how the changes can be added to the code base so it >will be available in future openRTSP releases. But if this is going to >happen, please keep me informed. Chris, Thanks for the contribution. They will be merged into the released "LIVE555 Streaming Media" code shortly. Ross. From armando at highseascs.com Tue Jan 16 14:05:23 2007 From: armando at highseascs.com (Armando de Oliveira Fortuna) Date: Tue, 16 Jan 2007 16:05:23 -0600 Subject: [Live-devel] rtsp live stream not playing? Message-ID: <000b01c739ba$6b9dc330$6702a8c0@rudder> Hi Ross, Thanks for your suggestion. I tested openrtsp w/ -t and the program downloaded the data :-) Progress! It?s strange, though, because both the server and the client are in the same subnet ? no firewall between them. I then added the ?q option and redirected the output to a file. I manually stopped (Control-C) openrstp after like 10 seconds. The quicktime player could not open the resulting mov file - the player output the following error message: Error -2048: the file is not a move file. Here is the openRTSP log. I tried w/ and w/o passing the width and height in the command line. Note that this is a broadcast. Would this affect the way the quicktime movie is generated? Armando C:\Documents and Settings\Armando\Desktop>openrtsp -V -n -t -q rtsp://rack.sanso ft.com/q7.sdp > x.mov Warning: The -q, -4 or -i option was used, but not -w. Assuming a video width o f 240 pixels Warning: The -q, -4 or -i option was used, but not -h. Assuming a video height of 180 pixels Warning: The -q, -4 or -i option was used, but not -f. Assuming a video frame r ate of 15 frames-per-second Sending request: OPTIONS rtsp://rack.sansoft.com/q7.sdp RTSP/1.0 CSeq: 1 User-Agent: openrtsp (LIVE555 Streaming Media v2007.01.11) Received OPTIONS response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD Sending request: DESCRIBE rtsp://rack.sansoft.com/q7.sdp RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: openrtsp (LIVE555 Streaming Media v2007.01.11) Received DESCRIBE response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 2 Cache-Control: no-cache Content-length: 704 Date: Tue, 16 Jan 2007 21:50:10 GMT Expires: Tue, 16 Jan 2007 21:50:10 GMT Content-Type: application/sdp x-Accept-Retransmit: our-retransmit x-Accept-Dynamic-Rate: 1 Content-Base: rtsp://rack.sansoft.com/q7.sdp/ Need to read 704 extra bytes Read 704 extra bytes: v=0 o=- 12 1504183104 IN IP4 127.0.0.0 s=QuickTime c=IN IP4 0.0.0.0 t=0 0 a=x-qt-text-an?:iMac Camera a=x-qt-text-pc?:copyright a=x-qt-text-ua?:author a=x-qt-text-ni?:info a=range:npt=now- a=isma-compliance:2,2.0,2 a=control:* m=audio 0 RTP/AVP 96 b=AS:16 a=rtpmap:96 mpeg4-generic/8000/2 a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdelt alength=3;config=1590 a=mpeg4-esid:101 a=control:trackid=1 m=video 0 RTP/AVP 97 b=AS:300 a=rtpmap:97 H264/90000 a=fmtp:97 packetization-mode=1;profile-level-id=4D401E;sprop-parameter-sets=J01A HqkYFwe2ANQYBBrbCte98BA=,KN4JPoA= a=mpeg4-esid:201 a=cliprect:0,0,480,736 a=framesize:97 736-480 a=control:trackid=2 Opened URL "rtsp://rack.sansoft.com/q7.sdp", returning a SDP description: v=0 o=- 12 1504183104 IN IP4 127.0.0.0 s=QuickTime c=IN IP4 0.0.0.0 t=0 0 a=x-qt-text-an?:iMac Camera a=x-qt-text-pc?:copyright a=x-qt-text-ua?:author a=x-qt-text-ni?:info a=range:npt=now- a=isma-compliance:2,2.0,2 a=control:* m=audio 0 RTP/AVP 96 b=AS:16 a=rtpmap:96 mpeg4-generic/8000/2 a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdelt alength=3;config=1590 a=mpeg4-esid:101 a=control:trackid=1 m=video 0 RTP/AVP 97 b=AS:300 a=rtpmap:97 H264/90000 a=fmtp:97 packetization-mode=1;profile-level-id=4D401E;sprop-parameter-sets=J01A HqkYFwe2ANQYBBrbCte98BA=,KN4JPoA= a=mpeg4-esid:201 a=cliprect:0,0,480,736 a=framesize:97 736-480 a=control:trackid=2 Created receiver for "audio/MPEG4-GENERIC" subsession (client ports 3822-3823) Created receiver for "video/H264" subsession (client ports 3824-3825) Sending request: SETUP rtsp://rack.sansoft.com/q7.sdp/trackid=1 RTSP/1.0 CSeq: 3 Transport: RTP/AVP/TCP;unicast;interleaved=0-1 User-Agent: openrtsp (LIVE555 Streaming Media v2007.01.11) Received SETUP response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 3 Cache-Control: no-cache Session: 14160507189352 Date: Tue, 16 Jan 2007 21:50:10 GMT Expires: Tue, 16 Jan 2007 21:50:10 GMT Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Setup "audio/MPEG4-GENERIC" subsession (client ports 3822-3823) Sending request: SETUP rtsp://rack.sansoft.com/q7.sdp/trackid=2 RTSP/1.0 CSeq: 4 Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Session: 14160507189352 User-Agent: openrtsp (LIVE555 Streaming Media v2007.01.11) Received SETUP response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 4 Session: 14160507189352 Cache-Control: no-cache Date: Tue, 16 Jan 2007 21:50:10 GMT Expires: Tue, 16 Jan 2007 21:50:10 GMT Transport: RTP/AVP/TCP;unicast;interleaved=2-3 Setup "video/H264" subsession (client ports 3824-3825) Sending request: PLAY rtsp://rack.sansoft.com/q7.sdp/ RTSP/1.0 CSeq: 5 Session: 14160507189352 Range: npt=0.000- User-Agent: openrtsp (LIVE555 Streaming Media v2007.01.11) Received PLAY response: RTSP/1.0 200 OK Server: DSS/5.5.4 (Build/489.13; Platform/Win32; Release/Darwin; ) Cseq: 5 Session: 14160507189352 Range: npt=now- RTP-Info: url=rtsp://rack.sansoft.com/q7.sdp/trackid=1,url=rtsp://rack.sansoft.c om/q7.sdp/trackid=2 Started playing session Receiving streamed data... Data packets have begun arriving [113668125] ^C -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070116/c102b073/attachment-0001.html From finlayson at live555.com Tue Jan 16 15:24:27 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 16 Jan 2007 15:24:27 -0800 Subject: [Live-devel] rtsp live stream not playing? In-Reply-To: <000b01c739ba$6b9dc330$6702a8c0@rudder> References: <000b01c739ba$6b9dc330$6702a8c0@rudder> Message-ID: >I then added the -q option and redirected the output to a file. I >manually stopped (Control-C) openrstp after like 10 seconds. You can't do that, because to properly complete writing a ".mov" (or ".mp4") file, the program needs to exit cleanly. Instead, use the "-e " option, or kill the application with "kill -HUP". >Here is the openRTSP log. I tried w/ and w/o passing the width and >height in the command line. If you don't pass the correct video width, height, and frame rate, the resulting ".mov" file is unlikely to play correctly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070116/92ce75a7/attachment.html From zjuchenjun at hotmail.com Tue Jan 16 18:35:24 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Wed, 17 Jan 2007 10:35:24 +0800 Subject: [Live-devel] "createNewStreamSource()" member function Message-ID: Hi ROSS, Thanks for your reply! I had defined "H264VideoStreamDiscreteFramer" to be a subclass of ""H264VideoStreamFramer".And the class "H264VideoStreamDiscreteFramer" included two member function(I read your reply in maillist):void H264VideoStreamDiscreteFramer::doGetNextFrame(), Boolean H264VideoStreamDiscreteFramer::currentNALUnitEndsAccessUnit(). Is it right ? According to your reply, I rewrite my code like this : //************************************************************************************************************************************//FramedSource* H264VideoLiveServerMediaSubsession::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 320; // kbps, estimate ; see my notebook // Create the video source:H264VideoStreamDiscreteFramer *liveSource =H264VideoStreamDiscreteFramer::createNew(*env_H264, NULL, buffers_H264, length_H264, bufferhasitem_H264, mutex_H264); if (liveSource == NULL) return NULL; return liveSource; }//***********************************************************************************************************************************// Is it right? Date: Tue, 16 Jan 2007 06:13:07 -0800To: live-devel at ns.live555.comFrom: finlayson at live555.comSubject: Re: [Live-devel] "createNewStreamSource()" member function return H264VideoStreamFramer::createNew(envir(),liveSource); You can't do this, because "H264VideoStreamFramer" is a virtual base class. Instead, you should define your own class "H263VideoStreamDiscreteFramer" to be a subclass of ""H264VideoStreamFramer". Then, your "H263VideoStreamDiscreteFramer" object can be the value returned by your implementation of "createNewStreamSource()".-- Ross FinlaysonLive Networks, Inc.http://www.live555.com/ _________________________________________________________________ Windows Live Safety Center ?????????????????? http://safety.live.com/site/ZH-CN/default.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070116/fabd8873/attachment.html From phujka at gmail.com Wed Jan 17 00:24:41 2007 From: phujka at gmail.com (Hujka Petr) Date: Wed, 17 Jan 2007 09:24:41 +0100 Subject: [Live-devel] RTP player in browser In-Reply-To: References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> Message-ID: <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> Srvr is not blocking anything, because vlc client works perfect. My conclusion is the same as yours, something is wrong with RTP. Idea of TCP transmittion is great, i will take look on it. Thx a lot. P 2007/1/16, Ross Finlayson : > > >## outgoing msg: > >## PLAY rtsp://172.31.149.238/test.mp3 RTSP/1.0 > >CSeq: 379 > >Range: npt=0.0- > >Session: > >User-Agent: JMF RTSP Player Version 2.1.1e > > > > > >## incoming msg: > >## RTSP/1.0 200 OK > >CSeq: 379 > >Date: Tue, Jan 16 2007 11:01:52 GMT > >Range: npt=0.000- > >Session: 4 > >RTP-Info: > >url=rtsp://172.31.149.238/test.mp3/track1;seq=35049;rtptime=1277791466 > > > > > >## RTP audio socket buffer size: 378 bytes. > > > >XX Failed to realize: Server is not responding > > That's odd - the RTSP protocol exchange looks perfect, but it seems > that your JMF client is not receiving the RTP data from our server. > > Do you have a firewall somewhere between your client and server that > could be blocking UDP packets? If so, either turn it off, or ask > your JMF client to request RTP-over-TCP streaming. (I don't know > anything about JMF, so I don't know how you would do this.) > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070117/cca40d5d/attachment.html From finlayson at live555.com Wed Jan 17 01:21:24 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Jan 2007 01:21:24 -0800 Subject: [Live-devel] RTP player in browser In-Reply-To: <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> Message-ID: >Srvr is not blocking anything, because vlc client works perfect Note that VLC automatically switches to requesting RTP-over-TCP if RTP-over-UDP does not work (i.e., if no UDP packets are received within 10s). So it's still conceivable that you have a firewall somewhere that's blocking UDP. You can test this by running "openRTSP" - first without, and then with the "-t" option. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From phujka at gmail.com Wed Jan 17 06:25:41 2007 From: phujka at gmail.com (Hujka Petr) Date: Wed, 17 Jan 2007 15:25:41 +0100 Subject: [Live-devel] RTP player in browser In-Reply-To: References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> Message-ID: <88b09ad40701170625h67875ab4q84bec642d1d7878c@mail.gmail.com> Both possibilities are working: -openrtsp address -openrtsp - t address Please correct me, if i'm wrong: It doesn't matter if my Java client is receiving over TCP or UDP, because LIVE srvr automaticaly switches between those protocol...? Or i must send some information to srvr to tell him to switch between UDP or TCP??? Thx for responses. Petr 2007/1/17, Ross Finlayson : > > >Srvr is not blocking anything, because vlc client works perfect > > Note that VLC automatically switches to requesting RTP-over-TCP if > RTP-over-UDP does not work (i.e., if no UDP packets are received > within 10s). So it's still conceivable that you have a firewall > somewhere that's blocking UDP. > > You can test this by running "openRTSP" > - first without, and then with the > "-t" option. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070117/5812979c/attachment.html From finlayson at live555.com Wed Jan 17 09:22:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Jan 2007 09:22:23 -0800 Subject: [Live-devel] RTP player in browser In-Reply-To: <88b09ad40701170625h67875ab4q84bec642d1d7878c@mail.gmail.com> References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> <88b09ad40701170625h67875ab4q84bec642d1d7878c@mail.gmail.com> Message-ID: >Both possibilities are working: >-openrtsp address >-openrtsp - t address OK, that shows that you don't have a firewall problem, and that (instead) some problem with your Java RTSP client is preventing incoming RTP/UDP packets from being received. >Please correct me, if i'm wrong: It doesn't matter if my Java client >is receiving over TCP or UDP, because LIVE srvr automaticaly >switches between those protocol...? Or i must send some information >to srvr to tell him to switch between UDP or TCP??? No, the choice of receiving RTP-over-UDP or RTP-over-TCP is made by the client, in the RTSP "SETUP" operation. See the RTSP specification. Unfortunately, because you're not using our code to develop your RTSP client, we can't give you a whole lot of help (as I'm not an expert on Java, and don't know much about the JMF). Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From drobbins at fsmlabs.com Wed Jan 17 09:50:49 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Wed, 17 Jan 2007 10:50:49 -0700 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] Message-ID: <45AE61F9.9070705@fsmlabs.com> bumping this back over to the list... Hi Ross, This patch does fix the problem, and the test indexing program runs correctly on PowerPC and generates an scaled output .ts file that is valid and can be played back. However, there *may* be some lingering issue as the .tsx files generated on x86 and ppc still don't have identical md5sums, even though everything seems to work: # cmp out.tsx ppc-out.tsx out.tsx ppc-out.tsx differ: char 3010036, line 9315 As you can see, the binary difference appears about 3MB into the file. The index files are around 8MB total. Let me know if you think there is still an outstanding issue or not. Regards, Daniel Ross Finlayson wrote: > OK, thanks. > > I think I've found the problem now. Try changing line 41 of > "liveMedia/MPEG2IndexFromTransportStream.cpp" from > void setFirstFlag() { *(u_int8_t*)&fRecordType |= 0x80; } > to > void setFirstFlag() { fRecordType = > (RecordType)(((u_int8_t)fRecordType) | 0x80); } > then run > make; cd ../testProgs; make MPEG2TransportStreamIndexer > and try creating the index file once again on a PowerPC. Let me know > if it now turns out the same as the x86 version. From drobbins at fsmlabs.com Wed Jan 17 09:57:50 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Wed, 17 Jan 2007 10:57:50 -0700 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: <45AE61F9.9070705@fsmlabs.com> References: <45AE61F9.9070705@fsmlabs.com> Message-ID: <45AE639E.8050809@fsmlabs.com> Ross, This looks like an off-by-one error. I ran "cmp -lb x86-out.tsx ppc-out.tsx" and am attaching the output to this email. There are 257 off-by-one differences between the x86 and ppc index files. Regards, Daniel Daniel Robbins wrote: > bumping this back over to the list... > > Hi Ross, > > This patch does fix the problem, and the test indexing program runs > correctly on PowerPC and generates an scaled output .ts file that is > valid and can be played back. However, there *may* be some lingering > issue as the .tsx files generated on x86 and ppc still don't have > identical md5sums, even though everything seems to work: > > # cmp out.tsx ppc-out.tsx > out.tsx ppc-out.tsx differ: char 3010036, line 9315 > > As you can see, the binary difference appears about 3MB into the file. > The index files are around 8MB total. > > Let me know if you think there is still an outstanding issue or not. > > Regards, > > Daniel > > Ross Finlayson wrote: >> OK, thanks. >> >> I think I've found the problem now. Try changing line 41 of >> "liveMedia/MPEG2IndexFromTransportStream.cpp" from >> void setFirstFlag() { *(u_int8_t*)&fRecordType |= 0x80; } >> to >> void setFirstFlag() { fRecordType = >> (RecordType)(((u_int8_t)fRecordType) | 0x80); } >> then run >> make; cd ../testProgs; make MPEG2TransportStreamIndexer >> and try creating the index file once again on a PowerPC. Let me know >> if it now turns out the same as the x86 version. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: out.txt.bz2 Type: application/octet-stream Size: 1170 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070117/e5eb2096/attachment-0001.obj From finlayson at live555.com Wed Jan 17 11:48:22 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 17 Jan 2007 11:48:22 -0800 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: <45AE639E.8050809@fsmlabs.com> References: <45AE61F9.9070705@fsmlabs.com> <45AE639E.8050809@fsmlabs.com> Message-ID: >Ross, > >This looks like an off-by-one error. I ran "cmp -lb x86-out.tsx >ppc-out.tsx" and am attaching the output to this email. There are >257 off-by-one differences between the x86 and ppc index files. This is very odd - the 'off by one' errors all occur where the index file references a particular (188 byte) 'packet' within the original Transport Stream file. At first glance, I don't see how this can happen if the indexing code is run with identical original Transport Stream files. Are you *sure* that the original Transport Stream files - used to generate the index files - are identical on your x86 and ppc computers? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From drobbins at fsmlabs.com Wed Jan 17 12:32:28 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Wed, 17 Jan 2007 13:32:28 -0700 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: References: <45AE61F9.9070705@fsmlabs.com> <45AE639E.8050809@fsmlabs.com> Message-ID: <45AE87DC.3090806@fsmlabs.com> Ross Finlayson wrote: >> Ross, >> >> This looks like an off-by-one error. I ran "cmp -lb x86-out.tsx >> ppc-out.tsx" and am attaching the output to this email. There are >> 257 off-by-one differences between the x86 and ppc index files. >> > > This is very odd - the 'off by one' errors all occur where the index > file references a particular (188 byte) 'packet' within the original > Transport Stream file. At first glance, I don't see how this can > happen if the indexing code is run with identical original Transport > Stream files. > > Are you *sure* that the original Transport Stream files - used to > generate the index files - are identical on your x86 and ppc > computers? > Yes, the original .ts files are identical - md5sums match. Regards, Daniel From drobbins at fsmlabs.com Wed Jan 17 12:43:34 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Wed, 17 Jan 2007 13:43:34 -0700 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: <45AE87DC.3090806@fsmlabs.com> References: <45AE61F9.9070705@fsmlabs.com> <45AE639E.8050809@fsmlabs.com> <45AE87DC.3090806@fsmlabs.com> Message-ID: <45AE8A76.3030107@fsmlabs.com> Hi Ross, Now that I think about it, I *did* start from an original .mpg file, and generated .ts files from these on the respective host machines. But I compared md5sums along the way, and I remember them matching. I can try again to make sure that I did this correctly. -Daniel Daniel Robbins wrote: > Ross Finlayson wrote: > >>> Ross, >>> >>> This looks like an off-by-one error. I ran "cmp -lb x86-out.tsx >>> ppc-out.tsx" and am attaching the output to this email. There are >>> 257 off-by-one differences between the x86 and ppc index files. >>> >>> >> This is very odd - the 'off by one' errors all occur where the index >> file references a particular (188 byte) 'packet' within the original >> Transport Stream file. At first glance, I don't see how this can >> happen if the indexing code is run with identical original Transport >> Stream files. >> >> Are you *sure* that the original Transport Stream files - used to >> generate the index files - are identical on your x86 and ppc >> computers? >> >> > Yes, the original .ts files are identical - md5sums match. > > Regards, > > Daniel > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From drobbins at fsmlabs.com Wed Jan 17 13:02:49 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Wed, 17 Jan 2007 14:02:49 -0700 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: References: <45AE61F9.9070705@fsmlabs.com> <45AE639E.8050809@fsmlabs.com> Message-ID: <45AE8EF9.8050501@fsmlabs.com> Ross, I've confirmed that the indexer was run against identical .ts files. These .ts files were created by the testMPEG1or2ProgramToTransportStream executable, run once each on x86 and ppc. However, the resultant .ts files had identical md5sums, so no problems there. The indexer did not produce identical .tsx indexes from the identical .ts files - the resultant .tsx files differed by small values in 257 distinct locations. The binary difference between the differing bytes ranges from -1 to +3, if that helps. Regards, Daniel Ross Finlayson wrote: >> Ross, >> >> This looks like an off-by-one error. I ran "cmp -lb x86-out.tsx >> ppc-out.tsx" and am attaching the output to this email. There are >> 257 off-by-one differences between the x86 and ppc index files. >> > > This is very odd - the 'off by one' errors all occur where the index > file references a particular (188 byte) 'packet' within the original > Transport Stream file. At first glance, I don't see how this can > happen if the indexing code is run with identical original Transport > Stream files. > > Are you *sure* that the original Transport Stream files - used to > generate the index files - are identical on your x86 and ppc > computers? > From zjuchenjun at hotmail.com Wed Jan 17 20:58:39 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Thu, 18 Jan 2007 12:58:39 +0800 Subject: [Live-devel] "createNewStreamSource()" member function Message-ID: Hi Ross, I want to ask another question before you answer my previous question :) In DeviceSource::doGetNextFrame() ,it mentiond a "non-blocking fashion ", I read the maillist and write my own code ,but it doesn't work. Where is my fault? Thanks in advance. void H264VideoStreamDiscreteFramer::doGetNextFrame() { //**************************non-blocking fashion**************************//while(1){ envforH264->taskScheduler().doEventLoop(HasItemForH264); pthread_mutex_lock(&mutexforH264); if(*HasItemForH264==99) { deliverFrame(); * HasItemForH264=0; } pthread_mutex_unlock(&mutexforH264); sleep(1); } //if (0 /* the source stops being readable */) { // handleClosure(this); // return; // } } From: zjuchenjun at hotmail.comTo: live-devel at ns.live555.comDate: Wed, 17 Jan 2007 10:35:24 +0800Subject: Re: [Live-devel] "createNewStreamSource()" member function Hi ROSS,Thanks for your reply!I had defined "H264VideoStreamDiscreteFramer" to be a subclass of ""H264VideoStreamFramer".And the class "H264VideoStreamDiscreteFramer" included two member function(I read your reply in maillist):void H264VideoStreamDiscreteFramer::doGetNextFrame(), Boolean H264VideoStreamDiscreteFramer::currentNALUnitEndsAccessUnit().Is it right ? According to your reply, I rewrite my code like this : //************************************************************************************************************************************//FramedSource* H264VideoLiveServerMediaSubsession::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 320; // kbps, estimate ; see my notebook // Create the video source:H264VideoStreamDiscreteFramer *liveSource =H264VideoStreamDiscreteFramer::createNew(*env_H264, NULL, buffers_H264, length_H264, bufferhasitem_H264, mutex_H264); if (liveSource == NULL) return NULL; return liveSource; }//***********************************************************************************************************************************// Is it right? Date: Tue, 16 Jan 2007 06:13:07 -0800To: live-devel at ns.live555.comFrom: finlayson at live555.comSubject: Re: [Live-devel] "createNewStreamSource()" member function return H264VideoStreamFramer::createNew(envir(),liveSource); You can't do this, because "H264VideoStreamFramer" is a virtual base class. Instead, you should define your own class "H263VideoStreamDiscreteFramer" to be a subclass of ""H264VideoStreamFramer". Then, your "H263VideoStreamDiscreteFramer" object can be the value returned by your implementation of "createNewStreamSource()".-- Ross FinlaysonLive Networks, Inc.http://www.live555.com/ ???? Windows Live Mail? Windows Live Mail _________________________________________________________________ Windows Live Safety Center ?????????????????? http://safety.live.com/site/ZH-CN/default.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070117/fb23f9da/attachment.html From ritsgenx at gmail.com Wed Jan 17 22:49:00 2007 From: ritsgenx at gmail.com (Ritesh Mittal) Date: Thu, 18 Jan 2007 12:19:00 +0530 Subject: [Live-devel] Maximum number of client connections Live555 can handle ??? In-Reply-To: <3cc3561f0701152154l1c521566wa18e9c6f0d6a2d1d@mail.gmail.com> References: <3cc3561f0701152154l1c521566wa18e9c6f0d6a2d1d@mail.gmail.com> Message-ID: Hi, I have tested rigrously to find out the reason that why Live555 server stops servering large number of clients. The architecture of Live555 is like that in the class BasicTaskScheduler, function ** * void BasicTaskScheduler::SingleStep(unsigned maxDelayTime)* identifies the active socket and then serve the clinet connected to that socket accordinly. I have observed that if there exist any delay in serving any client the client stops playing the current stream and we need to request to play the stream from start (at the client end). This is also true when i debug the live555 server code. Since the control of the server gets delay because of my break point, the client stops sending any request to the server. I would like to request Ross to test the performance of Live555 at your labs. Because i guess when the large number of clients simultaneously request for streaming the server can't respond with the desired frequency. Regards, Ritesh Mittal On 1/16/07, Morgan T?rvolt wrote: > > Have you tried with more that 21 connections? What happens if you > start 30 clients? You could script this by using the openRTSP client. > > -Morgan- > > On 15/01/07, Ritesh Mittal wrote: > > Hi Ross, > > > > I am performing this test on Windows 2000 Server (Standard Edition). The > > maximum limit of opening the same file (with "rb+") mode is 509 . This i > > have tested by writing a test application which returns NULL to fopen > call > > when it has already opened the same file 509 times. > > > > Hence, I guess there is some another reason for my query. > > > > Regards, > > Ritesh Mittal > > > > > > > > > > On 1/15/07, Ross Finlayson wrote: > > > >I tried to test live555 server on a dual processor machine. I > > > >streamed one mpeg-1 file using VLC and real player as clients. > > > >I tried to connect multiple clients (on different machines) to the > > > >same server (requestion for streaming of an mpeg file). But when the > > > >client count reaches 21 the LIVE555 server failed to response for > > > >the new connections. The CPU usage of the server machine was nominal > > > >(8 to 10 percent) . > > > > > > > > > You appear to have run up against an operating system-imposed limit - > > > most likely the number of open files. I.e., it is probably a limit > > > of your operating system, not an inherent limit in the LIVE555 code. > > > You may be able to increase this limit by reconfiguring your > > > operating system in some way. > > > -- > > > > > > Ross Finlayson > > > Live Networks, Inc. > > > http://www.live555.com/ > > > _______________________________________________ > > > live-devel mailing list > > > live-devel at lists.live555.com > > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > > > > > _______________________________________________ > > live-devel mailing list > > live-devel at lists.live555.com > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070117/b6e13142/attachment-0001.html From rmpg2001 at gmail.com Thu Jan 18 04:06:35 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Thu, 18 Jan 2007 13:06:35 +0100 Subject: [Live-devel] Nal Unit Type Message-ID: <389189e20701180406s50275014u9b476c681223491a@mail.gmail.com> Hi all, I create a subclass from H264VideoStreamFramer and I stream some nal units that I extract from a .264 file (that have RAW nal units separate by 00000001. My application send correctly all nal units with nal_unit_type = 5 (coded slice of an IDR picture) and 4, but it doesn't stream 1 (coded slice of a non-IDR picture), 6 (SEI) & 7 (Sequence parameter set). Is there ay filter in H264RTPSink or in another class that does it by default?? I would like to send these types too. Thanks in advance, Ramon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070118/c0529ce8/attachment.html From phujka at gmail.com Thu Jan 18 04:16:16 2007 From: phujka at gmail.com (Hujka Petr) Date: Thu, 18 Jan 2007 13:16:16 +0100 Subject: [Live-devel] RTP player in browser In-Reply-To: References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> <88b09ad40701170625h67875ab4q84bec642d1d7878c@mail.gmail.com> Message-ID: <88b09ad40701180416me754afrd15488dfeee4f68e@mail.gmail.com> Thus with this SETUP message sended by my client: ## outgoing msg: ## SETUP rtsp://172.31.149.238/test.mp3/track1 RTSP/1.0 CSeq: 378 Transport: RTP/AVP;unicast;client_port=46674-46675 User-Agent: JMF RTSP Player Version 2.1.1e should Live srvr switch to UDP? If so, then mistake is probably somewhere else, because LIVE sends everything over UDP, where my client accepts packets....? Please do you have some advice with client for LIVE for web browsers? Thx a lot, you are very helpfull. Petr 2007/1/17, Ross Finlayson : > > >Both possibilities are working: > >-openrtsp address > >-openrtsp - t address > > OK, that shows that you don't have a firewall problem, and that > (instead) some problem with your Java RTSP client is preventing > incoming RTP/UDP packets from being received. > > >Please correct me, if i'm wrong: It doesn't matter if my Java client > >is receiving over TCP or UDP, because LIVE srvr automaticaly > >switches between those protocol...? Or i must send some information > >to srvr to tell him to switch between UDP or TCP??? > > No, the choice of receiving RTP-over-UDP or RTP-over-TCP is made by > the client, in the RTSP "SETUP" operation. See the RTSP > specification. > > Unfortunately, because you're not using our code to develop your RTSP > client, we can't give you a whole lot of help (as I'm not an expert > on Java, and don't know much about the JMF). Sorry. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070118/4650aafc/attachment.html From zjuchenjun at hotmail.com Thu Jan 18 04:25:05 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Thu, 18 Jan 2007 20:25:05 +0800 Subject: [Live-devel] "createNewStreamSource()" member function Message-ID: Hi, I replace "non-blocking fashion " with a "while" sentence like : while(HasItemForH264==0) for experiment; In client, i implemented:[root at localhost ~]# mplayer rtsp://10.13.72.91:8554/H264LiveVideoTest (The result is :) MPlayer 1.0rc1-3.2.3 (C) 2000-2006 MPlayer TeamCPU: Intel(R) Pentium(R) 4 CPU 3.06GHz (Family: 15, Model: 4, Stepping: 9)CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2 Playing rtsp://10.13.72.91:8554/H264LiveVideoTest.Resolving 10.13.72.91 for AF_INET6...Couldn't resolve name for AF_INET6: 10.13.72.91Connecting to server 10.13.72.91[10.13.72.91]: 8554...rtsp_session: unsupported RTSP server. Server type is 'unknown'.STREAM_LIVE555, URL: rtsp://10.13.72.91:8554/H264LiveVideoTestStream not seekable! file format detected.Initiated "video/H264" RTP subsession on port 32770demux_rtp: Guessed the video frame rate as 16 frames-per-second. (If this is wrong, use the "-fps " option instead.)VIDEO: [H264] 0x0 0bpp 16.000 fps 0.0 kbps ( 0.0 kbyte/s)It seems there is no Xvideo support for your video card available.Run 'xvinfo' to verify its Xv support and read DOCS/HTML/en/video.html#xv!See 'mplayer -vo help' for other (non-xv) video out drivers. Try -vo x11==========================================================================Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec familySelected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)==========================================================================Audio: no soundStarting playback...Error while decoding frame![h264 @ 0x87b73f4]non existing PPS referenced[h264 @ 0x87b73f4]decode_slice_header errorError while decoding frame!Error while decoding frame!,?% 0 0[h264 @ 0x87b73f4]non existing PPS referenced[h264 @ 0x87b73f4]decode_slice_header errorError while decoding frame!Error while decoding frame!,?% 0 0Error while decoding frame!,?% 0 0V: 0.1 6/ 6 ??% ??% ??,?% 0 0 Would you please give some suggestions about this result? Thanks very much! From: zjuchenjun at hotmail.comTo: live-devel at ns.live555.comDate: Thu, 18 Jan 2007 12:58:39 +0800Subject: Re: [Live-devel] "createNewStreamSource()" member function Hi Ross, I want to ask another question before you answer my previous question :) In DeviceSource::doGetNextFrame() ,it mentiond a "non-blocking fashion ", I read the maillist and write my own code ,but it doesn't work. Where is my fault? Thanks in advance. void H264VideoStreamDiscreteFramer::doGetNextFrame() { //**************************non-blocking fashion**************************//while(1){ envforH264->taskScheduler().doEventLoop(HasItemForH264); pthread_mutex_lock(&mutexforH264); if(*HasItemForH264==99) { deliverFrame(); * HasItemForH264=0; } pthread_mutex_unlock(&mutexforH264); sleep(1); } //if (0 /* the source stops being readable */) { // handleClosure(this); // return; // } } From: zjuchenjun at hotmail.comTo: live-devel at ns.live555.comDate: Wed, 17 Jan 2007 10:35:24 +0800Subject: Re: [Live-devel] "createNewStreamSource()" member function Hi ROSS,Thanks for your reply!I had defined "H264VideoStreamDiscreteFramer" to be a subclass of ""H264VideoStreamFramer".And the class "H264VideoStreamDiscreteFramer" included two member function(I read your reply in maillist):void H264VideoStreamDiscreteFramer::doGetNextFrame(), Boolean H264VideoStreamDiscreteFramer::currentNALUnitEndsAccessUnit().Is it right ? According to your reply, I rewrite my code like this : //***********************************************************************************************! *************************************//FramedSource* H264VideoLiveServerMediaSubsession::createNewStreamSource(unsigned /*clientSessionId*/, unsigned& estBitrate) { estBitrate = 320; // kbps, estimate ; see my notebook // Create the video source:H264VideoStreamDiscreteFramer *liveSource =H264VideoStreamDiscreteFramer::createNew(*env_H264, NULL, buffers_H264, length_H264, bufferhasitem_H264, mutex_H264); if (liveSource == NULL) return NULL; return liveSource; }//***********************************************************************************************************************************// Is it right? Date: Tue, 16 Jan 2007 06:13:07 -0800To: live-devel at ns.live555.comFrom: finlayson at live555.comSubject: Re: [Live-devel] "createNewStreamSource()" member function return H264VideoStreamFramer::createNew(envir(),liveSource); You can't do this, because "H264VideoStreamFramer" is a virtual base class. Instead, you should define your own class "H263VideoStreamDiscreteFramer" to be a subclass of ""H264VideoStreamFramer". Then, your "H263VideoStreamDiscreteFramer" object can be the value returned by your implementation of "createNewStreamSource()".-- Ross FinlaysonLive Networks, Inc.http://www.live555.com/ ???? Windows Live Mail? Windows Live Mail ???? Windows Live Mail? Windows Live Mail _________________________________________________________________ Windows Live Safety Center ?????????????????? http://safety.live.com/site/ZH-CN/default.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070118/4061524f/attachment.html From kurutepe at nue.tu-berlin.de Thu Jan 18 04:36:11 2007 From: kurutepe at nue.tu-berlin.de (Engin Kurutepe) Date: Thu, 18 Jan 2007 13:36:11 +0100 Subject: [Live-devel] Nal Unit Type In-Reply-To: <389189e20701180406s50275014u9b476c681223491a@mail.gmail.com> References: <389189e20701180406s50275014u9b476c681223491a@mail.gmail.com> Message-ID: <45AF69BB.9080506@nue.tu-berlin.de> I have implemented my own H264VideoStreamFramer for RTP packets output of JVM encoder and did not have such problems. I suspect the problem might be in your code. Engin. Ramon Martin de Pozuelo wrote: > Hi all, > I create a subclass from H264VideoStreamFramer and I stream some nal > units that I extract from a .264 file (that have RAW nal units separate > by 00000001. My application send correctly all nal units with > nal_unit_type = 5 (coded slice of an IDR picture) and 4, but it doesn't > stream 1 (coded slice of a non-IDR picture), 6 (SEI) & 7 (Sequence > parameter set). Is there ay filter in H264RTPSink or in another class > that does it by default?? I would like to send these types too. > > Thanks in advance, > > Ramon > > > ------------------------------------------------------------------------ > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Jan 18 06:07:52 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Jan 2007 06:07:52 -0800 Subject: [Live-devel] RTP player in browser In-Reply-To: <88b09ad40701180416me754afrd15488dfeee4f68e@mail.gmail.com> References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> <88b09ad40701170625h67875ab4q84bec642d1d7878c@mail.gmail.com> <88b09ad40701180416me754afrd15488dfeee4f68e@mail.gmail.com> Message-ID: Are you asking what a RTSP client should do to request that the server send back RTP-over-TCP? If so, then you can figure this out by (i) reading the RTSP specification, (ii) looking at what the "openRTSP" client sends when you run "openRTSP -V -t", and (iii) looking at our RTSP server code (hint: search for "RTP_TCP"). Remember, You Have Complete Source Code, And Full Access To The RTSP Specification (RFC 2326) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From phujka at gmail.com Thu Jan 18 06:42:20 2007 From: phujka at gmail.com (Hujka Petr) Date: Thu, 18 Jan 2007 15:42:20 +0100 Subject: [Live-devel] RTP player in browser In-Reply-To: References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> <88b09ad40701170625h67875ab4q84bec642d1d7878c@mail.gmail.com> <88b09ad40701180416me754afrd15488dfeee4f68e@mail.gmail.com> Message-ID: <88b09ad40701180642r3f82aaf7y8c7e151767895676@mail.gmail.com> No, im asking to this: my client sends in SETUP header "Transport: RTP/AVP;unicast;client_port=46674-46675". Does this means, it's telling to LIVE to transmit over UDP? (I looked to RTSO Specification and it looks like so). If so, does this means, that LIVE starts to transmit over UDP, as with openRTSP? This question is asked because if so, the mistake in JMF is somewhere else. I not, i must probably change SETUP in my Java client to "Transport: RTP/AVP/TCP". Please again, correct me, where i'm wrong. I'm absolutely new on the filed of networking. I would like to use Live555Media Server to transmit indexed media (i'm making face detection and identification in video. that's where i'm home :) ) to the user, which will be able to seek in media file. Liive555MediaServer looks perfect for my needs. Thx a lot for your time. Petr 2007/1/18, Ross Finlayson : > > Are you asking what a RTSP client should do to request that the > server send back RTP-over-TCP? If so, then you can figure this out > by (i) reading the RTSP specification, (ii) looking at what the > "openRTSP" client sends when you run "openRTSP -V -t", and (iii) > looking at our RTSP server code (hint: search for "RTP_TCP"). > > Remember, You Have Complete Source Code, And Full Access To The RTSP > Specification (RFC 2326) > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070118/1dd045f8/attachment.html From finlayson at live555.com Thu Jan 18 06:48:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Jan 2007 06:48:57 -0800 Subject: [Live-devel] RTP player in browser In-Reply-To: <88b09ad40701180642r3f82aaf7y8c7e151767895676@mail.gmail.com> References: <88b09ad40701160614g12b2628w8e1eeba475677d2e@mail.gmail.com> <88b09ad40701170024j6fc1f0e2i30d94b1a25d5db4c@mail.gmail.com> <88b09ad40701170625h67875ab4q84bec642d1d7878c@mail.gmail.com> <88b09ad40701180416me754afrd15488dfeee4f68e@mail.gmail.com> <88b09ad40701180642r3f82aaf7y8c7e151767895676@mail.gmail.com> Message-ID: >No, im asking to this: >my client sends in SETUP header "Transport: >RTP/AVP;unicast;client_port=46674-46675". Does this means, it's >telling to LIVE to transmit over UDP? Yes. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From armando at highseascs.com Thu Jan 18 07:17:15 2007 From: armando at highseascs.com (Armando de Oliveira Fortuna) Date: Thu, 18 Jan 2007 09:17:15 -0600 Subject: [Live-devel] rtsp live stream not playing? Message-ID: <000801c73b13$bc7685d0$6702a8c0@rudder> Hi Ross, Ok, using the -e flag helped :-). Quicktime player was able to play the file. However, a value of 50 for -e resulted in a quicktime movie that was over 7 minutes long. Do you have any idea of why that would be? The video stream is encoded as H.264. Could that cause any problems? Thanks, Armando -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070118/83b0efa5/attachment.html From finlayson at live555.com Thu Jan 18 10:03:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Jan 2007 10:03:20 -0800 Subject: [Live-devel] rtsp live stream not playing? In-Reply-To: <000801c73b13$bc7685d0$6702a8c0@rudder> References: <000801c73b13$bc7685d0$6702a8c0@rudder> Message-ID: >Hi Ross, > > Ok, using the -e flag helped J. Quicktime player was >able to play the file. > However, a value of 50 for -e resulted in a quicktime >movie that was over 7 minutes long. Do you have any idea of why that >would be? Are you sure you specified the correct frame rate (using the "-f " option)? > The video stream is encoded as H.264. Could that cause >any problems? Quite possibly. "QuickTimeFileSink"s support for receiving H.264 video data is suspected to be buggy, unfortunately. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070118/7dd6615b/attachment.html From hartman at videolan.org Thu Jan 18 13:26:41 2007 From: hartman at videolan.org (Derk-Jan Hartman) Date: Thu, 18 Jan 2007 22:26:41 +0100 Subject: [Live-devel] timekeeping in VLC Message-ID: <93DE4C71-5F91-446A-8484-B15B4A9F3E9A@videolan.org> Hi Ross, I was further investigating the problems VLC has with timekeeping on mostly QTSS and DSS streams. As such I was reading Appendix B of the RTSP spec. I'm quite sure we are doing some stuff wrong in VLC and I will fix it. But in order to fix it, I need to retrieve the "sequence number" of the RTP packet and match it against the sequence number mentioned in the RTP-Info field. Is there an easy way to retrieve that last value from liveMedia ? I couldn't find it in the sources, and without that, I can't exactly know from which packet I need to start counting the NPT clock again after play, pause, seek. DJ From finlayson at live555.com Thu Jan 18 14:07:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Jan 2007 14:07:55 -0800 Subject: [Live-devel] timekeeping in VLC In-Reply-To: <93DE4C71-5F91-446A-8484-B15B4A9F3E9A@videolan.org> References: <93DE4C71-5F91-446A-8484-B15B4A9F3E9A@videolan.org> Message-ID: >I was further investigating the problems VLC has with timekeeping on >mostly QTSS and DSS streams. As such I was reading Appendix B of the >RTSP spec. I'm quite sure we are doing some stuff wrong in VLC and I >will fix it. But in order to fix it, I need to retrieve the "sequence >number" of the RTP packet and match it against the sequence number >mentioned in the RTP-Info field. Is there an easy way to retrieve >that last value from liveMedia ? I couldn't find it in the sources, >and without that, I can't exactly know from which packet I need to >start counting the NPT clock again after play, pause, seek. DJ, I'm not totally convinced that you really need the "RTP-Info" header information, because (assuming that RTCP is also being received) the LIVE555 library will continue to generate accurate time-synchronized presentation times (and pass it to the "StreamRead()" function in "live555.cpp"). However, perhaps there is a window of time - after resuming from a pause or seek but before receiving the next RTCP "SR" - in which you need this... In this case, you can get the "RTP-Info" data using "MediaSubsession::struct rtpinfo", and the sequence number of the most recently-received RTP packet using "RTPSource:: curPacketRTPSeqNum()". BTW, if you do a 'seek' within a stream from a DSS/QTSS, then you may be tripping into the following bug (more than two years old) in DSS. (I'm not sure if it has been fixed recently, but I suspect not.) >Date: Wed, 26 Jan 2005 07:46:53 -0800 >To: streaming-server-dev at lists.apple.com >From: Ross Finlayson >Subject: DSS RTP timestamp bug when 'seeking' >Cc: >Bcc: >X-Eudora-Signature: > >The DSS has a significant bug in the way that it handles RTSP 'seek' >operations - i.e., using the RTSP "PLAY" command with a "Range:" >header. It turns out that the DSS (incorrectly) changes its >outgoing RTP timestamps to match the seeking that it performs. > >Suppose, for example, that I "PLAY" a stream (using "Range: >npt=0.000-") for three seconds, and then issue another "PLAY" >command, using "Range: npt=1.000-", i.e., to seek backwards two >seconds, to the one second mark. It turns out that the DSS's >outgoing RTP timestamps also shift backwards two seconds. > >THIS IS WRONG! RFC 3550, section 5.1 specifically says that the RTP >timestamp "MUST be derived from a clock that increases monotonically >and linearly in time". > >The RTP timestamp is supposed to represent the stream's >'presentation time' - i.e., the time when audio or video frames >should be rendered by the receiving client(s). This is independent >of any 'seeking' that may (or may not) have happened within the >underlying media (in the server's file system) in order to generate >the stream. > >(I have tested this with "DSS/5.x (Build/475; Platform/FreeBSD; >Release/Development;") -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From drobbins at fsmlabs.com Thu Jan 18 15:23:27 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Thu, 18 Jan 2007 16:23:27 -0700 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: <45AE8EF9.8050501@fsmlabs.com> References: <45AE61F9.9070705@fsmlabs.com> <45AE639E.8050809@fsmlabs.com> <45AE8EF9.8050501@fsmlabs.com> Message-ID: <45B0016F.4090809@fsmlabs.com> Ross, Any ideas so far on the .tsx index differences? Just trying to figure out whether to certify our current build as "good enough for now" on PowerPC (it *does* appear to work, even with the .tsx files not matching) or whether there might be an upcoming patch in the next few days that I should wait for. Regards, Daniel Daniel Robbins wrote: > Ross, > > I've confirmed that the indexer was run against identical .ts files. > These .ts files were created by the testMPEG1or2ProgramToTransportStream > executable, run once each on x86 and ppc. However, the resultant .ts > files had identical md5sums, so no problems there. > > The indexer did not produce identical .tsx indexes from the identical > .ts files - the resultant .tsx files differed by small values in 257 > distinct locations. The binary difference between the differing bytes > ranges from -1 to +3, if that helps. > > Regards, > > Daniel > > Ross Finlayson wrote: > >>> Ross, >>> >>> This looks like an off-by-one error. I ran "cmp -lb x86-out.tsx >>> ppc-out.tsx" and am attaching the output to this email. There are >>> 257 off-by-one differences between the x86 and ppc index files. >>> >>> >> This is very odd - the 'off by one' errors all occur where the index >> file references a particular (188 byte) 'packet' within the original >> Transport Stream file. At first glance, I don't see how this can >> happen if the indexing code is run with identical original Transport >> Stream files. >> >> Are you *sure* that the original Transport Stream files - used to >> generate the index files - are identical on your x86 and ppc >> computers? >> >> > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From hartman at videolan.org Thu Jan 18 15:43:13 2007 From: hartman at videolan.org (Derk-Jan Hartman) Date: Fri, 19 Jan 2007 00:43:13 +0100 Subject: [Live-devel] timekeeping in VLC In-Reply-To: References: <93DE4C71-5F91-446A-8484-B15B4A9F3E9A@videolan.org> Message-ID: On 18-jan-2007, at 23:07, Ross Finlayson wrote: >> I was further investigating the problems VLC has with timekeeping on >> mostly QTSS and DSS streams. As such I was reading Appendix B of the >> RTSP spec. I'm quite sure we are doing some stuff wrong in VLC and I >> will fix it. But in order to fix it, I need to retrieve the "sequence >> number" of the RTP packet and match it against the sequence number >> mentioned in the RTP-Info field. Is there an easy way to retrieve >> that last value from liveMedia ? I couldn't find it in the sources, >> and without that, I can't exactly know from which packet I need to >> start counting the NPT clock again after play, pause, seek. > > DJ, > > I'm not totally convinced that you really need the "RTP-Info" header > information, because (assuming that RTCP is also being received) the > LIVE555 library will continue to generate accurate time-synchronized > presentation times (and pass it to the "StreamRead()" function in > "live555.cpp"). However, perhaps there is a window of time - after > resuming from a pause or seek but before receiving the next RTCP "SR" > - in which you need this... In this case, you can get the "RTP-Info" > data using "MediaSubsession::struct rtpinfo", and the sequence number > of the most recently-received RTP packet using "RTPSource:: > curPacketRTPSeqNum()". I'll explain further. The only way you can calculate the current NPT, you need to base it on the NPT specified in the PLAY response. However. if you seek, you might still receive RTP data from before the seek. So in order to determine the exact point from which i have to continue updating my NPT counter during playback, i need to know when i'm at the point in the data at which the "response" NPT is reached. As far as i know, i can only do this is by taking the value from the RTP-Info field and compare it to the data seq nr of the currently received data. thanks for the answer, i'll see if i can fix this stuff in VLC. > BTW, if you do a 'seek' within a stream from a DSS/QTSS, then you may > be tripping into the following bug (more than two years old) in DSS. > (I'm not sure if it has been fixed recently, but I suspect not.) I checked the MacWorld stream, and it seems that this stream has continuous PTS timeline wherever I seek. DJ >> Date: Wed, 26 Jan 2005 07:46:53 -0800 >> To: streaming-server-dev at lists.apple.com >> From: Ross Finlayson >> Subject: DSS RTP timestamp bug when 'seeking' >> Cc: >> Bcc: >> X-Eudora-Signature: >> >> The DSS has a significant bug in the way that it handles RTSP 'seek' >> operations - i.e., using the RTSP "PLAY" command with a "Range:" >> header. It turns out that the DSS (incorrectly) changes its >> outgoing RTP timestamps to match the seeking that it performs. >> >> Suppose, for example, that I "PLAY" a stream (using "Range: >> npt=0.000-") for three seconds, and then issue another "PLAY" >> command, using "Range: npt=1.000-", i.e., to seek backwards two >> seconds, to the one second mark. It turns out that the DSS's >> outgoing RTP timestamps also shift backwards two seconds. >> >> THIS IS WRONG! RFC 3550, section 5.1 specifically says that the RTP >> timestamp "MUST be derived from a clock that increases monotonically >> and linearly in time". >> >> The RTP timestamp is supposed to represent the stream's >> 'presentation time' - i.e., the time when audio or video frames >> should be rendered by the receiving client(s). This is independent >> of any 'seeking' that may (or may not) have happened within the >> underlying media (in the server's file system) in order to generate >> the stream. >> >> (I have tested this with "DSS/5.x (Build/475; Platform/FreeBSD; >> Release/Development;") > > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Thu Jan 18 15:54:35 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Jan 2007 15:54:35 -0800 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: <45B0016F.4090809@fsmlabs.com> References: <45AE61F9.9070705@fsmlabs.com> <45AE639E.8050809@fsmlabs.com> <45AE8EF9.8050501@fsmlabs.com> <45B0016F.4090809@fsmlabs.com> Message-ID: >Any ideas so far on the .tsx index differences? No, I can't explain it right now. (As I don't have a big-endian computer around right now to test this on, this may have to be something that you'll need to track down yourself.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From drobbins at fsmlabs.com Thu Jan 18 16:08:18 2007 From: drobbins at fsmlabs.com (Daniel Robbins) Date: Thu, 18 Jan 2007 17:08:18 -0700 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: References: <45AE61F9.9070705@fsmlabs.com> <45AE639E.8050809@fsmlabs.com> <45AE8EF9.8050501@fsmlabs.com> <45B0016F.4090809@fsmlabs.com> Message-ID: <45B00BF2.2090602@fsmlabs.com> Ross Finlayson wrote: >> Any ideas so far on the .tsx index differences? >> > > No, I can't explain it right now. (As I don't have a big-endian > computer around right now to test this on, this may have to be > something that you'll need to track down yourself.) > Could you point me to the particular line of code that is writing those 257 bytes to the index? Regards, Daniel From finlayson at live555.com Thu Jan 18 17:02:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 18 Jan 2007 17:02:55 -0800 Subject: [Live-devel] [Fwd: Re: trick mode index files: x86 and ppc] In-Reply-To: <45B00BF2.2090602@fsmlabs.com> References: <45AE61F9.9070705@fsmlabs.com> <45AE639E.8050809@fsmlabs.com> <45AE8EF9.8050501@fsmlabs.com> <45B0016F.4090809@fsmlabs.com> <45B00BF2.2090602@fsmlabs.com> Message-ID: >Ross Finlayson wrote: >>> Any ideas so far on the .tsx index differences? >>> >> >> No, I can't explain it right now. (As I don't have a big-endian >> computer around right now to test this on, this may have to be >> something that you'll need to track down yourself.) >> >Could you point me to the particular line of code that is writing those >257 bytes to the index? It's all in the file "liveMedia/MPEG2IndexFromTransportStream.cpp". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From armando at highseascs.com Fri Jan 19 08:18:18 2007 From: armando at highseascs.com (Armando de Oliveira Fortuna) Date: Fri, 19 Jan 2007 10:18:18 -0600 Subject: [Live-devel] rtsp live stream not playing? Message-ID: <001001c73be5$6e4edc40$6702a8c0@rudder> Hi Ross, I tested w/ mpeg4 encoding and the resulting .mov file played properly in the Quicktime player. Are there any known issues w/ live555 and mpeg4? If not, then it could be the way to go for us. Thanks, Armando -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070119/3c404bfa/attachment.html From rajeshkumar.r at imimobile.com Fri Jan 19 21:47:38 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Sat, 20 Jan 2007 11:17:38 +0530 Subject: [Live-devel] How to play the files created Message-ID: <00b301c73c56$7e735490$6902000a@imidomain.com> Hi Ross Live555 is creating two files named "video-MP4V-ES-1" and "audio-AMR-2".when i tried to play this file i could not can u tell me how to play these files. Thanks in Advance with Regards Rajesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070119/e76aa688/attachment.html From finlayson at live555.com Fri Jan 19 23:20:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 19 Jan 2007 23:20:01 -0800 Subject: [Live-devel] How to play the files created In-Reply-To: <00b301c73c56$7e735490$6902000a@imidomain.com> References: <00b301c73c56$7e735490$6902000a@imidomain.com> Message-ID: >Hi Ross >Live555 is creating two files named "video-MP4V-ES-1" and >"audio-AMR-2".when i tried to play this file i could not >can u tell me how to play these files. I think that QuickTime Player will be able to play the "audio-AMR-2" file (if you rename it so that its filename ends with ".amr"). However, I don't know of any media player that will be able to play the "video-MP4V-ES-1" file (MPEG-4 Elementary Stream video). Of course, if you use QuickTime Player (instead of "openRTSP") as your RTSP client, then you can play the "rtsp://" URL directly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070119/563f827e/attachment.html From weiyutao36 at 163.com Sat Jan 20 06:24:37 2007 From: weiyutao36 at 163.com (weiyutao36 at 163.com) Date: Sat, 20 Jan 2007 22:24:37 +0800 (CST) Subject: [Live-devel] Nal Unit Type In-Reply-To: <45AF69BB.9080506@nue.tu-berlin.de> References: <45AF69BB.9080506@nue.tu-berlin.de> <389189e20701180406s50275014u9b476c681223491a@mail.gmail.com> Message-ID: <3634013.495651169303077597.JavaMail.coremail@bj163app16.163.com> ?2007-01-18?Engin Kurutepe ??? I have implemented my own H264VideoStreamFramer for RTP packets output of JVM encoder and did not have such problems. I suspect the problem might be in your code. Engin. >>>>May I ask wether you can share your codes written for H.264? In the mail list, this topic had been hotly discussed for some time and I am interested in it. Thank you very much. Yutao Wei -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070120/7381bc43/attachment.html From TAYK0004 at ntu.edu.sg Sun Jan 21 13:46:08 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Mon, 22 Jan 2007 05:46:08 +0800 Subject: [Live-devel] H.264 payload Message-ID: <438567054C073949AEBE5A28B83E7DE133FCB5@MAIL21.student.main.ntu.edu.sg> Hi guys, I have done a simple framer to frame h.264 frames into rtp frame. I am working on the h264streamer and have a few questions. 1) videoSink = h264VideoRTPSink::createNew(*env, &rtpGroupsock, payload); I understand that h.264, unlike h.263, did not have a defined payload format by RTP body. It was mentioned that the payload of h.264 is dynamic. How do I assign the value for the payload in the above statement? 2) VLC (pda) recommended by Ross cannot support raw h.264. I read about the release of Coreplayer Mobile which support raw h.264. Has anyone tried this software before? Many thanks in advance. Regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070121/c86d7a76/attachment.html From finlayson at live555.com Sun Jan 21 15:18:48 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Jan 2007 15:18:48 -0800 Subject: [Live-devel] H.264 payload In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCB5@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCB5@MAIL21.student.main.ntu.edu.sg> Message-ID: >I have done a simple framer to frame h.264 frames into rtp frame. I >am working on the h264streamer and have a few questions. > >1) videoSink = h264VideoRTPSink::createNew(*env, &rtpGroupsock, payload); > >I understand that h.264, unlike h.263, did not have a defined >payload format by RTP body. It was mentioned that the payload of >h.264 is dynamic. How do I assign the value for the payload in the >above statement? It should be some value >= 96, so 96 is a good choice. (Note that if you're implementing a subclass of "OnDemandServerMediaSubsession", then you shouldn't have to care about this, because the 'payloadFormat' parameter to "createNewRTPSink()" virtual function is passed automatically by the "OnDemandServerMediaSubsession" code.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070121/39757434/attachment-0001.html From rajeshkumar.r at imimobile.com Sun Jan 21 20:50:24 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Mon, 22 Jan 2007 10:20:24 +0530 Subject: [Live-devel] How to play the files created References: <00b301c73c56$7e735490$6902000a@imidomain.com> Message-ID: <01e401c73de0$d4051520$6902000a@imidomain.com> Re: [Live-devel] How to play the files createdHi Ross Thanks for reply. How can i use any player in OpenRTSP client to play the recvd streaming content. Thanks in Advance with Regards Rajesh ----- Original Message ----- From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Saturday, January 20, 2007 12:50 PM Subject: Re: [Live-devel] How to play the files created Hi Ross Live555 is creating two files named "video-MP4V-ES-1" and "audio-AMR-2".when i tried to play this file i could not can u tell me how to play these files. I think that QuickTime Player will be able to play the "audio-AMR-2" file (if you rename it so that its filename ends with ".amr"). However, I don't know of any media player that will be able to play the "video-MP4V-ES-1" file (MPEG-4 Elementary Stream video). Of course, if you use QuickTime Player (instead of "openRTSP") as your RTSP client, then you can play the "rtsp://" URL directly. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ ------------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070121/54f9b7ce/attachment.html From finlayson at live555.com Sun Jan 21 22:25:42 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 21 Jan 2007 22:25:42 -0800 Subject: [Live-devel] How to play the files created In-Reply-To: <01e401c73de0$d4051520$6902000a@imidomain.com> References: <00b301c73c56$7e735490$6902000a@imidomain.com> <01e401c73de0$d4051520$6902000a@imidomain.com> Message-ID: >How can i use any player in OpenRTSP client to play the recvd >streaming content. The "openRTSP" client application is not a media player, and is not meant to be used to view streams. Instead, use VLC , which uses the same LIVE555 Streaming Media code, but inside a media player. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070121/98650e39/attachment.html From sademperor at gmail.com Mon Jan 22 01:08:36 2007 From: sademperor at gmail.com (LL Wang) Date: Mon, 22 Jan 2007 17:08:36 +0800 Subject: [Live-devel] Enquire about using LIVE555 for video monitor Message-ID: Hi there, my name is Frank, I found LIVE555 media server on internet and it could be fit for my gra-duate program. However, I get some problem with modifying that. Since the current video source for the lib is a file (maybe *.mpg or *.mp4) physically, but my one is embedded video monitor, therefore I have to replace the file by a real-time video source, like a SDRAM (getting data from a encode chip). So I'll be glad to be notified if there are some online resources to help me solve this problem. Thanks. Cheers, Frank Beijing, China -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070122/c61bc822/attachment.html From finlayson at live555.com Mon Jan 22 01:16:13 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Jan 2007 01:16:13 -0800 Subject: [Live-devel] Enquire about using LIVE555 for video monitor In-Reply-To: References: Message-ID: > >Hi there, my name is Frank, I found LIVE555 media server on internet >and it could be fit for my gra-duate program. However, I get some >problem with modifying that. Since the current video source for the >lib is a file (maybe *.mpg or *.mp4) physically, but my one is >embedded video monitor, therefore I have to replace the file by a >real-time video source, like a SDRAM (getting data from a encode >chip). So I'll be glad to be notified if there are some online >resources to help me solve this problem. Thanks. Please read the "LIVE555 Streaming Media" FAQ: , and, in particular http://www.live555.com/liveMedia/faq.html#liveInput and http://www.live555.com/liveMedia/faq.html#liveInput-unicast You will probably find that one of the demo applications - e.g., "testOnDemandRTSPServer" - will be a better starting point for your application than the "LIVE555 Media Server". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070122/f700a47c/attachment.html From weymar at ibr.cs.tu-bs.de Mon Jan 22 02:39:16 2007 From: weymar at ibr.cs.tu-bs.de (weymar at ibr.cs.tu-bs.de) Date: Mon, 22 Jan 2007 11:39:16 +0100 (CET) Subject: [Live-devel] How to play the files created In-Reply-To: References: <00b301c73c56$7e735490$6902000a@imidomain.com> Message-ID: <1285.134.169.35.207.1169462356.squirrel@mail.ibr.cs.tu-bs.de> Hi, >>Hi Ross >>Live555 is creating two files named "video-MP4V-ES-1" and >>"audio-AMR-2".when i tried to play this file i could not >>can u tell me how to play these files. > > I think that QuickTime Player will be able to play the "audio-AMR-2" > file (if you rename it so that its filename ends with ".amr"). > > However, I don't know of any media player that will be able to play > the "video-MP4V-ES-1" file (MPEG-4 Elementary Stream video). TCPMP is able to play the "video-MP4V-ES-1" file. It only needs the ffmpeg plug-in. regards, Rodrigo > Of course, if you use QuickTime Player (instead of "openRTSP") as > your RTSP client, then you can play the "rtsp://" URL directly. > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/_______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > From shishir at birmiwal.net Mon Jan 22 03:22:56 2007 From: shishir at birmiwal.net (Shishir Birmiwal) Date: Mon, 22 Jan 2007 16:52:56 +0530 Subject: [Live-devel] How to play the files created In-Reply-To: References: <00b301c73c56$7e735490$6902000a@imidomain.com> Message-ID: Hi, > However, I don't know of any media player that will be able to play the > "video-MP4V-ES-1" file (MPEG-4 Elementary Stream video). VLC and mplayer do play it back using ffmpeg. Regards Shishir From weiyutao36 at 163.com Mon Jan 22 04:17:33 2007 From: weiyutao36 at 163.com (weiyutao36 at 163.com) Date: Mon, 22 Jan 2007 20:17:33 +0800 (CST) Subject: [Live-devel] Nal Unit Type In-Reply-To: <45B485E4.1080106@nue.tu-berlin.de> References: <45B485E4.1080106@nue.tu-berlin.de> <45AF69BB.9080506@nue.tu-berlin.de> <389189e20701180406s50275014u9b476c681223491a@mail.gmail.com> <3634013.495651169303077597.JavaMail.coremail@bj163app16.163.com> Message-ID: <17315552.1502711169468253626.JavaMail.coremail@bj163app69.163.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070122/3242fef3/attachment.html From rupert.paget at ocag.ch Mon Jan 22 06:10:00 2007 From: rupert.paget at ocag.ch (Paget Rupert) Date: Mon, 22 Jan 2007 15:10:00 +0100 Subject: [Live-devel] steam duplication Message-ID: Hello, I have an mpeg4 stream (only video) transported via rtsp. I have implemented a sink using openRTSP.cpp from which I can display the output. Everything works. Now I want to take the rtsp stream and duplicate stream over a unicast network. How should I go about this? I want to split the source rtsp stream into 3 output streams. One stream will go to a logger, and requires a time stamp. The others will go to their own display sinks (one over the network). Should I split the rtsp into 3 rtp streams, or udp? What are the possibilities for logging the stream with time stamps (given that the mpeg stream contains its own time stamp)? And how could this logged stream be played back? I have tried looking through the test programs and code, but now I have more questions than answers. Thanks, Rupert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070122/b2458c26/attachment.html From rcourtney at iowadsl.net Mon Jan 22 06:49:03 2007 From: rcourtney at iowadsl.net (rcourtney at iowadsl.net) Date: Mon, 22 Jan 2007 08:49:03 -0600 Subject: [Live-devel] OT: Javascript for Aminocom STB Message-ID: <1169477343.45b4cedfa8c59@virtualmail.avalon.net> Does anyone have a cheat sheet on the Javascript functions specific to Aminocom STBs? I have a few code snipets using: VideoDisplay.SetAphaLevel AVMedia.Play AVMedia.Event AVMedia.SetSpeed AVMedia.Continue Looking for anything to use the new 0.15 trick functions and using fancier menus. From finlayson at live555.com Mon Jan 22 07:20:59 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 22 Jan 2007 07:20:59 -0800 Subject: [Live-devel] OT: Javascript for Aminocom STB In-Reply-To: <1169477343.45b4cedfa8c59@virtualmail.avalon.net> References: <1169477343.45b4cedfa8c59@virtualmail.avalon.net> Message-ID: >Looking for anything to use the new 0.15 trick functions Note that you can do Pause/FF/RW on the Amino STB using its remote controi. You can also seek to an initial starting point by adding ";offset=" to the end of the "rtsp://" URL. (This hack is seen only at the client - i.e., STB end; the server does not get to see the extra string.) Of course, be sure that the Amino STB is configured to use "NCube" mode beforehand. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rupert.paget at ocag.ch Mon Jan 22 08:14:50 2007 From: rupert.paget at ocag.ch (Paget Rupert) Date: Mon, 22 Jan 2007 17:14:50 +0100 Subject: [Live-devel] multi-unicast RTSP/RTP Message-ID: Hello, I want to implement the testRelay.cpp for multi-unicast. In my original configuration I have used openRTSP.cpp to read an rtsp stream and submit it to my own sink. However the testRelay.cpp files reads a UDP stream and sinks it to a UDP sink. How would this filter fit into my original configuration? Should I change testRelay.cpp to read from a RTSP source? And what type of sink should I send it to? Thanks, Rupert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070122/fafd3375/attachment.html From morgan.torvolt at gmail.com Mon Jan 22 22:49:08 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Tue, 23 Jan 2007 10:49:08 +0400 Subject: [Live-devel] Maximum number of client connections Live555 can handle ??? In-Reply-To: References: <3cc3561f0701152154l1c521566wa18e9c6f0d6a2d1d@mail.gmail.com> Message-ID: <3cc3561f0701222249u1e3d941co72a8f2007c776a4e@mail.gmail.com> Hi, How is your 'system' CPU usage when you have all these connections (use 'top')? What about disk troughput? Maybe your disks random access troughput is the limit? The disk read part of live is blocking I believe. Try making a RAM disk that contains the file and see if that makes a difference. Could maybe network troughput be the issue? What happens if you start the 21. client on the server machine? I have some applications with live, and have no major issues running 50+ clients, but that is while using a satellite tuner as source, and some other custom changes. Regards -Morgan- On 18/01/07, Ritesh Mittal wrote: > Hi, > > I have tested rigrously to find out the reason that why Live555 server stops > servering large number of clients. > The architecture of Live555 is like that in the class BasicTaskScheduler, > function > > void BasicTaskScheduler::SingleStep(unsigned maxDelayTime) > > identifies the active socket and then serve the clinet connected to that > socket accordinly. I have observed that if there exist any delay in serving > any client the client stops playing the current stream and we need to > request to play the stream from start (at the client end). > > This is also true when i debug the live555 server code. Since the control of > the server gets delay because of my break point, the client stops sending > any request to the server. > > I would like to request Ross to test the performance of Live555 at your > labs. Because i guess when the large number of clients simultaneously > request for streaming the server can't respond with the desired frequency. > > Regards, > Ritesh Mittal > > > > On 1/16/07, Morgan T?rvolt wrote: > > Have you tried with more that 21 connections? What happens if you > > start 30 clients? You could script this by using the openRTSP client. > > > > -Morgan- > > > > On 15/01/07, Ritesh Mittal wrote: > > > Hi Ross, > > > > > > I am performing this test on Windows 2000 Server (Standard Edition). The > > > maximum limit of opening the same file (with "rb+") mode is 509 . This i > > > have tested by writing a test application which returns NULL to fopen > call > > > when it has already opened the same file 509 times. > > > > > > Hence, I guess there is some another reason for my query. > > > > > > Regards, > > > Ritesh Mittal > > > > > > > > > > > > > > > On 1/15/07, Ross Finlayson < finlayson at live555.com> wrote: > > > > >I tried to test live555 server on a dual processor machine. I > > > > >streamed one mpeg-1 file using VLC and real player as clients. > > > > >I tried to connect multiple clients (on different machines) to the > > > > >same server (requestion for streaming of an mpeg file). But when the > > > > >client count reaches 21 the LIVE555 server failed to response for > > > > >the new connections. The CPU usage of the server machine was nominal > > > > >(8 to 10 percent) . > > > > > > > > > > > > You appear to have run up against an operating system-imposed limit - > > > > most likely the number of open files. I.e., it is probably a limit > > > > of your operating system, not an inherent limit in the LIVE555 code. > > > > You may be able to increase this limit by reconfiguring your > > > > operating system in some way. > > > > -- > > > > > > > > Ross Finlayson > > > > Live Networks, Inc. > > > > http://www.live555.com/ > > > > _______________________________________________ > > > > live-devel mailing list > > > > live-devel at lists.live555.com > > > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > > > > > > > > > _______________________________________________ > > > live-devel mailing list > > > live-devel at lists.live555.com > > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > > > > > > > _______________________________________________ > > live-devel mailing list > > live-devel at lists.live555.com > > http://lists.live555.com/mailman/listinfo/live-devel > > > > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > > > From vd_mail_id at yahoo.com Tue Jan 23 00:02:45 2007 From: vd_mail_id at yahoo.com (vd mail_id) Date: Tue, 23 Jan 2007 00:02:45 -0800 (PST) Subject: [Live-devel] RFC supported 3016 or 3640 ? In-Reply-To: Message-ID: <126043.57764.qm@web59003.mail.re1.yahoo.com> For determining MPEG-4 payload for RTP streaming which RFC standard is followed by Quicktime? I cam across two different standards on internet RFC 3016 and RFC 3640 and need to know which is followed for creating RTP packets? Or are there possibly more RFC / standards defining RTP payload for mpeg-4 and if Quicktime follows some other standard? I know these are newbie questions and I need help in clearing my doubts. Thanks a lot for help --Vikram --------------------------------- Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070123/9d45e1da/attachment-0001.html From finlayson at live555.com Tue Jan 23 00:06:33 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 00:06:33 -0800 Subject: [Live-devel] Maximum number of client connections Live555 can handle ??? In-Reply-To: <3cc3561f0701222249u1e3d941co72a8f2007c776a4e@mail.gmail.com> References: <3cc3561f0701152154l1c521566wa18e9c6f0d6a2d1d@mail.gmail.com> <3cc3561f0701222249u1e3d941co72a8f2007c776a4e@mail.gmail.com> Message-ID: >How is your 'system' CPU usage when you have all these connections >(use 'top')? What about disk troughput? Maybe your disks random access >troughput is the limit? The disk read part of live is blocking I >believe. That's true only for Windows. For Unix (including Linux), file reading is asynchronous. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 23 00:24:30 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 00:24:30 -0800 Subject: [Live-devel] RFC supported 3016 or 3640 ? In-Reply-To: <126043.57764.qm@web59003.mail.re1.yahoo.com> References: <126043.57764.qm@web59003.mail.re1.yahoo.com> Message-ID: >For determining MPEG-4 payload for RTP streaming which RFC standard >is followed by Quicktime? I cam across two different standards on >internet RFC 3016 and RFC 3640 and need to know which is followed >for creating RTP packets? Or are there possibly more RFC / standards >defining RTP payload for mpeg-4 and if Quicktime follows some other >standard? This is not a QuickTime mailing list! However, the "LIVE555 Streaming Media" software (and other standards-compliant streaming media systems, including QuickTime) use RFC 3640 for streaming most AAC audio streams (the "audio/MPEG4-GENERIC" MIME type), but use RFC 3016 (a more specific specification) for MPEG-4 Video streams (the "video/MP4V-ES" MIME type) and for LATM-formatted AAC audio streams (the "audio/MP4A-LATM" MIME type). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rupert.paget at ocag.ch Tue Jan 23 01:31:14 2007 From: rupert.paget at ocag.ch (Paget Rupert) Date: Tue, 23 Jan 2007 10:31:14 +0100 Subject: [Live-devel] testRelay.cpp Message-ID: Hello, How do I use testRelay.cpp on a unicast network to multi-unicast a rtsp mpeg4 live stream when the source is not multicast? Thanks, Rupert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070123/26e5855a/attachment.html From sandgull_1982 at 163.com Tue Jan 23 07:10:47 2007 From: sandgull_1982 at 163.com (=?gb2312?B?wfXNpg==?=) Date: Tue, 23 Jan 2007 23:10:47 +0800 Subject: [Live-devel] openRTSP on different OS Message-ID: <45B62568.03EB8C.32337@m12-14.163.com> Hi,all I streamed a MPG2 video/audio muliplexed file(about 190M) with testOnDemandRTSPServer, and complied the same playCommon code on both XP(VC++) and a STB(embedded linux, g++). I can use openRTSP to get a video and audio file perfectly on XP, but it seems not so perfect on STB, as the gennerated video file has only 70 to 100M. May be many packets were truncated? Who can tell me something about this and how can I solve it? Thanks! best regards, glacier From finlayson at live555.com Tue Jan 23 07:24:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 07:24:23 -0800 Subject: [Live-devel] openRTSP on different OS In-Reply-To: <45B62568.03EB8C.32337@m12-14.163.com> References: <45B62568.03EB8C.32337@m12-14.163.com> Message-ID: > I streamed a MPG2 video/audio muliplexed file(about 190M) >with testOnDemandRTSPServer, and complied the same playCommon code >on both XP(VC++) and a STB(embedded linux, g++). I can use openRTSP >to get a video and audio file perfectly on XP, but it seems not so >perfect on STB, as the gennerated video file has only 70 to 100M. >May be many packets were truncated? Yes, you may have experienced packet loss on your network (does it have enough bandwidth?). You could try adding the "-t" option to "openRTSP", to request streaming via TCP instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From alant at transtelecom.md Tue Jan 23 08:01:31 2007 From: alant at transtelecom.md (Alex Antropoff) Date: Tue, 23 Jan 2007 18:01:31 +0200 Subject: [Live-devel] streaming live channels Message-ID: <20070123160131.GA12369@alant.transtelecom.md> Hello, I need in simple rtsp server which will streams live channels from encoders(they send using multicast). I have sdp for each channel, what I have to modify in mediaServer's code ? -- Regards, Alex Antropoff From asmundg at snap.tv Tue Jan 23 08:29:42 2007 From: asmundg at snap.tv (=?utf-8?q?=C3=85smund_Grammeltvedt?=) Date: Tue, 23 Jan 2007 17:29:42 +0100 Subject: [Live-devel] raw/udp in rtsp multicast setup Message-ID: <200701231729.47453.asmundg@snap.tv> Hi. I noticed that RTSPServer doesn't seem to accept RAW_UDP (RAW/RAW/UDP or MP2T/H2221/UDP) in the Transport header when using a multicast source. I that right? In case it's not, the attached patch inserts a case for RAW_UDP. -- ?smund Grammeltvedt Snap TV -------------- next part -------------- A non-text attachment was scrubbed... Name: multicast_udp.patch Type: text/x-diff Size: 2226 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070123/5af6965b/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070123/5af6965b/attachment-0001.bin From finlayson at live555.com Tue Jan 23 09:06:00 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 09:06:00 -0800 Subject: [Live-devel] streaming live channels In-Reply-To: <20070123160131.GA12369@alant.transtelecom.md> References: <20070123160131.GA12369@alant.transtelecom.md> Message-ID: >Hello, I need in simple rtsp server which will streams >live channels from encoders(they send using multicast). >I have sdp for each channel, what I have to modify in mediaServer's code ? I don't recommend modifying the "LIVE555 Media Server" code for this. Instead, use one of the "test*Streamer" demo applications (in the "testProgs" directory). These already stream via multicast. Also, please read the FAQ for guidance on how to modify these applications to use a live input source. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 23 09:18:00 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 09:18:00 -0800 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: <200701231729.47453.asmundg@snap.tv> References: <200701231729.47453.asmundg@snap.tv> Message-ID: >I noticed that RTSPServer doesn't seem to accept RAW_UDP (RAW/RAW/UDP or >MP2T/H2221/UDP) in the Transport header when using a multicast source. I that >right? In case it's not, the attached patch inserts a case for RAW_UDP. Thanks. This will get included in the next release of the software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From alant at transtelecom.md Tue Jan 23 14:04:04 2007 From: alant at transtelecom.md (Alex Antropoff) Date: Wed, 24 Jan 2007 00:04:04 +0200 Subject: [Live-devel] streaming live channels In-Reply-To: References: <20070123160131.GA12369@alant.transtelecom.md> Message-ID: <20070123220404.GA6466@alant.transtelecom.md> On Tue, Jan 23, 2007 at 09:06:00AM -0800, Ross Finlayson wrote: RF> >Hello, I need in simple rtsp server which will streams RF> >live channels from encoders(they send using multicast). RF> >I have sdp for each channel, what I have to modify in mediaServer's code ? RF> RF> I don't recommend modifying the "LIVE555 Media Server" code for this. RF> Instead, use one of the "test*Streamer" demo applications (in the RF> "testProgs" directory). These already stream via multicast. Also, RF> please read the FAQ for guidance on how to modify these applications RF> to use a live input source. RF> -- Thanks, I found my question in FAQ. -- Regards, Alex Antropoff From alant at transtelecom.md Tue Jan 23 14:04:04 2007 From: alant at transtelecom.md (Alex Antropoff) Date: Wed, 24 Jan 2007 00:04:04 +0200 Subject: [Live-devel] streaming live channels In-Reply-To: References: <20070123160131.GA12369@alant.transtelecom.md> Message-ID: <20070123220404.GA6466@alant.transtelecom.md> On Tue, Jan 23, 2007 at 09:06:00AM -0800, Ross Finlayson wrote: RF> >Hello, I need in simple rtsp server which will streams RF> >live channels from encoders(they send using multicast). RF> >I have sdp for each channel, what I have to modify in mediaServer's code ? RF> RF> I don't recommend modifying the "LIVE555 Media Server" code for this. RF> Instead, use one of the "test*Streamer" demo applications (in the RF> "testProgs" directory). These already stream via multicast. Also, RF> please read the FAQ for guidance on how to modify these applications RF> to use a live input source. RF> -- Thanks, I found my question in FAQ. -- Regards, Alex Antropoff From alant at transtelecom.md Tue Jan 23 14:23:22 2007 From: alant at transtelecom.md (Alex Antropoff) Date: Wed, 24 Jan 2007 00:23:22 +0200 Subject: [Live-devel] streaming live channels In-Reply-To: References: <20070123160131.GA12369@alant.transtelecom.md> Message-ID: <20070123222322.GA6704@alant.transtelecom.md> On Tue, Jan 23, 2007 at 09:06:00AM -0800, Ross Finlayson wrote: RF> >Hello, I need in simple rtsp server which will streams RF> >live channels from encoders(they send using multicast). RF> >I have sdp for each channel, what I have to modify in mediaServer's code ? RF> RF> I don't recommend modifying the "LIVE555 Media Server" code for this. RF> Instead, use one of the "test*Streamer" demo applications (in the RF> "testProgs" directory). These already stream via multicast. Also, RF> please read the FAQ for guidance on how to modify these applications RF> to use a live input source. Hmm. May be I incorrectly describe my task... I have some encoders(vlc), they do transcoding of video streams and send them using multicast(H263/H264+AAC). Each encoder generate it's own sdp. I need in rtsp server which will get source from encoders and send it via unicast to rtsp clients(mobiles). As I understand from testOnDemandRTSPServer.cpp, I must make own xxxMediaSubsession.cpp, f.e. SDPFileMediaSubsession.cpp, which will parse SDP, make 1 or 2 Groupsock objects etc. -- Regards, Alex Antropoff From finlayson at live555.com Tue Jan 23 15:44:29 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 15:44:29 -0800 Subject: [Live-devel] streaming live channels In-Reply-To: <20070123222322.GA6704@alant.transtelecom.md> References: <20070123160131.GA12369@alant.transtelecom.md> <20070123222322.GA6704@alant.transtelecom.md> Message-ID: >Hmm. May be I incorrectly describe my task... >I have some encoders(vlc), they do transcoding of video streams and send them >using multicast(H263/H264+AAC). >Each encoder generate it's own sdp. > >I need in rtsp server which will get source from encoders and send it via >unicast to rtsp clients(mobiles). This seems ridiculously complex. It's silly to have your encoder stream via multicast, only to have this multicast traffic received by another application that then streams via unicast. Instead, just have your encoder feed directly (e.g., using a pipe, via stdout/stdin) to a LIVE555 RTSP server application. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From victor_l2000 at hotmail.com Tue Jan 23 16:43:59 2007 From: victor_l2000 at hotmail.com (Victor Lee) Date: Tue, 23 Jan 2007 16:43:59 -0800 Subject: [Live-devel] How can i set the client to use RAW_UDP? Message-ID: Hi Ross, LiveMedia supports RTP_TCP, RTP_UDP and RAW_UDP, right? When using openRTSP, i know how to set the connection to choose either use RTP_TCP or RTP_UDP for the stream transport between RTSP server and client. But I did not see how to set it with RAW_UDP. Could you please tell me how to do this? Thanks in advance! Victor _________________________________________________________________ Get in the mood for Valentine's Day. View photos, recipes and more on your Live.com page. http://www.live.com/?addTemplate=ValentinesDay&ocid=T001MSN30A0701 From alant at transtelecom.md Tue Jan 23 16:57:22 2007 From: alant at transtelecom.md (Alex Antropoff) Date: Wed, 24 Jan 2007 02:57:22 +0200 Subject: [Live-devel] streaming live channels In-Reply-To: References: <20070123160131.GA12369@alant.transtelecom.md> <20070123222322.GA6704@alant.transtelecom.md> Message-ID: <20070124005722.GA8842@alant.transtelecom.md> On Tue, Jan 23, 2007 at 03:44:29PM -0800, Ross Finlayson wrote: RF> >Hmm. May be I incorrectly describe my task... RF> >I have some encoders(vlc), they do transcoding of video streams and send them RF> >using multicast(H263/H264+AAC). RF> >Each encoder generate it's own sdp. RF> > RF> >I need in rtsp server which will get source from encoders and send it via RF> >unicast to rtsp clients(mobiles). RF> RF> This seems ridiculously complex. It's silly to have your encoder RF> stream via multicast, only to have this multicast traffic received by RF> another application that then streams via unicast. Encoders runs dynamically,allowing load-balancing on >1 host, becides that now I have to use different rtsp servers, because some mobiles use custom sdp format in DESCRIBE. Sometimes one multicast stream used by different rtsp servers. RF> RF> Instead, just have your encoder feed directly (e.g., using a pipe, RF> via stdout/stdin) to a LIVE555 RTSP server application. RF> -- Direct feed will limit me to have one host for encoding and streaming. -- Regards, Alex Antropoff From finlayson at live555.com Tue Jan 23 17:27:29 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 17:27:29 -0800 Subject: [Live-devel] How can i set the client to use RAW_UDP? In-Reply-To: References: Message-ID: >LiveMedia supports RTP_TCP, RTP_UDP and RAW_UDP, right? When using openRTSP, >i know how to set the connection to choose either use RTP_TCP or RTP_UDP for >the stream transport between RTSP server and client. But I did not see how >to set it with RAW_UDP. Could you please tell me how to do this? You can't do this (at least, not without modifying the code), because (i) streaming over raw-UDP is non-standard, (ii) only a few RTSP servers (like ours) support it, and (iii) it can only be used for streaming MPEG Transport Stream data anyway. If you really want to modify the RTSP client code to request this, then you can figure it out by looking at the code; however, I won't be giving you any help here. Instead, you should use regular RTP-over-UDP (or RTP-over-TCP) streaming, because that's the standard. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yunjnz at yahoo.com Tue Jan 23 17:42:05 2007 From: yunjnz at yahoo.com (Sean) Date: Tue, 23 Jan 2007 17:42:05 -0800 (PST) Subject: [Live-devel] About long time wait when server isn't available Message-ID: <754076.72327.qm@web35801.mail.mud.yahoo.com> Greetings, I'm working on a RTSP Client, and I noticed that when the server isn't available (maybe the server not open) but the specified host is available, the sendOptionsCmd will block at the point of the "connect" function called in the RTSPClient::openConnectionFromURL, is it OK for the RTSPClient work under non-blocking mode? Appreciate for your help. Sean. ____________________________________________________________________________________ Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 From finlayson at live555.com Tue Jan 23 18:03:54 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 18:03:54 -0800 Subject: [Live-devel] About long time wait when server isn't available In-Reply-To: <754076.72327.qm@web35801.mail.mud.yahoo.com> References: <754076.72327.qm@web35801.mail.mud.yahoo.com> Message-ID: >is it OK for the RTSPClient work under non-blocking mode? This would be nice to do, but would be a non-trivial change to the code. It might get done someday, but probably not soon. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rishikerala at gmail.com Tue Jan 23 18:40:06 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Wed, 24 Jan 2007 11:40:06 +0900 Subject: [Live-devel] hi all Message-ID: <4ba29cc0701231840g4adb84d8j28eca75e6c859f17@mail.gmail.com> Hi all.. I need a help.. I tried to use the VLC/module/live555.cpp. for porting the live client module for getting mpeg2-ts buffer. I need to get it and want to play using hardware player. Below I added the code where I am getting the some error while running my client application... next: subsession->readSource()->getNextFrame(fBuffer, fileSinkBufferSize, afterGettingFrame,tk, onSourceClosure, tk); rtsptime = timeOutCheck(ourClient); fprintf(stderr,"Timeout check--%d\n",rtsptime); sessionTimerTask = env->taskScheduler().scheduleDelayedTask(300000,(TaskFunc*)TaskInterrupt, subsession/*(void *) NULL*/); //startPlayingStreams(); fprintf(stderr,"Fbuffer-- main--%u\n",(unsigned int)fBuffer); env->taskScheduler().doEventLoop(&task); env->taskScheduler().unscheduleDelayedTask(sessionTimerTask); goto next; When I tried to read second time.. I am getting the error like this.. FramedSource[0x1002ad80]::getNextFrame(): attempting to read more than once at the same time! please help me ... where I need to scratch my head for this... If any one have these cleint module for unicast. To get buffer-- mpeg2ts -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070123/2c00405f/attachment.html From aswin.paranji at gmail.com Tue Jan 23 19:54:13 2007 From: aswin.paranji at gmail.com (Aswin Paranji) Date: Wed, 24 Jan 2007 09:24:13 +0530 Subject: [Live-devel] How to get the Mpeg4 byte Data? Message-ID: Dear Ross, Currently I'm working on developing a windows based viewer for AXIS camera which support RTSP protocol. I have actually gone thru the openrtsp source code i was able to build the application and my camera is streaming the video using the openrtsp test application. In the code i see that 'env->taskScheduler().doEventLoop()' doesnt return but in the console the data's are printed. i have recreated the process on a Dialog based application. i would like to know how i have to actually get the streamed video data and convert it into bitmap so that i can actually paste it on the picture frame. currently we are working on mpeg4 format. Any lead on this would be of a great help to me. if you want i can also send my test application for you to look into the code. Regards, *Aswin.N.Paranji** Senior System Analyst** * *"Everything is possible. The impossible just takes longer."* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070123/baa7aaca/attachment.html From finlayson at live555.com Tue Jan 23 21:55:39 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 21:55:39 -0800 Subject: [Live-devel] How to get the Mpeg4 byte Data? In-Reply-To: References: Message-ID: >Currently I'm working on developing a windows based viewer for AXIS >camera which support RTSP protocol. > >I have actually gone thru the openrtsp source code i was able to >build the application and my camera is streaming the video using the >openrtsp test application. Why reinvent the wheel? I suggest just using the existing VLC media player: . It is Open Source, runs on Windows (and many other OSs), and uses the "LIVE555 Streaming Media" code for its RTSP client implementation. It should be able to play the stream from an Axis camera. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From zhouh31415 at 163.com Tue Jan 23 22:23:42 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Wed, 24 Jan 2007 14:23:42 +0800 (CST) Subject: [Live-devel] I have a question! Message-ID: <449772039.4433061169619822586.JavaMail.coremail@bj163app136.163.com> I can stream transport stream(TS) with RTP/RTCP protocol by livemedia lib now. When I want to stream program stream(PS) using livemedia lib, I found the testprog could only stream elementary stream(ES). And I must split PS into video ES and audio ES and stream them with different port. Vlc , however ,can only play one port. Do you have some methods or testprogs to stream PS directly? The payload type is 96 and payload name is "MP2P"? When I using SimpleRtpSink function to transport the stream data, I found the data are streaming correctly by "sniff" the packet, but vlc could not play, why? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070123/d9f7b649/attachment-0001.html From rajeshkumar.r at imimobile.com Tue Jan 23 22:28:52 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Wed, 24 Jan 2007 11:58:52 +0530 Subject: [Live-devel] How to play the streaming content Message-ID: <001e01c73f80$ea4e6b00$6902000a@imidomain.com> Hi Ross I am getting the sreaming data from Helix server and streaming data ia being recvd by the openRtsp client. my objective is to send this data to some other application to play the stream. MultiFramedRTPSource::networkReadHandler() function is parsing the rtp Data .parsing includes ignoring header extension,padding and checking for the rtp pay load type. can we directly send the remianing data to some other application that is responsible for playing the Data ,if not plz guide me what to do. with Regards Rajesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070123/8dc2a0b9/attachment.html From finlayson at live555.com Tue Jan 23 22:59:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 22:59:43 -0800 Subject: [Live-devel] How to play the streaming content In-Reply-To: <001e01c73f80$ea4e6b00$6902000a@imidomain.com> References: <001e01c73f80$ea4e6b00$6902000a@imidomain.com> Message-ID: >Hi Ross >I am getting the sreaming data from Helix server and streaming data >ia being recvd by the openRtsp client. >my objective is to send this data to some other application to play >the stream. > >MultiFramedRTPSource::networkReadHandler() function is parsing the >rtp Data .parsing includes >ignoring header extension,padding and checking for the rtp pay load type. This is irrelevant. You don't need to care how that code works. > >can we directly send the remianing data to some other application >that is responsible for playing the Data Sure. If you're receiving only video, then use the "-v" option to "openRTSP", and pipe the output (video data) to the other application (which will read from 'stdin'). Similarly, if you're receiving only audio, then use the "-a" option to "openRTSP", and pipe the output (audio data) to the other application (which will read from 'stdin'). If you're receiving both video and audio, then you will need to modifiy the code to use new 'sink' objects (instead of "FileSink" objects). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070123/86b1e033/attachment.html From finlayson at live555.com Tue Jan 23 23:07:20 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 23 Jan 2007 23:07:20 -0800 Subject: [Live-devel] I have a question! In-Reply-To: <449772039.4433061169619822586.JavaMail.coremail@bj163app136.163.com> References: <449772039.4433061169619822586.JavaMail.coremail@bj163app136.163.com> Message-ID: >I can stream transport stream(TS) with RTP/RTCP protocol by >livemedia lib now. When I want to stream program stream(PS) using >livemedia lib, I found the testprog could only stream elementary >stream(ES). And I must split PS into video ES and audio ES and >stream them with different port. Vlc , however ,can only play one >port. That should not be the case. If you use the "testMPEG1or2AudioVideoStreamer" demo application (and enable the built-in RTSP server), or the "testOnDemandRTSPServer" application (using a Program Stream file named "test.mpg"), or the "live555MediaServer" application (using a Program Stream file named ".mpg"), then VLC should be able to play both the audio and video streams. >Do you have some methods or testprogs to stream PS directly? The >payload type is 96 and payload name is "MP2P"? When I using >SimpleRtpSink function to transport the stream data, I found the >data are streaming correctly by "sniff" the packet, but vlc could >not play, why? Because VLC does not implement that RTP payload format. (Nor does anyone else; instead, everyone streams MPEG Program Stream data as separate audio and video RTP streams. You should do the same, using the supplied demo applications as a guide.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rajeshkumar.r at imimobile.com Wed Jan 24 01:08:47 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Wed, 24 Jan 2007 14:38:47 +0530 Subject: [Live-devel] How to play the streaming content References: <001e01c73f80$ea4e6b00$6902000a@imidomain.com> Message-ID: <008b01c73f97$41b040b0$6902000a@imidomain.com> Re: [Live-devel] How to play the streaming content Hi Ross, The audio and video files that are generated once streaming is over.The content of these files are also same as what we will get from stdin with option -v for video and -a for audio. with Regards Rajesh From: Ross Finlayson To: LIVE555 Streaming Media - development & use Sent: Wednesday, January 24, 2007 12:29 PM Subject: Re: [Live-devel] How to play the streaming content Hi Ross I am getting the sreaming data from Helix server and streaming data ia being recvd by the openRtsp client. my objective is to send this data to some other application to play the stream. MultiFramedRTPSource::networkReadHandler() function is parsing the rtp Data .parsing includes ignoring header extension,padding and checking for the rtp pay load type. This is irrelevant. You don't need to care how that code works. can we directly send the remianing data to some other application that is responsible for playing the Data Sure. If you're receiving only video, then use the "-v" option to "openRTSP", and pipe the output (video data) to the other application (which will read from 'stdin'). Similarly, if you're receiving only audio, then use the "-a" option to "openRTSP", and pipe the output (audio data) to the other application (which will read from 'stdin'). If you're receiving both video and audio, then you will need to modifiy the code to use new 'sink' objects (instead of "FileSink" objects). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ ------------------------------------------------------------------------------ _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070124/eb53894b/attachment.html From mrnikhilagrawal at gmail.com Wed Jan 24 02:43:23 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Wed, 24 Jan 2007 16:13:23 +0530 Subject: [Live-devel] Regarding IO Read Bytes Message-ID: <733cde3e0701240243x259fb93dje7395bf89e3a6ffe@mail.gmail.com> Hi Ross, I streamed a wav file ( ~ 168 KB) . I dont know why Live555 process is showing huge amount of "IO Read bytes". If you know the reason that to read a small file 168 KB and stream it , why it is showing huge IO Read Bytes count ( 3-4 MB in this case). Regards, Nikhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070124/3bc0bb9a/attachment.html From aswin.paranji at gmail.com Wed Jan 24 05:37:21 2007 From: aswin.paranji at gmail.com (Aswin Paranji) Date: Wed, 24 Jan 2007 19:07:21 +0530 Subject: [Live-devel] How to get the Mpeg4 byte Data? Message-ID: Dear Ross, I'm not trying to reinvent i'm just trying to develop an utility to test some of the camera and there quality of service. I have to test mpeg4, H.264 as well as MJPEG formats, the total no of bytes recieved , packet loss, video loss etc. I would also like to know whther openrtsp is capable of handling MJPEG formats on http protocol. I would be happy to have your insight. Regards, *Aswin.N.Paranji** Senior System Analyst** *Omeon Solutions *"Everything is possible. The impossible just takes longer."*** >*Currently I'm working on developing a windows based viewer for AXIS *>*camera which support RTSP protocol. *>* *>*I have actually gone thru the openrtsp source code i was able to *>*build the application and my camera is streaming the video using the *>*openrtsp test application. * Why reinvent the wheel? I suggest just using the existing VLC media player: . It is Open Source, runs on Windows (and many other OSs), and uses the "LIVE555 Streaming Media" code for its RTSP client implementation. It should be able to play the stream from an Axis camera. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070124/aeb99092/attachment.html From finlayson at live555.com Wed Jan 24 07:13:29 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Jan 2007 07:13:29 -0800 Subject: [Live-devel] How to get the Mpeg4 byte Data? In-Reply-To: References: Message-ID: >I'm not trying to reinvent i'm just trying to develop an utility to >test some of the camera and there quality of service. > >I have to test mpeg4, H.264 as well as MJPEG formats, the total no >of bytes recieved , packet loss, video loss etc. That's not what you said before. Before you said "Currently I'm working on developing a windows based viewer for AXIS camera which support RTSP protocol". If that's the case, use VLC. If, instead, you want to test/measure a RTSP/RTP stream, without actually playing it, then use "openRTSP". Two different applications, for two different purposes... >I would also like to know whther openrtsp is capable of handling >MJPEG formats on http protocol. No. "openRTSP" uses the RTSP protocol (not HTTP). >Senior System Analyst >Omeon Solutions Then why do you use a toy email address? No credible company uses "GMail" for its professional communications. If you want to be taken seriously, then use a real email address (not "@gmail.com", "@hotmail.com", "@yahoo.com", etc.). This applies to everyone on this mailing list, BTW. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070124/819b7980/attachment-0001.html From xcsmith at rockwellcollins.com Wed Jan 24 11:20:45 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Wed, 24 Jan 2007 13:20:45 -0600 Subject: [Live-devel] About long time wait when server isn't available Message-ID: >is it OK for the RTSPClient work under non-blocking mode? This would be nice to do, but would be a non-trivial change to the code. It might get done someday, but probably not soon. I have added this to my copy the code, but I have a lot of paperwork to do before I can post my code. Create a new protected member "struct timeval* fResponseTimeout" and initialize it to NULL in the constructor. Create an accessor function for setting the value of fResponseTimeout. Then in function RTSPClient::getResponse1(), just inside the first "while" loop, change the readSocket call to: "readSocket(envir(), fInputSocketNum, &firstByte, 1, fromAddress, fResponseTimeout)" The client will default to passing NULL into the readSocket call, so it will work exactly as the original client if you do not set the value of fResponseTimeout. I have been using this modification in my code for a couple months now, and so far it works great. If the server is not available, the calls to getResponse1() fail, and the RTSPClient exits the function with "false" return value. Please make a post for me if you see any cases in which this would not work. Thank you! Xochitl P.S. I tried to implement an alternative using incomingRequestHandler(), but that was very complicated. I think this simple timeout might work for some people. From rcourtney at iowadsl.net Wed Jan 24 11:44:06 2007 From: rcourtney at iowadsl.net (rcourtney at iowadsl.net) Date: Wed, 24 Jan 2007 13:44:06 -0600 Subject: [Live-devel] OT: AMINO STB JS for displaying graphic when using trick functions In-Reply-To: References: <126043.57764.qm@web59003.mail.re1.yahoo.com> Message-ID: <1169667846.45b7b7062abb1@virtualmail.avalon.net> For those that have been playing with trick functions (FF REW PAUSE STOP) here is the Javascript I have been playing with. Build your graphic as a 640x500 PNG with a green background (00ff00). Where the background is green will be transparent. IM me if you need a sample emailed. When you press a trick key the trkbkg.png graphic will be shown overlayed onto the video. You will note that the first time PAUSE is pressed it will be very faint. The Amino units allow alpha blending. Amino JS Page From wweng at kencast.com Wed Jan 24 13:06:10 2007 From: wweng at kencast.com (Wei Weng) Date: Wed, 24 Jan 2007 16:06:10 -0500 Subject: [Live-devel] Streaming MPEG4 Files Message-ID: <45B7CA42.80402@kencast.com> I am trying to use the program live555MediaServer to stream a mpeg4 file "test.m4e" to VLC client. But I get the following errors on client side: ffmpeg warning: cannot decode one frame (1122 bytes) ffmpeg warning: header damaged (mpeg4 at 0x8ea0c00) (Repeat itself for many times until the video is finished) I can open the file directly with VLC client, but got those error messages when I am trying to see it through streaming. Any tips on how to broadcast a mpeg4 file? Thanks Wei From finlayson at live555.com Wed Jan 24 13:53:18 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Jan 2007 13:53:18 -0800 Subject: [Live-devel] Streaming MPEG4 Files In-Reply-To: <45B7CA42.80402@kencast.com> References: <45B7CA42.80402@kencast.com> Message-ID: >I am trying to use the program live555MediaServer to stream a mpeg4 file >"test.m4e" to VLC client. But I get the following errors on client side: > >ffmpeg warning: cannot decode one frame (1122 bytes) >ffmpeg warning: header damaged > (mpeg4 at 0x8ea0c00) Are you *sure* that your file is a MPEG-4 Elementary Stream Video file? (Hint: If your file originally had a file name ending with ".mp4", ".m4v" or ".mov", then it is almost certainly *not* a MPEG-4 Elementary Stream Video file.) If you are sure that your file really is a MPEG-4 Video Elementary Stream, then please put it on a web server and post its URL to the list, so we can take a look at it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yannanfei79 at hotmail.com Wed Jan 24 16:50:46 2007 From: yannanfei79 at hotmail.com (zhang shawn) Date: Thu, 25 Jan 2007 08:50:46 +0800 Subject: [Live-devel] about ts server trickmode(PMT_PID not same) Message-ID: hi, I test my STB trickmode performance with live555 media server. And I find that,when trickmode(server create a .tsx file with MPEG2TransportStreamIndexer),server send a PAT section which's PMT_PID is different from the original PAT'PMT_PID.I read code,maybe it's a default value--0X10. So,if my client just parse PAT once,it will save the original PMT_PID form the first PAT,it will not parse the trickmode PAT,so will not continue play out. I don't know,why don't server get the original TS file's PMT_PID, and reuse it in trickmode?Because many cases,we have only one programes in ts'file. thx, Shawn zhang _________________________________________________________________ ??????????????? MSN Hotmail? http://www.hotmail.com From zkunhui at hotmail.com Wed Jan 24 17:03:01 2007 From: zkunhui at hotmail.com (Tay Koon Hwee) Date: Thu, 25 Jan 2007 09:03:01 +0800 Subject: [Live-devel] Delay in streaming Message-ID: Hi guys, I am currently using MPEG2 -TS to stream video encoded using H.264. However, I experienced long delay at the receiver (approx 30sec). The encoder was unlikely to be the casue of the delay as we had set it to the bare minimum and to a profile which supported low delay for real time. It was suspected the delay was virtual (livemedia buffer) as the vlc reported that the frames are delivered late. Bandwidth should not be the problem as we used a wireless router to stream directly from pc to pc. Did anyone experience this problem before? Please advise. Many thanks in advance. zkunhui _________________________________________________________________ Get MSN Messenger emoticons and display pictures here! http://ilovemessenger.msn.com/?mkt=en-sg From finlayson at live555.com Wed Jan 24 17:19:08 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Jan 2007 17:19:08 -0800 Subject: [Live-devel] about ts server trickmode(PMT_PID not same) In-Reply-To: References: Message-ID: >hi, > I test my STB trickmode performance with live555 media server. > And I find that,when trickmode(server create a .tsx file with >MPEG2TransportStreamIndexer),server send a PAT section which's PMT_PID is >different from the original PAT'PMT_PID.I read code,maybe it's a default >value--0X10. > So,if my client just parse PAT once,it will save the original PMT_PID >form the first PAT,it will not parse the trickmode PAT,so will not continue >play out. You should fix your client to parse the PAT, whenever it appears. As far as I know, it is perfectly legal for the PMT_PID to change within a Transport Stream, as long as this change is noted in a PAT. > I don't know,why don't server get the original TS file's PMT_PID, and >reuse it in trickmode? This would require a change to the index file format, and is not something that we plan to do. >Because many cases,we have only one programes in >ts'file. As I noted above, it is legal for the PMT_PID to change within a stream. (Even if our server were modified not to do this, then other servers might still do it. So your client should check for it regardless...) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Wed Jan 24 17:27:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 24 Jan 2007 17:27:21 -0800 Subject: [Live-devel] Delay in streaming In-Reply-To: References: Message-ID: >Hi guys, > >I am currently using MPEG2 -TS to stream video encoded using H.264. However, >I experienced long delay at the receiver (approx 30sec). The encoder was >unlikely to be the casue of the delay as we had set it to the bare minimum >and to a profile which supported low delay for real time. > >It was suspected the delay was virtual (livemedia buffer) as the vlc >reported that the frames are delivered late. Bandwidth should not be the >problem as we used a wireless router to stream directly from pc to pc. > >Did anyone experience this problem before? Please advise. This is a VLC issue - not an issue with our libraries; any follow-up emails should be sent to a VLC mailing list. Note that you can control the size (latency) of VLC's playout buffer on the command line, using the "--rtsp-caching" option - e.g., vlc --rtsp-caching 100 to get a 100 ms buffer. I think the default value for this is 1200 - i.e., 1.2 seconds. You can also set this buffer size from the GUI - i.e. Preferences... -> Demuxers -> RTSP/RTP Then click the "advanced options" check box Then change "caching value (ms)" -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From yannanfei79 at hotmail.com Wed Jan 24 17:40:23 2007 From: yannanfei79 at hotmail.com (zhang shawn) Date: Thu, 25 Jan 2007 09:40:23 +0800 Subject: [Live-devel] about ts server trickmode(PMT_PID not same) In-Reply-To: Message-ID: Thx,i got it. i don't know media server much, I want to know,when trickmode, whether most servers use this method like live server,including commercial's?Just interest --:) >From: Ross Finlayson >Reply-To: LIVE555 Streaming Media - development & use >To: LIVE555 Streaming Media - development & use >Subject: Re: [Live-devel] about ts server trickmode(PMT_PID not same) >Date: Wed, 24 Jan 2007 17:19:08 -0800 > > >hi, > > I test my STB trickmode performance with live555 media server. > > And I find that,when trickmode(server create a .tsx file with > >MPEG2TransportStreamIndexer),server send a PAT section which's PMT_PID is > >different from the original PAT'PMT_PID.I read code,maybe it's a default > >value--0X10. > > So,if my client just parse PAT once,it will save the original PMT_PID > >form the first PAT,it will not parse the trickmode PAT,so will not continue > >play out. > >You should fix your client to parse the PAT, whenever it appears. As >far as I know, it is perfectly legal for the PMT_PID to change within >a Transport Stream, as long as this change is noted in a PAT. > > > I don't know,why don't server get the original TS file's PMT_PID, and > >reuse it in trickmode? > >This would require a change to the index file format, and is not >something that we plan to do. > > >Because many cases,we have only one programes in > >ts'file. > >As I noted above, it is legal for the PMT_PID to change within a >stream. (Even if our server were modified not to do this, then other >servers might still do it. So your client should check for it >regardless...) >-- > >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 _________________________________________________________________ ??????????????? MSN Hotmail? http://www.hotmail.com From yunjnz at yahoo.com Wed Jan 24 17:40:52 2007 From: yunjnz at yahoo.com (Sean) Date: Wed, 24 Jan 2007 17:40:52 -0800 (PST) Subject: [Live-devel] About long time wait when server isn't available In-Reply-To: Message-ID: <70255.55430.qm@web35814.mail.mud.yahoo.com> --- xcsmith at rockwellcollins.com wrote: > > >is it OK for the RTSPClient work under non-blocking > mode? > This would be nice to do, but would be a non-trivial > change to the > code. It might get done someday, but probably not > soon. > > I have added this to my copy the code, but I have a > lot of paperwork to do > before I can post my code. > > Create a new protected member "struct timeval* > fResponseTimeout" and > initialize it to NULL in the constructor. > Create an accessor function for setting the value of > fResponseTimeout. > Then in function RTSPClient::getResponse1(), just > inside the first "while" > loop, change the readSocket call to: > "readSocket(envir(), fInputSocketNum, &firstByte, 1, > fromAddress, > fResponseTimeout)" > > The client will default to passing NULL into the > readSocket call, so it > will work exactly as the original client if you do > not set the value of > fResponseTimeout. I have been using this > modification in my code for a > couple months now, and so far it works great. If > the server is not > available, the calls to getResponse1() fail, and the > RTSPClient exits the > function with "false" return value. > > Please make a post for me if you see any cases in > which this would not > work. > Thank you! Appreciate for your help on the issue, But as my investigation, the client will block in the function call "connect" in openConnectionFromURL, Do we need to modify the last parameter of setupStreamSocket from "False" to "True" for non-blocking mode? and it seems that the "connect" call will immediately return with error EINPROGRESS, in my opinion, we should check if the errno is EINPROGRESS and then continue, isn't it? and in that case, later the RTSPClient will send request to the server, should we wait for the signal of successfully connected? if so, how to get the signal? Anyway, it works better than blocking if the server isn't available according to your suggestion. That's good. Thanks. Sean > > Xochitl > > P.S. I tried to implement an alternative using > incomingRequestHandler(), > but that was very complicated. I think this simple > timeout might work for > some people. > > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited From zjuchenjun at hotmail.com Thu Jan 25 05:37:01 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Thu, 25 Jan 2007 21:37:01 +0800 Subject: [Live-devel] 1435Bytes(598H) lost in the first rtp bag Message-ID: Hi Ross, I met a problem: i streaming H.264 video from a live source and receive it with openRTSP,then I compared the received datas with the original datas, I found the first streaming rtp bag always lost about 1435bytes data from the head, however after that the data transmission are correct.Maybe you can give me a hint. Thanks very much. c.j _________________________________________________________________ Windows Live Safety Center ?????????????????? http://safety.live.com/site/ZH-CN/default.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070125/ce9b2c45/attachment.html From mrnikhilagrawal at gmail.com Thu Jan 25 06:03:46 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Thu, 25 Jan 2007 19:33:46 +0530 Subject: [Live-devel] Regarding embedding VLC in IE Message-ID: <733cde3e0701250603v7cc8d0e3n57ca40ea22824f5f@mail.gmail.com> Hi, I am using Live555 as my streaming server and VLC as client player . I want to embedd VLC player at client side in IE and I did it by using its plugIn, They have provided various functions like play() , seek() ...etc , i want to show on web page a position slidder kind of control through which user can perform seeking. So if any one has done this thing please let me know. Although I know this question must be asked in VLC group but as maximum Live555 users use VLC as their client player , so i may get help from our Live555 group also. Regards, Nikhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070125/43cd9cf8/attachment.html From shishir at birmiwal.net Thu Jan 25 06:24:01 2007 From: shishir at birmiwal.net (Shishir Birmiwal) Date: Thu, 25 Jan 2007 19:54:01 +0530 Subject: [Live-devel] 1435Bytes(598H) lost in the first rtp bag In-Reply-To: References: Message-ID: Chenjun, > I compared the received datas with the original datas, I found the first > streaming rtp bag always lost about > 1435bytes data from the head, however after that the data transmission are > correct.Maybe you can give me a hint. > Maybe this will help (from RFC 3984 - RTP Payload Format for H.264 Video): Section 1.2: One very fundamental design concept of H.264 is to generate self- contained packets, to make mechanisms such as the header duplication of RFC 2429 [10] or MPEG-4's Header Extension Code (HEC) [11] unnecessary. This was achieved by decoupling information relevant to more than one slice from the media stream. This higher layer meta information should be sent reliably, asynchronously, and in advance from the RTP packet stream that contains the slice packets. (Provisions for sending this information in-band are also available for applications that do not have an out-of-band transport channel appropriate for the purpose.) The combination of the higher-level parameters is called a parameter set. The H.264 specification includes two types of parameter sets: sequence parameter set and picture parameter set. An active sequence parameter set remains unchanged throughout a coded video sequence, and an active picture parameter set remains unchanged within a coded picture. The sequence and picture parameter set structures contain information such as picture size, optional coding modes employed, and macroblock to slice group map. To be able to change picture parameters (such as the picture size) without having to transmit parameter set updates synchronously to the slice packet stream, the encoder and decoder can maintain a list of more than one sequence and picture parameter set. Each slice header contains a codeword that indicates the sequence and picture parameter set to be used. This mechanism allows the decoupling of the transmission of parameter sets from the packet stream, and the transmission of them by external means (e.g., as a side effect of the capability exchange), or through a (reliable or unreliable) control protocol. It may even be possible that they are never transmitted but are fixed by an application design specification. Maybe you're missing the first 1435 bytes because they form the SPS and PPS. You can easily verify that by looking at the missing bytes (headers) for NAL unit type 7 and 8. HTH Regards Shishir From xcsmith at rockwellcollins.com Thu Jan 25 09:30:16 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 25 Jan 2007 11:30:16 -0600 Subject: [Live-devel] About long time wait when server isn't available Message-ID: >> Appreciate for your help on the issue, But as my investigation, the client will block in the function call "connect" in openConnectionFromURL, Do we need to modify the last parameter of setupStreamSocket from "False" to "True" for non-blocking mode? Re: This doesn't seem so for me. I just tried my build again with that parameter set to True, and my software always returned immediately and did nothing. I think connect has its own timeout on it maybe? I see something in the man pages about ETIMEDOUT. I'm no socket expert, but I don't think the socket should be set up as you suggest unless maybe some other setting is changed too. When I leave this set to false, my software returns correctly after the wait period if the RTSP server is not available, but only on the read calls. The connect call seems to have its own timeout, and returns quickly when I request a non-existent RTSP server on a neighboring workstation or a computer that does not exist. However, I tried asking for a non-existent RTSP server from one of our file servers, and the wait is extremely long (on the order of a couple minutes) but it still returned. This seems logical to me based on the man pages. I don't think blocking infinitely on connect was part of the initial problem you were seeing, I think that it is only the infinite blocking on the read attempts that are the issue. The original RTSP client sends a message and then blocks while waiting for the expected RTSP server response. I think this is the only blocking problem we need to solve. >> and it seems that the "connect" call will immediately return with error EINPROGRESS, in my opinion, we should check if the errno is EINPROGRESS and then continue, isn't it? and in that case, later the RTSPClient will send request to the server, should we wait for the signal of successfully connected? Re: RTSPClient::openConnectionFromURL() returns False if the connection is not successful, and all the RTSP methods in RTSPClient check the return value. RTSPClient doesn't try to send any information if the connection fails, so I think RTSPClient already does what you are suggesting. Xochitl From jean-paul.saman at planet.nl Thu Jan 25 11:43:06 2007 From: jean-paul.saman at planet.nl (Jean-Paul Saman) Date: Thu, 25 Jan 2007 20:43:06 +0100 Subject: [Live-devel] Regarding embedding VLC in IE In-Reply-To: <733cde3e0701250603v7cc8d0e3n57ca40ea22824f5f@mail.gmail.com> References: <733cde3e0701250603v7cc8d0e3n57ca40ea22824f5f@mail.gmail.com> Message-ID: <45B9084A.5010808@planet.nl> Nikhil Agrawal wrote: > Hi, > > I am using Live555 as my streaming server and VLC as client player . I want > to embedd VLC player at client side in IE and I did it by using its plugIn, > They have provided various functions like play() , seek() ...etc , i > want to > show on web page a position slidder kind of control through which user can > perform seeking. So if any one has done this thing please let me know. > Although I know this question must be asked in VLC group but as maximum > Live555 users use VLC as their client player , so i may get help from our > Live555 group also. I think this e-mail gets more response when sent to the right mailinglist. People there build the plugin and have JS sliders etc. examples in the documentation and much more that could be of help to you. Send an e-mail to vlc-devel at videolan dot org. Gtz, Jean-Paul Saman. From yunjnz at yahoo.com Thu Jan 25 16:50:07 2007 From: yunjnz at yahoo.com (Sean) Date: Thu, 25 Jan 2007 16:50:07 -0800 (PST) Subject: [Live-devel] About long time wait when server isn't available In-Reply-To: Message-ID: <970494.21360.qm@web35801.mail.mud.yahoo.com> --- xcsmith at rockwellcollins.com wrote: > However, I tried > asking for a non-existent > RTSP server from one of our file servers, and the > wait is extremely long > (on the order of a couple minutes) but it still > returned. This seems > logical to me based on the man pages. > Actually, I also found that the wait is extremely long, and the connect will return after several minutes if the server isn't available, for example, if you plug out the RTSP server's network connection, and use the RTSPClient to connect the server, this phenomenon will occur. I'm trying to use a timeout for non-blocking connect to the server, but it seems the client can't connect to the server even if the server is available. Thank you. Sean. ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ From zjuchenjun at hotmail.com Thu Jan 25 22:23:52 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Fri, 26 Jan 2007 14:23:52 +0800 Subject: [Live-devel] 1435Bytes(598H) lost in the first rtp bag Message-ID: Hi Shishir, You are right, it contains SPS ,PPS ,but also a part of "Coded slice of an IDR picture",I list the data below: 00 00 00 01 27 42 00 1E 8D 8D 40 80 4A 20 00 00 00 01 28 CE 04 08 C8 00 00 00 01 25 B8 00 04 ... These datas losted in transmission, So my client--Mplayer can't decoded the H264 video,it appears: Error while decoding frame![h264 @ 0x87b73f4]non existing PPS referenced[h264 @ 0x87b73f4]decode_slice_header errorError while decoding frame!I solve this problem by filled the 1435 bytes zeros from the head. I want to know why and where the live555 dropped these datas. How to solve it in essential. Thanks for your help. C.J > Date: Thu, 25 Jan 2007 19:54:01 +0530> From: shishir at birmiwal.net> To: live-devel at ns.live555.com> Subject: Re: [Live-devel] 1435Bytes(598H) lost in the first rtp bag> > Chenjun,> > > I compared the received datas with the original datas, I found the first> > streaming rtp bag always lost about> > 1435bytes data from the head, however after that the data transmission are> > correct.Maybe you can give me a hint.> >> > Maybe this will help (from RFC 3984 - RTP Payload Format for H.264 Video):> > Section 1.2:> > One very fundamental design concept of H.264 is to generate self-> contained packets, to make mechanisms such as the header duplication> of RFC 2429 [10] or MPEG-4's Header Extension Code (HEC) [11]> unnecessary. This was achieved by decoupling information relevant to> more than one slice from the media stream. This higher layer meta> information should be sent reliably, asynchronously, and in advance> from the RTP packet stream that contains the slice packets.> (Provisions for sending this information in-band are also available> for applications that do not have an out-of-band transport channel> appropriate for the purpose.) The combination of the higher-level> parameters is called a parameter set. The H.264 specification> includes two types of parameter sets: sequence parameter set and> picture parameter set. An active sequence parameter set remains> unchanged throughout a coded video sequence, and an active picture> parameter set remains unchanged within a coded picture. The sequence> and picture parameter set structures contain information such as> picture size, optional coding modes employed, and macroblock to slice> group map.> > To be able to change picture parameters (such as the picture size)> without having to transmit parameter set updates synchronously to the> slice packet stream, the encoder and decoder can maintain a list of> more than one sequence and picture parameter set. Each slice header> contains a codeword that indicates the sequence and picture parameter> set to be used.> > This mecha nism allows the decoupling of the transmission of parameter> sets from the packet stream, and the transmission of them by external> means (e.g., as a side effect of the capability exchange), or through> a (reliable or unreliable) control protocol. It may even be possible> that they are never transmitted but are fixed by an application> design specification.> > Maybe you're missing the first 1435 bytes because they form the SPS> and PPS. You can easily verify that by looking at the missing bytes> (headers) for NAL unit type 7 and 8.> > HTH> > Regards> Shishir> _______________________________________________> live-devel mailing list> live-devel at lists.live555.com> http://lists.live555.com/mailman/listinfo/live-devel _________________________________________________________________ ?? Windows Live Messenger ?????? http://get.live.com/messenger/overview -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070125/e30ae627/attachment-0001.html From weiyutao36 at 163.com Fri Jan 26 02:48:57 2007 From: weiyutao36 at 163.com (weiyutao36 at 163.com) Date: Fri, 26 Jan 2007 18:48:57 +0800 (CST) Subject: [Live-devel] =?gbk?q?Nal_Unit_Type=A3=AD=A3=ADEngin_Kurutepe?= In-Reply-To: <45B485E4.1080106@nue.tu-berlin.de> References: <45B485E4.1080106@nue.tu-berlin.de> <45AF69BB.9080506@nue.tu-berlin.de> <389189e20701180406s50275014u9b476c681223491a@mail.gmail.com> <3634013.495651169303077597.JavaMail.coremail@bj163app16.163.com> Message-ID: <24554505.3663181169808537052.JavaMail.coremail@bj163app87.163.com> Hi Engin, I have got your codes and read them. When I compiled them into the LIVE555 library, I found the codes had some bugs and small flaws and they caused some warnings and errors. I made some changes to satisfy the compiler. In the client, I used VLC to receive and play the .264 file. The VLC worked well except that the pictures seemed not so consecutive. I do not know the reason. Some changes are listed below: 1) In H264RTPStreamerFramer.cpp, I think the funtion "timeval* incrementTimeval(timeval* tv, unsigned int duration)" should be written as follows:timeval* incrementTimeval(timeval* tv, unsigned int duration) { tv->tv_usec+=duration; if( tv->tv_usec > 1000000) { tv->tv_sec=tv->tv_sec+tv->tv_usec/1000000; tv->tv_usec=tv->tv_usec%1000000; } return tv; }Maybe I missed something? Also, in function "void H264RTPStreamFramer::afterGettingNALU1()", I commented the "int tmp32" and "short tmp16" to avoid compling warnings because currently they are not used. Onece again, to avoid compling warning , in function "void encode()", for( int index=0; indexgetSPS(); char *pps = fOurFramer->getPPS(); unsigned int profile_level_id = fOurFramer->getProfileLevelID(); but class H264VideoStreamFramer does not has these member functions and when compiled it, there were some errors. H264RTPStreamFramer, derived from H264VideoStreamFramer, has these functions. So in H264VideoStreamFramer.hh I added the corresponding virtual functions to make complier satisfactory: virtual char* getSPS() = 0; //weiyutao added virtual char* getPPS() = 0; //weiyutao added virtual unsigned int getProfileLevelID() = 0; //weiyutao added If you changed the codes or added some new features/functions, please inform me, OK? I will study the codes more carefully and do more work. Thanks in advance. Yutao Wei,Shandong University, P.R. China ps: I can't send mail to your mailbox:kurutepe at nue.tu-berlin.de. I tried my two mailboxes and both could not send to you sucessfully. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070126/68c5fbaf/attachment.html From weiyutao36 at 163.com Fri Jan 26 04:27:02 2007 From: weiyutao36 at 163.com (weiyutao36 at 163.com) Date: Fri, 26 Jan 2007 20:27:02 +0800 (CST) Subject: [Live-devel] Old versions of LIVE555 library Message-ID: <27324689.3700831169814422670.JavaMail.coremail@bj163app87.163.com> Hi Ross,I want an old version of live library. However, I searched in the live555.com and did not find one. Can you please tell me where can I find those old versions of live library? Thanks in advance. Yutao Wei,Shandong University, P.R. China -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070126/b285dea7/attachment.html From asmundg at snap.tv Fri Jan 26 05:54:53 2007 From: asmundg at snap.tv (=?utf-8?q?=C3=85smund_Grammeltvedt?=) Date: Fri, 26 Jan 2007 14:54:53 +0100 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: References: <200701231729.47453.asmundg@snap.tv> Message-ID: <200701261454.57640.asmundg@snap.tv> On Tuesday 23 January 2007 18:18, Ross Finlayson wrote: > >I noticed that RTSPServer doesn't seem to accept RAW_UDP (RAW/RAW/UDP or > >MP2T/H2221/UDP) in the Transport header when using a multicast source. I > > that right? In case it's not, the attached patch inserts a case for > > RAW_UDP. > > Thanks. This will get included in the next release of the software. In the related update to the changelog, you note that multicast RAW/UDP is nonstandard. What's the reference for that? Not that I doubt you, but I'm trying to get an overview of the (more or less) standards. :) -- ?smund Grammeltvedt Snap TV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070126/767eb43a/attachment.bin From finlayson at live555.com Fri Jan 26 06:03:07 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Jan 2007 06:03:07 -0800 Subject: [Live-devel] Old versions of LIVE555 library In-Reply-To: <27324689.3700831169814422670.JavaMail.coremail@bj163app87.163.com> References: <27324689.3700831169814422670.JavaMail.coremail@bj163app87.163.com> Message-ID: >Hi Ross, >I want an old version of live library. However, I searched in the >live555.com and did not find one. Can you please tell me where can I >find those old versions of live library? No support is ever given for old versions of the code, and we do not make old versions available for downloading. You should make sure that your application(s) work with the latest version of the code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Fri Jan 26 06:16:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Jan 2007 06:16:57 -0800 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: <200701261454.57640.asmundg@snap.tv> References: <200701231729.47453.asmundg@snap.tv> <200701261454.57640.asmundg@snap.tv> Message-ID: >In the related update to the changelog, you note that multicast RAW/UDP is >nonstandard. What's the reference for that? *All* RAW/UDP streaming (not just multicast) is non-standard, because it has never been defined in a RFC. Also, it can only work for media types - like MPEG Transport Stream data - that includes its own timestamp information (so that the timestamp in the RTP header is not strictly needed). Despite not being a standard, RAW/UDP streaming (for MPEG Transport Stream data only) is requested by some prominent RTSP clients (most notably Amino set-top boxes), and therefore we (reluctantly) support it in our RTSP server implementation. All new RTSP clients, however, should request standard RTP streaming only. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From asmundg at snap.tv Fri Jan 26 07:24:08 2007 From: asmundg at snap.tv (=?utf-8?q?=C3=85smund_Grammeltvedt?=) Date: Fri, 26 Jan 2007 16:24:08 +0100 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: References: <200701231729.47453.asmundg@snap.tv> <200701261454.57640.asmundg@snap.tv> Message-ID: <200701261624.10812.asmundg@snap.tv> On Friday 26 January 2007 15:16, Ross Finlayson wrote: > Despite not being a standard, RAW/UDP streaming (for MPEG Transport > Stream data only) is requested by some prominent RTSP clients (most > notably Amino set-top boxes), and therefore we (reluctantly) support > it in our RTSP server implementation. All new RTSP clients, however, > should request standard RTP streaming only. Ok, thanks. That does, however, raise the question about the usefulness of supporting raw/udp multicast at all. Especially since Amino (and Kreatel/Motorola, for that matter) STBs don't seem to support multicast over rtsp anyway. -- ?smund Grammeltvedt Snap TV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070126/d38194a1/attachment.bin From gmartin at harris.com Fri Jan 26 07:52:36 2007 From: gmartin at harris.com (Martin, Gary) Date: Fri, 26 Jan 2007 10:52:36 -0500 Subject: [Live-devel] compliance with what version of RTSP RFC? In-Reply-To: Message-ID: Is the latest Live555 RTSP implementation written to the RFC 2326 proposed standard dated April 1998 or to the draft update to this RFC dated February 2004? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070126/7a93defb/attachment-0001.html From shishir at birmiwal.net Fri Jan 26 09:03:09 2007 From: shishir at birmiwal.net (Shishir Birmiwal) Date: Fri, 26 Jan 2007 22:33:09 +0530 Subject: [Live-devel] 1435Bytes(598H) lost in the first rtp bag In-Reply-To: References: Message-ID: Chenjun, > You are right, it contains SPS ,PPS ,but also a part of "Coded slice of an > IDR picture",I list the data below: > > 00 00 00 01 27 42 00 1E 8D 8D 40 80 4A 20 00 00 00 01 28 CE 04 08 C8 00 00 > 00 01 25 B8 00 04 ... > You are right about this. I do see that there is an SPS/PPS in the stream, as well as a "Coded slice of an IDR picture". I can't think of any reason why those bytes should go missing. Could you provide an ethereal capture of the RTSP transaction, as well as the first few packets of the RTP stream and (a portion) of the H.264 stream on a (FTP) site? What is the source(application) of the stream? Ross, any ideas? (Wild guess - did it get sent in the SDP somehow?) Regards Shishir PS: Chenjun, please strike-out my email address when you reply to mails, as otherwise, it gets harvested by spam-bots. Thanks in advance. From finlayson at live555.com Fri Jan 26 10:27:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Jan 2007 10:27:55 -0800 Subject: [Live-devel] compliance with what version of RTSP RFC? In-Reply-To: References: Message-ID: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C74161.FFF8E736" > > >Is the latest Live555 RTSP implementation written to the RFC 2326 >proposed standard dated April 1998 or to the draft update to this >RFC dated February 2004? Our RTSP implementation is intended to comply with the "RTSP 1.0" specification: RFC 2326. This is the only version of RTSP that is currently an Internet Standard. More recent Internet-Drafts - the latest of which is , dated December 2006 (*not* February 2004 - the link at www.rtsp.org is out-of-date) - define a newer version of RTSP ("RTSP 2.0"). This version has not yet been standardized by the IETF; however, the final RFC for this will likely be very similar to the latest draft. It is also very likely that our code will be upgraded to support RTSP 2.0 sometime in the future (as this may be needed to better support things like NAT traversal). However, for now, RTSP 1.0 (RFC 2326) is what we support. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070126/051f09cf/attachment.html From finlayson at live555.com Fri Jan 26 10:51:05 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Jan 2007 10:51:05 -0800 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: <200701261624.10812.asmundg@snap.tv> References: <200701231729.47453.asmundg@snap.tv> <200701261454.57640.asmundg@snap.tv> <200701261624.10812.asmundg@snap.tv> Message-ID: >Content-Type: multipart/signed; boundary="nextPart2156621.SsLREyNqSC"; > protocol="application/pgp-signature"; micalg=pgp-sha1 >Content-Transfer-Encoding: 7bit > >On Friday 26 January 2007 15:16, Ross Finlayson wrote: >> Despite not being a standard, RAW/UDP streaming (for MPEG Transport >> Stream data only) is requested by some prominent RTSP clients (most >> notably Amino set-top boxes), and therefore we (reluctantly) support >> it in our RTSP server implementation. All new RTSP clients, however, >> should request standard RTP streaming only. > >Ok, thanks. That does, however, raise the question about the usefulness of >supporting raw/udp multicast at all. Especially since Amino (and >Kreatel/Motorola, for that matter) STBs don't seem to support multicast over >rtsp anyway. And that raises the question of why you submitted a patch to support RAW/UDP multicast, given that no known client supports it :-) :-) I will, however, add your patch to the installed code, because it makes it more consistent. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From victor_l2000 at hotmail.com Fri Jan 26 14:23:09 2007 From: victor_l2000 at hotmail.com (Victor Lee) Date: Fri, 26 Jan 2007 14:23:09 -0800 Subject: [Live-devel] MPEG1or2VideoStreamParser::parseSlice(): Saw unexpected code 000001E0 Message-ID: Hi All, I am using an RTSP server. When i use it to stream out MPEG2 ES Video stream, i had the following error messages. Could you please tell me what is the problem? Thanks! MPEG1or2VideoStreamParser::parseSlice(): Saw unexpected code 000001E0 MPEG1or2VideoStreamParser::parseSlice(): Saw unexpected code 000001E0 Victor _________________________________________________________________ >From predictions to trailers, check out the MSN Entertainment Guide to the Academy Awards® http://movies.msn.com/movies/oscars2007/?icid=ncoscartagline1 From finlayson at live555.com Fri Jan 26 15:47:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 26 Jan 2007 15:47:45 -0800 Subject: [Live-devel] MPEG1or2VideoStreamParser::parseSlice(): Saw unexpected code 000001E0 In-Reply-To: References: Message-ID: >Hi All, > >I am using an RTSP server. When i use it to stream out MPEG2 ES >Video stream, i had the following error messages. Could you please >tell me what is the problem? Thanks! > >MPEG1or2VideoStreamParser::parseSlice(): Saw unexpected code 000001E0 >MPEG1or2VideoStreamParser::parseSlice(): Saw unexpected code 000001E0 Read the FAQ. Your file is probably a MPEG Program Stream, rather than a MPEG Video Elementary Stream. You can still stream this, but (if you're running "testOnDemandRTSPServer") using the file name "test.mpg" rather than "testv.mpg". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andrew.voznytsa at gmail.com Sat Jan 27 06:03:30 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sat, 27 Jan 2007 16:03:30 +0200 Subject: [Live-devel] ServerMediaSession.patch References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg Message-ID: <45BB5BB2.7090607@gmail.com> Hello all, attached is patch for ServerMediaSession which: a) enables user-level control of trackNumber for ServerMediaSubsession. This feature, if used, shall be used for every subsession of specified session object. b) allows to remove ServerMediaSubsession. c) allows to overwrite 's=' 'i=' during SDP generation process. All features above are mainly useful for manipulation ServerMediaSession without recreating instance. -- Best regards, Andrew Voznytsa -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ServerMediaSession.patch Url: http://lists.live555.com/pipermail/live-devel/attachments/20070127/980755e7/attachment.ksh From andrew.voznytsa at gmail.com Sat Jan 27 06:15:28 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sat, 27 Jan 2007 16:15:28 +0200 Subject: [Live-devel] RTSP connection loss Message-ID: <45BB5E80.1040004@gmail.com> Hello all, simple problem - if TCP connection is lost I'm getting 100% CPU usage (Win32 and company). Problem is in liveMedia/RTSPClient.cpp: void RTSPClient::incomingRequestHandler1() { ... bytesRead = getResponse1(readBuf, fResponseBufferSize); if (bytesRead == 0) { envir().setResultErrMsg("Failed to read response: "); return; } ... } if getResponse1() returns 0 (because of connection loss) incomingRequestHandler1() simply returns. Since scheduler has nothing else to do it will reschedule incomingRequestHandler1() again and again thus raising CPU usage to 100%. I simply insert Sleep(1) before 'return' operator (Win32 sys call) to temporary solve problem. Does anyone have better solution which could be applied to official source tree? -- Best regards, Andrew Voznytsa From finlayson at live555.com Sat Jan 27 06:22:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 27 Jan 2007 06:22:53 -0800 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: <45BB5BB2.7090607@gmail.com> References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> Message-ID: >attached is patch for ServerMediaSession which: >a) enables user-level control of trackNumber for ServerMediaSubsession. I won't be adding this feature, because it is both unnecessary (what's wrong with the current behavior; the user shouldn't care what track numbers the RTSP server uses?), and dangerous (it doesn't prevent duplicate track numbers). >b) allows to remove ServerMediaSubsession. Can you give an example of a realistic situation where you might want to do this? (This feature doesn't seem totally unreasonable, but I'm not convinced that is useful enough to add.) >c) allows to overwrite 's=' 'i=' during SDP generation process. Can you explain why you need this? In the current code, "ServerMediaSession::generateSDPDescription()" is called only by the RTSP server (to implement the RTSP "DESCRIBE" command). How would it be possible/appropriate to pass a "info" and/or "description" parameter to the call to "generateSDPDescription()" at this point? Do you have some other situation in mind where you want to call "generateSDPDescription()"? -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jan 27 06:35:16 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 27 Jan 2007 06:35:16 -0800 Subject: [Live-devel] RTSP connection loss In-Reply-To: <45BB5E80.1040004@gmail.com> References: <45BB5E80.1040004@gmail.com> Message-ID: >Hello all, > >simple problem - if TCP connection is lost I'm getting 100% CPU usage >(Win32 and company). > >Problem is in liveMedia/RTSPClient.cpp: > >void RTSPClient::incomingRequestHandler1() { >... > bytesRead = getResponse1(readBuf, fResponseBufferSize); > if (bytesRead == 0) { > envir().setResultErrMsg("Failed to read response: "); > return; > } >... >} > >if getResponse1() returns 0 (because of connection loss) >incomingRequestHandler1() simply returns. Since scheduler has nothing >else to do it will reschedule incomingRequestHandler1() again and again >thus raising CPU usage to 100%. > >I simply insert Sleep(1) before 'return' operator (Win32 sys call) to >temporary solve problem. > >Does anyone have better solution which could be applied to official >source tree? Try adding the following, before the "return" statement: envir().taskScheduler().turnOffBackgroundReadHandling(fInputSocketNum); (Let us know if this works; if so, I'll add it to the next code release.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andrew.voznytsa at gmail.com Sat Jan 27 06:45:42 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sat, 27 Jan 2007 16:45:42 +0200 Subject: [Live-devel] RTPSink::rtpmapLine() Message-ID: <45BB6596.8060401@gmail.com> Hello All, another simple problem - I've to stream audio to some brain-damaging black box which requires to allways append number of channels to format line (i.e. audio/format/frequency/channels). Current implementation of RTPSink::rtpmapLine() adds number of channels only if it is higher than 1. Since streaming to brain-damaging boxes is rather unusual task I'd ask to just make rtpmapLine() virtual. -- Best regards, Andrew Voznytsa From andrew.voznytsa at gmail.com Sat Jan 27 07:14:09 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sat, 27 Jan 2007 17:14:09 +0200 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> Message-ID: <45BB6C41.1050205@gmail.com> Ok, I'll explain my real use cases. I wrote DirectShow filter (http://en.wikipedia.org/wiki/DirectShow) which is used for streaming in DirectShow environment. Filter has a few input pins. Some pre-conditions: it is not necessary that all pins are connected. Also it is not necessary that pin connection process happens only once. Filter itself is associated with ServerMediaSession. Each connected input pin - with ServerMediaSubsession (in my case - some kind of PassiveMediaSubsession). b) Because pins may connect/disconnect in any order I should be able possible to add/remove associated subsession on each connect/disconnect event. a) Since it is possible to remove subsession then it is possible to add it again. If I do so subsession will get trackNumber equal to number of addSubession() calls + 1. This is not right because of compatibility with Darwin/QT software - they require trackNumber'ing from 0 if I understood it right. c) I don't use server object for streaming: I save SDP file in Darwin's content directory so if anyone requests Darwint to stream rtsp://../my.sdp it will wotk in relay mode: listen to my RTP and resend it. Because I may stream live content it would be nice to update session information. For example if my capture device was reconfigured from capturing TV1 channel to TV2 in run time then I'd be able to update session info too.. In run time, without recreation ServerMediaSession/etc. Ross Finlayson wrote: >> attached is patch for ServerMediaSession which: >> a) enables user-level control of trackNumber for ServerMediaSubsession. > > I won't be adding this feature, because it is both unnecessary > (what's wrong with the current behavior; the user shouldn't care what > track numbers the RTSP server uses?), and dangerous (it doesn't > prevent duplicate track numbers). > >> b) allows to remove ServerMediaSubsession. > > Can you give an example of a realistic situation where you might want > to do this? (This feature doesn't seem totally unreasonable, but I'm > not convinced that is useful enough to add.) > >> c) allows to overwrite 's=' 'i=' during SDP generation process. > > Can you explain why you need this? In the current code, > "ServerMediaSession::generateSDPDescription()" is called only by the > RTSP server (to implement the RTSP "DESCRIBE" command). How would it > be possible/appropriate to pass a "info" and/or "description" > parameter to the call to "generateSDPDescription()" at this point? > Do you have some other situation in mind where you want to call > "generateSDPDescription()"? -- Best regards, Andrew Voznytsa From andrew.voznytsa at gmail.com Sat Jan 27 07:53:30 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sat, 27 Jan 2007 17:53:30 +0200 Subject: [Live-devel] RTSP connection loss In-Reply-To: References: <45BB5E80.1040004@gmail.com> Message-ID: <45BB757A.9060203@gmail.com> Ross Finlayson wrote: > Try adding the following, before the "return" statement: > envir().taskScheduler().turnOffBackgroundReadHandling(fInputSocketNum); > > (Let us know if this works; if so, I'll add it to the next code release.) > It works, thanks. -- Best regards, Andrew Voznytsa From asmundg at snap.tv Sat Jan 27 09:38:32 2007 From: asmundg at snap.tv (=?iso-8859-1?q?=C5smund_Grammeltvedt?=) Date: Sat, 27 Jan 2007 18:38:32 +0100 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: References: <200701231729.47453.asmundg@snap.tv> <200701261624.10812.asmundg@snap.tv> Message-ID: <200701271838.35807.asmundg@snap.tv> On Friday 26 January 2007 19:51, Ross Finlayson wrote: > >Content-Type: multipart/signed; boundary="nextPart2156621.SsLREyNqSC"; > > protocol="application/pgp-signature"; micalg=pgp-sha1 > >Content-Transfer-Encoding: 7bit > > > >On Friday 26 January 2007 15:16, Ross Finlayson wrote: > >> Despite not being a standard, RAW/UDP streaming (for MPEG Transport > >> Stream data only) is requested by some prominent RTSP clients (most > >> notably Amino set-top boxes), and therefore we (reluctantly) support > >> it in our RTSP server implementation. All new RTSP clients, however, > >> should request standard RTP streaming only. > > > >Ok, thanks. That does, however, raise the question about the usefulness of > >supporting raw/udp multicast at all. Especially since Amino (and > >Kreatel/Motorola, for that matter) STBs don't seem to support multicast > > over rtsp anyway. > > And that raises the question of why you submitted a patch to support > RAW/UDP multicast, given that no known client supports it :-) :-) I > will, however, add your patch to the installed code, because it makes > it more consistent. Apparently, vlc will happily accept and request raw/udp (and we all know where vlc gets rtsp support from :)). Anyway, it seemed sensible to me, as I want to multicast from an mpeg2-ts source without adding rtp, and being able to do this with vlc is at least better than nothing. If you hadn't added the patch, I might have had to apply it manually on upgrades, so thanks again! -- ?smund Grammeltvedt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070127/10b7e108/attachment.bin From finlayson at live555.com Sat Jan 27 09:47:59 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 27 Jan 2007 09:47:59 -0800 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: <200701271838.35807.asmundg@snap.tv> References: <200701231729.47453.asmundg@snap.tv> <200701261624.10812.asmundg@snap.tv> <200701271838.35807.asmundg@snap.tv> Message-ID: > > And that raises the question of why you submitted a patch to support >> RAW/UDP multicast, given that no known client supports it :-) :-) I >> will, however, add your patch to the installed code, because it makes >> it more consistent. > >Apparently, vlc will happily accept and request raw/udp (and we all know where >vlc gets rtsp support from :)) VLC currently uses the "LIVE555 Streaming Media" code only for its RTSP *client* implementation. As a RTSP client, VLC (correctly) requests RTP streaming only. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jan 27 10:59:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 27 Jan 2007 10:59:45 -0800 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: <45BB6C41.1050205@gmail.com> References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> <45BB6C41.1050205@gmail.com> Message-ID: Although it's going to be a little bit awkward in your case, you should be able to handle any changes to your "ServerMediaSession" state by simply removing the existing "ServerMediaSession" object, and then creating a new one (adding new "ServerMediaSubsession" objects as appropriate). If you do this, you won't need any of the three changes to the "ServerMediaSession" code that you're requesting. Therefore, I don't feel that this motivates changing the existing code at this time. Sorry. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andrew.voznytsa at gmail.com Sat Jan 27 12:25:00 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sat, 27 Jan 2007 22:25:00 +0200 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> <45BB6C41.1050205@gmail.com> Message-ID: <45BBB51C.4040509@gmail.com> Ross Finlayson wrote: > Although it's going to be a little bit awkward in your case, you > should be able to handle any changes to your "ServerMediaSession" > state by simply removing the existing "ServerMediaSession" object, > and then creating a new one (adding new "ServerMediaSubsession" > objects as appropriate). If you do this, you won't need any of the > three changes to the "ServerMediaSession" code that you're > requesting. Therefore, I don't feel that this motivates changing the > existing code at this time. Sorry. Sorry for disturbing you again - I'd propose another solution: a) I'll leave addSubession() as it is b) removeSubsession(), after removing desired subsession, will reassing track numbers for rest of subsession's (I'll send new patch if we agree). c) It is not possible to solve my problem as you propose, removing exisint session and creating a new one, because in my case it is possible to change source of live content on the fly, in run time, without stopping streaming. Therefore there is only one possible way to update s=/i= - generate new SDP as I proposed before. P.S. What about RTPSink::rtpmapLine() - will you make it virtual? -- Best regards, Andrew Voznytsa From finlayson at live555.com Sat Jan 27 15:19:12 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 27 Jan 2007 15:19:12 -0800 Subject: [Live-devel] RTPSink::rtpmapLine() In-Reply-To: <45BB6596.8060401@gmail.com> References: <45BB6596.8060401@gmail.com> Message-ID: >Since streaming to brain-damaging boxes is rather unusual task I'd ask >to just make rtpmapLine() virtual. I'll do this (reluctantly), starting with the next release. However, you should ask for a new firmware revision for your 'black box'. Section 6 of the SDP specification states quite clearly that the "/" string (in this case, "/") is optional, especially if is 1. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sat Jan 27 15:50:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sat, 27 Jan 2007 15:50:21 -0800 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: <45BBB51C.4040509@gmail.com> References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> <45BB6C41.1050205@gmail.com> <45BBB51C.4040509@gmail.com> Message-ID: >c) It is not possible to solve my problem as you propose, removing >exisint session and creating a new one, because in my case it is >possible to change source of live content on the fly, in run time, >without stopping streaming. Therefore there is only one possible way to >update s=/i= - generate new SDP as I proposed before. The best solution here would be to add - to "ServerMediaSession" - new member functions to allow changing the "info" and "description" strings. These will be easy to do, and I'll probably add them at some point (perhaps in time for the next software release). However, I still don't see much motivation for adding a member function to remove "ServerMediaSubsession" objects from a "ServerMediaSession" so I'm not going to add complexity to the code by doing this anytime soon (if its only purpose is to make one hobbyist project a little easier). (BTW, I don't understand why you're dealing with the Darwin Streaming Server at all. We have a perfectly good RTSP server implementation (that uses the "ServerMediaS(ubs)ession" objects that you're creating), so you should just use that. In any case, if you really want to relay through a Darwin Streaming Server, then you could use our "DarwinInjector" class (and note the "*Darwin*" test programs that use this).) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andrew.voznytsa at gmail.com Sun Jan 28 05:14:13 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sun, 28 Jan 2007 15:14:13 +0200 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> <45BB6C41.1050205@gmail.com> <45BBB51C.4040509@gmail.com> Message-ID: <45BCA1A5.3010907@gmail.com> Ross Finlayson wrote: >> c) It is not possible to solve my problem as you propose, removing >> exisint session and creating a new one, because in my case it is >> possible to change source of live content on the fly, in run time, >> without stopping streaming. Therefore there is only one possible way to >> update s=/i= - generate new SDP as I proposed before. > > The best solution here would be to add - to "ServerMediaSession" - > new member functions to allow changing the "info" and "description" > strings. These will be easy to do, and I'll probably add them at > some point (perhaps in time for the next software release). I need to think how to resolve design issues. If I decided to recreate session object instead of patching each new version of liveMedia (patching should be easy - I don't expect that ServerMediaSession.[hh,cpp] will be frequently changed) then I will add member functions to allow changing the "info" and "description" strings at run time and send you new patch. > > However, I still don't see much motivation for adding a member > function to remove "ServerMediaSubsession" objects from a > "ServerMediaSession" so I'm not going to add complexity to the code > by doing this anytime soon (if its only purpose is to make one > hobbyist project a little easier). Actually agree - both solutions (mine and yours) are a bit ugly. I think something else will be found at the end. > > (BTW, I don't understand why you're dealing with the Darwin Streaming > Server at all. We have a perfectly good RTSP server implementation > (that uses the "ServerMediaS(ubs)ession" objects that you're > creating), so you should just use that. In any case, if you really I did not fully explain what my software is. You can think about as DirectShow-based encoder application, which can use file or capture device as media source, encode content into specified format, save it into file or push to network (unicast/multicast) describing streamed content using SDP file. In network case _any_ client, which supports initialization through .sdp file, could be used to receive broadcast. My other project uses "ServerMediaS(ubs)ession" objects plus RTSPServer to build specialized streaming server. You even get patches (initiated by http://lists.live555.com/pipermail/live-devel/2006-August/004937.html). > want to relay through a Darwin Streaming Server, then you could use > our "DarwinInjector" class (and note the "*Darwin*" test programs > that use this).) Actually disagree - in case of DarwinInjector you use RTSP ANNOUNCE and if I understood it correctly - upload file to server's side (I saw some comment in your code saying that I need write access to Darwin's movie directory). In my case it works like true relay, without temporal storage. Also DarwinIbject is much more limited solution than mine (i.e. you won't be able to play content without having Darwin server). -- Best regards, Andrew Voznytsa From andrew.voznytsa at gmail.com Sun Jan 28 06:21:56 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sun, 28 Jan 2007 16:21:56 +0200 Subject: [Live-devel] frame skiping during streaming Message-ID: <45BCB184.70800@gmail.com> Hello all, Let's assume that in this case all frames are key frames (sync point/I frame/IDR frame/etc), fps is constant, size of each frame is constant. Presentation time of any frame in terms of file timeline is frame index * MILLION / fps. RTP presentation time is 'initial gettimeofday()' + file presentation time. So consider next samples: A) 1) I sent 0 frame from the file. Presentation time 0, duration = MILLION / fps 2) I skip N frames 3) I sent N + 1 frame. Presentation time (N + 1) * MILLION / fps, duration = MILLION / fps 4) end of stream B) 1) I sent 0 frame from the file. Presentation time 0. Decide N for step step 2, duration = (1 + N) * MILLION / fps 2) I skip N frames 3) I sent N + 1 frame. Presentation time (N + 1) * MILLION / fps, duration = MILLION / fps 4) end of stream I noticed some problems with A. After consideration I got conclusion that I've to modify duration at step 1 (Sample B). Before I start with implementation - could anyone confirm that it is right? Or, if I missed something, could you please point me in right direction? -- Best regards, Andrew Voznytsa From finlayson at live555.com Sun Jan 28 07:08:56 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Jan 2007 07:08:56 -0800 Subject: [Live-devel] frame skiping during streaming In-Reply-To: <45BCB184.70800@gmail.com> References: <45BCB184.70800@gmail.com> Message-ID: Neither of your choices is correct. If you skip frames in the underlying medium at the server (e.g., to seek, or to implement 'fast forward'), it does not effect the presentation times of the stream that actually gets sent. "Presentation time" means just that - the time that frames are 'presented' (displayed) on the receiver's screen. The receiver still sees a normal-looking stream; it's only the underlying *content* that might have been shifted around. So, using your example, *each* frame that you send has a duration of MILLION. The presentation time of the first frame that you send is 0; the second 1*MILLION/fps; the third 2*MILLION/fps, etc. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Sun Jan 28 07:25:17 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Jan 2007 07:25:17 -0800 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: <45BCA1A5.3010907@gmail.com> References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> <45BB6C41.1050205@gmail.com> <45BBB51C.4040509@gmail.com> <45BCA1A5.3010907@gmail.com> Message-ID: > > (BTW, I don't understand why you're dealing with the Darwin Streaming >> Server at all. We have a perfectly good RTSP server implementation >> (that uses the "ServerMediaS(ubs)ession" objects that you're >> creating), so you should just use that. In any case, if you really > >I did not fully explain what my software is. You can think about as >DirectShow-based encoder application, which can use file or capture >device as media source, encode content into specified format, save it >into file or push to network (unicast/multicast) describing streamed >content using SDP file. In network case _any_ client, which supports >initialization through .sdp file, could be used to receive broadcast. That's true only for multicast streams. For unicast streams, a client cannot just 'read a SDP file'; it *must* use the RTSP protocol to (i) get the SDP description, and (ii) tell the server which IP address and port numbers it should send the stream to. (But a client can also use RTSP to receive a multicast stream, so you might as well use RTSP in either case. I'm not aware of any client that can read a SDP file, but which doesn't also support RTSP.) If you plan on supporting unicast transmission (especially if you want to support multiple concurrent clients), then you definitely need a RTSP server, and it's much better to use our server implementation than to have to rely upon a separate 'Darwin' server. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andrew.voznytsa at gmail.com Sun Jan 28 08:13:46 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sun, 28 Jan 2007 18:13:46 +0200 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> <45BB6C41.1050205@gmail.com> <45BBB51C.4040509@gmail.com> <45BCA1A5.3010907@gmail.com> Message-ID: <45BCCBBA.8020704@gmail.com> Ross Finlayson wrote: >> > (BTW, I don't understand why you're dealing with the Darwin Streaming >>> Server at all. We have a perfectly good RTSP server implementation >>> (that uses the "ServerMediaS(ubs)ession" objects that you're >>> creating), so you should just use that. In any case, if you really >> I did not fully explain what my software is. You can think about as >> DirectShow-based encoder application, which can use file or capture >> device as media source, encode content into specified format, save it >> into file or push to network (unicast/multicast) describing streamed >> content using SDP file. In network case _any_ client, which supports >> initialization through .sdp file, could be used to receive broadcast. > > That's true only for multicast streams. For unicast streams, a > client cannot just 'read a SDP file'; it *must* use the RTSP protocol > to (i) get the SDP description, and All info required to configure client to receive streams is already in SDP (in my case or in case of applications similar to mine, see Helix Mobile Producer for example) (ii) tell the server which IP > address and port numbers it should send the stream to. (But a client > can also use RTSP to receive a multicast stream, so you might as well > use RTSP in either case. I'm not aware of any client that can read a > SDP file, but which doesn't also support RTSP.) Before starting to encode my application is configured with destination IP, port and ttl. This info is saved into SDP for clients. > > If you plan on supporting unicast transmission (especially if you > want to support multiple concurrent clients), then you definitely > need a RTSP server, and it's much better to use our server > implementation than to have to rely upon a separate 'Darwin' server. In my specific case using separate Darwin server is better. Just two reasons: a) customer is paying for this b) there is pre-built network with already configured and tested streaming servers. Why to change something there? My solution does not affect anything in network configuration, especially security issues. -- Best regards, Andrew Voznytsa From andrew.voznytsa at gmail.com Sun Jan 28 08:25:30 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sun, 28 Jan 2007 18:25:30 +0200 Subject: [Live-devel] frame skiping during streaming In-Reply-To: References: <45BCB184.70800@gmail.com> Message-ID: <45BCCE7A.1010103@gmail.com> Ross Finlayson wrote: > Neither of your choices is correct. If you skip frames in the > underlying medium at the server (e.g., to seek, or to implement 'fast > forward'), it does not effect the presentation times of the stream > that actually gets sent. "Presentation time" means just that - the > time that frames are 'presented' (displayed) on the receiver's > screen. The receiver still sees a normal-looking stream; it's only > the underlying *content* that might have been shifted around. > > So, using your example, *each* frame that you send has a duration of > MILLION. The presentation time of the first frame that you send is > 0; the second 1*MILLION/fps; the third 2*MILLION/fps, etc. Sorry, I misunderstood or it won't work. If after sending frame 0 I skip N frames and assign presentation time 1*MILLION/fps for N+1 frame then I'll just lose audio/video sync because I'm not skipping audio samples. (Skipping was meant for video only, source media has two streams: audio and video). If I plan to skip a few frames just after current frame then current frame should be displayed longer, until timeline won't reach presentation time of next frame. It seems that current liveMedia implementation does not take into account presentation time when schedules next getNextFrame() but uses frame duration. Therefore, If I was skipping frames to lower bandwidth usage it won't help because video will be sent at the same rate. -- Best regards, Andrew Voznytsa From finlayson at live555.com Sun Jan 28 10:30:12 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Jan 2007 10:30:12 -0800 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: <45BCCBBA.8020704@gmail.com> References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> <45BB6C41.1050205@gmail.com> <45BBB51C.4040509@gmail.com> <45BCA1A5.3010907@gmail.com> <45BCCBBA.8020704@gmail.com> Message-ID: >a) customer is paying for this I would never pay for services from someone who uses a "@gmail.com" email address. If you want to be taken seriously, you should really start using a professional email address. (Often, when deciding whether or not to answer messages on this mailing list, I use the sender's email address as a first-level filter.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andrew.voznytsa at gmail.com Sun Jan 28 11:07:54 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sun, 28 Jan 2007 21:07:54 +0200 Subject: [Live-devel] ServerMediaSession.patch In-Reply-To: References: 438567054C073949AEBE5A28B83E7DE133FC8C@MAIL21.student.main.ntu.edu.sg <45BB5BB2.7090607@gmail.com> <45BB6C41.1050205@gmail.com> <45BBB51C.4040509@gmail.com> <45BCA1A5.3010907@gmail.com> <45BCCBBA.8020704@gmail.com> Message-ID: <45BCF48A.6070803@gmail.com> Ross Finlayson wrote: >> a) customer is paying for this > > I would never pay for services from someone who uses a "@gmail.com" > email address. If you want to be taken seriously, you should really > start using a professional email address. > > (Often, when deciding whether or not to answer messages on this > mailing list, I use the sender's email address as a first-level > filter.) Just imagine - if I'm earning enough using "@gmail.com" then what will happen if I get "professional email address"? Maybe someone will be out of work :) P.S. IMO if you wish we may continue this holy war directly. Public mail list is not right place. -- Best regards, Andrew Voznytsa From finlayson at live555.com Sun Jan 28 11:12:30 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Jan 2007 11:12:30 -0800 Subject: [Live-devel] frame skiping during streaming In-Reply-To: <45BCCE7A.1010103@gmail.com> References: <45BCB184.70800@gmail.com> <45BCCE7A.1010103@gmail.com> Message-ID: >Sorry, I misunderstood or it won't work. > >If after sending frame 0 I skip N frames and assign presentation time >1*MILLION/fps for N+1 frame then I'll just lose audio/video sync because >I'm not skipping audio samples. > >(Skipping was meant for video only, source media has two streams: audio >and video). OK, that was an important piece of information that should have been mentioned before. In this case, then, each video frame's presentation time needs to match that of the audio frame with which it is synchronized. *In principle*, the "fDurationInMicroseconds" value for a frame should be the difference in presentation times between this frame, and the next frame that you'll send. However, I can see that this would be difficult if you don't know in advance which future frames you're going to be skipping. *In practice*, however, for (outgoing) RTP streaming, the "fDurationInMicroseconds" value serves only to tell the "MultiFramedRTPSink" class how long to wait, after sending each packet, before asking the input source for new data. Therefore, in your case, you can leave the "fDurationInMicroseconds" field to be the normal duration of a single frame, but change your input source to delay appropriately (using "TaskScheduler::scheduleDelayedTask()") before calling "FramedSource::afterGetting()", if you decide to skip one or more frames. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From andrew.voznytsa at gmail.com Sun Jan 28 12:09:37 2007 From: andrew.voznytsa at gmail.com (Andrew Voznytsa) Date: Sun, 28 Jan 2007 22:09:37 +0200 Subject: [Live-devel] frame skiping during streaming In-Reply-To: References: <45BCB184.70800@gmail.com> <45BCCE7A.1010103@gmail.com> Message-ID: <45BD0301.2010806@gmail.com> Ross Finlayson wrote: >> Sorry, I misunderstood or it won't work. >> >> If after sending frame 0 I skip N frames and assign presentation time >> 1*MILLION/fps for N+1 frame then I'll just lose audio/video sync because >> I'm not skipping audio samples. >> >> (Skipping was meant for video only, source media has two streams: audio >> and video). > > OK, that was an important piece of information that should have been > mentioned before. In this case, then, each video frame's > presentation time needs to match that of the audio frame with which > it is synchronized. > > *In principle*, the "fDurationInMicroseconds" value for a frame > should be the difference in presentation times between this frame, > and the next frame that you'll send. However, I can see that this > would be difficult if you don't know in advance which future frames > you're going to be skipping. > > *In practice*, however, for (outgoing) RTP streaming, the > "fDurationInMicroseconds" value serves only to tell the > "MultiFramedRTPSink" class how long to wait, after sending each > packet, before asking the input source for new data. Then *principal* solution would be better because of more smooth RTP streaming (MultiFramedRTPSink will have more time to send frame). Thanks for help, I'll implement principal solution - it is more complicated but will give better results. -- Best regards, Andrew Voznytsa From rishikerala at gmail.com Sun Jan 28 16:58:02 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Mon, 29 Jan 2007 09:58:02 +0900 Subject: [Live-devel] Try to make Index file for H264 over mpeg2ts Message-ID: <4ba29cc0701281658p4c875f26ia9315073a22c8063@mail.gmail.com> Hi all, Can any one please tell me , when I try to create a index file for H264 over mpeg2ts , It shows empty file. whether this support is not included in live. Hi ross please give me a solution to port live555 to my board. Rgds rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070128/6fa45433/attachment-0001.html From finlayson at live555.com Sun Jan 28 18:05:43 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Jan 2007 18:05:43 -0800 Subject: [Live-devel] Try to make Index file for H264 over mpeg2ts In-Reply-To: <4ba29cc0701281658p4c875f26ia9315073a22c8063@mail.gmail.com> References: <4ba29cc0701281658p4c875f26ia9315073a22c8063@mail.gmail.com> Message-ID: >Can any one please tell me , when I try to create a index file for >H264 over mpeg2ts , It shows empty file. >whether this support is not included in live. The trick play indexing mechanism currently works only on MPEG Transport Stream files that contain a MPEG-1 or 2 video stream - not MPEG-4 (including H.264) video. However, if you put an example H.264 MPEG Transport Stream file on a web server, and post the URL, I'll download it, and look into what would be required to support indexing on such a file. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rishikerala at gmail.com Sun Jan 28 18:40:18 2007 From: rishikerala at gmail.com (Rishi kerala) Date: Mon, 29 Jan 2007 11:40:18 +0900 Subject: [Live-devel] Need a help to port the Live555 client player.. Message-ID: <4ba29cc0701281840r10d44892t93c65b475d51e82@mail.gmail.com> Hi all, I am trying for last one month to port the live555 to my board. please help me if any one is successfull in this. I have a VLC structure buffer. I have to prebuffer before I pass to the hardware player. Please help me how can I read with this syncronization. tk->readSource->getNextFrame(fBuffer, fileSinkBufferSize, afterGettingF,tk, onSourceClosure, tk); rtsptime = timeOutCheck(ourClient); sessionTimerTask = env->taskScheduler().scheduleDelayedTask(300000,TaskInterrupt, (void *) NULL); fprintf(stderr,"Fbuffer-- main--%u\n",(unsigned int)fBuffer); env->taskScheduler().doEventLoop(&task); env->taskScheduler().unscheduleDelayedTask(sessionTimerTask); please give me some suggestion how to get the buffer. when ever I asked to read() (using a function). Rgds Rishi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070128/8747019b/attachment.html From yunjnz at yahoo.com Sun Jan 28 20:23:46 2007 From: yunjnz at yahoo.com (Sean) Date: Sun, 28 Jan 2007 20:23:46 -0800 (PST) Subject: [Live-devel] About playing from byte offset Message-ID: <20070129042347.61022.qmail@web35808.mail.mud.yahoo.com> Greetings, I would like to play rtsp video from specified bytes offset, does it support by Live555 library on Client and Server? If not, how can I implement it? Appreciate, Sean. ____________________________________________________________________________________ Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 From finlayson at live555.com Sun Jan 28 20:46:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Jan 2007 20:46:14 -0800 Subject: [Live-devel] About playing from byte offset In-Reply-To: <20070129042347.61022.qmail@web35808.mail.mud.yahoo.com> References: <20070129042347.61022.qmail@web35808.mail.mud.yahoo.com> Message-ID: >Greetings, > >I would like to play rtsp video from specified bytes >offset, >does it support by Live555 library on Client and >Server? Yes. Please read the FAQ http://www.live555.com/liveMedia/faq.html#trick-mode -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070128/684113fb/attachment.html From yunjnz at yahoo.com Sun Jan 28 22:22:47 2007 From: yunjnz at yahoo.com (Sean) Date: Sun, 28 Jan 2007 22:22:47 -0800 (PST) Subject: [Live-devel] About playing from byte offset In-Reply-To: Message-ID: <20070129062248.60578.qmail@web35809.mail.mud.yahoo.com> --- Ross Finlayson wrote: > >Greetings, > > > >I would like to play rtsp video from specified > bytes > >offset, > >does it support by Live555 library on Client and > >Server? > > Yes. Please read the FAQ > > http://www.live555.com/liveMedia/faq.html#trick-mode > -- After reading the FAQ, it seems that the Live555 doesn't support byte offset seek currently, doesn't it? If I want to implement this feature for MPEG2TS video file, how to implement it? Thanks. Sean. > > 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 > ____________________________________________________________________________________ Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail From finlayson at live555.com Sun Jan 28 22:33:59 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 28 Jan 2007 22:33:59 -0800 Subject: [Live-devel] About playing from byte offset In-Reply-To: <20070129062248.60578.qmail@web35809.mail.mud.yahoo.com> References: <20070129062248.60578.qmail@web35809.mail.mud.yahoo.com> Message-ID: >--- Ross Finlayson wrote: > >> >Greetings, >> > >> >I would like to play rtsp video from specified >> bytes >> >offset, >> >does it support by Live555 library on Client and >> >Server? >> >> Yes. Please read the FAQ >> > > http://www.live555.com/liveMedia/faq.html#trick-mode >> -- > >After reading the FAQ, it seems that the Live555 >doesn't support byte offset seek currently, doesn't >it? Yes we do support this. Read the FAQ again! (Hint: The feature you're looking for is "seeking".) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ved.kpl at gmail.com Mon Jan 29 00:31:37 2007 From: ved.kpl at gmail.com (ved kpl) Date: Mon, 29 Jan 2007 14:01:37 +0530 Subject: [Live-devel] Mpeg 2 ts trickplay Message-ID: <7496c23f0701290031y62a9c8fesed730be75ef92d4a@mail.gmail.com> Hi I have some questions regarding the mpeg 2 ts trickplay. Whenever a pause, or rewind or a forward is issued, i read the last I frame that was sent from an I frames file. (i separate out the I frames as ts packets are sent). Generate the ts packets and stream them. Ok, sounds fine till this point (i hope). NOW, when in normal streaming the PCR difference is abt 33 ms. But when in trickplay ,i insert any random PCR value at the start (and also set the discontinuity indicator) and increment ithe PCR by 40 ms (mpeg2,frame rate = 25) for every i frame. So PCRs are present only at the start of every I frame. They never come in between. I m streaming it to an amino set up box. It's working fine. I would like to know whether it is efficient. And regarding pause, i keep on sending same frame . is this fine too? I pipe the output of my program to live555 mpeg2tsFramer, basic udpsink. regds v -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070129/0d1b0936/attachment.html From finlayson at live555.com Mon Jan 29 00:50:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Jan 2007 00:50:55 -0800 Subject: [Live-devel] Mpeg 2 ts trickplay In-Reply-To: <7496c23f0701290031y62a9c8fesed730be75ef92d4a@mail.gmail.com> References: <7496c23f0701290031y62a9c8fesed730be75ef92d4a@mail.gmail.com> Message-ID: >I have some questions regarding the mpeg 2 ts trickplay. >Whenever a pause, or rewind or a forward is issued, i >read the last I frame that was sent from an I frames file. >(i separate out the I frames as ts packets are sent). >Generate the ts packets and stream them. >Ok, sounds fine till this point (i hope). >NOW, when in normal streaming the PCR difference >is abt 33 ms. But when in trickplay ,i insert any random PCR value >at the start (and also set the discontinuity indicator) and >increment ithe PCR by 40 ms (mpeg2,frame rate = 25) >for every i frame. >So PCRs are present only at the start of every I frame. They never >come in between. >I m streaming it to an amino set up box. It's working fine. >I would like to know whether it is efficient. >And regarding pause, i keep on sending same frame . is this fine too? >I pipe the output of my program to live555 mpeg2tsFramer, basic udpsink. I'm confused. Are you referring to the support for MPEG-2 Transport Stream 'trick play' (using 'index files') that was recently added to the released "LIVE555 Streaming Media" software (see ), or are you instead referring to some new software that you wrote yourself that intends to do the same thing? (If it's the latter, then I'm not going to be able to help you - we can only provide support for the original software that you download from our web site.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070129/d5240f09/attachment.html From rajeshkumar.r at imimobile.com Mon Jan 29 02:03:06 2007 From: rajeshkumar.r at imimobile.com (rajesh) Date: Mon, 29 Jan 2007 15:33:06 +0530 Subject: [Live-devel] How to download content from streaming Server to openRTSP client Message-ID: <005f01c7438c$abe87850$6902000a@imidomain.com> Hi Ross I am using Helix Server for Streaming Purpose.Helix Server is using one 3gp file for streaming purpose. openRTSP is able to recvd the streaming contents.I want to download the file as it is. How can i do this with Regards Rajesh. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070129/e9de6fc2/attachment.html From ved.kpl at gmail.com Mon Jan 29 03:10:03 2007 From: ved.kpl at gmail.com (ved kpl) Date: Mon, 29 Jan 2007 16:40:03 +0530 Subject: [Live-devel] Mpeg 2 ts trickplay In-Reply-To: <7496c23f0701290031y62a9c8fesed730be75ef92d4a@mail.gmail.com> References: <7496c23f0701290031y62a9c8fesed730be75ef92d4a@mail.gmail.com> Message-ID: <7496c23f0701290310g562548ceice63bfd749db0789@mail.gmail.com> Hi Ross, it's the latter one. On 1/29/07, ved kpl wrote: > > Hi > > I have some questions regarding the mpeg 2 ts trickplay. > Whenever a pause, or rewind or a forward is issued, i > read the last I frame that was sent from an I frames file. > (i separate out the I frames as ts packets are sent). > Generate the ts packets and stream them. > Ok, sounds fine till this point (i hope). > NOW, when in normal streaming the PCR difference > is abt 33 ms. But when in trickplay ,i insert any random PCR value > at the start (and also set the discontinuity indicator) and increment ithe > PCR by 40 ms (mpeg2,frame rate = 25) > for every i frame. > So PCRs are present only at the start of every I frame. They never come in > between. > I m streaming it to an amino set up box. It's working fine. > I would like to know whether it is efficient. > And regarding pause, i keep on sending same frame . is this fine too? > I pipe the output of my program to live555 mpeg2tsFramer, basic udpsink. > > regds > v > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070129/627cf1f9/attachment-0001.html From mrnikhilagrawal at gmail.com Mon Jan 29 05:13:47 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Mon, 29 Jan 2007 18:43:47 +0530 Subject: [Live-devel] Regarding 'Pause' in Live555 Message-ID: <733cde3e0701290513j93cc961lcf067ce7354b3fb2@mail.gmail.com> Hi Ross, I tries PAUSE feature of Live555. First I streamed a wav file. In between, I paused the stream , it stopped successfully but when I played it , it was not playable properly, in VLC. It plays a word then stops for a 2-3 sec , then plays a word then again stops and so on... ( same problem when used RealPlayer but occured after 4-5 times pausing , it went into endless buffering deadlock) Next I tried to stream Audio+Video Prograam Stream ( .mpg file) , when I paused the stream using VLC , it got paused successfully , and when I played it , it continued without any problem . But second time when I paused and played it , it shows only video and no vioce there after (in successive pause and play). I also looked into the code little bit and saw it was working corrrectly as expected ( Pause + Play = Stop + Seek + Play). Can you tell me where I am wrong. Regards, Nikhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070129/7b4774ec/attachment.html From asmundg at snap.tv Mon Jan 29 04:54:34 2007 From: asmundg at snap.tv (=?utf-8?q?=C3=85smund_Grammeltvedt?=) Date: Mon, 29 Jan 2007 13:54:34 +0100 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: References: <200701231729.47453.asmundg@snap.tv> <200701271838.35807.asmundg@snap.tv> Message-ID: <200701291354.39874.asmundg@snap.tv> On Saturday 27 January 2007 18:47, Ross Finlayson wrote: > VLC currently uses the "LIVE555 Streaming Media" code only for its > RTSP *client* implementation. As a RTSP client, VLC (correctly) > requests RTP streaming only. Unless I'm reading this completely wrong, it does seem like VLC requests RAW/UDP (when coerced by the SDP). Using RTP would of course have been way more standards compliant, but having to make the same stream available to STBs appears to rule out that option. Compromises, compromises. accept()ed connection from 192.168.43.97 RTSPClientSession[0x80e9658]::incomingRequestHandler1() read 146 bytes:OPTIONS rtsp://192.168.43.1/LIVE_3sat.de.xmltv.snap.tv RTSP/1.0 CSeq: 1 User-Agent: VLC media player (LIVE555 Streaming Media v2006.07.03) parseRTSPRequestString() returned cmdName "OPTIONS", urlPreSuffix "", urlSuffix "LIVE_3sat.de.xmltv.snap.tv" sending response: RTSP/1.0 200 OK CSeq: 1 Date: Mon, Jan 29 2007 12:36:12 GMT Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE RTSPClientSession[0x80e9658]::incomingRequestHandler1() read 172 bytes:DESCRIBE rtsp://192.168.43.1/LIVE_3sat.de.xmltv.snap.tv RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: VLC media player (LIVE555 Streaming Media v2006.07.03) parseRTSPRequestString() returned cmdName "DESCRIBE", urlPreSuffix "", urlSuffix "LIVE_3sat.de.xmltv.snap.tv" sending response: RTSP/1.0 200 OK CSeq: 2 Date: Mon, Jan 29 2007 12:36:12 GMT Content-Base: rtsp://192.168.43.1/LIVE_3sat.de.xmltv.snap.tv/ Content-Type: application/sdp Content-Length: 400 v=0 o=- 1170074172300486 1 IN IP4 192.168.43.1 s=SnapTV Live i=LIVE_3sat.de.xmltv.snap.tv t=0 0 a=tool:LIVE555 Streaming Media v2007.01.17 a=type:broadcast a=control:* a=source-filter: incl IN IP4 * 192.168.43.1 a=rtcp-unicast: reflection a=range:npt=0- a=x-qt-text-nam:SnapTV Live a=x-qt-text-inf:LIVE_3sat.de.xmltv.snap.tv m=video 1234 udp 33 c=IN IP4 239.1.1.11/1 a=control:track1 RTSPClientSession[0x80e9658]::incomingRequestHandler1() read 201 bytes:SETUP rtsp://192.168.43.1/LIVE_3sat.de.xmltv.snap.tv/ RTSP/1.0 CSeq: 3 Transport: RAW/RAW/UDP;multicast;client_port=1234-1235 User-Agent: VLC media player (LIVE555 Streaming Media v2006.07.03) parseRTSPRequestString() returned cmdName "SETUP", urlPreSuffix "LIVE_3sat.de.xmltv.snap.tv", urlSuffix "" sending response: RTSP/1.0 200 OK CSeq: 3 Date: Mon, Jan 29 2007 12:36:12 GMT Transport: RAW/RAW/UDP;multicast;destination=239.1.1.11;client_port=1234;server_port=1234;port=1234 Session: 2 RTSPClientSession[0x80e9658]::incomingRequestHandler1() read 174 bytes:PLAY rtsp://192.168.43.1/LIVE_3sat.de.xmltv.snap.tv RTSP/1.0 CSeq: 4 Session: 2 Range: npt=0.000- User-Agent: VLC media player (LIVE555 Streaming Media v2006.07.03) parseRTSPRequestString() returned cmdName "PLAY", urlPreSuffix "", urlSuffix "LIVE_3sat.de.xmltv.snap.tv" sending response: RTSP/1.0 200 OK CSeq: 4 Date: Mon, Jan 29 2007 12:36:12 GMT Range: npt=0.000- Session: 2 RTP-Info: url=rtsp://192.168.43.1/LIVE_3sat.de.xmltv.snap.tv/track1;seq=53579;rtptime=1551800363 -- ?smund Grammeltvedt Snap TV -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070129/3b9a5e95/attachment.bin From odjosc at free.fr Mon Jan 29 07:00:00 2007 From: odjosc at free.fr (odjosc at free.fr) Date: Mon, 29 Jan 2007 16:00:00 +0100 Subject: [Live-devel] RTSP source for VDR Message-ID: <1170082800.45be0bf0406e0@imp.free.fr> Hello, I'm currently developping a plugin for VDR (please see www.cadsoft.de/vdr/ for more info) to add a new source (e.g. input device). As my FAI is providing TV-broadcast through a RTSP server, I'm working on such interface with the help of LiveMedia library. Although I read many (tons ;-)) of documentation/sources on the subject, I'm currently stuck here : I need to get a file descriptor (socket num for example) which will provide me with the stream data (TS format) and only this one. The stream provided by my FAI contains only one subsession, identified by openRTSP test program as video/MP2T. I dig into documentation, test programs and VLC/MPlayer source code to figure how to achieve this without success. Here is what I did : 1- Create a new RTSPClient object 2- Open the URL and get the SDP description 3- Send an OPTIONS command to see which one are accepted by server 4- Create a media session from SDP description 5- Create RTP receivers for each subsession (well, only one here) 6- Issue a playMediaSession() call Steps 1-6 seem to work OK, even the last playing call but I don't know how to get the TS data through a file descriptor. I tried to read thru RTSPClient::socketNum but got no data at all. If I directly try via subsession->rtpSource()->RTPgs()->socketNum(), I get some data which don't seem to be TS stream... Any idea on this ? Thanks in advance, Olivier. From finlayson at live555.com Mon Jan 29 16:07:33 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Jan 2007 16:07:33 -0800 Subject: [Live-devel] raw/udp in rtsp multicast setup In-Reply-To: <200701291354.39874.asmundg@snap.tv> References: <200701231729.47453.asmundg@snap.tv> <200701271838.35807.asmundg@snap.tv> <200701291354.39874.asmundg@snap.tv> Message-ID: >Unless I'm reading this completely wrong, it does seem like VLC requests >RAW/UDP (when coerced by the SDP). Yes, I stand corrected. I had forgotten that I had added that code. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 29 16:13:04 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Jan 2007 16:13:04 -0800 Subject: [Live-devel] Regarding 'Pause' in Live555 In-Reply-To: <733cde3e0701290513j93cc961lcf067ce7354b3fb2@mail.gmail.com> References: <733cde3e0701290513j93cc961lcf067ce7354b3fb2@mail.gmail.com> Message-ID: >Hi Ross, > >I tries PAUSE feature of Live555. > >First I streamed a wav file. In between, I paused the stream , it >stopped successfully but when I played it , it was not playable >properly, in VLC. It plays a word then stops for a 2-3 sec , then >plays a word then again stops and so on... ( same problem when used >RealPlayer but occured after 4-5 times pausing , it went into >endless buffering deadlock) > >Next I tried to stream Audio+Video Prograam Stream ( .mpg file) , >when I paused the stream using VLC , it got paused successfully , >and when I played it , it continued without any problem . But second >time when I paused and played it , it shows only video and no vioce >there after (in successive pause and play). > >I also looked into the code little bit and saw it was working >corrrectly as expected ( Pause + Play = Stop + Seek + Play). > >Can you tell me where I am wrong. I believe that this is a problem with VLC. As far as I can tell, our RTSP server handles RTSP "PAUSE" correctly (and WAV audio files are a good medium to test this with, because of their simplicity). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Jan 29 16:26:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 29 Jan 2007 16:26:40 -0800 Subject: [Live-devel] RTSP source for VDR In-Reply-To: <1170082800.45be0bf0406e0@imp.free.fr> References: <1170082800.45be0bf0406e0@imp.free.fr> Message-ID: >I'm currently developping a plugin for VDR (please see www.cadsoft.de/vdr/ for >more info) to add a new source (e.g. input device). As my FAI is providing >TV-broadcast through a RTSP server, I'm working on such interface >with the help >of LiveMedia library. [...] >Steps 1-6 seem to work OK, even the last playing call but I don't know how to >get the TS data through a file descriptor. You don't. If your incoming TS data is coming from a RTSP stream, then it will be coming in on a LIVE555 "MediaSource" object - in your case "subsession->readSource()". To receive this data, you must feed it to a "MediaSink" object, and call sink->startPlaying(). See the "openRTSP" code ("playCommon.cpp") for examples of this; "openRTSP" uses "FileSink" objects to store the incoming data. I.e., you must write an appropriate "MediaSink" object to handle the incoming TS data. (However, if you plan to just store this in a file, then you can use most of the "openRTSP" code as is. Or, you can just run "openRTSP" with the "-v" option, to get the incoming TS data written to 'stdout'.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From odjosc at free.fr Tue Jan 30 06:54:42 2007 From: odjosc at free.fr (odjosc at free.fr) Date: Tue, 30 Jan 2007 15:54:42 +0100 Subject: [Live-devel] RTSP source for VDR In-Reply-To: References: <1170082800.45be0bf0406e0@imp.free.fr> Message-ID: <1170168882.45bf5c3265b63@imp.free.fr> Hi, First, thanks for your response. > [...] > > >Steps 1-6 seem to work OK, even the last playing call but I don't know how > to > >get the TS data through a file descriptor. > > You don't. If your incoming TS data is coming from a RTSP stream, > then it will be coming in on a LIVE555 "MediaSource" object - in your > case "subsession->readSource()". To receive this data, you must feed > it to a "MediaSink" object, and call sink->startPlaying(). See the > "openRTSP" code ("playCommon.cpp") for examples of this; "openRTSP" > uses "FileSink" objects to store the incoming data. > > I.e., you must write an appropriate "MediaSink" object to handle the > incoming TS data. (However, if you plan to just store this in a > file, then you can use most of the "openRTSP" code as is. Or, you > can just run "openRTSP" with the "-v" option, to get the incoming TS > data written to 'stdout'.) > -- Unfortunately, it's not that easy because I'm only writing a plugin for VDR. As far as I understand how it works, I can only tell VDR how to get the TS stream just creating a "buffer" object and specifying the descriptor to use (ex.: tsBuffer = new cTSBuffer(file_descriptor, buf_size, parm)). Then, the actual data is read via an embedded method : tsBuffer->Get. The goal is to display the stream "on the fly" (VDR is a Mediacenter application), so it won't be written into a file (well, at least not directly). Before reading your response, I made additionnal tests where I took data directly from the subsession's socket (as I wrote in my previous post) and it worked a few second...(although the frames were displayed slowly and had many artifacts). Then the RTSP server gave up, because of some buffer concern (well LiveMedia lib provides some data buffer management, so does VDR as well and those seem to conflict...). Reading your post I understand it shouldn't be done this way but as far as I don't have direct access to VDR buffer, I don't see how to provide it with the stream from FileSink Object. From info at dnastudios.it Tue Jan 30 07:15:53 2007 From: info at dnastudios.it (DNA Studios s.r.l.) Date: Tue, 30 Jan 2007 16:15:53 +0100 Subject: [Live-devel] problem with streaming Message-ID: <45BF6129.5070703@dnastudios.it> I have encoded a movie with x264 and ateme encoder; vlc play it ok in local but in streaming from DSS the audio play and the video don't play or play badly. There are the settings to disable in x264 or ateme encoder for the video streaming contents, some data that the live555 library don't receive from Darwin or that Darwin don't send? From finlayson at live555.com Tue Jan 30 09:57:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Jan 2007 09:57:55 -0800 Subject: [Live-devel] problem with streaming In-Reply-To: <45BF6129.5070703@dnastudios.it> References: <45BF6129.5070703@dnastudios.it> Message-ID: >I have encoded a movie with x264 and ateme encoder; vlc play it ok in >local but in streaming from DSS the audio play and the video don't play >or play badly. What about QuickTime Player? Does it play the stream properly? If it doesn't, then the problem is with whatever software you use to generate and/or hint your file. If QuickTime Player *does* play your stream properly, then the problem is with VLC (most likely), or the "LIVE555 Streaming Media" library (less likely, assuming you're using the latest version of VLC). In this case, let us know the (publically accessible) "rtsp://" URL of the stream, so we can test this for ourselves. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 30 10:13:55 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Jan 2007 10:13:55 -0800 Subject: [Live-devel] RTSP source for VDR In-Reply-To: <1170168882.45bf5c3265b63@imp.free.fr> References: <1170082800.45be0bf0406e0@imp.free.fr> <1170168882.45bf5c3265b63@imp.free.fr> Message-ID: > > I.e., you must write an appropriate "MediaSink" object to handle the >> incoming TS data. (However, if you plan to just store this in a >> file, then you can use most of the "openRTSP" code as is. Or, you >> can just run "openRTSP" with the "-v" option, to get the incoming TS >> data written to 'stdout'.) >> -- >Unfortunately, it's not that easy because I'm only writing a plugin for VDR. Therefore, you're going to have to figure out how to write such a 'plugin' that works with the "LIVE555 Streaming Media" event loop. Because I don't know anything about how such a plugin works - in particular, whether it has its own event loop (in which case you'd need to somehow merge it with ours), or whether it has its own thread, doing reads synchronously - I'm probably not going to be able to help you any more with this. I suggest consulting an appropriate mailing list for your VDR software. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From info at dnastudios.it Tue Jan 30 10:45:50 2007 From: info at dnastudios.it (DNA Studios s.r.l.) Date: Tue, 30 Jan 2007 19:45:50 +0100 Subject: [Live-devel] problem with streaming In-Reply-To: References: <45BF6129.5070703@dnastudios.it> Message-ID: <45BF925E.1000702@dnastudios.it> rtsp://85.18.216.107/test01.mp4 this is baseline profile (x264) hinted with mpeg4ip rtsp://85.18.216.107/test02.mp4 this is baseline profile (x264) hinted with QuickTime To see the videos you must enable the http tunneling (in vlc and in QT) In both cases the seeking with VLC *does* not work; with test01.mp4 after 35 seconds vlc crash?!?!? Ross Finlayson ha scritto: >> I have encoded a movie with x264 and ateme encoder; vlc play it ok in >> local but in streaming from DSS the audio play and the video don't play >> or play badly. >> > > What about QuickTime Player? Does it play the stream properly? If > it doesn't, then the problem is with whatever software you use to > generate and/or hint your file. > > If QuickTime Player *does* play your stream properly, then the > problem is with VLC (most likely), or the "LIVE555 Streaming Media" > library (less likely, assuming you're using the latest version of > VLC). In this case, let us know the (publically accessible) > "rtsp://" URL of the stream, so we can test this for ourselves. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070130/c741d701/attachment.html From xcsmith at rockwellcollins.com Tue Jan 30 11:18:09 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Tue, 30 Jan 2007 13:18:09 -0600 Subject: [Live-devel] ReceivingInterfaceAddr Message-ID: Hi Ross! I need my server and client to come up on eth1 instead of eth0. So in openRTSP I have the following lines at the beginning: ReceivingInterfaceAddr = our_inet_addr("10.145.223.23"); SendingInterfaceAddr = our_inet_addr("10.145.223.23"); // i got this from an old mailing list entry, maybe linked from FAQ? When I try to use openRTSP to record from an RTSP server on an external device which is sending a multicast stream, it looks like everything goes OK, but actually the file only gets created and does not get any data written. ("./openRTSP -V rtsp://10.145.120.27:554/presentation0") When I remove the line about setting the ReceivingInterfaceAddr, openRTSP is able to make a recording from the multicast. Also, I tried running both a multicast (testMPEG2TransportStreamer) and unicast (mediaServer) server on my local machine. Both these servers have Receiving- and SendingInterfaceAddr setup also. I see no problem with openRTSP recording from unicast when ReceivingInterfaceAddr is set. When I run testMPEG2TransportStreamer as the server on the same machine, openRTSP again cannot make a recording. I use the same file for both servers on my local machine. I see the same thing with my own application which I have written based on openRTSP (which is why I tried out openRTSP again also). In my client application, I get this error when using ddd if ReceivingInterfaceAddr is set -> "Groupsock(-1:224.0.1.2, 32775, 255): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Bad File Descriptor". Not surprisingly, my application behaves the same as openRTSP with regard to whether or not it is able to record from multicast or unicast. So main question: what am I not understanding about Receiving- and SendingInterfaceAddr? Shouldn't it be OK to set the ReceivingInterfaceAddr in openRTSP and still read from a multicast? Do I need to change something in ourSourceAddressForMulticast() function? I am running on Linux Fedora 5 Thanks! ?????????????????????????????????????????? Xochitl Smith GS Software Engineer; Computer-E (Embedded image moved to file: ph: 319.263.0191 pic28532.jpg) xcsmith at rockwellcollins.com ?????????????????????????????????????????? -------------- next part -------------- A non-text attachment was scrubbed... Name: pic28532.jpg Type: image/jpeg Size: 2784 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070130/8ff45d6d/attachment.jpg From finlayson at live555.com Tue Jan 30 12:45:11 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Jan 2007 12:45:11 -0800 Subject: [Live-devel] problem with streaming In-Reply-To: <45BF925E.1000702@dnastudios.it> References: <45BF6129.5070703@dnastudios.it> <45BF925E.1000702@dnastudios.it> Message-ID: >In both cases the seeking with VLC *does* not work This is the first time you've mentioned *seeking*; I wish you had said this before. VLC has known problems with seeking in RTSP streams (this is a problem with VLC itself, not with the "LIVE555 Streaming Media" code). Therefore you should report your problems to a VLC mailing list instead. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Jan 30 12:59:42 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 30 Jan 2007 12:59:42 -0800 Subject: [Live-devel] ReceivingInterfaceAddr In-Reply-To: References: Message-ID: >So main question: what am I not understanding about Receiving- and >SendingInterfaceAddr? Shouldn't it be OK to set the ReceivingInterfaceAddr >in openRTSP and still read from a multicast? Yes, but only if multicast traffic actually uses the interface in question. To check this, run netstat -r -n and look to see which interface has a route for 224.*. This is the only interface on which you'll be able to receive multicast traffic. (If it's also your default interface, then you shouldn't need to set "ReceivingInterfaceAddr" at all.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From armandopoulos at yahoo.fr Wed Jan 31 05:07:16 2007 From: armandopoulos at yahoo.fr (Armando Ko) Date: Wed, 31 Jan 2007 13:07:16 +0000 (GMT) Subject: [Live-devel] error Groupsock Message-ID: <20070131130716.47985.qmail@web86912.mail.ukl.yahoo.com> hi, When i run the live555 i get this error at the beginning Groupsock(1908: 230.230.20.30, 1234, 7): failed to join group: setsockopt(IP_ADD_MEMBERSHIP) error: Unknown error but i don?t know why ? thanks. ___________________________________________________________________________ D?couvrez une nouvelle fa?on d'obtenir des r?ponses ? toutes vos questions ! Profitez des connaissances, des opinions et des exp?riences des internautes sur Yahoo! Questions/R?ponses http://fr.answers.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070131/3d1a5fbf/attachment.html From zhouh31415 at 163.com Wed Jan 31 18:08:23 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Thu, 1 Feb 2007 10:08:23 +0800 (CST) Subject: [Live-devel] how to run rtp client and server in one process? Message-ID: <13619833.642251170295703999.JavaMail.root@bj163app44.163.com> hi,all, I can run rtp client and server respective. Now I want to make my media bidirectional. But it seems difficult to make my codec chip under control in different process. So, how to run rtp source and sink in one process? Is it any test program? The "doEventLoop" is a block process, can I run source and sink with one "doEventLoop"? Will they conflict each other? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070131/da22796b/attachment.html From mrnikhilagrawal at gmail.com Wed Jan 31 20:35:53 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Thu, 1 Feb 2007 10:05:53 +0530 Subject: [Live-devel] Regarding 'Pause' in Live555 In-Reply-To: References: <733cde3e0701290513j93cc961lcf067ce7354b3fb2@mail.gmail.com> Message-ID: <733cde3e0701312035o5d3a272fvcf598495e3c9cfb9@mail.gmail.com> Hi, I also think that the problem regarding PAUSE is in VLC because , QuickTime is working fine with Live555 in context of Pause feature. I think many of the Live555 users, have used VLC as their client players and suffered from the same problem ( PAUSE not working), so I request all users of Live555 who have any idea or solution for this problem or any kind of patch they used to solve the problem. According to VLC forums , many users have reported the same issue and didn't any solution. Regards, Nikhil Agrawal On 1/30/07, Ross Finlayson wrote: > > >Hi Ross, > > > >I tries PAUSE feature of Live555. > > > >First I streamed a wav file. In between, I paused the stream , it > >stopped successfully but when I played it , it was not playable > >properly, in VLC. It plays a word then stops for a 2-3 sec , then > >plays a word then again stops and so on... ( same problem when used > >RealPlayer but occured after 4-5 times pausing , it went into > >endless buffering deadlock) > > > >Next I tried to stream Audio+Video Prograam Stream ( .mpg file) , > >when I paused the stream using VLC , it got paused successfully , > >and when I played it , it continued without any problem . But second > >time when I paused and played it , it shows only video and no vioce > >there after (in successive pause and play). > > > >I also looked into the code little bit and saw it was working > >corrrectly as expected ( Pause + Play = Stop + Seek + Play). > > > >Can you tell me where I am wrong. > > I believe that this is a problem with VLC. As far as I can tell, our > RTSP server handles RTSP "PAUSE" correctly (and WAV audio files are a > good medium to test this with, because of their simplicity). > -- > > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ > _______________________________________________ > live-devel mailing list > live-devel at lists.live555.com > http://lists.live555.com/mailman/listinfo/live-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070131/eb576a37/attachment-0001.html From ymreddy at ssdi.sharp.co.in Wed Jan 31 22:32:01 2007 From: ymreddy at ssdi.sharp.co.in (Mallikharjuna Reddy (NAVT)) Date: Thu, 1 Feb 2007 12:02:01 +0530 Subject: [Live-devel] Virtual Memory issues in client side Message-ID: <7FB4685EA93D014C8E30AA087B66E7520337D1D7@ssdimailsrvnt01.ssdi.sharp.co.in> Hi Everybody, We are using test programs testMPEG1or2VideoStreamer.cpp and testMPEG1or2VideoReceiver.cpp to stream MPEG II files from server to client. We are streaming MPEG files continuously from server to client, i.e. server will stream the same MPEG file to the client continuously. We are carrying this test for checking performance and stress on the server and the client. We were using the code base dated on 27th October 2006 and ran these tests and found that both server and client are running successfully for 5 days. We terminated both server and client gracefully. We are running these tests on Windows XP platform. When we upgrade the code base to dated on 17th January 2007, we found a problem with the client. The client reports a virtual memory issue after running the stream for 10 minutes. The client configuration is Pentium Dual Processor with 2.80 GHz and 1 GB RAM. Any clues on this, why its happening. Thanks and Regards Y. Mallikharjuna Reddy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070131/946ff410/attachment.html From zjuchenjun at hotmail.com Wed Jan 31 22:34:26 2007 From: zjuchenjun at hotmail.com (chenjun) Date: Thu, 1 Feb 2007 14:34:26 +0800 Subject: [Live-devel] How to set "fDurationInMicroseconds" Message-ID: Hi, In previous mailist, I got some explaination about "fDurationInMicroseconds": *In practice*, however, for (outgoing) RTP streaming, the "fDurationInMicroseconds" value serves only to tell the "MultiFramedRTPSink" class how long to wait, after sending each packet, before asking the input source for new data.But I send a frame from a live source, so i don't know how long to wait after sending a packet. I want to ask how to set "fDurationInMicroseconds" in my situation. Thanks in advance. _________________________________________________________________ ???? Windows Live Mail? http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070131/83c2cfd4/attachment.html From finlayson at live555.com Wed Jan 31 22:56:27 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 31 Jan 2007 22:56:27 -0800 Subject: [Live-devel] Virtual Memory issues in client side In-Reply-To: <7FB4685EA93D014C8E30AA087B66E7520337D1D7@ssdimailsrvnt01.ssdi.sharp.co.in > References: <7FB4685EA93D014C8E30AA087B66E7520337D1D7@ssdimailsrvnt01.ssdi.sharp.co.in > Message-ID: >When we upgrade the code base to dated on 17th January 2007, we >found a problem with the client. The client reports a virtual memory >issue after running the stream for 10 minutes. What do you mean by "a virtual memory issue"? Do you mean a memory access error? Or are you running out of swap space? In any case, I wasn't able to reproduce your problem, so unfortunately this is something that you're going to have to track down yourself. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070131/04d4182e/attachment.html From finlayson at live555.com Wed Jan 31 22:58:15 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 31 Jan 2007 22:58:15 -0800 Subject: [Live-devel] How to set "fDurationInMicroseconds" In-Reply-To: References: Message-ID: >In previous mailist, I got some explaination about "fDurationInMicroseconds": > >*In practice*, however, for (outgoing) RTP streaming, the >"fDurationInMicroseconds" value serves only to tell the >"MultiFramedRTPSink" class how long to wait, after sending each >packet, before asking the input source for new data. > >But I send a frame from a live source, so i don't know how long to >wait after sending a > >packet. I want to ask how to set "fDurationInMicroseconds" in my situation. If you're streaming from a live source, then you don't need to set "fDurationInMicroseconds" at all. (If you don't set this variable, it will remain at its default value: 0.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070131/74a0e257/attachment.html