H264 for Chrome under Windows 7

441 views
Skip to first unread message

carlo...@gmail.com

unread,
Apr 10, 2019, 2:34:49 AM4/10/19
to discuss-webrtc
Hi,

I'd like to confirm from some Chrome Devs if Chrome is using Windows 7 H264 encoder in order to encode H264 WebRTC streams. Isn't Chrome using openh264 instead?

We're having issues with video freezing (but audio continues) when recording HD videos in H264 with Chrome, only with Windows 7. However Windows 10 and Linux work. Firefox works always with no issues.

Thanks.

Regards

Alexander Abagian

unread,
Apr 10, 2019, 8:17:42 AM4/10/19
to discuss-webrtc
I encovered that Chrome WebRTC uses hardware H264 encoder if it's available (this can be disabled in chrome:://flags) for some additional profiles.

For example, my Windows 10 - notebook (Core I7, nVidia) with shows the following in local SDP :

a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032

Last two profiles came from hardware codec.

But the desktop (Core I5) - these :

a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f

It's OpenH264.

Try check what has been negotiated in you app.

carlo...@gmail.com

unread,
Apr 10, 2019, 3:46:19 PM4/10/19
to discuss-webrtc
Thanks for your reply Alexander.

What I'm getting in the SDP offer are only the ones you say are OpenH264. And indeed, if I check chrome://flags, hardware encoders are among the Unavailable options.

So it looks like Chrome is using OpenH264, but then... why it only breaks with Windows 7? (and videos over 640x360px) Is there anything else that Chrome can be using from Windows 7 that doesn't use (or it's different) in Windows 10? Firefox doesn't have this issue.

Thanks.

Regards.

carlo...@gmail.com

unread,
Apr 11, 2019, 12:20:17 PM4/11/19
to discuss-webrtc
Hi Alexander,

I was checking a bit more about the profile-level-id. That doesn't mean that it uses OpenH264, just that it uses H264 spec. So Chrome still is maybe using H264 codec provided with Windows 7, not necessarily OpenH264. Isn't?

Thanks.

Regards.

Alexander Abagian

unread,
Apr 15, 2019, 9:37:09 PM4/15/19
to discuss-webrtc
Actually, I've never heard that any Windows version provides h264 out-of-the box. I think it is incorporated in Edge or a Microsoft media player, but could not be exposed to third-party app. BTW my desktop is also Windows 7, and if the profiles the same, there's no visible difference in the video.

Try to switch off encryption in Chrome if another party could also do it (look for -disable-webrtc-encryption) and investigate the traffic. Fippo's webrtc-dump-importer could also help to dig the dump.

Juan Navarro

unread,
Apr 17, 2019, 1:52:38 PM4/17/19
to discuss-webrtc
I've found this, which hopefully reflects the current situation as of today:

Chrome uses OpenH264 (same lib as Firefox uses) for encoding, and FFmpeg (which is already used elsewhere in Chrome) for decoding.

Feature page: https://www.chromestatus.com/feature/6417796455989248

Since Chrome 52.

Bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=500605


Carlos N

unread,
May 15, 2019, 5:07:14 AM5/15/19
to discuss-webrtc
Thanks for the help.

I've eventually found out that it's not a problem with the profiles, but a problem with initial Chrome video scalation. I'm opening a new thread here:
Reply all
Reply to author
Forward
0 new messages