Modify Color Space Flag

[chris319]

Here is the ffmpeg command line:

bin\ffmpeg -y -loop 1 -t 10 -i test_pattern709.bmp -vf scale=out_color_matrix=bt709 -color_primaries bt709 -color_trc bt709 -colorspace bt709 test_pattern709.mp4

Here is the .bmp file.

[chris319]

Here is the mediainfo report for the "corrupt" .mp4 file:

Every html5 browser can play 8bit 4:2:0 AVC in Mp4 .

It is being reported as 4:4:4. Feel free to modify my ffmpeg command line to make it 4:2:0.

It is odd that a player wouldn't be able to play 4:4:4. Note that I added color-space flags, which mediainfo reports.

General
Complete name                            : D:\Archive\ffmpeg\zeranoe\CurrentVersion\test_pattern709.mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom (isom/iso2/avc1/mp41)
File size                                : 40.6 KiB
Duration                                 : 10 s 0 ms
Overall bit rate                         : 33.2 kb/s
Writing application                      : Lavf57.58.101

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High 4:4:4 Predictive@L3.1
Format settings, CABAC                   : Yes
Format settings, RefFrames               : 4 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 10 s 0 ms
Bit rate                                 : 30.2 kb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:4:4
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.001
Stream size                              : 36.8 KiB (91%)
Writing library                          : x264 core 148 r2721 72d53ab
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=4 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

[poisondeathray]

For AVC, you're not specifying pixel format, so you're encoding YUV 4:4:4, which is not supported in the majority of other browsers (chrome doesn't count, it's like a browser on steroids)

If you read the ffmpeg console output, it will highlight problem in yellow . So just add -pix_fmt yuv420p

No pixel format specified, yuv444p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.

So I guess ffmpeg "thinks" opera and FF are "outdated"

[chris319]

Firefox reads the mp4 file when encoded to 4:2:0. For the green patch:

R=28 (should be16)
G=208 (should be180)
B=21 (should be16)

[poisondeathray]

Firefox reads the mp4 file when encoded to 4:2:0. For the green patch:

R=28 (should be16)
G=208 (should be180)
B=21 (should be16)

Yes, that's old news for AVC and FF using default HTML5 - still not fixed


But it's fixed for VP9 in FF , but yet you reported different results. That needs double checking when you get a chance - with and without acceleration

[chris319]

Encoded to bt.601:

Firefox: colors +/- 3

Opera: colors +/- 2

Clearly Firefox and Opera default to bt.601, which was never intended for computer video. Where in the hell did they get the idea that 601 should be the default?

[chris319]

But it's fixed for VP9 in FF , but yet you reported different results. That needs double checking when you get a chance - with and without acceleration

They claim it's fixed and they think it's fixed. Whether it actually is fixed is anybody's guess. I very much doubt they are looking at test patterns with eyedropper programs like I am.

I'm not even sure how to turn hw accel on or off in FF. Jeff Muizelaar says they use hw accel for h264 and not for vp8-9 so I'm not going to chase after a setting which may not exist. Do you know how?

[poisondeathray]

But it's fixed for VP9 in FF , but yet you reported different results. That needs double checking when you get a chance - with and without acceleration

They claim it's fixed and they think it's fixed. Whether it actually is fixed is anybody's guess. I very much doubt they are looking at test patterns with eyedropper programs like I am.

I'm not even sure how to turn hw accel on or off in FF. Jeff Muizelaar says they use hw accel for h264 and not for vp8-9 so I'm not going to chase after a setting which may not exist. Do you know how?

Why is it a guess? Helllooo... I already tested it with eye dropper. I already posted the results and screenshots. I just tested on your bmp, in case it was a "magical" bmp. It's fixed here.

I already told you vpx is buggy for HW acceleration in FF. I already posted how to toggle hw acceleration for vp9. See a few posts above.

If you need more detailed instructions
1) type about:config in the navigator bar , hit enter
2) in the search field type "vp9"
3) media.wmf.vp9.enabled => true/false

[chris319]

Why is it a guess?

Why is WHAT a guess?

LOCAL Windows files: vp9 coded to bt.709

Firefox: colors not accurate +/- 2 (+/- 9)

[poisondeathray]

Why is it a guess?

Why is WHAT a guess?

You said "Whether it actually is fixed is anybody's guess. I very much doubt they are looking at test patterns with eyedropper programs like I am."

There is no "guessing" - It looks fixed here. I'm looking at test patterns and color pickers which show +/-2 deviation. I posted evidence, screenshots. I checked with 2 other people on different machines (Windows 7 and 8) it's fixed for them too. So I'm wondering why someone is experiencing something different. For example, is this only on Win10 FF ? Hence the need for details . What are the other differences - that's why I asked for HW accel on/off. If it's truly a "bug" then you're going to need to post the relevant details, and do the legwork if you want to be taken seriously when submitting a bug report.

LOCAL Windows files: vp9 coded to bt.709

Firefox: colors not accurate +/- 2 (+/- 9)

I will test Firefox again with various vp9 configurations.

Why does it say +/- 2 (+/- 9) ? Why not just +/-9 ? What do the parentheses indicate ?

I'll say it again, +/- 9 is "weird" . The magnitude. As you should be already aware - you should expect a larger deviation if it was a 709/601 mismatch. For example , the firefox mp4 read 208 instead of 180 for green. A delta of 28. So I am wondering if again there is some user error going on your end, or if there is another reason or combination of reasons for what you are seeing.

