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]
<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?
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
<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
<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]
<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
<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]