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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue has quit [Ping timeout: 264 seconds]
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
rvalue has joined #ffmpeg-devel
lexano has quit [Ping timeout: 268 seconds]
tufei has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
cone-501 has quit [Quit: transmission timeout]
dellas has quit [Remote host closed the connection]
iive has quit [Quit: They came for me...]
guest745 has joined #ffmpeg-devel
philipl has quit [Ping timeout: 268 seconds]
philipl has joined #ffmpeg-devel
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
guest745 has quit [Remote host closed the connection]
navi has quit [Quit: WeeChat 4.1.2]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
jamrial has quit []
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 264 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 268 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
Marth64 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg-devel
elastic_dog has quit [Ping timeout: 268 seconds]
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 260 seconds]
elastic_dog has joined #ffmpeg-devel
Flat has joined #ffmpeg-devel
Flat_ has quit [Quit: Rip internet]
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
derpydoo has quit [Ping timeout: 260 seconds]
Krowl has quit [Read error: Connection reset by peer]
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Ping timeout: 264 seconds]
haihao has quit [Ping timeout: 264 seconds]
haihao_ has joined #ffmpeg-devel
blb has quit [Ping timeout: 268 seconds]
blb has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
haihao_ has quit [Ping timeout: 256 seconds]
cone-789 has joined #ffmpeg-devel
<cone-789> ffmpeg Marton Balint master:71ea90638efa: avutil/thread: fix pthread_setname_np parameters for NetBSD and Apple
ngaullier has joined #ffmpeg-devel
haihao has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 246 seconds]
<elenril> so nice how that function has so many flavors
<JEEB> "beloved child has many names"
ccawley2011 has joined #ffmpeg-devel
crm has joined #ffmpeg-devel
bcheng has quit [Ping timeout: 268 seconds]
orthoplex64 has quit [Ping timeout: 268 seconds]
q66 has quit [Ping timeout: 268 seconds]
thilo has quit [Ping timeout: 268 seconds]
bcheng has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
q66 has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<wbs> elenril: well, it's _np, aka nonportable, so what does one expect - everybody has their own take
<elenril> yeah, there was a reason I didn't bother implementing it beyond linux
<elenril> i had one look at all the flavors and noped out of there
crmur__ has joined #ffmpeg-devel
chainik10 has joined #ffmpeg-devel
ocrete8 has joined #ffmpeg-devel
signalhunter8 has joined #ffmpeg-devel
Sebastinas_ has joined #ffmpeg-devel
bcheng_ has joined #ffmpeg-devel
jkhsjdhjs_ has joined #ffmpeg-devel
llyyrr has joined #ffmpeg-devel
wyatt8750 has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
TheAMM has joined #ffmpeg-devel
AMM has quit [Killed (NickServ (GHOST command used by TheAMM))]
skinkie has joined #ffmpeg-devel
gnafu_ has joined #ffmpeg-devel
TheAMM is now known as AMM
bencoh_ has joined #ffmpeg-devel
darkapex_ has joined #ffmpeg-devel
thilo_ has joined #ffmpeg-devel
thilo_ has quit [Changing host]
thilo_ has joined #ffmpeg-devel
deer2 has joined #ffmpeg-devel
bencoh_ has quit [Changing host]
bencoh_ has joined #ffmpeg-devel
guest745 has joined #ffmpeg-devel
MetaNova has quit [Killed (silver.libera.chat (Nickname regained by services))]
MetaNova has joined #ffmpeg-devel
thilo has quit [*.net *.split]
bcheng has quit [*.net *.split]
crm has quit [*.net *.split]
darkapex has quit [*.net *.split]
wyatt8740 has quit [*.net *.split]
chainik1 has quit [*.net *.split]
Sebastinas has quit [*.net *.split]
deer1 has quit [*.net *.split]
ocrete has quit [*.net *.split]
signalhunter has quit [*.net *.split]
llyyr has quit [*.net *.split]
bencoh has quit [*.net *.split]
gnafu has quit [*.net *.split]
skinkie_ has quit [*.net *.split]
jkhsjdhjs has quit [*.net *.split]
haxar has quit [*.net *.split]
bcheng_ is now known as bcheng
ocrete8 is now known as ocrete
jkhsjdhjs_ is now known as jkhsjdhjs
llyyrr is now known as llyyr
signalhunter8 is now known as signalhunter
chainik10 is now known as chainik1
<elenril> can anyone test my c11 patch on weird platforms like windows?
<JEEB> I can see after $dayjob if my MSVC setup still works
* JEEB hasn't utilized it in quite a while
haxar has joined #ffmpeg-devel
Sebastinas_ is now known as Sebastinas
<ramiro> JEEB: I use the developer image from microsoft under vmplayer whenever I need it. It's 20+gb but easy to setup and throw away.
<wbs> I run msvc on linux, with http://github.com/mstorsjo/msvc-wine
<wbs> plus testing with wine - with that I think even elenril himself could try it out? ;-)
<ramiro> there's a long way between "could" and "would want to" :)
<elenril> I guess I try running that in my gaming container
<wbs> well, he wants someone to try it, and he could be able to cut out the middleman here :-)
<elenril> not sure I'm confortable with installing microsoft stuff in my actual dev container
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
<JEEB> wbs: yea wine actually should actually work pretty well. you just need the sysroot & stuff. if the installer works nicely under wine then that should be pretty simple, too
<JEEB> ramiro: oh right they have those dev VMs; those should be nicely fire&forget
<wbs> JEEB: that repo of mine, it doesn't run the MSVC installer in wine
<wbs> JEEB: it's a reimplemented MSVC installer, which fets the manifest of what components to install, then downloads and unpacks them, no wine needed at all for that
<JEEB> ahh download & unpack :D finally read got to that point
<JEEB> yea that's pretty cool.
<wbs> plus a set of wrappers around cl.exe and similar, that do invoke wine to run it, so they look and behave mostly like regular unix build tools
<JEEB> and really cool that normie clang works with the headers and libs if someone wants to compile with official SDK like that
<wbs> yep
<cone-789> ffmpeg Anton Khirnov master:931192226b75: fftools/ffmpeg_mux: fix terminating muxer on streamcopy with -t
<cone-789> ffmpeg Anton Khirnov master:f80d91c05112: tests/fate/ffmpeg: add a test for the issue fixed in previous commit
<elenril> i wonder how many more 'fails to terminate when using -t together with -ss on a full moon' are there
thilo_ has quit [Quit: WeeChat 2.8]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
user1453 has joined #ffmpeg-devel
guest745 has quit [Remote host closed the connection]
guest745 has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 268 seconds]
<rodeo> Presumably the number of fixable bugs related to such issues is finite at a given point in linear time?
<jamrial> maybe he made it private
<jamrial> whatever the case, it's a shitty situation
<kierank> I have my troll fork
Wenbin_Chen has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
Wenbin_Chen_ has quit [Ping timeout: 264 seconds]
bencoh_ is now known as bencoh
lexano has joined #ffmpeg-devel
<haasn> shouldn't AV_NOWARN_DEPRECATED be redefined as AV_NOWARN_DEPRECATED(...) with __VA_ARGS__ ?
<haasn> or else how are you supposed to do AV_NOWARN_DEPRECATED(const enum AVPixelFormat yuvj_formats[] = { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, ... };)
Krowl has quit [Read error: Connection reset by peer]
omegatron has joined #ffmpeg-devel
rooisnoek has joined #ffmpeg-devel
<Lynne> does anyone have the latest full librempeg repo I can pull from?
<Lynne> I need the ac4 branch
<BBB> what is all this fuss about librempeg
<BBB> is this the new meme?
<jamrial> BBB: paul's fork on github
<BBB> why does anyone care
<jamrial> where he's been pushing his work for the past few weeks
<BBB> good for him
<BBB> why do you care
<BBB> why are we talking about his fork here
<kierank> because one of the STF tasks is "merge pauls fork"
<kierank> but the word paul is not mentioned
<BBB> fun
<jamrial> kierank: so it's confirmed it's that or not?
<kierank> no idea
<jamrial> and i'm not worried about that
<jamrial> i'm worried about paul just outright going awol
<jamrial> that fork on github at least got some activity from him
<kierank> for a few weeks yes
<kierank> but he stopped recently
<jamrial> yes, hence, shitty situation
<jamrial> losing him sucks
<kierank> well imo he's annoyed because he dislikes fflabs (fine, he's entitled to his own views) but the STF drama is essentially an fflabs proxy war
<kierank> that should not be on the ml
<jamrial> why does he dislike fflabs so much?
<kierank> he feels it's taking money that should go to him
<jamrial> i'm fairly sure fflabs has offered him work
<elenril> kierank: I am not so sure about that
<elenril> he has been offered paid work multiple times
<kierank> I don't disagree, I have offered him some paid work too
<kierank> and not small paid work
<elenril> and has never shown actual interest
AntimaD has joined #ffmpeg-devel
<elenril> my impression is more he just wants to bitch
<haasn> BBB: he had a bug fix for one of the testsrc that I was asked to cherry pick
<haasn> on trac
<haasn> but it's gone
<elenril> and/or vent about his personal problems
<kierank> yes he wants attention too
<BBB> exactly
<kierank> that used to be isolated to pmming me about how much he hated fflabs
<jamrial> elenril: he legit was not happy about the slowness of small packets the recent cli work generated, but i have no idea if you recent fix addressed his concerns or not
<kierank> but he put me on ignore in january and sent everything to the ml and main channel
<BBB> slowness of small packets is such a non-issue. it's just a big number that makes headlines but it has no practical significance to almost anyone
<BBB> I mean, if you care, shut up and fix it
<BBB> it's the bitching that is so suboptimal
<BBB> I don't understand we're trying to humour his misbehaviour
<elenril> because HE MIGHT LEAVE
<jamrial> i'm not trying to humor his misbehaviour. i'm trying to make him stop it
ngaullie has quit [Read error: Connection reset by peer]
<elenril> people have tried fir years
<elenril> at some point you have to accept it's a lost cause
<BBB> if we can't fix him, maybe it's better to let him leave then
<BBB> or are you trying to gauge interest for a goodbye party?
<BBB> I'll be present
<elenril> he needs professional help, we can't fix him
<BBB> bye paul, or whatever that might've been a pseudonym for
<BBB> ok, can we move on now?
<wbs> BBB: iirc he may be annoyed that there's some other project somewhere, claiming to have the fastest audio decoders, faster than ours - I think he's pushing for some improvements on our ffts which would flip us into being faster again - and the ffmpeg cli multithreading might be muddying these numbers
<Lynne> that was a little insensitive, you can't just speculate and pin it all on wanting attention
<Lynne> but regardless, he did do some good work in his fork, which I'd like to have
<BBB> it's funny that in a discussion about paul, we're the ones supposedly being insensitive
<Lynne> he may be out, or just out for now, but he's still a part of the community enough that the community committee shouldn't look kindly upon comments like that
<haasn> what does it mean when AVCodec.pix_fmt is set for a decoder?
<haasn> shouldn't it be for encoders only?
<JEEB> > decoding: Set by user if known, overridden by libavcodec while parsing the data
Krowl has joined #ffmpeg-devel
<JEEB> so something which would only get utilized if the probing or whatever isn't able to figure it out?
<JEEB> as soon as the decoder gets in there it would get overridden
<BBB> Lynne: I agree regarding his contributions btw. I've often repeated to him that I respect his contributions and think he's a great dev. I also encouraged him to do more of the online presentation that he did at vdd23. I don't think I was ever insensitive to him. but yes I can often be (brutally?) honest and I have real problems with paul's (or nicolas') behaviour
<haasn> JEEB: I mean AVCodec.pix_fmts, not AVCodecContext.pix_fmt
<kierank> I negotiated with him for weeks to get a vdd presentation
<JEEB> haasn: ahhh, durr
cone-789 has quit [Quit: transmission timeout]
<haasn> it doesn't seem as though any other decoders set it
<haasn> except ff_svq3_decoder
<JEEB> yea in theory it would be a way of exposing what pix_fmts are supported by the decoder, but indeed it is probably not that utilized since I bet everything just checks avctx value after init
<JEEB> since what is relevant during usage is what the pix_fmt of the content is that you're trying to decode
bocci has joined #ffmpeg-devel
cone-878 has joined #ffmpeg-devel
<cone-878> ffmpeg Nuo Mi master:88a040386a0e: avcodec/vvcdec: fix seeking for open GOP
<cone-878> ffmpeg Niklas Haas master:789109ab2177: avfilter/vf_tiltandshift: check outlink->color_range
<haasn> (huh how come it logged 2 commits instead of just 1, Nuo Mi was already on origin/master)
dellas has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
rooisnoek has quit [Remote host closed the connection]
<nevcairiel> there is 12 minutes between the logs, it was just pushed before yours
<haasn> ah
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
marcj has quit [Ping timeout: 252 seconds]
<kierank> elenril: see your email
dellas has quit [Ping timeout: 260 seconds]
dellas has joined #ffmpeg-devel
gnafu_ is now known as gnafu
qeed_ has quit [Quit: qeed_]
AntimaD has quit [Ping timeout: 260 seconds]
j45 has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
TheSashmo has joined #ffmpeg-devel
AntimaD has joined #ffmpeg-devel
AntimaD has quit [Client Quit]
AntimaD has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<mkver> elenril: If a BSF decided to output packets with varying stream_ids (even when the input packets had only one), how would ffmpeg react?
<JEEB> if that stream id was not there during init, ffmpeg would log that there was a packet received for an unknown stream and ignore them
<JEEB> at least in ffmpeg_demux: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg_demux.c;h=60dc9620c2a7da208a43bd6c297334be783bbc18;hb=HEAD#l738
<JEEB> for after demux I don't recall
<JEEB> this seems to be the output bsf logic https://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg_mux.c;h=e65fe89992ef05cfb465d7fd79eee44777d8c5ad;hb=HEAD#l321
<mkver> Seems like write_packet() simply in ffmpeg_mux.c simply overwrites the packet's stream_index with the output AVStream's id.
darkapex_ has quit [Quit: WeeChat 3.8]
darkapex has joined #ffmpeg-devel
epony has quit [Quit: QUIT]
<elenril> kierank: not sure if lol or bsf
<kierank> bsf?
<elenril> erm
<elenril> or wtf
<elenril> mkver: the contents of AVPacket.stream_index are undefined for anything except muxing and demuxing
<mkver> Yeah. So this information from the BSF would be ignored.
<elenril> I don't think it will be in ffmpeg_demux currently
<elenril> because it's set before bitstream filtering
<elenril> I'd argue that's a bug in ffmpeg CLI though
Krowl has joined #ffmpeg-devel
<mkver> Why are there BSFs in ffmpeg_demux.c and ffmpeg_mux.c?
<jamrial> extract_extradata?
<mkver> When doing demux->decode->encode->bsf->mux, the bsf needs to be in ffmpeg_mux.c, but what bsfs are in ffmpeg_demux.c?
<mkver> jamrial: This is fftools, not lavf.
<jamrial> no wait, ffmpeg_demux. misread
<jamrial> yeah
<jamrial> the demux ones were added by anton recently
<elenril> mkver: i don't get the question
<elenril> pre-decode filtering is separate from post-encode filtering
<elenril> there can be legitimate reasons to do either
<elenril> (or both)
<mkver> I was not aware that one can now have pre-decode filtering.
<elenril> it's quite new
<mkver> That's why I was not aware of it.
Marth64 has joined #ffmpeg-devel
marcj has joined #ffmpeg-devel
guest745 has quit [Ping timeout: 250 seconds]
<elenril> > haasn | what does it mean when AVCodec.pix_fmt is set for a decoder?
<elenril> nothing
<elenril> it's a cargo cult
<mkver> Yeah, i intend to remove that.
<elenril> mkver: are you actively working on avoptions at the moment?
<elenril> i wanted to implement list options, but don't want to get in your way
<elenril> it's needed to fix side data preference issues for the release
<mkver> You can work on it.
<elenril> ok
<haasn> mkver: okay, I'll go ahead and remove it then in my series
<mkver> Some decoders still use it.
<haasn> what do they use it for?
<mkver> To store what to offer the user in ff_get_format().
<haasn> ah
cone-878 has quit [Quit: transmission timeout]
TheSashmo has quit [Quit: Leaving...]
ngaullier has quit [Ping timeout: 240 seconds]
<elenril> wbs: have you measured ffmpeg CLI performance in wine compared to native?
epony has joined #ffmpeg-devel
<elenril> ../configure --toolchain=msvc --enable-cross-compile
<elenril> sure is taking its sweet time
TheSashmo has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
<elenril> the only thing that doesn't work with c11 seems to be missing max_align_t
<jamrial> can that be replaced? it's used in a single place
<jamrial> also what msvc version?
<elenril> it certainly can be replaced with whatever is done now for non-c11 compilerrs
cone-708 has joined #ffmpeg-devel
<cone-708> ffmpeg Leo Izen master:c0de7ac52067: avcodec/libjxlenc: support negative linesizes
<elenril> not sure it's the best way though
bocci has quit [Remote host closed the connection]
AbleBacon has joined #ffmpeg-devel
<jamrial> >closed because old. fuck you
<elenril> yes
<elenril> also >Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact.
<jamrial> also, we don't define max_align_t anywhere in compat headers
rvalue has joined #ffmpeg-devel
<jamrial> the only compat stuff for c11 is atomics
<elenril> we can probably drop all those
<elenril> not sure defining max_align_t in a general way would be simple
<jamrial> long double?
<elenril> ¯\_(ツ)_/¯
Krowl has quit [Read error: Connection reset by peer]
<elenril> also, seems native atomics are broken somehow
<jamrial> std:c17?
<elenril> tried that to see if it fixes max_align_t
<elenril> people suggested c17 at fosdem
<elenril> breaks the same way with c11
<elenril> right
<Traneptora> >We determined that this is by design.
<JEEB> yea so they want you to opt-in to it
<elenril> they are not implementing ATOMIC_VAR_INIT anyway
<Traneptora> can I opt-in by putting code in my C files
<mkver> https://pastebin.com/jStZtRY1 (since fd16d8c68cd7b820eda76c407b0645b7cf470efd)
<JEEB> > If you are interested in atomics, then I also recommend using the latest preview release, as it contains significant fixes in this area. After it is fully implemented it will be enabled by default under C11 and later and the experimental switch will be deprecated.
ccawley2011 has quit [Read error: Connection reset by peer]
<JEEB> apparently they at least are planning on improving things and then removing the experimentalism
<elenril> so seems we'll have to keep emulated atomics for a while
<mkver> elenril: ATOMIC_VAR_INIT is deprecated and we should actually not use it either.
<elenril> mkver: wtf
<elenril> (to the pthread thing)
<jamrial> mkver: isn't that a c23 change?
<Lynne> yup
<Lynne> I think we should hold off on c11/17 until we release 7.0
<elenril> mkver: IIUC we use it so that compat headers work
<mkver> jamrial: I don't know whether C23 already removed it. But there is definitely no reason to use it.
<elenril> Lynne: 7.1 is supposed to be less breaking
<elenril> 7.0 is an api break
<elenril> so i'd prefer to do it now
<mkver> #define ATOMIC_VAR_INIT(value) (value)
<elenril> ah
<elenril> nvm then
<mkver> That is the implementation in all our compat headers.
<elenril> let's kill it then
<courmisch> it archs back to drafts of c11 before _Atomic was added
<jamrial> /mingw64/include/c++/13.2.0/bits/atomic_base.h:#define ATOMIC_VAR_INIT(_VI) { _VI }
<courmisch> that's c++
<elenril> mkver: that seems like a strong argument for dropping everything sdl
<elenril> sdl is cursed
<elenril> (yes, including ffplay)
<jamrial> courmisch: ah right, it's /mingw64/lib/gcc/x86_64-w64-mingw32/13.2.0/include/stdatomic.h:#define ATOMIC_VAR_INIT(VALUE) (VALUE)
<courmisch> after _Atomic was introduced, ATOMIC_VAR_INIT no longer made sense
<courmisch> but that was only fixed in C17
<courmisch> also atomic_load{,_explicit} requires a non-const pointer in C11
<courmisch> C17 accepts const-qualifiers
<elenril> do we lose any compilers we care about?
<mkver> Presumably because it was believed that if atomics were emulated, a load may involve locking a mutex which involves writes even when one actually only wants to read a value.
<courmisch> well, yes but also no
<mkver> elenril: Some ancient Clang toolchains don't accept const. That's why there are a bunch of casts in the codebase. Michael always tests with them.
<courmisch> once _Atomic is defined, the compiler has to understand atomic variable as intrinsic types, so there's no point having ATOMIC_VAR_INIT
<elenril> mkver: but do we want to keep supporting them?
<mkver> I don't care about those ancient clang versions.
<courmisch> - unlike if there are only specific atomic_XX types from a fixed set
<elenril> mkver: and do you have an opinion on the missing max_align_t in msvc?
<mkver> courmisch: Presuming that your "well, yes but also no" is a reply to my statement just above it, I don't get your point.
<elenril> jamrial's patch above, or a compat header?
<mkver> elenril: If it is not there, just use 16.
<courmisch> you're free to read the C17 rationale for the long version, but it's basically what I just wrote
<courmisch> _Atomic requires that atomic types are intrinsic, so having a library-level wrapper like ATOMIC_VAR_INIT is pointless
<mkver> courmisch: What I wrote was about why atomic_load() initially did not accept const pointees. It has nothing to do with ATOMIC_VAR_INIT.
<mkver> elenril: jamrial's patch seems fine.
<courmisch> the compiler would have to "emit" the space, alignment and initial value for the lock, not the library
<courmisch> so ATOMIC_VAR_INIT serves no purpose
<courmisch> as for the const qualifier, I believe it's purely an editorial overlook
<courmisch> but somebody can probably dig out the rationale from some archive somewhere
<Lynne> elenril: fair enough
<courmisch> elenril: how hard can it be for Microsoft to add a header that defines max_align_t to a union of u64 and long double?
kurosu has quit [Quit: Connection closed for inactivity]
<elenril> apparently very?
<elenril> I mean it's microsoft
<elenril> one does not simply add something to some header
<elenril> I bet it needs 10 layers of approvals
<courmisch> don't they have the world's betterestest l44t coderz, e.g. Lennart
<courmisch> l33t even
<JEEB> and for a moment I thought l44t was the 10x developer version of l33t ;)
AntimaD has quit [Ping timeout: 256 seconds]
rodgort has quit [Quit: Leaving]
rodgort has joined #ffmpeg-devel
sepro has quit [Quit: Ping timeout (120 seconds)]
sepro has joined #ffmpeg-devel
sepro has quit [Client Quit]
sepro has joined #ffmpeg-devel
thilo has quit [Quit: WeeChat 2.8]
sepro1 has joined #ffmpeg-devel
sepro has quit [Ping timeout: 256 seconds]
sepro1 is now known as sepro
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
<mkver> jamrial: Clearly caused by d3111486f917f61df4100beb0cedc8e84cd7d2f7
<jamrial> heh
epony has quit [Remote host closed the connection]
b50d has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<BBB> uh oh
<BBB> cosminaught: isn't there a risk that it'll assign *all* ffmpeg-devel@ffmpeg.org commits to your personal account? The same problem exists for Vignesh also
<BBB> $ git log --author=ffmpeg-devel@ffmpeg.org --oneline | wc -l
<BBB> 10
<BBB> (I don't have a good solution here)
<cosminaught> no per mailmap documentation this format will match name and email and rewrite both
<cosminaught> you can check git shortlog to confirm
<BBB> ah ok that's cool
<BBB> no it's ok, I just wanted to make sure it was tested
<BBB> if it's intended, then it's good
<elenril> if only someone could write a push hook to make the server reject such commits
b50d has quit [Remote host closed the connection]
<BBB> elenril: patch welcome!
<elenril> indeed
<cosminaught> yeah, seems to work, we could use this to fix other via ffmpeg-devel commits if anyone cares
<cosminaught> https://git-scm.com/docs/gitmailmap turns out it is quite robust on the kind of rewrites it can handle
epony has joined #ffmpeg-devel
<cosminaught> elenril: I'm fairly certain I can write such a hook, but not sure where to send it
<elenril> to the mailing list?
<elenril> possibly ask michaelni if it doesn't exist already, I have vague memories of it being mentioned
<cosminaught> I haven't found a repo for any server side git hooks, if the repo exists I can send a patch to it
<Lynne> I went digging for the release date of centos 7, found a date, 7th of July 2014
<elenril> wikipedia lists them
<elenril> centos is dead anyway
<Traneptora> Centos 7 is EOL this june
derpydoo has joined #ffmpeg-devel
<Lynne> oh yeah, what was it they changed for centos? the license, going closed-source?
<j45> public source code access is limited to centos stream
<haasn> is there a reason we use -Wdeclaration-after-statement ?
MikhailAMD has joined #ffmpeg-devel
MikhailAMD has quit [Client Quit]
cone-708 has quit [Quit: transmission timeout]
<jamrial> haasn: not sure why (probably broke obscure compilers from 2003), but clearly defining the scope of variables is nice
<j-b> good morning
<mkver> haasn: It's because we are dinosaurs.
<Lynne> Daemon404 had issues with relaxing that IIRC
<Lynne> I too was against it
<Lynne> but then I started writing libavtransport with it, and it's incredibly comfortable after having to switch between top and bottom of function
<Lynne> I think we should discuss relaxing it again, maybe times have changed
<Lynne> I've had to resort to surrounding parts of complex code in blocks just to define some variables inline to make it clear, and it doesn't look good
<JEEB> yea, blocks (new contexts) are required to get new variables which aren't at the beginning of a function or a for loop or so. it's a slight annoyance but in general the rule attempts to make sure that there are no usages before definitions etc. of course sometimes it's not nice when you want to define and initialize at the same time as much as possible
<JEEB> so I kinda see why the rule is there, but also I'm not too hard-on about it myself.
<elenril> i prefer declarations to be separated
<elenril> Lynne: consider shorter functions
<haasn> I'm not sure what is gained by obscuring the type of a temporary variable
<elenril> you can use a block to make it actually temporary
Krowl has quit [Read error: Connection reset by peer]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
<JEEB> yea, at least we lot things be declared in a block and loops etc. since some old stuff wouldn't let you do that :s
<jkqxz> Plenty of people still using RHEL 7.
<jkqxz> Probably not actually a problem though, because pretty much anyone building new stuff on it will have newer tooling anyway.
<jkqxz> What are the "important fixes" which make you want C17 over C11, though?
<Lynne> atomic bugfixes and finally standardized alignment
<JEEB> wasn't there a repo for centos 7 which contained newer developer tooling? I recall RHEL also having that
<Lynne> elenril: it doesn't help and is annoying to write in some cases, such as needing 20+ parameters
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45_ has quit [Ping timeout: 260 seconds]
<jkqxz> C11 does just seem less contentious. C17 seems like it could cause some annoyance so really wants some warning before the change, while C11 could just be done.
dellas has quit [Remote host closed the connection]
<mkver> Lynne: What new alignment stuff in C17 (over C11) is there?
<Lynne> mkver: _Alignas, aligned_alloc
<mkver> Lynne: Both C11.
<wbs> also, even if the compiler may support C11, not all environments do support aligned_alloc. on macOS, it's available since 10.15 (which is not very long ago). on windows, neither msvc nor mingw environments provide aligned_alloc
<wbs> (but I guess aligned_alloc isn't something we need to use anyway, we have working, portable enough, platform specific aligned allocation already)
<Lynne> " Since the malloc function returns objects that meet the same alignment requirement, this restriction makes aligned_alloc useless in portable programs."
justache has quit [Read error: Connection reset by peer]
<Lynne> wbs: IIRC very recently we had issues with the alignment, didn't we?
<wbs> Lynne: yes, but not in a way that aligned_alloc would help
<wbs> we have issues because we lie to the compiler
justache has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
<Marth64> Any issues if I take a look at this one? `Re: [FFmpeg-devel] [PATCH] libavformat/dashdec.c Fix for ticket #7395` - Fri, Feb 2, 3:50 AM (3 days ago)
<Marth64> looks like a possible leak, possibly quick fix, but sender didn't put a proper patch
<Marth64> and I've somewhat studied dashdec while learning but not enough to call myself expert
<Marth64> but I also don't like leaks
<BBB> anyone can review!
<BBB> but most people don't ;)
<BBB> do more review is always welcome
<Marth64> TY
<Marth64> ffmpeg is addictive
kasper93 has quit [Remote host closed the connection]
dellas has quit [Remote host closed the connection]
mkver has quit [Ping timeout: 268 seconds]