[chris319]

There is no "guessing" - It looks fixed here.

That's why I'm checking it myself, no offense intended.

Why does it say +/- 2 (+/- 9) ? Why not just +/-9 ? What do the parentheses indicate ?

It says "not accurate +/- 2", i.e. it is not accurate to our benchmark of +/- 2. The value in parentheses is the maximum deviation from the +/- 2 benchmark.

[poisondeathray]

There is no "guessing" - It looks fixed here.

That's why I'm checking it myself, no offense intended.

No offense taken! - Recall that I asked you to check. I want more people to check . So far you're the only one (granted , out of four LOL) , but out of those the only one on win10 .

It was declared "fixed" , if you can provide solid evidence to the contrary then post the relevant details. e.g is it a win10 ff bug, a driver issue with a certain gpu etc... it needs more workup and has to be reproducible by others or at least under a specified set of conditions


Now it's my turn - no offense, but you've made some user errors, made some incorrect assumptions - so I have to double check the accuracy of the some of the things presented by you. That +/- 9 smells fishy to me and is not solely a rec601/709 mismatch . Something else is going on

[chris319]

you've made some user errors, made some incorrect assumptions

Such as?

I didn't know about 4:4:4 not working on some browsers. What else?

The test pattern bmp is solid. I do check my work. My ffmpeg skills are not up to snuff and I'm the first to admit it. Later I will post the ffmpeg command line for bmp -> vp9 for you to check. I do have to add the 4:2:0 code to it.

No offense taken. That's what peer review is all about.

[poisondeathray]

you've made some user errors, made some incorrect assumptions

Such as?

I didn't know about 4:4:4 not working on some browsers. What else?

The test pattern bmp is solid. I do check my work. My ffmpeg skills are not up to snuff and I'm the first to admit it. Later I will post the ffmpeg command line for bmp -> vp9 for you to check. I do have to add the 4:2:0 code to it.

No offense taken. That's what peer review is all about.

I'm not here to berate you or dwell on this. It's counterproductive.


The user errors ?

ffmpeg - it's ok if you're new to ffmpeg , but how can someone trust the accuracy of your observations, if they cannot trust your ability to produce an accurate test video in the first place ?

The problem is it's not just one time - one typo with or path error is understandable, but it's a few times where you couldn't get something to work, or it didn't work properly. I posted explanations why something didn't work, and why you need to use certain arguments like -pix_fmt if you use RGB input - and soon after you forget it again... It's a bit frustrating because it feels like I'm talking to myself. You reported that your previous RGB to h264 encodes were fine in post #39; if they were, I have no idea how you could make that mistake in #59. It raises some questions and doubt in my mind about your process and observations.

People make mistakes, I do all the time. But that's why I put everything out there - upload all the sources, encodes, commandlines - so the community as a whole can double check. Yes you should double check. Use the tools at your disposal like mediainfo, ffmpeg/ffprobe.



The incorrect assumptions?

In this thread, you used YT as "evidence" for VP9 being "off" in FF - yet you were actually watching AVC! You need to double check your assumptions, and be more precise if you want to be taken seriously when filing a bug report. Details matter!

https://bugzilla.mozilla.org/show_bug.cgi?id=1300170
Youtube . Re-encoding. You used YT to provide "evidence" for Mozilla. If you're going to use YT as a demonstration to a web browser developer - you'd better have a solid understanding of how YT works with re-encoding and streaming versions. You can't just "assume"; you have to be specific about everything, including the version being streamed, what hardware and settings, browser version , driver version, etc...ie DETAILS!. Just posting a YT URL and RGB values is inadequate without the methodology and details about what was actually being watched. It's like presenting a science paper conclusion , without the assumptions or methodology used . If there are problems with the assumptions or methods, the conclusion is invalidated.




Anyways, moving on...

You said you think VP9 in FF is defaulting to Bt601, but I'm saying it cannot be only that - that there is something else going on - because you would expect a larger deviation in green , not just +/-9 . So you need to double check, and/or post everything, commandlines, sources, encodes, screenshots.

[chris319]

BT.709
URL: https://www.youtube.com/watch?v=oA3-TFJv1xI
video/mp4; codecs="avc1.4d401e"

Microsoft Edge 40.15063.0.0
White: 235;235;235
Green 16;179;14

Firefox 55.01 (64 bit)
White: 235;235;235
Green: 29;207;21

Chrome Version 60.0.3112.90 (Official Build) (64-bit)
White: 236;235;236
Green: 30;207;21

Opera 47.0.2631.39 (PGO)
White: 236;235;236
Green: 30;207;21

========================

BT.601
URL: https://www.youtube.com/watch?v=9DycR9-zeXw
video/mp4; codecs="avc1.4d401e"

Microsoft Edge 40.15063.0.0
White: 235;235;235
Green: 4;154;10

Firefox 55.01 (64 bit)
White: 235;235;235
Green: 16;179;16

Chrome Version 60.0.3112.90 (Official Build) (64-bit)
White: 236;235;236
Green: 17;179;16

Opera 47.0.2631.39 (PGO)
White: 236;235;236
Green: 17;179;16

Conclusion: For H.264,

Microsoft Edge properly defaults to sRGB (BT.709)

Firefox, Chrome and Opera default to BT.601

BT.601 was intended as a bridge between analog and digital video. It was never intended for computer video, viz.:

http://visualhotbed.blogspot.com/p/blog-page.html