Steps to Reproduce Navigate to: blog.counter-strike.net/index.php/2015/09/12528/ Watch the video in the blog post (it uses a normal HTML5 <video> tag, with webm and mp4 versions) https://webcompat.com/issues/1707 Expected Behavior: The video playback is flawless and the colors in the video aren't messed up (i.e. the daggers have a mostly bright red color) Actual Behavior: At least the webm version is played back faulty by Firefox. The colors don't show properly, the daggers are mostly grey instead of red. When I actually download the video and use a local player for playback and not Firefox, the video playback is flawless and the colors are good, but inside of Firefox they show up wrong.
The video on that website is 4:4:4. It's being decoded correctly but is painted as if it is 4:2:0, leading to the chroma planes to be double normal size.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1190939
going to reopen this one and snatch it as our FFmpeg decoder fail to decode it
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
BTW, colours look goot to me with either ffvp9 or libvpx: I do get an extra green line on the side as per bug 1190939 comment 1
Summary: Colours look wrong on WebM video → VP9 4:4:4 playback (profile 1) failed to decode with FFmpeg
Created attachment 8707318 [details] [diff] [review] [ffmpeg] Add support for YUV444P pixel format in FFmpeg. We also prefer YUV444 format with decoder support it.
Attachment #8707318 - Flags: review?(gsquelart)
Comment on attachment 8707318 [details] [diff] [review] [ffmpeg] Add support for YUV444P pixel format in FFmpeg. Review of attachment 8707318 [details] [diff] [review]: ----------------------------------------------------------------- r+, but please review your check-in comment "We also prefer YUV444 format with decoder support it": 1. Grammar: I guess you meant "We also prefer YUV444 format when the decoder supports it" -- Or did you mean something else? 2. Execution: I don't see that we *prefer* YUV444, ChoosePixelFormat just returns the first accepted format found in the AVPixelFormat array. (Or do you know that 444 will always be before 420 in the list?) Happy to re-review if you need to change the code.
Attachment #8707318 - Flags: review?(gsquelart) → review+
it's the way FFmpeg works. The pixel format are in order of "quality" / best of use. First are the HW accel one if any, then software etc.. So for VP9 we can see the order is: https://dxr.mozilla.org/mozilla-central/source/media/ffvpx/libavcodec/vp9.c#468 Can see that we're missing YUV422 and YUV422P10 and P12 in there.. Will take this in a separate bug, though I'm not sure our compositor supports those and I have no idea what P10 and P12 are.
this went into the wrong bug :( https://hg.mozilla.org/integration/mozilla-inbound/rev/08ace2f8e999
See Also: → https://webcompat.com/issues/1707
(In reply to Jean-Yves Avenard [:jya] from comment #6) > Can see that we're missing YUV422 and YUV422P10 and P12 in there.. Will take > this in a separate bug, though I'm not sure our compositor supports those > and I have no idea what P10 and P12 are. Planar 10-bit and 12-bit.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 3 years ago
status-firefox46: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
You need to log in before you can comment on or make changes to this bug.