Subject: Re: [video-codec] Charter update

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 16 Jan 2013 08:27:00 -0800

First, I want to thank you for taking the time to review this and 
provide detailed feedback.

> be approved when what I think we need is a set of guidelines to work within
> that plow the work to be completed in a timely fashion. Note I am not

So, large portions of this charter are obviously cribbed from the CODEC 
charter, and I will certainly grant you that there are differences in 
what we needed to do in that WG compared to what we need to do for this 
one. Do you have some good examples of charters that provide "guidelines 
to work within that plow the work to be completed in a timely fashion" 
that I can learn from?

> against this work, but I do want to have a charter that maximizes the odds
> of success and I think we can easily come up with a much better charter
> form the point of view of helping get the work done.

I think we all want a charter that maximizes the odds of success, and I 
am definitely for much better things that are easy.

> Part of the problem is people, like myself, keep saying things and the
> charter never changes from the mozilla guy proposed long ago. If you look

To be fair, I posted some responses to the points you raised at the BoF 
the very next day, which were meant to be the start, not the end of a 
discussion about them... and heard nothing more from you for the next 
two months. I also didn't hear a lot of protest against what I said 
there from anyone else. There were frankly more comments on the 
requirements draft than the charter. But I'm glad you're engaged now.

> All of that said, I would be happy to book some time to have a conference
> call with a working document everyone could edit and try and write a
> charter that worked. I suspect that people largely agree on what they
> want, I just don't think this charter is going to help us get there quickly.

I've sent another mail about this to make it easier to find the details.

> worried the world would end at the end of the mayan calendar. Overall, get
> rid of political positioning and get down to what the is WG is going to do,
> why, and how.

I would argue that speaks to the "why" question, but I didn't come up 
with most of this text, and I'm not attached to it if people think there 
is something better we could be saying. Let's work it out on the call.

> delete all this and instead rewrite the next paragraph to say what
 > characteristics this codec is going to have

In CODEC, this language in particular was used to keep the WG focused on 
what we were trying to achieve. When I first went back to review that 
charter, I didn't remember much of what was in it, but I did remember 
this part. If you want to say these things in a different way, okay. But 
I think they need to be said.

> Given the most likely path forward for this WG is endorse VP.next, I'd shy

Well, given what I know of the current state of VP.next, I think there's 
still quite a bit of work to be done. I think it's an okay base to build 
off of, but we won't be able to just rubber-stamp it, even if we wanted 
to (and personally I don't, particularly).

> away from discussion of how codecs are developed and instead focus on how
> what you want to happen and how they were standardized. I think it is

I'm not sure I follow what you mean in this sentence.

> pretty clear that the SILK portion of opus was not "developed" under IETF
> IPR rules yet that was not a problem and I suspect this charter needs to be
> set up such that a similar situation would not be a problem.

Many of the core design principles of SILK didn't change after the WG 
was formed, but it was contributed with proper IPR disclosures and there 
_was_ a lot of development on it in the WG (I know, because Jean-Marc 
and I were the ones doing a bunch of that development). I take your 
point, however, that it matters less where the code was written than 
that the ideas were presented and reviewed in sufficient detail as to 
trigger disclosure requirements. The problem this paragraph calls out is 
a real one, though.

> I think most of the above is just confusing clutter in getting to a good
> charter and should be deleted.

I'm not deeply attached to this either.

>> 1. Designing for use in interactive applications (examples include, but
>> are not limited to, point-to-point video calls, multi-party video
>> conferencing, telepresence, teleoperation, and in-game video chat).
>
> As I brought up in the BOF - I think we need to get specific in the
> charter about what things we will actually do, that are not done in
> pretty much all codecs, that are "good for interactive"

There were at least three concrete ideas listed in the first paragraph 
you suggested we rewrite. We can move them here. Are there others you 
want to include? There are also a number of things that are _bad_ for 
interactive that we will have to make sure the codec does not do (see 
some of my examples in another thread). Should we list those also?

>> 2. Addressing the real transport conditions of the Internet, such
>> as the flexibility to rapidly respond to changing bandwidth
>> availability and loss rates, or as otherwise identified and
>> prioritized by the working group.
>
> Again the above point is useless for a charter. It does not provide
> any real information or constraints. Say what we actually mean here.

Definitely agree this could be improved.

>> 3. Ensuring interoperability and clean integration with the
>> Real-time Transport Protocol (RTP), including secure transport via
>> SRTP.
>
> seem uh, a bit obvious to need to be in the charter

Is non-obviousness the bar for what goes in the charter? This question 
is not rhetorical.

>> 4. Ensuring interoperability with Internet signaling technologies
 >> such as Session Initiation Protocol (SIP), Session Description
 >> Protocol (SDP), and Extensible Messaging and Presence Protocol
 >> (XMPP). However, the result should not depend on the details of
 >> any particular signaling technology.
>
> again, sort of irrelevant and missing RTSP

Well, RTSP is easy add, but see previous question.

>> 5. Ensuring suitability for use in Internet applications and Web
>> APIs, such as the HTML5 <video> tag, live streaming (e.g., via
>> icecast), adaptive streaming (e.g., Dynamic Adaptive Streaming
>> over HTTP (DASH), HTTP Live Streaming (HLS), etc.), the
>> MediaSource API, the WebRTC APIs, proposed web recording APIs,
>> and so on. However, the result should not depend on the details
>> of any particular API.
>
> What does the above mean - what constraints does this result in.
> I doubt we need to say much about any of this

This is mostly here as insurance to deter people arguing for a feature 
that would break one of these things. Many of these things are extremely 
complex, and I'm not sure I could enumerate in a small space (such as my 
brain) all the constraints they impose... which is why I just listed the 
things I didn't want to break instead.

