Re: rv10 vbr broadcasting bitrate puzzle

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
> >>>
> >>>        
> > >
>