BtbN 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.0 is released
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Quit: Hackerpcs]
Hackerpcs has joined #ffmpeg
Icedream has quit [Quit: A lol made me boom.]
Hackerpcs has quit [Max SendQ exceeded]
Icedream has joined #ffmpeg
prekk has quit [Quit: prekk]
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 252 seconds]
Hackerpcs has joined #ffmpeg
hbbs has quit [Ping timeout: 252 seconds]
hbbs has joined #ffmpeg
emanuele6 has quit [Ping timeout: 265 seconds]
emanuele6 has joined #ffmpeg
yans has quit [Quit: Let us play... Hide and Slay!]
lucasta has quit [Remote host closed the connection]
kasper93 has quit [Ping timeout: 252 seconds]
lexano has quit [Ping timeout: 260 seconds]
Warcop has quit [Remote host closed the connection]
FH_thecat has quit [Ping timeout: 264 seconds]
bertieb has joined #ffmpeg
Sketch has quit [Read error: Connection reset by peer]
JanC_ has joined #ffmpeg
JanC is now known as Guest757
JanC_ is now known as JanC
Guest757 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
Sketch has joined #ffmpeg
jarthur has quit [Quit: jarthur]
militantorc has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
Suchiman has quit [Quit: Connection closed for inactivity]
beaver has joined #ffmpeg
Dagger has quit [Ping timeout: 244 seconds]
Dagger has joined #ffmpeg
beaver has quit [Remote host closed the connection]
rpthms has quit [Remote host closed the connection]
<MisterMinister>
Greetings! Would anyone know any details regarding changing setpts via ZMQ while processign live feed? looking to adjust setpts of an overlay file to start its playback at 22 sec. zmq reports "38 Function not implemented", after executing `echo "setpts@1 setpts PTS-STARTPTS+22/TB"|zmqsend` FFmpeg: ` -i $duck_rtp -an -i $overlay1 -filter_complex "[0:v]setpts=PTS-STARTPTS[pv];[1:v]fps=fps=30,
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vlm has joined #ffmpeg
vincejv has joined #ffmpeg
lavaball has quit [Quit: lavaball]
coldfeet has quit [Remote host closed the connection]
<viric>
Hello...
<rv1sr>
hi
<viric>
It appears that, when using -hwaccel vaapi, the decoders are initialised before hw_accel is set to ctx
<viric>
Basically I want the vaapi hw mjpeg decoder to decode to nv12, to then download nv12
<viric>
But the mjpeg decoder initializes deciding to output to yuv422p (in hw)
<viric>
Therefore I'm adding a nv12->yuv422p conversion in hw, when downloading.
<JEEB>
is your JPEG 4:2:0 or 4:2:2?
<viric>
422
<JEEB>
well then not getting 420 NV12 from the decoder is correct, since a decoder should not do color space conversions (at least not by default) :)
<viric>
I'd like that the vaapi mjpeg decoder initialised the vaapi surfaces to nv12, my target format
<viric>
When mjpegdec decides the pix_fmt yuv422p it's before avctx->hw_accel is set.
<viric>
so it cannot ask the hwaccel "what is the best output format for you"
<viric>
I cannot find how can I tell to the vaapi mjpeg decoder that it outputed to nv12 vaapi surfaces.
MrZeus has joined #ffmpeg
<viric>
I think that's actually hardcoded... that the vaapi surfaces for mjpeg decoding are in the format the mjpeg software decoder decided.
<viric>
avctx->sw_pix_fmt is set to that, in decoder.c
lavaball has joined #ffmpeg
<viric>
ahh the hw cannot decode to nv12.
MrZeus has quit [Read error: Connection reset by peer]
<BtbN>
decoders will almost always give you the format of the input, in whatever pixel format they prefer
<BtbN>
conversion then happens afterwards
<viric>
but the vaapi decoders allow multiple output pixfmts
<viric>
without any particular preference.
<BtbN>
If there's multiple formats to represent the pixels, sure
<BtbN>
but it won't do any conversion
<viric>
For example, if I supply a 4:2:0 mjpeg, nevertheless the vaapi decoders can output only to 422, 440 or 440
<BtbN>
the easiest is probably to just let the decoder pick its preferred format, and then convert to what you want
<viric>
I wanted to save a bit of bandwidth
<viric>
because I'm hitting the limit.
<BtbN>
bandwidth?
<viric>
I'm converting to nv12 not because I want nv12, but because vaapi doesn't allow downloading the frame to cpu memory in 422.
<viric>
BtbN: I mean that all together makes my vaapi h264 encoder drop frames. intel_gpu_top shwos the rendering close to 100%
<BtbN>
rendering is not the encoder though
<viric>
I think the vaapi conversions (after decoding mjpeg) get reported as 'rendering'
<viric>
it's my guess.
<BtbN>
But that's after decoding?
<viric>
yes
<BtbN>
What are you actually trying to do?
<viric>
I'm running obs
<viric>
v4l2 mjpeg -> vaapi yuv422 -> downloaded as nv12 -> rendered -> sent to vaapi h264 encoder
<viric>
obs can only operate on cpu-memory frames, for rendering.
<BtbN>
The rendering in that scenario will be OBS composing the scene more than anything
<viric>
yes
<BtbN>
not some relatively trivial pixel format conversion
<viric>
it would be best if obs knew how to work with vaapi frames and we could save the cpu downloading
<viric>
+ reuploading them again
<BtbN>
It can only do that with d3d11 frames
<BtbN>
vaapi and all the other various Linux-APIs are too volatile for something like OBS
<viric>
what do you mean volatile?
<BtbN>
you just experienced yourself how wonky the whole API is.
Haxxa has joined #ffmpeg
<BtbN>
It behaves vastly differently depending on the exact hardware and vendor
<BtbN>
Also throw in driver version into the mix
<BtbN>
There's a reason Firefox took a lot of years to enable vaapi support, and even now has a very limited whitelist of known-working hw+driver combos
<viric>
unfortunate
<viric>
is it so difficult? I think vaapi allows converting to a gl texture and that'd be all
<BtbN>
it allows it if the driver supports it, and when it does, you need to implement quirks that depend on the exact driver and hardware
<viric>
oh
<BtbN>
Anything vaapi is never straight forward and just works. The API is super annoying to deal with.
<BtbN>
And OBS itself is programmed with d3d11 in mind first, so features like that on Linux/OSX are a lot harder to implement
<BtbN>
It's not impossible by any means, but a lot harder
<viric>
I see
<BtbN>
And VAAPI in general is just a pain
<BtbN>
so specially for something like mjpeg, which a CPU can deal with quite easily, I doubt anyone would make the effort
lavaball has quit [Remote host closed the connection]
makidoll has joined #ffmpeg
Tinos has quit [Ping timeout: 256 seconds]
SuicideShow has quit [Ping timeout: 248 seconds]
SuicideShow has joined #ffmpeg
pikapika_lunar has joined #ffmpeg
edman007_ has joined #ffmpeg
edman007_ is now known as edman007
pikapika_lunar is now known as militantorc
<edman007>
Is there a full and complete list of deprecations and deletions in the API? I found this https://raw.githubusercontent.com/FFmpeg/FFmpeg/master/doc/APIchanges but it seems to be missing a bunch of things (cur_dts removal from AVStream is missing as is the removal of avcodec_encode_video2() )
<edman007>
I'm trying to update something to build with a modern ffmpeg, that apperently hasn't worked right with 4.0... and finding docs for what the replacement was for the old API is a little painful