default H264 quality not as good in 4.0 . What string for better profile?

Stephen_-_ · ‎05-27-2018

Hi..

I'm comparing the quality between version 4.0 and 3.5.2 with the javascript sdk on a windows chrome machine.

It is a forward stream, the resolution is 320x240, the frame rate 15, the bitrate for the video 150kbps.

There is a big difference between both versions. I believe 4.0 must be falling back to baseline profile by default.

It seems in 3.5.2 it is using profile-level-id "42e033", I think...

QUESTION:

conference.publish(stream,{video: [{codec: {name: 'h264',profile: 'high'},maxBitrate: 150}]});

^ That is what my publish line looks like. The profile part does nothing. I haven't been able to get it to do anything yet. What are the possible strings that can be used with h264?? And how do I get the quality to be exactly the same as on 3.5.2 please. I would suggest the possible strings be added to the future documentation too.

Qiujiao_W_Intel · ‎05-28-2018

Hi, Stephen, what's your subscribe option when subscribing this forward stream? Currently profile option does not support, it will be automatically set in SDP negotiating.

Stephen_-_ · ‎05-28-2018

Hi Qiujiao,

The only options I set in subscribe is "{audio: false}", as I don't want to subscribe to audio. I just want to subscribe to the stream without any re-encoding. In the documentation it states I can specify a profile for the codec, is this an error or is this functionality just incomplete at this time?

This is sad news though... It means if I upgrade to 4.0 all my users will be hit with a noticeable downgrade in quality. H264 baseline looks AWFUL, even vp8 beats it! But I need to keep the forward streams as h.264 to give compatibility for iOS safari users.

There is definitely something that has changed between 3.5.2 and 4.0 that results in H.264 looking much worse. It is not encoding in a profile higher than baseline, like before. Same browsers, same devices!

