Re: [rtcweb] H.261 vs No MTI

Does a draft need to be created to propose H.261 as MTI?
MPEG-1 Part 2 might also be an option.

On 8 November 2013 17:56, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Hi Tim,
>
> On 08/11/2013 6:31 AM, Tim Panton wrote:
>
>
>    - If H.261 is MTI, you can still upgrade to VP8
>    - If H.261 is MTI, you can still upgrade to H.264
>    - If H.261 is MTI, you can still use transcoding to connect VP8 to
>    H.264
>
> Using H.261 as MTI is a big win over no MTI because "no MTI" means we're
> forced to do transcoding, whereas H.261 as MTI means we can still do
> transcoding if we want, but we don't have to.
>
> And yes, I agree that a more ideal solution is to choose VP8 or H.264 as
> MTI (or both) than H.261... but if worse comes to worse, I don't see a
> benefit to choosing "no MTI" over H.261.
>
> Does anyone have a counter-point?
>
>
>  Ok, I'll bite. (Despite having proposed H261 at the mic in Paris, I've
> changed my mind in the meanwhile.)
>
>  The H261 option makes _everyone_ equally unhappy.
>  Say we can't agree on whether to use VP8 or H.264 as MTI. We can then
> simply settle on a codec with expired IPR such as H.261. H.261 is the codec
> everyone loves to hate but allow me to point out the following:
>
>
> That's the goal :) Really. Making everyone equally unhappy gives them
> incentive to compromise to get a better experience.
>
>  The browser makers have to support and test 2 codecs - one of which they
> don't want anyone to use.
>
>
> It's either that or push the pain onto the application developers (no MTI
> = transcoding). Given that choice, I'd rather inconvenience a handful of
> browser developers over hundreds of thousands of application developers.
>
>  The javascript folks have to do massive amounts of digging in the SDP to
> try and work out if the remote offer of h264 is
> transcoded in a middlebox or is direct vp8 or perhaps that h261 is the
> best option - or perhaps no video is applicable.
>
>
> This problem is not specific to the choice of codec. SDP is a terrible
> choice as an API surface. The WG can improve the situation by providing an
> API call that retrieves this information on behalf of the user.
>
>  The middlebox guys get to implement 3 different codecs, and test
> transcode paths between all of them. The video mixer guys
> can't do video size switching well because h261 hasn't got that concept.
>
>
> Transcoding is already very complex. Simplifying it is not one of my
> goals. And again, we're only talking about the minority case where you're
> forced to fallback on H.261 (think of it as having to fall back on TURN).
>
>  The user gets a totally variable experience based on factors she cant
> control. There will be lots of dissatisfied users who's
> first video call happened to be h261 and never go back to the service -
> better to fail back to audio than connect with a poor experience.
>
>
> The argument is H.261 is better than transcoding, as opposed to H.261 is
> better than VP8 or H.264. I'm *not* arguing the latter. If this turns out
> that H.261 is so terrible for their particular use-case (it should be fine
> for most), the application developer can still choose to do transcoding.
> Mandating H.261 as MTI just gives them an extra option they normally
> wouldn't have.
>
>  Part of the problem is that O/A + SDP isn't a rich enough medium for the
> application to make a sensible/correct decision.
> Given that we are stuck with OA+SDP for version 1.0 at least, lets not
> make it worse by complicating the SDP and degrading the
> user experience at the same time.
>
>
> I agree. My view remains that (regardless of the codec choice) WebRTC
> should provide an OO interface on top of SDP and ideally eliminate SDP from
> the API altogether. Even if we choose no MTI, people are going to want to
> dig into the SDP to find out if the connection ended up choosing VP8 or
> H.264. That's painful, whether or not H.261 is MTI.
>
>  Sorry to be so negative.
> I'll try and come up with a more positive solution next :-)
>
>
> No problem. I appreciate the feedback.
>
> Gili
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>