<scribe> scribenick: kaz
Chris: note that people are encouraged to join the WICG for the follow-up discussion
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-web-and-tv/2019Jul/0014.html
Chris: mentions the preliminary
agenda topics
... 2. Review open issues and PRs on the use cases and requirements
document [4]
... 3. Review WICG explainer document [5]
... 4. Start to capture a list API issues and decisions to be
resolved
... 5. Next steps
... also OGC work
<cpn> https://github.com/w3c/me-media-timed-events
Chris: We have some of open issues. Don't want to go through them all today.
Chris: Would like to resolve PR 49, clarify terminology.
Chris: Started from an initial
comment around "timed event",
... and it wasn't clear what and "event" is: DOM event or something
else?
... Different usages exist, so not entirely clear in the
document.
... We used the term event, coming from emsg as a carrier for timed
information.
... So I suggested an alternative: "timed metadata", which is used
elsewhere,
... e.g., in the Apple HLS documentation and the DASH-IF doc.
... Nigel pointed out that isn't good fit in the document for one
of the use cases,
... where we have messages that are more like notification
commands,
... so not really metadata.
... I'm OK with using "metadata" but aware it doesn't fit all our
use cases
<cpn> https://pr-preview.s3.amazonaws.com/w3c/me-media-timed-events/pull/49.html
Chris: Are we OK to use timed metadata, or should we change it?
Andreas: I didn't have time to follow
this TF's work and this issue, but it is of interest.
... In general, also reluctant to use "metadata" for this
context.
... In TTML, metadata is something that's additional data or
annotations about something else.
... But here the media timed events have some application driven by
data.
... So from my impression the original wording "media timed event"
is quite good :)
Chris: Thanks. That's a possible option, to go back to the initial term.
Andreas: Nigel, you also have some opinion?
Nigel: The term metadata gets
misused, mostly. It had an original meaning: data about the
structure of data.
... Given it's widely misused, people won't be misled by its use
here as data about the video.
... However, the distinction is between something just giving
information that could be safely ignored, or information that's
required for processing or presentation.
... The control message example here is essential for the media
player to work, these messages can't be ignored.
... In general what this document describes is a mix of informative
extra data and other, required things.
Chris: Interesting, I'm not familiar with the disctinction there between essential and non-essential.
Nigel: We think a DataCue is a
solution here, so we could be misleading by calling it metadata
cues,
... as we already have the "metadata" kind in TextTrack.
Chris: Yes, although the DataCue
proposal extends the TextTrack with kind = metadata.
... identifying the gap
Nigel: So from that point of view, it would be misleading not to call it metadata.
Chris: The DASH-IF document is called
"application events and timed metadata processing model",
... seems good, as it covers both. Maybe could follow this.
Andreas: WebVTT has metadata cues, this isn't subtitles.
Chris: What we're proposing with
DataCue is a new way of handling metadata cues.
... With VTTCue you serialise the data to a string,
... but with DataCue we can convey the information in its more
native form.
Rob: IIUC, if an evemt is missed, it could cause the media playback to break?
Nigel: [explains the DASH manifest refresh use case]
Chris: I don't think there is a
single term to describe both.
... Nigel's proposal is to call it timed data, which is more
general, could cover both aspects.
... I'm reluctant to change the document, to maintain commonality
with usage elsewhere.
... I'd need to go through each usage.
... Possibly we could add something like application events for the
control messages.
Andreas: Don't have a strong view. More important what it does. Terminology is always difficult.
Chris: Indeed. I'd like to move to
the next stage. For conversation with the implementers, we need an
explainer.
... That still needs work, can copy from the IG note, but expains
the API from a user point of view.
Rob: Another question, is this
becoming a design issue?
... I didn't consider metadata as critical to playback, do we need
to flag this in the design?
Chris: Everything would be delivered,
so I don't think the case were items are optional,
... so may be present but not surfaced to the application, should
arise.
... Nigel, do we need to discuss more?
Nigel: I'm kind of happy to leave it to the editor, you've had some useful input.
Chris: I will give it more thought, could go back to the original wording.
Rob: A couple weeks ago there was OGC
technical committee meeting in Belgium.
... I was invited because I'm a member of the Spatial Data on the
Web group, a joint W3C and OGC group.
... I've presented to them before, but this was the first time in
person
... I gave three presentations and a short introduction.
... Went well, there's interest in what we're doing.
... There's an opportunity for them to make contribution.
... We had a breakout on video metadata search.
... There's a GitHub issue with the conclusions, you can have a
look:
<RobSmith> https://github.com/w3c/sdw/issues/1130
Rob: OGC have an innovation program,
similar to WICG.
... They investigate new problems, develop solutions, etc.
... OGC members sponsor efforts. Flood monitoring, traffic,
etc.
Chris: Were there any specific suggestions, or requirements for us to take into account here?
Rob: Not at this stage, but I've made
them aware that this activity is going on, and
... opportunity to contribute, and now is a good time.
Kaz: OGC guys attended the WoT
workshop in Munich,
... there was some discussion of collaboration with W3C for IoT use
cases.
draft minutes from the 2nd WoT workshop
Kaz: The use cases on issue 1130 are
very interesting from the ME viewpoint and the WoT viewpoint,
... further collaboration among OGC, ME and WoT is encouraged.
Rob: Please respond to the GitHub issue, the SDW chairs would be interested in the collobration, now rechartering.
Chris: [talks through the API example
(emsg event with an ad insertion cue)]
... Application has to interpret the data in the ArrayBuffer.
... There is a library that parses the SCTE-35 message, it's quite
a lot of code.
... You identify the type of the message using
inBandMetadataTrackDispatchType.
... It's a field in TextTrack in HTML, for the purpose of
identifying the stream for inband cues.
... For emsg, there is a schema id and value,
... "schemeIDUri" defined as "urn:scte:scte35:2013:bin" here.
... Proposal is similar to the HbbTV model. You have a TextTrack
per type of timed metadata cue.
... How to use for application generated events?
... In that case, you can simply create a TextTrack with
kind=metadata.
... No need to set inBandMetadataTrackDispatchType, as the events
aren't sourced by the UA.
... inBandMetadataTranckDispatchType is inconsistently implemented
in browsers, I don't think it's in Firefox at all.
... I think Safari has it for HLS timed metadata. Not sure about
Chrome.
... There is an issue, a lot of detail in HTML about ids
Chris: We may need to extend this in
HTML.
... It links to the Media Fragment URI spec. I couldn't see how the
id field works in that case.
... I can write a element and give it an id, so it's unclear how
the id behaves in the two cases:
... if I create a element or by creating a TextTrack object via the
API.
... This seems to be underspecified to me. Not sure how the spec
corresponds with what browsers actually do.
... If you have time, please look at the issue.
Chris: Rob and I had discussion on expected behavior for changing cue start and end times.
Chris: I have done some experiments
on how text track cues behave in practice when you adjust their
start and end times, will write up the results.
... I found some differences between browsers.
... For example, if you have a cue, and the mediaElement's
currentTime is in the middle of the cue,
... then you increase the cue endTime, in one browser you get a cue
onenter event, in another you don't.
... Also, if you have a cue, and the mediaElement's currentTime is
in the middle of the cue,
... then you change the cue endTime such that the mediaElement's
currentTime is now outside the cue,
... in one browser the cue still remains in the activeCues list,
and in another it gets removed.
... Not sure if it's a spec issue or an implementation issue, check
"time marches on".
Nigel: When it was moved, was the onexit handler fired?
Chris: I need to double check my
results on that. I'll write it down and share with you.
... Is there web platform test support for the TextTrack API? I
found some VTTCue tests, but not for TextTrack more generally.
Nigel: I only know about VTTCue, don't know about the rest.
Chris: I want to get implementer
feedback as soon as we can,
... to understand people's interests, where we have consensus, and
get input.
... We'd mainly use the explainer for that.
... My plan is to send out a doodle poll, you all are welcome to
join.
... Want to open up a conversation, see that we're going in the
right direction.
... Want to do that during the next week or so.
Chris: Anything else for today?
(none)
Chris: August 19th
[adjourned]