WebRTC and H264 stream {on VMWare}

john357smith

It seems Vivaldi (latest WIN version) can't handle H264 codec. With VP8 no problem but as most (maybe all ...) commerical streaming sites using Wowza streaming server and not bothering to detect real codec browser support Vivaldi is for those cases unusable. Chrome or Firefox no problem at all. Is there any possibility to use e.g. external Windows/System codec?

Thanks.

mib2berlin

@john357smith
Hi, Vivaldi use the Windows codecs, Chrome and Firefox are shipped with own codecs.
Do you have Windows 10 N or KN?
After update Windows it delete the media feature pack and it is needed to install or update again.

https://support.microsoft.com/en-us/help/3010081/media-feature-pack-for-windows-10-n-and-windows-10-kn-editions

Please add your Vivaldi version (Stable/Snapshot) and a link to a video page.

Cheers, mib

john357smith

I have standard Windows 10 (no "N" version ...). But anyway tried to install KB3099229 but no change.

You can use standard test site: https://webrtc.github.io/samples/src/content/peerconnection/change-codecs/

Select H264, check after "call" that really H264 was selected (text will appear below buttons) and after that I can't see anything on right window. With VP8/VP9 no problems. Checked in vivaldi://webrtc-internals - data are coming but no picture ...

Thanks.

Pathduck

@john357smith That WebRTC test site works fine for me on my laptop running Win10, I tested with a couple of the available H264 stream types. Tested in both 3.7 Stable and 3.8 Snapshot.

Check if the tests on this page work on your system:
http://demo.nimius.net/video_test/
All the tests work for me except the AVI test (which makes sense).

Go through all the troubleshooting steps:
https://help.vivaldi.com/article/troubleshooting-issues/

john357smith

@Pathduck that's very strange. I'm using WIN10 installation on my VMWare machine with clean Vivaldi installation.

The site you pasted uses just primitive inline VIDEO tag with media file (not even using GetUserMedia ...) and yes it works all except MPEG4/AVI example.

I enabled logging, this is what I found:

[5644:4064:0405/154309.934:WARNING:internal_decoder_factory.cc(59)] Trying to create decoder for unsupported format. Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=4d0015 }

So there is H264 codec in system and Vivaldi can use it but not for WebRTC ..

Pathduck

@john357smith Well, have you tried without a virtual machine?

The site you pasted uses just primitive inline VIDEO tag

Yes, but your initial assertion was:
"It seems Vivaldi (latest WIN version) can't handle H264 codec."
So that's obviously false.

I did a couple more tests on the WebRTC site, apparently if I choose the two last H264 options (4D001f, 64001f), it will fall back to using VP8, but I still get video+audio.

In your log it says:
level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=4d0015
Where does the 4d0015 come from? That's not one of the options I have there.

john357smith

Yes, but your initial assertion was:
"It seems Vivaldi (latest WIN version) can't handle H264 codec."
So that's obviously false.

Subject of this Topic is "WebRTC and H264 stream" so it's all about WebRTC API.

No I have not tried it outside of VMware and I don't see a reason for it - both VP8 and VP9 works without any problem so problem is not with VMWare but somewhere else ...

In my list of options I see 2x 42001f, 2x 42e01f, 4d001f and 64001f so 6 H264 options to select from. None of them works. But log still says (selected the first 42001f):

[7880:6836:0406/132948.152:WARNING:internal_decoder_factory.cc(59)] Trying to create decoder for unsupported format. Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=4d0015 }
[7880:6836:0406/132948.154:WARNING:internal_decoder_factory.cc(59)] Trying to create decoder for unsupported format. Codec name: H264, parameters: { level-asymmetry-allowed=1 packetization-mode=1 profile-level-id=640015 }

And Offer and Answer contain the correct profiles from combo:

Offer from pc1:

a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:104 H264/90000
a=rtcp-fb:104 goog-remb
a=rtcp-fb:104 transport-cc
a=rtcp-fb:104 ccm fir
a=rtcp-fb:104 nack
a=rtcp-fb:104 nack pli
a=fmtp:104 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:106 H264/90000
a=rtcp-fb:106 goog-remb
a=rtcp-fb:106 transport-cc
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack
a=rtcp-fb:106 nack pli
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f

Answer from pc:
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:104 H264/90000
a=rtcp-fb:104 goog-remb
a=rtcp-fb:104 transport-cc
a=rtcp-fb:104 ccm fir
a=rtcp-fb:104 nack
a=rtcp-fb:104 nack pli
a=fmtp:104 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:106 H264/90000
a=rtcp-fb:106 goog-remb
a=rtcp-fb:106 transport-cc
a=rtcp-fb:106 ccm fir
a=rtcp-fb:106 nack
a=rtcp-fb:106 nack pli
a=fmtp:106 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f

But I found following line in my log (one long line):

