This was was cloned from bug 13625 as part of operation convergence.
Originally filed: 2011-08-03 19:38:00 +0000
Original reporter: Bob Lund <b.lund@cablelabs.com>

================================================================================
 #0   Bob Lund                                        2011-08-03 19:38:53 +0000 
--------------------------------------------------------------------------------
Problem description:

Commercial video providers want to use an HTML5 user agent to provide user interface for media playback on devices that also support the UPnP home networking protocol [1]. In this use case, home network content is stored in a content directory where each item in the content directory contains the URL of the content item along with content metadata. This metadata is called resource encoding characteristics properties [2]. Some of this data may be needed by the user agent for content playback, specifically:

o protocolInfo - third and fourth fields [3] contain content type information
o size - provides a hint of the content item size in the case of file based content
o protection  contains additional information for content protection

There is currently no way to represent this type of metadata in the video and audio element so it is available to the user agent. These metadata items may be relevant to types of content other than UPnP.

Proposed solution:

To address the above problem, it is proposed that three new attributes be added to the HTMLMediaElement for this metadata, e.g. contentInfo, size and protectionInfo.


[1] http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0.pdf, also ISO/IEC 29341-1:2008
[2] http://upnp.org/specs/av/UPnP-av-ContentDirectory-v4-Service.pdf, also ISO/IEC 29341-3-12:2008
[3] http://upnp.org/specs/av/UPnP-av-ConnectionManager-v3-Service.pdf, also ISO/IEC 29341-3-11:2008 section 2.5.2
================================================================================
 #2   Philip J                                        2011-08-04 08:24:11 +0000 
--------------------------------------------------------------------------------
Would it be possible to treat UPnP devices much like a webcam so that you get access to it via getUserMedia? That way the UA is pretty much free to do whatever is necessary to get access to the content.
================================================================================
 #3   Bob Lund                                        2011-08-04 16:29:00 +0000 
--------------------------------------------------------------------------------
I looked for getUserMedia in W3C HTML5 ed draft and WHATWG but didn't see anything? Can you provide a link?

The problem is that the user agent might need this metadata for playback. If getUserMedia is something available to script then it wouldn't appear to solve this problem.

Bob
================================================================================
 #4   Philip J                                        2011-08-05 06:27:40 +0000 
--------------------------------------------------------------------------------
http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#obtaining-local-multimedia-content

getUserMedia has an options parameter which could probably be used to pass along whatever initialization data is needed.
================================================================================
 #5   Bob Lund                                        2011-08-11 17:04:16 +0000 
--------------------------------------------------------------------------------
Thanks for the link. It looks like getUserMedia is used to expose a local media source while the use case stimulating this bug was the client accessing content from a server. It seems however that the getUserMedia object could be applied to the remote content use case in the following way:

- The options attribute would be used to convey the media URL that the local UA uses to fetch the media.

- The options attribute would also be used to convey metadata specific to that content that the local UA needs to correctly decode the content.

- Depending on the metadata, certain behavior of the MediaStream may be disabled, recording for example or forking of specific tracks.

I am assuming that when using the MediaStream (returned by getUserMedia) as a child of <video>, multiple video, audio and text tracks in the MediaStream would be exposed per HTML5 support for multiple video/audio tracks and <track>.
================================================================================
 #6   Michael Cooper                                  2011-09-20 15:31:17 +0000 
--------------------------------------------------------------------------------
Bug triage sub-team thinks this is an HTML A11Y TF priority for the media sub-team.
================================================================================
 #7   Clarke Stevens                                  2011-11-09 23:04:59 +0000 
--------------------------------------------------------------------------------
At the F2F meetings in Santa Clara, the HTML WG appeared to support this bug as
a way to pass parameters to media elements for support of adaptive bit rate media as well as content protection schemes. However, the HTML WG would like a concise list of common parameters for these purposes.

The Media Pipeline task force (MPTF) has agreed to review this and come up with a proposed list.

Here is a link to the relevant MPTF requirements:

http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R7._Additional_Media_Parameters
http://www.w3.org/2011/webtv/wiki/MPTF/MPTF_Requirements#R10._Content_Protection_Parameters
================================================================================
 #8   Mark Vickers                                    2011-11-09 23:14:50 +0000 
--------------------------------------------------------------------------------
The MPTF also took an action item to provide a document detailing the mapping from UPnP to HTML5, which is the example in the original bug report. This is currently in preparation.
================================================================================
 #9   Michael[tm] Smith                               2011-11-20 14:17:32 +0000 
--------------------------------------------------------------------------------
Flagging this with the needsinfo keyword to note that resolution is waiting on further information to be provided; see comment #7 and comment #8
================================================================================
 #10  Ian 'Hixie' Hickson                             2011-11-24 00:54:25 +0000 
--------------------------------------------------------------------------------
Status: Did Not Understand Request
Change Description: no spec change
Rationale: see comment 9
================================================================================
 #11  Michael[tm] Smith                               2011-11-24 01:14:16 +0000 
--------------------------------------------------------------------------------
Bob, Mark, Clarke,

Moving this to resolved=needsinfo is just a housekeeping way of indicating that this is waiting for additional information. It doesn't mean anybody considers it finally resolved ("resolved" is just the closest appropriate status that bugzilla provides).  

So please go ahead and reopen this when you have the info ready that you noted in comment #7 and comment #8.
================================================================================
 #12  Bob Lund                                        2011-11-28 23:40:32 +0000 
--------------------------------------------------------------------------------
In the HTML WG/Media Pipeline Task Force at TPAC CableLabs and Comcast agreed to document the how HTML5 would be used in a UPnP environment. This link http://html5.cablelabs.com/upnp/html5-upnp-integration.html#2-box-a provides additional details relevant to the UPnP use case behind this bug.

Bob
================================================================================
 #13  Michael[tm] Smith                               2011-11-29 09:32:55 +0000 
--------------------------------------------------------------------------------
Excellent.

I note that this bug is now just waiting on the list of parameters mentioned in comment #7
================================================================================
 #14  Clarke Stevens                                  2011-12-16 06:57:05 +0000 
--------------------------------------------------------------------------------
The Media Pipeline Task Force has submitted the following proposal in response to comment #7

http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Proposal
================================================================================
 #15  Clarke Stevens                                  2011-12-16 06:57:49 +0000 
--------------------------------------------------------------------------------
(In reply to comment #13)
> (In reply to comment #12)
> > In the HTML WG/Media Pipeline Task Force at TPAC CableLabs and Comcast agreed
> > to document the how HTML5 would be used in a UPnP environment. This link
> > http://html5.cablelabs.com/upnp/html5-upnp-integration.html#2-box-a provides
> > additional details relevant to the UPnP use case behind this bug.
> 
> Excellent.
> 
> I note that this bug is now just waiting on the list of parameters mentioned in
> comment #7

The Media Pipeline Task Force has submitted the following proposal in response to comment #7

http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Proposal
================================================================================