I use three presets for the Video module: mp4, webm, and ogv, each of which functions normally on its own in supported browsers. (I'm on Mac OS X 10.6 and 10.7 and using Chrome, Safari, Firefox, Opera, and Camino. IE 9 doesn't play webm either on Windows Server 2008R2.)

What I'm able to verify now is that some transcoding jobs are passed through while others are not — even though the files work in some browsers. Transcoding results from a Nikon D4 (H.264) to a Video preset for mp4 doesn't work at all in Chrome, while it works great in Safari.

BUT if I convert that file to ProRes 422 and then transcode using the same presets, Chrome will display it.

#

Other behaviors:

If I show source and click on the mp4 file it hangs; but when I click on the webm or ogv files themselves, they both play. Webm has the best performance and starts immediately, whereas ogv needs to finish loading before it will play.

I have actually seen some of these newly transcoded mp4 files play in what looks like a QuickTime wrapper, but I can't reproduced that at the moment.

[EDIT: links deleted]

Comments

Status:Active» Closed (duplicate)

The non-working video has color space yuvj420, while the working video is yuv420p. According to http://code.google.com/p/chromium/issues/detail?id=117368 , yuvj420 isn't going to be supported by Chrome anytime soon.

This issue is in fact already requested in #1490626: FFmpeg pixel-format option, which I overlooked a bit. I try to address that issue soon.

Edit: In most cases, videos not playing because of incompatible formats is not a bug in Video.js, let alone this Drupal model. Video.js is just a wrapper around the native video support of browsers. However, in this specific case, perhaps Video.js can fall back to Flash when it detects that a browser can't play a file natively.

Very sorry about the duplicate issue. And thanks for the clarification about the likely culprit being browser support and not the wrapper.

I won't keep posting here, but just to follow up, I have confirmed that the following command (referencing the file in the post above) does allow the mp4 file to play in Chrome:

ffmpeg -i _MKF1332-c_mp4_1337233067.mp4 -pix_fmt yuv420p testPixFormat.mp4

[EDIT: links deleted]

I'm unclear why this pixel format issue doesn't work in Chrome because both the other presets work. Looking at the specs for the example URL, above, they all have yuvj420p because of the source clip. So I presume this issue must be about mp4 support for yuvj420p and not just yuvj420p alone?

It's sad, though, that the Chromium post you cite talks about not supporting what is a clear trend toward the wide colorspace in high-end DSLR video. They mention a specific Canon model, but my understanding is that yuvj420p is in much wider use than they indicate, including all new Canon and Nikon models. Indeed, my rental camera in this case was the brand new flagship Nikon D4. The D4 has the same video functionality as the new D800, which is making a big splash in the entry-level medium-format market, even though Canon is still killing the DSLR video market in general. Anyway, the point is that this pixel format is growing in popularity and use by large manufacturers, so Google should should definitely support this. I suppose that in the meantime FFmpeg transcoding jobs will have to correct for this and crush the color information.

Thanks again for your expertise and quick attention to these issues.

Issue summary:View changes

Delete old, unnecessary links to content.