Re: [rtcweb] Finishing up the Video Codec document

[Ron <[e-mail]>]

Hi Peter,

On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet wrote:
> On 11/25/14, 4:33 PM, Adam Roach wrote:
> >I've updated the draft-ietf-rtcweb-video based on the minutes from
> >Hawaii. Now that we have a clear path to success, I'd like to get the
> >document finalized and published as quickly as possible. This means I
> >need your feedback on the remaining open issues (1, 4, and 5, below). If
> >you are CCed on this mail, it's because you took an action item in
> >Hawaii, and I'm waiting to hear back from you.
> >
> >New version: http://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/
> >Diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-video-03.txt
> 
> I have concerns about the future-oriented text:
> 
>       To promote the use of non-royalty bearing video codecs,
>       participants in the RTCWEB working group, and any successor
>       working groups in the IETF, intend to monitor the evolving
>       licensing landscape as it pertains to the two mandatory-to-
>       implement codecs.  If compelling evidence arises that one of the
>       codecs is available for use on a royalty-free basis, the working
>       group plans to revisit the question of which codecs are required
>       for Non-Browsers, with the intention being that the royalty-free
>       codec will remain mandatory to implement, and the other will
>       become optional.
> 
> The if-clause in the last sentence establishes a trigger for revisiting the
> combination of VP8 and H.264 as MTI video codecs. But is that the only
> possible trigger? If so, I think the document is misguided.
> 
> The ideal solution to the video codec problem would be for the IETF
> community to create a truly unencumbered video codec, as it has already done
> for audio with the Opus codec. If the IETF (or some other standards
> development organization) were to develop such a codec, then I think that
> would be a sufficient trigger for revisiting the recommendations in this
> document, no matter what happens with the royalty-free status of VP8 and
> H.264.
> 
> I would strongly prefer that the document contain text recognizing that
> possibility.
> 
> Furthermore, this text about WebRTC Browsers sends the wrong message, I
> think:
> 
>       These provisions apply to WebRTC Non-Browsers only.  There is no
>       plan to revisit the codecs required for WebRTC Browsers.
> 
> Certainly there is no active plan at this time to revisit the MTI codec
> issue (after all, we're still *visiting* the issue for the first time), but
> that's immaterial to the question of when it might be appropriate to do so.
> The current text reads as if there are no conditions under which the MTI
> codec issue would ever be revisited, and that's just wrong.
> 
> (A smaller but not insignificant issue is that the document talks about "the
> RTCWEB working group", "any successor working groups in the IETF", and "the
> working group" interchangeably. Yet can this document establish plans for
> successor working groups, or even future incarnations of the RTCWEB working
> group? Any plans related to future efforts will be set by WG consensus or
> IETF consensus, not for all time by this document.)
> 
> IMHO we need to either pull out the future-oriented text entirely (which has
> its own problems) or significantly improve it. I would be happy to propose
> text for the latter.

I'd definitely be interested in seeing proposals from you to improve
upon these things.  It seemed premature to explore this until we had
some sense of whether this kind of compromise could fly at all, but
now that it seems it can, I think these are important details for us
to clarify as best we can.

  Thanks!
  Ron