Issue 1628 in webm: WebM container with H.264 video

[quanxunz… via monorail]

Status: Unconfirmed
Owner: ----

New issue 1628 by quanxunz...@gmail.com: WebM container with H.264 video
https://bugs.chromium.org/p/webm/issues/detail?id=1628

On the guidelines of WebM, only VP8 and VP9 codec are mentioned: https://www.webmproject.org/docs/container/ so many implementations only handles these codecs.

However, Chrome added support for generating WebM file with H.264 video inside (see https://bugs.chromium.org/p/chromium/issues/detail?id=601636), which causes compatibility issue when users try to open such WebM file in other implementations (see for example https://bugzilla.mozilla.org/show_bug.cgi?id=1551765).

Should WebM include H.264 as a supported video codec in the official document? If not, should Chrome's support be considered a spec violation, and thus be removed?

(This is purely copied from https://bugs.chromium.org/p/webm/issues/detail?id=1627 because I don't want to use that account for reporting. Please remove / close that one, thanks.)

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[tomfine… via monorail]

Comment #2 on issue 1628 by tomfi...@google.com: WebM container with H.264 video
https://bugs.chromium.org/p/webm/issues/detail?id=1628#c2

Please attach a sample file or provide a link.

I'm leaning toward marking this WontFix because Working As Intended. The DocType[1,2] for such files is Matroska and not WebM. The library (mkvmuxer aka libwebm) cannot control output file names. If there's a bug here it's related to the file extensions and mimetypes used by MediaRecorder implementations that exist in the wild (and possibly MediaRecorder itself).

[1] https://www.webmproject.org/docs/container/
[2] https://chromium.googlesource.com/webm/libwebm/+/refs/heads/master/mkvmuxer/mkvmuxer.cc#4190

[tomfine… via monorail]

Updates:
Cc: mca...@chromium.org

Comment #3 on issue 1628 by tomfi...@google.com: WebM container with H.264 video
https://bugs.chromium.org/p/webm/issues/detail?id=1628#c3

(No comment was entered for this change.)

[quanxunz… via monorail]

Comment #4 on issue 1628 by quanxunz...@gmail.com: WebM container with H.264 video
https://bugs.chromium.org/p/webm/issues/detail?id=1628#c4

Okay, so... Chromium supports playing Matroska as far as it uses .webm as its extension (or maybe video/webm as its mimetype)... That's... interesting...

[quanxunz… via monorail]

Comment #5 on issue 1628 by quanxunz...@gmail.com: WebM container with H.264 video
https://bugs.chromium.org/p/webm/issues/detail?id=1628#c5

Filed an issue to Chromium for this: https://bugs.chromium.org/p/chromium/issues/detail?id=967100

[tomfine… via monorail]

Updates:
Status: WontFix

Comment #6 on issue 1628 by tomfi...@google.com: WebM container with H.264 video
https://bugs.chromium.org/p/webm/issues/detail?id=1628#c6

The file extension isn't directly informative to the client requesting the content. As you're probably aware it maps to the mimetype on the HTTP server, but the client is free to do whatever it pleases with the content received in the HTTP response.

If the browser receiving the content knows how to demux and decode H.264 video from the container then it's almost certainly going to play the content. In this case the mimetype does not agree with the Matroska doctype, but I'm not really seeing any harm in this situation.

I suppose a browser could be configured in a pedantic mode that forces it to reject such content, but that doesn't seem user friendly to the vast majority of people attempting to play the content. Such a feature would likely only be useful to developers.