Re: Overview of Media Technologies for the Web

Francois, all

With the rechartering of the Media and Entertainment IG it makes sense to
take a fresh look at related technologies, their status and relations to
important aspects.

I think the document looks well and the structure is intuitive.

Some comments - mostly related to the Multi-device Timing CG.

- Media Control. One aspect of media that could additionally be addressed
here relates to flexibility. For example, can a media experience be
controlled from two devices or by multiple users? Can control easily be
handed over from one device to another? In a group, can media control be
symmetric (everybody can control) or asymmetric (only a select few can
control). This would be an area were exploratory work is covered by the
Multi-device Timing CG.

- Media Rendering vs Content Orchestration. The distinction between these
two categories at first seems a bit unclear to me, with distributed
playback being a theme of both.
The way I read it Media Rendering is focused on standalone playback
components, plus mechanisms for piping media output to another device.
Content orchestration seems to be about temporal coordination of
independent playback components (be it within a single web page or across
different devices)
Would this be correct?

- Content Orchestration. Could it rather be named Media Orchestration?
Within MPEG there is already an on-going initiative [1] using this term.

[1] https://mpeg.chiariglione.org/standards/mpeg-b/media-orchestration

- Media Capture. Please include also the aspect of timestamp accuracy in
captured content. This is of great importance to for any multi-angle media
productions involving video and audio, and more generally all media
production where captured media should be precisely relateable to a
real-world clock (epoch).

Capturing devices may provide a timestamp, but it is rarely known when
exactly this timestamp was taken (i.e. sometime after requesting an image
and before the image is available in JS - this could be hundreds of
milliseconds). Equally important, upstream delays in sensor processing
pipeline must be known, so that timestamps can be compensated. This is
analogous to work done in the Web Audio API where downstream delays are
exposed for media output. As delays may not always be known, techniques for
measurements and calibrations should likely be explored.
This is addressed as exploratory work within the Multi-device Timing CG.

Best,
Ingar Arntzen
chair Multi-device Timing CG


2017-09-28 11:22 GMT+02:00 Francois Daoust <fd@w3.org>:

> Dear Media and Entertainment Interest Group,
>
> I have been working on an "Overview of Media Technologies for the Web"
> document that lists Web technologies that can be used to build media
> applications and services, and highlights known gaps:
>
> http://w3c.github.io/web-roadmaps/media/
>
> The purpose is to provide a single resource that web developers in the
> media industry, as well as those involved in the standardization process,
> can use to find out about the current status of relevant Web technologies.
>
> The document is structured around different aspects of the media pipeline:
> - Media rendering
> - Media control
> - Media distribution
> - Media processing
> - Content orchestration
> - Media capture
> - Media application development
>
> It details Web technologies that apply to each of these aspects, with a
> short description of what that technology enables in a media context each
> time. Technologies are sorted in different categories depending on their
> status:
>
> - *Well-deployed technologies* are technologies that are finished or
> nearly finished (e.g. CR and beyond in the W3C Rec track) and that have
> already found significant adoption among implementations;
> - *Technologies in progress* list features that have already started their
> standardization track progress;
> - *Exploratory work* groups features described in specifications prior to
> their proper standardization work;
> - *Features not covered by ongoing work* identify functionalities that are
> known to be needed for some use cases, but that no existing specification
> adequately covers
> - *Discontinued features* point out attempts to develop a feature that was
> deemed useful at a point in time, but that was stopped for some reason, or
> that led to some alternative proposal.
>
> This overview should not be considered as anything else than work in
> progress right now. Some technologies are probably missing, descriptions
> should be improved. I wanted to share this document with you for two
> reasons:
>
> 1. to invite feedback on the document (look and feel, usefulness,
> structure, content, etc.).
> 2. to check whether the Media and Entertainment Interest Group would be
> interested to adopt this document as working document.
>
> In particular, the current charter of the Interest Group says that the
> group will "maintain a public list of the media features on the Web that it
> is tracking and investigating. These features will include identified gaps,
> stable features deployed in browser implementations, as well as features
> under development in W3C and external groups":
> https://www.w3.org/2017/03/webtv-charter.html#deliverables
>
> I'm wondering whether the Overview document could provide a good basis for
> that list, and a good working document to structure discussions within the
> group. If people are interested, I'll be happy to present that document
> during one of the IG calls as well as during the group's F2F during TPAC.
>
> This document is intended to be lightweight to maintain and complete over
> time. It is part of a series of roadmap-like documents, developed with a
> common framework. The framework takes care of adding implementation data
> for each feature/technology listed in the document, and of providing means
> for users to navigate between pages. The framework is still very sketchy
> for the time being, but will be maintained and improved by W3C team over
> time.
>
> You'll find more information about the ins and outs of such documents in:
> https://github.com/w3c/web-roadmaps#framework-for-web-technology-roadmaps
>
> Feel free to raise comments on the associated issue tracker:
> https://github.com/w3c/web-roadmaps/issues/
> (replies to this email are of course welcome as well)
>
> Thanks,
> Francois.
>
>
>