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