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
Marth64 has quit [Remote host closed the connection]
raven4Get has quit [Quit: Leaving]
Livio has quit [Ping timeout: 255 seconds]
<andrewrk>
IMHO, chromaprint should be ported to C and placed inside FFmpeg directly
<andrewrk>
one of the nice things about FFmpeg is that it doesn't drag in a C++ dependency
<andrewrk>
and libchromaprint upstream already has an FFmpeg dependency, and a bunch of boilerplate to abstract around the case when not using FFmpeg
<andrewrk>
the project has basically entered maintenance mode, and I see that it only took 2 weeks for somebody to port it to rust
<psykose>
they're also circular with eachother because to build fpcalc you need to build chromaprint with ffmpeg
<andrewrk>
yeah good point
<psykose>
which in some distros precludes adding chromaprint to ffmpeg :D
<psykose>
indeed would be nice
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
lexano has quit [Ping timeout: 256 seconds]
rvalue- is now known as rvalue
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<andrewrk>
I'll dip my toes in and estimate how long the project would take me
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 260 seconds]
Mister_D has quit [Ping timeout: 256 seconds]
<cone-416>
ffmpeg Tong Wu master:0faf2ca98a3a: avcodec/d3d12va_decode: remove extra spaces for declaration
<cone-416>
ffmpeg Fei Wang master:09377887df4b: lavc/vaapi_encode: Add VAAPI version check for BLBRC
<cone-416>
ffmpeg Haihao Xiang master:1590a96adc28: lavc/vaapi_encode: convert from lambda to qp
Pheo has joined #ffmpeg-devel
crimson has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<cone-416>
ffmpeg Fei Wang release/7.0:2d18c4906f29: lavc/vaapi_encode: Add VAAPI version check for BLBRC
<cone-416>
ffmpeg Haihao Xiang release/7.0:74e4e900bb52: lavc/vaapi_encode: convert from lambda to qp
mkver has quit [Ping timeout: 240 seconds]
crimson has quit [Quit: crimson]
jamrial has quit []
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 255 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
<andrewrk>
2 more observations about chromaprint
<andrewrk>
1. the first thing it does is resample to 11025 Hz. that could be done with the FFmpeg filtergraph and corresponding chromaprint code deleted
<andrewrk>
2. it uses S16 sample format for some reason, but then does a bunch of double floating point math on the samples, and then uses FFmpeg fft which uses floats
<andrewrk>
I think about half of this code could be deleted if it were properly integrated into FFmpeg and not maintained as a separate library
<andrewrk>
and it's only 2,500 lines to begin with
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<andrewrk>
I see av_buffersink_set_frame_size. Is there a way to pull overlapped samples from the filtergraph? for example, pull samples [0..4096], and then next time pull samples [2048..6144], and so on
Traneptora has quit [Quit: Quit]
<andrewrk>
looks like maybe I can use afftfilt with overlap=0.66
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Remote host closed the connection]
<Lynne>
are you implementing the FFT via a filter?
<andrewrk>
Lynne: I was looking into it, but it doesn't look like any filter API exposes the results of FFT as a buffer
cone-416 has quit [Quit: transmission timeout]
<andrewrk>
so my current strategy is abuffer -> aformat (mono, flt, 11025Hz) -> abuffersink (4096 framesize) -> then do manual processing from here
<andrewrk>
to be clear I'm implementing it outside of ffmpeg first just to get a feeling for the problem, but once I start patching FFmpeg then I think it should be implemented as a filter
<Lynne>
andrewrk: just do it all in the filter?
<Lynne>
swresample the frame, then av_tx() the data
<andrewrk>
ah, ok
bpmedley has quit [Ping timeout: 256 seconds]
<Lynne>
lavfi handles everything for you, including FIFO, and resampling
<Lynne>
during query_formats(), just specify that you only support 11025hz input and it'll automatically insert a resampler
<andrewrk>
aha, nice
<Lynne>
lavfi will accumulate samples and when you call ff_inlink_consume_samples with the specific number of samples you want, it'll give you that many
<Lynne>
for reference, you can take a look at anlms
kurosu has joined #ffmpeg-devel
<Lynne>
then just feed that into an... ah, FFT
bpmedley has joined #ffmpeg-devel
<Lynne>
FFT is a complex to complex transform, you should take a look at how chromaprint handles that
<Lynne>
it should put all input samples into the real part of the input coefficients and do an FFT, that's called an RDFT and we have optimized version just for that
<andrewrk>
it uses av_rdft_init(log2(4096), DFT_R2C) and av_rdft_calc()
<andrewrk>
with a hamming window
<andrewrk>
next there are a series of straightforward transformations that are put into a dozen different abstract C++ classes pretending to be generic streams for no reason
<Lynne>
ah, ok, it's just a standard RDFT
<andrewrk>
it's barely doing anything else after the RDFT
<Lynne>
keep in mind that av_rdft and av_tx use a different convention, av_rdft tightly packs the last real DC value into coeff[0].im, av_tx() leaves coeff[0].im as 0 and instead puts it at the end as coeff[len].re
<andrewrk>
this is a good DSP intro project for me. it's fairly straightforward, but I'll need to solidify my understanding a little bit in order to solve any bugs that pop up :)
<Lynne>
I'm surprised it's *that* simple, does it average all coefficients for every frame, then output that?
<andrewrk>
after RDFT, it reduces the data to 12 bands (corresponding to one octave), applies a simple filter with some hard coded coefficients, does a trivial normalization, and then calls it a day
<Lynne>
oh, so does it upload each 4096-sample frame's result to the database?
<andrewrk>
those black and white images at the end are a visualization of an acoustid fingerprint. this library also provides bespoke compression for them, resulting in a relatively small base64 string to be used as what is stored in the database
<jdek>
wbs: can you comment on [PATCH 2/2] configure: simplify bigendian check
<jdek>
also Lynne if u still have access to your POWER machine
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Ping timeout: 246 seconds]
<Lynne>
jdek: on it
<Lynne>
jdek: works
<wbs>
yeah.. I guess the previous check was meant to catch it even for compilers that don't expose those predefined macros
<jdek>
if we're requiring c11 now I think every compiler should have those macros
<wbs>
are those mandated by C11?
<wbs>
aren't those just compiler specific ones?
<jdek>
they should be mandated by big endian ABIs
<jdek>
but trying to find a source for that
<wbs>
that sounds like more of a platform specific thing - not sure if we work on weirdo vendor compilers anyway though (especially ones that claim to be c11 compliant)
<Lynne>
I'm not sure they're standard
<Lynne>
given that it was only c23 that introduces __STDC_ENDIAN_BIG__
<wbs>
exactly
ngaullier has joined #ffmpeg-devel
<wbs>
but those kinds of detections can some times give incorrect results with e.g. LTO (where the object files don't really represent the final binary form) or things like debug info. but if such options normally are applied only after this check, that's probably fine
<wbs>
(meson used to have issues if you passed e.g. '-g' in your cross file, as it did similar kinds of detections on object files)
<wbs>
for things like symbol prefixes
<jdek>
would you prefer filtering out -flto/-g and adding them in later again then
<jdek>
like yes the preferred way is to use --enable-lto but often times you still end up with -fto in cflags for other reasons
<wbs>
exactly... but if there's no known issue, I wouldn't start doing changes just for the sake of it either
<jdek>
this is a patch given to me by a downstream who had such issues with enabling lto globally
<wbs>
right
<wbs>
that might be good context to include in the commit message
<wbs>
filtering out such options also feels somewhat brittle, in that case it might possibly be better to go with your patch anyway, unless we know of concrete big endian tools that don't have such a define (and then we might look for another define too)
ngaullier has quit [Read error: Connection reset by peer]
<jdek>
I much prefer fixing it with this define and then finding the cases where that doesnt work and fixing with their proprietary defines
<jdek>
than grepping a binary file
<jdek>
nothing mandates object file representation either
<wbs>
that's true
<jdek>
I'll resend it with some rationale in the commit message in a few
geoffhill has quit [Quit: geoffhill]
Livio has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
<Lynne>
is there a spec where they put a chip in your head just to position it correctly in an environment with 32 audio speakers just to be able to do proper perspective calculations?
<JEEB>
:D
<Lynne>
oh, there is! the ISO/IEC 27092-2
<JEEB>
that's CICP, right?
<JEEB>
I think that is also in some ITU spec
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
<JEEB>
but yea, CICP defines the integer enum values that also MPEG-4 Audio uses
<JEEB>
(and mp4 etc with the channel layout box)
<Lynne>
no, it was just a random number
sudden has quit [Ping timeout: 272 seconds]
<Daemon404>
52
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
sudden has joined #ffmpeg-devel
<j-b>
lol
Livio has quit [Ping timeout: 272 seconds]
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Ping timeout: 252 seconds]
<Marth64>
yikes
<Daemon404>
big yikes
<kierank>
BBB: well well well
<kierank>
;)
<BBB>
what did I do
<JEEB>
> Query from Reuters on XZ, open source, and Microsoft
<BBB>
dafuk
<BBB>
:D
<BBB>
that's a good thing right?
<BBB>
I feel I should call the guy - assuming he really is from Reuters
<kierank>
I would have no problem with you calling him
<Daemon404>
i feel like he hasnt grasp he has published his details in public
<Daemon404>
grasped*
<JEEB>
yea
<kierank>
Might be interesting to not tell him that ;)
<BBB>
like what, so "Elon Musk" can call him?
<Marth64>
oh yeah, the guy who answers trac tickets
<BBB>
I'm waiting for "Elon Musk" to call him, claiming to be "Elon Musk" (whatever that means) - and then he'll get calls from thilo & jb & kieran & michael and he'll be super overwhelmed
<BBB>
while still not grasping fully what's happening
<Daemon404>
ng conspiracy theory replies on the ML seem more likely
<Daemon404>
and paul schizo posts
<Daemon404>
sorry. elon b mahol.
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 272 seconds]
cone-210 has quit [Quit: transmission timeout]
<BBB>
I agree that none of us can claim to represent the community as a whole
<BBB>
at the same time, each of us will have valid opinions that can be useful for an interview setting th way they're used to
<Marth64>
i'm sort of looking forward to the conspiracy theory replies
<kierank>
True
<kierank>
To bbb
<kierank>
Not to marth
<Marth64>
hahaha
<Marth64>
jokes aside, I did watch the demuxed 2023 video. nice speeches, kierank & j-b
<Marth64>
at first i thought it was recent because i was seeking around and hit the ffmpeg 7.0 slide
<BBB>
that was "forward-looking guidance"
cone-303 has joined #ffmpeg-devel
<cone-303>
ffmpeg Andreas Rheinhardt master:b351cbb31416: fate/api: Fix requirements of fate-api-seek
<cone-303>
ffmpeg Andreas Rheinhardt master:2cd397d90d70: fate/lavf-container: Check earlier for presence of ffmpeg cli
<cone-303>
ffmpeg Andreas Rheinhardt master:7eff280599ec: fate/libswscale: Disable ffmpeg-dependent tests without ffmpeg
<cone-303>
ffmpeg Andreas Rheinhardt master:07c734b2b2ff: fate/ffprobe: Fix test requirements
<cone-303>
ffmpeg Andreas Rheinhardt master:e123295cc870: avcodec/proresdec2: Rename to proresdec
<cone-303>
ffmpeg Andreas Rheinhardt master:a5fcd978011e: avcodec/libvpxenc: Avoid unused-variable warning if VP9 enc is disabled
<cone-303>
ffmpeg Andreas Rheinhardt master:abcb4b44f5d1: avcodec/tiff: Don't cast const away via bsearch
<cone-303>
ffmpeg Andreas Rheinhardt master:c96d0a0b850f: avfilter/avfilter: Use AV_DICT_DONT_STRDUP_(KEY|VAL) when possible
<cone-303>
ffmpeg Andreas Rheinhardt master:0c800c0b48f9: avfilter/avfilter: Honour the short options documentation
<cone-303>
ffmpeg Andreas Rheinhardt master:6260d4f770e0: avfilter/vf_swapuv: Remove empty options and AVClass
<cone-303>
ffmpeg Andreas Rheinhardt master:99a200cad8b6: avfilter/vf_vflip: Remove empty options and AVClass
<cone-303>
ffmpeg Andreas Rheinhardt master:de288e406ab2: avfilter/vf_hflip: Remove empty options and AVClass
<cone-303>
ffmpeg Andreas Rheinhardt master:8d3fdb42c030: avfilter/vf_grayworld: Remove empty options and AVClass
<cone-303>
ffmpeg Andreas Rheinhardt master:7895d1860f15: avfilter/avfilter: Don't use av_uninit
<kierank>
BBB: lol
<Marth64>
TIL ffmpeg jobs do exist
<Marth64>
I don't know why but in my previous searches I was always getting empty result. guess I am dumb.
<j-b>
Marth64: <3
<JEEB>
Marth64: also if you actually find something like that, try seeing how far you get without having existing gstreamer development experience :)
<Marth64>
<3 back
<Marth64>
my core professional experience is management honestly at this point. of course I know how to code but I don't know that I'm a good fit with a gst/ffmpeg hands-on job
<Marth64>
i'm more of a problem diffuser lol these days i do review PRs and snoop on code but don't get to do any hands-on
<Marth64>
dvd/ffmpeg kinda became an outlet for me
<JEEB>
:)
<JEEB>
and if you enjoy it, that's great
<JEEB>
I also enjoy (on some level) doing the stuff I end up doing, like plugging them pipes
<Marth64>
i enjoy working with people and solving problems/clearing roadblocks, but at some point when you realize you aren't passionate about the product, it goes downhill :(
<jkqxz>
Does anyone actually use the V4L2 M2M codecs?
<JEEB>
they are more or less leftover kind of things where the vendor doesn't want to implement requests
<JEEB>
like rpi4
<JEEB>
where there's a MMAL based v4l2 m2m wrapper
<JEEB>
but for HEVC there is native -requests decoder
<jkqxz>
Why is V4L2 requests still a weird external fork?
<JEEB>
it's *multiple* forks
<JEEB>
one for rpi, one for another vendor, third for another
<JEEB>
vOv
<kierank>
embedded
<elenril>
embedded people cannot imagine a world without vendor forks?
<kierank>
correct
<jkqxz>
Oh, so that's why it isn't upstreamed.
<wbs>
elenril: I wonder if that's the symptom of a 32 bit userland/kernel on a 64 bit kernel
<jkqxz>
I'm trying to decide what to do with the Intel patch to add a quirk for one of their VAAPI implementations to always use dynamic frame pools and therefore avoid the problems which other things have with it.
<cone-303>
ffmpeg Jan Ekström master:29561c8e2d4c: avutil/pix{desc,fmt}: add new matrix coefficients from H.273 v3
<cone-303>
ffmpeg Jan Ekström master:06c53efd2333: avcodec/options_table: map IPT-C2, YCgCo-R variants in colorspace
<cone-303>
ffmpeg Jan Ekström master:23d1b50175a6: avfilter/{buffersrc,vf_setparams}: map IPT-C2, YCgCo-R variants
<cone-303>
ffmpeg Jan Ekström master:16128f3c5595: avcodec/libx265: do not arbitrarily limit color values
<JEEB>
haasn: ^now we have DoVi Profile 5 VUI values in there. too bad the only encoder that doesn't either ignore or outright nope at these is SVT-AV1 :D
<elenril>
wbs: is it seriously 32bit in 2024?
<haasn>
JEEB: neat
<jkqxz>
It does seem like noone else actually cares at all. Things like D3D11 and V4L2 M2M are broken by the same problem but it's not obvious that anyone uses them such that they will notice.
<elenril>
jkqxz: what's the reason not to?
<jkqxz>
Because vendor-specific quirks are stupid?
<elenril>
oh, so it only works on intel
<elenril>
?
Marth64 has quit [Remote host closed the connection]
<jkqxz>
No, it works on current both the other Intel driver and current Mesa, but Intel doesn't care about those.
<elenril>
do you not agree that in general dynamic pools are superior, when available?
<jkqxz>
So just unconditionally doing it and seeing who breaks might be the easiest answer.
<elenril>
ah
<jkqxz>
Yes, but it seems bad to break other users.
<wbs>
elenril: raspbian waa primarily 32 bit for quite long at least, I think they provide both variants now
<wbs>
but uname saying 64 bit when compiler is 32 bit, is a mess
<elenril>
so you think the compiler is schizophrenice about its target arch?
<haasn>
mkver: regarding your proposed API for avcodec_get_supported_configs(), I assume the intent here is to also replace supported_framerates, supported_samplerates etc.
<haasn>
how should we handle the case of "no restriction" in the case of such fields which we can't easily enumerate?
<haasn>
just return NULL to mean "no restriction"?
<mkver>
Yes.
<wbs>
elenril: no the compiler is very clear about being 32 bit. but configure checks uname, if one doesn't specify --arch, and thinks the default target is 64 bit, and sets our config.h defines accordingly, and includes inline asm from the aarch64 subdir
<wbs>
(this is my hypothesis)
<elenril>
fun
<wbs>
so instead of uname, it should check $CC -dumpmachine or similar
<wbs>
(while the latter is nonstandard)
<BBB>
anyone know what "ELO scoring for images" means?
<kierank>
sounds like a weissman score
<kierank>
something to impress VCs
<BBB>
heh :) I only know weissman from silicon valley
<BBB>
which I guess proves the point
Livio has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
<j-b>
it's when images plays chess against each other
<cone-303>
ffmpeg Michael Niedermayer master:5a5422196d02: doc/developer: (security) researchers should be credited
darkapex has quit [Remote host closed the connection]
<j-b>
It says "should" in the commit log and the documentation says "always credit"
<j-b>
so, it's a must.
<cone-303>
ffmpeg Andreas Rheinhardt master:9c4558b5963b: configure: Fix iamfdec dependencies
Wenbin_Chen__ has joined #ffmpeg-devel
<j-b>
mkver: not yours :D
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
<mkver>
That's what I was worried about.
<j-b>
mkver: you never make mistakes :)
<mkver>
If only that were true.
<j-b>
:)
<BBB>
I think michael uses "should" as "I won't shoot you if you forget, but you really ought to"
<BBB>
which is fine
<BBB>
also in some theoretical situations, security researchers may wish to remain anonymous
<BBB>
this wording allows for that
<jkqxz>
I thought it was generally accepted that "SHOULD" means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course", so it seems pretty fair.
<jkqxz>
There may be some confusion caused by people who speak in lowercase-only, though.
<jkqxz>
Lynne: Do cooperative matrices actually get used for anything?
<jkqxz>
(I'm looking at making vulkan work for people who prefer to keep their blood internal again.)
<haasn>
jkqxz: doesn't seem like anything uses it
<jkqxz>
I guess it gets a CONFIG_EXTRA.
<haasn>
what is it even useful for? FFT?
<jkqxz>
I have no idea. Matrices I try to use are always uncooperative.
<j-b>
jamrial: ping
<JEEB>
haasn: 358919506d611493508c8af203c4dd15706c570f -> "It's of interest to API users, and of interest to us as a DCT/DST can be implemented via matrix multiplies."
<jamrial>
j-b: pong
<JEEB>
some new gcc 14 features of -fanalyzer were linked on #videolan , so I decided to try it out. glad to see that libavcodec/cbs_h2645.c still utterly confuses it
<jkqxz>
It builds, but unfortunately on that machine I have both "Device does not support the VK_KHR_video_decode_queue extension!" and "Vulkan filtering requires that the VK_EXT_descriptor_buffer extension is supported!" so can't actually use it for anything.
<jkqxz>
I get the feeling that there is more magic dependency that means it still isn't going to work in stable cases.
<andrewrk>
same! finally playing with ffmpeg again recently and looking into contributing a filter (Lynne has been graciously providing guidance)
<andrewrk>
I see you are harassing people for changelog entries. that is relatable as I'm also trying to get a zig release out the door and harassing contributors for release notes
<j-b>
Zig <3
ngaullier has joined #ffmpeg-devel
<j-b>
andrewrk: ever tried a Zig filter for ffmpeg? (I did)
<andrewrk>
oh neat! I didn't know you tried it
<j-b>
I'm a big Zig fan.
<andrewrk>
I am currently porting chromaprint to zig and using ffmpeg APIs. I was planning to further port it to C and contribute it as a filter after that
<andrewrk>
that way ffmpeg can lose the external dependency, and it will be in pure C and less complicated
<j-b>
great idea.
<cone-303>
ffmpeg Andreas Rheinhardt release/7.0:aeff85620ac6: configure: Fix iamfdec dependencies
<mkver>
jamrial: Default size of the interleaving queue in mux.c is 10s; there was more than 10s of audio in that test run, so it was written without waiting for the attached pic.
<wbs>
j-b: re changelog, I'd do s/ARM/AArch64/ for the HEVC bit
ngaullier has quit [Ping timeout: 268 seconds]
<JEEB>
j-b: +- Display metadata support in libx265, libx264 and libaom encoders <- 1) libaom -> SVT-AV1, I didn't touch since E_NO_INTEREST (also the next step is general codec-specific logic) 2) probably easier to call it "HDR10 metadata passthrough when encoding with libx264, libx265 and SVT-AV1"
<JEEB>
(if we want to call all the things their wrappers, the last one would be libsvtav1)
<Daemon404>
i wonder if well see papers for ages using vvcdec in the 7.0 release (rather than master)
<cone-303>
ffmpeg Anton Khirnov release/4.3:031c9601d067: lavc/pthread_frame: avoid leaving stale hwaccel state in worker threads
<cone-303>
ffmpeg Rémi Denis-Courmont release/4.3:93ecf0893407: avcodec/x86/mathops: clip constants used with shift instructions within inline assembly
<cone-303>
ffmpeg Rémi Denis-Courmont release/4.2:4cfb8dbe10fb: avcodec/x86/mathops: clip constants used with shift instructions within inline assembly
<j-b>
wbs: JEEB: noted and changed localy.
<cone-303>
ffmpeg Rémi Denis-Courmont release/4.1:7ef6f317f8f9: avcodec/x86/mathops: clip constants used with shift instructions within inline assembly
<JEEB>
and if the MP4 ambient viewing environment thing is worth a changelog entry, then I'll check if the support for it in decoders was during 7.0 development
<JEEB>
(also enabling HDR10 metadata in H.264 decoder, removing it from being HEVC specific)
<jamrial>
JEEB: it's mostly padding :p
<j-b>
JEEB: CLL also.
<j-b>
or whatever was your 12 patchsets with v16 :D
<JEEB>
that was the HDR10 passthrough set when encoding I think
<j-b>
ok
* j-b
is annoying
<JEEB>
I just use the HDR10 shorthand because otherwise you need to always mention MDCV/CLL and many people don't even know those names. but they do know HDR10
<j-b>
elenril: you cannot escape me
<JEEB>
ok, so ambient viewing environment in decoders went in during 6.1 already, so that's unrelated. so just MP4 reading and writing for it