Meeting minutes
Slideset:
https://
Agenda
Chris: (goes through
the agenda)
… CTA WAVE liaison, Media WG/HDR, IETF SCONEPRO,
DASH-IF, TPAC
… any other topics?
(none)
CTA WAVE liaison
Chris: We received a liaison letter from CTA WAVE
Chris: They have
developed a test suite to help with interoperability of media
content across devices including TV
… There was a demo at Media Web Symposium 2024 as
well. I think this is an important contribution.
… I replied to say we're very interested and would
invite CTA WAVE to present and discuss,
… need to identify the date.
<Igarashi> +1
Chris: We'll negotiate
a session to discuss in more detail.
… There are links to the various resources in the
liaison letter.
Alicia: have to be
something separate
… the goal is to make sure browser support for
different contents
… could be web platform test by different browser
vendors
Chris: any specific points?
Alicia: maybe resource
intensive for resources
… may use automatic image validation
Chris: the test set to
be clarified too
… QR codes here and time codes
… image processing by the smartphone's video
camera
Alicia: it's an interesting approach definitely
Piers: The code and
media for the CTA-WAVE DPC Test suite is here: https://
Chris: not sure how to test video element
Martin: I'm part of the
team that hosted that demo.
… The QR code on the right is from currentTime API,
it tests correct emission of the events and metadata.
… The recording device must capure the video at 2x
the FPS of the refresh rate of the panel.
… When the content has 25 FPS, the recording device
must be at 50 FPS, so no frame is missed.
Alicia: But not all cameras will be capturing at 50 FPS, could be 60 FPS.
Martin: Yes, it just needs to be a higher FPS, 50fps, 60fps or 120fps.
Alicia: flicker also
Martin: The system measuring MSE, measurement might be distracted by the device itself
Alicia: Tests that
require real devices aren't done often, need manual
components,
… unless you have a permanent CI test system. With
WPT the infrastructure already
… exists. Can test through the APIs, can be done on
every commit
Martin: The tests are
based on WPT, but there are long running tests, can be too much for
every commit.
… After the reording is done, there's analysis,
which takes time.
Chris: Martin, have you seen the discussion by CTA WAVE guys around organising a future meeting?
Martin: I'd need to talk to Louay
Chris: OK, I'd like to
invite you both, as well as CTA WAVE members to talk in more
detail.
… I will follow up to invite you.
Media WG update
Chris: EME v2 first
public WD is in progress.
… We'll also publish the HDCP version registry
which lists the HDCP versions that could be used.
… The WG is also publishing all EME/MSE registries
to /TR
… No major changes to these, but they may need
maintenance updates, e.g., to point to the latest referenced
specs.
Chris: Registries
include:
… MSE Byte Stream Format Registry
… EME Initialization Data Registry
… EME Stream Format Registry
… Also WebCodecs VideoFrame Metadata Registry was
recently published. This includes some entries to suport WebRTC use
cases.
… Human face detection metadata and background
segmentation, for background blur or removal in the web
app.
… These come from WebRTC WG but has been useful to
discuss in Media WG where there's expertise on VideoFrame and
WebCodecs.
… There's more work to do in Media WG, e.g., on MSE
with Managed Media Source, which doesn't have multiple
implementations yet,
… so it's ongoing working progress
… Any comments or questions?
(none)
HDR update
Chris: PNG WG is
working on PNG v3 spec with HDR support.
… It's at Candidate Recommendation now, and the
plan is to finalize it as a REC
… then look at other potential
changes.
… Color on the Web CG next meeting on July 9, to
look at
… TAG feed back on the current HDR Canvas
proposal.
Chris: I invite you to join that meeting if HDR is of interest to you.
Chris: Apart from this, is there anything you're aware of also to mention?
(nothing specific)
IETF SCONEPRO
Chris: We discussed a bit in the Web & Networks IG meeting last week. I would like to invite Dan to talk about it.
Dan: Thanks for
summarizing in the slides
… SCONEPRO stands for "Secure Communication of
Network Properties",
… but the actual scope is a lot narrower than the
title.
Dan: The main thing it
tries to solve is a challenge perceived in the industry
… regarding how some of the plan management is
transitioning from data caps to bitrate caps.
… Important for mobile operators and satellite
operators, where radio resources are limited.
… With video the dominant form of media, it's
necessary in the market to differentiate.
… Previously done using data caps, 5GB or 25GB. Now
in the US they're all unlimited plans, but with variations that are
around video,
… e.g., a cheaper plan with standard video, other
plans that allow HD, others 4K.
… Adaptive bitrate by definition adapts to network
conditions, but not always easy to detect video.
… Network policy is applying shaping, caps the
bandwidth of the connection to certain limits.
… This doesn't necessarily translate to the video,
it blindly covers all flows.
… SCONEPRO tries to create a plan-aware mechansim
where the app providers receive a signal
… about the max bitrate they're supposed to deliver
to a player, and they stick to that and adapt within that
range,
… not the entire range of ABR
available.
… It's meant to be in-path for QUIC traffic. QUIC
is becoming the majority of video traffic from large video and
social media providers. Relevant to short form videos.
… At IETF in March there was a non WG forming BoF,
so people presented the issues, some heated debates on what
should/shouldn't be done.
… IETF July will be a WG forming BoF, goal to start
work on this topic.
… It is a one way communication for now. Metadata
associated with the subscription and video streaming properties,
and the application will self-police.
… Why is it relevant to this group?
… QUIC is an application layer transport stack.
Many services have implementations on both client and server
side.
… They can receive signals on the endpoints.
Challenging when player is in the browser, as the client uses the
browser's QUIC implementation.
… There's no web API that exposes anything at
protocol level to the web app. It's in the charter, when the
protocol work starts, a corresponding nneed for a web layer
API.
… MEIG is a good place to share the idea and get
clear requirements, then start the API work in a WG.
… If you're planning to be in Vancouver, the agenda
isn't yet published. Should be interesting, hope to see you
there.
Chris: Thanks for introducing this. Any thoughts/questions?
Alicia: I'm concerned about net neutrality. Why should W3C support this?
Dan: Good question,
Meta published a draft about that. It's really not discriminatory,
for one app vs annother.
… Signal is sent to all apps, for all users and all
applications. Recommend looking at the draft from Meta.
<piers> Draft on net
neutrality:
https://
Alicia: This doesn't
alleviate my concerns, worry of ISPs squeezing money out of
customers.
… Different between pricing bandwidth for specific
apps and bandwidth in general. W3C shouldn't encourage
this.
Dan: In the IETF discussion, net neutrality wasn't the major concen, more privacy issues associated with the subscriber's side.
Alicia: QUIC was intended to prevent ISP from doing this.
Dan: This was initated
more by the content providers than the network operators.
… They do apply policies for traffic. It's not
about squeezing more money from users, it provides
choice.
… They can choose a SD vs HD vs 4K
plan.
… I just wanted to point you to the draft on net
neutrality above for today.
… We could have further discussion at
TPAC.
Chris: I wanted to
mention about a proposed addition of a quality attribute to
ManagedMediaSource API,
… as a hint from the browser to the web
app.
media-source Issue 322 - Proposal: Add quality attribute to ManagedMediaSource API
Chris: It could satisfy this use case?
Dan: Maybe, but seems premature to discuss.
Chris: Thanks Dan for joining and introducing this topic. How to send feedback, e.g., comments in a SCONEPRO GitHub repo?
Dan: Most QUIC
participants are supportive, as they understand the use case.
… Also a reverse use case where the app can convey
congestion options, what is the app interested in
deprioritising?
Chris: So the current focus is scoping of a WG, not so much on specific technical solutions?
Dan: Yes
Piers: There was a presentation from YouTube also, they're already using something similar.
Dan: That's an OOB mechanism rather than in-line. They explained how it improves performance.
Piers: On the preferred
quality in ManagedMediaSource, another possible thing it can be for
is server-guided bitrate selection.
… MoQ is more server driven than client driven,
maybe it comes from that angle as well?
Chris: I'd need to check on the original rationale for including it. But for now it's on hold in Media WG and not part of the spec.
Chris: Thanks all for the discussion.
DASH-IF special session on Content Authenticity and Provenance in DASH
Chris: I should declare
some interest in this. BBC is contributing to C2PA
specifications.
… But today I'm speaking as MEIG co-chair rather
than proponent from BBC.
… I'm in discussion with the people from Adobe who
presented this at June 7 DASH-IF meeting.
… C2PA is about showing provenance of the
content.
… In the meeting someone suggested that it could be
interesting to move the work from the DASH player to the HTML video
element or MSE implementation in the browser.
Chris: Image shows
content credentials menu on the timeline, where the blue indicates
succesful validation, and red invalid.
… The content credentials icon shows the
metadata.
… There's work in C2PA looking at how to do DASH
streaming, both live and on-demand video.
… We could discuss detail in a possible future
meeting, but not planned yet.
Alicia: I have some
general doubts, as proposed by Adobe, but I'm not familiar with the
protocols.
… I have some concerns in that it could be very
nice, signing is generally useful.
… I can see good uses but I can also see potential
concerns and incentives from Adobe.
Chris: If you haven't seen it, I would suggest watching the DASH-IF meeting recording.
Piers: Unclear they have a mechanism. One idea could be to have an EME for authentication as opposed to encryption.
Alicia: One concern as
an example: Who is signing the information?
… We already have mechanism on the web. If I was
the authentication provider I'm incentivised to sign all content to
charge fees in the future.
… How is addressed in the protocol?
Piers: It's a separate PKI, not the web PKI.
Alicia: That's part of my concern.
TPAC 2024
Chris: We're running
out of time, so just quickly, one open question to you is
… if you plan to join the meeting (in person or
remotely) and if you have any topics in mind for the
agenda,
… please let me know.
… There'll be some discussion around
next-generation audio (covered in previous TPAC), etc.
AOB
Chris: Anything else for today?
(none)
Chris: Thanks for all
your discussions!
… The next meeting will be held in
August
[adjourned]