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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
dellas83 has joined #ffmpeg-devel
dellas has quit [Ping timeout: 256 seconds]
navi has quit [Quit: WeeChat 4.0.4]
iive has quit [Quit: They came for me...]
cone-058 has quit [Quit: transmission timeout]
sr55 has quit [Ping timeout: 276 seconds]
s55 has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 268 seconds]
thilo has quit [Ping timeout: 255 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
dellas83 has quit [Remote host closed the connection]
lemourin has quit [Read error: Connection reset by peer]
lemourin0 has joined #ffmpeg-devel
lemourin0 is now known as lemourin
AbleBacon has quit [Read error: Connection reset by peer]
<cone-526>
ffmpeg Haihao Xiang master:fc73b372cd43: lavc/qsvdec: reduce info message when more data is required
<cone-526>
ffmpeg Haihao Xiang master:05debdaa5fde: lavu/hwcontext_qsv: use mfxImplDescription instead of mfxExtendedDeviceId on Linux
<cone-526>
ffmpeg Haihao Xiang master:35a555e2b98e: lavfi/vf_vpp_qsv: set the default value of async_depth to 4
mkver has joined #ffmpeg-devel
qeed has quit [Read error: Connection reset by peer]
<rix>
what's the difference between AVCodecParser and FFCodec?
<Lynne>
parsers split/combine packets into something codecs can decode
<rix>
so on success, poutbuf and poutbuf_size will return the buffer that contains a full packet?
<Lynne>
yes, but the function does not have a failure value
IdontKnowAName has joined #ffmpeg-devel
<Lynne>
if it returns negative, it just means the frame start was in a previous packet
<Lynne>
as per the AVCodecParser.parser_parse() description in libavcodec/avcodec.h
<rix>
ok. I'm trying to understand what should I fill avctx->ch_layout in mlp_parse()
<rix>
since the parser doesn't take decoder options it seems, and there can be multiple modes to parse TrueHD channels that can result in different layouts
IdontKnowAName is now known as CrumpleZone
<CrumpleZone>
hello all, I am investigating how to have keyframed animation for a crop filter. The idea is that I would pre-process a clip, create a file full of crop parameters for each video frame, and then would like to pass those values to an ffmpeg encode from the cli. I've kinda come to the conclusion this isn't possible, but I saw there is way to talk over ZMQ to ffmpeg - however, as I understand, that is entirely interactive (i.e. one way - there's
<CrumpleZone>
no way to know what frame of the video we're at when we send a value). Is there currently a way to achieve the above?
<CrumpleZone>
I only post here because I'm intending to implement this (and would eventually submit a patch) but would like to know if the functionality exists in one way or another.
<Lynne>
rix: is there no information contained in the packet to parse them correctly?
<Lynne>
surely the decoder knows the layout
<Lynne>
CrumpleZone: there's an interface to control each filter, but it's C only
<Lynne>
patches which add support for parsing parameters via a file for a single filter will be 99% rejected
<rix>
Lynne: well, for example a TrueHD ATMOS stream with 4 substreams is compatible with 2/6/8/16 channels decoders, and depending on what mode is using, it may apply completely different matrixing and have very different channel layouts that may have non-overlapping channel positionings
<Lynne>
CrumpleZone: but if you have something capabile of adjusting parameters for multiple filters via the existing interface, it shoudn't be too bad
<rix>
my plan is to add a new TrueHD decoder option to specify the mode to operate the decoder, so it would choose the appropriate channel layout and matrixing
<CrumpleZone>
the patch would not be to control a single filter, but to implement a proper ROUTER/DEALER concept so that the current frame count could be dealt out to the sender tool. When you say there's an interface to control each filter, do you mean an externally addressable API?
<rix>
but question is how should I handle the avctx->ch_layout filled by the mlp_parse() parser function
<Lynne>
CrumpleZone: C api
<Lynne>
rix: I think for now you should just do 16-channel output
<Lynne>
downmixing is mostly reliable
<rix>
that's not a good choice because 16 channel usually involves dynamic objects, and until we have a full object audio renderer, they are not useful
<Lynne>
ambisonics, then?
<Lynne>
we have ambisonics support
<rix>
ATMOS are object based not scene based
<CrumpleZone>
Lynne: so you're saying there's no desire to make the zmq eval loop (in libavfilter/f_zmq.c) implement anything beyond what it is right now?
<Lynne>
CrumpleZone: oh, I didn't know you were going to use that part
<Lynne>
rix: then contribute an object-based output? jamrial may be interested too, as he implemented iamf, which is soon going to support object-based audio too
<Lynne>
it shouldn't be more complicated than just side data
<CrumpleZone>
Lynne: is there another part? (where ZMQ is, that is?) the loop is extremely basic in terms of what ZMQ is capable of. It would be relatively easy to make that substantially richer while probably maintaining some for of backward compatibility (I think probably total).
<Lynne>
sure, that doesn't sound too bad
<rix>
I haven't worked on object audio rendering. I'm planning to do the object audio PCM decoding and OAMD metadata attachment and maybe some parsing of those metadata
<CrumpleZone>
Lynne: (I take it you were responding to me), ok then I will start sniffing around this. I have a project that might utilize this and I am very fond of zmq. I will come back here if/when I have something that might be useful.
<rix>
I think what I'm looking for is a way to let the parser to signal that the stream provides different channel layouts instead of only reporting one of them
<Lynne>
rix: AV_CHAN_UNKNOWN in all channels?
<rix>
I defined an AV_CHAN enum range for dynamic objects, similar to AV_CHAN_AMBISONIC_BASE and AV_CHAN_AMBISONIC_END
paulk-bis has joined #ffmpeg-devel
<rix>
how about I limit the avctx->ch_layout reported from mlp_parse() to at most 8 channel, as that would not include any dynamic objects. and in the TrueHD decoder, I would then override the output channel layout if decoder option allows 16 channel with dynamic objects?
<Lynne>
that sounds reasonable, but talk with jamrial about adding enum values for dynamic objects
<rix>
ok
<Lynne>
we don't want to end up having no space left for more objects in case atmos 2024 adds 65536 objects
<rix>
that's fair
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<elenril>
huh, we have a tie for TC
<elenril>
haasn and JEEB will need to fight to the death
<JEEB>
lol
<Lynne>
huh, we do
<Lynne>
elenril: the faq says to look into the nonproportional representation
<Lynne>
in case there's a tie
<elenril>
that is also a tie
<Lynne>
really?
<elenril>
I just checked, it's 13 vs 13
<elenril>
i.e. 13 voters prefer 1st over second, and 13 the reverse
<elenril>
otherwise the system would resolve the tie automatically
<Lynne>
numbers are bigger in the nonproportional rep for jeeb though
<elenril>
which numbers do you mean?
<Lynne>
bottom, show details
<elenril>
I don't trust that computation very much
<elenril>
it is, at best, inverted
<Lynne>
now what?
<elenril>
08:34:49 @elenril | haasn and JEEB will need to fight to the death
<Lynne>
if you say another vote...
<elenril>
no, no more votes
<durandal_1707>
moar votes
<Lynne>
6-person TC, then?
<Lynne>
at least until the next vote
<Lynne>
how long is that away? how long does the TC last?
<Lynne>
(statistically, 3.5 years, but principally?)
<elenril>
a year
<elenril>
in theory
<Lynne>
"As an additional refinement, it is helpful to break ties between the proportional preferences of two committees by using the nonproportional preferences. This rule allows majorities to have their choice when the minority is indifferent."
<courmisch>
s/ARM/ARM and RISC-V/ anyone can do it
<j-b>
courmisch: sure, but your opinion is the question here. is it GAS too?
<Lynne>
kierank: in fairness, it does say on the voting page the algorithm is experimental
<kierank>
Daemon404: don't wake up
<kierank>
just stay in bed
* kierank
so glad not to be on GA
<courmisch>
j-b: it should be according to the RISC-V Assembly Programmer's Manual non-ISA specification
<wbs>
generally speaking, isn't it pretty much that GAS is the way to go for anything non-x86?
<wbs>
(although PPC seems to mostly go for intrinsics...)
<courmisch>
yes but GAS has taken certain questionable freedoms from the RV spec
<wbs>
oh, ok
<courmisch>
like allowing ADD in place of ADDI
<wbs>
is there any other large vendor implementation of an assembler for RV, other than GAS and the seemingly less mature LLVM?
<wbs>
(like ARM used to have their armasm)
<courmisch>
not that I know
<wbs>
I guess MS will release an rvasm or something like that, once they ship windows for RV
<courmisch>
I think LLVM was fixed earlier this year but that's version 17 or 18
<wbs>
ok
<wbs>
my latest gripes with aarch64 extension handling was fixed before LLVM 17 at least, so that should hopefully end up in the larger Xcode update around March next year
<durandal_1707>
all who voted for LibAV devs should be immediately stripped from all powers and banned from FFmpeg
<Lynne>
that's unfair to applicants, it may be too late to send patches to libav, so not anyone can be considered a libav developer
<durandal_1707>
Lynne: FFTW3 faster than tx!
<Lynne>
durandal_1707: for rdft, yes, and for everything we otherwise derive from rdfts
<durandal_1707>
Lynne: by how much?
<durandal_1707>
where is naive tx fix?
BetweenUs has joined #ffmpeg-devel
<haasn>
JEEB: if you want, you can take the tc spot
<haasn>
I’m not super invested
<JEEB>
surefine
<Lynne>
durandal_1707: correction, for dct2/3, we're 10% faster on 1024pt!
dellas has quit [Remote host closed the connection]
<Lynne>
we're 2% slower for 1024pt rdfts
<thilo>
haasn: JEEB: thanks!
<Lynne>
holy shit, why are we so fast???
<Lynne>
ah, I disabled SIMD for both
<durandal_1707>
lmao
<Lynne>
with SIMD, it's still not so bad, fftw is 26% faster
<durandal_1707>
why?
<durandal_1707>
what you did wrong?
<Lynne>
no SIMD for RDFT
<durandal_1707>
seriously?
<durandal_1707>
why?
<Lynne>
*partial SIMD for RDFT
<durandal_1707>
what is missing?
<Lynne>
the FFT is SIMD'd underneath, but the loop to turn an FFT to RDFT is not
<durandal_1707>
what that loop is doing?
<Lynne>
for DCT23, we're faster by 50% though!
<durandal_1707>
nobody uses DCT23
<Lynne>
it's the default, de-facto DCT, used from JPEG to mp2
<durandal_1707>
Lynne: where is that loop i wanna write x86 for it!
<cone-948>
ffmpeg Leo Izen master:019b3ea65aee: avcodec/jpegxl_parse{,r}: use correct ISOBMFF extended size location
<cone-948>
ffmpeg Leo Izen master:c4be080e65a3: avcodec/jpegxl_parser: fix parsing sequences of extremely small files
<cone-948>
ffmpeg Leo Izen master:b60d39fbe2b3: fate/jpegxl: add parser test for extboxes and small files
<Lynne>
for maximum speed, you should use the NIH-ABI we have in libavutil/x86/tx_float.asm
<Lynne>
which allows you to call the FFT directly in asm without needing branches
<Lynne>
the codelet builder goes all the way down to asm, even for asm to asm
<Lynne>
take a look at mdct_inv_float.transform to see how the call is performed
<Lynne>
keep in mind, you'll need to make checkasm for the RDFT, it's not so bad since I templated it, but you'll need to account for the +1 coeff size
<durandal_1707>
Lynne: you not want to work on this anymore?
<Lynne>
do you want me to work on it? for such a loop of 4 multiplies, I think I have time for
<durandal_1707>
what is status of other things in tx?
<durandal_1707>
anything near finishing?
<durandal_1707>
Lynne: if you do not have time than also send wip work of tx naive fixes/improvements
Krowl has quit [Read error: Connection reset by peer]
<cone-948>
ffmpeg Michael Niedermayer master:4cdf2c7f7680: avformat/mov: Ignore duplicate ftyp
<durandal_1707>
nobody wants to review asegment fate tests :(
<Lynne>
durandal_1707: I did tell you that I have cooley-tukey running, so it's close to being in sendable form
<durandal_1707>
i wait 2 years already
<Lynne>
it's already open on a virtual desktop, and I have a limited number of those, so I'll take a look at it
<Lynne>
what needs it the most? showcwt?
<Lynne>
or afir?
<durandal_1707>
you mean for naive C only variant?
<durandal_1707>
anything that allows non-power of 2 transforms
<durandal_1707>
virtual desktop? i work in tmux/xterm only
<durandal_1707>
afir is convolution so it does not need that its just happy with power of 2
<durandal_1707>
so showspectrum, but better use surround=win_size=N
<durandal_1707>
if you can test audio output by listening to it
<durandal_1707>
showspectrum is FFT and surround is RDFT
<durandal_1707>
will look into this rdft x86 thing seems relatively easy task
Krowl has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<kierank>
So when is sdr vote?
<durandal_1707>
never
<durandal_1707>
nevcairiel: why qoa tests on mingw segvs?
Daemon404 has quit [Ping timeout: 240 seconds]
navi has joined #ffmpeg-devel
Daemon404 has joined #ffmpeg-devel
navi has quit [Client Quit]
NuoMi has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
<cone-948>
ffmpeg Michael Niedermayer master:22daf2148fc0: avcodec/av1dec: Fix resolving zero divisor
MrZeus_ has joined #ffmpeg-devel
<jamrial>
durandal_1707: the slice = bytestream2_get_be64u() it seems
<jamrial>
you may be overreading the packet buffer with an unchecked call
<elenril>
unchecked calls were a mistake
<elenril>
people massively overuse them IMO
<durandal_1707>
no
<durandal_1707>
its fine
<durandal_1707>
files are broken
<durandal_1707>
and decoder check for full packet size is buggy
<jamrial>
that's why tests are good :p
Krowl has quit [Read error: Connection reset by peer]
<CrumpleZone>
Hi all, just following up on a question I asked last night regarding the ZMQ interface for ffmpeg. As due diligence, I'm trying to understand who would use the feature so I need to understand: is the current standard practice of making use of "dynamic" (i.e. changing over time) filter parameters done by using libffmpeg programmatically? (Lynne mentioned the C API for filters)
dellas has joined #ffmpeg-devel
<CrumpleZone>
toy example is, I went to re-encode a video and blur out a particular face. This is trivial to do using a command line call. It's also trivial to track a face using opencv. But I want to avoid having to roll out the kind of parallelization that I would otherwise get for free by making this into a bonafide binary. Is the current SOP for this to make use of libffmpeg and the C API?
<nevcairiel>
can confirm it crashes in that bytestream2 read
<Lynne>
durandal_1707: looking into r2c simd now, may be slightly more complicated due to needing to do LUTs
<durandal_1707>
Lynne: i'm looking into that one
<durandal_1707>
Lynne: you fix naive code
<Lynne>
but I want to do this simd, it's fun
<durandal_1707>
Lynne: naive makes tx nofun
Krowl has joined #ffmpeg-devel
<cone-948>
ffmpeg Jean-Baptiste Kempf master:6e26a5a64e12: doc/developer: require asm for RISC-V
<jdek>
j-b: reworded slightly
<cone-948>
ffmpeg Paul B Mahol master:7e453dad3c77: avcodec/qoadec: fix overreads and fix packet size check
<cone-948>
ffmpeg Paul B Mahol master:3047f05a99a9: tests/fate: add asegment filter tests
<courmisch>
maybe I'll write a not-blog post on how to install Debian
<elenril>
debootstrap is the only patrician way
<courmisch>
so, yes but only because RISC-V is an official architecture
<courmisch>
mmdebstrap is allegedly better for installing unofficial ports
<courmisch>
in any case, it's not just debootstrap
<courmisch>
there may be a few commands before and after it
<Lynne>
elenril: true dat, also allows you to install debian on whatever filesystem or partition scheme you wish
<courmisch>
elenril: and you forgot to mention that you need QEMU and binfmt support
<elenril>
qemu supports all existing hardware
<elenril>
obviously
<courmisch>
once upon a time, at a green blob corporation, a courmisch worked with a proprietary ISA that was not supported by QEMU
<courmisch>
elenril: now the question is, is jdek one of those RPM heretics
<jdek>
you don't want the real answer...
<courmisch>
that sounds like something a gentoo user would say
<jdek>
.
<courmisch>
I don't know what he did but unlord managed to miscompile his Genroot RISC-V rootfs
<jdek>
indeed was my distro of choice, but I primarily use windows & macos now
<jdek>
all my current linux systems are on nixos
kurosu has joined #ffmpeg-devel
<courmisch>
it could be worse. The vendor SDK uses Busybox/buildroot
<courmisch>
also runs Linux on the slow non-V core
<JEEB>
at least not openembedded/poky?
<courmisch>
no, custom "makefile" that officially and unofficially only works with -j1
<courmisch>
and will not compile on anything but Ubuntu 22.04 x86-64
<courmisch>
but eh, if you don't want to use my boot code, have fun
<JEEB>
courmisch: that's a brand spanking new ubuntu at least
<JEEB>
I'm using to someone mentioning at least 4 year old one :D
<courmisch>
sorry
<courmisch>
I meant Ubuntu 20.04
<elenril>
jdek: consider an exorcist
<courmisch>
I guess that my brain wanted to forget the abomination
<jdek>
I'm beyond saving
darkapex has quit [Remote host closed the connection]
<courmisch>
RISC-V support on macOS ... any decade
darkapex has joined #ffmpeg-devel
<courmisch>
Apple only signed up on Arm until 2040
<courmisch>
NG's last post is rather ironic if I say so myself
<jdek>
what's the workflow for risc? I guess just like cross compile on main pc + nfs on risc board
<courmisch>
I use crosscompile and rsync, but NFS is also possible
<courmisch>
you could compile natively. The FATE runner does. But it's obviously not the comfort of a Threadripper or an M1
Krowl has quit [Read error: Connection reset by peer]
<j-b>
durandal_1707: playing videogames on ARM on Linux? BS
<catfella>
tbf there are project that claim to enable precisely that
<Lynne>
you could probably emulate a ps3 on a graviton
<Lynne>
and still have leftover to run vulkan in software
Krowl has joined #ffmpeg-devel
NuoMi has quit [Quit: Leaving]
<courmisch>
emulating x86 is a lie
dellas has quit [Ping timeout: 260 seconds]
<courmisch>
unless you have control over the CPU *and* the OS (in other words, unless you are Apple)
dellas has joined #ffmpeg-devel
<courmisch>
it won't work on Arm because Arm doesn't have TSO
<courmisch>
and it won't work on RISC-V because it doesn't have 128-bit atomics and nobody implements Ztso
<catfella>
can't you at least control the os? if not hardware
<courmisch>
OS can't force TSO
<courmisch>
I should rather have written that you need to control the CPU and the emulator
cone-948 has quit [Quit: transmission timeout]
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
durandal_1707: yaay, loop done, reorder done (for r2c, c2r's reorder will be different), now I have to remember how I wrote the NIH ABI
<Lynne>
14 instructions (minus load/stores), 2 instructions per cycle min, maybe it could beat fftw even though they integrate rdft into their FFT by cutting out the last step
kurosu has quit [Quit: Connection closed for inactivity]
mkver has joined #ffmpeg-devel
BetweenUs has joined #ffmpeg-devel
<durandal_1707>
Lynne: show the code
<BtbN>
Anyone got any comments on the minimum alignment patch? It'll probably need backported a lot.
<durandal_1707>
i will push flite patches, and leave users to report any issues
MikhailAMD has quit [Quit: Leaving]
<durandal_1707>
j-b: you are still president of VLC and FFmpeg ? BS.
<Lynne>
this **MAY** be the very first time I've found haddps to be actually useful
<Lynne>
also, who uses flite? was it that text to speech thing?
<Lynne>
these days there's tortoisetts
<durandal_1707>
Lynne: why C code changed?
<Lynne>
it's just a simple reorder that I'm not going to commit
<j-b>
durandal_1707: I've never been :D
BetweenUs has quit [Quit: Leaving]
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 252 seconds]
AbleBacon has joined #ffmpeg-devel
<another|>
why oh why did I read ML again?
<courmisch>
because of an irrepressible masochistic pulsion?
qeed has joined #ffmpeg-devel
<another|>
have not considered that
<another|>
I really hope it gets better, now that there is a new CC
<durandal_1707>
another|: you are revenge seeking?
<another|>
No. I try not to burden my life with such petty stuff.
<durandal_1707>
another|: do you live under a bridge?
<another|>
What does that have to do with it?
MikhailAMD has joined #ffmpeg-devel
cone-965 has joined #ffmpeg-devel
<cone-965>
ffmpeg Nuo Mi master:e78c6a1f2c9e: MAINTAINERS: add myself as vvc maintainer
<durandal_1707>
Lynne: c2r ready?
<kierank>
durandal_1707: get a grip
<durandal_1707>
kierank: whats your problem?
<kierank>
why are you insulting another|
<durandal_1707>
another| is seeking revenge by enforcing CC tyrants
<another|>
tf would I seek revenge for?
* j-b
stabs another|
<j-b>
now, you do need revenge!
<courmisch>
another|: colour me pessimistic
<courmisch>
or should I say more pessimistic than my standard
MikhailAMD has quit [Quit: Leaving]
<durandal_1707>
elenril: why ffmpeg -i audio.wav -f null - , shows final duration smaller than actual duration reported by ffprobe/ffmpeg or stored in .wav?
sepro has quit [Quit: Bye!]
navi has quit [Quit: WeeChat 4.0.4]
<another|>
diff --git a/another b/another
sepro has joined #ffmpeg-devel
<another|>
- stab wound
navi has joined #ffmpeg-devel
<durandal_1707>
another|: is that the most useful diff?
<another|>
it's a patch
<another|>
badum-ts
<elenril>
durandal_1707: complicated reasons
<elenril>
I'll fix it after threading is in
<another|>
courmisch: "A man can dream. A man can dream..."
<durandal_1707>
elenril: is that blocked by NG only?
<elenril>
not sure if it's even blocked, he did not reply to my last email
<elenril>
otherwise yes
<durandal_1707>
another|: one man's dream another man's nightmare
<courmisch>
another|: I was not elected, so who possibly will sort it out?!
<elenril>
did something happen on ML today?
<elenril>
it seemed pretty calm to me
<j-b>
elenril: email down :D
<durandal_1707>
i voted for me on both CC and TC
<courmisch>
elenril: Somebody Dared To Merge A RV Patch Without My Permission. Can you believe this?
<durandal_1707>
what ?
<durandal_1707>
where ? when? how ?
<elenril>
ばかな！
<j-b>
:)
<courmisch>
jdek at 14:45 CET
<APic>
☺
<durandal_1707>
very big change
<courmisch>
you don't say. Clearly time to bring the ICBMs
<durandal_1707>
targeting criticial infrastructure everybody cares about
<j-b>
burn the world
<durandal_1707>
burnt the irc
<courmisch>
elenril: you fail to pick on my Hitori Gotoh references and now you pretend to know Japanese?
<j-b>
/j #ffmpeg-weeb
<elenril>
nah, I only pretend to know the memes
<courmisch>
so uncultured
<durandal_1707>
/j #ffmpeg-dark
<elenril>
though I have participated in at least one semi-coherent conversation in japanese in my life
<courmisch>
elenril: if it's any consolation even JEEB failed to pick it
<durandal_1707>
BtbN: is your ffmpeg build with flite?
<BtbN>
the name doesn't ring a bell immediately
<BtbN>
if that's an external library, probably not
<BtbN>
Google says flite is a codec pack for DirectShow?
<durandal_1707>
Google is fake news
<durandal_1707>
Lynne: for only r2c its here 22% faster comparing to before diff
<durandal_1707>
this is HUGE speed up !!! but looks like its float is not correctly scaling or not working properly