Is there no way at all to get back the quality in 3.5.2 ? :(

Could you look into it further and consider finding an option to bring it back in the next update maybe?

Qiujiao_W_Intel · ‎05-28-2018

Hi, Stephen, could you provide two snapshot for 3.5.2 and 4.0 for us to check, and also please provide the received video info snapshot in chrome://webrtc-internals for both 3.5.2 and 4.0, in our side, we did not see obvious downgrade in quality for 4.0, and also please provide your deployment and testing environment info, thanks~

Stephen_-_ · ‎05-29-2018

I have modified script2.js from 3.5.2, and index.js from 4.0 to show you the problem I am experiencing. Everything else is untouched from the basic examples.

on 3.5.2, script2.js changes:

subscribeMix defaults to false when unspecified.

myResolution defaults to {width: 320, height: 240} when unspecified.

removed the part that prevents automatic subscription to your own forward stream.

added the options to camera publish "{maxVideoBW: 150, videoCodec: 'h264'}".

added "frameRate: 15", and changed audio to false, on Woogeen.LocalStream.create .

changed default displayStream (video element) resolution to 720x540

Here is a pastebin of the full script: https://pastebin.com/iUi62UFh

on 4.0, index.js changes:

changed subscribeForward to default to true when unspecified.

changed "const videoConstraintsForCamera" to "var videoConstraintsForCamera"

then, added the line "videoConstraintsForCamera.frameRate = 15;"

and, added "videoConstraintsForCamera.resolution = {width: 320,height:240};"

then changed "conference.publish(localStream)" to "conference.publish(localStream,{audio: false,video: [{codec: {name: 'h264'},maxBitrate: 150}]})"

(edit: I have since realised that audio:false does not stop the audio being published. however setting audioConstraintsForMic to false does as it stops the mic from being accessed. I re-tried this and no difference in video quality was observed)

in RenderVideo function, I added the options "{audio: false}" to conference.subscribe

and, also changed video element resolution to 720x540

Here is a pastebin of the full script: https://pastebin.com/5REECixZ

__

All you need to do is drop those into each version, and open each webpage.

I have attached the webrtc_internals_dump . 192.168.1.118 is 3.5.2 , 192.168.1.106 is 4.0

I have installed them both in separate vmware virtual machines running on CentOS 7 and accessing them on the same machine on my windows 10 host. My chrome version is 67.

I have made a short video showing the video quality difference between the two versions. 3.5.2 is on the left, and 4.0 is on the right. Please watch in 1440p for best quality. My webcam is a logitech c920, but the same happens on my xiaomi air 13 webcam.

Video: https://youtu.be/olGIAfNZ18Y

As you can see, there are a lot of blocky artifacts when I move my hands. It's very slow to make my face visible again on 4.0.

Another side-effect of 4.0.

on 3.5.2, none of the remote streams were viewable, and broadcasting was impossible, on SOME android devices running chrome.

but on 4.0, every remote stream is viewable, and broadcasting works, on every device I have tested so far.

I believe this is because chrome android only has the baseline openH264 software encoder (i think), so on devices that it can't properly access hardware decoding and encoding, 3.5.2 fails as it can't access higher than baseline.

But on 4.0, since all the streams are baseline (I assume), both hardware accelerated and non-hardware accelerated devices can access everything fine.

I don't mind some android devices being blocked out on 3.5.2, I assume google will get around to implementing a better software codec eventually.

The quality of 240p, 15fps, with h264, without audio, at 150kbps, has been very well received by my site's users on 3.5.2 . I'm also happy that iOS users are able to access and broadcast (although they broadcast at 480p since iOS doesn't support 240p). I really wouldn't want to have to move to vp8.

I hope that was enough information :) . Looking forward to you guys finding out what the issue is! Thanks for your help.

Stephen_-_ · ‎05-29-2018

Oh and to make matters worse... I seem to be having the problem where MOST of the time the iphone can't play the h264 forward video stream from chrome (like in my example) on 4.0 . I have very rarely been able to get it to work though but can't reliably reproduce it. It would be nice if you could test that out too while you're at it. I have no issues at all with 3.5.2 though, so it seems apple iOS doesn't really like the h264 profile chrome is using as well.

Jianjun_Z_Intel · ‎05-30-2018

Hi, Stephen

The way to control bandwidth usage has been changed during 4.0 development because x-google-max-bitrate is able to constrain the bitrate for each codec. However, we observed that the actual bitrate is lower than the one specified when H.264 is the preferred codec. We're still investigating this issue. As a workaround, please set a higher value for max bitrate on Windows platform. Thanks.

Stephen_-_ · ‎05-30-2018

Thanks for your reply Jianjun,

So... x-google-max-bitrate is being used in 4.0, but in 3.5.2 something else was being used? and switching to the proprietary x-google-max-bitrate was preferred as it worked per codec rather than per stream? was 3.5.2 using b=AS instead?

I did notice the bug you describe on 3.5.2, but only for chrome android. Although it was set to 150kbps, it was only uploading at 70~ or so. Are the google chrome devs aware of these issues yet? I'll go in and check the actual bandwidth, thanks for your information. I am still experiencing issues between chrome windows h264 and iOS safari. only maybe 20% of the time iOS safari successfully plays the h264 stream, where as with 3.5.2 it always works.

YanbinZ_Intel · ‎06-14-2018

Stephen -. wrote:

Thanks for your reply Jianjun,

So... x-google-max-bitrate is being used in 4.0, but in 3.5.2 something else was being used? and switching to the proprietary x-google-max-bitrate was preferred as it worked per codec rather than per stream? was 3.5.2 using b=AS instead?

I did notice the bug you describe on 3.5.2, but only for chrome android. Although it was set to 150kbps, it was only uploading at 70~ or so. Are the google chrome devs aware of these issues yet? I'll go in and check the actual bandwidth, thanks for your information. I am still experiencing issues between chrome windows h264 and iOS safari. only maybe 20% of the time iOS safari successfully plays the h264 stream, where as with 3.5.2 it always works.

Hi, Stephen

For iOS safari and Chrome windows h264 issue, could you please provide more detail steps and configuration ? We use iOS 11.3 , Window Chrome version：Version 67.0.3396.87 , only set codec as H264 in publish option . It works fine in 4.0 version .

Stephen_-_ · ‎06-14-2018

For iOS safari and Chrome windows h264 issue, could you please provide more detail steps and configuration ?

Hi Yanbin,

I'm still building the new site, I'm still just using it over my local network which may be causing some issues.

The bug is VERY strange, and may disappear when I eventually put it on the web.

What I'm experiencing is this: When I broadcast from chrome 67 (windows) with h264, Chrome,Firefox,Edge on windows, and chrome,firefox on android all can successfully play the video, except for safari 11.3 on iOS (subscribes fine, wont play though)... However... now this is the strange part.. If I make any modifications to the javascript file on the server (as in, even add a comment!) then when i refresh the page on chrome (windows) and click broadcast, the stream is viewable on iOS safari...

So.. it's some weirdness that's happening on chrome, where if the javascript is cached rather than freshly loaded, then the stream is usually not viewable on iOS (and only iOS...) ... Quite weird indeed. Perhaps it's a weird quirk that is happening with an invalid certificate and using IP rather than a domain.

I'm going to assume the problem will fix itself when I finally deploy it on the real web, and I'll be sure to let you guys know if I see the problem start up again.