- From: <bugzilla@jessica.w3.org>
- Date: Mon, 15 Apr 2013 17:18:18 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18920
Aaron Colwell <acolwell@google.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
CC|acolwell@chromium.org |acolwell@google.com
Resolution|--- |WONTFIX
--- Comment #8 from Aaron Colwell <acolwell@google.com> ---
(In reply to comment #7)
> We are operating an encrypted cloud storage site, and are using XHR + File
> API + FileSytem API to do in-browser encryption / decryption for file
> transfers. We would love to offer our users a preview feature for the
> various supported video formats and we very much welcome the MediaSource
> API. However, we do not have access to the user file so we cannot determine
> the mime type on the server side. It would very much help us if the Media
> Source API is more intelligent and auto-detects the codec. Format parsing in
> JavaScript is indeed very cumbersome.
For applications to properly work with MSE they need to have details about the
layout of the files so they can properly handle seeking. MSE also only works
with files that conform to the byte stream specifications outlined in the spec.
For example normal non-fragmented MP4 files cannot be played w/ MSE. Only
fragmented MP4 files can be used. Even if the mimetype requirement was relaxed,
you still would have to know intimate details about the file for your
application to work properly with MSE.
As MSE becomes more popular, I'm sure that JavaScript libraries to parse and/or
transmux content will become available so it should be easier to achieve your
goals. Simply making the mimetype parameter optional won't accomplish what you
need though and actually makes it harder for the UA to reject content it can't
support w/o interrupting playback.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 15 April 2013 17:18:20 UTC