michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Kwiboo has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 260 seconds]
cone-177 has joined #ffmpeg-devel
<cone-177>
ffmpeg Leo Izen master:3fca5877d034: avcodec/pngdec: avoid hard failure on illegal sBIT chunks
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<fflogger>
[newticket] uttam_32472: Ticket #11463 ([undetermined] Bitstreams with long Closed Captions do not get passed through in transcode flows) created https://trac.ffmpeg.org/ticket/11463
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Traneptora>
Marth64> eia608 and interlacing can burn in the same hell
<Traneptora>
don't forget IVTC
<Traneptora>
and /1001 framerate denominators
jannau has quit [Ping timeout: 260 seconds]
jannau has joined #ffmpeg-devel
<Lynne>
telecine is by far the worst
<Lynne>
imo odd framerates are perfectly okay, if you don't properly use a timebase for calculations, you shouldn't be writing a player
<Lynne>
I have some horribly telecine'd live events shot on 24fps, telecined to 30fps, and they're completely unrecoverable
<Lynne>
on a blu-ray!
<nevcairiel>
NTSC frame rates are definitely the least offensive in the bunch
<nevcairiel>
telecine is not bad in theory, but in practice its so often messed up
<Traneptora>
in this house we do not love or respect pulldown
<IQLeader>
congratulations, such an advanced dev skills!
<IQLeader>
beats leader at ease
<haasn>
why are AV_PIX_FMT_XV30BE / AV_PIX_FMT_XV30LE defined as AV_PIX_FMT_FLAG_BITSTREAM ?
<haasn>
as I understood, this flag is useful mainly for formats where pixels are not aligned with byte boundaries
<haasn>
but xv30 is aligned, it has 2 bits of padding in bitween each pixel
<Lynne>
that flag most definitely does not mean that
<haasn>
oh even weirder, xv30be is bitstream while xv30le is not
<Lynne>
otherwise we wouldn't have bitpacked or v210 decoders
<IQLeader>
yes, bitstream flag as used in some spots is invalid
<IQLeader>
bitstream means aligned is not on byte boundary, so bits need to be moved around in more complex manner
<Lynne>
but it does mean that there's still an alignment requirement for all values for a single pixel or component pairs to fit in a byte-aligned value
<Lynne>
rather than a continuous bitstream of say 10bit values
<Lynne>
its infuriating
<IQLeader>
v210 need more patterns to self describe
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
srikanth has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
toots5441 has joined #ffmpeg-devel
toots5441 is now known as toots5446
<toots5446>
Morn! I have this series of patches adding proper metadata decoding support to chained ogg/flac streams: https://ffmpeg.org/pipermail/ffmpeg-devel/2025-February/339254.html. I'm considering doing the same to ogg/opus which, at the moment, does not utilize the canonical mechanism from the ogg demuxer. Do y'all advise that I way for this series to be reviewed or can I send a v3 with the opus
<toots5446>
case added to review everything at once?
<toots5446>
I *wait
abdu11 has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
beastd|2 has joined #ffmpeg-devel
beastd|2 is now known as beastd
<beastd>
Hi all :)
<Marth64[m]>
hi beastd
<beastd>
At those that were there: How was FOSDEM? As I understood there was an ffmpeg meeting
* beastd
is totally behind everything related to open source projects (just finished reading some of the IRC backlog...)
<BBB>
mkver: any opinions on "threadprogress: reorder instructions to silence tsan warning"? I'd like to move that forward
<Marth64[m]>
beastd: i only joined the virtual meeting. there were notes left somewhere but it sounded like a wish list
<Marth64[m]>
it was short and hard to hear/talk being virtual
<mkver>
BBB: The patch is ok, but the commit message is not. It does not only "silence" a tsan warning, it fixes an actual race.
<BBB>
mkver: ok I can change that. do you want me to send a new patch?
<mkver>
No.
<BBB>
alright, tnx
<BBB>
to "fix tsan warning"? or to "fix race condition"?
<beastd>
Marth64: ah ok, thanks
<mkver>
"fix race" is better (it is both a data race and a race condition).
<BBB>
alright, "fix race" it is then
<beastd>
Marth64: Actually I wanted to got there (usually the timing of fosdem doesn't work well for me tho), and this time i already had booked sth else for that weekend. so probably will try again in 2026
<cone-677>
ffmpeg Ronald S. Bultje master:586de322ab7d: threadprogress: reorder instructions to fix race.
<Marth64>
beastd: i hope to attend some time too in person
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
<Compn>
"we need to switch to newer community development platforms to attract new people" also "we cant figure out a $20 microphone to host a zoom meeting"
<Marth64>
it looked like a packed party, i didn't expect a perfect virtual call
<IQLeader>
it was a mess
<devinheitmueller>
Also, we didn’t have a real room like normal, so it was in a noisy cafeteria.
<Lynne>
I know someone who's holding onto a few dozen patches just waiting for us to use a platform other than a mailing list
<IQLeader>
never going to happen
<IQLeader>
use librempeg instead
<Lynne>
I know BtbN's still working on Forgejo CI
<another|>
apparently, FOSDEM did require proper registration for rooms this year
<BtbN>
It's working fine for all I know
<JEEB>
yea, I noticed already at FOSDEM that it was running FATE
<Lynne>
when can we start using it?
<IQLeader>
ask leader
<BtbN>
Well, some people still hate Forgejo with a passion
<BtbN>
Apparently cause if the name
<kierank>
No, because it's deliberately contrarian
<kierank>
To other parts of OSS multimedia
<kierank>
The name is dumb too
<IQLeader>
says ex-contributor
<kierank>
dav1d already has working gitlab
<another|>
almost anything is better then ML *shrugs*
<another|>
s/then/than/
<kierank>
Whereas forjego is the third fork of something
<IQLeader>
gitlab is mess, avoid at all cost
<kierank>
that will probably bitrot in a few years
<BtbN>
Having seen Gitlab and Forgejo, I prefer Forgejo
<another|>
kierank: 2nd fork?
<BtbN>
The risk of Forgejo getting abandoned seems very slim
<kierank>
The risk of Gogs being abandoned was slim
<kierank>
and Gitea
<BtbN>
It seems more risky that Gitlab pulls some stunt that splits it up as well or locks away features behind a paywall
<kierank>
let's attach a drama filled project to more drama
<BtbN>
Gitea isn't abandoned
<Lynne>
its hardly contrarian if one option takes ages to open a diff and hides large chunks by default to avoid overloading
<BtbN>
It's still in active development
<kierank>
videolan gitlab has actual sysadmins
<Lynne>
so do we
<kierank>
foregjo is just a bunch of scripts
<Lynne>
they work
<kierank>
lol
<kierank>
like trac works
<Lynne>
you're being contrarian here
<kierank>
forjego will become like trac, a relic
<kierank>
I'm not
<Lynne>
you are
<kierank>
dav1d, vlc use gitlab in a very sophisticated way as I posted
<BtbN>
So is every piece of software if you want to put it like that
<Lynne>
it powers, unmodified, the third largest open source platform
<Lynne>
codeberg
<kierank>
that forked out of some kind of intellectual purity test
<Lynne>
its hardly purity, its democracy
<BtbN>
Yes, I'd have preferred if gitea was still one whole, but here we are
<kierank>
We know gitlab works, videolan use it for complex projects.
<kierank>
They have CI already working on tons of targets
<BtbN>
We also know Forgejo works
<Lynne>
we know forgejo works too
<Lynne>
you've been repeating the same 3 arguments ever since the discussion was brought up, and you're completely refusing to change your viewpoint, do research, or agree to compromise
<Lynne>
I'm not entirely unused to this being in ffmpeg development for so long now
<kierank>
Anyone with the simplest foresight can see choosing a platform for contrarianness is destined to fail
<kierank>
cf x265 and hg
<kierank>
they went hg to be contrarian against git
<Lynne>
but if we're changing platforms, maybe some amount of willingness to compromise is needed too
<Lynne>
hg is older than git
<Lynne>
mozilla had no choice
<kierank>
Videolan gitlab, it works, dav1d uses it, videolan uses it
<kierank>
CI is detailed
<Lynne>
forgejo also works
<Lynne>
the plan has always been to use our own CI instances
<kierank>
?
ccawley2011_ has joined #ffmpeg-devel
<Lynne>
because we currently test on much more devices via fate
<Lynne>
than dav1d does
<kierank>
huh
<kierank>
FATE is not per MR CI
ccawley2011__ has joined #ffmpeg-devel
<Lynne>
no, but we'd like for feature and platform parity with current FATE systems
<kierank>
Or do you now expect FATE runners to run unmanaged code
<Lynne>
no, I don't
<kierank>
so...
<kierank>
Videolan gitlab has sandboxed CI already done
<Lynne>
I'm just pointing out that if we want to match the same number of systems and platforms we currently test on, the videolan gitlab infra is not sufficient
<kierank>
it's a false equivalency
<kierank>
because currently tested platforms on the ML are zero
ccawley2011 has quit [Ping timeout: 245 seconds]
<JEEB>
patchwork does still do x86 an x86 FATE
<Lynne>
per MR is not all that CI does, you know
<JEEB>
(probably 64bit)
<Lynne>
a CI run is performed on every commit merged
<Lynne>
and we have that
<Lynne>
and that's what I'd like to have parity with
<kierank>
huh
<kierank>
What I want is for my PR to be able to test on targets I don't have, riscv, windows, arm etc
<kierank>
without having to wait for it to be pushed and subsequently see issues
<Lynne>
yes
<Lynne>
yes
<kierank>
And Videolan gitlab has this all done and sandboxed
<IQLeader>
forgejo can do iti
<Lynne>
but it doesn't have enough platforms and systems
ccawley2011_ has quit [Ping timeout: 252 seconds]
<kierank>
forgejo will be dead in a few years
<kierank>
anyone with simple foresight can see this
<Lynne>
then don't use it
<Lynne>
you don't have to use it
<kierank>
gitlab will have to exist because other big multimedia OSS projects use it
<IQLeader>
"big"
<kierank>
and we get economies of scale by using videolan
<IQLeader>
"scale"
<Lynne>
again, you don't have to use it
<kierank>
forejgo is another house of cards ffmpeg infrastructure piece
<kierank>
that one person understands
<Lynne>
fine, fine, don't use it then.
<kierank>
and when they go it's game over
<Lynne>
yup, yup
<kierank>
It's like we celebrate the jank in this project
<IQLeader>
fine, fine, don't use it
<Lynne>
very much so, I totally agree
<kierank>
I see why Derek left
<IQLeader>
because Derek does not like libavfilter
<IQLeader>
and disables all filters
<haasn>
assuming we can't or don't want to use existing videolan infra, do you think gitlab is easier to set up and maintain from scratch than forgejo?
<kierank>
we use videolan infra for git already
<Lynne>
according to 2 testaments, it's hell to maintain gitlab
<haasn>
oh, really?
<Lynne>
yup, BtbN had experience IIRC
<haasn>
then why not just move to code.videolan.org again
<kierank>
haasn: yes exactly
<Lynne>
its slow
<haasn>
I thought the argument there was "ffmpeg is not a videolan project and we should control our own infra" or something
<Lynne>
no, literally, its slow
<jamrial>
yes, we have our own infra
<kierank>
lol
<Lynne>
also, forgejo embraces modern design decisions, like being federated, so you don't need one account for each project you want to contribute to
<haasn>
gitlab is also federated, you can cross sign in via your github account /s
<kierank>
we could have proper CI in a proper datacentre, but no, we celebrate the jank here
<kierank>
at the moment registration is broken
blb has quit [Quit: brb]
<Lynne>
then BtbN will fix it, and anyway, don't 99% of users just use github
<kierank>
"then BtbN will fix it"
<kierank>
that's the issue
<IQLeader>
kierank: you need proof you are human, and not bot
<kierank>
it's held together with string
<kierank>
like trac
<kierank>
like patchwrok
<kierank>
nobody knows how it works, it's just lashed together
<kierank>
but all glory to the jank in this project
<Lynne>
its currently being setup
<Lynne>
I registered fine, but something broke, it happens
<haasn>
didn't we also have a gitlab demo instance running somewhere?
<Lynne>
its barely been a thing for 2 weeks
<Lynne>
nope
<IQLeader>
"jank" is not proper wording
<Traneptora>
haasn: code.ffmpeg.org had a forgejo instance
<haasn>
Lynne: my point is that creating a fork is a non-responsive UI action, it keeps loading the page until it finally succeeds internally copying all files
mkver has quit [Quit: Leaving]
<BtbN>
A fork does not copy much of anything internally
ccawley2011__ has quit [Ping timeout: 252 seconds]
<BtbN>
It's the same git repo backing all forks
<BtbN>
So I don't see how it would possibly take 30 seconds
<haasn>
in other sites like github it will load the repository page instantly and just show a spinner for the repo contents
<haasn>
ditto for gitlab, just tested
blb has joined #ffmpeg-devel
<jamrial>
kierank: we can go with gitlab if most people prefer it. we haven't yet voted for it
<kierank>
Also running MR jobs on random people's machines is a huge security risk
<jamrial>
but we have our own hardware, so ideally we should use it
<kierank>
we do?
<kierank>
hardware own?
<kierank>
we* own
<IQLeader>
leader owns all infrastructure
<jamrial>
ah, not exactly own, no
<kierank>
IQLeader: leader is the cloud
<Traneptora>
kierank: the registration seems to have a bug when it's in admin only mode
<kierank>
IQLeader: don't ask where the infra is, just accept it is somewhere
<IQLeader>
its somewhere in bulgaria?
<jamrial>
it's already stated where in the infra doc, afair
<Traneptora>
I don't believe the registration bug is a thing when you're not in admin-approval-only mode
<BtbN>
Right now only I have access and I pay the bills, since it's a test instance
<BtbN>
When decided to actually install permanently, the regular admin group will get access and payment go via SPI
<IQLeader>
what about moving everything to Github and paying nothing?
<kierank>
"regular admin group" lol
<IQLeader>
"regular admin group" = michaelni, compn and kierank
<BtbN>
No
<Traneptora>
I assume regular admin group means everyone who currently has access to the stuff
<Traneptora>
will continue to have access
<BtbN>
I wouldn't mind just using GitHub, but plenty of people do
<Traneptora>
public github repo rather than private instance sounds like a very easy way to get a lot of really really bad issues and PRs
<Traneptora>
but I think some people want us to have control over our servers on principle
<BtbN>
We already do if I wouldn't block them lol
<IQLeader>
i have 0 experience with bad issues and pull request
<Traneptora>
that said Trac is really really slow so I'd kinda just be happy to use anything that isnt' trac
<kierank>
IQLeader: what about SDR patch I sent
<IQLeader>
kierank: awesome code
<kierank>
"Sorry, but SDR support in that form is currently out of scope."
<IQLeader>
trac is just on some shitty virtual instance
<BtbN>
trac is really really slow cause of the intense barrage of crawlers
<BtbN>
The server hosting it is relatively powerful even
<IQLeader>
put it on cloudflare
<BtbN>
trac gets nearly 1000 requests of mostly nonsense per minute
<jamrial>
kierank: simply put, michael doesn't want the main repo to be in videolan servers, and as is, he has veto power regardless of the supposed democracy in effect
<kierank>
the main repo is in videolan servers already
<jamrial>
be it gitlab or forgejo, we're going to host our own instance for that reason
<IQLeader>
^^
<kierank>
C:\Users\kiera>ping source.ffmpeg.org
<kierank>
Pinging git.videolan.org [213.36.253.5] with 32 bytes of data:
<kierank>
Reply from 213.36.253.5: bytes=32 time=23ms TTL=49
<jamrial>
and it will not be in the bulgaria telepoint server
<jamrial>
kierank: try git.ffmpeg.org
<another|>
kierank: there's a difference between a simple git repo and a full forge
<another|>
a git repo can be moved relatively simply
ccawley2011 has joined #ffmpeg-devel
elChippo has quit [Quit: There is no spoon!]
<BBB>
democracy with veto power, that sounds very democratic
<haasn>
this is the exact conversion matrix I calculate
<haasn>
well, exact up to printf precision :)
<haasn>
so e.g. 0.878431 * 128 + 16.0608 = 128.499968 is the computed chroma value after full->lim conversion
<haasn>
the +0.5 is the rounding bias
<haasn>
this has way, way more than enough bits of precision to be exact across all 8 (and 16) bit values
<haasn>
the min/max behavior is 0.878431 * 255 + 16.0608 = 240.06070499999998
<haasn>
and the minimum is ofc 16.0608
<haasn>
theoretically a value of 255 represents an exact chroma of 0.4980392156862745
<haasn>
which would be exactly 239.5607843137255
<haasn>
but is unrepresentable, so we round it up to 240, as expected
<haasn>
yeah, I'm like 99% sure my new values are mathematically correct and that whatever difference we see from swscale is due to rounding errors in swscale
<haasn>
that a rounding error can happen to make the MSE lower in a specific, small test pattern is not unexpected
<haasn>
because random errors can also randomly cancel out
fflogger has quit [Remote host closed the connection]
fflogger has joined #ffmpeg-devel
<haasn>
Oh, there’s actually an even more likely explanation
fflogger has quit [Remote host closed the connection]
fflogger has joined #ffmpeg-devel
abdu11 has quit [Quit: Client closed]
abdu11 has joined #ffmpeg-devel
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
srikanth has joined #ffmpeg-devel
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
iive has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ccawley2011__ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 268 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 252 seconds]
srikanth has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
abdu50 has joined #ffmpeg-devel
abdu11 has quit [Ping timeout: 240 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
ccawley2011_ has joined #ffmpeg-devel
abdu50 has quit [Quit: Client closed]
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
abdu50 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
ccawley2011__ has quit [Read error: Connection reset by peer]
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
srikanth has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
System_Error has quit [Ping timeout: 264 seconds]
abdu50 has quit [Quit: Client closed]
System_Error has joined #ffmpeg-devel
<haasn>
probably nobody cares about this case, but
<haasn>
sadly rgb565le etc. are significantly (20%) slower in this implementation
<haasn>
but I think nobody cares enough about these formats to let that be a blocker for now
<haasn>
can always revisit later
<haasn>
on the plus side, monob -> rgb24 is 2.188x faster
<BtbN>
Could someone who has OSX run `date -d "2025-03-17T01:46:29Z" "+%s"` and see if it produces the correct unix timestamp, 1742175989?
<BtbN>
I don't trust OSX shell utils...
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
iive has quit [Quit: They came for me...]
<Riviera>
BtbN: macOS' date does not have -d
<BtbN>
just as fun as I expected
<BtbN>
now to find some way to convert that timestamp to a unix time in portable bash...
<Riviera>
nah it's worse!
<Riviera>
busybox date (which is a GNU date) does not have -d either ;p
<BtbN>
well, it's a bash script, as in proper bash
<Riviera>
well you could do the math yourself
<Riviera>
it's only mildly annoying
<BtbN>
the RFC is quite involved, I don't want to implement it in bash
<Riviera>
hm, fair.
<BtbN>
All the doc says is "rfc3339 date time string"
<BtbN>
so I need to be ready to parse it. coreutils date does.
<Riviera>
nothing portable comes to mind
<Riviera>
relying on Python is no option I guess?
<Riviera>
ah, that also cannot do it with built-in stuff.
<Riviera>
yeah no idea then, implementing it in bash then is what i'd do
<BtbN>
It's for dehydrated
<BtbN>
allowed dependencies are basically nothing beyond curl
<BtbN>
And it should run everywhere bash runs
<BtbN>
Even just manually parsing it won't be easy, given converting a date time to unix isn't trivial
<Riviera>
i think the parsing is the annoying part,
<Riviera>
converting a date/time to unix time is a few lines of maths
<Riviera>
integer math even, so it's really fairly easy
<Riviera>
BtbN: you'd need a solution relatively soon i guess? if it could wait a bit i might consider writing it, would have to read the rfc for seeing how complex that'd be
<BtbN>
It's no rush, but I also don't want to send them a 2000 line parser monster
<Riviera>
yeah, that'd be ugly especially in bash
<BtbN>
Are you able to test date commandlines on OSX?
<Riviera>
BtbN: i'll check the RFC until the end of the week and let you know
<Riviera>
BtbN: yes
<Riviera>
last time I checked (a few years ago) the macOS date version only allowed relative date arithmetics, ie. you could say stuff like "+3 hours" "-2 days"
<ePirat>
BtbN, date -j -f "%Y-%m-%dT%H:%M:%S%z" "2025-03-17T01:46:29+0000" "+%s"
<BtbN>
date -j "SOMETHING" "2025-03-17T01:46:29Z" "+%s"
<BtbN>
supposedly works
<Riviera>
argh
<Riviera>
gawds right
<Riviera>
ePirat: forgot about that :D
<BtbN>
Does it parse the Z fine, or does it insist on the +0000?
<Riviera>
$ date -j -f "%Y-%m-%dT%H:%M:%S%z" "2025-03-17T01:46:29+0000" "+%s"
<Riviera>
1742175989
<ePirat>
insists on +0000
<Riviera>
$ date -j -f "%Y-%m-%dT%H:%M:%S%z" "2025-03-17T01:46:29+0100" "+%s"
<Riviera>
1742172389
<BtbN>
no good then, API returns Z
<Riviera>
Failed conversion of ``2025-03-17T01:46:29Z'' using format ``%Y-%m-%dT%H:%M:%S%z''
<Riviera>
let me see if %z is just the wrong format specifier
<Riviera>
hm, not finding a solution
<Riviera>
the Z could be dealt with manually, but then one had to read about all potential "quirks" of the format in the RFC