michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
rvalue has quit [Ping timeout: 240 seconds]
rvalue has joined #ffmpeg-devel
paulk-bis has joined #ffmpeg-devel
paulk has quit [Read error: Connection reset by peer]
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
<YourNick99>
The problem is that all your builds don't contain ALSA Output device... I tested FFPLAY on many Debian 12 Based Distro... ALSA doesn't appear in the device list at all...
<YourNick99>
Do you enabled libasound devel at your compile?
<YourNick99>
Look at the ffplay output... there is no ALSA:
<YourNick99>
Devices:
<YourNick99>
D. = Demuxing supported
<YourNick99>
.E = Muxing supported
<YourNick99>
---
<YourNick99>
DE fbdev Linux framebuffer
<YourNick99>
D kmsgrab KMS screen capture
<YourNick99>
D lavfi Libavfilter virtual input device
<YourNick99>
D openal OpenAL audio capture device
<YourNick99>
DE oss OSS (Open Sound System) playback
<YourNick99>
DE pulse Pulse audio output
<YourNick99>
E sdl,sdl2 SDL2 output device
<YourNick99>
DE video4linux2,v4l2 Video4Linux2 output device
<YourNick99>
D x11grab X11 screen capture, using XCB
<YourNick99>
E xv XV (XVideo) output device
<BtbN>
alsa lib cannot be statically linked, use PA instead
<BtbN>
And don't flood the channel
<YourNick99>
OSS is working through... Is it because SDL2 is statically linked in the build?
<BtbN>
It's because OSS is just dumping raw pcm into a file in /dev :D
<YourNick99>
Anyway, i'm trying to make ALSA work even if PA is working. Is SDL2 statically linked?
AndrewSayers has quit [Quit: Leaving.]
<BtbN>
Again, you cannot statically link alsas library
<BtbN>
so it won't work with a static build
<YourNick99>
that i know but is it because os SDL2?
<BtbN>
I have no idea what SDL got to do with anything
<YourNick99>
I've read that alsa is detected by SDL2, is that true?
<BtbN>
ffmpeg does not use SDL for audio output
<BtbN>
ffplay might, but that's about it
<BtbN>
And again again: You cannot statically link alsas library
<BtbN>
no matter if you put SDL in between it and ffmpeg or not
<YourNick99>
that's the issue. I'm talking about ffplay. How is ffplay detecting alsa lib? Is it by SDL2?
<BtbN>
It's not, since it cannot be statically linked.
Warcop has quit [Remote host closed the connection]
<YourNick99>
ok so by logic, the shared build you make should make ALSA work?
<BtbN>
no
<BtbN>
For the fourth time: You cannot statically link alsas library
<BtbN>
And if I would link it as a shared library, and the distro uses a different version, it'd fail to start at all or crash
<BtbN>
So it's not feasible to include it in static builds.
<BtbN>
I also just noticed that you're in the wrong channel. User-Questions go to #ffmpeg
AndrewSayers has joined #ffmpeg-devel
<YourNick99>
yes i understand that. I was wondering if alsa lib could be a big issue... I will do some static build test on my side and see if i can find a way to make it works. I didn't look at the flags concerning alsa to be honest.
<BtbN>
You cannot
<YourNick99>
ok thanks BtbN and sorry for the flood :)
<BtbN>
I spent significant time on it, trying to build a shim loader. Just not worth it.
<Marth64>
best example to start for serializing json (from a demuxer)? ffprobe?
<Marth64>
context: want dvd demuxer to provide list and properties of of available titles, menus, etc
<BtbN>
It's usually done the printf-way I think
<Marth64>
should be fine, i have nothing to escape, all numbers and simple constant strings
YourNick99 has joined #ffmpeg-devel
<Marth64>
was thinking usage in theory like ffmpeg -f dvdvideo -mode list -map 0:d -f data - --> json
<YourNick99>
ya made it to work with the following command. FFPLAY is using SDL2 as output device. But we must specify ALSA backend that SDL2 wil use like this: env SDL_AUDIODRIVER=alsa AUDIODEV=hw:0 ffplay
<YourNick99>
So i Can still use ALSA even if ALSA outpout device is not available.
HarshK23 has quit [Quit: Connection closed for inactivity]
<BtbN>
I doubt that works, given that SDL itself is also statically linked and thus has the exact same problem of needing a static alsa lib, which is impossible.
AbleBacon has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
cone-442 has quit [Quit: transmission timeout]
compnn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
Livio has quit [Quit: Reconnecting]
Livio has joined #ffmpeg-devel
compnn has joined #ffmpeg-devel
compn has quit [Ping timeout: 255 seconds]
Livio has quit [Ping timeout: 252 seconds]
jamrial has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
compnn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
AndrewSayers1 has joined #ffmpeg-devel
AndrewSayers has quit [Ping timeout: 246 seconds]
Guest35 has joined #ffmpeg-devel
<Guest35>
Well BtbN, after looking at another Static project made by johnvansickle.com, ALSA Support is well compiled statically. So you should do the same. It will not break anything because he did it. Look at the compile options on his side: https://johnvansickle.com/ffmpeg/release-readme.txt
<Guest35>
libalsa: 1.2.4 can be compiled statically without any problem. I also believe that alsa is not the kind of library that could cause regression or incompatibility problem on any "recent" platform
Guest35 has quit [Client Quit]
<BtbN>
Well, my investigation into it looks vastly different
<BtbN>
libalsa loads a lot of plugins at runtime, and those need to match the library _perfectly_
<BtbN>
There is no guarantee for ABI between libalsa and its plugins
<BtbN>
And there is no mechanism for linking those plugins statically
<BtbN>
so linking the main lib statically will inevitably lead to crashes if the versions don't happen to line up
<psykose>
which plugins
<BtbN>
stuff like the PA one
<BtbN>
And there's a whole set of other ones that come directly with libalsa
<iive>
like dmix
<psykose>
the ones that come from alsa-plugins?
<BtbN>
That's where the PA one and friends live
<BtbN>
but there's a whole bunch of first-party ones
<psykose>
arent the alsa-lib ones already in the lib
<psykose>
they're not separate files
<BtbN>
nope, they're runtime-loaded
<psykose>
i don't see anything in alsa-lib except the library and conf files
<psykose>
there are no separate plugins
<psykose>
the alsa-plugins ones are loaded but that's all optional and separate
<BtbN>
Well, every time I tried it, it went badly
<BtbN>
Despite alsa officially saying they support static linking even
<q66>
anything that is in alsa-plugins is largely useless especially considering one should always be using a sound server anyway
<psykose>
yeah there's no libasound_module_*.so in alsa-lib itself
<q66>
so just the library is all one needs
<BtbN>
Well, the PA plugin is kinda important
<BtbN>
or the Pipewire at that
<psykose>
if someone was using PA they would be connecting with libpulse already
<q66>
yes those are loadable
<psykose>
why would they use the alsa output for ffmpeg just to then connect to pa
<psykose>
instead of pa directly
<q66>
yea
<psykose>
it's not like you'd only have alsa support that then needs a pa plugin
<BtbN>
Cause you got no clue you're using PA/copied an invocation of Stackoverflow
<q66>
the pa/pipewire plugins are pretty much only for scuffed applications that use alsa api directly
<psykose>
user issue
<BtbN>
I forgot what the exact issue was, it's been long ago
<BtbN>
But statically linking that lib did not work out
<BtbN>
it wanted to load stuff at runtime, and failed
<psykose>
q66: they're useless there too because pa/pw support regular alsa clients and don't need alsa to load a pa plugin to talk to them
<q66>
nah
<q66>
the alsa client support is through the plugins
<q66>
like, pa comes with an alsa plugin, pw comes with an alsa plugin
<psykose>
ah
<q66>
when an alsa client does audio, it talks to alsa, alsa loads the plugin, plugin talks to pipewire or whatever, pipewire talks back to alsa at low level
<psykose>
yea makes sense then
<psykose>
this is definitely abi compatible tho
<psykose>
i guess it makes sense static alsa cant load it tho