Skip to content
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

FFmpeg & FFprobe binarys segfault on Linux #28

Closed
mariocynicys opened this issue Sep 26, 2023 · 6 comments · Fixed by #42
Closed

FFmpeg & FFprobe binarys segfault on Linux #28

mariocynicys opened this issue Sep 26, 2023 · 6 comments · Fixed by #42
Labels
platform: Linux Issues affecting Linux priority: P0 Broken for everyone; no workaround; urgent type: bug Something isn't working correctly
Milestone

Comments

@mariocynicys
Copy link
Contributor

System information:

OS: Arch Linux x86_64
Kernel: 6.4.3-arch1-1

The output of running ffprobe on vid.mp4:

$ /home/mario/.local/share/virtualenvs/shaka-F3LkE8tS/lib/python3.11/site-packages/streamer_binaries/ffprobe-linux-x64 vid.mp4
ffprobe version n4.4 Copyright (c) 2007-2021 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.3.0-17ubuntu1~20.04)
  configuration: --pkg-config-flags=--static --disable-ffplay --enable-libvpx --enable-libaom --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-mbedtls --enable-runtime-cpudetect --enable-gpl --enable-version3 --enable-static --enable-nvenc --enable-vdpau
  libavutil      56. 70.100 / 56. 70.100
  libavcodec     58.134.100 / 58.134.100
  libavformat    58. 76.100 / 58. 76.100
  libavdevice    58. 13.100 / 58. 13.100
  libavfilter     7.110.100 /  7.110.100
  libswscale      5.  9.100 /  5.  9.100
  libswresample   3.  9.100 /  3.  9.100
  libpostproc    55.  9.100 / 55.  9.100
zsh: segmentation fault (core dumped)   vid.mp4

Tried multiple other videos and facing the same issue.

@joeyparrish
Copy link
Member

I am making a lot of changes right now to the build and configs. I'll ask you to try again as soon as I have these changes merged.

@joeyparrish joeyparrish added type: bug Something isn't working correctly priority: P0 Broken for everyone; no workaround; urgent platform: Linux Issues affecting Linux labels Sep 27, 2023
@github-actions github-actions bot added this to the Backlog milestone Sep 27, 2023
@joeyparrish
Copy link
Member

Please try the binaries from this workflow run and let me know if the issue is resolved for you:

https://github.com/shaka-project/static-ffmpeg-binaries/actions/runs/6340785810

@mariocynicys
Copy link
Contributor Author

Please try the binaries from this workflow run and let me know if the issue is resolved for you:

shaka-project/static-ffmpeg-binaries/actions/runs/6340785810

Still segfaulting on my Arch system, but tried them on Ubuntu and they worked :/

@joeyparrish
Copy link
Member

I wonder what the incompatibility is...

I have seen an alternative to true static binaries, which we could try. We could bundle dynamic libraries with the executable, and use a script that sets the loader path to make sure those get used. This would be similar to what we do on Windows and macOS, except in those cases, the OS has stable libraries we can count on. Different Linux distributions can do things very differently.

@mariocynicys
Copy link
Contributor Author

I wonder what the incompatibility is...

It's probably some FFmpeg bug or a problem with one of the features we enable. I need to re-compile with different configurations to see where the issue comes from.

@joeyparrish
Copy link
Member

We've recently discovered that compiling against musl instead of glibc fixes the issue. Our latest Shaka Packager release (v3.0.0) is fully static on Linux. The same could work here.

joeyparrish added a commit that referenced this issue Oct 9, 2024
This uses an Alpine Linux container to build truly static
Linux binaries that do not depend on glibc at runtime.

Alpine uses musl instead of glibc, which enables this fully static
build.  With musl compiler wrappers in Ubuntu, you still end up
importing glibc references through libstdc++.  And since x265 uses
C++, we can't eliminate these in Ubuntu without dropping HEVC support.
Using Alpine, with its musl-native environment, allows us to avoid
glibc and build fully static Linux binaries.

Closes #28
joeyparrish added a commit that referenced this issue Oct 9, 2024
This uses an Alpine Linux container to build truly static
Linux binaries that do not depend on glibc at runtime.

Alpine uses musl instead of glibc, which enables this fully static
build.  With musl compiler wrappers in Ubuntu, you still end up
importing glibc references through libstdc++.  And since x265 uses
C++, we can't eliminate these in Ubuntu without dropping HEVC support.
Using Alpine, with its musl-native environment, allows us to avoid
glibc and build fully static Linux binaries.

Closes #28
joeyparrish added a commit that referenced this issue Oct 9, 2024
This uses an Alpine Linux container to build truly static
Linux binaries that do not depend on glibc at runtime.

Alpine uses musl instead of glibc, which enables this fully static
build.  With musl compiler wrappers in Ubuntu, you still end up
importing glibc references through libstdc++.  And since x265 uses
C++, we can't eliminate these in Ubuntu without dropping HEVC support.
Using Alpine, with its musl-native environment, allows us to avoid
glibc and build fully static Linux binaries.

Closes #28
joeyparrish added a commit that referenced this issue Oct 9, 2024
This uses an Alpine Linux container to build truly static
Linux binaries that do not depend on glibc at runtime.

Alpine uses musl instead of glibc, which enables this fully static
build.  With musl compiler wrappers in Ubuntu, you still end up
importing glibc references through libstdc++.  And since x265 uses
C++, we can't eliminate these in Ubuntu without dropping HEVC support.
Using Alpine, with its musl-native environment, allows us to avoid
glibc and build fully static Linux binaries.

Closes #28
joeyparrish added a commit that referenced this issue Oct 10, 2024
This uses an Alpine Linux container to build truly static
Linux binaries that do not depend on glibc at runtime.

Alpine uses musl instead of glibc, which enables this fully static
build.  With musl compiler wrappers in Ubuntu, you still end up
importing glibc references through libstdc++.  And since x265 uses
C++, we can't eliminate these in Ubuntu without dropping HEVC support.
Using Alpine, with its musl-native environment, allows us to avoid
glibc and build fully static Linux binaries.

Closes #28
joeyparrish added a commit to shaka-project/shaka-lab that referenced this issue Oct 10, 2024
If you want to run workflows with jobs that inside containers, you need support for nested containers.  This is now possible with a little bit of configuration.

To make this work, we need to synchronize a few important folders between the host and the main container so that they can be forwarded on correctly to nested containers.

Part of the solution to shaka-project/static-ffmpeg-binaries#28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform: Linux Issues affecting Linux priority: P0 Broken for everyone; no workaround; urgent type: bug Something isn't working correctly
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants