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
xx has quit [Ping timeout: 260 seconds]
arbitercoin has quit [Ping timeout: 255 seconds]
nd has joined #ffmpeg
CarlFK has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
Muimi has joined #ffmpeg
emmanuelux has quit [Quit: au revoir]
minimal has quit [Quit: Leaving]
<aaabbb>
question about the internal aac encoder. the -aac_coder flag default is twoloop, but the coding method "fast" says it uses a faster version of the twoloop algorithm which is worse at bitrates lower than 64kbps but is better at higher bitrates
<aaabbb>
is the documentation saying that "fast" is simply particularly bad <64kbps and not too bad >64kbps, or is it saying that "fast" is better than "twoloop" at >64kbps?
Keshl_ has joined #ffmpeg
Keshl has quit [Read error: Connection reset by peer]
Traneptora has quit [Quit: Quit]
Tano has quit [Quit: WeeChat 4.3.4]
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
ewomer has quit [Quit: WeeChat 4.4.2]
CarlFK has quit [Quit: Leaving.]
Suchiman has quit [Quit: Connection closed for inactivity]
Corroddi1 has quit [Quit: WeeChat 4.3.4]
Dagger has quit [Ping timeout: 265 seconds]
fling has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
fling has joined #ffmpeg
Dagger has joined #ffmpeg
hussein1 has quit [Remote host closed the connection]
hussein1 has joined #ffmpeg
sugoi has joined #ffmpeg
CarlFK has joined #ffmpeg
sugoi1 has joined #ffmpeg
sugoi has quit [Ping timeout: 246 seconds]
sugoi has joined #ffmpeg
sugoi1 has quit [Ping timeout: 245 seconds]
Vonter has quit [Ping timeout: 252 seconds]
grufwub has quit [Ping timeout: 276 seconds]
grufwub has joined #ffmpeg
HarryMcKenzie has quit [Quit: HarryMcKenzie]
Keshl_ is now known as Keshl
meinside has joined #ffmpeg
FH_thecat has quit [Quit: Leaving]
HarshK23 has joined #ffmpeg
rv1sr has joined #ffmpeg
sugoi1 has joined #ffmpeg
sugoi has quit [Ping timeout: 265 seconds]
sugoi1 is now known as sugoi
FH_thecat has joined #ffmpeg
fling_ has joined #ffmpeg
fling has quit [Ping timeout: 260 seconds]
Vonter has joined #ffmpeg
fling_ is now known as fling
CarlFK has quit [Ping timeout: 260 seconds]
FH_thecat has quit [Quit: Leaving]
FH_thecat has joined #ffmpeg
lavaball has joined #ffmpeg
Blacker47 has joined #ffmpeg
sugoi has quit [Ping timeout: 248 seconds]
HerbY_NL has joined #ffmpeg
Corroddity has joined #ffmpeg
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
Magissia has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #ffmpeg
Vonter has quit [Client Quit]
Vonter has joined #ffmpeg
Vonter has quit [Client Quit]
coldfeet has joined #ffmpeg
Vonter has joined #ffmpeg
gvg has joined #ffmpeg
xx has joined #ffmpeg
travisghansen4 has joined #ffmpeg
travisghansen has quit [Ping timeout: 252 seconds]
<snoriman>
Hey! I'm looking into IntelVPL for video decoding and curious if I'm lucky and that there is interop with OpenGL? My guts tell me that there is still no (cross platform) interop, but maybe someone knows more about this?
<JEEB>
if you want decoding utilize vaapi on linux and d3d11va on windows, instead of the intel-specific API. since it then utilizes underneath those two.
<JEEB>
this also allows supporting AMD with the same.
<JEEB>
and nvidia on windows since *all* vendors implement d3d11va
<snoriman>
I was thinking about using onevpl as it works both on Win/Linux; so I only have to focus on one API... or can I maybe simply use ffmpeg lib for that?
<JEEB>
yes you utilize the hwaccel selection based on pix_fmt when initializing the decoder
<JEEB>
either VAAPI or D3D11 one, specifically
<snoriman>
ah I see, thanks! so I (luckily don't have to worry about VAAPI)
<JEEB>
d3d11va is windows only, so if you want intel (and amd) on linux it's needed
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JEEB>
but yea, I know there is non-copy hwaccel for vaapi in mpv with opengl rendering, so I expect there is a way to import a vaapi picture into GL
<snoriman>
ah ok thanks! I'll check mpv
<JEEB>
also I think libplacebo's FFmpeg helper stuff implements VAAPI import as well
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg
cousin_luigi has joined #ffmpeg
<cousin_luigi>
Greetings.
<cousin_luigi>
Can I use ffplay with hwdecode?
<haasn>
michaelni: what name do you prefer, SwsContext2 or SwsScaleContext or maybe even something like SwsGraph (alluding to the fact that it internelly implements a more sophisticated operations graph)
<haasn>
I'm leaning towards SwsContext2, if not AVScaleContext
<haasn>
not only is it shorter but it also makes it clear that it's an upgrade with slightly different semantics
Vonter has quit [Ping timeout: 252 seconds]
Dagger has quit [Ping timeout: 246 seconds]
Dagger has joined #ffmpeg
welder has joined #ffmpeg
<haasn>
maybe prefixing all functions by sws2_ is overkill
<haasn>
but I'm worried about API confusion between v1 and v2 functions
<haasn>
well, I well keep the code as written for now (avscale prefix) until a discussion/vote can happen on the ML
HerbY_NL has joined #ffmpeg
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Dagger has quit [Ping timeout: 265 seconds]
Dagger has joined #ffmpeg
sugoi has joined #ffmpeg
sugoi has quit [Ping timeout: 264 seconds]
nasso has quit [Remote host closed the connection]
<michaelni>
haasn, if its intended to primarly represent a graph then SwsGraph is a good choice. I dont think anything can be confused, parts of the current API should either become deprecated and removed or updated and continued to be used
<haasn>
It's meant to replace sws_scale_frame
<haasn>
The problem mainly stems from functions like avscale_test_format which may be confused with sws_supportedOutput
function1 has quit [Ping timeout: 255 seconds]
EmleyMoor has joined #ffmpeg
<haasn>
if we rename it to sws_test_format
<haasn>
I can see format support diverging between the two
<haasn>
if we add support for more things to the new impl before the old is fully removed
<snoriman>
When I create a AVFormatContext/AVCodecContext, etc.. and initialize a hardware accel, is there a way to verify that it is actually using the hardware based decoder (e.g. when receiving frames) ?
coldfeet has quit [Remote host closed the connection]
dilaver_ has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
CarlFK has joined #ffmpeg
<DeHackEd>
assuming you select a specific codec (as opposed to auto-detection) make sure you select one for hardware. I'm pretty sure no codec supports software fallback. if the necessary hardware is missing or unsupported, it will fail.
<JEEB>
DeHackEd: proper hwaccel based things are the usual decoder + HW pix_fmt hwaccel setupp
<JEEB>
snoriman: I would not be surprised if it would somehow fail when trying to init the decoder if the format is not supported
Tano has joined #ffmpeg
rvalue- has joined #ffmpeg
rvalue has quit [Read error: Connection reset by peer]
rvalue- is now known as rvalue
hussein1 has quit [Remote host closed the connection]
hussein1 has joined #ffmpeg
sugoi has joined #ffmpeg
sugoi has quit [Ping timeout: 248 seconds]
Traneptora has joined #ffmpeg
HerbY_NL has joined #ffmpeg
lavaball has joined #ffmpeg
beastd has joined #ffmpeg
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg
System_Error has quit [Quit: Leaving]
System_Error has joined #ffmpeg
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
xx has quit [Ping timeout: 260 seconds]
xx has joined #ffmpeg
ewomer has quit [Read error: Connection reset by peer]
sugoi has joined #ffmpeg
ewomer has joined #ffmpeg
beastd has quit [Ping timeout: 272 seconds]
Kei_N has joined #ffmpeg
Kei_N_ has quit [Read error: Connection reset by peer]
Vonter has joined #ffmpeg
<snoriman>
JEEB: yeah I was looking at the hwaccel example and pixel format selection seems like an important things; besides initializing the right hwaccel type and setting the `hw_device_ctx` on the `AVCodecContext` there's not much to it, it seems at least.