-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixup MIME usage #222
base: main
Are you sure you want to change the base?
Fixup MIME usage #222
Conversation
305ab3d
to
b7f3138
Compare
This PR replaces valid media MIME type with algorithmic steps. It could lead to similar changes to valid video configuration all the way up to valid MediaConfiguration. Please comment if you see any issues with the direction this is taking. @aboba One specific question, as we develop this PR: section 2.1.4.2 RTP currently references RFC4855 and RFC6838, which define registration requirements. This PR proposes changing these to reference https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml instead. Is this OK? |
This is ready for review. PTAL @mfoltzgoogle, @aboba, @alastor0325, @marcoscaceres The PR makes two main changes:
If needed we can tackle "valid video configuration" etc in follow-up PRs. |
LGTM with one side comment, nice PR @marcoscaceres I just did a first read of the spec and wondered if a long term possibility is to decouple from mime types along the lines of the WebCodecs registry. However, the registry is missing a bunch of codecs though that may never be supported in WebCodecs, and container parsing support seems to be out of scope for WebCodecs as well. |
There's a similar discussion in this EME issue: w3c/encrypted-media#559. I think a registry could help, but also recognise Joey's concerns in w3c/encrypted-media#559 (comment). This might be one to talk about at TPAC. |
@adoba, bumping the question above in #222 (comment):
|
@chrisn per https://www.w3.org/2024/09/26-mediawg-minutes.html#a01:
After that is done, this should be ready to merge. |
I've added the link to the IANA media type registry, as well as bringing back the references to the RTP specific RFCs. |
Co-authored-by: Marcos Cáceres <[email protected]>
Co-authored-by: Marcos Cáceres <[email protected]>
Co-authored-by: François Daoust <[email protected]>
…ation of algorithms
Helps readers understand the algorithm is specified in EME.
@markafoltz I have removed the RFC4855 reference as we discussed in today's meeting (minutes). The PR is ready for your review. Many thanks. |
and {{MediaEncodingType}} or {{MediaDecodingType}} |encodingOrDecodingType|. | ||
</li> | ||
<li> | ||
If |result| is <code>failure</code> or <code>unsupported</code>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two problems here?
-
The Check MIME Type Support steps don't return
unsupported
, but see my proposed change below to fix the steps. -
If the result is
unsupported
, IIUC, we shouldn't reject the configuration as invalid. We should pass through the result to Create a MediaCapabilitiesDecodingInfo to set thesupported
property of theMediaCapabilitiesDecodingInfo
return value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right ... we should only reject if parsing the MIME type fails or the type something other than video
or application
. I can try to adjust the algorithms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difficulty I see is that we currently call Check MIME Type Support from valid video configuration and valid audio configuration (via valid MediaDecodingConfiguration and valid MediaConfiguration) but we need to use the result from Check MIME Type Support in Create a MediaCapabilitiesDecodingInfo.
What I'd like to propose is we write a complete set of algorithm steps for decodingInfo()
and in doing so remove the valid MediaDecodingConfiguration, valid MediaConfiguration, valid audio configuration, valid video configuration, etc. concepts (and similar for encodingInfo()
).
This would make this PR a much bigger rewrite, but I think it would takes us in the right direction. The alternative would be to keep valid video configuration etc but then we'd need to split Check MIME Type Support into two algorithms: one to check basic validity (does it parse, is its type audio, video or application, etc), the other to check for UA support.
Or am I missing an easier way to solve this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we take Check MIME Type Support out of the valid video configuration steps and instead call it in the Create a MediaCapabilitiesDecodingInfo algorithms? (Similar for audio, encoding, etc.)
It would be okay to reject early with a TypeError
because the input is invalid (i.e. correct properties not set) and later also reject with a TypeError
because the contentType
could not be parsed.
and {{MediaEncodingType}} or {{MediaDecodingType}} |encodingOrDecodingType|. | ||
</li> | ||
<li> | ||
If |result| is <code>failure</code> or <code>unsupported</code>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment applies here.
Closes #69
this is a draft... it doesn't actually address all the issues with MIME usage yet... just a start.
Preview | Diff