Bug 1459526 Comment 17 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

This is being investigated. I appreciate it is frustrating to run into this issue, and comments that provide information on cases where this occurs and where it can be tested are useful. Aggressive comments and/or demands are not going to increase peoples motivation, and are not welcome. Please refer to the [etiquette](https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) guidelines if you're uncertain.

---

On the dev side this seems like it should per codec or container. In some cases the codec string will contain info on if the colours are full range, but codec strings are going to be less reliable than info in the codec or container.

The h264 case sounds like the most pressing case. Annex E of the h264 spec discusses the 'Video usability information' structure, which includes the `video_full_range_flag` flag. This flag seems like the governing info for if we consider the colour space we're dealing with is full range or not. Annex E defines the specific values for use with different matrix coefficients/colour spaces.

We appear to have handling for parsing this information already[0], this is used to populate metadata elsewhere[1]. It seems like there's gfx support for 8bit colour (i.e. not HDR) with full range. However, there appears to be a missing link in the chain somewhere. I'll see if I can figure out where that is.

Holding NI while I investigate further.

[0] https://searchfox.org/mozilla-central/rev/f82d5c549f046cb64ce5602bfd894b7ae807c8f8/dom/media/platforms/agnostic/bytestreams/H264.cpp#870
[1] https://searchfox.org/mozilla-central/rev/f82d5c549f046cb64ce5602bfd894b7ae807c8f8/dom/media/platforms/wrappers/MediaChangeMonitor.cpp#134-136
This is being investigated. I appreciate it is frustrating to run into this issue, and comments that provide information on cases where this occurs and where it can be tested are useful. Aggressive comments and/or demands are not going to increase peoples motivation, and are not welcome. Please refer to the [etiquette](https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) guidelines if you're uncertain.

---

On the dev side this seems like it the check needs to be per codec or container. In some cases the codec string will contain info on if the colours are full range, but codec strings are going to be less reliable than info in the codec or container.

The h264 case sounds like the most pressing case. Annex E of the h264 spec discusses the 'Video usability information' structure, which includes the `video_full_range_flag` flag. This flag seems like the governing info for if we consider the colour space we're dealing with is full range or not. Annex E defines the specific values for use with different matrix coefficients/colour spaces.

We appear to have handling for parsing this information already[0], this is used to populate metadata elsewhere[1]. It seems like there's gfx support for 8bit colour (i.e. not HDR) with full range. However, there appears to be a missing link in the chain somewhere. I'll see if I can figure out where that is.

Holding NI while I investigate further.

[0] https://searchfox.org/mozilla-central/rev/f82d5c549f046cb64ce5602bfd894b7ae807c8f8/dom/media/platforms/agnostic/bytestreams/H264.cpp#870
[1] https://searchfox.org/mozilla-central/rev/f82d5c549f046cb64ce5602bfd894b7ae807c8f8/dom/media/platforms/wrappers/MediaChangeMonitor.cpp#134-136
This is being investigated. I appreciate it is frustrating to run into this issue, and comments that provide information on cases where this occurs and where it can be tested are useful. Aggressive comments and/or demands are not going to increase peoples motivation, and are not welcome. Please refer to the [etiquette](https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) guidelines if you're uncertain.

---

On the dev side this seems like the check needs to be per codec or container. In some cases the codec string will contain info on if the colours are full range, but codec strings are going to be less reliable than info in the codec or container.

The h264 case sounds like the most pressing case. Annex E of the h264 spec discusses the 'Video usability information' structure, which includes the `video_full_range_flag` flag. This flag seems like the governing info for if we consider the colour space we're dealing with is full range or not. Annex E defines the specific values for use with different matrix coefficients/colour spaces.

We appear to have handling for parsing this information already[0], this is used to populate metadata elsewhere[1]. It seems like there's gfx support for 8bit colour (i.e. not HDR) with full range. However, there appears to be a missing link in the chain somewhere. I'll see if I can figure out where that is.

Holding NI while I investigate further.

[0] https://searchfox.org/mozilla-central/rev/f82d5c549f046cb64ce5602bfd894b7ae807c8f8/dom/media/platforms/agnostic/bytestreams/H264.cpp#870
[1] https://searchfox.org/mozilla-central/rev/f82d5c549f046cb64ce5602bfd894b7ae807c8f8/dom/media/platforms/wrappers/MediaChangeMonitor.cpp#134-136

Back to Bug 1459526 Comment 17