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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
minimal has quit [Quit: Leaving]
iive has quit [Quit: They came for me...]
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo_ has quit [Ping timeout: 260 seconds]
<Lynne>
wbs: no, thanks
cone-890 has quit [Quit: transmission timeout]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
jamrial has quit []
<Lynne>
wbs: err, this was fixed in master
<wbs>
Lynne: it was? where? I can still repro it on latest master
<TheVibeCoder>
shouldnt that code use bsf instead of that hack?
<TheVibeCoder>
pross: ^
<pross>
maybe. there are many properties in the mlv header (like white/black level, cfa pattern) that we need to transmit alongside the bayer jpeg. can bsf handle that?
ngaullier has joined #ffmpeg-devel
<TheVibeCoder>
bsf rewrites packets
rvalue has quit [Ping timeout: 245 seconds]
rvalue has joined #ffmpeg-devel
<cone-664>
ffmpeg Kacper Michajłow master:53da090ab7bf: configure: fix Microsoft tools detection
microchip_ has quit [Ping timeout: 272 seconds]
Guest79 has joined #ffmpeg-devel
microlappy_ has joined #ffmpeg-devel
Guest79 has quit [Client Quit]
microlappy has quit [Ping timeout: 252 seconds]
microchip_ has joined #ffmpeg-devel
mkver has quit [Ping timeout: 265 seconds]
microlappy_ has quit [Quit: Konversation terminated!]
<haasn>
TheVibeCoder: oops, copy/pasted that license header :) fixed
kurosu has quit [Quit: Connection closed for inactivity]
jamrial has joined #ffmpeg-devel
cone-664 has quit [Quit: transmission timeout]
Kei_N has quit [Ping timeout: 248 seconds]
Kei_N has joined #ffmpeg-devel
<TheVibeCoder>
haasn: the true peak and sample peak is same code, just one use longer buffer
<TheVibeCoder>
and updates/stores to different place
<haasn>
good point, we can use the same asm routine for both
<haasn>
probably that routine could be optimized further
<TheVibeCoder>
there is no need to use 2 FFMAX there
<haasn>
I did also try changing the logic to have the loop over samples handled by asm (with a fixed channel count) but it was only 5%-10% faster
<TheVibeCoder>
one only updates frame (sample/true) peaks, and updates global peaks after loop ends...
<TheVibeCoder>
dunno how faster would be instead of swresample code use windowed sinc 4x resampler of 48 points
<TheVibeCoder>
but i guess they are not interested in true peak speeding up?
<haasn>
they are, but currently they run the true peak detection separately from the ebur128 filter
<haasn>
TheVibeCoder: for the peak detection, do you know if it is possible to bypass calculating it altogether for sections which the averaged intensity is sufficiently lower than the current true peak?
<haasn>
I think not, because the intensity is measured as the average of squares, which may be substantially below the true peak in a frame
<TheVibeCoder>
windowed sinc allows that, like linear interpolation (which uses 2 points. this one uses much more)
<TheVibeCoder>
and it needs only 24 past and forward original samples
<haasn>
but maybe something we could instead do is, first use the sample peak detection function to see if the current sample peak exceeds the previous sample peak, and only run the swr_convert() when that is the case (to find the true peak, possibly already limited to a small window around the sample peak)
<TheVibeCoder>
for 48. point sinc
<haasn>
since I think the time of true peak detection is dominated by the resample step
<TheVibeCoder>
swr is not designed for such things afaik
<TheVibeCoder>
besided true peak in r128 specification is also FIR filter
<TheVibeCoder>
just with less points
<TheVibeCoder>
thing is what speed ratio would you get with such periodical upsampling, and would it be guaranted to provide correct results
<TheVibeCoder>
the true peak "science" is more dark art
cone-045 has joined #ffmpeg-devel
<cone-045>
ffmpeg Dawid Kozinski master:8087777e667c: avcodec/liboapvenc: set the encoder output to OAPV_CFG_VAL_AU_BS_FMT_NONE format
<cone-045>
ffmpeg Dawid Kozinski master:5d380e4431a7: configure: Update liboapv version requirement
rvalue has quit [Ping timeout: 276 seconds]
rvalue has joined #ffmpeg-devel
<kasper93>
wbs: Could we add host_extralibs= in win32|win64) target_os case?
<kasper93>
cl.exe is ignoring -lm with warning as invalid arg
<kasper93>
clang.exe is trying to link m.lib, which obviusly doesn't exist on this target
<kasper93>
do you know a case where it would be needed?
<wbs>
kasper93: yeah I ran into this when I tested things on windows now myself too. however, we can't do that based on target_os; then we'd remove it from host_extralibs when we're cross compiling to windows on linux too, while the host tools do need -lm
<kasper93>
we have mingw64 target_os for this, no?
<wbs>
that is entirely orthogonal
<kasper93>
ok, fair
<wbs>
you can compile with msvc, or clang in msvc mode, or mingw, on linux
<kasper93>
yes, but then two first doesn't need -lm
<wbs>
you're mixing things up
<wbs>
if I'm cross compiling with a msvc toolchain, on linux
<wbs>
then my host_cc is still a linux gcc
<kasper93>
oh my, it's host_extralibs, now I see it
<wbs>
exactly
<wbs>
so the proper fix would to do more of the same kind of toolchain detection, that we do for the target compiler, for the host compiler too
<wbs>
we do it to some small extent so far
<wbs>
regarding the resource file and bin2c and backslashes; if you compile with "clang-cl" you probably don't hit that. when compiling with clang-cl, we use $cc -showIncludes with a _lot_ of postprocessing to produce the .d files, while with "clang" we use the regular gcc style -M* parameters for generating a .d file
<wbs>
now the problem is that on first compile, e.g. graph.html.o is compiled from graph.html.c which is generated from graph.html
<wbs>
but the compilation of graph.html.o produces a .d file which says "graph.html.o: fftools\resources\graph.html.c"
<wbs>
then make will try to regenerate fftools\resources\graph.html.c from graph.html, and choke at the insufficiently quoted backslashes
<kasper93>
yes, right, it's windows clang after all
<wbs>
(side note; when building clang, one can configure whether it should prefer to produce backslashes or forward slashes as path separator; for mingw flavoured builds of clang, the default is forward slashes)
<wbs>
normally in such a build, all the .d files produced by clang have got backslashes, and make copes just fine with it
<wbs>
it's just the pattern rule that ends up matching, that tries to run bin2c with a path with backslashes as input
<haasn>
TheVibeCoder: sample peak vs true peak detection is a ~4x speed difference, so it really is dominated by resampling
<haasn>
sample peak detection is almost free now (~2%)
<haasn>
TheVibeCoder: does anybody actually care about true_peaks_per_frame?
<haasn>
maybe we could make it a separate option, to allow us to skip true peak calculation in the future without having to preserve it just for this printout
<TheVibeCoder>
IIRC it was added by some guy in past
<TheVibeCoder>
~4 difference in speed, smells like linear complexity sample rate conversion
<haasn>
TheVibeCoder: something else weird about this function is that it says if (ebur128->metadata) /* happens only once per filter_frame call */, but the code actually triggers every 400 ms
<haasn>
what if the audio frame contains more than 400 ms of data?
<haasn>
or is something else preventing that?
<TheVibeCoder>
i think it would just overwrite/replace prev values
<TheVibeCoder>
but, yes, it should be called only once
<TheVibeCoder>
per frame
<TheVibeCoder>
if meatadata or true peak, its process 100ms of data per frame
<TheVibeCoder>
maybe that causes additional slowdown for true peak, as it moves samples around more
<TheVibeCoder>
at least for true-peak it should not be mandatory to have 100ms frames
<TheVibeCoder>
but then resampling code needs addtional changes
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 244 seconds]
kurosu has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
<cone-045>
ffmpeg Lidong Yan master:ee1f79b0fa4c: avformat/sbgdec: fix leak in sbg_read_header()
<TheVibeCoder>
zlib compression is the truly rocket science
DodoGTA has quit [Quit: DodoGTA]
<kasper93>
I sense mild amount of sarcasm
DodoGTA has joined #ffmpeg-devel
<TheVibeCoder>
zlib decompression is the truly string theory
devinheitmueller has quit [Ping timeout: 252 seconds]
<TheVibeCoder>
anyone have svq3 sample with watermarking ?
<haasn>
TheVibeCoder: it's easy to generate a sample file where the true peak is arbitrarily far from the sample peak
<haasn>
say the resampling filter coefs are [k1, k2 ... kN], if the input signal is something like { 1 if kN > 0 else -1 } you get a true peak at that location of |k1| + |k2| + ... + |kN| > 1
<haasn>
(since k1 + k2 + ... + kN = 1)
<haasn>
place this somewhere at 0.9 amplitude and then have a sine wave of amplitude 1 somewhere far away
<haasn>
so there really is no easy way to avoid checking the whole file for the true peak
<haasn>
unless you can do a prepass to detect such adversarial examples