Closed Bug 1495025 Opened 6 years ago Closed 6 years ago

VP9 Profile 2 10 bits fails to decode with hardware decoder

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox64 --- fixed

People

(Reporter: jya, Assigned: jya)

References

(Blocks 1 open bug)

Details

Attachments

(8 files)

Attached video The World in HDR10.webm
Try to open a video with a machine that supports VP9 profile 2 10 bits (Intel 8th gen or nvidia 10xx and later)

You get a decoding error.

Reason for this is we always attempt to decode into a NV12 surface, and the decoder won't let you.
Priority: -- → P3
When decoding a vp9 profile 2 (10 bits), the MF_E_TRANSFORM_STREAM_CHANGE message is returned. We need to look for alternative format type other than NV12: 10/16 bits.

When using those formats, we can no longer assume that the D3D11ShareHandleImage can use NV12. So we will convert to RGBA32 on the fly via a MFT.
I find it easier to read than a function pointer making you search elsewhere to see what it's about

Depends on D7294
This allows more easily the creation of the MFT required to convert to a RGBA32 image when doing a readback.

Depends on D7295
Depends on D7296
As we do not have an IMF nor D3D11 NV12 image, we always require a full copy of the data that will deinterleave the chroma channels.

Depends on D7316
Comment on attachment 9013330 [details]
Bug 1495025 - P1. Search for alternative pixel format when stream change.

Chris Pearce (:cpearce) has approved the revision.
Attachment #9013330 - Flags: review+
Comment on attachment 9013331 [details]
Bug 1495025 - P2. Use lambda for callback.

Chris Pearce (:cpearce) has approved the revision.
Attachment #9013331 - Flags: review+
Comment on attachment 9013333 [details]
Bug 1495025 - P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage.

Chris Pearce (:cpearce) has approved the revision.
Attachment #9013333 - Flags: review+
Comment on attachment 9013378 [details]
Bug 1495025 - P5. Add Windows P010 and P016 support for software decoder

Chris Pearce (:cpearce) has approved the revision.
Attachment #9013378 - Flags: review+
Comment on attachment 9013371 [details]
Bug 1495025 - P4. Add COLOR_16 type

Nicolas Silva [:nical] has approved the revision.
Attachment #9013371 - Flags: review+
Depends on D7316
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/208624601a18
P1. Search for alternative pixel format when stream change. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/c548d816019d
P2. Use lambda for callback. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/c3b43ee1092e
P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/25895d283d47
P4. Add COLOR_16 type r=nical
https://hg.mozilla.org/integration/autoland/rev/528dbc463c22
P5. Add Windows P010 and P016 support for software decoder r=cpearce
https://hg.mozilla.org/integration/autoland/rev/263d4f722174
P6. Remove now unused paramater. r=bryce
Assignee: nobody → jyavenard
Flags: needinfo?(jyavenard)
I can't reproduce that failure with identical patches.

I don't think it had any relations with that webgl failure.

https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=203847594&revision=c54ca4cb1c36244c4e1c36239c5dc5e23130f10f

I'll reland shortly
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c62823871aca
P1. Search for alternative pixel format when stream change. r=cpearce
https://hg.mozilla.org/integration/mozilla-inbound/rev/f1afe7e2a9e3
P2. Use lambda for callback. r=cpearce
https://hg.mozilla.org/integration/mozilla-inbound/rev/7fd1f6103294
P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce
https://hg.mozilla.org/integration/mozilla-inbound/rev/9f59a50dcc6d
P4. Add COLOR_16 type r=nical
https://hg.mozilla.org/integration/mozilla-inbound/rev/68efa7588ba8
P5. Add Windows P010 and P016 support for software decoder r=cpearce
https://hg.mozilla.org/integration/mozilla-inbound/rev/24d67618f6b9
P6. Remove now unused paramater. r=bryce
That test is invalid and based on wrong premises.

Yes, the encoded image is 1920x1080

however it has a display aspect ratio set at [SAR 171:176 DAR 19:11]

So it is to be displayed as 1920x1111.

In the test we read:
    // It was found that Firefox's videoHeight doesn't report the
    // correct answer for this video resource, though the uploaded
    // video texture is the correct size.
so videoHeight must be 1111, if it's not it's wrong.

Why that test ever passed is a mystery, it shouldn't

Where does that test come from?
Flags: needinfo?(jyavenard) → needinfo?(jgilbert)
FWIW, Chrome displays it as 1920x1112
Edge displays it as 1865x1080

so all browsers have similar behaviour
Flags: needinfo?(jgilbert)
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/107add19c310
P1. Search for alternative pixel format when stream change. r=cpearce
https://hg.mozilla.org/integration/mozilla-inbound/rev/2851d7aead76
P2. Use lambda for callback. r=cpearce
https://hg.mozilla.org/integration/mozilla-inbound/rev/5e7ea76f73f3
P3. Store original IMFMediaType's subtype in D3D11SharedHandleImage. r=cpearce
https://hg.mozilla.org/integration/mozilla-inbound/rev/9818fa498ba5
P4. Add COLOR_16 type r=nical
https://hg.mozilla.org/integration/mozilla-inbound/rev/b88586cb4fdd
P5. Add Windows P010 and P016 support for software decoder r=cpearce
https://hg.mozilla.org/integration/mozilla-inbound/rev/982f91f69b39
P6. Remove now unused paramater. r=bryce
See Also: → 1497294
(In reply to Jean-Yves Avenard [:jya] from comment #17)
> That test is invalid and based on wrong premises.
> 
> Yes, the encoded image is 1920x1080
> 
> however it has a display aspect ratio set at [SAR 171:176 DAR 19:11]
> 
> So it is to be displayed as 1920x1111.
> 
> In the test we read:
>     // It was found that Firefox's videoHeight doesn't report the
>     // correct answer for this video resource, though the uploaded
>     // video texture is the correct size.
> so videoHeight must be 1111, if it's not it's wrong.
> 
> Why that test ever passed is a mystery, it shouldn't
> 
> Where does that test come from?

As the path hints, it's from the webgl2 conformance tests.
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2a9f2418655a
P7. Silence compilation warning r=mattwoodrow
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: