Re: [rtcweb] Finishing up the Video Codec document

[Peter Saint-Andre - &yet <[e-mail]>]

On 12/4/14, 8:00 AM, Ron wrote:
>
> 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.

OK, I'll get to work. :-)

Peter

-- 
Peter Saint-Andre
https://andyet.com/