Chrome recording downscaled to 640x360px #372
Comments
|
By the way, if this bug is confirmed and has been here so long, I'm very surprised nobody has raised the hand before as recording with Chrome in HD is something more than expected... This issue should have high priority. |
|
I think that Chrome is already sending low resolution, so Kurento receives that and that's wht you see in the recording. In principle, Kurento doesn't do rescaling of your video... Chrome has its REMB congestion control algorithm and is also able to dynamically reduce the resolution in cases of not enough bandwidth; while Firefox doesn't have that ability. So I'd say that Chrome is rescaling your video. Look at this Kurento log: Especially the part about the input caps being |
|
A dump or quick inspection of chrome://webrtc-internals would also assert what resolution chrome is in fact sending @RaistGH. |
|
Hi, sorry for the late reply, busy time!
Yes, you're right, it was not a thing of Kurento and indeed Chrome is already sending the wrong resolution. Then I started to explore the possibility of a congestion and I read about the parameter "degradationPreference" belonging to RTCRtpSender, but both source codes of Firefox and Chrome set it to "balance", and exploring chrome://webrtc-internals, as @prlanzarin suggested, didn't show anything related to congestion. And eventually I could see that for short videos the "sscr_xxxxxxxxxx_send" group had the following kind of values: And indeed, checking the graphs I can see that Chrome is scaling the frame resolution!! So it starts with 640x360px, then upscale after few seconds to 960x540px and eventually to 1280x720px. This happens for VP8 in Windows 10 and Windows 7 and for H264 only in Windows 7 (in Windows 10 it starts directly with 1280x720px). I attach some screenshots: So as the resolution starts with 640x360px, VP8 recording on WEBM would record for the minimum resolution. That fits the KMS logs where I've seen different tracks, some with transcodifications, for the same recorded video, which was making no sense for me, but now I see every track belongs to one resolution. Therefore it's clear this is not a Kurento issue, but a Chrome one. However, before closing the issue, and in order to also have here a solution to it, do you have any idea of how to force Chrome to use a resolution from the beginning like in Windows10+H264? Bare in mind that I'm using constraints "width: {min:1280}, height:{min:720}", so it should do it already now, and it doesn't. P.S.: One of the clients is still having the same issue with Windows10+H264, and I'm a bit confused about that but I'm sure there is a reason for it, although still didn't check it out. |
|
Thank you very much for this analysis, this at a minimum will turn out as a new entry in the Troubleshooting Guide in the Kurento documentation, but it also might end up with some improvements to Kurento itself... My first thought is that maybe a new feature could be to let you "force" the recording resolution when you know the resolution or the source media, so Kurento would rescale any input which didn't match the expected size. This would solve the general issue of the browser deciding to dynamically change its output video size according to congestion-prevention heuristics. It would also have the drawback that if the browser never gets to stabilize on the expected resolution, the whole recording would be of a rescaled media, which means a performance cost (and storage too). So the idea is not perfect. Maybe there are other solutions we could explore |
|
Yeah, definitely that feature would be useful :) I thing however there is other approach that can be done from Kurento side. |
|
kurento-utils.js is provided as a small convenience layer for handling RTCPeerConnection objects, but if you are tinkering with the API and experimenting with different modes and settings, it would be very beneficial for you to skip the Kurento layer and use the browser API directly.
In any case yes, there have been some PRs to fix the outdated calls in kurento-utils and these will be merged its just that we are busy with big changes integrating latest GStreamer and improving the internal End2End test results. So I'm not sure if reviewing these changes in the JS library will happen very soon or in a few weeks.
… Sent: Wednesday, May 22, 2019 at 2:41 PM
From: "RaistGH" ***@***.***>
To: Kurento/bugtracker ***@***.***>
Cc: "Juan Navarro" ***@***.***>, Assign ***@***.***>
Subject: Re: [Kurento/bugtracker] Chrome recording downscaled to 640x360px (#372)
Yeah, definitely that feature would be useful :)
I opened [this topic](https://groups.google.com/d/topic/discuss-webrtc/CQzNjfEpcf0/discussion) in discuss-webrtc forum, but so far no replies about it.
I thing however there is other approach that can be done from Kurento side.
Right now kurento-utils.js library is using the "addStream" API, which is actually deprecated and Firefox is always warning about that. The newest versions of adapter.js shim that API to use the new "addTrack" API. I thought you would introduce this change in the version 6.10.0, but I've just checked and kurento-utilis.js is still using the old API.
Do you plan to introduce this API soon? Besides solving other problems (like the black screen in iOS after the second play that I think it can be solved using "replaceTrack"), it would also give us a chance to solve this issue because we can try the parameter "degradationPreference" belonging to RTCRtpSender class. This parameter would allow us to degrade framerate instead of resolution and maybe that could be a workaround forcing Chrome to do the initial upscale with framerate instead of resolution. Although not sure if it's gonna work.
--
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub:
#372 (comment)
|
|
Hi, Just update before closing issue. Apparently the client we had with problems also with Windows 10 was connected at the same time to the cable and to the WiFi, so it looks like that was triggering Chrome network checks and scaling up. Summarizing: |
|
until now, did anyone has a solution to fix it?. i have the same issue.
|
|
Hi, |
|
I though the problem we were having now with WEBM and VP8 was related to GStreamer >= 1.14 as it's stated in this issue. But it's not the case. Firstly because we're using KMS 6.16, so GStreamer version is the forked one "libgstreamer1.5-0/now 1.8.1-1kurento2.16.04". Secondly because we don't see that error in KMS logs. Instead we see this: I reopen the issue, as it seems like the recording is still in the low resolution but the container is not the reason. |
KMS Version:
It happens in versions at least from 6.7.2 to 6.9.0. Testing with docker container.
Ubuntu Version
Docker container:
Docker host:
Other libraries versions:
Docker version:
Client libraries
Browsers tested
System description:
Docker container. Clients can be anywhere. We use TURN but issue happens also with STUN and inside the same LAN without any STUN/TURN.
VP8 or H264 codec, it doesn't matter. Chrome recordings is always 640x360px Maximum. It doesn't happen in Firefox. It happens at least in Windows 7 and Windows 10. It doesn't happen in tests done in the same computer and browser with this test.
What steps will reproduce the problem?
What is the expected result?
Recorded video should on the resolution requested, namely 1280x720px.
What happens instead?
The recorded files is always 640x360px even when "min" constraints are used.
Media constraints are not being respected.
Does it happen with one of the tutorials?
Yes, Kurento Hello World Recorder with Generators.
However it doesn't happen with WebRTC Samples: https://webrtc.github.io/samples/src/content/getusermedia/record/
Please provide any additional information below
When using H264 additional problem with video freezing and audio continuing described in bug report #359 .
Media constraints used:_
Following several KMS logs and MediaInfo reports for different cases:
Chrome in Windows 10 with webcam HD where Firefox gets 1280x720px resolution (FF log cannot be taken at the moment due to other issues):
Resulting file analyzed with MediaInfo:
KMS Log:
Chrome in Windows 7 with webcam HD where Firefox gets 1280x720px resolution:
Resulting file analyzed with MediaInfo:
KMS Log:
Firefox in Windows 7 with webcam HD:
Resulting file analyzed with MediaInfo:
KMS Log:
Chrome in Windows 7 with webcam HD using this website (exactly the same computer and browser where Kurento fails):
Resulting file analyzed with MediaInfo:
Noticeable that the Writting Application in this case is "Chrome" while in the case of Kurento is "GStreamer Matroska muxer".
Additionally I attach a KMS log from a session done by a client with Windows 10. This client is not only getting the 640x360px problem, but also they get the video freezing of issue #359 when forzing H264 for the WebRTC Endpoint (that we thought it was only in Windows 7, but it happens in Windows 10 too).
In this log, there should be supposedly only 2 recordings, but I think the user started to record firstly one, then cancelled and deleted and then recorded the other 2. Still, there are things in the log that are pretty unclear and errors that I don't know when they happened.
The text was updated successfully, but these errors were encountered: