Page MenuHomePhabricator
Create Task
Maniphest T6674

Support video MIME types and distinguish between audio and video OGG files
Closed, DuplicatePublic
Actions

Description

Upstreaming this from https://phabricator.wikimedia.org/T75990

OGG video files and OGG audio files can both be "application/ogg".

Phabricator has "application/ogg: true" set for "files.audio-mime-types" by default. Same for "files.viewable-mime-types".
Hence in tasks that refer to an OGG video file, there is an embedded audio-only preview shown (and many screencast video files do not have sound which makes people think that something's really borken).

Assuming that content sniffing for OGG files is a bit heavy, I'd propose to set

"application/ogg" : false

by default under "files.audio-mime-types" as it can be both video and audio.

After doing so, there is no file preview in the task anymore and when clicking the link to the video file, the video is now flawlessly played in Firefox 33.
Before that I had to go to the File page, right-clicking on "View File", choose "Save as", and open the file in the native video player of my OS to watch it.

Related Objects

Event Timeline

aklapper created this task.Dec 2 2014, 3:25 PM
aklapper raised the priority of this task from to Needs Triage.
aklapper updated the task description. (Show Details)
aklapper added a project: Files.
aklapper added a subscriber: aklapper.
epriestley triaged this task as Wishlist priority.Dec 2 2014, 5:05 PM
epriestley added a subscriber: epriestley.

In the long term, adding files.video-mime-types (which would render as HTML5 <video /> ) and type-detecting OGG is probably the way to go.

Prior to that, I'd like to see more installs run into issues before removing this from the default list of audio types. I believe OGG is primarily used for audio in the wild today, and we haven't seen other reports of users running into this same audio vs video issue. If, say, 95% of installs use OGG only for audio, it seems reasonable to leave it as a default and let the other 5% configure it.

As a workaround, removing it from local configuration is reasonable. In the general case, you can also force a file to render as a link (instead of <img />, <audio /> or, in the future, <video />) with {Fxxxx, layout=link}.

epriestley renamed this task from "application/ogg" Ogv videos are interpreted as audio and do not show a preview image in tasks to Support video MIME types and distinguish between audio and video OGG files.Dec 2 2014, 5:05 PM
qgil added a comment.Dec 2 2014, 10:36 PM

Phabricator users uploading audio files in software projects? I'm not debating, just surprised.

Our ogg videos are basically screencasts showing bugs.

epriestley added a comment.Dec 2 2014, 10:50 PM

Well, anecdotally, 100% of the application/ogg files (which is to say: exactly 1 file) on this install are audio only!

{F115975, autoplay=true}

qgil added a comment.Dec 2 2014, 10:54 PM

Touché :P

mattflaschen added a subscriber: mattflaschen.EditedJan 1 2015, 1:59 AM
In T6674#85975, @epriestley wrote:

I believe OGG is primarily used for audio in the wild today, and we haven't seen other reports of users running into this same audio vs video issue. If, say, 95% of installs use OGG only for audio, it seems reasonable to leave it as a default and let the other 5% configure it.

Anecdotally, I ran into this bug while trying to view another Wikimedia-related screencast on our Phabricator.

I'm not sure how you detect mime types, but there is a way to avoid this dilemma. There are now dedicated mime types for video (video/ogg) and audio (audio/ogg).

If your library can pick this up (i.e. audio files are audio/ogg and screencasts are video/ogg), then it solves the problem. The file command on my machine outputs (for file -i):

TOC_clip.ogv: video/ogg; charset=binary
epriestley added a comment.Jan 1 2015, 2:24 AM

We use PHP's Fileinfo extension if it's available and fall back to running file, then fall back to mime_content_type() if that doesn't work either. Presumably Fileinfo will eventually update to perform this detection, although I'm not sure what that timeline might look like or exactly what's going on with it internally.

epriestley mentioned this in T6916: Allow video embed in remarkup.Jan 9 2015, 2:46 PM
quiddity added a subscriber: quiddity.Jun 22 2015, 10:39 PM

Another +1, with details:
ogg theora videos are the most common across Wikimedia (in articles, documentation, and bug-reports), partially because of the simpler licensing issues, hence many of our editors/developers are accustomed to producing/working with ogg theora video.
For example, the default output of the FOSS screencast recording software RecordMyDesktop is ogg theora, and that's what I use to record videos of hard-to-describe/reproduce bugs. (e.g. at https://phabricator.wikimedia.org/T103433 )

liuxinyu970226 added a subscriber: liuxinyu970226.Aug 22 2015, 5:17 AM
brion added a subscriber: brion.Oct 25 2015, 1:50 AM
epriestley mentioned this in T6445: Rendering SVG images.Feb 7 2016, 10:16 PM
epriestley added a comment.Jun 7 2016, 6:06 PM

I'm going to merge this into T6916. That implements a reasonable behavior for application/ogg (assume video by default, allow users to embed as audio instead with media="audio") and browser seem to do fine when audio is embedded with <video /> anyway, so I suspect we'll be in reasonable shape after that and not need to try to determine the contents of OGG containers in a more sophisticated way.

Herald added a subscriber: eadler. · View Herald TranscriptJun 7 2016, 6:06 PM
epriestley closed this task as a duplicate of T6916: Allow video embed in remarkup.Jun 7 2016, 6:06 PM
liuxinyu970226 removed a subscriber: liuxinyu970226.Jun 9 2016, 12:20 AM
mattflaschen removed a subscriber: mattflaschen.Jun 9 2016, 9:49 PM
Twilight added a subscriber: Twilight.Jul 4 2016, 12:58 PM
Twilight removed a subscriber: Twilight.Jul 16 2017, 2:12 PM
Phabricator · Built by Phacility