Redmine

Go MAEDA wrote:

After applying the patch, Firefox shows the following error instead of a video. The Japanese text in the screenshot says "No video with supported format and mime type found".

Oops... I thought I had tested my WebM file both in Firefox and in Chrome, but you're right, I can reproduce the issue in Firefox. Sorry for that, I should've probably taken more care to choose an example file that works :)

I had created this file with the Chrome extension Screencastify. According to ffmpeg, it's encoded with h264:

Input #0, matroska,webm, from 'Example Domain.webm':
  Metadata:
    encoder         : w69b-mediawriter
  Duration: 00:00:01.85, start: 0.000000, bitrate: 154 kb/s
    Stream #0:0(eng): Video: h264 (Constrained Baseline), yuv420p(progressive), 746x720, SAR 1:1 DAR 373:360, 1k tbr, 1k tbn, 2k tbc (default)

But apparently, h264 isn't even an allowed video codec for the WebM container format, so Firefox isn't in the wrong here. Maybe the demo files provided by webmfiles.org are more suitable? https://www.webmfiles.org/demo-files/

I've attached http://dl5.webmfiles.org/elephants-dream.webm to a test ticket in our production Redmine and manually changed the <audio> tag to a <video> tag (I don't have a dev instance ready so I can't test the patch properly), and that one seems to work fine in Firefox and in Chrome.

I've attached the patch to my dev environment and it works flawlessly with my test video made by a screen recorder. Very nice improvement!

Thanks for the fix!

Unfortunately a colleague just noticed that *.wmv is also affected; mini_mime maps it to audio/x-ms-wmv instead of video/x-ms-wmv:

wmv         audio/x-ms-wmv                                                            base64          

This time it seems more like a bug in mini_mime to me; after all, the V in WMV stands for video. The upstream MIME database that mini_mime is based on maps wmv both to audio/x-ms-wmv and video/x-ms-wmv, but mini_mime apparently only takes the first match and ignores the other one.

Should I file a separate Redmine issue for WMV, or should I file against mini_mime?

EDIT: I'm wondering whether mini_mime is still the right tool for the job, now that we've found multiple cases where its simplistic mapping of extensions to a single MIME type has proven problematic. How about using MIME::Types instead? It returns all MIME types for a given extension, and this makes it pretty easy to tell if a certain extension is capable of containing video or not:

irb(main):022:0* MIME::Types.type_for('test.wmv')
=> [#<MIME::Type: audio/x-ms-wmv>, #<MIME::Type: video/x-ms-wmv>]
irb(main):023:0> MIME::Types.type_for('test.webm')
=> [#<MIME::Type: audio/webm>, #<MIME::Type: video/webm>]
irb(main):027:0> MIME::Types.type_for('test.mp3')
=> [#<MIME::Type: audio/mpeg>]

irb(main):024:0> MIME::Types.type_for('test.wmv').find { |m| m.media_type == 'video' }
=> #<MIME::Type: video/x-ms-wmv>
irb(main):025:0> MIME::Types.type_for('test.webm').find { |m| m.media_type == 'video' }
=> #<MIME::Type: video/webm>
irb(main):026:0> MIME::Types.type_for('test.mp3').find { |m| m.media_type == 'video' }
=> nil

I agree that in these cases a video format should be prefered.

MIME::Types instead? It returns all MIME types for a given extension, and this makes it pretty easy to tell if a certain extension is capable of containing video or not

you can't determine just according to an extension like webm if it contains a video or an audio because it could contain both. It's a matter of preference.

the main reason why redmine switched from mime-types were memory savings https://github.com/mime-types/ruby-mime-types/issues/123
mini_mime shares the same db as MIME::Types but it assumes only one return. Lookups return the highest priority, nonobsolete, registered match.

Martin von Wittich could you open an issue on https://github.com/discourse/mini_mime/issues and link this ticket? thanks

Pavel Rosický wrote:

MIME::Types instead? It returns all MIME types for a given extension, and this makes it pretty easy to tell if a certain extension is capable of containing video or not

you can't determine just according to an extension like webm if it contains a video or an audio because it could contain both. It's a matter of preference.

Well, yes, but that's pretty much exactly what Redmine is trying to do here. It's true that you can only properly tell whether a given file contains a video stream if you actually look into the file, but for Redmine's purposes, just knowing whether a given file format could theoretically contain a video stream would be enough.

the main reason why redmine switched from mime-types were memory savings https://github.com/mime-types/ruby-mime-types/issues/123

OK, didn't know about that.

mini_mime shares the same db as MIME::Types but it assumes only one return. Lookups return the highest priority, nonobsolete, registered match.

Unfortunately, this very concept of mini_mime seems fundamentally broken to me. mini_mime assumes that MIME::Types' priority_compare will return the most fitting MIME type for a certain extension, ordered by some kind of priority - _but there is no concept of priority in MIME::Types@_. @priority_compare essentially just runs simplified on the MIME types and then compares them alphabetically. This means that audio will always win over video:

irb(main):005:0> MIME::Types.type_for('test.wmv').each { |m| pp m.simplified }; nil
"audio/x-ms-wmv" 
"video/x-ms-wmv" 
=> nil

So the MIME types returned by mini_mime are not the most fitting ones, as one would expect, but essentially those who come first in the alphabet. If there were such a thing as priorities in MIME::Types, this could work, but at the moment, I believe that mini_mime needs to be adapted so that it can return multiple MIME types. This would enable Redmine to properly determine whether a given file extension could in theory contain a video stream.

Martin von Wittich could you open an issue on https://github.com/discourse/mini_mime/issues and link this ticket? thanks

Done: https://github.com/discourse/mini_mime/issues/26