Open RaistGH opened 5 years ago
RaistGH
commented
5 years ago 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.
j1elo
commented
5 years ago 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:
1:38:35.720682531 1 0x7f693c0b4590 INFO agnosticbin kmsagnosticbin.c:889:input_bin_src_caps_probe:<kmsagnosticbin2-6> Set input caps: video/x-raw, format=(string)I420, width=(int)640, height=(int)360, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)10/1Especially the part about the input caps being width=(int)640, height=(int)360, that seems to confirm it's not a Kurento issue, thus that's why nobody has raised the hand before...
prlanzarin
commented
5 years ago A dump or quick inspection of chrome://webrtc-internals would also assert what resolution chrome is in fact sending @RaistGH.
RaistGH
commented
5 years ago Hi, sorry for the late reply, busy time! So well, I eventually got the reason of all of this, the problem is maybe to find a solution. First I answer your comments:
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:
1:38:35.720682531 1 0x7f693c0b4590 INFO agnosticbin kmsagnosticbin.c:889:input_bin_src_caps_probe:<kmsagnosticbin2-6> Set input caps: video/x-raw, format=(string)I420, width=(int)640, height=(int)360, interlace-mode=(string)progressive, pixel-aspect-ratio=(fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)10/1Especially the part about the input caps being
width=(int)640, height=(int)360, that seems to confirm it's not a Kurento issue, thus that's why nobody has raised the hand before...
Yes, you're right, it was not a thing of Kurento and indeed Chrome is already sending the wrong resolution. Just a note: Firefox does support REMB, what it doesn't support still is transport-cc. So I started to test that way, mangling the SDP offer removing the transport-cc system. But no luck. I tried also removing REMB, but same result.
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: googFrameHeightInput 720 googFrameHeightSent 540 googFrameWidthInput 1280 googFrameWidthSent 960
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: https://dev.spiquer.com/shares/VP8Resolution.png https://dev.spiquer.com/shares/H264Win7Resolution.png https://dev.spiquer.com/shares/H264Win10Resolution.png https://dev.spiquer.com/shares/VP8ResolutionFPShigh.png This also explains the issue #359 , since it seems that those 6 seconds are the scaling time, that's when Chrome decides the connection is good enough to scale up. If I allow higher FPS then the escalation is faster as you can see in the last screenshot.
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. In the case of H264 on MP4, the codec simply cannot continue storing the video with different resolution and only with the audio.
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.
j1elo
commented
5 years ago 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
RaistGH
commented
5 years ago Yeah, definitely that feature would be useful :) I opened this topic 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.
j1elo
commented
5 years ago 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" notifications@github.com To: Kurento/bugtracker bugtracker@noreply.github.com Cc: "Juan Navarro" juan.navarro@gmx.es, Assign assign@noreply.github.com Subject: Re: [Kurento/bugtracker] Chrome recording downscaled to 640x360px (#372)
Yeah, definitely that feature would be useful :) I opened this topic 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: https://github.com/Kurento/bugtracker/issues/372#issuecomment-494785217
RaistGH
commented
5 years ago 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: Windows 10 + H264 works (while network conditions are good enough). Windows 10 + VP8 doesn't work. Windows 7 doesn't work.
vanhungoz
commented
4 years ago until now, did anyone has a solution to fix it?. i have the same issue. i use react-native-webrtc in client. when i try minWidth and minHeight is really small. it can work but the resolution is really slow when i set minWidth and minHeight is bigger, the Error log appears. the recording is stopped.
2020-06-13T08:19:42,321134 1397 0x00007f10f75a3700 warning basesrc gstbasesrc.c:2948 gst_base_src_loop()
error: Internal data flow error. 2020-06-13T08:19:42,321183 1397 0x00007f10f75a3700 warning basesrc gstbasesrc.c:2948 gst_base_src_loop() error: streaming task paused, reason not-negotiated (-4) 2020-06-13T08:19:42,321269 1397 0x00007f10f75a3700 warning structure gststructure.c:1935 priv_gst_structure_append_to_gstring() No value transform to serialize field 'gerror' of type 'GError' 2020-06-13T08:19:42,321261 1397 0x00007f10f75a3700 warning recorderendpoint kmsrecorderendpoint.c:1969 bus_sync_signal_handler() Message error message: 0x7f1120017930, time 99:99:99.999999999, seq-num 12140, element 'videoSrc', GstMessageError, gerror=(GError)NULL, debug=(string)"gstbasesrc.c(2948):\ gst_base_src_loop\ ():\ /GstPipeline:pipeline9/GstAppSrc:videoSrc:\012streaming\ task\ paused\,\ reason\ not-negotiated\ (-4)"; 2020-06-13T08:19:42,321866 1397 0x00007f10f75a3700 warning structure gststructure.c:1935 priv_gst_structure_append_to_gstring() No value transform to serialize field 'gerror' of type 'GError' 2020-06-13T08:19:42,321856 1397 0x00007f10f75a3700 warning recorderendpoint kmsrecorderendpoint.c:1973 bus_sync_signal_handler() Error: error message: 0x7f1120017930, time 99:99:99.999999999, seq-num 12140, element 'videoSrc', GstMessageError, gerror=(GError)NULL, debug=(string)"gstbasesrc.c(2948):\ gst_base_src_loop\ ():\ /GstPipeline:pipeline9/GstAppSrc:videoSrc:\012streaming\ task\ paused\,\ reason\ not-negotiated\ (-4)"; 2020-06-13T08:19:42,322103 1397 0x00007f10f75a3700 warning qtmux gstqtmux.c:4123 gst_qt_mux_video_sink_set_caps() pad video_0 refused renegotiation to video/x-h264, codec_data=(buffer)0164000dffe100176764000dacb40905b60220000003002ee6b28001e2855401000468ef3cb0, stream-format=(string)avc, alignment=(string)au, level=(string)1.3, profile=(string)high, width=(int)288, height=(int)352, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)0/1 2020-06-13T08:19:42,322204 1397 0x00007f10f75a3700 warning qtmux gstqtmux.c:4123 gst_qt_mux_video_sink_set_caps() pad video_0 refused renegotiation to video/x-h264, codec_data=(buffer)0164000dffe100176764000dacb40905b60220000003002ee6b28001e2855401000468ef3cb0, stream-format=(string)avc, alignment=(string)au, level=(string)1.3, profile=(string)high, width=(int)288, height=(int)352, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)0/1 2020-06-13T08:19:42,322351 1397 0x00007f114629a240 error KurentoMediaPipelineImpl MediaPipelineImpl.cpp:69 processBusMessage() Error code 1: 'Internal data flow error.', element: kmsrecorderendpoint4, parent: pipeline8 2020-06-13T08:19:42,322420 1397 0x00007f114629a240 error KurentoMediaPipelineImpl MediaPipelineImpl.cpp:72 processBusMessage() Debugging info: gstbasesrc.c(2948): gst_base_src_loop (): /GstPipeline:pipeline9/GstAppSrc:videoSrc: streaming task paused, reason not-negotiated (-4) 2020-06-13T08:19:42,322492 1397 0x00007f114629a240 error KurentoMediaElementImpl MediaElementImpl.cpp:266 processBusMessage() Error code 1: 'Internal data flow error.', element: kmsrecorderendpoint4, parent: kmsrecorderendpoint4 2020-06-13T08:19:42,322572 1397 0x00007f114629a240 error KurentoMediaElementImpl MediaElementImpl.cpp:269 processBusMessage() Debugging info: gstbasesrc.c(2948): gst_base_src_loop (): /GstPipeline:pipeline9/GstAppSrc:videoSrc: streaming task paused, reason not-negotiated (-4) 2020-06-13T08:19:48,185070 1397 0x00007f10f7da4700 warning rtpsource rtpsource.c:1147 update_receiver_stats() duplicate or reordered packet (seqnr 24439, expected 24441) 2020-06-13T08:19:52,164616 1397 0x00007f10e9b0e700 info agnosticbin kmsagnosticbin.c:899 input_bin_src_caps_probe() Set input caps: video/x-h264, stream-format=(string)avc, alignment=(string)au, codec_data=(buffer)0164001effe100122764001eac568120b69b81010103682211a801000428ee3cb0, level=(string)3, profile=(string)high, width=(int)288, height=(int)352, framerate=(fraction)0/1, parsed=(boolean)true 2020-06-13T08:19:52,164783 1397 0x00007f10e9b0e700 info agnosticbin kmsagnosticbin.c:774 kms_agnostic_bin2_link_pad() Upstream provided caps: ANY 2020-06-13T08:19:52,164949 1397 0x00007f10e9b0e700 info agnosticbin kmsagnosticbin.c:783 kms_agnostic_bin2_link_pad() Downstream wanted caps: video/x-h264, profile=(string)constrained-baseline, stream-format=(string)avc, alignment=(string)au; video/x-h264, stream-format=(string)avc, alignment=(string)au; video/x-h264, profile=(string)constrained-baseline, stream-format=(string)byte-stream, alignment=(string){ nal, au }; video/x-h264, stream-format=(string)byte-stream, alignment=(string){ nal, au } 2020-06-13T08:19:52,165752 1397 0x00007f10e9b0e700 info agnosticbin kmsagnosticbin.c:774 kms_agnostic_bin2_link_pad() Upstream provided caps: ANY 2020-06-13T08:19:52,165937 1397 0x00007f10e9b0e700 info agnosticbin kmsagnosticbin.c:783 kms_agnostic_bin2_link_pad() Downstream wanted caps: video/x-h264, stream-format=(string)avc, alignment=(string)au, width=(int)288, height=(int)352, codec_data=(buffer)0164000dffe100176764000dacb40905b60220000003002ee6b28001e2855401000468ef3cb0, level=(string)1.3, profile=(string)high, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)0/1
vanhungoz
commented
4 years ago @j1elo @RaistGH , do you have any ideal to handle it?
RaistGH
commented
3 years ago Hi, Sorry @vanhungoz , I didn't notice your message. Unfortunately I didn't find a way to solve it and indeed now it's getting worse. Using VP8 and WEBM seemed promising, but it doesn't work. More about it here.
RaistGH
commented
3 years ago 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:
2021-06-13T18:25:24,947540 1 0x00007f4346ffd700 debug recorderendpoint kmsrecorderendpoint.c:1153 link_sinkpad_cb() <kmsrecorderendpoint0:sink_audio_default> linked to <kmswebrtcendpoint0:audio_src_default_0>
2021-06-13T18:25:24,953266 1 0x00007f43467fc700 debug recorderendpoint kmsrecorderendpoint.c:1046 appsink_event_probe() <appsink0:sink> Processing CAPS event audio/x-opus, rate=(int)48000, channels=(int)2, channel-mapping-family=(int)0, stream-count=(int)1, coupled-count=(int)1, streamheader=(buffer)< 4f707573486561640102000080bb0000000000, 4f707573546167731f0000004753747265616d657220656e636f64656420766f72626973636f6d6d656e740000000001 >
2021-06-13T18:25:24,953369 1 0x00007f43467fc700 debug recorderendpoint kmsrecorderendpoint.c:1054 appsink_event_probe() <appsink0> Setting caps: audio/x-opus, rate=(int)48000, channels=(int)2, channel-mapping-family=(int)0, stream-count=(int)1, coupled-count=(int)1, streamheader=(buffer)< 4f707573486561640102000080bb0000000000, 4f707573546167731f0000004753747265616d657220656e636f64656420766f72626973636f6d6d656e740000000001 >
2021-06-13T18:25:24,953431 1 0x00007f43467fc700 debug recorderendpoint kmsrecorderendpoint.c:1021 set_appsink_caps() <appsink0> Setting sink caps audio/x-opus, rate=(int)48000, channels=(int)2, channel-mapping-family=(int)0, stream-count=(int)1, coupled-count=(int)1, streamheader=(buffer)< 4f707573486561640102000080bb0000000000, 4f707573546167731f0000004753747265616d657220656e636f64656420766f72626973636f6d6d656e740000000001 >
2021-06-13T18:25:24,953499 1 0x00007f43467fc700 debug recorderendpoint kmsrecorderendpoint.c:981 set_appsrc_caps() <audioSrc> Setting source caps audio/x-opus, rate=(int)48000, channels=(int)2, channel-mapping-family=(int)0, stream-count=(int)1, coupled-count=(int)1, streamheader=(buffer)< 4f707573486561640102000080bb0000000000, 4f707573546167731f0000004753747265616d657220656e636f64656420766f72626973636f6d6d656e740000000001 >, framerate=(fraction)0/1
2021-06-13T18:25:24,954119 1 0x00007f43467fc700 debug recorderendpoint kmsrecorderendpoint.c:364 recv_sample() <kmsrecorderendpoint0> Setting PTS base time to 0:00:02.026515804
2021-06-13T18:25:24,954181 1 0x00007f43467fc700 debug recorderendpoint kmsrecorderendpoint.c:371 recv_sample() <kmsrecorderendpoint0> Setting DTS base time to 0:00:02.026515804
2021-06-13T18:25:25,037026 1 0x00007f4351ffb700 warning rtpsource rtpsource.c:1176 update_receiver_stats() probation: seqnr 30414 != expected 30416
2021-06-13T18:25:25,037301 1 0x00007f4351ffb700 warning rtpsource rtpsource.c:1176 update_receiver_stats() probation: seqnr 30416 != expected 30415
2021-06-13T18:25:25,038856 1 0x00007f43457fa700 debug recorderendpoint kmsrecorderendpoint.c:1153 link_sinkpad_cb() <kmsrecorderendpoint0:sink_video_default> linked to <kmswebrtcendpoint0:video_src_default_0>
2021-06-13T18:25:25,314053 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1046 appsink_event_probe() <appsink1:sink> Processing CAPS event video/x-vp8, framerate=(fraction)10/1, height=(int)360, width=(int)640, profile=(string)0
2021-06-13T18:25:25,318868 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1054 appsink_event_probe() <appsink1> Setting caps: video/x-vp8, framerate=(fraction)10/1, height=(int)360, width=(int)640, profile=(string)0
2021-06-13T18:25:25,319001 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1021 set_appsink_caps() <appsink1> Setting sink caps video/x-vp8, profile=(string)0
2021-06-13T18:25:25,319092 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:981 set_appsrc_caps() <videoSrc> Setting source caps video/x-vp8, framerate=(fraction)0/1, height=(int)360, width=(int)640, profile=(string)0
2021-06-13T18:25:25,421533 1 0x00007f43449d1700 debug uriendpoint kmsuriendpoint.c:108 kms_uri_endpoint_change_state_impl() <kmsrecorderendpoint0> State changed from stop to start
2021-06-13T18:25:25,421667 1 0x00007f43449d1700 debug KurentoRecorderEndpointImpl RecorderEndpointImpl.cpp:194 onStateChanged() <kmsrecorderendpoint0> State changed to Recording
2021-06-13T18:25:25,421720 1 0x00007f43449d1700 trace KurentoRecorderEndpointImpl RecorderEndpointImpl.cpp:222 onStateChanged() <kmsrecorderendpoint0> State changed to 1
2021-06-13T18:25:40,152380 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1046 appsink_event_probe() <appsink1:sink> Processing CAPS event video/x-vp8, framerate=(fraction)10/1, height=(int)540, width=(int)960, profile=(string)0
2021-06-13T18:25:40,152643 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1054 appsink_event_probe() <appsink1> Setting caps: video/x-vp8, framerate=(fraction)10/1, height=(int)540, width=(int)960, profile=(string)0
2021-06-13T18:25:40,152695 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1021 set_appsink_caps() <appsink1> Setting sink caps video/x-vp8, profile=(string)0
2021-06-13T18:25:40,152758 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:981 set_appsrc_caps() <videoSrc> Setting source caps video/x-vp8, framerate=(fraction)0/1, height=(int)540, width=(int)960, profile=(string)0
2021-06-13T18:25:56,127631 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1046 appsink_event_probe() <appsink1:sink> Processing CAPS event video/x-vp8, framerate=(fraction)10/1, height=(int)720, width=(int)1280, profile=(string)0
2021-06-13T18:25:56,127898 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1054 appsink_event_probe() <appsink1> Setting caps: video/x-vp8, framerate=(fraction)10/1, height=(int)720, width=(int)1280, profile=(string)0
2021-06-13T18:25:56,127975 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:1021 set_appsink_caps() <appsink1> Setting sink caps video/x-vp8, profile=(string)0
2021-06-13T18:25:56,128157 1 0x00007f4347fff700 debug recorderendpoint kmsrecorderendpoint.c:981 set_appsrc_caps() <videoSrc> Setting source caps video/x-vp8, framerate=(fraction)0/1, height=(int)720, width=(int)1280, profile=(string)0
2021-06-13T18:26:07,327094 1 0x00007f439201c700 debug recorderendpoint kmsrecorderendpoint.c:249 send_eos() Send EOS to audioSrc
2021-06-13T18:26:07,327237 1 0x00007f439201c700 debug recorderendpoint kmsrecorderendpoint.c:249 send_eos() Send EOS to videoSrc
2021-06-13T18:26:07,327493 1 0x00007f439201c700 debug recorderendpoint kmsrecorderendpoint.c:1218 unlink_sinkpad_cb() <kmsrecorderendpoint0> Stop operation is pending
2021-06-13T18:26:07,328662 1 0x00007f439201c700 debug recorderendpoint kmsrecorderendpoint.c:1218 unlink_sinkpad_cb() <kmsrecorderendpoint0> Stop operation is pending
2021-06-13T18:26:07,328876 1 0x00007f43441d0700 debug recorderendpoint kmsrecorderendpoint.c:1338 kms_recorder_endpoint_on_eos() <kmsrecorderendpoint0> Received EOS in muxing pipeline
2021-06-13T18:26:07,329370 1 0x00007f439201c700 debug recorderendpoint kmsrecorderendpoint.c:834 kms_recorder_endpoint_stopped() <kmsrecorderendpoint0> Pipeline will stop when all eos are processed
2021-06-13T18:26:07,329605 1 0x00007f43441d0700 warning recorderendpoint kmsrecorderendpoint.c:1345 kms_recorder_endpoint_on_eos() <kmsrecorderendpoint0> Releasing pending pads
2021-06-13T18:26:07,329828 1 0x00007f43441d0700 debug recorderendpoint kmsrecorderendpoint.c:1357 kms_recorder_endpoint_on_eos() <kmsrecorderendpoint0> EOS received as a result of a stop operation. Setting pipeline to NULL
2021-06-13T18:26:07,330747 1 0x00007f43441d0700 debug uriendpoint kmsuriendpoint.c:108 kms_uri_endpoint_change_state_impl() <kmsrecorderendpoint0> State changed from start to stop
2021-06-13T18:26:07,330862 1 0x00007f43441d0700 debug KurentoRecorderEndpointImpl RecorderEndpointImpl.cpp:181 onStateChanged() <kmsrecorderendpoint0> State changed to Stopped
2021-06-13T18:26:07,331007 1 0x00007f43441d0700 trace KurentoRecorderEndpointImpl RecorderEndpointImpl.cpp:222 onStateChanged() <kmsrecorderendpoint0> State changed to 0
2021-06-13T18:26:07,487635 1 0x00007f43a0591240 debug recorderendpoint kmsrecorderendpoint.c:582 kms_recorder_endpoint_dispose() <kmsrecorderendpoint0> dispose
2021-06-13T18:26:07,487784 1 0x00007f43a0591240 debug uriendpoint kmsuriendpoint.c:214 kms_uri_endpoint_dispose() <kmsrecorderendpoint0> dispose
2021-06-13T18:26:07,487884 1 0x00007f43a0591240 debug recorderendpoint kmsrecorderendpoint.c:634 kms_recorder_endpoint_finalize() <kmsrecorderendpoint0> releasing resources...
2021-06-13T18:26:07,487963 1 0x00007f43a0591240 log basemediamuxer kmsbasemediamuxer.c:71 kms_base_media_muxer_finalize() <KmsAVMuxer@0x7f4380021ca0> finalize
2021-06-13T18:26:07,488201 1 0x00007f43a0591240 debug recorderendpoint kmsrecorderendpoint.c:648 kms_recorder_endpoint_finalize() <kmsrecorderendpoint0> finalized
2021-06-13T18:26:07,488246 1 0x00007f43a0591240 debug uriendpoint kmsuriendpoint.c:224 kms_uri_endpoint_finalize() <kmsrecorderendpoint0> finalizeI 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.