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: 260 seconds]
rvalue has joined #ffmpeg-devel
cone-605 has quit [Quit: transmission timeout]
cone-426 has joined #ffmpeg-devel
<cone-426>
ffmpeg Andreas Rheinhardt master:b8a00a1f7333: avcodec/assenc: Use size_t for length of string
<cone-426>
ffmpeg Andreas Rheinhardt master:fe08058f24ca: avcodec/cbs_vp8: Don't leave out ... in calls to variadic macros
<cone-426>
ffmpeg Andreas Rheinhardt master:76b41511757f: avcodec/h264dec: Reindent after the previous commit
<cone-426>
ffmpeg Andreas Rheinhardt master:b550dd670a02: avcodec/h264dec: Return early in ff_h264_draw_horiz_band()
<cone-426>
ffmpeg Andreas Rheinhardt master:abea3749b32f: avcodec/webvttenc: Don't copy data around unnecessarily
<cone-426>
ffmpeg Andreas Rheinhardt master:686af4578c1e: avcodec/srtenc: Don't copy data around unnecessarily
<cone-426>
ffmpeg Andreas Rheinhardt master:253a8340f53f: avcodec/ttmlenc: Don't copy data around unnecessarily
<cone-426>
ffmpeg Andreas Rheinhardt master:ed9de6d2d8cb: avcodec/ttmlenc: Remove always-true check
<cone-426>
ffmpeg Andreas Rheinhardt master:e9a587af25f6: avcodec/srtenc, webvttenc: Use av_printf_format
<cone-426>
ffmpeg Andreas Rheinhardt master:4179c121c331: avcodec/movtextenc: Don't copy data around unnecessarily
thilo has quit [Ping timeout: 255 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
omegatron has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
rajivharlalka has joined #ffmpeg-devel
<cone-426>
ffmpeg James Almer master:76b2bb96b4ea: avutil/tx: print debug log at trace level
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 264 seconds]
jarthur has joined #ffmpeg-devel
rajivharlalka has quit [Quit: Connection closed for inactivity]
cone-426 has quit [Quit: transmission timeout]
mkver has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
rooisnoek has joined #ffmpeg-devel
rooisnoek has quit [Client Quit]
Krowl has joined #ffmpeg-devel
lexano has quit [Ping timeout: 264 seconds]
lexano has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
\\Mr_C\\ has joined #ffmpeg-devel
<jdek>
wbs: can I run gaspp on linux too somehow? --cc=clang --as="gas-preprocessor.pl clang" seems to configure but not build because of .const_data
<JEEB>
is that still required for clang?
<jdek>
no idea, just want to be able to test this locally easily
<wbs>
JEEB: no, modern clang has supported everything we need for gas macros since maybe 7 years or so - gas-preprocessor is only needed for MSVC for ARM these days
<another|>
heh. here I was thinking I found a new bug in ffv1. turns out it's been reported 8 years ago
<JEEB>
wbs: thanks. that matches my understanding wrt how I built recently for ARM :)
<wbs>
jdek: that manages to compile everything but one assembly file
<wbs>
it doesn't do exactly what it does with MSVC though; for that, you'd do -as-type armasm (but then the output can only be assembled with armasm of course)
<jdek>
i though lack of comma in the macro but .macro hevc_loop_filter_luma dir, bitdepth
<wbs>
let's see... gas macros behave ever so slightly different for apple targets
<wbs>
the reason for this, is that apple initially used their own binutils fork from maybe 1990 or so
<wbs>
which had a more primitive macroing system
<jdek>
oh wait, no comma in the macro call
<wbs>
with modern full gas compatible macroing in clang, they still retain support for that old system as well, which makes some bits behave slightly differently
<wbs>
yeah it's usually a missing comma somewhere
<jdek>
seems to be fine now
<jdek>
wbs: any other changes you want before I resubmit?
<wbs>
jdek: none that came to mind; I didn't look at the contents of the patches yesterday, I just ran them through this
<jdek>
right
<jdek>
as I noted in the checkasm changes, this function is quite difficult to bench in a vacuum
<jdek>
I originally wrote it differently but took this approach (even flawed as it is) since I thought it would be better in real-world performance
<jdek>
Lynne: see previous version of opengl/sdl deprecation patch on list for the comments re: just removing it. People generally learned towards deprecation
<wbs>
jdek: yep, loopfiltering benchmarking is a bit tricky, as it operates in-place, and it might not make the exact same decisions on each consecutive run
<jdek>
I struggle for registers a bit since I wanted to avoid having to save v8-v15
<wbs>
I often do that as well, but don't stress out too much about it, saving a couple of them doesn't really cost many cycles anyway
<jdek>
assumed that writing/reading from stack would be slower than slightly worse pipelining (at the end of the function only)
<haasn>
can we define AVERROR_SHOOT_SAMPLE_AUTHOR
novaphoenix has quit [Quit: i quit]
ngaullier has joined #ffmpeg-devel
novaphoenix has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
ngaullier has quit [Read error: Connection reset by peer]
ngaullier has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
cone-587 has joined #ffmpeg-devel
<cone-587>
ffmpeg Zhao Zhili master:338e33b084b1: avcodec/audiotoolboxenc: remove CAP_VARIABLE_FRAME_SIZE from alac
<cone-587>
ffmpeg Zhao Zhili master:80cd6e655bc9: avcodec/audiotoolboxenc: Ensure frame_size isn't zero
<nevcairiel>
probably because you use DKIM and the ML forwarding breaks that
<nevcairiel>
most of the mails on the ML are flagged like that for me, I had to setup a filter to exclude it from spam treatment
wcpan has joined #ffmpeg-devel
<jdek>
I dont think I changed anything with my mail setup in years though
<jdek>
why would it suddenly be different
<jamrial>
only patch 2/3 for me was flagged as such
<kierank>
potentially yes
<kierank>
I assumed when I unflagged 2/3 it unflagged them all
<kierank>
the world "block" for blockchain maybe?
<kierank>
and de for de-fi?
<jdek>
deblockchain
<elenril>
>@nevcairiel | probably because you use DKIM and the ML forwarding breaks that
<elenril>
I think it's the footer that breaks it
<nevcairiel>
the body change certainly doesnt help
<elenril>
I wonder if we should just stop adding it
<elenril>
I really doubts nontrivial numbers of people actually use it
mkver has quit [Ping timeout: 260 seconds]
<jdek>
seems reasonable, in replies you probably remove it manually anyway
<Gramner>
iirc mailman can be configured to perform mime wrapping the original message to supposedly be dmarc-compliant. no idea how well it works in practice though, but I'm sure someone would complain that it breaks their 1980s mail client written in lisp
drv has quit [Quit: No Ping reply in 180 seconds.]
drv has joined #ffmpeg-devel
<Lynne>
I don't know why I'm not affected, both dkim and dmarc (with zero policy) are enabled for me
<Gramner>
Lynne: your mails on ffmpeg-devel fail DKIM/DMARC, but your domain is not configured to do nothing on failure (p=none)
<Gramner>
if you were to set p=reject or p=quarantine it would break
<Gramner>
s/not//
drv has quit [Ping timeout: 268 seconds]
<Lynne>
hard for them to not fail it after being resent by a mailing list
Krowl has quit [Read error: Connection reset by peer]
AbleBacon has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
<courmisch>
munging emails is evulz
<elenril>
^
<BtbN>
What's the correct way with avio_* to check if the target url "exists"?
<elenril>
don't
<BtbN>
I got the problem right now that I have the segment muxer biting its own tail, cause it's using a unix timestamp as filename, and sometimes when bursts of data come in, it overwrites the same file multiple times.
<courmisch>
that sounds like a ToCToU in the making
<courmisch>
the only one correct way to deal with that is the O_EXCL flag
<courmisch>
otherwise, you have a text-book ToCToU attack leading to potential data loss
<courmisch>
(obviously, you can't do that with an abstraction layer, you need to take into stdio or io directly)
<courmisch>
s/take/tap/
<elenril>
why couldn't that flag be propagated through avio?
<courmisch>
what other output would implement it?
<courmisch>
and how should it work if unsupported?
<JEEB>
in this case for unix timestamp based file names I'd say just have the max(number) saved in the context and files shouldn't be possible to write which are <= that
<BtbN>
well, it never sees a number
<BtbN>
just a strftime string
<BtbN>
I'm adding a horrible hack for now to at least avoid the problem
<BtbN>
(i.e. sleep until the strftime result is different from last time)