lavaball has quit [Remote host closed the connection]
user23 has quit [Ping timeout: 250 seconds]
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg
user23 has joined #ffmpeg
Jiggy has joined #ffmpeg
jtgd has joined #ffmpeg
lec_thege80427 has quit [Read error: Connection reset by peer]
lec_thege804270 has joined #ffmpeg
Livio has joined #ffmpeg
lec_thege804270 has quit [Read error: Connection reset by peer]
lec_thege80427 has joined #ffmpeg
<Jiggy>
Having trouble building ffmpeg on Archlinux. There's an error when testing libjxl against cuda gcc: "/usr/bin/ld: /usr/lib/libhwy.so.1: undefined reference to `__extendbfsf2@GCC_13.0.0'"
<Jiggy>
Actually that isn't cuda gcc since I'm on 12.3.0 for that...
<Jiggy>
Ah that's likely the issue, that I'm using 12 instead of 13
<psykose>
that method comes from the compiler runtime library (libgcc_s) when it has to emit code that something something at runtime, so if you're using gcc13 it expects that libgcc_s will be 13 too
Livio has quit [Ping timeout: 268 seconds]
<Jiggy>
That makes a lot of sense lol
<psykose>
i don't know how cuda-gcc works but unless you can compile things in a way that it won't emit such calls at all you need the same version as runtime will have ~
<Jiggy>
Thank you
<psykose>
or
<psykose>
ah no i misread
<psykose>
you're using the cuda gcc 12, but then at link time the code is linking libhwy which was already built with a dependency of libgcc_s 13, and it's probably trying to create an executable with libgcc_s 12 linked (since you're using gcc 12)
<psykose>
so yes 13 would fix it
<psykose>
just tired but that's loosely correct
<psykose>
tl;dr can't use a compiler older than your system is built with if you're linking stuff that already depends on the newer compiler runtime library
<Jiggy>
Yea that seems to be the case. Greatly appreciated. So I guess I don't need to use cuda's gcc to build ffmpeg with cuda support. We'll see..
Sakura`Kinomoto has quit [Remote host closed the connection]
Sakura`Kinomoto has joined #ffmpeg
j45 has quit [Ping timeout: 260 seconds]
j45 has joined #ffmpeg
deetwelve has quit [Quit: null]
evilscreww has joined #ffmpeg
deetwelve has joined #ffmpeg
Ogobaga has quit [Ping timeout: 260 seconds]
beaver has quit [Remote host closed the connection]
j45 has quit [Ping timeout: 240 seconds]
j45 has joined #ffmpeg
rvalue has joined #ffmpeg
tips_ has joined #ffmpeg
Livio has joined #ffmpeg
Suchiman has joined #ffmpeg
zenloading has quit [Ping timeout: 264 seconds]
YuGiOhJCJ has joined #ffmpeg
bitoff has joined #ffmpeg
lavaball has joined #ffmpeg
YuGiOhJCJ has quit [Remote host closed the connection]
Livio has quit [Ping timeout: 264 seconds]
YuGiOhJCJ has joined #ffmpeg
peac has joined #ffmpeg
<peac>
hey, how can I properly set the GOP size in ffmpeg using the h264_v4l2m2m codec? ffmpeg says `Failed to set gop size: Invalid argument` when using `-g 30`
evilscreww has quit [Remote host closed the connection]
<BtbN>
That's literally how you do it. If that throws an error, your hardware must not support the value you picked.
<peac>
how can i check the supported values ?
<JEEB>
first you figure out if the v4l2 api allows for that :)
<JEEB>
if it doesn't, then you scratch your head and hope the driver is open source and you can figure it out
<peac>
i'm finding threads that say i need to recompile ffmpeg with a patch to make it work, trying a vanilla compilation as first step
theobjectivedad has quit [Ping timeout: 260 seconds]
lavaball has joined #ffmpeg
LuKaRo has joined #ffmpeg
theobjectivedad has joined #ffmpeg
lusciouslover has quit [Ping timeout: 260 seconds]
lusciouslover has joined #ffmpeg
echkourine25 has quit [Quit: Client closed]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg
stevenliu has quit [Read error: Connection reset by peer]
stevenliu_ has joined #ffmpeg
Marth64 has joined #ffmpeg
LuKaRo has quit [Ping timeout: 272 seconds]
Ogobaga has joined #ffmpeg
junaid_ has quit [Remote host closed the connection]
e^pi-1 has quit [Quit: WeeChat 4.2.1]
Livio has joined #ffmpeg
Livio has quit [Ping timeout: 240 seconds]
alien_lappy has quit [Ping timeout: 252 seconds]
JanC has quit [Ping timeout: 256 seconds]
JanC has joined #ffmpeg
bencc1 has joined #ffmpeg
<bencc1>
Hi. I'm getting this error when using x11grab with ffmpeg 6.1 in a debian container:
<bencc1>
[x11grab @ 0x563e8ebc7800] Could not get shared memory buffer.
<bencc1>
It's working fine with ffmpeg 5.1
<bencc1>
did something changed with x11grab? Do I need to change anything?
alien_lappy has joined #ffmpeg
beaver has joined #ffmpeg
lusciouslover has quit [Quit: \]
hamzah has joined #ffmpeg
lusciouslover has joined #ffmpeg
marcj has quit [Ping timeout: 240 seconds]
bencc1 has quit [Quit: Leaving]
lexano has joined #ffmpeg
beaver has quit []
chiselfuse has quit [Ping timeout: 260 seconds]
marcj has joined #ffmpeg
NaviTheFairy has quit [Ping timeout: 264 seconds]
chiselfuse has joined #ffmpeg
NaviTheFairy has joined #ffmpeg
iive has joined #ffmpeg
beaver has joined #ffmpeg
<BtbN>
My guess would be that it's cause of that container-situation.
minimal has joined #ffmpeg
Livio has joined #ffmpeg
beaver has quit [Quit: modification de tcp_read_time_out && tcp_connect_time_out]
beaver has joined #ffmpeg
Marth64 has quit [Ping timeout: 264 seconds]
hightower4 has joined #ffmpeg
hightower3 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg
fling_ has joined #ffmpeg
fling has quit [Ping timeout: 260 seconds]
fling_ is now known as fling
gchound has joined #ffmpeg
rv1sr has quit []
mishehu has joined #ffmpeg
<Jiggy>
psykose: compiling just fine now that I'm the updated cuda
<Jiggy>
I'm on*
rv1sr has joined #ffmpeg
hamzah has quit [Ping timeout: 250 seconds]
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg
rvalue has quit [Ping timeout: 252 seconds]
<peac>
okay so the only way i found to fix my issue, is to send broken but hardware encoded h264 stream from the rpi, and reencode it with libx264 on the server. now the HLS streaming has correct keyframes...
<peac>
however with 5 streams out of total 16 i need to handle, i'm already at 70% cpu
<peac>
the only thing i can say is that the h264_v4l2m2m fails to understand -g 30 and creates a stream that is malformed, causing playback at the wrong speed and jumps from keyframe to keyframe
<furq>
if it's actually broken on playback then never mind
vlm has joined #ffmpeg
Vonter has quit [Ping timeout: 255 seconds]
<BtbN>
Why are you using cuda-gcc at all? What even is that? Jiggy
<BtbN>
You mean nvcc?
gchound has quit [Quit: Leaving]
<BtbN>
And even when using nvcc, it won't introduce any runtime dependencies on cuda libs, since it's sololey used for building .cu code to ptx. So I'm confused.
Vonter has joined #ffmpeg
<Jiggy>
BtbN: Yes, nvcc to be more precise. Was building the AUR package ffmpeg-obs to support cuda hw accel. When running tests for libjxl, the following error occurred
<Jiggy>
/usr/bin/ld: /usr/lib/libhwy.so.1: undefined reference to `__extendbfsf2@GCC_13.0.0'
<BtbN>
You do not need nvcc or the cuda sdk _at all_ to build ffmpeg
<BtbN>
And it will also not introduce any such library dependencies
<BtbN>
so... huh?
<Jiggy>
Well I was getting that error in the testing phase prior to updating from cuda 12.3 to 12.4 (the latter of which has support for gcc 13)
<Jiggy>
after updating cuda, no issue, without changing the PKGBUILD
<BtbN>
I really don't follow. FFmpeg purely talk to the driver. It has zero dependencies or interactions with anything from the CUDA SDK. nvcc is the only thing, and it's entirely optional.
<BtbN>
And it won't intoroduce any runtime dependencies either.
<BtbN>
You just need any clang version installed and you don't need nvcc at all.
<Jiggy>
I'm aware nvcc is optional; I'm opting to use it
<BtbN>
Why though?
<BtbN>
And even if you use it, it won't cause that kind of errors.
<Jiggy>
I'm not getting any errors now that I've updated to cuda 12.4 w/ gcc 13.2 support
<BtbN>
You probably have clang installed anyway on arch, so why bother with the rather huge cuda sdk, just for nvcc?
<BtbN>
There is zero difference in speed or functionality.
<Jiggy>
The nvidia docs seem to suggest otherwise
<BtbN>
no idea what they suggest, but they're wrong if so.
<BtbN>
Literally all ffmpeg uses nvcc for is to turn .cu files into .ptx files. clang can do that as well.
<BtbN>
The entire rest of the cuda sdk is not touched in any way
<Jiggy>
So you're telling me that running ffmpeg with "-hwaccel cuda" "-hwaccel_output_format cuda" actually redirects to standard nvenc/nvdec instead of using cudaa?
<Jiggy>
Cuz that doesn't make sense to me
<BtbN>
You don't even need nvcc for that. That's just nvenc/dec
<BtbN>
The only thing that needs a .cu->.ptx compiler are the cuda based filters.
<BtbN>
Everything else only needs the ffnvcodec headers.
<BtbN>
Not sure where that doesn't make sense. It's how it is.
Traneptora has quit [Quit: Quit]
<furq>
cuda is an old (deprecated?) alias for nvdec/enc
<furq>
in that sense, at least
<BtbN>
nah, cuda is the correct and latest name for the hwaccel
<BtbN>
It just doesn't interact with the CUDA SDK in any way, but somehow people keep claiming that
Traneptora has joined #ffmpeg
FH_thecat has quit [Ping timeout: 268 seconds]
<Jiggy>
I like that the official ffmpeg documention itself is ambiguous about it and its benefits over cuda-llvm
<BtbN>
libnpp is basically legacy stuff and has long been superseeded by scale_cuda outside of some extreme nieche cases
<BtbN>
Calling npp an "older cuvid option" is a bit weird, but nothing there seems ambigious to me.
<Jiggy>
that's the funny part to me. It says that it has "basically been replaced" rather than superseded. And it doesn't give any information related to performance differences lol
<Jiggy>
"They might have different options/flexibility than their XX_cuda equivalent. Might be similar performance. These have more funky licensing (nonfree)."
<Jiggy>
This doesn't give any reason to choose one over the other lol. Some better docs would be nice
<BtbN>
one needs a giant SDK and is nonfree
<Jiggy>
Not a problem for me
<BtbN>
The other doesn't have either of these issues. End of the story.
<BtbN>
libnpp will likely just go away at some point anyway, so zero point using it
<BtbN>
And the .cu compiler just simply has no effect on performance whatsoever.
<BtbN>
Just forget the stuff that needs the CUDA SDK exists. There is no point to it.
<Jiggy>
/shrug I'm still going to follow nvidia's instructions
<BtbN>
lol
<BtbN>
Nvidias instructions have been historically terrible.
<BtbN>
Of course they also use as much of their proprietary stuff as possible.
Marth64 has quit [Killed (NickServ (GHOST command used by Marth128!~Marth128@188.215.95.221))]
Marth64 has joined #ffmpeg
Livio has quit [Ping timeout: 260 seconds]
noobaroo has quit [Remote host closed the connection]
hamzah has joined #ffmpeg
noobaroo has joined #ffmpeg
Vonter has quit [Ping timeout: 255 seconds]
Vonter has joined #ffmpeg
hightower3 has joined #ffmpeg
elastic_dog has quit [Ping timeout: 246 seconds]
hightower4 has quit [Ping timeout: 268 seconds]
hamzah has quit [Ping timeout: 250 seconds]
elastic_dog has joined #ffmpeg
gchound has joined #ffmpeg
Marth64 has quit [Remote host closed the connection]
Muimi__ has joined #ffmpeg
gchound has quit [Quit: Leaving]
intrac has quit [Quit: Konversation terminated!]
gchound__ has joined #ffmpeg
iliv has quit [Ping timeout: 252 seconds]
AbleBacon has joined #ffmpeg
ivanich_ has joined #ffmpeg
ivanich has quit [Read error: Connection reset by peer]
Tinos has quit [Remote host closed the connection]
hightower4 has joined #ffmpeg
hightower3 has quit [Ping timeout: 268 seconds]
FH_thecat has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
KDDLB0 has joined #ffmpeg
KDDLB has quit [Ping timeout: 260 seconds]
KDDLB0 is now known as KDDLB
ivanich_ has quit [Remote host closed the connection]
<CounterPillow>
"don't do this it's dumb" - "I will do this anyway"
rv1sr has quit []
<CounterPillow>
Doing the think the place you're asking for help from explicitly recommends against just to then continually badger them for help with the broken proprietary trillion dollar company solution is amazing
emmanuelux has quit [Read error: Connection reset by peer]
emmanuelux has joined #ffmpeg
<Jiggy>
CounterPillow: I know where I am and who BtbN is, and I do respect his knowledge of ffmpeg. This is just the way I've built ffmpeg for a few years now, as has anyone who has been using tytan652's obs package from AUR. I intend to continue researching this further to better understand why I should make the change. I wish ffmpeg docs had more information on the differences, but I'll look at commits
<Jiggy>
I'll probably do my own performance and quality tests to compare
<BtbN>
It's just to get rid of a several GB large thing from nvidia that services no purpose
<CounterPillow>
ah yes, the epitome of quality packaging decisions: the AUR
<BtbN>
if you are not actually using scale_npp, there is _nothing_ that even _can_ be different
<Jiggy>
CounterPillow: I don't disagree that AUR isn't the best thing in the world, but tytan652 is on the official OBS team
emmanuelux has quit [Read error: Connection reset by peer]
<Jiggy>
BtbN: I will look further into that and if I don't use it then I'll switch and test
<BtbN>
OBS still does not support the proper variable bitrate/crf mode of nvenc, so I'm not sure how much of an authority anything OBS does is.
<BtbN>
I don't understand what's there to look into...
<Jiggy>
I don't use obs's built in settings. I encode through ffmpeg
<BtbN>
FFmpeg does not use the cuda SDK. At all. With the notable exception of libnpp for scale_npp, which you should forget exists.
<Jiggy>
and the alternative is scale_cuda?
<BtbN>
Naturally, yes
<BtbN>
scale_npp also does a lot of very weird format conversions internally, so there's a good chance scale_cuda is a bit faster just cause of that. But the filter is not going to be the speed limit either way.
emmanuelux has joined #ffmpeg
<BtbN>
That's why it's so irrelevant. Unless your goal is to scale frames as fast as humanly possible, while not de/encoding anything, it would matter. But when do you ever do that?
SuicideShow has quit [Ping timeout: 264 seconds]
SuicideShow has joined #ffmpeg
emmanuelux has quit [Read error: Connection reset by peer]
Livio_ has quit [Ping timeout: 252 seconds]
emmanuelux has joined #ffmpeg
emmanuelux has quit [Read error: Connection reset by peer]
emmanuelux has joined #ffmpeg
emmanuelux has quit [Read error: Connection reset by peer]
emmanuelux has joined #ffmpeg
<Jiggy>
Turns out tytan652 has "no idea how much CUDA is usefull in FFmpeg" and only made it an option in his package since people complained about needing to use his ffmpeg package instead of the ffmpeg-cuda package they were using years ago
<Jiggy>
lol
<Jiggy>
I have not been knowingly using scale_npp so I'm gonna build without nvcc