W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

[Bug 13333] audio, video (and source) elements require param children or equivalent

From: <bugzilla@jessica.w3.org>
Date: Thu, 28 Jul 2011 12:09:13 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QmPOr-0008F8-LA@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #33 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-07-28 12:09:13 UTC ---
(In reply to comment #32)
> (In reply to comment #0)
> > <audio>
> >   <source src="audio.mp3">
> >     <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
> >   </source>
> >   <source src="audio.mp3">
> >     <param name="dlna-res-protocolInfo"
> > value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
> >   </source>
> > </audio>
> 
> Why isn't this written as 
> <audio>
>   <source src="rtsp://something/audio.mp3">
>   <source src="http://something/audio.mp3">
> </audio>
> ?
> 
> (In reply to comment #28)
> > (In reply to comment #26)
> > > (In reply to comment #24)
> > > > Regarding actual implementations of DRM support in browsers, there is more than
> > > > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > > > TIME makes use of the param child on object to communicate DRM parameters.
> > > 
> > > What browsers are those?
> > 
> > I am referring to browsers currently deployed on Televisions, Set-Top Boxes,
> > and Mobile Devices, particularly those that participate in the playback and
> > sharing of DRM controlled video or audio content. There are a variety of
> > standards/specifications that apply to such devices, such as those defined by
> > DLNA and other industry associations.
> 
> I meant the names of the browsers.
> 
> Why does your DRM scheme require parameters to be supplied alongside the
> DRM-obfuscated file? That is, why isn't it sufficient to treat the DRM wrapper
> as a special kind of file format? Like this:
> <audio>
>   <source src="audio.drm" type="audio/industry-association-drm-wrapper">
> </audio>
> 
> Anyway HTML5 is trying to be a spec for the Web--a royalty-free system where
> multiple vendors can implement clients without asking permission from a DRM
> proprietor. While it's possible to reuse Web specs in closed systems, I think
> we shouldn't design HTML5 for closed systems, since that's a distraction that
> takes attention and focus away from making the Web better. That is, I think we
> shouldn't spend time adding closed system-motivated features.
> 
> More concretely, I don't want to disrupt the parsing of <source> (a void
> element--for better or worse--in shipped Web browsers) in order to cater to
> closed-system use cases.



I actually read this whole thread as a request for an attribute and not an
element. I think it can be done better with an attribute without destroying the
parsing of <source> as it is now. For example, it can be done as something
like:

<audio>
  <source src="audio.drm"
          x-dlna-res-protocolInfo="httpget:*:audio/mpeg:DLNA.ORG_PN=MP3">
</audio>

or

<audio>
  <source src="audio.drm"
          x-param="dlna-res-protocolInfo=httpget:*:audio/mpeg:DLNA.ORG_PN=MP3">
</audio>

In any case, I agree with Henry that we should neither destroy the parsing of
<source> nor the openness of the HTML5 spec.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 28 July 2011 12:09:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:14 UTC