>> 6. Ensuring the work is done under the IPR rules of the IETF.
>
> given it's an IETF charter, this seem uh, oh I give up

This exact phrasing is what we agreed to at the bar BoF in Vancouver, 
and I was basically told to put it in by our ADs. Even if I hadn't been, 
I happen to like the IPR rules of the IETF... it's one of the reasons I 
want to do this work here, and I think that's worth calling out 
explicitly to those who may not have worked in the IETF before.

>> - Within the AVT WG, define the codec's payload format for use
>> with the Real-time Transport Protocol (RTP).
>
> uh, small nit, wrong WG - how much review has this charter had :-)

So much I wouldn't even notice a mistake like that. :)

> Lets list out the specific aspects now - the real issues comes to
> a video codec that smoothly adapt to wide range of bitrates -
> just define what is needed and write it down in the charter

It's not just rate adaptation, but things like redundancy/FEC/loss 
resiliency. I don't actually know what all the answers are here... 
that's what the collaboration is for.

>> - Collaborate with working groups in the RAI Area to ensure that
>> information about and negotiation of the codec can be easily
>> represented at the signaling layer.
>
> what will this above even mean in practice

Presumably it means that we do whatever work is needed to make sure that 
all of the things that negotiate codecs can successfully negotiate this 
codec. I don't remember doing very much here for Opus. I don't have a 
problem with dropping it.

>> - Collaborate with working groups in the RAI Area such as CLUE and
>> RTCWEB to ensure the codec can satisfy all of their video-related
>> use cases.
>
> These WG do not even have requirements for codecs as far as I can
> tell so sort of hard to see how above will work

Well, if RTCWEB or CLUE tells us that the codec we're designing fails to 
work in some use case they have (and they certainly have those), then 
that's a problem. Maybe it's worrying about nothing. You tell me.

> The above paragraph loosely translated to "we will ignore other SDOs",
> if we want to actually reach out and try and have collaboration with
> other SDOs, we likely need to do that before chartering so we can
> create a joint charter.

Well, the above paragraph was written by Rob Glidden, an active 
participant in the MPEG IVC ad-hoc group, who did reach out to us. So 
I'm not sure that's really what it says.

>> The Guidelines for Development of an Audio Codec within the IETF
>> (RFC 6569) will form the starting point for guidelines and
>
> I think the above is a terrible idea as I suggest at the BOF. Some
> of the issues are around waiting to receive a bunch of proposal
> before moving forward, requiring a reference implication to be
> standardized, and so on.

I actually don't remember either of those two issues being brought up at 
the BoF... perhaps I just have a bad memory, but I definitely talked 
about doing the first one in my presentation and no one objected to it 
then. But I said we should base things on RFC 6569 mostly because I 
didn't want to spend a lot of time re-hashing arguments we already had 
in CODEC. The process in RFC 6569 can proceed as soon as "a sufficient 
number of proposals has been received"... maybe we decide that number is 1.

As for standardizing a reference implementation... I don't think anyone 
on this list came out in support for the code being the normative 
standard, but I _do_ think it should be published as an RFC, if for no 
other reasons than to get wider review on it and hang IPR declarations 
off of it.

> Could the next two paragraphs be reduced to one sentence ?

We can probably cut out a lot. I think we'd need at least two, though, 
as the last sentence was added in response to a specific request by 
Spencer, and doesn't quite stand on its own.

> In the codec WG, not sure the guidelines helped much  - but they used
> up a lot of time

I think they helped a lot at the end, when Opus went before the IESG... 
some of whom were unhappy about things like "the code is the spec", but 
admitted they had agreed to it up-front.

> say above will be PS

Isn't that what it says, or do you just mean use fewer words?

> I think the above should not be part of IETF process. Of course I
> think there should and will be some open source implementation on
> github or something but IETF process does not work to review or
> update such a thing

I can still download tarballs of linux-1.0 from March 1994. Just because 
something is open-source doesn't mean its releases are any less 
permanent than an RFC. And just knowing that code will be reviewed at 
the IETF level changes the way it is written. The common sentiment I've 
heard elsewhere is that the IETF should publish more reference code [1].

[1] 
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=64944&tid=1358315223

> It seems to me that many people think we should use an existing
> storage format not invent a new one. If we are doing a new video
> storage format, I suggest that be a WG of it's own.

Even describing how to map a new codec into an existing container is 
still work. Getting Opus into Matroska has so far required the creation 
of at least two entirely new elements and still isn't done. Putting it 
in Ogg was more straightforward, but still needed a draft describing it. 
This deliverable was meant to motivate the production of such a draft, 
not the creation of a brand-new container (we at Xiph have discussed 
making a successor to RFC 3533, but I think it is totally fair to insist 
that happen in its own WG).