1258279 - Separated colours in mp4 playback

Status: RESOLVED DUPLICATE of bug 1239066

(Core :: Audio/Video: Playback, defect, P1)

Description

[Cory Bloor]

Attachment: video that plays back incorrectly

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160304114926

Steps to reproduce:

I created an mp4 video with kazam, capturing a short clip of my desktop. I then dragged and dropped the video into a Firefox window to open it. I've attached the video in question (though it seems to happen with all the videos I take).

Hardware is Ubuntu 14.04, Intel Iris Pro (Haswell), Late-2013 MacBook Pro [11,2].


Actual results:

The colours separated. Black and white looks ok, but everything else is incorrectly sized.


Expected results:

Colours should not separate.

Comment 1

[Cory Bloor]

Attachment: Playback as it appears on my machine

Comment 2

[Cory Bloor]

Attachment: Playback as I expect it to appear

Added screenshots of actual and expected behaviour.

Comment 3

[Loic]

I can't even play this video in FF45 on Win 7, the seekbar goes to end directly. I old versions of Firefox, the video appears as corrupt file. Do you encode this video with settings to be played on the web?

Comment 4

[Cory Bloor]

I'm not really an expert on this stuff, but I do know it's encoded H.264 [2]. Based on the MDN "H.264 support in Firefox" article [1] it seems that support is platform-dependant, but I believe my browser should support H.264. I opened up the console and found that canPlayH264() returns true. The definition of canPlayH264() can be found in the "Detecting Playback" section of the MDN page.

[1] https://developer.mozilla.org/en-US/Apps/Fundamentals/Audio_and_video_delivery/H.264_support_in_Firefox

[2] slavik@melchior:~$ avconv -i ~/Desktop/why-I-hate-rich-text-editors.mp4
avconv version 9.18-6:9.18-0ubuntu0.14.04.1, Copyright (c) 2000-2014 the Libav developers
  built on Mar 16 2015 13:19:10 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/slavik/Desktop/why-I-hate-rich-text-editors.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: mp42mp41isomiso2
    creation_time   : 2016-03-21 07:21:42
    encoder         : x264
  Duration: 00:00:35.46, start: 0.000000, bitrate: 46 kb/s
    Stream #0.0(eng): Video: h264 (High 4:4:4 Predictive), yuv444p, 750x350 [PAR 1:1 DAR 15:7], 45 kb/s, 15 fps, 15 tbr, 1500 tbn, 30 tbc
    Metadata:
      creation_time   : 2016-03-21 07:21:42
At least one output file must be specified

Comment 5

[Loic]

General
Complete name                            : why-I-hate-rich-text-editors.mp4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42
File size                                : 201 KiB
Duration                                 : 35s 466ms
Overall bit rate                         : 46.4 Kbps
Encoded date                             : UTC 2016-03-21 07:21:42
Tagged date                              : UTC 2016-03-21 07:21:42
Writing application                      : x264

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High 4:4:4 Predictive@L2.2
Format settings, CABAC                   : No
Format settings, ReFrames                : 1 frame
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 35s 466ms
Bit rate                                 : 45.1 Kbps
Width                                    : 750 pixels
Height                                   : 350 pixels
Display aspect ratio                     : 2.143
Frame rate mode                          : Constant
Frame rate                               : 15.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:4:4
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.011
Stream size                              : 195 KiB (97%)
Writing library                          : x264 core 142 r2389 956c8d8
Encoding settings                        : cabac=0 / ref=1 / deblock=0:0:0 / analyse=0:0 / me=dia / subme=0 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=6 / threads=4 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=150 / keyint_min=15 / scenecut=0 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=15 / ip_ratio=1.40 / aq=0
Language                                 : English
Encoded date                             : UTC 2016-03-21 07:21:42
Tagged date                              : UTC 2016-03-21 07:21:42

Comment 6

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

WFM on Linux nightly with libavcodec-ffmpeg56

Jean-Yves - seems to be broken on Windows and Mac OSX. Maybe it's an issue with 4:4:4. Can you take a look?

Comment 7

[Jean-Yves Avenard [:jya]]

we don't specifically support 4:4:4 with h264.

this should be all handled by the decoder. On mac, we request that it to output YUV422 and that's what we expect.

sounds like a bug in the Apple decoder, for which there's nothing we can do about.

Comment 8

[Jean-Yves Avenard [:jya]]

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #6)
> WFM on Linux nightly with libavcodec-ffmpeg56
> 
> Jean-Yves - seems to be broken on Windows and Mac OSX. Maybe it's an issue
> with 4:4:4. Can you take a look?

yes, the ffmpeg decoder is the only only handling yuv 444

Comment 9

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

What do we get if we request 444 from Apple? I thought there was some negotiation on Windows for the colour format.

Comment 10

[Jean-Yves Avenard [:jya]]

We never request 444. That's not how the apple decoder works. We tell it what we want out, which is currently yuv422 (uyvy) in nightly. 

Earlier version we requested YUV420p. 

Have you tried with nightly?

Comment 11

[Jean-Yves Avenard [:jya]]

Oh. I see that this is on Ubuntu. 

Yuv444 support was added in 47 there.

Comment 12

[Jean-Yves Avenard [:jya]]

Actually support added in 46