- From: Francois Daoust <fd@w3.org>
- Date: Fri, 15 May 2020 08:09:28 +0000
- To: public-media-wg@w3.org
Hi all,
The minutes of this week's Media Working Group call are available at:
https://www.w3.org/2020/05/12-mediawg-minutes.html
... and copied as raw text at the end of this message. Let me know if
minutes need to be completed or adjusted!
Resolutions taken during the call:
TPAC F2F 2020
-----
https://github.com/w3c/media-wg/issues/13
RESOLUTION: We will meet at TPAC 2020 and include WebCodecs as a joint
session with the WICG.
Note that W3C announced yesterday that there will be no in-person TPAC
2020, so meeting will be virtual. This gives the group leeway on dates
and logistics (day-long meetings are obviously not going to work well
given the spread of timezones in the group).
Picture in picture - Rename CSS pseudo-class :picture-in-picture
-----
https://github.com/w3c/picture-in-picture/issues/172
RESOLUTION: Francois Beaufort to craft a PR to add
picture-in-picture-inline pseudo-class.
Media Capabilities - Discuss how to reconcile colorGamut &
transferFunction with ISO 23001-8:2016
-----
https://github.com/w3c/media-capabilities/issues/152
RESOLUTION reject the promise when there are conflicting inputs, details
can be discussed back in the issue
Thanks,
Francois
--
Media WG call
12 May 2020
[2]Agenda. [3]IRC log.
[2]
https://github.com/w3c/media-wg/blob/master/meetings/2020-05-12-Media_Working_Group_Teleconference-agenda.md
[3] https://www.w3.org/2020/05/12-mediawg-irc
Attendees
Present
Barbara Hoschgang, Becca Hughes, Chris Needham, Cyril
Concolato, Eric Carlsson, Francois Daoust, Gary
Katsevman, Greg Freedman, Jean-Yves Avenard, Jer Noble,
Joey Parrish, John Luther, Lucas Pardue, Mark Foltz,
Mark Watson, Mounir Lamouri, Peng Liu, Pierre-Anthony
Lemieux, Simon Thompson, Tess O Connor, Vi Nguyen
Regrets
Paul Adenot, Matt Wolenetz
Chair
Jer, Mounir
Scribe
Francois
Contents
1. [4]Rename CSS pseudo-class :picture-in-picture
2. [5]TPAC F2F 2020
3. [6]Autoplay API: update on API shape and editors
4. [7]Discuss how to reconcile colorGamut & transferFunction
with ISO 23001-8:2016
5. [8]TextTrackCue: add optional event synchronisation
6. [9]TextTrackCue: add unbounded duration
7. [10]EME: Persistent Usage Record
8. [11]Summary of resolutions
Meeting minutes
Rename CSS pseudo-class :picture-in-picture
[12]Rename CSS pseudo-class :picture-in-picture
[12] https://github.com/w3c/picture-in-picture/issues/172
mounir: Goal is to rename the :picture-in-picture CSS
pseudo-class. I think you, Jer, were not super fan of it.
jernoble: Not clear whether the goal is to rename the existing
class or to add a new one.
mounir: At the moment, we're not considering adding a new
class.
jernoble: If it would rename a pseudo class that people are
already using, then I'm not super fan.
mounir: The goal would be to rename the name to append -inline.
Then, there is the question of duplication.
… There will be different paths depending on who shipped it
already.
… Having an -inline name is not a bad thing in any case.
… If we add the -inline name, we have a path to remove the old
name.
jernoble: Testing with Chrome, I think it hasn't shipped
… I don't see the value in renaming this once people have
shipped and started using it.
… My opinion is that we should find a new name for things
within the picture in picture element.
mounir: The issue is not that we want to use the name in the
window. It's that people may try to use the pseudo-class
because the name is so vague and expect that this would style
the element in the other window, whereas it's styling the video
in the original page.
… That's why we wanted to add a clarification by adding
"inline".
… I'm fine keeping both names with the vague one flagged as
deprecated, and the inline one being the recommended one.
… I think we can find a compromise by adding the inline one and
deprecating the old one.
jernoble: I said my piece. Any other views?
… Maybe new proposed text would make things clear.
mounir: How to move forward? Could we suggest to Francois
Beaufort to craft a PR and have you or someone else from Safari
review it?
jernoble: Yes.
Resolution: Francois Beaufort to craft a PR to add
picture-in-picture-inline pseudo-class.
TPAC F2F 2020
[13]TPAC F2F 2020
[13] https://github.com/w3c/media-wg/issues/13
mounir: We got an email from W3C management to check whether we
want to have a F2F at TPAC as a group. I would assume that as a
group we want to meet. We don't know whether TPAC will be
physical or virtual. Last I heard, it's still physical, but I
would be surprised if it remained the case.
… One open question is whether to include a session on
WebCodecs.
… We had fruitful discussions on WebCodecs last year at TPAC,
and lots of progress since then, so seems useful to add it to
the agenda, especially since it's flagged on our charter.
jernoble: Is it being incubated in another group?
mounir: I would say it's in WICG for now... Yes, confirmed.
jernoble: So we could do a joint session between the CG and
ourselves.
mounir: Right.
jernoble: Make sense to me.
Resolution: We will meet at TPAC 2020 and include WebCodecs as
a joint session with the WICG.
Autoplay API: update on API shape and editors
mounir: We reached out to the TAG to get advise. They
[14]recommended a synchronous API
… Further discussion will be needed, but hopefully that
shouldn't require going back to the TAG at this stage.
… Paul reached out to me before the meeting to mention that
someone from Mozilla would volunteer as editor. Anyone else?
[14]
https://github.com/w3ctag/design-reviews/issues/439#issuecomment-561902607
jernoble: If no one else, we may be able to find someone within
Apple to do it.
mounir: This is a good first spec for an editing role. It's
mostly about writing the outcomes of discussions down.
jya: Nothing to add for now, I'm catching up as I've been out
of the loop for a while.
Discuss how to reconcile colorGamut & transferFunction with ISO
23001-8:2016
[15]Discuss how to reconcile colorGamut & transferFunction with
ISO 23001-8:2016
[15] https://github.com/w3c/media-capabilities/issues/152
vi: Happy to talk about it now if folks are willing to
GregFreedman: I don't have much to say. The cases you're
pointing out don't look like cases we'd be querying ourselves.
vi: What about [example using Dolby parameters with
discrepancies between colorGamut and transferFunction input and
the color information implicit in the mime type]?
GregFreedman: I don't know if the question is really for
content providers. I think it falls on the user agent to
provide an answer that is consistent.
jernoble: As a user agent, let me chime in. This is not
specific to HDR properties. Example of resolution: low-profile
H.264 presented as 4K. Conflict within properties and mime
type.
… One possibility is to reply "Not supported" because
properties are not all satisfiable.
… Another possibility would be to decide which of these
properties have precedence over the others.
… Should we prioritize the content type for instance?
cpn: It would seem to me that detecting that this case happens
and reporting it to the developer would be good.
jernoble: We don't have lots of venue to do so.
… A console message could perhaps work.
… I don't think that's something that should be specified in
the spec.
jernoble: Any strong feeling between these 2 options?
cpn: I would prefer to see rejecting in case of
inconsistencies.
jya: It would be nice to have consistency between user agents.
jernoble: That consistency implies some text in the spec along
the lines of "in case of inconsistency, reply no"
jya: That seems like a good approach to me.
jernoble: OK, then that needs text. Let's get back to the issue
and move things forward there.
Resolution: reject the promise when there are conflicting
inputs, details can be discussed back in the issue
TextTrackCue: add optional event synchronisation
[16]Add optional event synchronisation
[16] https://github.com/whatwg/html/issues/5306
cpn: For context, this is work we've been doing in the Media &
Entertainment IG on Media Timed Events.
… Ongoing incubation on DataCue in the WICG.
… And two proposals against the HTML spec.
… First is on recommending timing accuracy for TextTrackCue
enter and exit events.
… Historically, Chromium has not been super accurate with these
event firing, which were tightly coupled with timeupdate
events, roughly fired every 250ms.
… There's a desire to have much more accurate timing sync
capabilities.
… With recent changes to Chromium, all main user agents are on
par with good timing accuracy.
… We'd like to add some language to the HTML spec to specify
that timing accuracy.
… I'd like feedback on whether this proposal and wording look
good.
GregFreedman: If events have been missed, with the proposed
wording, I cannot tell whether a subtitle that has been skipped
should be showed slightly after, or altogether eliminated?
cpn: That's a slightly different issue.
… If you're using cue change events, it's possible that, in
this situation, the cue would be missed, as the cue would no
longer be in the list of active cues.
… If, instead, you're listening to enter and exit events,
you're guaranteed to get them.
jernoble: If all implementations are already conformant, why
would we need to add non-normative guidance?
cpn: For developers that use these APIs, it does cause some
confusion. Having some clarification would benefit them. It
would also help setting up the expectations for any future
implementations.
jernoble: Do you think that web developers use spec language
for this? Or do they e.g. use MDN?
… That is, another option would be to reach out to MDN and add
language around expectations.
cpn: I'd like us to do both.
… This stems from the fact that one of the implementations
didn't meet these expectations for a long time. Documenting the
expectations seems a good thing.
jernoble: I don't think it can be anything else than a SHOULD.
cpn: Right, I was not looking for something normative,
actually. Philip suggested that in response to the issue.
mounir: What would be the issue specifying what everyone is
doing now?
jernoble: I don't think you can crystallize things to a precise
value, e.g. 20ms.
mounir: Goal is to have every browser use enter/exit as a way
to drive show/hide. If the spec was saying that, wouldn't that
solve the issue without having to specify a time value?
jernoble: Maybe I misunderstand the issue. Can these events be
skipped in Chrome?
mounir: I think we're driving everything through timeupdate.
But the goal here is to make Chrome non-compliant.
jernoble: This is a quality issue, rather than something that
the spec can mandate.
… A note would, I think, strike the right balance.
… Responding to cue change events within 20ms, without
requiring implementations to do that.
cpn: Would you guys be happy if I craft a PR along these lines?
jernoble: Sure!
TextTrackCue: add unbounded duration
[17]TextTrackCue: add unbounded duration
[17] https://github.com/whatwg/html/issues/5297
cpn: If you're using cues for metadata rather than for
captioning, you may want to describe when an event starts, but
you may not know in advance when the cue ends, e.g. the start
of a news program in a live stream.
… Goal is to make it possible to create a cue with a start time
that would run until the end of the media stream.
… Idea is to use infinity value to mean "no end".
… There are some use cases related to broadcasting. There are
other use cases in other industries.
… Proposal is to make endTime an unrestricted value.
ericc: That sounds fine, as long as we say that it's only legal
in files that have infinite duration. It wouldn't make sense in
a file that has a finite duration.
cpn: I would need to think about that.
jernoble: There are a number of file formats where cues don't
have a duration until another cue comes up.
… I wonder whether there's an opportunity to have not only an
infinite duration, but actually not to have a duration at all.
ericc: What we do is when we get one of these in-band captions
for which we only know the start time, we give it an end time
that is the duration of the file.
… And then we update the end time when we get the next cue.
jernoble: And maybe that's fine and we can continue doing that.
EME: Persistent Usage Record
mounir: The feature is in the charter. Chrome is working on
this.
… Any feedback on this?
xiaohan: I am trying to enable Persistent Usage Record (PUR) in
Chromium and would like to know whether other browsers would
support it.
jernoble: Safari has implemented the PUR session type, and
think it's already in use. I'm pretty sure that we're happy
with the current API.
xiaohan: I'm wondering about implementation details, given
concerns raised by the TAG
jernoble: I can only talk about FairPlay. We store the proof
messages on disk in the open. The proofs are cryptographically
signed and encrypted, same as key messages. We make no effort
to prevent tampering; according to clients who use PUR
sessions, the only effect that corrupting or deleting these
messages is that media providers might stop serving new keys to
those users.
mounir: Any feedback from Mozilla on the API itself?
jya: I need to consult.
mounir: Tess, any feedback from the TAG?
tess: None off hand, no.
xiaohan: The plan is to send a TAG review to get feedback to
drive the process forward. It has been in the ED for a pretty
long time.
… If you have comments, let me know!
mounir: End of meeting, thanks everyone!
Received on Friday, 15 May 2020 08:09:35 UTC