Closed abrar71 closed 1 year ago
You should report this to upstream ffmpeg. Something with rtmp + mbedtls seems to be broken in ffmpeg. Other people have reported this before. On Windows it should just work though, since Windows uses the native schannel API. But on Linux, mbedtls really is the only available option for statically linked TLS.
Thank you for your prompt response,
I'm using markus pearl's FFmpeg 6.0 build script, and its working perfectly with FFmpeg static build.
I've even tested running markus's script in a debian:bullseye-slim
docker image, and it runs smoothly using the restreaming command mentioned in the issue description.
For reference I used the following command to build static FFmpeg using markus's script and also have attached the build below
./build-ffmpeg --build --enable-gpl-and-non-free --latest --full-static
What TLS library is it using? The only other option I'm aware of is OpenSSL, which can't be linked statically due to licensing concerns for versions before 3.0, and I can't use 3.0+ because other dependencies that depend on OpenSSL are not compatible with 3.0. Which leaves mbedtls as the only option.
I did a quick search for tls/ssl and it looks like he's using
https://github.com/markus-perl/ffmpeg-build-script/blob/master/build-ffmpeg
I looked into gnutls, but it has way too many too big dependencies I don't want to deal with. mbedtls really should work, please report the issue to upstream FFmpeg so it can get fixed there.
Sorry, On having a second look, I think he's not using gnutls, and hasn't used or enabled it anywhere so I made a markus ffmpeg build without build part of gnutls in the script and FFmpeg still works good with OpenSSL.
I think this reported issue can be resolved by using openssl 1.1.1t
instead of mbedtls
and using --enable-openssl
in FFmpeg build configuration, and also updating SRT build to use OpenSSL
The mbedtls
library is buggy with FFmpeg
If you use --enable-openssl with an OpenSSL version before 3.0, it makes the build nonfree and not redistributable. So I obviously can't use it for builds I distribute. And I can't use OpenSSL 3.0 since there are other dependencies that only support 1.1.1 or older.
Oh, you are definitely right about the licensing, All other FFmpeg builds use OpenSSL 1.1.1t and not the later ones due to the dependencies
Maybe we can use OpenSSL 1.1.1t only for the nonfree versions and mbedtls for all other versions?
Until the mbedtls bugs gets fixed?
I mean, it's easily possible. But it wouldn't really fix the issue in any builds you can download from Github. It's an unfortunate situation, but I can't think of any actually good fix.
I might give bumping to OpenSSL 3 another try soon. But mbedtls has to stay anyway, since it's also a dependency of other dependencies.
I use my own forked repo with nonfree and doing this would help fix the problem,
I don't know if OpenSSL 3 would work with the dependencies but to be on the safe side maybe we should still stick to 1.1.1t
If we use enable and use OpenSSL for nonfree versions only and not use mbedtls with nonfree
And use mbedtls with the other versions without OpenSSL, It would be a huge help and will help solve this issue for me and probably many others.
*other versions without OpenSSL
Seems like whatever didn't like OpenSSL 3.0 fixed their stuff in the meantime. At least win64 and linux64 worked fine locally. So I just bumped openssl to 3.0.x.
I've tried different versions, including LGPL/GPL and both static and shared builds from the Releases section. However, when attempting to restream a video to Facebook's RTMPS endpoint, the command gets stuck after connecting to the RTMPS server.
Other FFmpeg builders, such as https://github.com/markus-perl/ffmpeg-build-script, don't experience this issue with any of their versions.
Here is the command I'm using:
Expected behavior:
The video should be successfully restreamed to the Facebook RTMP Endpoint without getting stuck.
Actual behavior:
The command gets stuck after connecting to the RTMPS server