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.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<kurosu>
re sfence and the movntdq* familly, yes, GPU. I remember nevcairiel chiming in some years ago when the same topic was brought. He might be someone with a better opinion or better facts than I
<nevcairiel>
that was limited to those gpu-specific copy functions though, no idea about any asm in sws
<nevcairiel>
trying to use sws straight on gpu memory seems like an adventure
<nevcairiel>
also, make the gpu do pixel shuffling, thats what they are good at
ramiro has quit [Ping timeout: 240 seconds]
<JEEB>
yea
<JEEB>
libplacebo is a good example of that :)
ramiro has joined #ffmpeg-devel
beastd has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Livio has quit [Ping timeout: 255 seconds]
Livio has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 264 seconds]
Krowl has joined #ffmpeg-devel
mkver has quit [Ping timeout: 272 seconds]
cone-858 has joined #ffmpeg-devel
<cone-858>
ffmpeg Gyan Doshi master:d55f5cba7b1f: avfilter/trim: flag trim filter as metadata only
IndecisiveTurtle has quit [Ping timeout: 246 seconds]
Krowl has quit [Read error: Connection reset by peer]
rvalue has quit [Ping timeout: 256 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
derpydoo has quit [Ping timeout: 240 seconds]
rvalue has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
Livio has quit [Ping timeout: 252 seconds]
cubicibo has joined #ffmpeg-devel
cone-858 has quit [Quit: transmission timeout]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
cubicibo has quit [Quit: Client closed]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
blb has quit [Quit: brb]
mateo` has quit [Ping timeout: 252 seconds]
blb has joined #ffmpeg-devel
mateo` has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
IndecisiveTurtle has quit [Remote host closed the connection]
Livio has quit [Quit: leaving]
Krowl has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
ramiro has quit [Ping timeout: 256 seconds]
ramiro has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
MrZeus has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 255 seconds]
ngaullier has quit [Ping timeout: 272 seconds]
Sean_McG has quit [Quit: leaving]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 256 seconds]
ccawley2011 has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<ramiro>
is there already a macro for aarch64 neon that loads a 32-bit immediate and replicates it 4 times in a vector?
<Lynne>
not really, I'd suggest just putting it in rodata
<Lynne>
I believe ld1r had worse timings on some chips, so I suggest just splatting it in an entire vector in rodata
<BtbN>
Is it valid to send 0 bytes via tcp? Pretty much only as a "would this block" check
HarshK23 has quit [Quit: Connection closed for inactivity]
<ramiro>
Lynne: thanks, I'll do that
<Lynne>
BtbN: may conflict with the return code for ancillary data only
<Lynne>
on the receive side
<BtbN>
hm, so it would send an empty packet?
<Lynne>
either that, or clients would interpret it as only receiving an ancillary data about something they subscribed
<BtbN>
Annoying, no idea how to sensibly implement non-blocking tls writes then
<BtbN>
For reading it's easy enough, but for writes, I see no clear solution
<Lynne>
I think it should be fine to send zero-sized packets, some voip systems rely on this for dtx
<BtbN>
it's ugly though
<BtbN>
specially because it's absolutely possible to check for blocking, it's just that our avformat layer does not implement it