Closed Bug 1505284 Opened 6 years ago Closed 5 years ago

Use H264 MediaDataDecoder for webrtc calls

Categories

(Core :: WebRTC: Audio/Video, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla65
Tracking Status
firefox65 --- fixed

People

(Reporter: jya, Assigned: jya)

References

Details

Attachments

(5 files)

It is now possible to use the system's H264 decoder for webrtc calls, we should enable it by default.

It allows for low-latency, typically hardware accelerated calls with webrtc peers using h264.
No longer blocks: 1492038
Great. How about we flip the pref for Nightly users on Mac?

The other question is if with this change then H264 with hardware should be preferred over VP8?

I assume we don't have any means to switch dynamically in the middle of the call if the hardware decoder fails. It would be great if we would have the ability to fall back to available software decoders in that case.
(In reply to Nils Ohlmeier [:drno] from comment #1)
> Great. How about we flip the pref for Nightly users on Mac?
> 

it works on all platform.

> The other question is if with this change then H264 with hardware should be
> preferred over VP8?

H264 is almost universally HW accelerated on both mac and windows, on linux it will still be SW.

VP8 can be HW accelerated only on recent Intel (generation 6 and later) and on windows only.

> 
> I assume we don't have any means to switch dynamically in the middle of the
> call if the hardware decoder fails. It would be great if we would have the
> ability to fall back to available software decoders in that case.

Actually, you can. If the HW decoder fail we have mechanism to retry (requiring a keyframe) and fallback to SW automatically.
(In reply to Nils Ohlmeier [:drno] from comment #1)
> Great. How about we flip the pref for Nightly users on Mac?
> 
> The other question is if with this change then H264 with hardware should be
> preferred over VP8?

I actually have a bug open to make VP9 the default if the machine has HW decoders (bug 1392962)
See Also: → 1492038
Rank: 25
Priority: -- → P2
All H264 system's decoders now handle low latency mode and are typically hardware accelerated.

Depends on D12431
See Also: → 1508677
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/05fd55926206
P1. Use ffmpeg decoder for h264 in low latency mode. r=padenot
https://hg.mozilla.org/integration/autoland/rev/1d3eb26cfeac
P2. Use system's h264 decoder for webrtc call. r=padenot
There were also crashes on [@ mozilla::WMFDecoderModule::Init()]

Log link: https://treeherder.mozilla.org/logviewer.html#?job_id=212963900&repo=autoland&lineNumber=22073
Also triggered a mda perma failure on test_peerConnection_basicH264Video.html

Log link: https://treeherder.mozilla.org/logviewer.html#?job_id=212964686&repo=autoland&lineNumber=20007
Attachment #9026401 - Attachment description: Bug 1505284 - P2. Use system's h264 decoder for webrtc call. r?padenot! → Bug 1505284 - P2. Use system's h264 decoder for webrtc call. r?padenot! All H264 system's decoders now handle low latency mode and are typically hardware accelerated.
While typically those will always be, when using through gtest it won't.

Depends on D12432
See Also: → 1509012
The fake H.264 GMP encoder creates dummy frames that can't be decoded by anything but the fake GMP decoder.

Depends on D12519
Attachment #9026681 - Attachment description: Bug 1505284 - P4. Don't use real H264 decoder with fake GMP encoder. r?dminor! → Bug 1505284 - P5. Don't use real H264 decoder with fake GMP encoder. r?dminor!
So that we can disable just the H264 decoders while allowing VP8 or VP9.
Attachment #9026681 - Attachment description: Bug 1505284 - P5. Don't use real H264 decoder with fake GMP encoder. r?dminor! → Bug 1505284 - P5. Don't use real H264 decoder with fake GMP encoder. r?dminor! The fake H.264 GMP encoder creates dummy frames that can't be decoded by anything but the fake GMP decoder.
Attachment #9026401 - Attachment description: Bug 1505284 - P2. Use system's h264 decoder for webrtc call. r?padenot! All H264 system's decoders now handle low latency mode and are typically hardware accelerated. → Bug 1505284 - P2. Use system's h264 decoder for webrtc call. r?padenot!
Attachment #9026681 - Attachment description: Bug 1505284 - P5. Don't use real H264 decoder with fake GMP encoder. r?dminor! The fake H.264 GMP encoder creates dummy frames that can't be decoded by anything but the fake GMP decoder. → Bug 1505284 - P5. Don't use real H264 decoder with fake GMP encoder. r?dminor!
Attachment #9026400 - Attachment description: Bug 1505284 - P1. Use ffmpeg decoder for h264 in low latency mode. r?padenot! → Bug 1505284 - P1. Use ffmpeg decoder for h264 in low latency mode. r=padenot
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/92a1eb79716c
P1. Use ffmpeg decoder for h264 in low latency mode. r=padenot
https://hg.mozilla.org/integration/autoland/rev/e89c4b9db24d
P2. Use system's h264 decoder for webrtc call. r=padenot
https://hg.mozilla.org/integration/autoland/rev/99321f96fd0c
P3. Ensure gfxVars and gfxPrefs are always initialized when using PDMFactory. r=gerald
https://hg.mozilla.org/integration/autoland/rev/7f62a35b4171
P4. Split preferences to enable WebRTC with MediaDataDecoder. r=padenot
https://hg.mozilla.org/integration/autoland/rev/95d5bb21c934
P5. Don't use real H264 decoder with fake GMP encoder. r=dminor
Flags: needinfo?(jyavenard)
Blocks: 1525230
Regressions: 1538508
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: