This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10202 - use of "codecs" parameter
Summary: use of "codecs" parameter
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NE, WGDecision
Depends on:
Blocks:
 
Reported: 2010-07-19 15:30 UTC by Julian Reschke
Modified: 2011-04-12 22:14 UTC (History)
7 users (show)

See Also:


Attachments

Description Julian Reschke 2010-07-19 15:30:12 UTC
<http://dev.w3.org/html5/spec/video.html#the-source-element> shows the "codecs" parameter in use with various media types that do not define it, for instance, "video/mp4".

For these media types, either the registration needs to be updated, or those examples should be removed.
Comment 1 Ian 'Hixie' Hickson 2010-08-16 21:49:06 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Please update the registrations.
Comment 2 Julian Reschke 2010-08-17 06:15:06 UTC
One way to fix this is indeed to update the registrations. It's not clear to me why this would be my job, though.

This continues to be a bug, so closing the bug doesn't help.
Comment 3 Ian 'Hixie' Hickson 2010-08-17 18:50:14 UTC
Dave, can you advise?
Comment 4 David Singer 2010-08-18 08:04:05 UTC
RFC 4281 applies to all files in the ISO base media file format family, as clearly stated at the end of section 3.1 and the beginning of 3.2:

"This document only defines values for files in the ISO Base Media File Format family.  Other file formats may also define codec naming.

3.2.  ISO File Format Name Space

   For the ISO Base Media File Format, the first element of a Codecs
   parameter value is a sample description entry four-character code as
   registered by the MP4 Registration Authority [MP4-Reg].  Values are
   case sensitive."

video/mp4 is one of these formats, and therefore the example is correct.
Comment 5 Julian Reschke 2010-08-18 08:38:29 UTC
Other examples in the spec are "application/octet-stream" and various non-registered types.

For "application/octet-stream", this is a problem:

"In the absence of a  specification to the contrary, the MIME type "application/octet-stream" when used with  parameters, e.g. "application/octet-stream;codecs=theora", is  a type that the user agent knows it cannot render."

Maybe this can be fixed by simply stating that there is no codecs parameter on application/octet-stream, thus the example is invalid (and thus results in "cannot render").
Comment 6 David Singer 2010-08-18 09:31:52 UTC
The authors of 4281 had no 'ownership' of application/octet-stream so use of the codecs parameter on this might be helpful but cannot be normative.  I am not sure that it helps anyone to forbid clients from looking at the parameter, however, but we certainly cannot require that they look at something that is formally undefined.
Comment 7 Julian Reschke 2010-08-18 09:38:37 UTC
(In reply to comment #6)
> The authors of 4281 had no 'ownership' of application/octet-stream so use of
> the codecs parameter on this might be helpful but cannot be normative.  I am
> not sure that it helps anyone to forbid clients from looking at the parameter,
> however, but we certainly cannot require that they look at something that is
> formally undefined.

Indeed.

Also, it would be good if it was clear that application/octet-stream never should be played.
Comment 8 Philip Jägenstedt 2010-08-18 12:21:51 UTC
The weird condition on application/octet-stream was added after we (Opera) asked how to handle applciation/octet-stream with a codecs parameter, for completeness. I would be fine with the spec saying that application/octet-stream is a "maybe" type regardless of the codecs parameter, it doesn't really matter.

It would also be great if application/octet-stream was a "no" type, but I doubt we can change this now, especially as WebKit is ignoring Content-Type entirely.
Comment 9 Julian Reschke 2010-08-18 12:30:57 UTC
(In reply to comment #8)
> It would also be great if application/octet-stream was a "no" type, but I doubt
> we can change this now, especially as WebKit is ignoring Content-Type entirely.

I agree that "no" would be the right thing here.
Comment 10 Ian 'Hixie' Hickson 2010-08-18 17:55:25 UTC
It seems to me that, ignoring any formal process issues, what we want is for UAs to honour codecs="" on all the types they support. Given that, I don't really see a problem with including the examples as is. Now if it happens that this conflicts with some other definitions, we should either update those definitions or mention the violation in the spec, but we shouldn't pick an inferior solution because of process.

Does anyone care enough about process to fix the process issue (e.g. by registering this parameter on all video and audio types)?

The application/octet-stream thing is a separate issue.
Comment 11 David Singer 2010-08-18 17:58:17 UTC
The problem is that there is no 'global name' for a codec.  The 'names' in MP4 files are the codec 4CCs used in MP4, but different 4CCs are used in say AVI, and ASF does not use 4CCs at all.  This means that a 'codecs' parameter for (say) octet-stream is 'un-anchored' in its name space.  You *can* say (and some have) supplies the names of the codecs *as if* they were in an MP4 file, if you like.
Comment 12 Ian 'Hixie' Hickson 2010-08-19 18:15:35 UTC
Ah, I didn't realise that codecs="" had names whose meaning was scoped to the given MIME type, that changes matters significantly. I'll have to look at the spec more carefully to make sure I haven't made a mistake because of that assumption.

Presumably though, the original report -- that codecs="" is applied to video/mp4 -- is not actually a problem then, since video/mp4 is one of the types that has well-defined codecs="" values? Right? Does that mean that video/mp4 should be updated to accept codecs="", or is Julian wrong and it already does?
Comment 13 Julian Reschke 2010-08-19 18:21:47 UTC
(In reply to comment #12)
> Ah, I didn't realise that codecs="" had names whose meaning was scoped to the
> given MIME type, that changes matters significantly. I'll have to look at the
> spec more carefully to make sure I haven't made a mistake because of that
> assumption.
> 
> Presumably though, the original report -- that codecs="" is applied to
> video/mp4 -- is not actually a problem then, since video/mp4 is one of the
> types that has well-defined codecs="" values? Right? Does that mean that
> video/mp4 should be updated to accept codecs="", or is Julian wrong and it
> already does?

David already clarified that it's fine for video/mp4.

The issue remains for application/octet-stream, and yet unregistered types in the examples.
Comment 14 Ian 'Hixie' Hickson 2010-08-31 04:09:56 UTC
What is the issue with application/octet-stream? I don't see any examples in the spec that suggest that should use the "codecs" parameter (on the contrary).
Comment 15 Julian Reschke 2010-08-31 06:04:35 UTC
(In reply to comment #14)
> What is the issue with application/octet-stream? I don't see any examples in
> the spec that suggest that should use the "codecs" parameter (on the contrary).

"Note: In the absence of a  specification to the contrary, the MIME type "application/octet-stream" when used with  parameters, e.g. "application/octet-stream;codecs=theora", is  a type that the user agent knows it cannot render."

The intent of this probably is right, but it could be much much clearer that the codecs parameter is not defined on application/octet-stream. Such as.

"Note: the "codecs" parameter is not defined on application/octet-stream, therefore..."

Yes, that *could* become incorrect if somebody did define it, but I really don't see how this can happen for this type.

The first before is:

"A media resource can be described in terms of its type, specifically a MIME type, optionally with a codecs parameter. [RFC4281]"

This is another place where the spec could clarify that "codecs" is only defined on certain media types (and maybe list the RFCs that do this).
Comment 16 Ian 'Hixie' Hickson 2010-09-29 00:07:31 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Ok, I've tried to make it clear that the type isn't allowed everywhere.
Comment 17 contributor 2010-09-29 00:08:01 UTC
Checked in as WHATWG revision r5544.
Check-in comment: Be more pedantic about 'codecs'.
http://html5.org/tools/web-apps-tracker?from=5543&to=5544
Comment 18 Julian Reschke 2010-09-29 06:54:01 UTC
Thanks for the clarifications. However, the spec still says:

  "Note: In the absence of a  specification to the contrary, the MIME type  "application/octet-stream" when used with  parameters, e.g. "application/octet-stream;codecs=theora", is  a type that the user agent knows it cannot render."

This is still confusing.

Can this example be changed to use a different parameter name? Such as "type=example"?
Comment 19 Ian 'Hixie' Hickson 2010-09-29 08:10:00 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: That isn't what the spec says anymore.

I don't want to use another parameter because the whole point is to clarify what the codecs parameter should do here, since that's what implementors asked me about. We're not doing this just to be pretty or perfect, the goal here is to actually get implementations doing this stuff interoperably.
Comment 20 Julian Reschke 2010-09-29 08:24:50 UTC
In which case it would be great if the spec clarified that "codecs" is indeed not defined on application/octet-stream.
Comment 21 Philip Jägenstedt 2010-10-13 08:56:34 UTC
(In reply to comment #20)
> In which case it would be great if the spec clarified that "codecs" is indeed
> not defined on application/octet-stream.

Sure, if it also says exactly what should happened with parameters which are not defined. Existing implementations ignore unknown parameters, so canPlayType('video/ogg;bla=bla') returns 'maybe' in at least Firefox and Opera. Along this line, we could let canPlayType('application/octet-stream; codecs=bla') return whatever canPlayType('application/octet-stream') returns.
Comment 22 Julian Reschke 2010-10-13 09:41:29 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > In which case it would be great if the spec clarified that "codecs" is indeed
> > not defined on application/octet-stream.
> 
> Sure, if it also says exactly what should happened with parameters which are
> not defined. Existing implementations ignore unknown parameters, so
> canPlayType('video/ogg;bla=bla') returns 'maybe' in at least Firefox and Opera.
> Along this line, we could let canPlayType('application/octet-stream;
> codecs=bla') return whatever canPlayType('application/octet-stream') returns.

Which sort-of confirms that the spec is confusing.

In general, ignoring unknown parameters is the right thing to do.

If HTML5 wants UAs to treat a bare "application/octet-stream" in a specific way, it probably needs to be phrased differently.

Optimally, "application/octet-stream" would never be treated as video.
Comment 23 Philip Jägenstedt 2010-10-14 11:49:01 UTC
For the record, this is the bug I filed asking for clarification on application/octet-stream with parameters: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977
Comment 24 Ian 'Hixie' Hickson 2010-11-11 23:05:18 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: no new information since comment 19
Comment 25 Sam Ruby 2010-11-29 19:37:22 UTC
http://www.w3.org/html/wg/tracker/issues/145
Comment 26 Sam Ruby 2011-03-31 14:15:22 UTC
Working Group Decision: http://lists.w3.org/Archives/Public/public-html/2011Mar/0755.html
Comment 27 contributor 2011-04-12 22:14:03 UTC
Checked in as WHATWG revision r5994.
Check-in comment: apply wg decision
http://html5.org/tools/web-apps-tracker?from=5993&to=5994