Meeting minutes
cn: we have a couple of web codec issues we could cover
Managed Media Source
<cpn> w3c/
cn: we have a pull request open to add it
cn: question is, is it ready to merge? What's outstanding? Looking at the PR, there have been a lot review and comments. Matt has left a bunch of comments, so we could use this meeting time to look at some of those. We are getting positive signals of support. It might be good land the PR and then do followup.
jya: I went through the comments. A lot of it were playing on semantics, but doesn't have substantive impact. However, it's really up to the player when more data, etc. however, it doesn't make a difference on the implementation level (as implementation will vary). Similarly, the requirements for memory are deliberately vague.
cn: on that one, Matt is more pointing to the inconsistency about the phrasing which could be addressed or clarified. The note and normative text don't exactly align.
jya: like, how do we know when the system is going to run out of memory and what the exact behavior is going to be. We could say that something is preferred, but we really don't have control of the underlying system because it's not alway possible to know how the underlying system is going to behave. There is also the issue that the original spec, however we've found that the underlying spec is not erroneous. For examples, the eventing model i[CUT]
jya: so I went for the latter, I tried to fix how the eventing is done for MMS, but the rest of the spec needs to be updated. However, the MSE spec is currently, the updates are incorrect. So like, bufferedchanged should really be bufferchange... you do the action, then you queue at task to update attributes, etc. so the whole spec is kinda incorrect
cn: are you suggesting there is a follow up to address the eventing issues?
jya: yes, Marcos has filed bugs about this also. We also have issues in the WPTests that are inherently racy, that also show some of these problems. We have failures in both Safari and Firefox because they are following the Chrome implementation rather than the spec. We need to address some of those.
jya: there are is quite a bit of followup. Marcos is working on fixing up the spec as much as possible so we can start addressing some of these larger issues with the architecture of the spec itself.
jya: we need to address issues with Timerages too and how the are inconsistently handled
cn: are there places in HTML that use Timerages.
jya: there are also some issues in HTML that we also need to fix. We need to do some cleanup in HTML also. However, I might defer to another spec editor to deal with that.
cn: I'm coming back to Matt's comments. Some of them are about the semantics and precision of the language in the spec. However, it would be good to remove some of the ambiguity that Matt is describing.
jya: I can do another pass and try to address Matt's comments.
jya: I'm not sure what the exactly sure what the process is
cn: should we merge the PR and address the issues?
jya: I will go through Matt's comments, however, I don't think Matt's comments would change how things are implemented
<cpn> https://
cn: there is one comment that may have an impact ☝️
cn: it's not obvious how an app may distinguish between the time ranges removed by the UA and those changed by script
jya: if you call remove or append, that will generate a change event. The issue that is unaddressed is clarifying a bit more about how the buffer changes and what causes the event to fire. I will clarify that a bit more.
cn: it would be good to get Matt to review this if he has time once this is addressed.
cn: has anyone else got views
marcos: we have a preference in other groups not to merge things until we have a test suite in place
… a lot of the issues jya is pointing out is there seems to be mismatch between test and spec
… so requiring tests before merging helps catch things
… having a second implementer commitment before merging, otherwise we have a single vendor implementation, which isn't great
… in other WGs we have a template that points to browser bugs for implementations
… we should try to minimise bugs as people might start relying on the implementation
… this may not apply in this particular PR, but something in general for the WG
… also the quality of the spec text in HTML needs to be fixed
cn: so merge if we have tests plus implementation commitments
marcos: we have tests we can put in
cn: i haven't looked at the test coverage for this yet
marcos: so in parallel with reviewing matt's comments we'll do the tests as well
cn: anything else on this topic?
EME
cn: thank you Greg on the work you've done thus far. The work to be done on there was to add a registry for the different HTCP versions.
gf: I've ping intel. I think it's hard to get version 1.4, or 2.3... they generally require people to move to a new spec every 18 months so there might not be publicly accessible documents.
cn: they internet archive does have some of the old ones.
cn: they are generally not available anymore. So I can pull out the metadata, and we could have references without URLs.
gf: we should do the best that we can. But we can get the metadata and we can list the transport types in the registry.
cn: is there a core specification?
gf: I'll work on this and get all the references for the transport types
gf: I'll work with you on those.
mw: I don't think it's essential that we spend too much time on this. It's really a question about what that string means to between the content provider and the DRM provider. People can lie about it anyway, so it could fail when DRM decoding actually happens. We are not making any promises about how it would work.
fd: is the meaning is not that important, do we need an actual registry?
mw: we are just kinda describing the intention. However, in terms of having actual normative references, we might not needed because the documents are not available anyway
<sushraja_MSFT_> What is the mechanism for notifying the page when getStatusForPolicy changes? This would be a scenario like the user moving his browser window across monitors.
xw: if we get whatever references we can, but we shouldn't waste too much time on this because they are not publicly available anyway. However, I think the version really does matter. The version can be used by the OS to talk to the hardware.
cn: I'll leave it with you Greg to update the PR. I'm wondering if, given what people are Marcos and jya have been doing on the shape of the spec, I wonder if we can make to EME to make it easier to work it.
xw: if you can file bugs on how to modernize it, that would be great
Web Codecs
cn: packet loss
ba: this is a feature we use on native. anyone from chrome have a view on what to do for concealment?
… something to track whether implemented by anybody, current it isn't
… it's also odd as FEC doesnt' work across all codecs, not guaranteed the same everywhere
ba: this looks like a test gap, i think we're concluding that Safari's implementation isn't correct and needs a test case
… so instead of reporting supported = false, it throws
… i can put together a test, but there may be a more general problem
jya: possibly youenn fixed that
ba: there could be a more general misunderstanding. next step to discuss in thread if the spec text is all we need - there are specific conditions where it should throw. Are those the only conditions, or are there others?
… so question is what the test should cover, or if the spec text is too narrow and needs clarifying
… In this case, scalabilityMode is a DOMString, if it were enum it would be valid to throw. so not as cut and dry as the spec indicates
cn: so lets follow up in the issue thread and the test case
Media Capabilities
ba: this is a question - if MCAPI shows something is supported, is there a possibity if you set it, you won't get it
… the SVC modes are almost always software implemented, which will always be there
… possible you won't be power efficient, but the mode will always be there
… don't have hardware support for the spatial modes today
… right now if a mode is advertised in MCAPI you get it
jya: not sure it's true in all hardware though, in FF on some hardware it would pause video until a decoder was available
… so there was not even a software decoder, only hardware
ba: for h265 there'll only be hardware in Chrome
jya: but with HW decoder, there's no limit on Windows, you can open as many HW h265 decoders as you want
ba: may not be true for the encoder though
… so the point is you're not guaranteed to get what you ask for in MCAPI, it's possible it won't be there
… resources could be taken away even if you did get them
… but from the bug I'm not seeing a problem in the spec
… anyone have thoughts?
jn: do they want MCAPI to reserve what they request?
ba: not really, it's just the API is optimistic. not suggesting changing the API
jn: without a reservation API it could fail for other reasons
ba: my recommendation is to resolve it by referring to the bug on error messages, without a spec change
cn: we should organise a session to triage MCAPI issues, we haven't looked at it in a while
[adjourned]