[7880:6836:0406/132948.139:INFO:video_receive_stream2.cc(240)] VideoReceiveStream2: {decoders: [{payload_type: 96, payload_name: VP8, codec_params: {}}, {payload_type: 98, payload_name: VP9, codec_params: {profile-id: 0}}, {payload_type: 100, payload_name: VP9, codec_params: {profile-id: 2}}, {payload_type: 102, payload_name: VP9, codec_params: {profile-id: 1}}, {payload_type: 104, payload_name: H264, codec_params: {level-asymmetry-allowed: 1, packetization-mode: 1, profile-level-id: 42001f}}, {payload_type: 106, payload_name: H264, codec_params: {level-asymmetry-allowed: 1, packetization-mode: 0, profile-level-id: 42001f}}, {payload_type: 108, payload_name: H264, codec_params: {level-asymmetry-allowed: 1, packetization-mode: 1, profile-level-id: 42e01f}}, {payload_type: 110, payload_name: H264, codec_params: {level-asymmetry-allowed: 1, packetization-mode: 0, profile-level-id: 42e01f}}, {payload_type: 112, payload_name: H264, codec_params: {level-asymmetry-allowed: 1, packetization-mode: 1, profile-level-id: 4d0015}}, {payload_type: 114, payload_name: H264, codec_params: {level-asymmetry-allowed: 1, packetization-mode: 1, profile-level-id: 640015}}], rtp: {remote_ssrc: 1111203507, local_ssrc: 1, rtcp_mode: RtcpMode::kReducedSize, rtcp_xr: {receiver_reference_time_report: off}, transport_cc: on, lntf: {enabled: false}, nack: {rtp_history_ms: 1000}, ulpfec_payload_type: 118, red_type: 116, rtx_ssrc: 4286913351, rtx_payload_types: {97 (pt) -> 96 (apt), 99 (pt) -> 98 (apt), 101 (pt) -> 100 (apt), 103 (pt) -> 102 (apt), 105 (pt) -> 104 (apt), 107 (pt) -> 106 (apt), 109 (pt) -> 108 (apt), 111 (pt) -> 110 (apt), 113 (pt) -> 112 (apt), 115 (pt) -> 114 (apt), 117 (pt) -> 116 (apt), }, raw_payload_types: {}, extensions: []}, renderer: (renderer), render_delay_ms: 10, sync_group: Zp7GjJsld4KUGkJtqGK58s8wH7gICKzbRtZM, target_delay_ms: 0}

So it seems first 4 H264 profiles match but Vivaldi ignores them and for some reason takes the last 2 lines (4d0015 and 640015) which don't match SDP ...

Pathduck

@john357smith My knowledge of WebRTC is not good enough to understand what goes on in your system.

problem is not with VMWare but somewhere else

How do you know? You won't know before you actually test all possibilities.

For me the demo site works, so I suggest once again you go through the troubleshooting steps I linked, including disabling all extensions and trying in a clean profile.

john357smith

@Pathduck can you post here your full chrome_debug.log? I would like to see what differences are there.

Thanks.

Pathduck

@john357smith Hi, I would, but how do I turn that on?

john357smith

Run this command in directory where Vivaldi is installed (directory with vivaldi.exe):

vivaldi -enable-logging --v=1

And then chrome_debug.log will be placed somewhere at "\Users\[your user]\AppData\Local\Vivaldi\User Data\chrome_debug.log". Or just try to search the filename.

Thanks.

Pathduck

@john357smith OK I uploaded one here:
https://wormhole.app/w88j0#-0vaX4x2Z8IfQWA45dHo-A
No idea how to read that log, I leave that up to you

john357smith

Thanks a lot, it's very interesting - in my log I see only these lines:

[4884:4940:0410/171252.680:INFO:generic_decoder.cc(241)] Decoder implementation: DecoderInfo { prefers_late_decoding = implementation_name = 'FFmpeg', is_hardware_accelerated = false }

While in your log are:

[3260:6540:0410/172430.913:INFO:generic_decoder.cc(241)] Decoder implementation: DecoderInfo { prefers_late_decoding = implementation_name = 'ExternalDecoder', is_hardware_accelerated = false } 
[3260:6540:0410/172456.749:INFO:generic_decoder.cc(241)] Decoder implementation: DecoderInfo { prefers_late_decoding = implementation_name = 'libvpx', is_hardware_accelerated = false }

I need to dig in more ...

Thanks.

Pathduck

@john357smith Yes, I thought Vivaldi would have no need to use external decoders as FFmpeg should be able to decode almost anything, maybe apart from VP.

Well, if you ever figure it out let us know, it would be interesting to know the cause

And obviously, if you're able to reproduce this in a consistent manner in a clean profile, there nothing stopping you making a bug report with all the relevant details here:
https://vivaldi.com/bugreport/
Maybe someone on the team can reproduce it.