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.2 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 264 seconds]
thilo has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
feiw has quit [Ping timeout: 252 seconds]
feiw has joined #ffmpeg-devel
deus0ww has quit [Ping timeout: 255 seconds]
deus0ww has joined #ffmpeg-devel
aikaeksen has joined #ffmpeg-devel
aikaeksen has quit [Quit: Client closed]
jamrial has quit []
Xaldafax has quit [Quit: Bye...]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 248 seconds]
Kei_N has joined #ffmpeg-devel
arch1t3cht2 has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 260 seconds]
arch1t3cht has quit [Ping timeout: 260 seconds]
arch1t3cht2 is now known as arch1t3cht
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
wellsakus has joined #ffmpeg-devel
feiw has quit [Ping timeout: 252 seconds]
feiw has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
cone-733 has joined #ffmpeg-devel
<cone-733>
ffmpeg Steven Liu master:74553f002694: tests/fate/mov: check mov formats build status be for make test
<cone-733>
ffmpeg Steven Liu master:f3fc7af9fd82: tests/fate/matroska: check the demuxer and decoder allyes before fate-matroska-side-data-pref-codec
<cone-733>
ffmpeg Steven Liu master:8f100a66a1dd: tests/fate/audio: set flcl1905 test case with depend formats,decoder,protocol
<cone-733>
ffmpeg Steven Liu master:7df89cc1eca6: tests/fate/libavcodec: add mjpeg encoder depend for fate-libavcodec-huffman
<cone-733>
ffmpeg Steven Liu master:2fb2cd5c79fc: tests/fate/mov: check mov and framemd5 has enabled when test
<cone-733>
ffmpeg Steven Liu master:eb20eff90319: tests/fate/seek: check seek opertation with mov demuxer and file protocol
<cone-733>
ffmpeg Steven Liu master:09580383c69d: tests/fate/cbs: refine depend prerequisites for cbs-h264-discard test
<cone-733>
ffmpeg Steven Liu master:75fbff117000: tests/fate/demux: refine depend prerequisites for fate-mov-mp3-demux
<cone-733>
ffmpeg Steven Liu master:6832134b7e09: tests/fate/cbs: refine depend prerequisites for cbs-hevc-discard test
<cone-733>
ffmpeg Steven Liu master:76ff97cef5b7: tests/fate/cbs: make cbs-vvc test depends prerequisites correct
tufei_ has joined #ffmpeg-devel
tufei has quit [Ping timeout: 260 seconds]
<Lynne>
we bump minor on new encoders/decoders, right?
<JEEB>
yes
<JEEB>
I think the developer.html page documents that
<elenril>
it's a pointless cargo cult though
<JEEB>
if the decoder or encoder doesn't have an externally exposed symbol, then indeed it's not required by semver, so we're mostly doing it to have some versioning on when a component was added
<wbs>
yes, but it's still moderately useful for being able to somewhat pinpoint versions inbetween actual releases
<JEEB>
of course with decoders and encoders you can just ask for it and if you get nothing back from the name query API the build doesn't have it
IndecisiveTurtle has joined #ffmpeg-devel
Xaldafax has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<cone-733>
ffmpeg Lynne master:0fa6f3387573: hwcontext_vulkan: add support for x2bgr10 and proper DRM mappings for 10-bit images
<cone-733>
ffmpeg Lynne master:37243b2a08ac: lavc: add Vulkan video encoding base code
<cone-733>
ffmpeg Lynne master:ceb471cfde90: lavc: bump minor version and add changelog for h264_vulkan
<Lynne>
whoever has control of twitter, could this get mentioned?
<Lynne>
phoronix reported that this was merged a month ago when it wasn't
<elenril>
>phoronix gets something wrong
<elenril>
shockedpikachu.jpg
<Lynne>
...there hasn't been a single thing I've written that they reported on that they DIDN'T make a mistake on
<Lynne>
I mean it, every signle time
<elenril>
then again serious publications like lwn don't report on us at all, so...
<llyyr>
for some reason they reported on me adding window titles and appid to winewayland, and even had a mistake in that
<llyyr>
congrats on vulkan encoding though
<Lynne>
its neat that you can go entirely with vulkan all the way from a compositor drawing to drm leased vk images, to you encoding those images directly
<llyyr>
I think you could remove radeonsi and still have everything working just fine now, except firefox which would require zink I suppose
<LaserEyess>
has there been any progress on the KHR side with vp9?
<jamrial>
elenril: can't seem to apply the v2 patch you sent. getting variations of "malformed patch at line X" or "error: patch fragment without header at line Y"
<jamrial>
can you update the branch in your repo?
<elenril>
just did
<elenril>
weird though, I just sent it with git send-email
<Traneptora>
JEEB: AV_CODEC_ID_FOO? isn't that an external symbol
<Traneptora>
iirc that's why we bump minor
<jamrial>
i tried the email as i got it in thunderbird, and also the "mbox" and "diff" ones from patchwork
<jamrial>
none would apply :/
<elenril>
must be the bunnies meddling again
<Traneptora>
jamrial: try downloading source?
<llyyr>
LaserEyess: apparently it's in the works, av1 encoding was just higher priority
<elenril>
who uses vp9 anyway
<elenril>
besides youtube
<llyyr>
exactly, youtube uses it and even though it's only one source I end up watching more vp9 videos and any other codec
<llyyr>
they have h264 for videos though, but not livestreams
<BtbN>
vp9s main issue is the lack of a widely available good encoder
<BtbN>
libvpx is a nightmare
<jamrial>
elenril: 4chan :p
<elenril>
well, no post-avc codec has that
<elenril>
jamrial: uh....
<LaserEyess>
elenril: youtube is like 10% of all internet traffic according to some sources
<LaserEyess>
I would consider vp9 support pretty significant
<jamrial>
only vp8 or vp9 in webm can be uploaded there
<wbs>
BtbN: btw, your response re the windows/arm64 build, you mentioned that it's highly experimental and breaks every other week - was that in response to the experimental gcc toolchain, or regarding arm64 builds in general?
<elenril>
>webm
<elenril>
must be like the only user
<BtbN>
wbs: arm builds for Windows in general/particular
<elenril>
or is youtube still using that as well?
<jamrial>
they are using it for vp9 still
<jamrial>
mp4 for h264 and av1
<BtbN>
I have not managed to cook up a working arm for windows gcc toolchain yet, though it's getting closer. The clang one generally works, but it combined breakage because "not gcc" with breakage because "arm for windows"
<llyyr>
there's sites that replace gifs with webms too
<BtbN>
arm builds for Linux are not a huge deal
<wbs>
BtbN: yeah, the gcc stuff for windows is way way way immature anyway, that one can be disregarded
<BtbN>
It generally works fine, the only issue at this point is openmp
<BtbN>
And yes, some of our deps insist on using openmp...
<wbs>
oh, ok... they have a bunch of lower level stuff "deferred", like actually matching the ABI that we've set down for aarch64 in mingw
<BtbN>
Microsoft has contributed support to gcc 15
<wbs>
yes, I know
<BtbN>
But not everything around gcc :D
<wbs>
the thing is.... for mingw stuff, originally gcc/binutils have done things however they have done it, kinda defining the quirks of the mingw/x86 environment. then llvm has come along and spent a lot of effort mimicing that. for aarch64, there was no existing gcc/binutils set of quirks to mimic, so we've laid out the ground for how aarch64 should work in mingw, together with llvm
<wbs>
now gcc/binutils comes along 7 years later - and one would hope that they would, you know, try to sync those details with the preexisting implementation
<wbs>
but they feel that's "not important"
<wbs>
so whenever they post a patchset to gcc/binutils, I have to babysit them to see they're not diverging more
<wbs>
the last few weeks I've had to tell them NO, on a combined binutils/gcc patchset with some bits that made zero sense
<BtbN>
Don't they all have to mimic msvc anyway?
<wbs>
where they, microsoft employees, suggested changes that break object file compatibility with llvm and msvc
<wbs>
so they wanted to change how an object file relocation works, to make it possible to reference a symbol + 4 GB offset range, when the standard for COFF-arm64 allows symbol+1MB offset
<wbs>
so for binutils, they propose a patch that breaks this, breaking compat with LLVM and MSVC. and then a patch to GCC to _not_ use symbol+offset, "because of relocation issues"
<wbs>
so if that relocation is broken and you're not going to use it, why change it in the first placae?
___nick___ has quit [Ping timeout: 276 seconds]
___nick___ has joined #ffmpeg-devel
<wbs>
and "don't they have to mimic msvc"? yes, and no. for basic object file stuff, it's in general mostly similar
<BtbN>
I got to try if ct-ng can spin up a toolchain now. It failed later and later every time I tried it
<wbs>
but for historical reasons, there are minor divergences... like if you have a dllexport symbol, you embed a "-export:<symbol>" directive into the object file. on i386, you have symbol prefixes
<wbs>
so mingw dllexport embeds "-export:func", while msvc dllexport embeds "-export:_func", for the same case
<wbs>
which makes object files just ever so slightly incompatible
<wbs>
there are around half a dozen such issues, and I'd like to avoid adding more
<wbs>
one other thing, is if you have a function that allocates a large stack frame, >4 KB, the compiler generates calls to a function "__chkstk" to probe the stack, to make sure there's enough allocated
<wbs>
well for historical x86 mingw, the function that gets called is ABI compatible with the MSVC one, but it's not named "__chkstk", it's called "_alloca" on i386 and "___chkstk_ms" on x86_64
<wbs>
so for aarch64, I've settled on using the same name "__chkstk" as MSVC does, because why diverge more when you can diverge less?
<wbs>
that particular bit, they haven't broken, yet (they just don't emit any function call at all yet, they expand it inline in the function prologue instead)
<wbs>
but then for the really big annoyment: on x86, MSVC has "long double" == 64 bit, equal to regular double. GCC has "long double" == 80 bit
<wbs>
which means that you cannot reuse any code from the Microsoft CRT or similar, for anything that touches "long double"
<wbs>
but as x86 _does_ have hardware support for 80 bit floats, I guess it's debatable which choice makes more sense - that's a train that has left too long ago anyway so one can't really easily reconsider that design aspect
<wbs>
for aarch64, there is no >64 bit float HW. so for aarch64/mingw, I chose to make "long double" equal to regular double - this is the same on apple platforms as well
<wbs>
but on linux, "long double" is a 128 bit softfloat
<wbs>
so now for 7 years, we have this laid down, aarch64/mingw has got long double equal to double
<wbs>
and when gcc comes along, one would hope that they would have the courtesy to try to match this established practice
<wbs>
so they have an issue in their github repo, "should we change long doubles to 64 bit?" which is deferred to later, not very important to them
<wbs>
also, switching it to 64 bit makes fewer tests in their gcc test suite pass, so they don't want to change that, and it requires more code in gcc than to stick with 128 bit softfloats
<wbs>
(while other, similarly experimental ports, like gcc for macos/arm64, has followed the platform ABI properly and does use 64 bit long doubles)
<wbs>
(so for those reasons, it also requires a bunch of patches on top of mingw-w64, that I'm not going to accept upstream there - they'll need to switch to match the established ABI if they want to work with mingw-w64 without custom patches)
ngaullier has quit [Read error: Connection reset by peer]
<haasn>
the straightforward way of adding chroma location to filter negotiation is a bit ugly in that it doesn't allow tying certain chroma locs to specific pixel formats
feiw has quit [Ping timeout: 248 seconds]
<haasn>
is there a filter/codec/whatever that needs e.g. center chroma for 420 but top chroma for 422?
feiw has joined #ffmpeg-devel
<haasn>
I guess in any case it isn't inconceivable that both might be tied together
<haasn>
maybe we can get around it by e.g. splitting up the horizontal from the vertical placement requirements
<haasn>
but eh
<haasn>
I'm not terribly happy about this either way
Traneptora has joined #ffmpeg-devel
<haasn>
AV_PIX_FMT_PAL8 is the only palette format we have, right?
<elenril>
yes
annemarie has joined #ffmpeg-devel
annemarie has left #ffmpeg-devel [#ffmpeg-devel]
ccawley2011 has quit [Ping timeout: 252 seconds]
psykose has quit [Ping timeout: 252 seconds]
__nick__ has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 272 seconds]
wyatt8740 has quit [Ping timeout: 260 seconds]
wyatt8740 has joined #ffmpeg-devel
<haasn>
I'm thinking about how we want to handle pallette formats in swscale
<haasn>
it seems like a proper/correct solution here would require being able to convert to arbitrary palettes
<haasn>
like some sort of dithering algo
<haasn>
so lacking an implementation of this, it's better to continue hacking around it using RGB8 like we do currently
<haasn>
but not in swscale proper
jarthur has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<Lynne>
we have palettization/depalettization code in lavfi if that would help
<haasn>
okey
<haasn>
will add proper PAR
<haasn>
PAL support to the list of swscale features*
compnn has joined #ffmpeg-devel
compn has quit [Read error: Connection reset by peer]
<haasn>
elenril: doesn't fftools have code to reinit the filter graph if the input frame params change midstream?
<haasn>
ohh nvm
<haasn>
the problem here is the use of the movie filter
<haasn>
and specifically the fact that it ignores the YUV metadata
<haasn>
in other news
<haasn>
avscale passes FATE
Sean_McG has joined #ffmpeg-devel
<Sean_McG>
ramiro: I'll see what I can do about getting my G5 online soon. It's been a bit of a challenge both technically and time-wise
__nick__ has quit [Ping timeout: 260 seconds]
___nick___ has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
kasper93_ has joined #ffmpeg-devel
any1_ has joined #ffmpeg-devel
fennewald_ has joined #ffmpeg-devel
kurosu_ has joined #ffmpeg-devel
aaabbb- has joined #ffmpeg-devel
SuperFashi_ has joined #ffmpeg-devel
another has joined #ffmpeg-devel
bencoh_ has joined #ffmpeg-devel
Daemon405 has joined #ffmpeg-devel
thilo_ has joined #ffmpeg-devel
thilo_ has joined #ffmpeg-devel
thilo_ has quit [Changing host]
Rodn3y has joined #ffmpeg-devel
Rodn3y has joined #ffmpeg-devel
Kei_N has quit [*.net *.split]
thilo has quit [*.net *.split]
kasper93 has quit [*.net *.split]
r0dn3y has quit [*.net *.split]
bbbccc has quit [*.net *.split]
kurosu has quit [*.net *.split]
any1 has quit [*.net *.split]
Daemon404 has quit [*.net *.split]
SuperFashi has quit [*.net *.split]
bencoh has quit [*.net *.split]
fennewald has quit [*.net *.split]
another| has quit [*.net *.split]
kurosu_ is now known as kurosu
any1_ is now known as any1
fennewald_ is now known as fennewald
IndecisiveTurtle has quit [Ping timeout: 265 seconds]