Re: rv10 vbr broadcasting bitrate puzzle
Steve McMillen <[email protected]> Thu, 26 Nov 2009 00:48:01 -0800
| Newsgroups | gmane.comp.multimedia.helix.devel |
|---|---|
| Message-ID | <[email protected]> |
That's a fair ask. I'll see if I can put some resource on this. I don't recall seeing a job file in this thread. Can you send me one so we can make sure to reproduce what you are seeing. -- Steve on 11/26/2009 12:13 AM Alan Li wrote the following: > Steve, > > I really appreciated your lengthy discussion. Here is my answer: > > 1. Our business is using rm encoding for surveillance type and the producer to server is the bottleneck and critical path because we are using 2.75G/3G wireless channel for that. > > 2. We have demonstrated the low efficiency (average 30% overhead compared to supposedly 10% in theory) for the transmission between Helix producer and server. > > 3. Since there is no significant improvement for rm encoding on release 13, so there is no need for helix producer sdk update. > > Since waiting for next sdk (v14) release is simply too far away and that overhead is critical for our product efficiency and business success as a Helix technology OEM partner, Our only request is if there is any way for Real to allocate resource to do the following two things: > > 1. Validate if 30% overhead in general is true or not. > 2. If it turns out that the 30% overhead is true, is there any thing we can do ourselves based on the current Helix producer sdk 11.1 source code to improve the situation (possibly with the help from Real/Helix engineer's pointer or advise)? > > thanks a lot, > > alan > > --- On Wed, 11/25/09, Steve McMillen<[email protected]> wrote: > > >> From: Steve McMillen<[email protected]> >> Subject: Re: rv10 vbr broadcasting bitrate puzzle >> To: "Alan Li"<[email protected]> >> Date: Wednesday, November 25, 2009, 6:50 AM >> There was not a release of the >> Producer 13 SDK. Just the application. >> And just in case you were wondering, there was no version >> 12; we skipped >> it to align our version with the server. >> >> In terms of RM format, you are probably jus as well >> sticking with >> Producer 11.1. No significant changes at the SDK >> level to RM format so >> not really worth upgrading. The big change in the 13 >> release was that >> we added 3GPP formats (264, mpg4, 263, aac, amr codecs) and >> revamped the >> UI in a big way. While some bugs might have been >> fixed, some others may >> be introduced. >> >> It is possible to build Producer 13 SDK thru the community >> but it would >> need to be QA'ed. Right now we don't see the demand >> on the SDK from a >> commercial perspective. Of course, it could be that >> we are not aware of >> who all is using it so maybe you could elaborate to me how >> your company >> is using the SDK and if you know of others actively >> supporting >> generation of content in the RM format. If there is >> enough demand, I >> may be able to convince the business side of the house to >> allocate >> resources towards a release of the SDK v13 and look into >> some of the >> multiple output bug you reported before (which btw we have >> not seen in >> the testing we did on v13. More likely that a v14 >> (which is started) >> would have an SDK release. >> >> -- Steve >> >> on 11/25/2009 12:39 AM Alan Li wrote the following: >> >>> Hi, Steve, >>> >>> Just want to let you know I did find the release of >>> >> RealProducer 13 from the website, but I could NOT find the >> corresponding sdk from Helix community website. What we >> really need is the Helix Producer SDK. Could you give a >> pointer for where we can download it or it is available from >> the CVS source tree as Helix developer? thanks, >> >>> alan >>> >>> --- On Tue, 11/24/09, Alan Li<[email protected]> >>> >> wrote: >> >>> >>> >>>> From: Alan Li<[email protected]> >>>> Subject: Re: rv10 vbr broadcasting bitrate puzzle >>>> To: "Steve McMillen"<[email protected]> >>>> Date: Tuesday, November 24, 2009, 9:19 PM >>>> Hi, Steve, >>>> >>>> You mean Real released RealProducer 13? We are >>>> >> stilling >> >>>> using Helix DNA Producer SDK 11! Please let me >>>> >> know where we >> >>>> can download V13 (producer sdk or producer, >>>> >> whatever). Many >> >>>> thanks, and many thanks for giving this important >>>> >> low >> >>>> efficicy a whack as early as you could. >>>> >>>> alan >>>> >>>> --- On Tue, 11/24/09, Steve McMillen<[email protected]> >>>> wrote: >>>> >>>> >>>> >>>>> From: Steve McMillen<[email protected]> >>>>> Subject: Re: rv10 vbr broadcasting bitrate >>>>> >> puzzle >> >>>>> To: "Alan Li"<[email protected]> >>>>> Cc: [email protected], >>>>> >>>>> >>>> "Gregory Wright"<[email protected]> >>>> >>>> >>>>> Date: Tuesday, November 24, 2009, 8:00 PM >>>>> Thanks for clarifying. >>>>> >>>>> While certainly this is less efficient than it >>>>> >> ought >> >>>>> >>>>> >>>> to be, >>>> >>>> >>>>> I suspect >>>>> the explanation boils down to something in >>>>> >> the >> >>>>> >>>>> >>>> protocol - >>>> >>>> >>>>> more than >>>>> likely something that should not be >>>>> >> happening. >> >>>>> Right now, as you know, we released version 13 >>>>> >> and the >> >>>>> >>>>> >>>> big >>>> >>>> >>>>> fish for us >>>>> to fry at the moment is stability as this was >>>>> >> a major >> >>>>> release in that we >>>>> added many new data types and >>>>> >> functionality. Part >> >>>>> >>>>> >>>> of >>>> >>>> >>>>> our goal for the >>>>> next cycle is broadcast reliability. >>>>> >> Even that does >> >>>>> not really >>>>> encompass efficiency of the data stream but >>>>> >> I'll put >> >>>>> >>>>> >>>> it >>>> >>>> >>>>> down as >>>>> something to consider while we are into the >>>>> >> broadcast >> >>>>> libraries. More >>>>> importantly there are features like reconnect >>>>> >> and >> >>>>> >>>>> >>>> reliable >>>> >>>> >>>>> initial >>>>> connections that we want to clean up. >>>>> >>>>> -- Steve >>>>> >>>>> on 11/24/2009 5:00 PM Alan Li wrote the >>>>> >> following: >> >>>>> >>>>> >>>>>> Hi, Steve, >>>>>> >>>>>> Just want to clarify the bitrate overhead >>>>>> >> is >> >>>>>> >>>>>> >>>> between >>>> >>>> >>>>> PRODUCER and SERVER, NOT between the server >>>>> >> and >> >>>>> >>>>> >>>> player, >>>> >>>> >>>>> which I tested quite thoroughly. Again, the >>>>> >>>>> >>>> broadcasting >>>> >>>> >>>>> bitrate (captured on the server) overhead >>>>> >> could be as >> >>>>> >>>>> >>>> high >>>> >>>> >>>>> as 50% more than the encoded bitrate (server >>>>> >> archived >> >>>>> >>>>> >>>> file), >>>> >>>> >>>>> but in general it is at least 20-30% more than >>>>> >> the >> >>>>> >>>>> >>>> encoded >>>> >>>> >>>>> bitrate. >>>>> >>>>> >>>>>> May I suggest that Real's producer team >>>>>> >> could >> >>>>>> >>>>>> >>>> allocate >>>> >>>> >>>>> an engineer to spend a little time to verify >>>>> >> this and >> >>>>> >>>>> >>>> try to >>>> >>>> >>>>> give a more convincing explanation? It seems >>>>> >> to be a >> >>>>> >>>>> >>>> big >>>> >>>> >>>>> issue for Helix users to expand the Helix >>>>> >>>>> >>>> producer/server >>>> >>>> >>>>> product to wireless network. Thanks, >>>>> >>>>> >>>>>> alan >>>>>> >>>>>> --- On Tue, 11/24/09, Steve McMillen<[email protected]> >>>>>> >>>>>> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>>> From: Steve McMillen<[email protected]> >>>>>>> Subject: Re: rv10 vbr broadcasting >>>>>>> >> bitrate >> >>>>>>> >>>>>>> >> >> >>>> puzzle >>>> >>>> >>>>>>> To: "Alan Li"<[email protected]> >>>>>>> Cc: [email protected], >>>>>>> >>>>>>> >> >> >>>>> "Gregory Wright"<[email protected]> >>>>> >>>>> >>>>>>> Date: Tuesday, November 24, 2009, 2:22 >>>>>>> >> AM >> >>>>>>> Even the archived RM file has packet >>>>>>> overhead (RM file format stores the >>>>>>> data packetized). So its quite >>>>>>> >> possible >> >>>>>>> >>>>>>> >> >> >>>> that >>>> >>>> >>>>> whatever >>>>> >>>>> >>>>>>> is attributing to >>>>>>> the additional overhead is even more >>>>>>> >> than >> >>>>>>> >>>>>>> >> >> >>>> 9%. >>>> >>>> >>>>>>> But I have no clue as to what it may >>>>>>> >> be. >> >>>>>>> >>>>>>> >> >> >>>>> Hopefully >>>>> >>>>> >>>>>>> someone else on the >>>>>>> discussion list has a better idea >>>>>>> >> about what >> >>>>>>> >>>>>>> >> >> >>>> goes >>>> >>>> >>>>> on >>>>> >>>>> >>>>>>> between the server >>>>>>> and the player and why this overhead >>>>>>> >> might be >> >>>>>>> >>>>>>> >> >> >>>> so >>>> >>>> >>>>> high. >>>>> >>>>> >>>>>>> -- Steve >>>>>>> >>>>>>> on 11/21/2009 8:39 PM Alan Li wrote >>>>>>> >> the >> >>>>>>> >>>>>>> >> >> >>>>> following: >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I did this many times with >>>>>>>> >> attached >> >>>>>>>> >>>>>>>> >> >> >>>> audience >>>> >>>> >>>>> file (150 >>>>> >>>>> >>>>>>>> >>>>>>>> >> >> >>>>>>> LAN) on a local LAN with one machine >>>>>>> >> having >> >>>>>>> >>>>>>> >> >> >>>> helix >>>> >>>> >>>>> producer >>>>> >>>>> >>>>>>> sdk 11 (mediasinkencoder.exe) and >>>>>>> >> another >> >>>>>>> >>>>>>> >> >> >>>> machine >>>> >>>> >>>>> having >>>>> >>>>> >>>>>>> helix server 12. What is found is the >>>>>>> >>>>>>> >> >> >>>> following: >>>> >>>> >>>>>>> >>>>>>> >> >> >>>>>>>> 1. Broadcasting bitrate is >>>>>>>> >> 191kbps, >> >>>>>>>> >>>>>>>> >> >> >>>> while >>>> >>>> >>>>> actual >>>>> >>>>> >>>>>>>> >>>>>>>> >> >> >>>>>>> encoded bitrate is 161kbps (from the >>>>>>> >> archived >> >>>>>>> >>>>>>> >> >> >>>> rm >>>> >>>> >>>>> file). >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>> 2. We know there is NO FEC and >>>>>>>> >> Re-Send >> >>>>>>>> >>>>>>>> >> >> >>>> (well, >>>> >>>> >>>>> it is >>>>> >>>>> >>>>>>>> >>>>>>>> >> >> >>>>>>> within 2 machines sit side-by-side >>>>>>> >> within a >> >>>>>>> >>>>>>> >> >> >>>> LAN, >>>> >>>> >>>>> it is crazy >>>>> >>>>> >>>>>>> to have packet loss) >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>> 3. We captured all packets on the >>>>>>>> >> server >> >>>>>>>> >>>>>>>> >> >> >>>>> using >>>>> >>>>> >>>>>>>> >>>>>>>> >> >> >>>>>>> WireShard. It is all seeming right >>>>>>> >> (average >> >>>>>>> >>>>>>> >> >> >>>> packet >>>> >>>> >>>>> size is >>>>> >>>>> >>>>>>> 367bytes, and the header size for each >>>>>>> >> packet >> >>>>>>> >>>>>>> >> >> >>>> is >>>> >>>> >>>>> 42 bytes >>>>> >>>>> >>>>>>> (14(Ethernet)+20(ip)+8(udp)). >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>> Based on the broadcasting header >>>>>>>> >> overhead >> >>>>>>>> >>>>>>>> >> >> >>>> and >>>> >>>> >>>>> possible >>>>> >>>>> >>>>>>>> >>>>>>>> >> >> >>>>>>> SDP annoucement, the overhead should >>>>>>> >> be >> >>>>>>> >>>>>>> >> >> >>>> definitely >>>> >>>> >>>>> within >>>>> >>>>> >>>>>>> 11%, but we experience almost 20% >>>>>>> >> extra >> >>>>>>> >>>>>>> >> >> >>>> overhead. >>>> >>>> >>>>>>> >>>>>>> >> >> >>>>>>>> We have experiments varing >>>>>>>> >> different >> >>>>>>>> >>>>>>>> >> >> >>>> audiences >>>> >>>> >>>>> and >>>>> >>>>> >>>>>>>> >>>>>>>> >> >> >>>>>>> bitrate and CBR vs. VBR and different >>>>>>> >>>>>>> >> >> >>>> encoding >>>> >>>> >>>>> length, most >>>>> >>>>> >>>>>>> of experiments show close to 20% >>>>>>> >> overhead >> >>>>>>> >>>>>>> >> >> >>>>> sometimes even >>>>> >>>>> >>>>>>> higher. >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>> What makes those extra overheads >>>>>>>> >> for >> >>>>>>>> >>>>>>>> >> >> >>>>> broadcasting? >>>>> >>>>> >>>>>>>> >>>>>>>> >> >> >>>>>>> This is really something we are >>>>>>> >> puzzled. It >> >>>>>>> >>>>>>> >> >> >>>> is >>>> >>>> >>>>> important to >>>>> >>>>> >>>>>>> get to the bottom of the truth because >>>>>>> >> those >> >>>>>>> >>>>>>> >> >> >>>> extra >>>> >>>> >>>>> 10 or >>>>> >>>>> >>>>>>> more percent overhead is quite crucial >>>>>>> >> for >> >>>>>>> >>>>>>> >> >> >>>>> wireless >>>>> >>>>> >>>>>>> channels. Anyone to shed some light on >>>>>>> >> this? >> >>>>>>> >>>>>>> >> >> >>>>> thanks a lot, >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>> alan, >>>>>>>> >>>>>>>> --- On Fri, 5/29/09, Steve >>>>>>>> >> McMillen<[email protected]> >> >>>>>>>> >>>>>>>> >> >> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>> >>>>>>>> >> >> >>>>>>>>> From: Steve McMillen<[email protected]> >>>>>>>>> Subject: Re: >>>>>>>>> >> [Helix-producer-dev] cbr >> >>>>>>>>> >>>>>>>>> >> >> >>>> vs. >>>> >>>> >>>>> vbr >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> bitrate >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> To: "Alan Li"<[email protected]> >>>>>>>>> Cc: "Gregory Wright"<[email protected]>, >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> [email protected] >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> Date: Friday, May 29, 2009, >>>>>>>>> >> 8:14 AM >> >>>>>>>>> Try a capture to file while >>>>>>>>> >> you are >> >>>>>>>>> broadcasting. The exact >>>>>>>>> >> same bits >> >>>>>>>>> (less packet overhead) is >>>>>>>>> >> written to >> >>>>>>>>> >>>>>>>>> >> >> >>>>> file. >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> So you >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> should be able to see >>>>>>>>> what the actual media bitrate >>>>>>>>> >> is from >> >>>>>>>>> >>>>>>>>> >> >> >>>> that >>>> >>>> >>>>> test. >>>>> >>>>> >>>>>>>>> Given my experience with the >>>>>>>>> >> codecs, >> >>>>>>>>> >>>>>>>>> >> >> >>>> I'd >>>> >>>> >>>>> be very >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> surprised >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> that you find >>>>>>>>> any more than a few kbps >>>>>>>>> >> over. My >> >>>>>>>>> >>>>>>>>> >> >> >>>>> guess is >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> something >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> is corrupting the >>>>>>>>> wireshark results (e.g. some >>>>>>>>> >> other >> >>>>>>>>> >>>>>>>>> >> >> >>>> traffic >>>> >>>> >>>>> flow or >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> some >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> extraordinary >>>>>>>>> amount of resend). >>>>>>>>> >>>>>>>>> -- Steve >>>>>>>>> >>>>>>>>> on 5/28/09 5:38 PM Alan Li >>>>>>>>> >> wrote the >> >>>>>>>>> >>>>>>>>> >> >> >>>>> following: >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> We directly use the >>>>>>>>>> >> audience file >> >>>>>>>>>> >>>>>>>>>> >> >> >>>> that >>>> >>>> >>>>> comes >>>>> >>>>> >>>>>>>>>> >>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> along >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>> >>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> with producersdk 11 on >>>>>>>>> >> windows, >> >>>>>>>>> >>>>>>>>> >> >> >>>>> particularly, we >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> use 150k >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> LAN.rpad, and alternatively >>>>>>>>> >> encode >> >>>>>>>>> >>>>>>>>> >> >> >>>> with >>>> >>>> >>>>> cbr vs >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> vbrBitrate. I >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> believe the codec is rv10. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>> alan >>>>>>>>>> >>>>>>>>>> --- On Tue, 5/26/09, >>>>>>>>>> >> Gregory >> >>>>>>>>>> >>>>>>>>>> >> >> >>>>> Wright<[email protected]> >>>>> >>>>> >>>>>>>>>> >>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>> >>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>>>> From: Gregory >>>>>>>>>>> >> Wright<[email protected]> >> >>>>>>>>>>> Subject: Re: >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> [Helix-producer-dev] >>>> >>>> >>>>> cbr vs. >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> vbr >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> bitrate >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> To: "Alan Li"<[email protected]> >>>>>>>>>>> Cc: [email protected] >>>>>>>>>>> Date: Tuesday, May 26, >>>>>>>>>>> >> 2009, >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> 7:15 >>>> >>>> >>>>> AM >>>>> >>>>> >>>>>>>>>>> Can you provide more >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> details, >>>> >>>> >>>>> like >>>>> >>>>> >>>>>>>>>>> the job file (source >>>>>>>>>>> >> content >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> type, >>>> >>>> >>>>> codec >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> used, >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> encoder >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> settings, >>>>>>>>>>> etc.). >>>>>>>>>>> >>>>>>>>>>> --greg. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On May 25, 2009, at >>>>>>>>>>> >> 6:48 PM, >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> Alan >>>> >>>> >>>>> Li >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> We are using >>>>>>>>>>>> >> producersdk >> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>> 11 on >>>> >>>> >>>>> Windows >>>>> >>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> >>>>> >>>>>>> and >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> noticed >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> huge difference in >>>>>>>>>>> >> bitrate >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> output >>>> >>>> >>>>> between >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> cbr >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> encoding and >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> vbr encoding. For the >>>>>>>>>>> >> same >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> audience >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> encoding at >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> 150kbps, the >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> actual CBR encoding >>>>>>>>>>> >> outputs >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> average >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> 230kbps (we >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> measured it >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> by using WireShark >>>>>>>>>>> >> capture on >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> the >>>> >>>> >>>>> server >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> side for >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> this >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> particular >>>>>>>>>>> >> broadcasting), >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> while >>>> >>>> >>>>> VBR >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> encoding >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> outputs 170kbps >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> in average. The >>>>>>>>>>> >> realplayer >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> reports >>>> >>>> >>>>> both >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> streams be >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> 150kbps. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> Apparently, we know >>>>>>>>>>> >> there >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> will be >>>> >>>> >>>>> some >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> overhead >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> with >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> udp/ip/ethernet >>>>>>>>>>> >> header, but >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> that >>>> >>>> >>>>> should >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> amount to >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> about 10% >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> more than the bitrate, >>>>>>>>>>> >> not >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> 50% or >>>> >>>> >>>>> even >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> higher >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> overhead. We >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> made sure there is No >>>>>>>>>>> >> FEC >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>> setting >>>> >>>> >>>>> active >>>>> >>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> or >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> anything that >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>> nature. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>>>>> What makes CBR >>>>>>>>>>>> >> output >> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> bitstream so >>>>> >>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> >>>>> >>>>>>> much higher >>>>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> than >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> set value? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>>>>> alan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>> >>>>>>>>> >> >> >>>>> >> _______________________________________________ >> >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>>>>>>> >> Helix-producer-dev >> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>> mailing >>>> >>>> >>>>> list >>>>> >>>>> >>>>>>>>>>>> [email protected] >>>>>>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-producer-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> >> >> >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>>> >>>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>>> >>>>>>>>>> >> >> >>>>> >>>>> >>>>>>> >>>>>>> >> >> >>>> _______________________________________________ >>>> >>>> >>>>>>> >>>>>>> >> >> >>>>>>>>>> Helix-producer-dev mailing >>>>>>>>>> >> list >> >>>>>>>>>> [email protected] >>>>>>>>>> http://lists.helixcommunity.org/mailman/listinfo/helix-producer-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> >> >>>>> >>>>> >>>>>>>>> >>>>>>>>> >> >> >>>>>>> >>>>>>> >> >> >>>>> >>>>> >>>> >>>> >>