ChanServ changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.1.1 is released
Fiji has joined #ffmpeg
kasper93 has quit [Ping timeout: 276 seconds]
minimal has joined #ffmpeg
kasper93 has joined #ffmpeg
ackyshake has joined #ffmpeg
ackyshake has quit [Ping timeout: 276 seconds]
xx has quit [Ping timeout: 264 seconds]
wobbol has quit [Ping timeout: 252 seconds]
_whitelogger has joined #ffmpeg
minimal has quit [Quit: Leaving]
<Guest40>
Hey, quick question for you all, is there a way to build current ffmpeg with support for an older NVENC version? I've installed the necessary SDK headers, and pkg-config can find them, but once I got it built it still throws an error during transcoding, looking for NVENC 12.2 rather than 11.1 (which is what I've got right now)
gebra has quit [Ping timeout: 276 seconds]
Fiji has quit [Ping timeout: 260 seconds]
<aaabbb>
Guest40: are you sure it's ffmpeg's fault and not a vdpau library or something?
<Guest40>
I'm pretty sure aaabbb
<Guest40>
Here, let me pull the error
<Guest40>
[h264_nvenc @ 0x5593004a25c0] Driver does not support the required nvenc API version. Required: 12.2 Found: 11.1
<Guest40>
[h264_nvenc @ 0x5593004a25c0] The minimum required Nvidia driver for nvenc is 550.54.14 or newer
<aaabbb>
are you not able to upgrade your nvidia driver?
<aaabbb>
because it might be that the older nvidia drivers just don't support nvenc
<Guest40>
(The error is in fact correct, 470.256.02 only supports CUDA 11.4. The card I'm using is not supported by new drivers)
<aaabbb>
ah
<Guest40>
It definitely supports NVENC, just old NVENC
<aaabbb>
it's possible that h264_nvenc just no longer supports the older api. if that's the case then you may need to use an older ffmpeg version
<Guest40>
Huh, I didn't think of that. I assumed it was FFMPEG as a whole that needed it
<aaabbb>
it might be but i assume that ffmpeg supported nvenc back when 47.256.02 was current
<aaabbb>
if it's a really old card then you might be better off just using software encoding though
<Guest40>
Well the configure script didn't refuse the option
<aaabbb>
because nvenc with h264 is really crappy, even for new cards
<Guest40>
(I am *definitely* not better with software encoding. Xeon 5150 is already unhappy about being alive, let along software transcoding)
<aaabbb>
fair lol
<aaabbb>
there may also be other utilities that can do nvenc with that older api, and then you can just pipe ffmpeg's output to them
<furq>
e.g. an older ffmpeg
<aaabbb>
yep then you can get the modern and demuxers and whatever you want, and then pipe it into an older ffmpeg that's just used to encode
<Guest40>
I did think about that, but I couldn't quickly find a standalone build and 5.1.x failed to build libplacebo
<aaabbb>
you don't need libplacebo, just build a minimal older ffmpeg with just nvenc support
<aaabbb>
for libplacebo you can use the newer ffmpeg
<aaabbb>
there will be a little bit of overhead because you've got to copy over a pipe and you can't do zerocopy but it's probably worth it
<furq>
not ideal if you're doing hwdec as well
<aaabbb>
but possibly doable since sw decoding is much easier than sw encoding
<aaabbb>
maybe there's a standalone btbn build that's 5.1.x?
<furq>
he doesn't do versioned builds but there are builds from 2023
<Hassan01>
I'd like to dynamically change the stream size
jab416171 has quit [Ping timeout: 252 seconds]
<Hassan01>
gemini to the rescue, [1] doesn't have timestamps because it's a png so need to add tpad
MisterMinister has quit [Ping timeout: 265 seconds]
jab416171 has joined #ffmpeg
jab416171 has quit [Ping timeout: 245 seconds]
microlappy has joined #ffmpeg
jab416171 has joined #ffmpeg
YUiNA has quit [Remote host closed the connection]
jab416171 has quit [Ping timeout: 245 seconds]
jab416171 has joined #ffmpeg
microlappy has quit [Quit: Konversation terminated!]
jab416171 has quit [Ping timeout: 245 seconds]
microlappy has joined #ffmpeg
microlappy has quit [Client Quit]
gebra has joined #ffmpeg
gebra has quit [Changing host]
gebra has joined #ffmpeg
jab416171 has joined #ffmpeg
jab416171 has quit [Ping timeout: 245 seconds]
squeaktoy has joined #ffmpeg
cantelope has joined #ffmpeg
utsweetyfish has quit [Ping timeout: 260 seconds]
squeaktoy has quit [Ping timeout: 248 seconds]
squeaktoy has joined #ffmpeg
bouchiba has joined #ffmpeg
<bouchiba>
hello i'm tryng to real time streaming a browser content using ffmpeg , x-server and audio are given by DISPLAY:0 and PULSE_SERVER=tcp:127.0.0.1:4713
<JEEB>
and yes if you actually have multiple DRM devices you may need to specify the one that you require, nothing wayland-specific about that as far as I can tell
JanC has quit [Ping timeout: 252 seconds]
<ralfalfa>
I can get that info too, but I have to run it like this: DRI_PRIME=1 LIBVA_DRIVER_NAME=radeonsi vainfo
<JEEB>
yea, so DRI_PRIME is mesa's env var for device selection
cers has quit [Ping timeout: 268 seconds]
JanC is now known as Guest8768
Guest8768 has quit [Killed (copper.libera.chat (Nickname regained by services))]
JanC has joined #ffmpeg
<JEEB>
DRI_PRIME_DEBUG=1 or so then adds debug prints regarding its decision logic (even if you don't then set DRI_PRIME itself), if you're interested how mesa picks the default
<JEEB>
but of course the intel vaapi driver is not in mesa, so that one wouldn't be affected I presume :P
<ralfalfa>
I got it to work!
<ralfalfa>
it seems that there was a problem with video filters
<ralfalfa>
something about the original h264 file
<ralfalfa>
Still, it's a chore to invoke it
JanC has quit [Ping timeout: 244 seconds]
ralfalfa has left #ffmpeg [WeeChat 4.5.2]
cers has joined #ffmpeg
cers has quit [Ping timeout: 276 seconds]
JanC has joined #ffmpeg
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg
System_Error has quit [Remote host closed the connection]
lavaball has quit [Ping timeout: 252 seconds]
squeaktoy has quit [Ping timeout: 245 seconds]
squeaktoy has joined #ffmpeg
cers has joined #ffmpeg
minimal has joined #ffmpeg
<johnjaye>
are any of the textbooks on ffmpeg usage worth buying?
<johnjaye>
there's 2 or 3 on amazon that have good reviews.
System_Error has joined #ffmpeg
ackyshake has quit [Quit: Soupy Twist!]
JanC has quit [Read error: Connection reset by peer]
yans has joined #ffmpeg
YUiNA has joined #ffmpeg
coldfeet has quit [Remote host closed the connection]
JanC has joined #ffmpeg
kasper93 has quit [Ping timeout: 252 seconds]
Traneptora has quit [Quit: Quit]
jrofd has quit [Ping timeout: 268 seconds]
coldfeet has joined #ffmpeg
kasper93 has joined #ffmpeg
BUSY has joined #ffmpeg
JanC is now known as Guest3876
Guest3876 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
JanC has joined #ffmpeg
jmcantrell has joined #ffmpeg
kasper93_ has joined #ffmpeg
kasper93 has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
kasper93_ is now known as kasper93
l4yer has quit [Ping timeout: 252 seconds]
l4yer has joined #ffmpeg
Shine_ has quit [Read error: Connection reset by peer]
kasper93 has quit [Quit: kasper93]
kasper93 has joined #ffmpeg
kasper93 has quit [Client Quit]
jmcantrell has quit [Ping timeout: 252 seconds]
kasper93 has joined #ffmpeg
kasper93 has quit [Client Quit]
kasper93 has joined #ffmpeg
kasper93 has quit [Client Quit]
kasper93 has joined #ffmpeg
kasper93 has quit [Client Quit]
kasper93 has joined #ffmpeg
kasper93 has quit [Client Quit]
kasper93 has joined #ffmpeg
Traneptora has joined #ffmpeg
coldfeet has quit [Remote host closed the connection]
user23 has quit [Ping timeout: 265 seconds]
catcream has quit [Remote host closed the connection]
catcream has joined #ffmpeg
EmleyMoor has quit [Ping timeout: 272 seconds]
EmleyMoor has joined #ffmpeg
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
ahc has joined #ffmpeg
TheSilentLink has quit [Quit: Good Bye! My bouncer has probably crashed or lost connection to the internet...]
jarthur has joined #ffmpeg
Sakura`Kinomoto has joined #ffmpeg
Sakura`Kinomoto has quit [Remote host closed the connection]
SakuraChan has quit [Ping timeout: 245 seconds]
sm1999 has quit [Quit: WeeChat 4.6.2]
Sakura`Kinomoto has joined #ffmpeg
sm1999 has joined #ffmpeg
Traneptora has quit [Quit: Quit]
sentriz has quit [Read error: Connection reset by peer]
sentriz has joined #ffmpeg
jmcantrell has joined #ffmpeg
Shuriko has joined #ffmpeg
JanC is now known as Guest1951
Guest1951 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
JanC has joined #ffmpeg
jrofd has joined #ffmpeg
hmyers has joined #ffmpeg
<hmyers>
Is it possible to use ffmpeg cli >=6 in single threaded mode similar to version 5? Multithreaded mode uses significantly more cpu for a live streaming workload.
<BtbN>
It makes zero difference when live-encoding something. The amound of work is kinda pre-set for that.
<BtbN>
*t
<kepstin>
there's potentially a bit of extra overhead from the extra synchronization needed, but i wouldn't expect "significantly more".
<hmyers>
it's significant. .8 vs 1.2
<kepstin>
what units is that in?
<hmyers>
%cpu from pidstat
<BtbN>
that's so low, it might as well be noise
<kepstin>
honestly, 0.8% to 1.2% is super low, and probably within measurement noise depending on video content.
<kepstin>
you doing hardware encoding or something?
<hmyers>
multiple that time 450 processes and it's more than noise
<hmyers>
no encoding. muxing to fragmented mp4
<kepstin>
what's the input?
<hmyers>
an rtsp stream
<BtbN>
The overhead from managing the threads and inter-locking between them could easy cause 0.2% of extra load
<BtbN>
But that ain't going away, even with -threads 1
<hmyers>
I think you've kinda answered my question and confirmed my pidstat results. The threading in this simple workflow adds cpu overhead. Multiply that by a large number of processes on a system that doesn't have a lot of cpu wiggle room under load, and I'm over the top
<BtbN>
the reality is, not many people will care about such a minisqule bump in overhead, given the massive amounts of speedup it generated in many other scenarious
<hmyers>
yeah I get that. one of the cases where I should write a program that uses the libs and not ffmpeg-cli for this particular case
<kepstin>
honestly, you should probably consider writing a custom application using the ffmpeg apis to handle your specific use case. You can almost certainly get down to lower overhead than the previous ffmpeg cli tool had.
<kepstin>
ffmpeg cli tool is a general tool for doing pretty much anything with ffmpeg, and the threaded input significantly expanded on things it is useful for, especially for live inputs.
<hmyers>
was curious if there was a way to get the old behavior, but I suspect the code has been signifiantly refactored, so using an older release or writing our own program is the answer.