-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't recording 720P .mp4 (H264) video #49
Comments
Hi, Any update with this issue? I know Kurento is in low mantainance mode, but I think there are a possible compatibility issue in Kurento with new H264/X264 releases of 2024. I reproduce same behaviour in iOS 17.4 devices in Safari. It happens 80% of connections. When everything works fine, there are no WARN/ERROR logs related to this, but sometimes, Kurento in latest version (7.0.1) prints: (enabling MKV):
Enabling MP4:
Curiously, we receive correctly images in our custom OpenCV filter (we're saving all frames Kurento receive for testing purposes) but final video is pixelated, trimmed, partially black... Could be related to transcoding or something like that? According to GStreamer errors, it seems an incompatibility issue. Any light on that? By the way, I reproduce same behaviour in OpenVidu demo with Kurento backend. Regards. |
Could it be related to old issue Kurento/bugtracker#535? As far as I saw in @j1elo comments, no fix was implemented (because matroska and VP8). I don't know if at least, you have a workaround. Regards. |
The problem is exactly issue Kurento/bugtracker#535, as mentioned above, and it stems from this:
Problem was that Kurento got upgraded to use the GStreamer dependency that comes with Ubuntu 20.04 (GStreamer 1.16), but it turns out that this came with breaking changes in behaviors (I guess at some point they considered it a bug but then changed their mind and considered it a regression, but in the meantime a release was cut, published, and ended up being part of Ubuntu). Solution is not small as it would consist on researching a bit about that GStreamer issue, see which commits fixed the problem, then locate which releases already contain the commit(s) to be clear on what GStreamer version needs to be used. And then, the major part, upgrading Kurento to make it work with that version. It's not a trivial thing to do because GStreamer sometimes changes internals such that old code needs to be changed in order to use newer versions of the library. I'd like to get some of my own time at some point to do the upgrade. For now, may I suggest you try using the latest available version of Kurento 6.x? |
Seems that I had done the initial part that I mentioned: Kurento/bugtracker#535 (comment) So GStreamer >= 1.20 seems to contain the fixes already. But as the next comment in that issue points out, there seem to be some other additional issues when using those newer versions of GStreamer! No doubt, those corruption issues come probably from the fact that the user who tested with GStteamer 1.21 tried to use Kurento 7 as-is, without the work to adapt it to possible breaking changes. As expected, some work needs to be done explicitly to support newer versions of the library, it cannot be used as-is like nothing bad would happen. |
Hi @j1elo Thanks for your quick response. I think I 've understood properly root cause of problem. I got your advice to rollback to previos Kurento versión (6.18.0) but I've been looking for a quick solution and I found (already deprecated) degradationPreference parameter (https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/setParameters#degradationpreference) and I think it could be a mitigation and possible cause of behaviour we're experiencing since iOS 17.4. According to iOS 17.4 release notes, they "fixed" degradationPreference's "mantain-framerate" option (https://developer.apple.com/documentation/safari-release-notes/safari-17_4-release-notes#WebRTC) and It seems they fixed "balanced" option too (which is default value), so probable it's related to our recent problem. When I have a chance to test It, I'll come back to share my results. Regards. |
Hi all, In case it helps to anyone, issue for me is solved setting "degradationPreference" parameter to "mantain-resolution". Sample code:
Anyway, this is a mitigation because Kurento shouldn't crash. Do you have plans to upgrade it to latest version of Gstreamer? I think I could help in case is needed. Regards. |
Prerequisites
These are MANDATORY, otherwise the issue will be automatically closed.
Issue description
even change conferenceroom.js media constraints.
Context
I'm trying to accomplish this:
Application Server: Demo Project revised from Tutorial-GroupCall & focal-gstreamer-build-from-source (docker image)
GStreamer Core Library version 1.16.3
I pull media server image for test recording:
docker pull kurento/kurento-media-server
, and setup my own media server on AWS EC2 test recording separately.Both server's video resolution always 640 x 480.
At Fisrt, I thought was Browser or JS WebRTC API problem, use different client to call application server
Browser Result:
When first participant join room and room Created immediately recording
Application Server Log & Media info
General Format : MPEG-4 Format profile : Base Media / Version 2 Codec ID : mp42 (mp42/mp41/isom/iso2) File size : 121 MiB Duration : 10 min 4 s Overall bit rate : 1 683 kb/s Frame rate : 29.708 FPS Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : Constrained Baseline@L3 Format settings : 1 Ref Frames Format settings, CABAC : No Format settings, Reference frames : 1 frame Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 10 min 4 s Bit rate : 1 681 kb/s Width : 640 pixels Height : 480 pixels Display aspect ratio : 4:3 Frame rate mode : Variable Frame rate : 29.708 FPS Minimum frame rate : 12.500 FPS Maximum frame rate : 33.223 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.184 Stream size : 121 MiB (100%) Codec configuration box : avcC
Media Constraints set over 480P, then call application server, media server will occur errors.
Application Server Error Message:
With this approach, it's challenging for me, especially I'm not familiar C programming language and Linux.
I'm unsure if it will work or not, but I give it a try.
However, still unable to recording and identify the root cause of the issue.
with 1.20 / 1.22, Group-Call, media server same Log info:
#359, #372, #535, #641, #642
;How to reproduce?
Expected & current behavior
(Optional) Possible solution
Info about your environment
configs
WebRtcEndpoint.conf.ini
SdpEndpoint.conf.json
MediaElement.conf.ini
About Kurento Media Server
About your Application Server
About end-user clients
Run these commands
DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"
The text was updated successfully, but these errors were encountered: