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
Everything has quit [Quit: leaving]
thilo has quit [Ping timeout: 265 seconds]
thilo has joined #ffmpeg-devel
<kierank>
should I buy a lettuce
Marth64 has quit [Ping timeout: 265 seconds]
Marth64 has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 260 seconds]
jamrial has quit []
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 265 seconds]
<kierank>
ffmpeg.org is down
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 265 seconds]
thresh has joined #ffmpeg-devel
<Marth64>
yes
<Marth64>
just came back up actually for me
<Marth64>
nvm...cached..yea its down
mkver has joined #ffmpeg-devel
<Lynne>
we've made fun of matrix on this channel before
<Lynne>
but its so sad at this point
<Lynne>
they tried to carter to the new proposal by the EU for a unified chat protocol everyone speaks, and gladly folded to the demands of big companies
<Lynne>
they've been working on a sliding sync protocol to allow fast joining of channels, but after 2 solid years of development, a complete and optimized implementation, and a spec literally everyone uses and supports, its still not merged and official!
<frankplow>
Is the ML down? I received a mail addressed to me and I see ffmpeg-devel@ffmpeg.org is also in the To: field, however I did not receive the copy of the mail from the reflector, nor has it appeared on the archive.
<frankplow>
The mail was sent around the time this morning when it appears ffmpeg.org was down. ffmpeg.org appears to be back for me now.
<kurosu>
Not again
<frankplow>
Yes I think the ML is down. Just tried sending a mail and it didn't bounce back nor did I get a reflected copy.
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 252 seconds]
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 244 seconds]
rvalue- is now known as rvalue
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<BtbN>
Some check_policy_service is down.
<BtbN>
Turns out it was grossd, which just exited at 5am tonight
<kierank>
what does SECTION_RODATA actually do compared to the normal declaration
<wbs>
I'm not sure about what the "normal declaration" means here, but I presume it means placing the data in the text section
<wbs>
separating data in a separate readonly section is good for utilizing the I-cache better, to avoid filling it with things that isn't code
<kierank>
"section .data"
<wbs>
also, some security modes on some OSes makes the text section execute-only, not readable (openBSD has this for aarch64, it seems - we had to fix up a bit in dav1d to make that work without downstream patches)
<kierank>
what does the macro actually do undernearth
<wbs>
oh, .data is read-write
<kierank>
ok "section .rodata"
<wbs>
like for any global variable; that section contains the initializers for it
<wbs>
yeah, the exact way to switch to the readonly data section differs between COFF/ELF/MachO
<kierank>
ahh
<wbs>
on COFF it's .rdata, not .rodata
<wbs>
on MachO it's .const_data instead of .section <foo>
<kierank>
Not sure if there are other topics to cover in lesson 2
<kierank>
I was going to do the negative offset trick in lesson 3
<JEEB>
ah, this reminds me of the time I did some basic loop asm for median prediction :)
Everything has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 276 seconds]
<kurosu>
kierank: discussing FLAGS sounds dangerous. x86 memory addressing... Why not, but the elephant in the room is RIP relative addressing, and that easily comes to bite you on x86_64
<kurosu>
(s/dangerous/prone to confuse)
<kierank>
Is that something you have to deal with when writing SIMD in FFmpeg?
* kierank
has not dealt with it
<kurosu>
Maybe not, you're right. Just that it's often what you get when you look at the debugger/disassembly output
<kurosu>
I remember trickeries in dav1d code
<Gramner>
most of the weird stuff is on 32-bit x86. x86-64 is not particularly complicated in that regard
<kierank>
tbh the mailing list workflow is going to be the hardest part of getting contributors
<kierank>
maybe I'm going to have to accept PRs and then forward them myself to the ML
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
<Compn>
This project provides tools for copying pull requests and patch comments to a mailing list or other email address. This can be useful for integrating github with an email-based workflow.
Everything has joined #ffmpeg-devel
Mirarora has joined #ffmpeg-devel
<kierank>
What does DEFINE_ARGS do?
<jamrial>
kierank: gives registers aliases
<kierank>
ah so it lets you override the ones in cglobal?
<jamrial>
so you can use something other than the default r0, r1, etc
<jamrial>
yeah
iive has joined #ffmpeg-devel
<kierank>
oh so you can name extra ones you make along the way, I see
<kierank>
that are not arguments
<jamrial>
you can also name non argument regs in cglobal. DEFINE_ARGS overrides whatever cglobal set