#7298: use html5 video tag for animations
-------------------------------------+-------------------------------------
Reporter: whuss | Owner: whuss
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.4
Component: graphics | Resolution: fixed
Keywords: animation, video | Merged in:
Authors: Martin von Gagern | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/7298 | 025c6c12fdaf4ac34636712b2ad5da5c315ec6e4
Dependencies: | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gagern):
Replying to [comment:63 vbraun]:
> But !OutputVideoAny is just a slap in the face of any attempt at sanity.
The whole point of the rich output model is to separate different output
types.
I can understand some of your concerns. To me, a supported output type is
a promise. For most simple output types the promise is “if you give me a
file of said type, I'll display it to the user”. But with video, it's not
as simple. It's not the backend which decides what video formats are
supported, but instead it's the browser or the system setup. So the
promise I associate with `OutputVideoAny` is “if you give me a file of
said type, I'll present it to a user in such a way that it either plays or
the user gets notified about what went wrong”. Which in a browser context
means “I'll create a HTML5 `<video>` tag for it”.
Due to this nature, `OutputVideoAny` should never be used to auto-guess
supported formats. It doesn't mean “this client supports any video
format”, but instead “this client can present any video format to the
user, but that presentation might be in the form or an error message”. So
the machinery shouldn't use it to throw arbitrary formats at the back end,
but as a means to throw explicitly requested formats at it.
I wouldn't mind having specific formats. For video, a full file format
description consists of a container format, a video codec format, and
possibly a bunch of other constraints as well. So we'd have
`OutputVideoWebMVP8` and `OutputVideoWebMVP9` and `OutputVideoOggTheora`
and `OutputVideoAviH264` and `OutputVideoFlashH264` and
`OutputVideoMp4H264` and `OutputVideoQuicktimeH264` and probably a hundred
other combinations. (We could parse the list of formats FFmpeg supports.)
And in my opinion, each of these would indicate a promise to actually
support the given type. So we'd have to somehow detect support. Or state
that such a type being listed with the supported types does not imply it's
actually supported. I have no idea on how to do auto-detection, and having
a bunch of maybe supported formats feels no different to my
`OutputVideoAny`.
So do you have any suggestions of how to handle this situation in a better
way? I understand your criticism from an idealistic point of view, but on
the pragmatic side, unless one can do active format support detection, all
formats are essentially the same to the backend, and a single
representation for all of them avoids useless overhead.
> The rich output container must not contain anything but the data. No
mime types, no file extensions. The type is unique to the output. By
lumping it into a single OutputAllVideoThatSageNBunderstands you destroy
any hope of ever supporting other notebooks without reverting your branch.
It's not “output all video that Sage NB understands”. It's more like
“output all video which can possibly be handled by a `<video>` tag”,
combined with “output all video which gets opened by launching up the
user's default media player”. For the `<video>` tag you need the MIME
type. For the media player, you need the correct file extension. But if
you consider the `<video>` element as the deliverable of the output, then
the mime type is very much part of the data needed to assemble that.
One more comment: if there is one thing I can't stand about computer
programs, it's if these try to be more clever than the user. The user
should be in charge, and if the user says “I want to view this animation
in that format”, the code should not second-guess that decision, should
not forbid the operation just because the named format isn't in a list of
known formats, or support by the browser or media player can't be verified
up front. Please leave the users in charge of their application, not the
other way round!
--
Ticket URL: <http://trac.sagemath.org/ticket/7298#comment:64>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
