Re: [rtcweb] Tim Panton's choices

["DRAGE, Keith (Keith)" <[e-mail]>]

No.

Video was one component within a frame structure defined by H.221 that also included the audio and data.

That frame structure could leave a video component with 46.4 kbit within a single B-channel. As far as I can remember the video occupies all the space not otherwise allocated to audio, etc, therefore there could be all sorts of bandwidth figures depending on the number of B-channels allocated, and the space taken by other media.

Not sure how much active changing of  bandwidth there might have been once the call was set up.

Keith

> -----Original Message-----
> From: rtcweb [mailto:[e-mail]] On Behalf Of Tim Panton
> Sent: 30 December 2013 16:00
> To: Stephan Wenger
> Cc: [e-mail]
> Subject: Re: [rtcweb] Tim Panton's choices
> 
> 
> On 30 Dec 2013, at 15:47, Stephan Wenger <[e-mail]> wrote:
> 
> > Tim,
> > 
> > I believe your questions below have been answered before, 
> but allow me 
> > to add more redundancy.
> > 
> 
> How apposite :-) - Must be some lossy connection between me 
> and the discussion, or perhaps I temporarily didn't have the 
> bandwidth to keep up !
> 
> > Stephan
> > 
> > On 12/30/13, 6:05 AM, "Tim Panton" <[e-mail]> wrote:
> > 
> >> 
> >> On 28 Dec 2013, at 17:19, Maik Merten 
> <[e-mail]> wrote:
> >> 
> >>> Am 28.12.2013 17:08, schrieb Tim Panton:
> >>>> 6.
> >>>>   All entities MUST support H.261
> >>>>    1.
> >>>>       Are you in favor of this option [Yes/No/Acceptable]:No
> >>>>    2.
> >>>>       Do you have any objections to this option, if so please
> >>>>       summarize them:
> >>>>       The codec will be unacceptable for a large number 
> of (mobile)
> >>>>       use cases requiring dynamic bandwidth adjustment.
> >>>> 
> >>> 
> >>> Can you elaborate on that argument, which you also apply to H.263 
> >>> and Theora?
> >>> 
> >>> H.261/H.263/Theora have no fixed increments regarding bitrate and 
> >>> any encoder can scale bandwidth basically at will. IMO bandwidth 
> >>> management is completely within the encoder realm, and 
> >>> implementations can choose to accept new bitrate targets 
> at runtime.
> >> 
> >> Has any of that been done?
> > 
> > It¹s bread and butter for encoder developers since at least 1990.
> > 
> >> Is it exempt from patent attacks?
> > 
> > I don¹t know what ³exempt from patent attacks² means, but I 
> will note 
> > that rate control mechanisms are among the most heavily patented 
> > encoder mechanisms.  For two reasons: every real-world 
> encoder needs 
> > some form of rate control (to adapt to application 
> requirements that 
> > include network condition dictated bandwidth as well as 
> user dictated 
> > bandwidth), and features of rate control determine to a significant 
> > extent the performance of an overall system over variable speed 
> > networks such as the Internet--and are, therefore, a 
> critical product differentiator.
> > Note that the vast majority of rate control patents are written 
> > independently of the codec technology in use.  The possible 
> exception 
> > are rate control mechanisms that cover somewhat exotic 
> codec technologies:
> > scalability, SI/SP pictures, and the like.  For the purpose of the 
> > discussion at hand, you can lump together into the same 
> risk category 
> > any of the codecs under discussion with the exception of 
> MJPEG.  Note 
> > also that many modern rate control algorithms work on older codecs, 
> > and vice versa.  Design-around is sometimes an option once a patent 
> > has been asserted--normally at the cost of some performance.
> > 
> 
> So If I understand that correctly:
> 1) rate control on the older codecs is possible.
> 2) rate control is typically separated from the codec itself
> 3) rate control is heavily patented
> 4) a modern H261 implementation would (mostly) use the same 
> rate control techniques as H264 or VP8 
> 
> which leaves me wondering if selecting H261 wouldn't mean we 
> retain many of the same IPR risks of newer codecs but without 
> a licensing authority to go to for fixes/workarounds (or a 
> technical or legal nature). And still have a significantly 
> worse visual experience at a given bandwidth than for a modern codec.
> 
> Seems like the worst of all worlds to me - hopefully I misunderstood.
> 
> >> Is there real world experience of how encoders/decoders respond to 
> >> halving the available bandwidth (eg when someone walks between you 
> >> and the distant wifi ap) during a call?
> > 
> > Halving the bandwidth is trivial for H.26x and VPx.  The 
> dynamic range 
> > of bandwidth for any of the codecs under discussion (minus MJPEG 
> > perhaps) is several orders of magnitude.  Yes, there is such 
> > real-world experience and has been since at least 1990 (ISDN MCU 
> > implementations, also academic work).
> 
> Surely with ISDN the steps were quantized at 64kbps? 
> 
> Tim.
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>