From ulrik.mikaelsson at gmail.com Thu Mar 1 01:29:08 2007 From: ulrik.mikaelsson at gmail.com (Ulrik Mikaelsson) Date: Thu, 1 Mar 2007 10:29:08 +0100 Subject: [Live-devel] Trick play support Message-ID: <15c1dfa0703010129v62e91dd4o8598ec5d8176ff69@mail.gmail.com> Hi there, I just tried out the liveMediaServer on a MPEG2 TS stream, with the Motorola/Kreatel STB 1510 as client. Definitely interesting results. Though the behavior was a bit flaky, the streams actually ran, and all trick-play operations worked, to some extent. However, there were some glitches, for instance video were quite a bit distorted on ffwd with high scales, and the client crashed at a number of times, during trick play operations. I've got two followup questions: * Is there a "reference" client to try with, supporting trick-play. Of course theres the openRTSP command-line tool, but since most issues I had were related to going back and forth, i can't really test that with the openRTSP utility, I think? * During the test, i ran a packet capture on the streaming server. The packet capture showed very clean nice network traffic out from the server during regular play, but during fast-forward, the bandwidths jumped sky high, and sometimes exceeded 20 mbit/second on a VBR stream with an average bitrate of 5mbit/s. Is this expected behavior? Regards / Ulrik From finlayson at live555.com Thu Mar 1 01:23:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Mar 2007 01:23:50 -0800 Subject: [Live-devel] Simulation and packet loss In-Reply-To: <45E60C79.3090606@libero.it> References: <45E60C79.3090606@libero.it> Message-ID: >For my thesis, i have to study the effect of packet loss on a MPEG video >recived during a streaming session. I thinked to execute locally both >Live555MediaServer and VLC client. >Is it possibile to edit the live555MediaServer, in order to implement a >packet loss model during streaming of a MPEG video? What file i have to >edit? Search for "TEST_LOSS" in the file "liveMedia/MultiFramedRTPSink.cpp". There you'll see code (#ifdef'd out, by default) that simulates 10% packet loss (upon transmission). I suggest using that code (changing it, as appropriate, to simulate a particular desired packet loss rate). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Mar 1 02:10:46 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Mar 2007 02:10:46 -0800 Subject: [Live-devel] Trick play support In-Reply-To: <15c1dfa0703010129v62e91dd4o8598ec5d8176ff69@mail.gmail.com> References: <15c1dfa0703010129v62e91dd4o8598ec5d8176ff69@mail.gmail.com> Message-ID: >I just tried out the liveMediaServer on a MPEG2 TS stream, with the >Motorola/Kreatel STB 1510 as client. Definitely interesting results. >Though the behavior was a bit flaky, the streams actually ran, and all >trick-play operations worked, to some extent. > >However, there were some glitches, for instance video were quite a bit >distorted on ffwd with high scales, and the client crashed at a number >of times, during trick play operations. Only Motorola can help you with that :-) > >I've got two followup questions: >* Is there a "reference" client to try with, supporting trick-play. No, not really. However, the Amino 110 set-top box is known to work. >* During the test, i ran a packet capture on the streaming server. The >packet capture showed very clean nice network traffic out from the >server during regular play, but during fast-forward, the bandwidths >jumped sky high, and sometimes exceeded 20 mbit/second on a VBR stream >with an average bitrate of 5mbit/s. Is this expected behavior? Yes, because the streams used for fast-forward and reverse play consist solely of I-frames. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Thu Mar 1 02:47:23 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Mar 2007 02:47:23 -0800 Subject: [Live-devel] Transport Stream In-Reply-To: <000001c75bb4$a8d1a160$0a2a320a@telxsi.com> References: <000001c75bb4$a8d1a160$0a2a320a@telxsi.com> Message-ID: >C:\Fresh Live555\live\testProgs>MPEG2TransportStreamIndexer FTN_Part1.ts >Writing index file "FTN_Part1.tsx"......done > >After that it creat FTN_Part1.txs file of size 0KB.I can not understand what >was happing. The problem with your Transport Stream file is that each Program Association Table (PAT) references more than one program (i.e. includes more than one "program_map_PID"), and, because of this, our indexing code does not know which program is the real one (i.e., the one that contains your actual audio and video data). For a Transport Stream file to be indexable, it should contain only one program. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From morgan.torvolt at gmail.com Thu Mar 1 04:12:19 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 1 Mar 2007 16:12:19 +0400 Subject: [Live-devel] Trick play support In-Reply-To: References: <15c1dfa0703010129v62e91dd4o8598ec5d8176ff69@mail.gmail.com> Message-ID: <3cc3561f0703010412l7fe85fdftb892533da7fe742@mail.gmail.com> > >* During the test, i ran a packet capture on the streaming server. The > >packet capture showed very clean nice network traffic out from the > >server during regular play, but during fast-forward, the bandwidths > >jumped sky high, and sometimes exceeded 20 mbit/second on a VBR stream > >with an average bitrate of 5mbit/s. Is this expected behavior? > > Yes, because the streams used for fast-forward and reverse play > consist solely of I-frames. I have heard that some kreatel boxes does not support high bitrates, even bitrates that are far within specs. I have also heard rumors that even some satellite channels need to be reencoded to lower bitrate for the STB to be able to play them. Given such a high bitrates as here, this does indeed sound like a kreatel issue. I have myself observed that some tv channels streamed to kreatel boxes has been reencoded, even on a fibre network. I cannot say the exact reason for this, but high bitrate troubles comes to mind... -Morgan- From ulrik.mikaelsson at gmail.com Thu Mar 1 05:34:28 2007 From: ulrik.mikaelsson at gmail.com (Ulrik Mikaelsson) Date: Thu, 1 Mar 2007 14:34:28 +0100 Subject: [Live-devel] Trick play support In-Reply-To: <3cc3561f0703010412l7fe85fdftb892533da7fe742@mail.gmail.com> References: <15c1dfa0703010129v62e91dd4o8598ec5d8176ff69@mail.gmail.com> <3cc3561f0703010412l7fe85fdftb892533da7fe742@mail.gmail.com> Message-ID: <15c1dfa0703010534l51b9110br1418461519789368@mail.gmail.com> > I have heard that some kreatel boxes does not support high bitrates, > even bitrates that are far within specs. I have also heard rumors that > even some satellite channels need to be reencoded to lower bitrate for > the STB to be able to play them. Given such a high bitrates as here, > this does indeed sound like a kreatel issue. > > I have myself observed that some tv channels streamed to kreatel boxes > has been reencoded, even on a fibre network. I cannot say the exact > reason for this, but high bitrate troubles comes to mind... Interesting point. I know the box works without issues on 12mbit streams, but I haven't tried any higher than that. (more than 12mbit for SDTV is quite silly anyways. ;) From ulrik.mikaelsson at gmail.com Thu Mar 1 05:37:18 2007 From: ulrik.mikaelsson at gmail.com (Ulrik Mikaelsson) Date: Thu, 1 Mar 2007 14:37:18 +0100 Subject: [Live-devel] Trick play support In-Reply-To: References: <15c1dfa0703010129v62e91dd4o8598ec5d8176ff69@mail.gmail.com> Message-ID: <15c1dfa0703010537u6d76d387r11afa4a78a0211d4@mail.gmail.com> > >However, there were some glitches, for instance video were quite a bit > >distorted on ffwd with high scales, and the client crashed at a number > >of times, during trick play operations. > Only Motorola can help you with that :-) Probably, but since I've been able to confirm trick-play on the client using other server solutions, I were looking for ways to reference-test the liveMediaServer using some other toolkit to better push Motorola. > >I've got two followup questions: > >* Is there a "reference" client to try with, supporting trick-play. > No, not really. However, the Amino 110 set-top box is known to work. Thank you for the tip. I think I have a 110 lying around somewhere at work. Will be interesting to watch. :) > >* During the test, i ran a packet capture on the streaming server. The > >packet capture showed very clean nice network traffic out from the > >server during regular play, but during fast-forward, the bandwidths > >jumped sky high, and sometimes exceeded 20 mbit/second on a VBR stream > >with an average bitrate of 5mbit/s. Is this expected behavior? > Yes, because the streams used for fast-forward and reverse play > consist solely of I-frames. Is pre-encoding material for ffwd/reverse in the roadmap? From morgan.torvolt at gmail.com Thu Mar 1 07:31:54 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 1 Mar 2007 19:31:54 +0400 Subject: [Live-devel] Trick play support In-Reply-To: <15c1dfa0703010534l51b9110br1418461519789368@mail.gmail.com> References: <15c1dfa0703010129v62e91dd4o8598ec5d8176ff69@mail.gmail.com> <3cc3561f0703010412l7fe85fdftb892533da7fe742@mail.gmail.com> <15c1dfa0703010534l51b9110br1418461519789368@mail.gmail.com> Message-ID: <3cc3561f0703010731q3efbf5sae93a0d3e303be9d@mail.gmail.com> > Interesting point. I know the box works without issues on 12mbit > streams, but I haven't tried any higher than that. (more than 12mbit > for SDTV is quite silly anyways. ;) I have to agree on the sillyness =) The channel I saw was average 8Mbit variable bitrate stream (2 streams shared 16Mbit, with minimum set to 4 if i remember correctly. I know this because I worked at the earth station transmitting the two channels, and knew the configuration of the equipment =) ). The problem could of course be caused by poor variable bitrate handling causing a need for reencoding to CBR. I never really considered that before just now. The stream was possibly high bitrate after encoding also, but reencoded streams not using 4:2:2 and I frame detection will give some pretty bad results most of the time. All I noticed was that it, as opposed to all the other services, this one was reencoded. Other services also had such high average bitrates, but none had VBR. I don't know if that information helps you any, as I realize now that I did not give you much to work with. A test of the VBR handling could possibly give you a hint, but I guess that these IPTV STBs usually have the same MPEG2 decoders as ordinary satellite STBs. -Morgan- From xcsmith at rockwellcollins.com Thu Mar 1 07:43:06 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Thu, 1 Mar 2007 09:43:06 -0600 Subject: [Live-devel] Trick play support Message-ID: I have heard that some kreatel boxes does not support high bitrates, even bitrates that are far within specs. -Morgan- Morgan, where do you find specs for bitrates? Thx! xochitl From morgan.torvolt at gmail.com Thu Mar 1 08:33:59 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Thu, 1 Mar 2007 20:33:59 +0400 Subject: [Live-devel] Trick play support In-Reply-To: References: Message-ID: <3cc3561f0703010833q67434683ke37cf9573ff5a02b@mail.gmail.com> > Morgan, where do you find specs for bitrates? Thx! > > xochitl For the STB you need to go to the producer I guess. For bitrates on services you need to measure it. As to the services I saw, I worked at the satellite uplink station (earth station), so I have inside information. -Morgan- From zhouh31415 at 163.com Thu Mar 1 19:46:36 2007 From: zhouh31415 at 163.com (=?gbk?B?1ty66w==?=) Date: Fri, 2 Mar 2007 11:46:36 +0800 (CST) Subject: [Live-devel] Question abaut RTCP Message-ID: <2414394.4602801172807196022.JavaMail.root@bj163app15.163.com> In the testprog, when I add? RTCPInstance::createNew(*env, &rtcpGroupsock, estimatedSessionBandwidth, CNAME, NULL , source);/* we're a client */ ,the RTCP is OK.But I wonder how RTCP run in the program. Can I use the protocol caculating the package loss ratio? Or use it estimating the state of our network? How to use it? thanks. welltrans Zhouhong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070301/5f688614/attachment.html From finlayson at live555.com Thu Mar 1 23:26:28 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 1 Mar 2007 23:26:28 -0800 Subject: [Live-devel] Question abaut RTCP In-Reply-To: <2414394.4602801172807196022.JavaMail.root@bj163app15.163.com> References: <2414394.4602801172807196022.JavaMail.root@bj163app15.163.com> Message-ID: > ,the RTCP is OK.But I wonder how RTCP run in the program. Can I use >the protocol caculating the package loss ratio? Or use it estimating >the state of our network? How to use it? Look at how the "openRTSP" application implements the "-Q" option. I.e., if you are receiving RTP data (like "openRTSP" does), then use "RTPReceptionStats". If, however, you're sending RTP data, then use "RTPTransmissionStats". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ydq at nbicc.com Thu Mar 1 23:34:54 2007 From: ydq at nbicc.com (ydq) Date: Fri, 2 Mar 2007 15:34:54 +0800 Subject: [Live-devel] RTCP "BYE" command Message-ID: <20070302074257.1B93A24B5D8@slave.mail113.cn4e.com> _____ ???: ydq [mailto:ydq at nbicc.com] ????: 2007?3?2? 9:47 ???: 'finlayson at live555.com' ??: RTCP "BYE" command Hi , Thanks for your support ! In your letter you mentioned that Servers usually use the RTCP "BYE" command - which we support - to inform the client of the end of the stream. Dose Darwin Server support it ? In the openRTSP program, it set subsession->rtcpInstance()->setByeHandler(subsessionByeHandler , subsession) , so at the end of stream , program will close down session and exit immediately . But, in fact it does not do it ! Best regards ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070301/0127de3d/attachment.html From ydq at nbicc.com Thu Mar 1 23:36:51 2007 From: ydq at nbicc.com (ydq) Date: Fri, 2 Mar 2007 15:36:51 +0800 Subject: [Live-devel] RTCP "BYE" command Message-ID: <20070302074454.346DE24B34D@slave.mail113.cn4e.com> Hi , Thanks for your support ! In your letter you mentioned that Servers usually use the RTCP "BYE" command - which we support - to inform the client of the end of the stream. Dose Darwin Server support it ? In the openRTSP program, it set subsession->rtcpInstance()->setByeHandler(subsessionByeHandler , subsession) , so at the end of stream , program will close down session and exit immediately . But, in fact it does not do it ! Best regards ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070301/717d4e34/attachment.html From finlayson at live555.com Fri Mar 2 02:26:45 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Mar 2007 02:26:45 -0800 Subject: [Live-devel] RTCP "BYE" command In-Reply-To: <20070302074454.346DE24B34D@slave.mail113.cn4e.com> References: <20070302074454.346DE24B34D@slave.mail113.cn4e.com> Message-ID: >Hi , >Thanks for your support ! >In your letter you mentioned that Servers usually use the RTCP "BYE" >command - which we support - to inform the client of the end of the >stream. >Dose Darwin Server support it ? I don't know; you'll have to ask them. (This mailing list is not for the "Darwin Streaming Server" - that's Apple's software, not ours.) However, *our* RTSP server implementation (e.g, as used in the "LIVE555 Media Server") *does* send RTCP "BYE" packets when the stream ends, but only for media types for which 'seeking' is not supported. (For those media types, the server keeps the session open after the stream ends, in case the client wants to replay it from an earlier time.) > >In the openRTSP program, it set >subsession->rtcpInstance()->setByeHandler(subsessionByeHandler , >subsession) , so at the end of stream , program will close down > session and exit immediately . But, in fact it does not do it ! This code works correctly, *if* the server sends a RTCP "BYE" packet. You can test this by running "openRTSP" with the "-V" option (to specify verbose output). -- 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/20070302/1ff9586f/attachment-0001.html From tribest_tata at hotmail.com Fri Mar 2 22:30:14 2007 From: tribest_tata at hotmail.com (=?big5?B?qkwgqHysUA==?=) Date: Sat, 03 Mar 2007 06:30:14 +0000 Subject: [Live-devel] testMPEG1or2VideoStreamer Message-ID: i just began to use testpro . I use testMPEG1or2VideoStreamer to stream my ?test.mpg?. Then I use Quicktime player rtsp:// /testStream . But don?t see any Video . How do I do anything?? _________________________________________________________________ Windows Live Messenger ??????????????????????? http://get.live.com/messenger/overview From finlayson at live555.com Fri Mar 2 22:50:28 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 2 Mar 2007 22:50:28 -0800 Subject: [Live-devel] testMPEG1or2VideoStreamer In-Reply-To: References: Message-ID: >i just began to use testpro . I use testMPEG1or2VideoStreamer to stream my >"test.mpg". > >Then I use Quicktime player rtsp:// /testStream . > >But don't see any Video . > >How do I do anything?? Start by reading the FAQ - in particular http://www.live555.com/liveMedia/faq.html#my-file-doesnt-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/20070302/37bd6552/attachment.html From tribest_tata at hotmail.com Sat Mar 3 00:17:17 2007 From: tribest_tata at hotmail.com (=?big5?B?qkwgqHysUA==?=) Date: Sat, 03 Mar 2007 08:17:17 +0000 Subject: [Live-devel] testMPEG1or2VideoStreamer In-Reply-To: Message-ID: >From: Ross Finlayson >Reply-To: LIVE555 Streaming Media - development & use >To: LIVE555 Streaming Media - development & use >Subject: Re: [Live-devel] testMPEG1or2VideoStreamer >Date: Fri, 2 Mar 2007 22:50:28 -0800 > >>i just began to use testpro . I use testMPEG1or2VideoStreamer to >>stream my >>"test.mpg". >> >>Then I use Quicktime player rtsp:// /testStream . >> >>But don't see any Video . >> >>How do I do anything?? > >Start by reading the FAQ - in particular > http://www.live555.com/liveMedia/faq.html#my-file-doesnt-work >-- > >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 ??? Match.com ??????????????? http://match.msn.com.tw/Registration/Registration.aspx?trackingid=281200 From stabrawa at stanford.edu Sat Mar 3 16:10:28 2007 From: stabrawa at stanford.edu (Tim Stabrawa) Date: Sat, 03 Mar 2007 18:10:28 -0600 Subject: [Live-devel] Layered video with Live555 In-Reply-To: References: <45DEA2A8.7060805@stanford.edu> Message-ID: <45EA0E74.109@stanford.edu> Ross Finlayson wrote: >> For an academic demonstration, I'm planning on extending Live555 to >> support RTP transport of scalable H.264 video and was hoping someone >> with a reasonable amount of experience with Live555 could help steer me >> in the direction of least pain ... >> >> Basically, I'll be using the reference codec for H.264 SVC (currently in >> development) to generate a file containing H.264 NAL units. The >> important difference between the output of this codec and a standard >> H.264 stream is the addition of two NAL unit types (20 & 21), which >> carry information about which layer of video is described in the >> preceding/current NAL unit. For now, assume I know how to parse this >> file and determine which NAL units belong to which layers. My intention >> is to send each layer out either multiplexed in the same RTP stream (the >> easy way) or in separate RTP streams (the hard / interesting way), >> according to this draft RFC: >> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-00.txt >> > > This is interesting. I suggest proceeding in three steps (with each > step requiring additional work building on the previous steps): > 1/ Stream regular (non-SVC) H.264 video from a file. You will be > able to test this using VLC. > 2/ Add additional SVC layers, multiplexed in the same RTP stream as > the base layer. > 3/ Use separate RTP streams for separate SVC layers. > > If you're streaming on a single RTP stream (steps 1/ or 2/), then > it's fairly straightforward: You'll need to write your own subclass > of "H264VideoStreamFramer"; that subclass will parse the input stream > (from a "ByteStreamFileSource"). You'll then 'play' this to a > "H264VideoRTPSink" object Ok, I think I have the StreamFramer class basically working except for one small problem. To parse the file, I created a subclass of MPEGVideoStreamParser (purely out of convenience), and defined a parse() routine that has two states: PARSING_START_SEQUENCE and PARSING_NAL_UNIT. The parser basically alternates between these two states either throwing data out (to find the first sequence), or saving it (until it finds the next). So naturally, there is no start sequence at the end of the file. It just sorta ends. So what I'm seeing when I play from my Framer source class to a H264VideoFileSink class is that all the NAL units are copied over to the output file except the last one. What I think is happening is, for the last NAL unit, my call to test4Bytes() is throwing an exception once it gets to the end of the file .. causing parse() to return 0. Meanwhile, the StreamParser class goes off and tries to read more from the file, sees that the file is at EOF, and closes the file, etc. I peeked around at some of the mechanisms for handling what to do when a stream gets closed, thinking this would afford me the opportunity to tell my stream parser to give me what it has left it its buffer, but I haven't been able to wrap my mind around it completely yet. Do you think this is the Right Way to do it? Any other suggestions? Below is the code for my parse routines .. there's not much to 'em. - Tim - snip - void H264JSVMVideoStreamParser :: parseStartSequence() { // Find start sequence (0001) u_int32_t test = test4Bytes(); while (test != 0x00000001) { skipBytes(1); test = test4Bytes(); } setParseState(PARSING_NAL_UNIT); skipBytes(4); } unsigned H264JSVMVideoStreamParser :: parseNALUnit() { // Find next start sequence (0001) or end of stream u_int32_t test = test4Bytes(); while (test != 0x00000001) { saveByte(get1Byte()); test = test4Bytes(); } setParseState(PARSING_START_SEQUENCE); return curFrameSize(); } From antoniotirri at libero.it Sat Mar 3 17:44:44 2007 From: antoniotirri at libero.it (Antonio Tirri) Date: Sun, 04 Mar 2007 02:44:44 +0100 Subject: [Live-devel] Simulation and packet loss, part two In-Reply-To: References: <45E60C79.3090606@libero.it> Message-ID: <45EA248C.6070402@libero.it> Hi, i tried to substitute the code: #ifdef TEST_LOSS if ((our_random()%10) != 0) // simulate 10% packet loss ##### #endif with the code: //#ifdef TEST_LOSS if (((double)our_random()%10000)/10000.0 <= 0.8) // simulate 10% packet loss ##### //#endif where 0.8 is (1-0.2), where 0.2 is the packet loss rate(in this case 20%) But my compiler (Visual C++ 6.0) gives me this error: MultiFramedRTPSink.cpp MultiFramedRTPSink.cpp(352) : error C2296: '%' : illegal, left operand has type 'double' NMAKE : fatal error U1077: '"C:\Programmi\Microsoft Visual Studio\VC98\bin\cl"' : return code '0x2' Stop. Error executing NMAKE. How can i edit the code in order to introduce the packet loss rate in correct way? Thanks a lot, Antonio Tirri Ross Finlayson ha scritto: >> For my thesis, i have to study the effect of packet loss on a MPEG video >> recived during a streaming session. I thinked to execute locally both >> Live555MediaServer and VLC client. >> Is it possibile to edit the live555MediaServer, in order to implement a >> packet loss model during streaming of a MPEG video? What file i have to >> edit? >> > > Search for "TEST_LOSS" in the file > "liveMedia/MultiFramedRTPSink.cpp". There you'll see code (#ifdef'd > out, by default) that simulates 10% packet loss (upon transmission). > I suggest using that code (changing it, as appropriate, to simulate a > particular desired packet loss rate). > From stabrawa at stanford.edu Sat Mar 3 17:56:24 2007 From: stabrawa at stanford.edu (Tim Stabrawa) Date: Sat, 03 Mar 2007 19:56:24 -0600 Subject: [Live-devel] Simulation and packet loss, part two In-Reply-To: <45EA248C.6070402@libero.it> References: <45E60C79.3090606@libero.it> <45EA248C.6070402@libero.it> Message-ID: <45EA2748.3040801@stanford.edu> Antonio Tirri wrote: > Hi, i tried to substitute the code: > > #ifdef TEST_LOSS > if ((our_random()%10) != 0) // simulate 10% packet loss ##### > #endif > > > with the code: > > //#ifdef TEST_LOSS > if (((double)our_random()%10000)/10000.0 <= 0.8) // simulate 10% packet loss ##### > //#endif > > How can i edit the code in order to introduce the packet loss rate in correct way? > This should do it: if ((our_random()%5) != 0) // simulate 20% packet loss ##### If you need something more flexible, read up on what range of numbers come out of our_random() and do something like this: if (our_random() > OUR_RAND_MAX * 0.2) // simulate 20% packet loss ##### Good luck ... - Tim From finlayson at live555.com Sun Mar 4 04:12:28 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 4 Mar 2007 04:12:28 -0800 Subject: [Live-devel] Layered video with Live555 In-Reply-To: <45EA0E74.109@stanford.edu> References: <45DEA2A8.7060805@stanford.edu> <45EA0E74.109@stanford.edu> Message-ID: >Ok, I think I have the StreamFramer class basically working except for >one small problem. To parse the file, I created a subclass of >MPEGVideoStreamParser (purely out of convenience), and defined a parse() >routine that has two states: PARSING_START_SEQUENCE and >PARSING_NAL_UNIT. The parser basically alternates between these two >states either throwing data out (to find the first sequence), or saving >it (until it finds the next). > >So naturally, there is no start sequence at the end of the file. It >just sorta ends. So what I'm seeing when I play from my Framer source >class to a H264VideoFileSink class is that all the NAL units are copied >over to the output file except the last one. > What I think is happening is, for the last NAL unit, my call to >test4Bytes() is throwing an exception once it gets to the end of the >file .. causing parse() to return 0. Meanwhile, the StreamParser class >goes off and tries to read more from the file, sees that the file is at >EOF, and closes the file, etc. Yes. Unfortunately, the current stream parsing code discards already-read data once it encounters the end of the input file. There are probably ways to work around this (e.g., pass some function other than "FramedSource::handleClosure" to the parent constructor when constructing "MPEGVideoStreamParser"), but it would be messy. Instead, I suggest just ignoring the issue if you can. (Is the very last NAL unit in each file really important to get?) If you can't ignore it, then you could also work around the problem by appending a 'start code' to the end of each file, before you start reading it. By the way, the *real* difficulty that you're going to face in writing your "H264VideoStreamFramer" subclass is computing proper presentation times and durations (the "fPresentationTime" and "fDurationInMicroseconds" member variables) for each NAL unit. (This has tripped up other people who have tried streaming H.264 video from a file.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From stabrawa at stanford.edu Sun Mar 4 13:11:58 2007 From: stabrawa at stanford.edu (Tim Stabrawa) Date: Sun, 04 Mar 2007 15:11:58 -0600 Subject: [Live-devel] Layered video with Live555 In-Reply-To: References: <45DEA2A8.7060805@stanford.edu> <45EA0E74.109@stanford.edu> Message-ID: <45EB361E.4050901@stanford.edu> Ross Finlayson wrote: > Yes. Unfortunately, the current stream parsing code discards > already-read data once it encounters the end of the input file. > There are probably ways to work around this (e.g., pass some function > other than "FramedSource::handleClosure" to the parent constructor > when constructing "MPEGVideoStreamParser"), but it would be messy. > Instead, I suggest just ignoring the issue if you can. (Is the very > last NAL unit in each file really important to get?) If you can't > ignore it, then you could also work around the problem by appending a > 'start code' to the end of each file, before you start reading it. > Of the two sample files I'm working with right now, one ends with a suffix NAL unit, and the other actual slice data. So, the effect of dropping that would either be the preceeding frame gets sent on the base layer accidentally or the last chunk of slice data is never received. I suppose I could deal with either if they happened, but if it can be fixed, why not? I tried just putting a fake start code at the end of the file and that seems to do the trick (the received file is the same as the sent one, sans fake start code). That's good enough for now, I'd say. (It's for a demonstration, after all.) > By the way, the *real* difficulty that you're going to face in > writing your "H264VideoStreamFramer" subclass is computing proper > presentation times and durations (the "fPresentationTime" and > "fDurationInMicroseconds" member variables) for each NAL unit. (This > has tripped up other people who have tried streaming H.264 video from > a file. For my purposes, I plan on just computing these based on the average bitrate of the file. Not ideal, but should get the job done. That gets me to thinking though ... When it comes time to re-combine the streams on the client side, I assume the best (only?) way is to use the presentation times to put things back together correctly. Unfortunately, I don't see any "Mux" classes to base this off of. In fact, the only reordering code I see is the ReorderingPacketBuffer class, but this looks like it keys off of RTP sequence numbers, not presentation times. Have you ever heard of someone needing to do this? What would you suggest? - Tim From finlayson at live555.com Sun Mar 4 13:30:21 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 4 Mar 2007 13:30:21 -0800 Subject: [Live-devel] Layered video with Live555 In-Reply-To: <45EB361E.4050901@stanford.edu> References: <45DEA2A8.7060805@stanford.edu> <45EA0E74.109@stanford.edu> <45EB361E.4050901@stanford.edu> Message-ID: > > By the way, the *real* difficulty that you're going to face in >> writing your "H264VideoStreamFramer" subclass is computing proper >> presentation times and durations (the "fPresentationTime" and >> "fDurationInMicroseconds" member variables) for each NAL unit. (This >> has tripped up other people who have tried streaming H.264 video from >> a file. >For my purposes, I plan on just computing these based on the average >bitrate of the file. Not ideal, but should get the job done. > >That gets me to thinking though ... When it comes time to re-combine the >streams on the client side, I assume the best (only?) way is to use the >presentation times to put things back together correctly. >Unfortunately, I don't see any "Mux" classes to base this off of. In >fact, the only reordering code I see is the ReorderingPacketBuffer >class, but this looks like it keys off of RTP sequence numbers, not >presentation times. Have you ever heard of someone needing to do this? >What would you suggest? What you need is a 'jitter buffer' implementation (not really a "mux" ("multiplexor"), because that implies that two or more incoming streams are being merged into one). I suggest just basing your client implementation around VLC , because it already receives/plays (regiular, non-structured) H.264/RTP streams (using the "LIVE555 Streaming Media" code). If you use VLC, you'll be saving yourself lots of work (and, perhaps, the additions that you make to support structured H.264 video will end up being of use to the VLC codebase). -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From stabrawa at stanford.edu Sun Mar 4 15:32:21 2007 From: stabrawa at stanford.edu (Tim Stabrawa) Date: Sun, 04 Mar 2007 17:32:21 -0600 Subject: [Live-devel] Layered video with Live555 In-Reply-To: References: <45DEA2A8.7060805@stanford.edu> <45EA0E74.109@stanford.edu> <45EB361E.4050901@stanford.edu> Message-ID: <45EB5705.3050001@stanford.edu> Ross Finlayson wrote: > What you need is a 'jitter buffer' implementation (not really a "mux" > ("multiplexor"), because that implies that two or more incoming > streams are being merged into one). > > I suggest just basing your client implementation around VLC > , because it already receives/plays (regiular, > non-structured) H.264/RTP streams (using the "LIVE555 Streaming > Media" code). If you use VLC, you'll be saving yourself lots of work > (and, perhaps, the additions that you make to support structured > H.264 video will end up being of use to the VLC codebase). > Well, actually, I think we will have multiple incoming streams to deal with. What we intend to demonstrate is basically separating the layers into multiple RTP streams on the server side, then letting the client choose which streams to subscribe to and recombine them to produce the desired video quality. We plan on feeding the recombined stream into the reference SVC decoder to let it handle decoding the actual video. We originally considered VLC, but eventually decided not to use it, figuring it'd be too difficult to shoehorn the reference codec into it. Does it still sound like a mux approach is not the way to go? Thanks, - Tim From finlayson at live555.com Sun Mar 4 17:58:01 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 4 Mar 2007 17:58:01 -0800 Subject: [Live-devel] Layered video with Live555 In-Reply-To: <45EB5705.3050001@stanford.edu> References: <45DEA2A8.7060805@stanford.edu> <45EA0E74.109@stanford.edu> <45EB361E.4050901@stanford.edu> <45EB5705.3050001@stanford.edu> Message-ID: >Well, actually, I think we will have multiple incoming streams to deal >with. What we intend to demonstrate is basically separating the layers >into multiple RTP streams on the server side, then letting the client >choose which streams to subscribe to and recombine them to produce the >desired video quality. We plan on feeding the recombined stream into >the reference SVC decoder to let it handle decoding the actual video. >We originally considered VLC, but eventually decided not to use it, >figuring it'd be too difficult to shoehorn the reference codec into it. > >Does it still sound like a mux approach is not the way to go? Yes, what you're describing is 'multiplexing'. (I had forgotten that you were planning to have multiple incoming layers. If you have just one layer of RTP video (the normal case), then there's no multiplexing - just time-based playout (based on presentation time).) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From bidibulle at operamail.com Mon Mar 5 06:49:47 2007 From: bidibulle at operamail.com (David Betrand) Date: Mon, 05 Mar 2007 15:49:47 +0100 Subject: [Live-devel] AMR timestamps Message-ID: <20070305144947.96B4E2474D@ws5-3.us4.outblaze.com> Hello Ross, I am experiencing a timestamp problem when I use AMRAudioRTPSource and when I receive several AMR frames in a sinle RTP packet. In RawAMRRTPSource:hasBeenSynchronizedUsingRTCP() : the method waits at least a complete interleave cycle of synchronized packets before returning true. So in this case some frames are not reported "synchronized" even if these frames are actually coming from a "synchronized" RTP packet. My problem is that I need exactly to know if a frame is coming from a "synchronized" or not "synchronized" RTP packet. It is crucial when there is a large gap between streamer and receiver clocks. In this case it could lead to huge discontinutity of timestamps, in the past or in the future. I solved this problem storing the "synchronization" info for each AMRDeinterleaverBuffer object. A boolean value is also stored in RawAMRRTPSource (actually fInputSource from AMRDeinterleaver point of view) and updated by reference at each time we call retreiveFrame method. By this mechanism the method hasBeenSynchronizedUsingRTCP() simply returns the new boolean. I attached my patch for consideration to this email. Are changes in the code suitable? Of course another suggestion to solve my problem will be welcome. Thanks a lot in advance for your help. David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze -------------- next part -------------- 47,48d46 < Boolean fIsSynchronized; < 101c99 < RawAMRRTPSource* fInputSource; --- > FramedSource* fInputSource; 104d101 < 220c217 < fNumSuccessiveSyncedPackets(0), fIsSynchronized(false) { --- > fNumSuccessiveSyncedPackets(0) { 318c315 < return fIsWideband ? "audio/AMR-WB" : "audio/AMR-NB"; --- > return fIsWideband ? "audio/AMR-WB" : "audio/AMR-WB"; 322,326d318 < < return fIsSynchronized; < < // LIVE MEDIA VERSION < /* 336d327 < */ 413,414c404 < struct timeval& resultPresentationTime, < Boolean& resultIsSynchronized); --- > struct timeval& resultPresentationTime); 431,432d420 < < Boolean fIsSynchronized; 454c442,443 < return new AMRDeinterleaver(env, isWideband, numChannels, maxInterleaveGroupSize, inputSource); --- > return new AMRDeinterleaver(env, isWideband, numChannels, maxInterleaveGroupSize, > inputSource); 475d463 < 479,481c467 < fLastFrameHeader, fPresentationTime, < fInputSource->fIsSynchronized)) { < --- > fLastFrameHeader, fPresentationTime)) { 519d504 < 560d544 < 616d599 < inBin.fIsSynchronized = (RTPSource*)source->RTPSource::hasBeenSynchronizedUsingRTCP(); 630,632c613 < struct timeval& resultPresentationTime, < Boolean& resultIsSynchronized) { < --- > struct timeval& resultPresentationTime) { 636d616 < 640d619 < resultIsSynchronized = outBin.fIsSynchronized; From finlayson at live555.com Mon Mar 5 07:22:24 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Mar 2007 07:22:24 -0800 Subject: [Live-devel] AMR timestamps In-Reply-To: <20070305144947.96B4E2474D@ws5-3.us4.outblaze.com> References: <20070305144947.96B4E2474D@ws5-3.us4.outblaze.com> Message-ID: Thanks, but please resend this as a proper patch file - e.g., generated using diff -c -B -b AMRAudioRTPSource.cpp.orig AMRAudioRTPSource.cpp -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jlfurlong at hotmail.com Mon Mar 5 07:48:12 2007 From: jlfurlong at hotmail.com (Jeff Furlong) Date: Mon, 5 Mar 2007 11:48:12 -0400 Subject: [Live-devel] Index file for H264 over mpeg2ts Message-ID: Hi Ross, I'm not sure if you've had a chance to look at this file yet, but I did notice in the MPEG2IndexFromTransportStream.cpp file, that it is currently only looking for stream types 1 or 2. For H264, the stream type is 27. I did modify it and tried it, and I got a tsx output file of about 40KB. It obviously still didn't work, but at least it was able to find the video PID. Anyway, just a note so that when and if you get a chance to look at it, it may save you a few minutes. Jeff Date: Tue, 27 Feb 2007 13:18:00 -0800To: live-devel at ns.live555.comFrom: finlayson at live555.comSubject: Re: [Live-devel] Index file for H264 over mpeg2ts I've seen some recent posts regarding H.264 - specifically one regarding the creation of index files. I have placed an HD H.264 sample clip from a live encoder and was wondering if someone (Ross ?) could take a look to see what would be required to be able to support indexing? You can access the file here: http://www.geeknet.ca/~temp/tenten16-2.ts Thanks. (I'm downloading this now.)-- Ross FinlaysonLive Networks, Inc.http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070305/586af45e/attachment.html From bidibulle at operamail.com Mon Mar 5 07:59:11 2007 From: bidibulle at operamail.com (David Betrand) Date: Mon, 05 Mar 2007 16:59:11 +0100 Subject: [Live-devel] AMR timestamps Message-ID: <20070305155911.7084644199@ws5-1.us4.outblaze.com> OK sorry about that. I also fixed a small bug in method MIMEtype() that always returned the string "audio/AMR-WB" whatever the type of AMR. David > ----- Original Message ----- > From: "Ross Finlayson" > To: "LIVE555 Streaming Media - development & use" > Subject: Re: [Live-devel] AMR timestamps > Date: Mon, 5 Mar 2007 07:22:24 -0800 > > > Thanks, but please resend this as a proper patch file - e.g., generated using > diff -c -B -b AMRAudioRTPSource.cpp.orig AMRAudioRTPSource.cpp > -- > > 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 > -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze -------------- next part -------------- *** AMRAudioRTPSource.cpp.orig 2007-03-05 16:15:43.000000000 +0100 --- AMRAudioRTPSource.cpp 2007-03-05 16:30:31.000000000 +0100 *************** *** 44,49 **** --- 44,51 ---- unsigned char* TOC() const { return fTOC; } // FT+Q value for each TOC entry unsigned& frameIndex() { return fFrameIndex; } // index of frame-block within pkt + Boolean fIsSynchronized; + private: RawAMRRTPSource(UsageEnvironment& env, Groupsock* RTPgs, unsigned char rtpPayloadFormat, *************** *** 96,104 **** virtual void doStopGettingFrames(); private: ! FramedSource* fInputSource; class AMRDeinterleavingBuffer* fDeinterleavingBuffer; Boolean fNeedAFrame; }; --- 98,107 ---- virtual void doStopGettingFrames(); private: ! RawAMRRTPSource* fInputSource; class AMRDeinterleavingBuffer* fDeinterleavingBuffer; Boolean fNeedAFrame; + }; *************** *** 214,220 **** fIsWideband(isWideband), fIsOctetAligned(isOctetAligned), fIsInterleaved(isInterleaved), fCRCsArePresent(CRCsArePresent), fILL(0), fILP(0), fTOCSize(0), fTOC(NULL), fFrameIndex(0), ! fNumSuccessiveSyncedPackets(0) { } RawAMRRTPSource::~RawAMRRTPSource() { --- 217,223 ---- fIsWideband(isWideband), fIsOctetAligned(isOctetAligned), fIsInterleaved(isInterleaved), fCRCsArePresent(CRCsArePresent), fILL(0), fILP(0), fTOCSize(0), fTOC(NULL), fFrameIndex(0), ! fNumSuccessiveSyncedPackets(0), fIsSynchronized(false) { } RawAMRRTPSource::~RawAMRRTPSource() { *************** *** 312,330 **** } char const* RawAMRRTPSource::MIMEtype() const { ! return fIsWideband ? "audio/AMR-WB" : "audio/AMR-WB"; } Boolean RawAMRRTPSource::hasBeenSynchronizedUsingRTCP() { ! // Don't report ourselves as being synchronized until we've received ! // at least a complete interleave cycle of synchronized packets. ! // This ensures that the receiver is currently getting a frame from ! // a packet that was synchronized. ! if (fNumSuccessiveSyncedPackets > (unsigned)(fILL+1)) { ! fNumSuccessiveSyncedPackets = fILL + 2; // prevents overflow ! return True; ! } ! return False; } --- 315,325 ---- } char const* RawAMRRTPSource::MIMEtype() const { ! return fIsWideband ? "audio/AMR-WB" : "audio/AMR-NB"; } Boolean RawAMRRTPSource::hasBeenSynchronizedUsingRTCP() { ! return fIsSynchronized; } *************** *** 401,407 **** Boolean retrieveFrame(unsigned char* to, unsigned maxSize, unsigned& resultFrameSize, unsigned& resultNumTruncatedBytes, u_int8_t& resultFrameHeader, ! struct timeval& resultPresentationTime); unsigned char* inputBuffer() { return fInputBuffer; } unsigned inputBufferSize() const { return AMR_MAX_FRAME_SIZE; } --- 396,403 ---- Boolean retrieveFrame(unsigned char* to, unsigned maxSize, unsigned& resultFrameSize, unsigned& resultNumTruncatedBytes, u_int8_t& resultFrameHeader, ! struct timeval& resultPresentationTime, ! Boolean& resultIsSynchronized); unsigned char* inputBuffer() { return fInputBuffer; } unsigned inputBufferSize() const { return AMR_MAX_FRAME_SIZE; } *************** *** 418,423 **** --- 414,421 ---- unsigned char* frameData; u_int8_t frameHeader; struct timeval presentationTime; + + Boolean fIsSynchronized; }; unsigned fNumChannels, fMaxInterleaveGroupSize; *************** *** 439,446 **** ::createNew(UsageEnvironment& env, Boolean isWideband, unsigned numChannels, unsigned maxInterleaveGroupSize, RawAMRRTPSource* inputSource) { ! return new AMRDeinterleaver(env, isWideband, numChannels, maxInterleaveGroupSize, ! inputSource); } AMRDeinterleaver::AMRDeinterleaver(UsageEnvironment& env, --- 437,443 ---- ::createNew(UsageEnvironment& env, Boolean isWideband, unsigned numChannels, unsigned maxInterleaveGroupSize, RawAMRRTPSource* inputSource) { ! return new AMRDeinterleaver(env, isWideband, numChannels, maxInterleaveGroupSize, inputSource); } AMRDeinterleaver::AMRDeinterleaver(UsageEnvironment& env, *************** *** 464,470 **** // First, try getting a frame from the deinterleaving buffer: if (fDeinterleavingBuffer->retrieveFrame(fTo, fMaxSize, fFrameSize, fNumTruncatedBytes, ! fLastFrameHeader, fPresentationTime)) { // Success! fNeedAFrame = False; --- 462,470 ---- // First, try getting a frame from the deinterleaving buffer: if (fDeinterleavingBuffer->retrieveFrame(fTo, fMaxSize, fFrameSize, fNumTruncatedBytes, ! fLastFrameHeader, fPresentationTime, ! fInputSource->fIsSynchronized)) { ! // Success! fNeedAFrame = False; *************** *** 597,602 **** --- 599,605 ---- inBin.frameSize = frameSize; inBin.frameHeader = frameHeader; inBin.presentationTime = presentationTime; + inBin.fIsSynchronized = (RTPSource*)source->RTPSource::hasBeenSynchronizedUsingRTCP(); if (curBuffer == NULL) curBuffer = createNewBuffer(); fInputBuffer = curBuffer; *************** *** 610,616 **** ::retrieveFrame(unsigned char* to, unsigned maxSize, unsigned& resultFrameSize, unsigned& resultNumTruncatedBytes, u_int8_t& resultFrameHeader, ! struct timeval& resultPresentationTime) { if (fNextOutgoingBin >= fOutgoingBinMax) return False; // none left FrameDescriptor& outBin = fFrames[fIncomingBankId^1][fNextOutgoingBin]; --- 613,621 ---- ::retrieveFrame(unsigned char* to, unsigned maxSize, unsigned& resultFrameSize, unsigned& resultNumTruncatedBytes, u_int8_t& resultFrameHeader, ! struct timeval& resultPresentationTime, ! Boolean& resultIsSynchronized) { ! if (fNextOutgoingBin >= fOutgoingBinMax) return False; // none left FrameDescriptor& outBin = fFrames[fIncomingBankId^1][fNextOutgoingBin]; *************** *** 617,622 **** --- 623,629 ---- unsigned char* fromPtr = outBin.frameData; unsigned char fromSize = outBin.frameSize; outBin.frameSize = 0; // for the next time this bin is used + resultIsSynchronized = outBin.fIsSynchronized; // Check whether this frame is missing; if so, return a FT_NO_DATA frame: if (fromSize == 0) { From finlayson at live555.com Mon Mar 5 08:50:50 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 5 Mar 2007 08:50:50 -0800 Subject: [Live-devel] AMR timestamps In-Reply-To: <20070305155911.7084644199@ws5-1.us4.outblaze.com> References: <20070305155911.7084644199@ws5-1.us4.outblaze.com> Message-ID: Thanks. This will be included in the next release of the software. >OK sorry about that. I also fixed a small bug in method MIMEtype() >that always returned the string "audio/AMR-WB" whatever the type of AMR. Actually, I also made a small change to this fix. The actual choice (according to RFC 3267) is between "audio/AMR" and "audio/AMR-WB". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From TAYK0004 at ntu.edu.sg Mon Mar 5 09:39:36 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Tue, 6 Mar 2007 01:39:36 +0800 Subject: [Live-devel] PDA player Message-ID: <438567054C073949AEBE5A28B83E7DE133FCF5@MAIL21.student.main.ntu.edu.sg> Hi guys, I have completed a PC streamer (using Visual C++) which streams H.264/MP3 using MPEG2 TS. I have tested it with VLC on PC to receive the TS and it works perfectly. However, I am looking for a PDA player (Windows Mobile 5) to test the TS. I have tried using VLC (PDA version), however, it does not support multicast. Can anyone share his/her experience on this issue? I have tried to search for PDA softwares to no avail and have to resort to using livemedia mailing list for help. As part of sharing, I will be most willing to share my streamer source code with the rest after testing it on the pda. Thank you and regards. Zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070305/67d5a40b/attachment.html From susovan at tataelxsi.co.in Tue Mar 6 01:38:42 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Tue, 6 Mar 2007 15:08:42 +0530 Subject: [Live-devel] Recv system call Message-ID: <002a01c75fd3$3af4d310$0a2a320a@telxsi.com> Hi all, i used live555 server to stream .ts file to STB.It is ok for some time ,but after that the STB can not receive data from socket and "recv system call" return zero. but recv system call can not return zero.I kniow it is the problem of SBV.If any one can identify this problem please help me. Thank You. SUSOVAN GHOSH PH No-9986667320 Engineer (D&D) PRDE TATAELXSI LIMITED From susovan at tataelxsi.co.in Tue Mar 6 02:51:03 2007 From: susovan at tataelxsi.co.in (Susovan Ghosh) Date: Tue, 6 Mar 2007 16:21:03 +0530 Subject: [Live-devel] Configuration Message-ID: <002f01c75fdd$5679ea30$0a2a320a@telxsi.com> Hi all, i want to configured the server, means i want to change the bit rate,Max no of client connection,Unicast IP address.how i can do this.What are those file where i have to change those parameter.If any one know those file plese help me to know those files. Thank You. SUSOVAN GHOSH PH No-9986667320 Engineer (D&D) PRDE TATAELXSI LIMITED From finlayson at live555.com Tue Mar 6 03:06:26 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 6 Mar 2007 03:06:26 -0800 Subject: [Live-devel] Configuration In-Reply-To: <002f01c75fdd$5679ea30$0a2a320a@telxsi.com> References: <002f01c75fdd$5679ea30$0a2a320a@telxsi.com> Message-ID: > i want to configured the server, means i want to change the bit >rate,Max no of client connection,Unicast IP address. None of those three things makes any sense. 1/ The bit rate depends upon the file that you're streaming (the data streams at the same rate that data would be consumed if the file were played locally). 2/ There is no inherent limit on the number of client connections (any such limit would be a property of your OS and/or your network, not the application). And 3/ the IP address that the server sends to is that of the client. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From ruru605 at 163.com Tue Mar 6 06:58:51 2007 From: ruru605 at 163.com (ruru605) Date: Tue, 6 Mar 2007 23:58:51 +0900 Subject: [Live-devel] help_SDES Message-ID: <200703062358461255535@163.com> Hi, everyone I have a question as follows: I want to transmit "User name SDES item" using RTCP, so in the addSDES(), I enqueue the name after the SDES item in the form of NAME=2 length text, however, when I use Ethereal to grap packet, SDES items show that they only includes one Type(CNAME). What should I do if I want to add new item,please help me. Thanks a lot. Regards ru ruru605 2007-03-06 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070306/d94903a2/attachment.html From martin.gutenbrunner at telekom.at Wed Mar 7 00:35:43 2007 From: martin.gutenbrunner at telekom.at (Gutenbrunner Martin) Date: Wed, 7 Mar 2007 09:35:43 +0100 Subject: [Live-devel] Trick play on Amino 110 Message-ID: hi! Although there are many posts about trick play, I haven't been able to find the solution for my specific problem: I am able to stream an indexed transport stream with my amino box. but when I push ffwd or rewind, the image freezes. after pressing play again it becomes obvious that the video really forwarded (or rewinded) faster, the forwarding just wasn't visible. how comes that forwarding and rewinding aren't 'visible' to the user? my /mnt/nv/config.txt has amino.rtsp.scale set to 3 (also already tried with 6) amino.rtsp.server wasn't set, so I added amino.rtsp.server=nCube what else can I try to solve this problem? thanks in advance for your help and keep up the great work. It's amazing stuff you're doing here :-) regards martin gutenbrunner -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070307/b9b1e127/attachment.html From finlayson at live555.com Wed Mar 7 04:27:51 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 7 Mar 2007 04:27:51 -0800 Subject: [Live-devel] Trick play on Amino 110 In-Reply-To: References: Message-ID: >I am able to stream an indexed transport stream with my amino box. >but when I push ffwd or rewind, the image freezes. after pressing >play again it becomes obvious that the video really forwarded (or >rewinded) faster, the forwarding just wasn't visible. > >how comes that forwarding and rewinding aren't 'visible' to the user? I'm not sure. The only thing I can suggest is that perhaps the higher bit rate of the 'trick play' streams (because, in such streams, each frame is an I-frame) is overwhelming your set-top box or (less likely) your network. Assuming that you have sufficient network bandwidth (e.g., you're not going through a 10 Mbps Ethernet switch), then the only thing I can suggest is seeing if there is some way to increase your STB's input buffering. (Not being an expert on Amino STBs, however, I'm not sure how/if you can do 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/20070307/20f7723b/attachment.html From morgan.torvolt at gmail.com Wed Mar 7 05:18:45 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Wed, 7 Mar 2007 17:18:45 +0400 Subject: [Live-devel] Trick play on Amino 110 In-Reply-To: References: Message-ID: <3cc3561f0703070518g64259e6cmf133f099788059fc@mail.gmail.com> > I am able to stream an indexed transport stream with my amino box. but when > I push ffwd or rewind, the image freezes. after pressing play again it > becomes obvious that the video really forwarded (or rewinded) faster, the > forwarding just wasn't visible. > > how comes that forwarding and rewinding aren't 'visible' to the user? > > > I'm not sure. The only thing I can suggest is that perhaps the higher bit > rate of the 'trick play' streams (because, in such streams, each frame is an > I-frame) is overwhelming your set-top box or (less likely) your network. Quite possible. I cannot confirm this though, as I have not tested your trick play yet. I do know that the 110H box does handle immense ammounts of data in an expected manner though. We tried dumping 100Mbit to it, and it decoded some portions at least, but with alot of garbage. Here it sounds as if there is nothing on screen at all, which sounds weird to me. As for a "fix", would it be possible to add a feature that ensures that not more than 5 (or something) I frames are transmitted per second, and then just skip the rest? That would limit the bandwidth demand quite a bit I would think, and could possibly make the frames more watchable. Maybe even 3 is enough per second. > Assuming that you have sufficient network bandwidth (e.g., you're not going > through a 10 Mbps Ethernet switch), then the only thing I can suggest is > seeing if there is some way to increase your STB's input buffering. (Not > being an expert on Amino STBs, however, I'm not sure how/if you can do > this.) -- I believe this is NDA material unfortunately since all the documentation covering this is marked confidential. Asking Amino about it or reading some documentation could answer this. -Morgan- From martin.gutenbrunner at telekom.at Wed Mar 7 06:44:19 2007 From: martin.gutenbrunner at telekom.at (Gutenbrunner Martin) Date: Wed, 7 Mar 2007 15:44:19 +0100 Subject: [Live-devel] Trick play on Amino 110 In-Reply-To: <3cc3561f0703070518g64259e6cmf133f099788059fc@mail.gmail.com> References: <3cc3561f0703070518g64259e6cmf133f099788059fc@mail.gmail.com> Message-ID: >As for a "fix", would it be possible to add a feature that ensures that not more than 5 (or something) I frames are transmitted per second, and then just skip the rest? That would limit the bandwidth demand quite a bit I would think, and could possibly make the frames more watchable. Maybe even 3 is enough per second. trick play does work with oracle video servers. does this mean that ovs automatically reduces bandwith to make trick play possible? is there anything I can do to find out, how ovs works? (ie ethereal stream sniffing, etc) thanks From morgan.torvolt at gmail.com Wed Mar 7 07:06:24 2007 From: morgan.torvolt at gmail.com (=?ISO-8859-1?Q?Morgan_T=F8rvolt?=) Date: Wed, 7 Mar 2007 19:06:24 +0400 Subject: [Live-devel] Trick play on Amino 110 In-Reply-To: References: <3cc3561f0703070518g64259e6cmf133f099788059fc@mail.gmail.com> Message-ID: <3cc3561f0703070706md4aa19dja454ff51fbe57c33@mail.gmail.com> > trick play does work with oracle video servers. does this mean that ovs > automatically reduces bandwith to make trick play possible? Yes, it should. It is a commercial video server, and the STB producers and VOD server producers make it work somehow. > is there anything I can do to find out, how ovs works? (ie ethereal > stream sniffing, etc) You could allways take a look at the stream it produces. You could dump it to disk using VLC or live555s RTSPclient. To check the bandwidht, you could do that while dumping it to disk. I am unsure if VLC supports trick play yet though, and if OVS is standard compliant enough to work with the mentioned clients. -Morgan- From finlayson at live555.com Wed Mar 7 21:31:36 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 7 Mar 2007 21:31:36 -0800 Subject: [Live-devel] Trick play on Amino 110 In-Reply-To: References: <3cc3561f0703070518g64259e6cmf133f099788059fc@mail.gmail.com> Message-ID: A reminder to people who may be having trouble getting Transport Stream trick play to work with some clients: We provide a utility "testMPEG2TransportStreamTrickPlay" which generates - from an original Transport Stream file plus index file - a new Transport Stream file that contains the effect of 'fast forward' or 'reverse play' applied to the original stream. This file will contain the exact same data that the server would send if you had requested 'fast forward' or 'reverse play' from the client. See for more details. Therefore, you can try streaming the resulting Transport Stream file (without indexing) to the client, to see how the client handles it. You may find this an easier way to debug your client. In general, though, note that this mailing list is *not* the right place to be be complaining about problems with clients (unless, of course, those clients use the "LIVE555 Streaming Media" software). In particular, problems with the Amino set-top boxes are best discussed on an Amino-related mailing list. Live Networks, Inc. is not affiliated with Amino Technologies, and we don't know enough about their hardware to debug it. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070307/797d39c9/attachment.html From martin.gutenbrunner at telekom.at Thu Mar 8 01:50:12 2007 From: martin.gutenbrunner at telekom.at (Gutenbrunner Martin) Date: Thu, 8 Mar 2007 10:50:12 +0100 Subject: [Live-devel] Trick play on Amino 110 In-Reply-To: References: <3cc3561f0703070518g64259e6cmf133f099788059fc@mail.gmail.com> Message-ID: >A reminder to people who may be having trouble getting Transport Stream trick play to work with some clients: We provide a utility >"testMPEG2TransportStreamTrickPlay" which generates - from an original Transport Stream file plus index file - a new Transport Stream file that contains the >effect of 'fast forward' or 'reverse play' applied to the original stream. This file will contain the exact same data that the server would send if you had >requested 'fast forward' or 'reverse play' from the client. ok, tried that. the "accelerated" video stream (scale 3) plays correctly on the amino box. I have scale in /mnt/nv/config.txt also set to 3. that would mean that an unaccelerated stream should be fast forwarded absolutely the same way as the output file from testMPEG2TransportStreamTrickPlay.exe, no? >In general, though, note that this mailing list is *not* the right place to be be complaining about problems with clients (unless, of course, those clients use the >"LIVE555 Streaming Media" software). In particular, problems with the Amino set-top boxes are best discussed on an Amino-related mailing list. Live Networks, >Inc. is not affiliated with Amino Technologies, and we don't know enough about their hardware to debug it. Sorry if you got the impression that I'm complaining about anything. The fact that the box is working with ovs but not with live555 made me believe that this would be the right place to ask questions. Actually, I think it's really great work you accomplish, especially when regarding the fact that your software is free. So, complaining about anything really was the last thing I intended and your help is very much appreciated. I just thought it would be also of interest to you if your server was able to handle a larger variety of clients. So if I can be of any help to you in extending your software to work with amino (or adb, I also work with ADB-3800TW but that box will be tested in a few days) clients, I'd be really glad. Thanks martin From finlayson at live555.com Thu Mar 8 02:52:38 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Mar 2007 02:52:38 -0800 Subject: [Live-devel] Trick play on Amino 110 In-Reply-To: References: <3cc3561f0703070518g64259e6cmf133f099788059fc@ma il.gmail.com> Message-ID: > >A reminder to people who may be having trouble getting Transport Stream >trick play to work with some clients: We provide a utility >>"testMPEG2TransportStreamTrickPlay" which generates - from an original >Transport Stream file plus index file - a new Transport Stream file that >contains the >>effect of 'fast forward' or 'reverse play' applied to the original >stream. This file will contain the exact same data that the server would >send if you had >>requested 'fast forward' or 'reverse play' from the client. > >ok, tried that. the "accelerated" video stream (scale 3) plays correctly >on the amino box. I have scale in /mnt/nv/config.txt also set to 3. > >that would mean that an unaccelerated stream should be fast forwarded >absolutely the same way as the output file from >testMPEG2TransportStreamTrickPlay.exe, no? That's correct - which surprises me even more that you are having problems when playing 'fast forward' using an Amino 110 STB. (I, and most others who have used that client, have not had any such problems.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rmpg2001 at gmail.com Thu Mar 8 03:52:21 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Thu, 8 Mar 2007 12:52:21 +0100 Subject: [Live-devel] frameDurationInMicroseconds Message-ID: <389189e20703080352g4922797cjbb48c9b1fa48c954@mail.gmail.com> Hi all, I am working on a H264 Streamer. It works very well with VLC and QuickTime but I need that the frames will be sent exactly (as much as possible) at 40 mseg, so I set frameDurationInMicroseconds to 40000. I used Etherreal to analize packet's time and I saw that packets are sent in intervals of 32-33 mseg. and 47-48 mseg. Main time is correct but is there any way to send packets regulary to 40 mseg?? Someone says to me that it is possible an error of using Windows and Visual C++ to build Live libraries. It can be solved building Live in UNIX/Linux? Ramon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070308/da4942c9/attachment.html From finlayson at live555.com Thu Mar 8 04:07:34 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Mar 2007 04:07:34 -0800 Subject: [Live-devel] frameDurationInMicroseconds In-Reply-To: <389189e20703080352g4922797cjbb48c9b1fa48c954@mail.gmail.com> References: <389189e20703080352g4922797cjbb48c9b1fa48c954@mail.gmail.com> Message-ID: >Hi all, >I am working on a H264 Streamer. It works very well with VLC and >QuickTime but I need that the frames will be sent exactly (as much >as possible) at 40 mseg, so I set frameDurationInMicroseconds to >40000. I used Etherreal to analize packet's time and I saw that >packets are sent in intervals of 32-33 mseg. and 47-48 mseg. Main >time is correct but is there any way to send packets regulary to 40 >mseg?? > >Someone says to me that it is possible an error of using Windows and >Visual C++ to build Live libraries. It can be solved building Live >in UNIX/Linux? Perhaps - Windows' timers are notoriously inaccurate. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From alvaro.i at ikusi.es Thu Mar 8 05:48:10 2007 From: alvaro.i at ikusi.es (=?iso-8859-1?Q?=C1lvaro_Pajuelo=2C_I=F1aki?=) Date: Thu, 8 Mar 2007 14:48:10 +0100 Subject: [Live-devel] Raw UDP streaming Message-ID: <435A66F076E8344FA6D3917739BD99A4914AC7@srviku004.ikusi.net> Hello, Please could you help me to configure the wis-streamer to stream raw udp rather than standard RTP streaming. I'm using an Amino IP STB that only acepts raw udp. It's possible ? which command must I use ?. Another question what is the bandwitdh limit for the wis-streamer. I'm using a demo board from micronas and I see pixelation when I increase the bandwidth (upper 6Mbis/seg). Best Regards, I?aki Alvaro PajueloI?aki Alvaro Pajuelo R&D Dept. Project Manager IP Area Design & Manufacturing Division alvaro.i at ikusi.es www.ikusi.es --- IKUSI - ?ngel Iglesias, S.A. Paseo Miram?n, 170 20009 San Sebasti?n SPAIN Tel: +34 943 448800 Fax: +34 943 448811 From finlayson at live555.com Thu Mar 8 06:11:09 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Mar 2007 06:11:09 -0800 Subject: [Live-devel] Raw UDP streaming In-Reply-To: <435A66F076E8344FA6D3917739BD99A4914AC7@srviku004.ikusi.net> References: <435A66F076E8344FA6D3917739BD99A4914AC7@srviku004.ikusi.net> Message-ID: >Please could you help me to configure the wis-streamer to stream raw >udp rather than standard >RTP streaming. I'm using an Amino IP STB that only acepts raw udp. >It's possible ? Yes - this is already supported by "wis-streamer" (and our other RTSP server applications, such as the "LIVE555 Media Server" ). Note, however, that the stream must be unicast on demand - not multicast, because the Amino STBs (at least, the ones that I have tested) do not handle multicast streams. Note also that if you use an Amino STB client to play your stream, then *all* clients must be Amino STBs. Because of limitations of the software, you cannot mix Amino STBs with other clients (such as VLC) that request RTP/UDP streaming. >Another question what is the bandwitdh limit for the wis-streamer. The application itself has no inherent bandwidth limit. The only limits are those imposed (indirectly) by your hardware, OS, and network. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From alvaro.i at ikusi.es Thu Mar 8 06:34:48 2007 From: alvaro.i at ikusi.es (=?iso-8859-1?Q?=C1lvaro_Pajuelo=2C_I=F1aki?=) Date: Thu, 8 Mar 2007 15:34:48 +0100 Subject: [Live-devel] Raw UDP streaming In-Reply-To: Message-ID: <435A66F076E8344FA6D3917739BD99A4914AC8@srviku004.ikusi.net> Thank you for your fast response. Do you Know which command must I use ?. I?aki. -----Mensaje original----- De: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com]En nombre de Ross Finlayson Enviado el: 08/03/2007 03:11 Para: LIVE555 Streaming Media - development & use Asunto: Re: [Live-devel] Raw UDP streaming >Please could you help me to configure the wis-streamer to stream raw >udp rather than standard >RTP streaming. I'm using an Amino IP STB that only acepts raw udp. >It's possible ? Yes - this is already supported by "wis-streamer" (and our other RTSP server applications, such as the "LIVE555 Media Server" ). Note, however, that the stream must be unicast on demand - not multicast, because the Amino STBs (at least, the ones that I have tested) do not handle multicast streams. Note also that if you use an Amino STB client to play your stream, then *all* clients must be Amino STBs. Because of limitations of the software, you cannot mix Amino STBs with other clients (such as VLC) that request RTP/UDP streaming. >Another question what is the bandwitdh limit for the wis-streamer. The application itself has no inherent bandwidth limit. The only limits are those imposed (indirectly) by your hardware, OS, and network. -- 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 Mar 8 06:45:27 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Mar 2007 06:45:27 -0800 Subject: [Live-devel] Raw UDP streaming In-Reply-To: <435A66F076E8344FA6D3917739BD99A4914AC8@srviku004.ikusi.net> References: <435A66F076E8344FA6D3917739BD99A4914AC8@srviku004.ikusi.net> Message-ID: >Thank you for your fast response. Do you Know which command must I use ?. Please read the documentation: . (Search for "MPEG Transport".) -- 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/20070308/8e7c688c/attachment-0001.html From alvaro.i at ikusi.es Thu Mar 8 07:50:58 2007 From: alvaro.i at ikusi.es (=?iso-8859-1?Q?=C1lvaro_Pajuelo=2C_I=F1aki?=) Date: Thu, 8 Mar 2007 16:50:58 +0100 Subject: [Live-devel] Raw UDP streaming In-Reply-To: Message-ID: <435A66F076E8344FA6D3917739BD99A4914AC9@srviku004.ikusi.net> Dear Ross, I tried with the parameter you said -mpegtransport but I hope the stream is sent using RTP yet, now I can see it with the amino box, but the image goes slowly. It seems that doesn't have timming information or the information is not OK. In this mode are you using RTP headers or only UDP ?. you include PCR information ?. Best Regards, I?aki. -----Mensaje original----- De: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com]En nombre de Ross Finlayson Enviado el: 08/03/2007 03:45 Para: LIVE555 Streaming Media - development & use Asunto: Re: [Live-devel] Raw UDP streaming Thank you for your fast response. Do you Know which command must I use ?. Please read the documentation: . (Search for "MPEG Transport".) -- 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/20070308/51623ffe/attachment.html From finlayson at live555.com Thu Mar 8 09:20:57 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Mar 2007 09:20:57 -0800 Subject: [Live-devel] Raw UDP streaming In-Reply-To: <435A66F076E8344FA6D3917739BD99A4914AC9@srviku004.ikusi.net> References: <435A66F076E8344FA6D3917739BD99A4914AC9@srviku004.ikusi.net> Message-ID: >I tried with the parameter you said -mpegtransport but I hope the >stream is sent using RTP yet, now I can see it >with the amino box, but the image goes slowly. Try playing around with the encoder bit rate and frame rate parameters. That's all I can suggest right now... >In this mode are you using RTP headers or only UDP ? Yes, the Amino STB requests raw UDP streaming, so that's what the server delivers. -- 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/20070308/442e210d/attachment.html From rmerca at adinet.com.uy Thu Mar 8 09:31:15 2007 From: rmerca at adinet.com.uy (rmerca at adinet.com.uy) Date: Thu, 8 Mar 2007 14:31:15 -0300 (UYT) Subject: [Live-devel] Need to stream wav files over RTP Message-ID: <4006584.1173375075654.JavaMail.tomcat@fe-ps01> Hi: I am developing a web application that has to be able to transmit wav files audio over RTP to a destination IP, where a Cisco IP Phone is ready to accept that RTP stream. I need to transmit 50 RTP packets per second, G711 u-law, and I have wav files format of 8 bit, 8000Hz, Mono. I wonder if you have any software solution that can be used in my ASP. NET application to accomplish this task. I would really appreciate any response Regards, Rodrigo Mercader -------------- next part -------------- An embedded message was scrubbed... From: "rmerca at adinet.com.uy" Subject: Need to stream wav files over RTP Date: Thu, 8 Mar 2007 11:56:20 -0300 (UYT) Size: 1011 Url: http://lists.live555.com/pipermail/live-devel/attachments/20070308/44d3514c/attachment.mht From finlayson at live555.com Thu Mar 8 11:32:17 2007 From: finlayson at live555.com (Ross Finlayson) Date: Thu, 8 Mar 2007 11:32:17 -0800 Subject: [Live-devel] Need to stream wav files over RTP In-Reply-To: <4006584.1173375075654.JavaMail.tomcat@fe-ps01> References: <4006584.1173375075654.JavaMail.tomcat@fe-ps01> Message-ID: >Hi: >I am developing a web application that has to be able to transmit wav >files audio over RTP to a destination IP, where a Cisco IP Phone is >ready >to accept that RTP stream. We have code, and applications (e.g., "testWAVAudioStreamer" (multicast), "testOnDemandRTSPServer" (unicast) and "live555MediaServer" (unicast) that will stream WAV file data via RTP. However, we do not yet have a SIP server implementation, so it's not clear whether or not you will be able to use our code to stream to an IP phone. You will need to evaluate our code for yourself to figure this out. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From rmpg2001 at gmail.com Fri Mar 9 00:49:23 2007 From: rmpg2001 at gmail.com (Ramon Martin de Pozuelo) Date: Fri, 9 Mar 2007 09:49:23 +0100 Subject: [Live-devel] frameDurationInMicroseconds In-Reply-To: References: <389189e20703080352g4922797cjbb48c9b1fa48c954@mail.gmail.com> Message-ID: <389189e20703090049k3f2a2fadu62b90e8465ef7056@mail.gmail.com> Hi, I fix it. It's a Windows problem. I add to link options "winmm.lib" library. This library has some functions where you can change Windows timers' precision. Using timeBeginPeriod(1) you set the timer precision to 1 ms. (By default it seems that it's set to 16 ms). Though I solved it in Windows, I think I will start to move my project to UNIX, to avoid more future problems. Thank you very much, Ramon 2007/3/8, Ross Finlayson : > > >Hi all, > >I am working on a H264 Streamer. It works very well with VLC and > >QuickTime but I need that the frames will be sent exactly (as much > >as possible) at 40 mseg, so I set frameDurationInMicroseconds to > >40000. I used Etherreal to analize packet's time and I saw that > >packets are sent in intervals of 32-33 mseg. and 47-48 mseg. Main > >time is correct but is there any way to send packets regulary to 40 > >mseg?? > > > >Someone says to me that it is possible an error of using Windows and > >Visual C++ to build Live libraries. It can be solved building Live > >in UNIX/Linux? > > Perhaps - Windows' timers are notoriously inaccurate. > > -- > > 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/20070309/4dc0350b/attachment.html From yelite993 at 163.com Fri Mar 9 01:10:40 2007 From: yelite993 at 163.com (=?gbk?B?0ac=?=) Date: Fri, 9 Mar 2007 17:10:40 +0800 (CST) Subject: [Live-devel] HELP: About the LATM format in ISO/IEC 14496-3 Message-ID: <2886968.2928471173431440414.JavaMail.root@bj163app17.163.com> Dear All, I have a question about the AudioMuxElement() in LATM format in ISO/IEC 14496-3:2005. Following is the Syntax of AudioMuxElement(): AudioMuxElement(muxConfigPresent) { if (muxConfigPresent) { useSameStreamMux; if (!useSameStreamMux) StreamMuxConfig(); } if (audioMuxVersionA == 0) { for (i = 0; i <= numSubFrames; i++) { PayloadLengthInfo(); PayloadMux(); } . . . } } I think somebody should have konwn that the StreamMuxConfig() is not octet-aligned. So I have to shift all of the bytes of the AAC frame to generate the PayloadMux()? In this case it's very inefficient. Can anybody give me some suggestions? And tell me which palyers can play the LATM format audio data? Thank you very much, Best Wishes, yelite -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070309/919f1502/attachment.html From luc47654 at yahoo.it Fri Mar 9 13:25:18 2007 From: luc47654 at yahoo.it (luca norm) Date: Fri, 9 Mar 2007 22:25:18 +0100 (CET) Subject: [Live-devel] Frame Rate and (soft) real-time extensions Message-ID: <751997.57783.qm@web23413.mail.ird.yahoo.com> Hi, I have noticed that in some classes, there's a durationInMicroseconds var which appears as a parameter but it is never set with a value different than 0 (default). So, I ask: should I do my own implementation for the frame rate control (using it in doGetNextFrame())? In addition, the variable above is "marked" for microseconds: is this a tip for the implementation? If so, in order to have the control of a task with timing costraints in microseconds , should I add (soft) Real Time extensions to my tasks (for example RTAI or RTLinux)? For example: if I want to make a streamer which streams exactly at 25 fps, should i add these extensions? any help/info is greatly appreciated, Luca ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html From finlayson at live555.com Fri Mar 9 16:26:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Mar 2007 16:26:40 -0800 Subject: [Live-devel] Frame Rate and (soft) real-time extensions In-Reply-To: <751997.57783.qm@web23413.mail.ird.yahoo.com> References: <751997.57783.qm@web23413.mail.ird.yahoo.com> Message-ID: >I have noticed that in some classes, there's a >durationInMicroseconds var which appears as a >parameter but it is never set with a value different >than 0 (default). At present, the "fDurationInMicroseconds" field is currently used only when *sending* RTP packets, to figure out how long to wait until sending the next packet. This means that - in practice - the field need be set only when data is being streamed from a file. (If data is being received - or if data is being streamed from a live source - then it's not important that that variable be set.) >For example: if I want to make a streamer which >streams exactly at 25 fps, should i add these >extensions? Trying to stream packets at a perfectly even rate - without any jitter, is pointless. The network will always add some jitter anyway, and the receiving client(s) - if implemented correctly - will have enough buffer memory to absorb network jitter. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From brainlai at gmail.com Fri Mar 9 19:07:11 2007 From: brainlai at gmail.com (Brain Lai) Date: Sat, 10 Mar 2007 11:07:11 +0800 Subject: [Live-devel] liveness issue on the server side Message-ID: Dear Sir: The RTSPServer has taken care of client session liveness. In contrast, the RTSPClient seems not to note server liveness now. Is it unnecessary or something missed? Regards Brain Lai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070309/35712abc/attachment-0001.html From finlayson at live555.com Fri Mar 9 21:30:14 2007 From: finlayson at live555.com (Ross Finlayson) Date: Fri, 9 Mar 2007 21:30:14 -0800 Subject: [Live-devel] liveness issue on the server side In-Reply-To: References: Message-ID: >Dear Sir: > >The RTSPServer has taken care of client session liveness. >In contrast, the RTSPClient seems not to note server liveness now. Yes it does - by sending RTCP "Reception Report" (RR) packets. The server interprets incoming RTCP packets (or RTSP commands) from a client as indicating its 'liveness'. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From brainlai at gmail.com Sat Mar 10 00:37:12 2007 From: brainlai at gmail.com (Brain Lai) Date: Sat, 10 Mar 2007 16:37:12 +0800 Subject: [Live-devel] liveness issue on the server side In-Reply-To: References: Message-ID: Well, I mean if an RTSP server dies accidentally or closes the session without sending RTCP BYE, will an RTSPClient sense that with some kind of timeout mechanism? It seems that the RTSPClient has not implemented this feature so far ... Regards Brain Lai 2007/3/10, Ross Finlayson : > > >Dear Sir: > > > >The RTSPServer has taken care of client session liveness. > >In contrast, the RTSPClient seems not to note server liveness now. > > Yes it does - by sending RTCP "Reception Report" (RR) packets. The > server interprets incoming RTCP packets (or RTSP commands) from a > client as indicating its 'liveness'. > -- > > 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/20070310/6af7283e/attachment.html From info at dnastudios.it Sun Mar 11 14:16:21 2007 From: info at dnastudios.it (DNA STUDIOS s.r.l.) Date: Sun, 11 Mar 2007 23:16:21 +0100 Subject: [Live-devel] livemedia & mplayer Message-ID: <45F47FB5.9050902@dnastudios.it> I have find a bug (i think...) in the way that mplayer use livemedia. When i stream with mplayer from DSS, in "connected user" of Darwin i see 2 connection from the same host...this very strange and i think that this is a bug. I know that mplayer use live555 libraries to stream RTSP, i have tried VLC and openRTS but only with mplayer i see 2 connection in Darwin; i tried with and without -rtsp-stream-over-tcp but is the same thing.... Someone know this "bug" and someone knows in that way can be solved this problem? Thanks. ----------------------------- Nicola From dweber at robotics.net Sun Mar 11 15:44:39 2007 From: dweber at robotics.net (Dan Weber) Date: Sun, 11 Mar 2007 18:44:39 -0500 Subject: [Live-devel] Segfault in doEventLoop Message-ID: <20070311234439.GA2294@Barney.robotics.net> Hi there, I called doEventLoop and it's segfaulting on the fact that it appears SingleStep is inexistant i.e. pure virtual. It compiled fine, and I made sure I was using BasicTaskScheduler::createNew(). In the debugger, the task scheduler clearly was resolved but in BasicTaskScheduler0... it called SingleStep and segfaulted. Do you have any ideas? Dan From finlayson at live555.com Sun Mar 11 16:29:02 2007 From: finlayson at live555.com (Ross Finlayson) Date: Sun, 11 Mar 2007 17:29:02 -0700 Subject: [Live-devel] livemedia & mplayer In-Reply-To: <45F47FB5.9050902@dnastudios.it> References: <45F47FB5.9050902@dnastudios.it> Message-ID: >I have find a bug (i think...) in the way that mplayer use livemedia. >When i stream with mplayer from DSS, in "connected user" of Darwin i see >2 connection from the same host... By "connection", do you mean TCP connection? If so, then yes, it probably is a bug, but Remember, You Have Complete Source Code, which will enable you to track it down. If by "connection", however, you mean UDP socket, then this is normal - there's one socket for RTP, and one for RTCP, for each media type. So, if the stream contains both audio and video, then there will be 4 UDP sockets. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Mon Mar 12 23:14:19 2007 From: finlayson at live555.com (Ross Finlayson) Date: Mon, 12 Mar 2007 23:14:19 -0700 Subject: [Live-devel] Testing - please ignore Message-ID: Testing our new mail server - please ignore. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jarod.dong at gmail.com Tue Mar 13 00:29:56 2007 From: jarod.dong at gmail.com (Jarod Dong) Date: Tue, 13 Mar 2007 15:29:56 +0800 Subject: [Live-devel] the frame gotten from MPEG4ESVideoRTPSource Message-ID: <3099c0f30703130029s443e5a1fn977d6f124054ff8a@mail.gmail.com> Hi everyone, I just want to know what I get when using getNextFrame() in class MPEG4ESVideoRTPSource. Is it a VOP? Thank you. -- Free trade reduces world suffering. From TAYK0004 at ntu.edu.sg Tue Mar 13 01:38:44 2007 From: TAYK0004 at ntu.edu.sg (#TAY KOON HWEE#) Date: Tue, 13 Mar 2007 16:38:44 +0800 Subject: [Live-devel] Multicast over Wireless LAN Message-ID: <438567054C073949AEBE5A28B83E7DE133FCF9@MAIL21.student.main.ntu.edu.sg> Hi guys, I have the following problem with multicasting. My program installed in my PC is able to unicast to laptops/PDA connected wireless to my router. However, for multicasting, it only works for devices connected by LAN cable to my router. Therefore PDA will not be able to receive the multicast while laptop if connected via LAN cable to the router will be able to receive the multicast. Weird thing is if my program installed on my laptop (wireless connected to my router) is about to stream (unicast and multcast) to devices connected by wires to the router. Does the RTCP Bandwidth got to do with it? I have set my estimatedSessionBandwidthVideo = 512. Can anyone advise on the above problem? Thank you and regards. zkunhui -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070313/6e8987d8/attachment.html From stabrawa at stanford.edu Tue Mar 13 02:18:00 2007 From: stabrawa at stanford.edu (Tim Stabrawa) Date: Tue, 13 Mar 2007 04:18:00 -0500 Subject: [Live-devel] Multicast over Wireless LAN In-Reply-To: <438567054C073949AEBE5A28B83E7DE133FCF9@MAIL21.student.main.ntu.edu.sg> References: <438567054C073949AEBE5A28B83E7DE133FCF9@MAIL21.student.main.ntu.edu.sg> Message-ID: <45F66C48.5000409@stanford.edu> #TAY KOON HWEE# wrote: > Hi guys, > > I have the following problem with multicasting. My program installed > in my PC is able to unicast to laptops/PDA connected wireless to my > router. However, for multicasting, it only works for devices connected > by LAN cable to my router. Therefore PDA will not be able to receive > the multicast while laptop if connected via LAN cable to the router > will be able to receive the multicast. > > Weird thing is if my program installed on my laptop (wireless > connected to my router) is about to stream (unicast and multcast) to > devices connected by wires to the router. > > Does the RTCP Bandwidth got to do with it? I have set my > estimatedSessionBandwidthVideo = 512. > > Can anyone advise on the above problem? > My best guess is that your router itself is at fault. The way most switches work with multicast is they'll treat it as broadcast and flood the network. (You'd have to shell out extra bucks to get one that handles it smarter - read up on GMRP (802.1p) if you care.) Now, wireless routers on the other hand, tend to do something funky with how they connect up the wireless and wired clients. For example, the Linksys WRT54G has physically separate interfaces to the main processor for wireless and wired clients. It provides connectivity between the two with a software bridge (which effectively combines them as if they were connected via a hardware switch). FWIW, it looks like multicast traffic is being forwarded to my wireless link on my WRT54G (only verified by looking at the LED's though). Chances are your particular router is trying to be smart and is filtering multicast traffic from appearing on the wireless interface (presumably so it doesn't bog down the wireless link with useless data). It's possible, although unlikely, that you can receive the data from your wireless device if you do a GMRP join procedure for the multicast session(s) you're interested in. I've never done this in practice though, since I've never actually seen a switch that supports GMRP. Anyways, hopefully some of this is useful or interesting. It kept me amused writing it at least. :-) Good luck, - Tim From mrnikhilagrawal at gmail.com Mon Mar 12 23:53:34 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Tue, 13 Mar 2007 12:23:34 +0530 Subject: [Live-devel] Regarding streaming Jpeg images Message-ID: <733cde3e0703122353l106760cm4af263a53ae2ecad@mail.gmail.com> Hi Ross, I want to stream Jpeg images. I have still pictures in Jpeg format , what classes i need to derive and what needs to be implemented . What functions need to be implemented. Thanks and Regards, Nikhil Agrawal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070312/289d5619/attachment.html From finlayson at live555.com Tue Mar 13 03:11:17 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Mar 2007 03:11:17 -0700 Subject: [Live-devel] Regarding streaming Jpeg images In-Reply-To: <733cde3e0703122353l106760cm4af263a53ae2ecad@mail.gmail.com> References: <733cde3e0703122353l106760cm4af263a53ae2ecad@mail.gmail.com> Message-ID: >Hi Ross, > >I want to stream Jpeg images. I have still pictures in Jpeg format , >what classes i need to derive and what needs to be implemented . >What functions need to be implemented. Please read the FAQ. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From opera at kth.se Tue Mar 13 03:45:10 2007 From: opera at kth.se (=?ISO-8859-1?Q?Gustaf_R=E4ntil=E4?=) Date: Tue, 13 Mar 2007 11:45:10 +0100 Subject: [Live-devel] Streaming MPEG2 TS with separate audio and video input Message-ID: <45F680B6.5010006@kth.se> Hi, I'd like to stream (with rtsp) a transport stream of MPEG2 to an amino. It works well for single files muxed with video and audio (using the technique as for the onDemand-test-program, with a test.ts file). But I'd like to use one video file and one audio file. When using two instances of : sms->addSubsession(MPEG2TransportFileServerMediaSubsession::createNew(...)); the players (amino, mplayer, vlc) dies or halts. Mplayer says it received two video streams. Is there a solution for how to accomplish this, or do I have to use pre-muxed single files? Note; The output stream needs to be bundled as a TS. Gustaf From rmerca at adinet.com.uy Tue Mar 13 05:33:58 2007 From: rmerca at adinet.com.uy (rmerca at adinet.com.uy) Date: Tue, 13 Mar 2007 09:33:58 -0300 (UYT) Subject: [Live-devel] Need to stream wav files over RTP Message-ID: <23695311.1173789238974.JavaMail.tomcat@fe-ps01> I only need a software capable of handle concurrent RTP request, though, the ability to send RTP from wav to many IP addresses and ports. >----Mensaje original---- >De: live-devel-request at ns.live555.com >Fecha: 13/03/2007 07:16 >Para: >Asunto: live-devel Digest, Vol 41, Issue 8 > >Send live-devel mailing list submissions to > live-devel at lists.live555.com > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.live555.com/mailman/listinfo/live-devel >or, via email, send a message with subject or body 'help' to > live-devel-request at lists.live555.com > >You can reach the person managing the list at > live-devel-owner at lists.live555.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of live-devel digest..." > > >Today's Topics: > > 1. Re: liveness issue on the server side (Ross Finlayson) > 2. Re: liveness issue on the server side (Brain Lai) > 3. livemedia & mplayer (DNA STUDIOS s.r.l.) > 4. Segfault in doEventLoop (Dan Weber) > 5. Re: livemedia & mplayer (Ross Finlayson) > 6. Testing - please ignore (Ross Finlayson) > 7. the frame gotten from MPEG4ESVideoRTPSource (Jarod Dong) > 8. Multicast over Wireless LAN (#TAY KOON HWEE#) > 9. Re: Multicast over Wireless LAN (Tim Stabrawa) > 10. Regarding streaming Jpeg images (Nikhil Agrawal) > 11. Re: Regarding streaming Jpeg images (Ross Finlayson) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 9 Mar 2007 21:30:14 -0800 >From: Ross Finlayson >Subject: Re: [Live-devel] liveness issue on the server side >To: LIVE555 Streaming Media - development & use > >Message-ID: >Content-Type: text/plain; charset="us-ascii" ; format="flowed" > >>Dear Sir: >> >>The RTSPServer has taken care of client session liveness. >>In contrast, the RTSPClient seems not to note server liveness now. > >Yes it does - by sending RTCP "Reception Report" (RR) packets. The >server interprets incoming RTCP packets (or RTSP commands) from a >client as indicating its 'liveness'. >-- > >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ > > >------------------------------ > >Message: 2 >Date: Sat, 10 Mar 2007 16:37:12 +0800 >From: "Brain Lai" >Subject: Re: [Live-devel] liveness issue on the server side >To: "LIVE555 Streaming Media - development & use" > >Message-ID: > >Content-Type: text/plain; charset="iso-8859-1" > >Well, I mean if an RTSP server dies accidentally or closes the session >without sending RTCP BYE, >will an RTSPClient sense that with some kind of timeout mechanism? >It seems that the RTSPClient has not implemented this feature so far ... > >Regards >Brain Lai > >2007/3/10, Ross Finlayson : >> >> >Dear Sir: >> > >> >The RTSPServer has taken care of client session liveness. >> >In contrast, the RTSPClient seems not to note server liveness now. >> >> Yes it does - by sending RTCP "Reception Report" (RR) packets. The >> server interprets incoming RTCP packets (or RTSP commands) from a >> client as indicating its 'liveness'. >> -- >> >> 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/20070310/6af7283e/attachment-0001.html > >------------------------------ > >Message: 3 >Date: Sun, 11 Mar 2007 23:16:21 +0100 >From: "DNA STUDIOS s.r.l." >Subject: [Live-devel] livemedia & mplayer >To: live-devel at ns.live555.com >Message-ID: <45F47FB5.9050902 at dnastudios.it> >Content-Type: text/plain; charset=ISO-8859-15; format=flowed > >I have find a bug (i think...) in the way that mplayer use livemedia. >When i stream with mplayer from DSS, in "connected user" of Darwin i see >2 connection from the same host...this very strange and i think that >this is a bug. >I know that mplayer use live555 libraries to stream RTSP, i have tried >VLC and openRTS but only with mplayer i see 2 connection in Darwin; i >tried with and without -rtsp-stream-over-tcp but is the same thing.... >Someone know this "bug" and someone knows in that way can be solved this >problem? >Thanks. >----------------------------- >Nicola > > >------------------------------ > >Message: 4 >Date: Sun, 11 Mar 2007 18:44:39 -0500 >From: Dan Weber >Subject: [Live-devel] Segfault in doEventLoop >To: live-devel at ns.live555.com >Message-ID: <20070311234439.GA2294 at Barney.robotics.net> >Content-Type: text/plain; charset=us-ascii > > >Hi there, > >I called doEventLoop and it's segfaulting on the fact that it >appears SingleStep is inexistant i.e. pure virtual. It compiled fine, >and I made sure I was using BasicTaskScheduler::createNew(). In the debugger, >the task scheduler clearly was resolved but in BasicTaskScheduler0... it >called SingleStep and segfaulted. Do you have any ideas? > >Dan > > >------------------------------ > >Message: 5 >Date: Sun, 11 Mar 2007 17:29:02 -0700 >From: Ross Finlayson >Subject: Re: [Live-devel] livemedia & mplayer >To: LIVE555 Streaming Media - development & use > >Message-ID: >Content-Type: text/plain; charset="us-ascii" ; format="flowed" > >>I have find a bug (i think...) in the way that mplayer use livemedia. >>When i stream with mplayer from DSS, in "connected user" of Darwin i see >>2 connection from the same host... > >By "connection", do you mean TCP connection? If so, then yes, it >probably is a bug, but Remember, You Have Complete Source Code, which >will enable you to track it down. > >If by "connection", however, you mean UDP socket, then this is normal >- there's one socket for RTP, and one for RTCP, for each media type. >So, if the stream contains both audio and video, then there will be 4 >UDP sockets. >-- > >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ > > >------------------------------ > >Message: 6 >Date: Mon, 12 Mar 2007 23:14:19 -0700 >From: Ross Finlayson >Subject: [Live-devel] Testing - please ignore >To: live-devel at ns.live555.com >Message-ID: >Content-Type: text/plain; charset="us-ascii" ; format="flowed" > >Testing our new mail server - please ignore. >-- > >Ross Finlayson >Live Networks, Inc. >http://www.live555.com/ > > >------------------------------ > >Message: 7 >Date: Tue, 13 Mar 2007 15:29:56 +0800 >From: "Jarod Dong" >Subject: [Live-devel] the frame gotten from MPEG4ESVideoRTPSource >To: live-devel at ns.live555.com >Message-ID: > <3099c0f30703130029s443e5a1fn977d6f124054ff8a at mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Hi everyone, > >I just want to know what I get when using getNextFrame() in class >MPEG4ESVideoRTPSource. Is it a VOP? Thank you. > >-- >Free trade reduces world suffering. > > >------------------------------ > >Message: 8 >Date: Tue, 13 Mar 2007 16:38:44 +0800 >From: "#TAY KOON HWEE#" >Subject: [Live-devel] Multicast over Wireless LAN >To: >Message-ID: > <438567054C073949AEBE5A28B83E7DE133FCF9 at MAIL21.student.main.ntu.edu. sg> > >Content-Type: text/plain; charset="iso-8859-1" > >Hi guys, > >I have the following problem with multicasting. My program installed in my PC is able to unicast to laptops/PDA connected wireless to my router. However, for multicasting, it only works for devices connected by LAN cable to my router. Therefore PDA will not be able to receive the multicast while laptop if connected via LAN cable to the router will be able to receive the multicast. > >Weird thing is if my program installed on my laptop (wireless connected to my router) is about to stream (unicast and multcast) to devices connected by wires to the router. > >Does the RTCP Bandwidth got to do with it? I have set my estimatedSessionBandwidthVideo = 512. > >Can anyone advise on the above problem? > >Thank you and regards. > >zkunhui >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: http://lists.live555.com/pipermail/live- devel/attachments/20070313/6e8987d8/attachment-0001.html > >------------------------------ > >Message: 9 >Date: Tue, 13 Mar 2007 04:18:00 -0500 >From: Tim Stabrawa >Subject: Re: [Live-devel] Multicast over Wireless LAN >To: LIVE555 Streaming Media - development & use > >Message-ID: <45F66C48.5000409 at stanford.edu> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >#TAY KOON HWEE# wrote: >> Hi guys, >> >> I have the following problem with multicasting. My program installed >> in my PC is able to unicast to laptops/PDA connected wireless to my >> router. However, for multicasting, it only works for devices connected >> by LAN cable to my router. Therefore PDA will not be able to receive >> the multicast while laptop if connected via LAN cable to the router >> will be able to receive the multicast. >> >> Weird thing is if my program installed on my laptop (wireless >> connected to my router) is about to stream (unicast and multcast) to >> devices connected by wires to the router. >> >> Does the RTCP Bandwidth got to do with it? I have set my >> estimatedSessionBandwidthVideo = 512. >> >> Can anyone advise on the above problem? >> > >My best guess is that your router itself is at fault. The way most >switches work with multicast is they'll treat it as broadcast and flood >the network. (You'd have to shell out extra bucks to get one that >handles it smarter - read up on GMRP (802.1p) if you care.) > >Now, wireless routers on the other hand, tend to do something funky with >how they connect up the wireless and wired clients. For example, the >Linksys WRT54G has physically separate interfaces to the main processor >for wireless and wired clients. It provides connectivity between the >two with a software bridge (which effectively combines them as if they >were connected via a hardware switch). FWIW, it looks like multicast >traffic is being forwarded to my wireless link on my WRT54G (only >verified by looking at the LED's though). > >Chances are your particular router is trying to be smart and is >filtering multicast traffic from appearing on the wireless interface >(presumably so it doesn't bog down the wireless link with useless >data). It's possible, although unlikely, that you can receive the data >from your wireless device if you do a GMRP join procedure for the >multicast session(s) you're interested in. I've never done this in >practice though, since I've never actually seen a switch that supports GMRP. > >Anyways, hopefully some of this is useful or interesting. It kept me >amused writing it at least. :-) > >Good luck, > >- Tim > > >------------------------------ > >Message: 10 >Date: Tue, 13 Mar 2007 12:23:34 +0530 >From: "Nikhil Agrawal" >Subject: [Live-devel] Regarding streaming Jpeg images >To: live-devel at ns.live555.com >Message-ID: > <733cde3e0703122353l106760cm4af263a53ae2ecad at mail.gmail.com> >Content-Type: text/plain; charset="iso-8859-1" > >Hi Ross, > >I want to stream Jpeg images. I have still pictures in Jpeg format , what >classes i need to derive and what needs to be implemented . >What functions need to be implemented. > >Thanks and Regards, >Nikhil Agrawal >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: http://lists.live555.com/pipermail/live- devel/attachments/20070312/289d5619/attachment-0001.html > >------------------------------ > >Message: 11 >Date: Tue, 13 Mar 2007 03:11:17 -0700 >From: Ross Finlayson >Subject: Re: [Live-devel] Regarding streaming Jpeg images >To: LIVE555 Streaming Media - development & use > >Message-ID: >Content-Type: text/plain; charset="us-ascii" ; format="flowed" > >>Hi Ross, >> >>I want to stream Jpeg images. I have still pictures in Jpeg format , >>what classes i need to derive and what needs to be implemented . >>What functions need to be implemented. > >Please read the FAQ. >-- > >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 > > >End of live-devel Digest, Vol 41, Issue 8 >***************************************** > From finlayson at live555.com Tue Mar 13 06:38:40 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Mar 2007 06:38:40 -0700 Subject: [Live-devel] Streaming MPEG2 TS with separate audio and video input In-Reply-To: <45F680B6.5010006@kth.se> References: <45F680B6.5010006@kth.se> Message-ID: >Hi, > >I'd like to stream (with rtsp) a transport stream of MPEG2 to an amino. >It works well for single files muxed with video and audio (using the >technique as for the onDemand-test-program, with a test.ts file). But >I'd like to use one video file and one audio file. When using two >instances of : >sms->addSubsession(MPEG2TransportFileServerMediaSubsession::createNew(...)); >the players (amino, mplayer, vlc) dies or halts. Mplayer says it >received two video streams. > >Is there a solution for how to accomplish this, or do I have to use >pre-muxed single files? > >Note; The output stream needs to be bundled as a TS. Yes, you can multiplex the input audio and video streams together into a single Transport Stream, and stream that. You would do this using a subclass of "MPEG2TransportStreamMultiplexor" - e.g., "MPEG2TransportStreamFromESSource.hh". For example, look at how the "wis-streamer" code combines separate audio and video sources into a single Transport Stream - see "WISMPEG2TransportStreamServerMediaSubsession.cpp". -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From finlayson at live555.com Tue Mar 13 06:52:42 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Mar 2007 06:52:42 -0700 Subject: [Live-devel] the frame gotten from MPEG4ESVideoRTPSource In-Reply-To: <3099c0f30703130029s443e5a1fn977d6f124054ff8a@mail.gmail.com> References: <3099c0f30703130029s443e5a1fn977d6f124054ff8a@mail.gmail.com> Message-ID: >Hi everyone, > >I just want to know what I get when using getNextFrame() in class >MPEG4ESVideoRTPSource. See RFC 3016 - especially sections 3.2 and 3.3. -- 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/20070313/a1cdf165/attachment.html From vinodjoshi at tataelxsi.co.in Tue Mar 13 07:24:23 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Tue, 13 Mar 2007 19:54:23 +0530 Subject: [Live-devel] FW: Query for Live555 forum. Message-ID: <002a01c7657b$4ca87640$022a320a@telxsi.com> Hi all, We are using Live 555 Streaming Server to stream MPEG-2 TS to the Set Top Box as a client. The transactions "DESCRIBE", "SETUP"," PLAY" are correctly happening on both server and client side. But we are hit at a problem , the problem is that after a particular time period server stops streaming before "TEARDOWN" transaction to happen. At that instant recv( ) system call is failing. We want to know that whether the client needs to send any message during streaming. Is anybody facing the same problem? What the solution for this can be to prevent this ? Is anybody having more information about this? Thank You. From xcsmith at rockwellcollins.com Tue Mar 13 08:26:45 2007 From: xcsmith at rockwellcollins.com (xcsmith at rockwellcollins.com) Date: Tue, 13 Mar 2007 10:26:45 -0500 Subject: [Live-devel] Re: Query for Live555 forum. Message-ID: >> We want to know that whether the client needs to send any message during streaming. If your client does not implement RTCP, you need to send periodic RTSP messages. If you are not sending RTCP reports or RTSP messages, then the RTSP server will think the client has died, and the server will stop the stream. You can check the way you instantiate the RTSP server, but I think the default might be something like 45 seconds. Maybe this is not what is happening to you though, I'm not sure what you have for a client. How long is the period of time before the stream stops? Is the stream from a file or some other device? From antoniotirri at libero.it Tue Mar 13 12:46:42 2007 From: antoniotirri at libero.it (Antonio Tirri) Date: Tue, 13 Mar 2007 20:46:42 +0100 Subject: [Live-devel] Simulation and packet loss, part three In-Reply-To: References: <45E60C79.3090606@libero.it> Message-ID: <45F6FFA2.9000902@libero.it> Hi, I edited the live555 mediaserver in order to apply the Gilbert model to send the video packets (gilbert model.jpg) The code is: void MultiFramedRTPSink::sendPacketIfNecessary() { //antonio static int state = 0; double p = 0.70; // defining p double q = 0.20; // defining q if (fNumFramesUsedSoFar > 0) { if ((state == 0) && ((double)(our_random()%10000))/10000.0 <= p) stato =1; else if((state == 1) && ((double)(our_random()%10000))/10000.0 <=q) stato =0; if(stato == 0)fRTPInterface.sendPacket(fOutBuf->packet(), fOutBuf->curPacketSize()); ++fPacketCount; fTotalOctetCount += fOutBuf->curPacketSize(); fOctetCount += fOutBuf->curPacketSize() - rtpHeaderSize - fSpecialHeaderSize - fTotalFrameSpecificHeaderSizes; ++fSeqNo; // for next time } if (fOutBuf->haveOverflowData() && fOutBuf->totalBytesAvailable() > fOutBuf->totalBufferSize()/2) { // Efficiency hack: Reset the packet start pointer to just in front of // the overflow data (allowing for the RTP header and special headers), // so that we probably don't have to "memmove()" the overflow data // into place when building the next packet: unsigned newPacketStart = fOutBuf->curPacketSize() - (rtpHeaderSize + fSpecialHeaderSize + frameSpecificHeaderSize()); fOutBuf->adjustPacketStart(newPacketStart); } else { // Normal case: Reset the packet start pointer back to the start: fOutBuf->resetPacketStart(); } fOutBuf->resetOffset(); fNumFramesUsedSoFar = 0; if (fNoFramesLeft) { // We're done: onSourceClosure(this); } else { // We have more frames left to send. Figure out when the next frame // is due to start playing, then make sure that we wait this long before // sending the next packet. struct timeval timeNow; gettimeofday(&timeNow, NULL); int uSecondsToGo; if (fNextSendTime.tv_sec < timeNow.tv_sec) { uSecondsToGo = 0; // prevents integer underflow if too far behind } else { uSecondsToGo = (fNextSendTime.tv_sec - timeNow.tv_sec)*1000000 + (fNextSendTime.tv_usec - timeNow.tv_usec); } // Delay this amount of time: nextTask() = envir().taskScheduler().scheduleDelayedTask(uSecondsToGo, (TaskFunc*)sendNext, this); } } I need to implement a scrambler and a descrambler as showed in the modello.gif, in order to implement this technique of scrambling (for more information: http://en.wikipedia.org/wiki/Scrambler_%28randomizer%29 ) How can i start this work? Thanks, Antonio Tirri -------------- next part -------------- A non-text attachment was scrubbed... Name: modello.GIF Type: image/gif Size: 2376 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070313/72f82c1f/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: gilbert model.jpg Type: image/jpeg Size: 11902 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070313/72f82c1f/attachment-0001.jpg From lkml.list at gmail.com Tue Mar 13 16:44:14 2007 From: lkml.list at gmail.com (Karthik) Date: Tue, 13 Mar 2007 19:44:14 -0400 Subject: [Live-devel] H263+ streamer Message-ID: <5718a99f0703131644q1ee8b6a1w17838f20e5012a89@mail.gmail.com> Hi, I am looking to implement a H263+ streamer. I tried to implement the streamer based on the testMPEG1or2VideoStreamer.cpp file. I did this by replacing the MPEG1or2 classes as H263plus classes (esp the H263plusVideoRTPSink class). Is this right? Now, I provide a video file encoded using an H263+ encoder as an input the testH263plusVideoStreamer executable. I also built the receiver part of the program by using the H263plusVideoRTPSource class. I stream the video ( video.263) file to the receiver and storethe received video. When I check the file size, they are different. Also, the packet trace generated provides an invalid packet of 3 bytes size at the beginning of the stream. Is this a bug? I also find that some of the header fields of some frames do not match the original H263 stream. Is Live modifying the headers or omitting some (GOB headers)? If anyone else has come across this problem please let me know. TIA, Karthik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.live555.com/pipermail/live-devel/attachments/20070313/1c1c9fbf/attachment.html From finlayson at live555.com Tue Mar 13 18:25:03 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Mar 2007 18:25:03 -0700 Subject: [Live-devel] H263+ streamer In-Reply-To: <5718a99f0703131644q1ee8b6a1w17838f20e5012a89@mail.gmail.com> References: <5718a99f0703131644q1ee8b6a1w17838f20e5012a89@mail.gmail.com> Message-ID: >I am looking to implement a H263+ streamer. I tried to implement the >streamer based on the testMPEG1or2VideoStreamer.cpp file. > >I did this by replacing the MPEG1or2 classes as H263plus classes >(esp the H263plusVideoRTPSink class). Is this right? Yes. > >Now, I provide a video file encoded using an H263+ encoder as an >input the testH263plusVideoStreamer executable. I also built the >receiver part of the program by using the H263plusVideoRTPSource >class. I stream the video ( video.263) file to the receiver and >storethe received video. > >When I check the file size, they are different. Also, the packet >trace generated provides an invalid packet of 3 bytes size at the >beginning of the stream. Is this a bug? Perhaps. Some of the H.263 code - specifically, "H263plusVideoFileServerMediaSubsession.cpp", "H263plusVideoStreamFramer.cpp" and "H263plusVideoStreamParser.cpp" - was written by a 3rd party, and I have not had time to review it in detail myself. So it's conceivable that there might be a bug there (or perhaps in some of the other H.263-related code). >I also find that some of the header fields of some frames do not >match the original H263 stream. Is Live modifying the headers or >omitting some (GOB headers)? I don't know. Unfortunaetly you're going to have to track this down yourself, by reviewing the source code, and RFC 2429, which it implements. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From jarod.dong at gmail.com Tue Mar 13 20:50:36 2007 From: jarod.dong at gmail.com (Jarod Dong) Date: Wed, 14 Mar 2007 11:50:36 +0800 Subject: [Live-devel] the frame gotten from MPEG4ESVideoRTPSource In-Reply-To: References: <3099c0f30703130029s443e5a1fn977d6f124054ff8a@mail.gmail.com> Message-ID: <3099c0f30703132050l372326l7d9e55e677e87fc1@mail.gmail.com> Hi Ross, As my understanding of the RFC, there should be some frames containing GOV headers, but my test shows that all frames started with VOP headers. 2007/3/13, Ross Finlayson : > > > Hi everyone, > > I just want to know what I get when using getNextFrame() in class > MPEG4ESVideoRTPSource. > > > See RFC 3016 - > especially sections 3.2 and 3.3. -- > > > > 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 > > -- Free trade reduces world suffering. From vinodjoshi at tataelxsi.co.in Tue Mar 13 23:09:44 2007 From: vinodjoshi at tataelxsi.co.in (Vinod Madhav Joshi) Date: Wed, 14 Mar 2007 11:39:44 +0530 Subject: [Live-devel] Query for Live555 forum. In-Reply-To: Message-ID: <002d01c765ff$5d611da0$022a320a@telxsi.com> Hi, Thanks for the reply. The video is stopping near about 45 seconds. I want to know at what time interval do the client needs to send RTCP packets or RTSP message. If RTSP message can be sent to the server, which specific RTSP message do we need to send? Thank You.. -----Original Message----- From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com]On Behalf Of xcsmith at rockwellcollins.com Sent: Tuesday, March 13, 2007 8:57 PM To: live-devel at ns.live555.com Subject: [Live-devel] Re: Query for Live555 forum. >> We want to know that whether the client needs to send any message during streaming. If your client does not implement RTCP, you need to send periodic RTSP messages. If you are not sending RTCP reports or RTSP messages, then the RTSP server will think the client has died, and the server will stop the stream. You can check the way you instantiate the RTSP server, but I think the default might be something like 45 seconds. Maybe this is not what is happening to you though, I'm not sure what you have for a client. How long is the period of time before the stream stops? Is the stream from a file or some other device? _______________________________________________ live-devel mailing list live-devel at lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel From finlayson at live555.com Tue Mar 13 23:17:32 2007 From: finlayson at live555.com (Ross Finlayson) Date: Tue, 13 Mar 2007 23:17:32 -0700 Subject: [Live-devel] Query for Live555 forum. In-Reply-To: <002d01c765ff$5d611da0$022a320a@telxsi.com> References: <002d01c765ff$5d611da0$022a320a@telxsi.com> Message-ID: > I want to know at what time interval do the client needs to send RTCP >packets or RTSP message. If RTCP is implemented properly, then RTCP packets will be sent much more frequently than 45s. Note that - according to the RTP standard - RTCP is *not* optional. You should implement it (provided of course, that you are streaming via RTP, and not raw-UDP). > If RTSP message can be sent to the server, which specific RTSP message > do we need to send? "GET_PARAMETER" will work. (Our RTSP server implementation will ignore the contents of that message, and just send back an empty response.) (Note that the "LIVE555 Streaming Media" software includes a RTSP/RTP/RTCP *client* implementation, as well as a server implementation.) -- Ross Finlayson Live Networks, Inc. http://www.live555.com/ From mrnikhilagrawal at gmail.com Wed Mar 14 03:54:49 2007 From: mrnikhilagrawal at gmail.com (Nikhil Agrawal) Date: Wed, 14 Mar 2007 16:24:49 +0530 Subject: [Live-devel] Regarding streaming Jpeg images In-Reply-To: References: <733cde3e0703122353l106760cm4af263a53ae2ecad@mail.gmail.com> Message-ID: <733cde3e0703140354o42f741d0vf4794daad5a87426@mail.gmail.com> Hi, I have implemented all the classes ( subclass of JPEGVideoSource and JPEGVideoFileServerMediaSubsession). I have two queries 1. I am using a single image output.jpeg ( taken from live555 forum mail attachment). I dont know what is the Q factor of the image. How can i calculate Q factor.(I tried with some default values) (also provided in attachment) 2. What the type value i should use , i have tried both 0 and 1. 3. Looking into packets that are flowing across network , i found that first packet( 1428 bytes approx) is missing and remaining data is flowing.Also I dumped data using client OpenRTSP , is shows data with first few ( ~ 1428) bytes missing and remining present). What further steps I need to take? Regards, Nikhil Agrawal On 3/13/07, Ross Finlayson wrote: > > >Hi Ross, > > > >I want to stream Jpeg images. I have still pictures in Jpeg format , > >what classes i need to derive and what needs to be implemented . > >What functions need to be implemented. > > Please read the FAQ. > -- > > 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/20070314/98d9199f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: test.jpg Type: image/jpeg Size: 22060 bytes Desc: not available Url : http://lists.live555.com/pipermail/live-devel/attachments/20070314/98d9199f/attachment-0001.jpg From kurutepe at nue.tu-berlin.de Wed Mar 14 06:01:04 2007 From: kurutepe at nue.tu-berlin.de (Engin Kurutepe) Date: Wed, 14 Mar 2007 14:01:04 +0100 Subject: [Live-devel] doEventLoop watch variable Message-ID: <45F7F210.8020107@nue.tu-berlin.de> Dear Ross, I want to implement stream switching in my RTSP client. So after I start streaming by doEventLoop(watch), I understand I can interrupt the loop by setting *watch=1. My idea is to use a separate control thread to watch for keyboard inputs, which will set the watch variable. If the event loop is interrupted streams will be switched and another doEventLoop(watch) to keep streaming. My question is how are the scheduled tasks affected when the event loop is interrupted. Are they unscheduled or do they continue unaffected after the loop resumes? Thanks a lot, Engin. From finlayson at live555.com Wed Mar 14 06:14:53 2007 From: finlayson at live555.com (Ross Finlayson) Date: Wed, 14 Mar 2007