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 6.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
clark_hung has joined #ffmpeg-devel
navirc has quit [Quit: WeeChat 4.0.4]
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
lexano has quit [Ping timeout: 245 seconds]
thilo has quit [Ping timeout: 240 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
<Traneptora>
zsoltiv_: you don't need to keep a copy of the first frame, just its PTS
<Traneptora>
if you need to hold onto a frame in order to do things, you can, but it costs a bit more memory
cone-696 has quit [Quit: transmission timeout]
feiw2 has quit [Remote host closed the connection]
feiw2 has joined #ffmpeg-devel
beastd has quit [Ping timeout: 268 seconds]
beastd has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
clark_hung has quit [Quit: Client closed]
jamrial has quit []
cone-551 has joined #ffmpeg-devel
<cone-551>
ffmpeg Frank Plowman master:7d7ba2175c9e: libavformat/vvc: Make probe more conservative
derpydoo has quit [Ping timeout: 252 seconds]
<cone-551>
ffmpeg Frank Plowman release/6.1:a888d21c8cfb: libavformat/vvc: Make probe more conservative
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
Xaldafax has quit [Quit: Bye...]
HarshK23 has quit [Quit: Connection closed for inactivity]
<Gramner>
wbs: or just compile with -wd4028 because that warning is plain wrong
<wbs>
Gramner: that is of course an option as well. apparently newer MSVC don't warn about it anyway
<wbs>
but still, we don't use that kind of extra const in the ffmpeg coding style (it's one of the things in dav1d I disagree with) :P
<Gramner>
ah. i may or may not have sent a bug report about it, don't remember. good thing they fixed it
<Gramner>
i personally like throwing in const everywhere. immediately being able to know that a variable will not change halfway through some block of code (or maybe more importantly, the lack of const implies that it will) makes code easier to quickly read and understand for me
<wbs>
yep; I understand that argument (I have a collegue who does that as well), but I dislike it nevertheless (it doesn't give me the same amount of value wrt code reading, it gets in the way when working with the code when you do want to modify it) - all of that is of course personal taste
<Gramner>
would've been nice to maybe have a shorter keyword i guess, it can make lines kinda long sometimes
<wbs>
that's for local variables, and parameters within function definitions. in function declarations/prototypes, const on things passed by value is just noise, and that annoys the hell out of me to have them there :-)
<wbs>
as you say, the compiler should just ignore differences in it, but when one creates a declaration by copying the first line of a definition, it happens so easily that these consts creep in in the headers, and there, they are more annoying when they end up there, inconsistent (based on however the function implementation looked when it was copied from there)
kurosu has quit [Quit: Connection closed for inactivity]
<Gramner>
agree, const in declarations is pure noise and adds nothing of value
<wbs>
like this case we have here. oops, it's inconsistent with the function definion, and old MSVC is OCD'y enough to complain about it. and then I realize I forgot to strip out these consts when porting these functions from dav1d :-)
<wbs>
if we'd have some sort of tooling to make sure we don't accidentally bring them into declarations, I'd be marginally more tolerant towards them :-)
<Gramner>
some pedantic compiler warning flag for that would be useful, yes. it's easy to just copy-paste things and miss that
<wbs>
anyway, I appreciate that the arguments for keeping it was correct and focused on readability. occasionally (potentially even from said collegue who likes to use such features) one would get the argument that the const attribute for these local scalar variables would help the compiler optimize it - but for local variables, the compiler already knows their entire lifetime so it really shouldn't matter
<wbs>
for a compiler, unless we're talking ...
<wbs>
... decades old compilers
derpydoo has joined #ffmpeg-devel
<BBB>
I guess I went a bit overboard trying to use const everywhere when we started dav1d... oops
<BBB>
sorry :)
<wbs>
NP :P
<BBB>
but there were some good things to it. the way the "frame" and "tile" state are separated from the "global" state (and const'ed) in dav1d is really pretty and prevents whole classes of threading bugs, IMHO
<BBB>
I'd love to see something like that in ffmpeg one day
<wbs>
yeah, most of the new stuff/style in dav1d is good. this is just a cosmetic annoyance :-)
<cone-664>
ffmpeg James Almer master:0a87bd02ee6c: avutil/iamf: add missing doxy to free functions
zsoltiv_ has quit [Quit: Left]
zsoltiv_ has joined #ffmpeg-devel
<wbs>
elenril: do you want to quantify "blessed" on the ML? :P
<Lynne>
(apart from the obvious issues, I wrote most of this, and a real marketing person said LGTM!)
Flat has quit [Ping timeout: 245 seconds]
Flat has joined #ffmpeg-devel
<JEEB>
Lynne: 'grats
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
kierank: could you post the link on X?
<JEEB>
also glad the AV1 extension is getting officialized
<Lynne>
soon, we can remove the header files in lavc
<kierank>
Lynne: done
<courmisch>
I feel undee attack
<courmisch>
elenril: the inconvenient truth is that, to take custom muteces into use, you first need to take custom CV into use
<courmisch>
elenril: but you didn't hear this from me!
<Lynne>
kierank: thanks
<courmisch>
wbs: const local variables is the way of Rust, so you could be argued to go against the flow
deadshot4141 has joined #ffmpeg-devel
<Lynne>
now available in C, via constexpr!
<BBB>
no vp9 encode? ;-(
<BBB>
nobody loves vp9
<BBB>
sad
<BBB>
I mean I'm not talking about dead """standards""" like vp3 or theora or vp8
<BBB>
but vp9 ain't so bad
<JEEB>
BBB: vp9 encoding was only added to some hardware
<BBB>
see? it exists
<BBB>
don't get me wrong, I understand h264 comes first. I wasn't born yesteryear
<BBB>
I even understand some crazies who think h265 is a thing (I personally wish it wasn't)
<BBB>
but if hevc is a thing, then so is vp9? it's not that bad
<elenril>
you could say the same thing about snow
<JEEB>
BBB: but HEVC encode is actually in hardware while VP9 encode is in a very limited set of things
<JEEB>
I think that's the primary reason
<JEEB>
unlike VP9 decode
<JEEB>
which is in various things
<BBB>
I suppose
<BBB>
sad :(
ccawley2011 has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
deadshot4141 has quit [Quit: Quit]
deadshot4141 has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
deadshot4141 has quit [Read error: Connection reset by peer]
Guest46 has joined #ffmpeg-devel
deadshot4141 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Guest46 has left #ffmpeg-devel [#ffmpeg-devel]
<courmisch>
elenril: arguing with NG during working hours is wasting somebody else's time, and I can't port muteces during working hours
<courmisch>
specifically, I wrote the message during lunch, and I can't port muteces during lunch
dellas has joined #ffmpeg-devel
cone-664 has quit [Quit: transmission timeout]
Krowl has quit [Read error: Connection reset by peer]
deadshot has joined #ffmpeg-devel
deadshot4141 has quit [Quit: Quit]
wyatt8750 has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 268 seconds]
Traneptora has quit [Remote host closed the connection]
wyatt8740 has joined #ffmpeg-devel
wyatt8750 has quit [Ping timeout: 260 seconds]
Oneric has quit [Quit: Connection lost]
kekePower has quit [Read error: Connection reset by peer]
Oneric has joined #ffmpeg-devel
kekePower has joined #ffmpeg-devel
kekePower has quit [Read error: Connection reset by peer]
kekePower has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
tmatth has quit [Read error: Connection reset by peer]
Manouchehri has quit [Ping timeout: 245 seconds]
jkkm has quit [Ping timeout: 245 seconds]
tmatth has joined #ffmpeg-devel
frankplow has quit [Remote host closed the connection]
uau has quit [Remote host closed the connection]
cosminaught has quit [Read error: Connection reset by peer]
cosminaught has joined #ffmpeg-devel
uau has joined #ffmpeg-devel
jkkm has joined #ffmpeg-devel
Manouchehri has joined #ffmpeg-devel
frankplow has joined #ffmpeg-devel
michaelni has quit [Ping timeout: 245 seconds]
bencoh has quit [Ping timeout: 245 seconds]
daddesio has quit [Ping timeout: 245 seconds]
bencoh has joined #ffmpeg-devel
<Lynne>
c23 is really neat, the overflow checks are convenient
<courmisch>
aren't they just renamed versions of GCC's ?
daddesio has joined #ffmpeg-devel
michaelni has joined #ffmpeg-devel
<Lynne>
they are, but they're official now
<beastd>
+1 (those things only provide real utility when they are in the standard, otherwise it's not a clear advantage except when you are limiting yourself to specific compilers)
<courmisch>
uh wut? you can always provide fallbacks. Not like FFmpeg is going to require C23 compilers any time soon anyway
<courmisch>
gcc 4.4 still listed on FATE
deadshot has quit [Quit: Connection closed for inactivity]
<Lynne>
the biggest advantage is I'm lazy, and when I'm writing something new and I can't reuse code due to more licensing, I don't have to reinvent stuff
<beastd>
courmisch: sure
<Lynne>
...I really wish they'd introduce a fractional reduce function though
<beastd>
courmisch: but at some point requiring C23 is probably ok and for some (new) projects it might be ok soon after the standard is done
<courmisch>
since it does not even require C11 yet, that won't be before 2038
<beastd>
also implementing fallbacks is particularly what I meant when saying not providing real utility
<courmisch>
I think it's very useful. You can use GCC and Clang's intrinsics as fallback and that will get you performance improvements on anything of signficance, as well as better code legibility
<courmisch>
you only use the dumb fallbacks for proprietary compilers that nobody cares about
<Lynne>
shame you need a configure check for it for now, since it's c23 that adds a macro to check for header existence
<courmisch>
and I would probably not use C if I started a new project in 2024
<Lynne>
rust?
<courmisch>
me, yes
<beastd>
courmisch: That's your choice of course. Though I think there are enough reasons to choose it and enough projects have reason to upgrade.
<Lynne>
when you're into security, rust is probably the only way to be taken seriously these days
<beastd>
Depends on what the problem is mostly
<Gramner>
does rust have a spec yet, or is all behavior still defined as "whatever the (singular) compiler does"?
<Lynne>
for everything else, you'd be taken unseriously if you used rust according to me though
<beastd>
:D
<Lynne>
have fun spending months on safe wrappers on top of unsafe code just to slice a buffer into mutable chunks
<beastd>
Regarding security: At least we get memset_explicit in C23
<courmisch>
well actually, in my experience, Rust integrates better with asm than C does
<beastd>
courmisch: Can you explain why? Just curious.
<courmisch>
1) support for naked functions
<courmisch>
2) much better and more flexible inline assembler syntax
<courmisch>
in fact, naked functions make outline assembler mostly useless
Venemo has joined #ffmpeg-devel
<courmisch>
Lynne: judging from the recruitment spam, Rust is mostly used in cloud and in safety-critical stuff (such as automotive), not so much security
<beastd>
Sounds cool, but you and others know more about mixing in ASM than me. Just looked it up bit.
deadshot has joined #ffmpeg-devel
<courmisch>
for automotive, if the alternative to Rust is MISRA C, no wonder devs prefer Rust
bencoh has joined #ffmpeg-devel
bencoh has quit [Changing host]
<Lynne>
go, then?
<beastd>
IIUC popular python cryptography package switched partially to rust for ASN1 parsing. Also there is an TLS implementation rustls. Only things I noticed without actively searching. So probably incomplete
<courmisch>
I'm not sure if Go has much to sell over Rust nowadays, but I am not familiar with it
<courmisch>
and I don't think Go works on bare metal?
<JEEB>
go was simple to do http stuff in
<beastd>
"Philosophy" in Go and Rust seems quite different. And on bare metal it will be hard with GC etc
<JEEB>
and bunch of stuff in stdlib
<JEEB>
which is different to rust yea
<courmisch>
no_std Rust is much nicer than free-standing C, though conceptually similar.
<courmisch>
The downside is that you can't escape writing unsafe code on bare metal
<beastd>
I have seen some arguing for Rust on micro controllers on a recent embedded conference. Looks interesting if one dares to but not really fully convincing. Also depends a lot on the application.
<courmisch>
compiled Rust code may be 2-3x larger than C due to aggressive inlining/specialisation and runtime error checks
<courmisch>
so not ideal for the tiniest microcontrollers
<beastd>
Lynne: What do think about (partial) constexpr in C23?
Sk0tik has joined #ffmpeg-devel
<Lynne>
beastd: I don't get them yet
<Lynne>
you can't use them for functions
<Lynne>
I don't know where to use them yet
<beastd>
Same here. Don't get it. Will need to have a closer look sometime...
<Lynne>
I don't get the benefits of char8_t yet either
<Lynne>
not sure why you'd want to know the sign of chars in a utf8->utf32 function
Traneptora has joined #ffmpeg-devel
Traneptora has quit [Remote host closed the connection]
epony has quit [Remote host closed the connection]
<nevcairiel>
if you hide changes in an otherwise named commit, you are on a mission
<nevcairiel>
nevermidn that lto feels like one of those things people talk about but it benefits very little
<JEEB>
and with issues with LTO you never know
<JEEB>
is it the code, or is it the compiler or is it the linker? or is it some option you gave to one of them?
<nevcairiel>
if its even a lto related issue and the person isnt on something else
<wbs>
that looks like building with llvm-mingw; I'm aware of some issues surrounding LTO (which should be fixed for the next major release), but those show up as linker errors, and I doubt that it hits specifically that decoder
<wbs>
however, a LTO build can probably break some cases of UB which is normally benign as long as things are compiled in separate object files
<BtbN>
full-tree LTO of ffmpeg with gcc works fine for Linux at least
<BtbN>
but I obviously did not test every last line of code
philipl has quit [Quit: leaving]
<wbs>
I haven't tested ffmpeg built with LTO with llvm-mingw though, I guess I could do that, and if something actually fails, I guess I could be capable of creating a more constructive bug report than those comments there...
<wbs>
or maybe fix the bug if it is in the toolchain itself
<JEEB>
BtbN: yea normal LTO (seemingly with gcc) is on FATE
<JEEB>
wbs: yea it's unfortunate how little details there are looking at the commit log... maybe the PR that possibly was there for that change has more context but I'll be honest I was not really /that/ interested in attempting to look into that after the commit message itself lacked info
<BtbN>
JEEB: I LTOd literally every single dependency together with ffmpeg
<BtbN>
except for glibc
<JEEB>
:)
<Lynne>
neat, c17 added bsearch
<Lynne>
err, lol, it was always there? wonder why no one uses it
<JEEB>
yea it's been there for ages
<JEEB>
lol, I like the notes that cppreference has for that
<JEEB>
> Despite the name, neither C nor POSIX standards require this function to be implemented using binary search or make any complexity guarantees.
<JEEB>
did not know that
<JEEB>
huh, so C23 added type-generic macros and deprecated direct function usage?
<BtbN>
I'm about to rip out JpegXL support from my builds... it's just perpetually broken, wtf
<wbs>
Oh, lovely, the same dude claims that I'm "very interested" in doing LTO of all the base toolchain files (like the CRT startup/glue code); yes I've actively worked on fixing bugs in such configurations, but it's not something I foresee giving any actual benefit anywhere
<Lynne>
BtbN: ABI breakage?
<BtbN>
no, I just can't get the thing to link
<BtbN>
their pkg-config file is perpetually broken. In a different way every other week