Re: rv10 vbr broadcasting bitrate puzzle
Steve McMillen <[email protected]> Tue, 24 Nov 2009 20:00:15 -0800
| Newsgroups | gmane.comp.multimedia.helix.devel |
|---|---|
| Message-ID | <[email protected]> |
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 >>>>> >>>>> >>>>> >>>> >>