[bumped]

Ken: Sangwhan gave comments and they responded and he wants to look further. Need Sangwhan for this one.

Yves: we did add something about adding to the web platform in the guidelines.. we can look if the guide is okay with what they proposed? ... Is it okay to add examples on how things can go wrong in design principles if they are not respected?

Dan: I think so... raise it as an issue and we can discuss it in design week.

Yves: in the case of the HTTP header syntax, explaining that it's imporatn to respoect it, and counter example is the cookie header which has been a nightmare.

Dan: if you have a fully formed idea of what you want to put in, make a PR.

Yves: the style is usually very terse

Dan: depends which part of the document you're in.. We need to keep balance. Having examples is always good.

Yves: first was too terse, I'll work on that.

.. for web codecs we should wait for Sangwhan

Ken: discussion around timestamps. Not really timestamps.. offset inside the stream. Also depends on playback speed. Normally playback correlatest o timestamp but you might be able to change playback..

Sangwhan: a timer that starts at beginning of stream?

Ken: they want to use unsigned microseconds but depends on playback speed. A lot of issues. Makes sense to me to use unsigned microseconds. Can add timestamp if there's really a need.

Sangwhan: also asking about window environments, detach codec inputs..

Ken: only on worklets or workers initially.. a lot of people who want it on window as well.

Sangwhan: on window not harmful unless there's an implementation detail..

Ken: wanted it not to be a blocking api..

Sangwhan: don't necessarily always want a worker, more involved

Ken: if no-one sets up a worker you end up with crappy web experiences

Sangwhan: going to block the main thread.. very heavy stuff.. people won't do that

Ken: if it's heavy it should always be in a worker

Sangwhan: image decoder part..

Ken: can we expoes that to the main thread?

Sangwhan: use cases like short video transfer you can block for a little bit while you're encoding it.. makes sense on window.

Ken: makes sense to start on workers, then if you have those use cases add it to window. You can always add it to window. If you add it now you cannot remove it again. Gradually build API. Makes a lot of sense. [leaves comment]

Sangwhan: by having it worker only, using it in webrtc is going to be a pain.

Ken: those people work on webrtc

Sangwhan: on worker only, someone will polyfill for window. When there's enough usage on window, say it's time to expose it to window.

Sangwhan: PR for image encoder/decoder API.. we haven't had that.. it's a common thing people want to do.

Ken: PR is pretty big. Metadata as well?

Sangwhan: seems like no api for that... [reads stuff] ... [discussion] ... [drafts comment]

Sangwhan: there's a debate. Window or worker?

Ken: shouldn't it be both places?

Sangwhan: yes We agreed window or worker global scope. ... but Tess disagrees. 2 implementers disagree it should be excposed to window. one strongly disagrees.

Ken: we benchmarked (in intel) - a lot of overhead.

Sangwhan: a lot of cases where it makes sense running on the window...

Sangwhan: some argued what about single-cores... I think this should be on window or worker global scope.

Dan: if we can't get consensus we need to move on. I suggest we say these are the opinions, take it to plenary that we want to close it, we can leave a message saying we haven't had consensus

**status: we have a tentative consensus view

• to validate at plenary.**

closed