<JEEB>
I guess I'll try to still get the libaribcaption changes in as soon as I get confirmation from author that the commit message changes are fine by him.
<JEEB>
did the review/changes on midnight 23-24, but then posting on the mailing list is what I ended up not capable of doing .-.
<elenril>
being JEEB is suffering~
<courmisch>
elenril: dead in the silly con valley, still strong in Texas and China
<JEEB>
while there are other things that people requested me to check for 6.1, those I haven't done a full review on yet so it's not going to happen. this at least I went through and rephrased commit messages
<elenril>
courmisch: i hear silly cone valley is itself dead
___nick___ has joined #ffmpeg-devel
<courmisch>
elenril: did the Big One just happen?
<elenril>
metaphorically dead
<courmisch>
elenril: scientists claim that the Big One is more likely to level LA than the silly con valley
<courmisch>
elenril: I'm not clear what metaphorical death means as applied to a geographical area
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 245 seconds]
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
<courmisch>
in PixBlockDSP, are the strides guaranteed to be multiple of 8/16 even in the unaligned cases?
<courmisch>
at least checkasm seems to think yes
kurosu has joined #ffmpeg-devel
<elenril>
git grep PixBlockDSP|wc -l
<elenril>
0
SystemError has quit [Ping timeout: 256 seconds]
SystemError has joined #ffmpeg-devel
<courmisch>
elenril: how about some helping of -i
<elenril>
sounds like a workaround for courmisch bugs
<courmisch>
it is a bug that it's called PixblockDSP, but that's not mine
<courmisch>
I blame you for failing to correct it
<elenril>
sure is crappy signal in this train
<elenril>
well it's an internal API with few callers
<elenril>
you can go over them one by one, check that it's always true, and document it as a requirement
<j-b>
There is always an XKCD for each geeks' problems
<haasn>
one downside to signalling the color ranges as a static list inside AVCodec is that it does not work for codecs which support only full-range gray8 but only limited-range yuv
<haasn>
I'm not entirely sure such codecs exist
<haasn>
maybe snow?
<j-b>
Can we vote people out of the community? Asking for a friend.
<haasn>
oh, that is easy to solve by just introducing multiple FFCodec
<haasn>
like what pnmenc does
<haasn>
it has split between mpeg range pgmyuv and jpeg range pgm
<jamrial>
michaelni: you forgot the version bump commits post branching
<durandal_1707>
j-b: President can become Tyrant
<j-b>
durandal_1707: as can LEADER
<durandal_1707>
why we still have LEADER
<j-b>
NG
HarshK23 has quit [Quit: Connection closed for inactivity]
<courmisch>
hmm, err, how exactly is my SBR sum_square code passing checkasm
<courmisch>
while doing literally nothing
<elenril>
who tests the testers
<BBB>
kierank: fair enough
derpydoo has joined #ffmpeg-devel
<another|>
elenril: AI
<Daemon404>
Lynne, define 'aac trimming issues'
<Daemon404>
it would only possibly affect end trimming
<Daemon404>
[15:45] <@Lynne> it is hard to follow, but I'd like to know if it makes sense, to override ctts with stts <-- 'override ctts with stts' is funementally a nonsense statement. theyre different things.
<Daemon404>
so: yes, overriding ctts with stts is actully wrong
<cone-579>
ffmpeg James Almer release/6.1:5c5d3e315e80: Changelog: mark 6.0
<courmisch>
elenril: I guess nothing clobbers the float point result register, so doing nothing counts as returning the same value as the reference C function
<jamrial>
err, typo
<cone-579>
ffmpeg James Almer master:ff3429991ec1: Changelog: mark 6.1
<Lynne>
Daemon404: with the decoder fixed, it fixes the pre-padding of mp4 files generated by fdkaac.c
<Lynne>
removes around 3000 samples at the start
<Daemon404>
that sounds wrong to me
<Daemon404>
the fact anything could be fixed by that patch means something elsewhere is wrong
<Daemon404>
the correct fix for priming samples is an edit list
<Daemon404>
(you *could* use ctts, but nothing except quicktime will handle audio with a ctts box correctly)
<Daemon404>
the patch itself looks wrong/misguided...
<JEEB>
(not according to Fraunhofer any more, they now want encoders to strip priming samples)
<JEEB>
(and consider edit lists a "hack")
<Daemon404>
JEEB, well that fixes it at encoding time. s.
<Daemon404>
so*
<Daemon404>
it becomes a non issue
<durandal_1707>
for new files
<Daemon404>
durandal_1707, for old files with priming samples that are not signalle, it is impossible to 'fix' them.
<JEEB>
Daemon404: yea just noted since I found it funny as it literally was the only way :P
<JEEB>
well as you say, ctts technically was possible
<Daemon404>
99% of everything expects an edit list
<Daemon404>
more like 99.999
<JEEB>
yea
<Lynne>
encoders can't really skip priming samples, it's called algorithmic delay for a reason
<Daemon404>
Lynne, they can chop them off and not output them and take the hit in error during decode
<Daemon404>
banking on the fact humans are stupid at hearing
<Daemon404>
(ofc only works if delay is an integer multiple of framesize)
<Lynne>
so they take into account the decoder's delay, and cut it off on their end, such that the time is still correct?
<Daemon404>
well. """works""".
<Lynne>
good luck to them, it's impossible
<Daemon404>
yeah if their delay is e.g. 2048 samples, theyll drop the first two 1024 sample lc-aac frames
<Daemon404>
just never output them.
<Daemon404>
it's totally possible and widely done. just technically not gret.
<JEEB>
yea
<Daemon404>
to be clear they drop then from *encoding*
<Daemon404>
not decoding
<JEEB>
yup
<JEEB>
during decoding you just decode
<JEEB>
anyways, is there a sample for that mp4 demux patch?
<JEEB>
to see what it is supposed to fix
<Daemon404>
maybe in the trak
<Daemon404>
the subtitle thing?
<Daemon404>
using stts there for duration is super wrong anyway, in mov/mp4 the duration of the last sample is determined by min(track_dur, movie_dur)
<Lynne>
Daemon404: yeah, I guess so, though it gets complicated with HE-AAC, and anything in the apple ecosystem probably with dumb raw adts
<Daemon404>
he-aac is a total crapshoot
<Lynne>
yyyyyyyyyup
<Daemon404>
you cant really drop frames
<Daemon404>
itll never line up
<Daemon404>
*has* to be an eitl ist
<Daemon404>
edit list*
<Lynne>
ah, so maybe something's wrong with edit list parsing, either on our end, or fdkaac.c
<Daemon404>
is this during encoding or decoding?
<Daemon404>
is the encode done by ffmpeg?
<Lynne>
decoding, I did say fdkaac.c == command like fdkaac
<Daemon404>
are you outputting to mp4 or adts?
<Lynne>
mp4, the default
<Daemon404>
curious if their cli tool is failing to write an edit list
<Daemon404>
aka leaving it totally unsignalled
<Lynne>
it writes something, because apple's afconvert-generated files are not changed by the patch
<Daemon404>
can i see a fil?
<Daemon404>
file even
<Daemon404>
i swear to $deity if this is more youtube-edit-list-patch shenanigans...
<galad>
it was introduced when Apple added gapless playback to iTunes
<Daemon404>
we have *something* for it in mov.c
<JEEB>
start_pad :3
<Daemon404>
hmm
<Daemon404>
we *do* set skip_samples properly on Lynne's file
<Daemon404>
so it should be trimmed properly
<Daemon404>
it's even the right value
<Daemon404>
"side_data_type": "Skip Samples",
<Daemon404>
"skip_samples": 2048,
<Daemon404>
on the first packet
<durandal_1707>
ffmpeg.c ignores that
<Daemon404>
i thought skip_samples was handled by avcodec?
<Daemon404>
Lynne, i have a guess: do you know if our decoding is off by the full 2048 samples, or maybe just 1024?
b50d has joined #ffmpeg-devel
<durandal_1707>
iirc avcodec just sets signal
<Lynne>
depends on the encoder
<Daemon404>
well. on this fil.
<Daemon404>
file*
<Daemon404>
durandal_1707, are you saying ffmpeg.c ignores skip_samples?
<Daemon404>
and avcodec too?
<Daemon404>
that cant be right
<Lynne>
with fdkaac/most other encoders, it's 2048 samples, only with apple it's actually 2112 samples, with our aac encoder, it's 1024 samples (the algorithmic delay), and when you go over to HE-AAC, like that file, good luck
<Lynne>
with fdkaac with that file it's 5057 samples IIRC
<durandal_1707>
Daemon404: there are multiple ways in API to skip samples, one of them is 100% ignored by ffmpeg, but mpv use it.
<Lynne>
fixing the SBR priming such that it's as the spec requires, and I still get a large gap at the start
<Daemon404>
Lynne, ok. i was asking because i noticed the packet skip_samples (with value 2048) is attached to is 1024 samples long, so i thought maybe something was failing to apply skip_samples to the stream, and only to the first packet
<Daemon404>
but that would be off by 1024, not 2048.
<Daemon404>
so my guess ws wrong.
<Lynne>
somehow every single encoder is wrong, and the third least competent encoder is right
<durandal_1707>
iirc i poked elenril to fix ffmpeg.c for that one, but he ignored my requests.
<Lynne>
I have no explanation why they're using 2048 sample pre-skip, even if they had a lookup
<Lynne>
durandal_1707: the side data is never ignored
<elenril>
durandal_1707: slander
<Lynne>
the decoder-provided avci->skip_samples is ignored if there's side data
<elenril>
i challenge you to a duel
<Daemon404>
Lynne, well somewhere in the pipeline something is failing to apply_skip samples properly
<Daemon404>
the delay is correctly set at demux
<Daemon404>
apply skip_samples(
<Daemon404>
*
<Lynne>
why does only that specific file get better with the patch?
<Daemon404>
i dont know, pure luck
<Daemon404>
because what it changes is super unrelated
<durandal_1707>
look at my fix for opus skip samples
<Daemon404>
link?
<cone-579>
ffmpeg TADANO Tokumei master:82faba8a6ce8: lavc/libaribcaption: switch all `bool` context variables to `int`
<cone-579>
ffmpeg TADANO Tokumei master:21bfadd9b4a2: lavc/libaribcaption: add MSZ character related options
<cone-579>
ffmpeg TADANO Tokumei master:a824c6f2f627: lavc/libaribcaption: rename `replace_fullwidth_ascii` to `replace_msz_ascii`
<j-b>
JEEB: thx for pushing those.
<JEEB>
j-b: I will attempt to put those into release/6.1 as well since the library author requested the first release to include the wrapper to have these changes
<JEEB>
I did the review in midnight 23-24 but then crap happened so I never got to posting what I just did earlier
<j-b>
JEEB: the issue is that this changes the libaripcaption requirement, but I think it would be fair
<JEEB>
yea, he requested it to be bumped. 0.1.0 did not build to begin with
<JEEB>
you had to go X commits after 0.1.0 to begin with
<j-b>
yeah, but the MSZ commit requires 1.0.x no?
<JEEB>
yup
<JEEB>
anyways the requirement bump was a request from the author since otherwise there was messy ifdefs
<JEEB>
and since the wrapper was not yet in any release
<Daemon404>
oh good there is debug code for skip_samples
<Daemon404>
might help
<JEEB>
I also checked the common linux distros and aribcaption doesn't seem to be packaged yet
* Daemon404
rebuilds as debug
<JEEB>
so if they package, it's going to be latest
<JEEB>
homebrew on mac has already updated, I think?
<JEEB>
but at the end of the day, the author of the aribcaption library requested the requirement to get bumped
<JEEB>
(since older versions had issues)
<Daemon404>
i have a suspicion again
* Daemon404
stares at decode.c
<JEEB>
:D
<Daemon404>
(though i cant find durandal_1707's opus fix)
<jamrial>
Daemon404: Lynne was going to touch that skip_samples stuff afaik
<JEEB>
so in cherry-picks, do we also take in the micro bump and just match it against the minor of the release branch?
<JEEB>
so in this case since both master and release/6.1 are at micro 100 what was xxx.32.101 on master would be xxx.31.101 on release branch?
<JEEB>
or do I just leave the micro bump out?
<Daemon404>
because the frame is 1024 sampls
<Daemon404>
how can there be 0 skp left?
<Daemon404>
OH
<Daemon404>
duh
dellas83 has quit [Remote host closed the connection]
<Daemon404>
the skip is 2048 SAMPLES, and the frame is 1024 ... in timbase 24000
<JEEB>
\o/
<JEEB>
conversion from one to other?
<Daemon404>
so makes sense to skip exactly one avframe
<JEEB>
ah
<JEEB>
right
<Daemon404>
so the first PTS ends up being non-0
<Daemon404>
will ffmpeg.c filter stuff inject silence?
<Daemon404>
(which would add the delay right back lol)
<cone-579>
ffmpeg TADANO Tokumei release/6.1:48afb4354902: lavc/libaribcaption: switch all `bool` context variables to `int`
<cone-579>
ffmpeg TADANO Tokumei release/6.1:8ccd1593a4b8: lavc/libaribcaption: add MSZ character related options
<cone-579>
ffmpeg TADANO Tokumei release/6.1:1cff6e41bf2b: lavc/libaribcaption: rename `replace_fullwidth_ascii` to `replace_msz_ascii`
<Daemon404>
actuallly maybe output is correct...
<JEEB>
there. that is all from me since this was my mistake of doing review between 23-24 but then not having the mental to send the final OK on the commit message rewrite + the library author had requested the first release including that wrapper to include those changes.
<Daemon404>
Lynne, i you perhaps was your input to fdk a wav?
MrZeus has joined #ffmpeg-devel
<Daemon404>
(and if so from where)
<jamrial>
JEEB: things that bump version should not go to release branches
<JEEB>
even micro?
<Daemon404>
i am almos wonderng if there's priming samples left over from a prevous encode/decode cycle
<Daemon404>
before it even got encoded with fdk
<Daemon404>
hmmm no, maybe not
MrZeus_ has joined #ffmpeg-devel
<JEEB>
minor of course not
<Daemon404>
it is very odd, the avcodec output (in avframes) looks correct
<jamrial>
JEEB: eh, i guess micro is not a problem, as long as the addition is also in master
<Daemon404>
but ffmpeg.c output is *not*
<durandal_1707>
git misbehaves baddly here, can track libavcodec/opus_parse.c changes
<Daemon404>
this sounds cursed
<JEEB>
jamrial: yea, it is. and also got requested from the library author to not have the first release including this wrapper without these changes
MrZeus__ has joined #ffmpeg-devel
<durandal_1707>
opus_parse set delay and skip samples
<Daemon404>
skip_Samples is being set here already correctly
MrZeus has quit [Ping timeout: 240 seconds]
<JEEB>
jamrial: but in general, for micro bumps - has the standard so far been that such fixups' bumps don't end up in cherry-picks?
<durandal_1707>
time to update buggy git
<durandal_1707>
Daemon404: note that ffmpeg.c ignores initial_padding for sure
<durandal_1707>
huh, no update for buggy git?
MrZeus_ has quit [Ping timeout: 240 seconds]
<durandal_1707>
everything is going downhill
<Daemon404>
durandal_1707, what i suspect is happening is the aresample flter is inserting silence since first avframe has non-zero pts due to skip_samples being applied in decode.c
<jamrial>
JEEB: i don't recall cherry-picks that introduced avoptions
<Daemon404>
decode.c will drop output but not shift timestamps
<durandal_1707>
aresample should not insert silence by default, that is meant as additional feature to be enabled by option
<Daemon404>
i see
<Daemon404>
well output has exactly 2048 samples of silence at the start
<Lynne>
Daemon404: raw
<JEEB>
jamrial: yea I don't expect to be doing that again any time soon. just got heavily requested to not have the wrapper without those changes in the first release the wrapper would be in
<Lynne>
not wav
<jamrial>
JEEB: that's ok
<Daemon404>
Lynne, from a CD?
<durandal_1707>
start_pts=1024
<Daemon404>
i.e. never been encoded before
<Daemon404>
durandal_1707, which is correct, because the first decode frame is droppe
<Daemon404>
due to skip_samples
<JEEB>
jamrial: but yea, normal fixups don't seem to get micro bumps around here
<Lynne>
Daemon404: no, some random .flac file I found, I trimmed it, and outputted it to 48khz 2channel raw
<JEEB>
so I guess the question of whether to back-port micro bumps is not that big of a thing
<Daemon404>
Lynne, ok
<Daemon404>
i suspect ffmpeg.c is to blame atm
<jamrial>
JEEB: yeah, we don't normally bump micro for fixes, only for changes that are exposed in some form to the api user, as is the case of avoptions
<JEEB>
right'o
<Lynne>
Daemon404: for the part that isn't the additional SBR decoder delay, right?
<Lynne>
let me send you my patch which fixes it
<Daemon404>
Lynne, specifically due to priming, not SBR
<Lynne>
ah, really?
<Lynne>
if I manually skip via an option I added, it's correct, so it could be the side data, perhaps somewhere in decode.c
<Daemon404>
ohhhh fuck
<Daemon404>
i just realized this is he
* Daemon404
deskface
<Daemon404>
so maybe ONLY priming skip is applied
<Daemon404>
when it should be sbr+priming?
<Lynne>
I fixed that part, I added a += sigh in decode.c so both are taken into account
<Lynne>
but skipping the decoder-specified number of samples as per the spec still leaves a gap, even with both the side data and this
<Daemon404>
'gap' here meaning extra silence at the start?
<Lynne>
yup
<Daemon404>
or is this specifically when measurin *between* tracks being playe
<Daemon404>
(i.e. could be end padding)
<Lynne>
no, at the start
<Daemon404>
ok
b50d has quit [Remote host closed the connection]
MrZeus_ has joined #ffmpeg-devel
<Daemon404>
well ffmpeg.c output looks correct for the amount of skip_samples
<Daemon404>
Lynne, so this only happens with HE right?
<Lynne>
err, I just tested it, and it works now
<Daemon404>
if adding sbr to the skip works, i guess that is the right fix
<Daemon404>
yeah
<Daemon404>
i thought i was going crazy lol
<Lynne>
no, it's just me, I'm having to deal with it
<Lynne>
I can't believe we don't skip any samples during seeking
MrZeus__ has quit [Ping timeout: 248 seconds]
<Lynne>
it's very sadistic to seek in he-aac and hear +12dB white noise burst
<Daemon404>
gross
<elenril>
serves you right for seeking
<j-b>
Seeking?
<elenril>
only uncultured plebeians seek
<Lynne>
seek button is mandatory nowadays, especially in youtube content
<Daemon404>
imagine telling christopher nolan you seek in his movies
<Lynne>
it's not an IETF RFC, it's something higher, an internet standard
<elenril>
>implying I watch youtube through a browser
<Lynne>
exactly
<Daemon404>
yeh elenril uses ipad only for YT
<elenril>
the virgin seek button
<elenril>
the chad playback speed
* elenril
stabs Daemon404
<durandal_1707>
elenril is Master Chad
<Lynne>
why would anyone want a slider to make voices sound like chipmunks?
<Daemon404>
fetishes
<JEEB>
the voices get adjusted
<Lynne>
there are already enough nightmare fuel movies out there which do that
<JEEB>
I watch most of my youtube at 1.75x
<durandal_1707>
Lynne: seek in mpv works that way anyway, even for flac
<JEEB>
or well, pitch adjustment
<elenril>
Lynne: like you you didn't watch chip&dale as a kid
<Lynne>
flac does not have any decoder delay
<durandal_1707>
git log libavcodec/opus_parse.c
<durandal_1707>
why i can not follow full history of this?
<durandal_1707>
all other commits are unreeachable
<Daemon404>
did it get renamed
<durandal_1707>
yes
<durandal_1707>
--follow does not help
<Daemon404>
git log --follow
<Daemon404>
o
<Daemon404>
rip
<durandal_1707>
can you also reproduce that?
<Lynne>
checkout the previous commit and go from there is my way
<Daemon404>
the refactor must have been too hardcore
<Daemon404>
so git cant figure out where it came from
<Daemon404>
do what Lynne said
<elenril>
Daemon404: it clearly can, git show does see the move
<Daemon404>
git show what?
<elenril>
git show the commit that created the file
<j-b>
git blame -C -M
<Daemon404>
show doesnt show a move
<Daemon404>
just a new file
<elenril>
do you even --color-moved
<Daemon404>
elenril, still dont see it.
<Daemon404>
just new file. even with that flag.
<durandal_1707>
Waiting for data... (^X or interrupt to abort)
<Lynne>
how? we're all so full of patented algorithms despite never reading any
<JEEB>
of course for most formats you need freeworld because of US software patents
<durandal_1707>
elenril: the threading work is full of hacks and does not really work unlike avfilter
<JEEB>
so "totally unrelated even though maintained by same people" RPMFusion -freeworld packages exist
<Lynne>
I remember it was a requirement that all patented code must be removed
<JEEB>
at some point that changed apparnetly
<JEEB>
and build config only became a thing?
<Daemon404>
the only way to be sure no patented code sneaked in is rm -rf /
<durandal_1707>
everyhing is patented
<another|>
>inb4: patent on unlinking data from a filing system
<microchip_>
durandal_1707: even you! I patented you yesterday :D
<Daemon404>
method to remove nodes from a tree
<JEEB>
method and apparatus
<Daemon404>
oh yes
<j-b>
I would say that the only way to be sure that there is no patent, is that the patent existed and is now expired.
<j-b>
Like MPEG-2 video or AC-3
<durandal_1707>
they repatent stuff
<JEEB>
j-b: yea, knowing that you are working with a patent that already existed and expired means that you have something to point at
<Lynne>
you can necromancer dying patents, usually companies do this once or so
<Son_Goku>
JEEB: actually the rpmfusion package is maintained by different people
<Son_Goku>
Lynne: it happens a lot less than you'd think, thank god, because the USPTO charges an absurd amount of money and it's hard to do without getting the patent invalidated
<Son_Goku>
Sonos recently got screwed that way
<Son_Goku>
Daemon404: the packaging for ffmpeg in Fedora is *special*
<Son_Goku>
I maintain an allowlist of codec files and generate a tarball based on that
<Son_Goku>
and then further maintain a list of allowed to enable stuff
<durandal_1707>
see, 99% stuff is disabled/
<j-b>
Are you allowed to call FFmpeg if all is disabled?
<elenril>
durandal_1707: threading work passes fate in its entirety, except for sub2video
<Son_Goku>
durandal_1707: it's not 99% disabled actually
<another|>
--enable-calling-it-ffmpeg
<Son_Goku>
j-b: why wouldn't we? it's no different than someone else doing an ffmpeg build where only some codecs are enabled
<Son_Goku>
it's part of the build scripts to allow that
<j-b>
Son_Goku: just asking. But for VLC, this is not allowed.
<Son_Goku>
it's pretty common for people to ship builds of ffmpeg where not every single codec option is enabled
b50d has joined #ffmpeg-devel
<JEEB>
yea, ubuntu after all used to default to it
<JEEB>
then apparently they stopped doing that at some point
<Son_Goku>
they definitely still do
<Son_Goku>
since they inherit it from debian
<Son_Goku>
which still does
<Son_Goku>
the difference between libavcodec and libavcodec-extra in debian/ubuntu
<Son_Goku>
JEEB: ubuntu isn't separately maintaining it from debian, and I'm surprised debian is doing that since their own policy forbids it
<Son_Goku>
but then again, it's actually quite hard to enforce debian policy on debian maintainers
<JEEB>
Son_Goku: I think whatever changed happened around ~10 years ago
* Son_Goku
shrugs
<Son_Goku>
I'm working with what I can do
<JEEB>
anyways since I see most users understanding that it's a distro problem and not an FFmpeg problem I don't get too annoyed with this stuff since debian/ubuntu used to have this as well in the olden days. of course with debian/ubuntu the easy part was that it was just another package in already enabled repos
<Son_Goku>
the list of codecs we have not-enabled is pretty small
<Son_Goku>
and our arrangement with Cisco for OpenH264 also closes the gap pretty well
<Son_Goku>
so our ffmpeg can play H264 through that codec library
<JEEB>
yea, cisco did a good thing there
<JEEB>
since they're already paying max
<Son_Goku>
I wish that the ffmpeg-libopenh264 support wasn't quite so barebones, but I just don't understand how this stuff works to fix it
<Son_Goku>
e.g. no support for SEI stuff
<Son_Goku>
but it's better than nothing
<Son_Goku>
and works in most cases
<JEEB>
yea that's the classic thing where the built-in functionalities in the framework are not utilized due to it being a 3rd party wrapper
<JEEB>
you could in theory start mapping all that stuff, but I'd bet most people just don't see the benefit
<JEEB>
and/or only utilize openh264 for encoding
<JEEB>
since most people utilize the internal h.264 decoder which naturally has everything wired up already
<Son_Goku>
yeah
<Son_Goku>
we still have that disabled unfortunately
<Son_Goku>
I'd like to enable it at some point, and I hope I can soon
<durandal_1707>
disable FLAC too
<Daemon404>
there is probably a way to expose stuff
<durandal_1707>
its full of patents
<Son_Goku>
:/
<Son_Goku>
flac has been allowed in Fedora for a very long time
<Son_Goku>
durandal_1707: it's not a question of patents or not, it's a question of a useful patent grant
<Son_Goku>
that's why the VPx and AV1 codecs are in Fedora
<kierank>
does fedora disable aac?
<Son_Goku>
nope
<kierank>
he-aac is still patented
<Son_Goku>
well, we have a stripped fdk-aac
<Lynne>
isn't mpeg-4 aac still under patent too?
<Son_Goku>
sort of?
<kierank>
Son_Goku: yeah but decoder?
<kierank>
he-aacv2 clearly patented
<j-b>
clearly
<Daemon404>
people serving he-aac to people get what they deserve
<JEEB>
Lynne: I think the patents affect features? (and thus mpeg-4 audio types)
<Son_Goku>
yes
<j-b>
yes
<kierank>
so how is it ok in fedora to ship?
<Son_Goku>
we don't have those things
<j-b>
You do.
<kierank>
you have a patched ffmpeg with he-aac removed?
<Lynne>
stop responding and ignore, you've all been on the internet long enough?
<courmisch>
can't even do some autoderision, as it's insinuating being insulted
<Daemon404>
i dont respond on the ML to it
<Daemon404>
because i dont want to hate life.
<Daemon404>
but if noone responds then ffmpeg goes to shit
<Daemon404>
so.
<durandal_1707>
both ways - loose.
<Daemon404>
indeed
<Daemon404>
nihilism ftw
<courmisch>
some people are going to have some very real life problems
<courmisch>
if their employment problem is not resolved
<elenril>
sounds kinda tautological
<Daemon404>
problems wont just be for people employed to work on ffmpeg
<jamrial>
i don't understand what is happening on that spi thread
<courmisch>
I really want to answer "please refrain from insinuating that I am insinuating that you are insulting me"
<courmisch>
but I won't
<Daemon404>
jamrial, crack cocaine
<elenril>
thank you for helping us help you help us all
<courmisch>
jamrial: El Presidente threatened to quit and go make money on non-multimedia startups...
<courmisch>
jamrial: ...and now people are panicking that they need to make a living
<Daemon404>
ironcally making the former more likely
<Daemon404>
and killing it more
<j-b>
jamrial: and the accusation against Kieran?
<Daemon404>
he is projecting
<Daemon404>
just wait for it.
<BBB>
I do think nicolas' statements are hurtful and false
___nick___ has quit [Ping timeout: 255 seconds]
<BBB>
and I'm thankful that Michael apologized for hit statements to kieran. that was necessary
<BBB>
nicolas could learn from that
<Daemon404>
thilo hasnt
<BBB>
indeed...
<j-b>
People who don't apologise should risk sanctions.
<kierank>
I have sent two emails to the CC
mkver has quit [Ping timeout: 258 seconds]
<Daemon404>
BBB, nicolas can never apologize, because it would be admitting he was wrong about somethin.g
<jamrial>
we haven't even voted a new CC
<BBB>
old CC is still in place
<elenril>
we have no rules for sanctioning people
<BBB>
but nicolas needs to soften his tone, at the very least
<Daemon404>
cant wait for "CC is too old, i dont recognize ther authorit"
<BBB>
:)
<jamrial>
Daemon404: nicolas already did that
<j-b>
it's been already done
<Daemon404>
lmao
<Daemon404>
life == satire
<Daemon404>
got it
<j-b>
that's exactly why I can't do any warnings anymore.
<BBB>
ok I accept my nomination for the CC after all
<j-b>
BBB: good.
<BBB>
now get on and vote
<elenril>
vote starts tomorrow
<j-b>
the GA vote starts in 2 hours
<j-b>
elenril: did you give a TZ?
<BBB>
I wouldn't know, I'm not eligible to vote ;)
<j-b>
or what is UTC?
<BBB>
I'm asking to be added :-p
<elenril>
not for starting to vote
<Daemon404>
BBB, you can vote on the GA because youre on the old GA
<j-b>
BBB: you are eligible to vote, for the old one.
<jamrial>
BBB: commit cosmetics :p
<elenril>
cosmetics explicitly don't count
<Daemon404>
maybe we need a dependency manager for votes
<jamrial>
curses
<elenril>
quick, commit other people's patches
<elenril>
those do count, according to a literal interpretation
<j-b>
Authorship
<elenril>
j-b: not what it says
<j-b>
it should be changed, then.
<elenril>
i agree
<elenril>
nevertheless, what it says is "Contributors are considered "active contributors" if they have pushed more than 20 patches in the last 36 months in the main FFmpeg repository"
<courmisch>
oooh, I should change to different personas, so I can vote multiple times
MisterMinister has joined #ffmpeg-devel
<j-b>
courmisch: lol
<elenril>
huh, it doesn't actually say anything about cosmetics
<j-b>
yes, one could courmisches (yes, it's a word) its way into the GA
<Daemon404>
just commit broken code and then slowly fix in in 10 commits