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
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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<cone-001>
ffmpeg Andreas Rheinhardt n7.1-dev:HEAD: avcodec/wavpack: Remove always-false check
kasper93 has joined #ffmpeg-devel
hbbs has quit [Ping timeout: 240 seconds]
<Lynne>
happy release
<Lynne>
mkver: planning for 7.1 already?
<jamrial>
Lynne: that was me, and it's the typical post branch tag
<jamrial>
it ensures git describe doesn't refer to an old release
<andrewrk>
congrats!
<Lynne>
oh, right, I didn't know it was manual
kurosu has quit [Quit: Connection closed for inactivity]
IndecisiveTurtle has quit [Ping timeout: 256 seconds]
mkver has quit [Ping timeout: 264 seconds]
arch1t3cht9 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 264 seconds]
arch1t3cht9 is now known as arch1t3cht
thilo has quit [Ping timeout: 272 seconds]
thilo has joined #ffmpeg-devel
<Marth64>
+1 to happy release
<Sean_McG>
same
<Sean_McG>
just for my own edification -- are we trying to do quarterly (or sooner) releases? is there some way I can help make sure we meet that?
<Lynne>
once every few months
<Lynne>
yeah, by simply making releases not as special
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
arch1t3cht3 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 268 seconds]
arch1t3cht3 is now known as arch1t3cht
<Marth64>
user support channel #ffmpeg topic still says 6.0 whenever an op gets a chance
<Marth64>
here is fancy color version:
<Marth64>
-~ FFmpeg 7.0 is released !~-
<Marth64>
(compatible irc client required to see colors, but most should work)
cone-001 has quit [Quit: transmission timeout]
zsoltiv__ has quit [Ping timeout: 268 seconds]
<blb>
congrats on 7.0 y'all
<Lynne>
minor releases get the best features
jamrial has quit []
<Marth64>
7.1 will be awesome
AbleBacon has quit [Read error: Connection reset by peer]
<Marth64>
some user-friendliness thing has been bugging me though since 6.1. if you remux to a format that supports setting colorspace info (eg mkv) and you set for example -color_primaries, CLI will log a warning saying the attribute isn't used (as its a streamcopy). but on the format metadata, the attribute is actually being set. so the log message is misleading, and wouldn't print in that
<Marth64>
scenario prior to 6.1
<Marth64>
at least as of 2 wks ago i still noticed it, i'll check again tomorrow. its harmless just confusing-ish
<Marth64>
on the format's stream metadata*
Traneptora has joined #ffmpeg-devel
<andrewrk>
Lynne: do you have any suggestions for debugging why there is a discrepancy the results from av_rdft_calc vs the reference implementation? https://clbin.com/OXxHA
<Lynne>
andrewrk: which reference?
<andrewrk>
`fpcalc test/data/test.mp3`
<Lynne>
what is buggy?
<Lynne>
is reference libchromaprint?
<andrewrk>
big picture: my implementation gets a lower match score on some songs, and fails the match on other songs, compared to fpcalc
<andrewrk>
in this data that I linked: some of the values returned from av_rdft_calc seem too much different from the results that fpcalc receives (particularly the second value in the first row)
<andrewrk>
I guess I'll try visualizing each frame of input to av_rdft_calc and try to spot a difference
<Marth64>
you can maybe checksum chunks of the video with streamhash and compare to a known sample to narrow down where the difference is, if the difference is time based
<Marth64>
(i am not a dsp expert)
<Marth64>
saves you visual strain if its feasible for your work
<Lynne>
what is fpcalc?
<andrewrk>
fpcalc is the command line tool bundled with libchromaprint that inputs a file and outputs an acoustid fingerprint
<Lynne>
oh, and it also outputs the coefficients?
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 240 seconds]
<andrewrk>
aha, I visualized the input to av_rdft_calc and noticed that only the first third of the window is populated with data
<andrewrk>
which, suspiciously, corresponds to the hop_size (window_size / 3)
<Lynne>
you're not using av_tx, right?
<Lynne>
av_rdft is a wrapper around it which moves the coefficient to [1] for compatibility
<Lynne>
the reference makes no sense
<Lynne>
since [1] must be either a real DC value (old av_rdft-style), or exactly [0] (everything else)
StevenLiu has quit [Remote host closed the connection]
StevenLiu has joined #ffmpeg-devel
raven4Get has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
<Lynne>
is there a way to set the frame size for an encoder which supports that?
<andrewrk>
are you suggesting libchromaprint is using the ffmpeg API incorrectly?
<Lynne>
make sure you're using the same ffmpeg version for both
<Lynne>
*the same*
<andrewrk>
I'm not
<andrewrk>
will check that now
<Lynne>
they also have no idea what they're doing, they're taking the square of the current complex number's imaginary and the next complex number's real
<Lynne>
oh, nevermind
<andrewrk>
the reference fpcalc I have built from source is with ffmpeg 5.1.3
<andrewrk>
however my project is currently on 6.1.1
<psykose>
you can build fpcalc against 6.1.1 too with like one patch
<andrewrk>
my new desktop built ffmpeg 6.1.1 in 25 seconds 🤩
<andrewrk>
the fpcalc I have built from source against ffmpeg 6.1.1 produces byte-for-byte identical output for the example song as the system provided fpcalc which is on ffmpeg 4.x
<andrewrk>
so, there must be some problem introduced by my implementation
<Lynne>
use 7.0 just in case, because of 90adef99cab46ed1791c8096ac2ac0b89f67a266 causing overreads
<Lynne>
phase-wise, yes, but why is the peak not on the left?
<andrewrk>
because of the hamming window, I thought? it looks like a bell curve
<andrewrk>
https://i.imgur.com/f9iqfds.png same thing but with reference overlaid on top. green is reference; magenta is mine
<andrewrk>
are these differences significant enough to be problematic do you think? could this be due to using the av filter graph vs a direct call to av_resample?
<andrewrk>
or maybe my decision to use flt instead of int16
<andrewrk>
oh, you're asking why not orient the waveform vertically?
<andrewrk>
good idea
<Lynne>
no, that's frequency spectrum, right?
<andrewrk>
no it's a waveform because it's the input to av_rdft_calc
<andrewrk>
which, according to my understanding, is what produces the frequency spectrum
hbbs has joined #ffmpeg-devel
hbbs has quit [Changing host]
hbbs has joined #ffmpeg-devel
<andrewrk>
I'm trying to understand where error is creeping in in my implementation and I'm lacking the DSP experience to know where it is
<andrewrk>
or rather to know what it looks like
<andrewrk>
I guess I'll produce visualizations of the entire process for starters
hbbs has quit [Ping timeout: 252 seconds]
hbbs has joined #ffmpeg-devel
hbbs has quit [Changing host]
hbbs has joined #ffmpeg-devel
<Lynne>
it's not an input issue, I think
ngaullier has joined #ffmpeg-devel
<kierank>
posted on X about 7.0
MisterMinister has quit [Ping timeout: 256 seconds]
<another|>
that tweet popped up in various forms everywhere in my feed
<Daemon404>
i swear half the comments are about using chatgpt to make ffmpeg cli arfs
<Daemon404>
why learn when you can not
<elenril>
yeah...
<elenril>
people keep hurfing how our documentation is so horrible, but when I try writing some nobody reads it
<aaabbb>
i always read the documentation :(
<elenril>
you're in the minority then
<elenril>
a very tiny one
<aaabbb>
i guess ms would consider me overqualified, since i read documentation
<Daemon404>
afaict the average cli user doesnt even understand what order to put options in
<Daemon404>
(before -i etc)
<elenril>
even though it's said very clearly in the very first section
<elenril>
and in the one-line synopsis even
<aaabbb>
people often don't understand the implications even if it's explained there. it's not because ffmpeg is hard to use, it's because audio/video is not trivial
<Daemon404>
there is a set of people who just try stuff over and over instead of stopping to think
<Daemon404>
human AI style
<Daemon404>
aaabbb, true, one cannot understand howbto do something if they dont even know what they want to do.
<wbs>
I saw one case of someone using ffmpeg, via a javascript api wrapping the ffmpeg cli invocations... wanting to do things like transcode something, shrink video, set framerate and bitrate etc. this was done by invoking N repeated ffmpeg calls, each time just setting one option for changing one aspect
<aaabbb>
that's the first thing i learned when i got into av. my first fallacy is "wow this is a complex tool, how the hell do i understand it?" then it finally turned into "wow av is complex, how do i understand it?" and i finally started making progress
<Daemon404>
wbs, we call that composability!
<aaabbb>
wbs: generation loss stress tester? :D
<wbs>
aaabbb: yup, pretty much!
<another|>
I still see lots of `-r` options thrown around. Was under the impression you're rather supposed to use `fps` filter in most cases?
<Daemon404>
-r does many thinga
<aaabbb>
another|: really depends on the use case
<Daemon404>
it is really a poor option
<Daemon404>
overloaded functionaloty
<Daemon404>
e.g. you can *sort of* use it to set rates on stuff like elementary streams and image sequences
<another|>
hmm.. recently I actually had to use it for remuxing to the timebase I think
<another|>
*to set the
<aaabbb>
that's what i use it for. the fps filter on the other hand will happily drop or duplicate frames
<aaabbb>
i've seen people misuse the poorly named framerate filter when they wanted to use fps...
<elenril>
another|: for framerate conversion, -r has a more sophisticated algorithm
<elenril>
which really should be folded into vf_fps, but it's float-based so it's not trivial
<another|>
hmm.. oka
<JEEB>
til the ffmpeg,c adhoc is more sophisticated
<JEEB>
Daemon404: I see you dislike -r sometimes setting the rate, and sometimes "pls convert to this rate"
<Daemon404>
it is classic 2006 ffmpeg
<Lynne>
-re is my favorite ffmpeg.c flag
<jdek>
lib(-re)mpeg
<Lynne>
what it means: "send packets at just under realtime, as indicated by timestamps", very useful for when you want to starve a receiver
<JEEB>
Lynne: :D at least that got a new name now
<JEEB>
which lets you set the speed as float, too
<Daemon404>
that sounds doomed to fail?
<elenril>
doom9ed?
<another|>
hmm.. is there a spec for ivf?
<Daemon404>
no
<Daemon404>
multimediawiki is the best youll get
<Daemon404>
butnit is extrwmely simple
jamrial has joined #ffmpeg-devel
<JEEB>
yea it's not really a container, closer to annex
<JEEB>
*annex b
<Lynne>
simple, yet it still found a way to have unused fields
<Daemon404>
also no way to get the duration of the last frame
<elenril>
Daemon404: it has been prophesied by John of Patmos that the duration of the last frame shall be revealed when the sixth seal is broken and the moon becomes as blood
<haasn>
mkver: elenril: can you think of a conceivable case in which avcodec_get_supported_config() might error out?
<mkver>
Besides allocation error?
<haasn>
one case I can think of is when you pass an invalid configuraiton type, e.g. asking for supported pixel formats from an audio encoder
<jamrial>
elenril: the duration of the last frame is the time it takes you to close the player
<JEEB>
:D
<mkver>
haasn: Yeah, such stuff.
<haasn>
I'm just thinking that the API would be easier to use if it directly returned the list rather than having you pass a pointer to write it to
<haasn>
and also eliminates the possibility of failure, which I don't think should happen under reasonable circumstances - what codecs even need to dynamically allocate this list?
<haasn>
avoids having to cast your output list to (const void **) also
<elenril>
I can imagine that being useful for external library wrappers
<haasn>
I guess
<elenril>
then again it's not a very strong reason if none of the current ones need it
Livio has joined #ffmpeg-devel
<mkver>
You would not not need to cast your output lists; you would just have to use an intermediate variable: void **tmp; AVPixelFormat *list; avcodec_get_supported_config(&tmp); list =tmp;
<mkver>
Allocating the stuff gives us furthermore more freedom in the future. E.g. we may want to use more compact way to store stuff (like only uint64_t channel layouts instead of the complete AVChannelLayout).
<mkver>
Or there might be genuine scenarios in which using static lists would be too cumbersome. External library wrappers might be such a usecase, as elenril has already pointed out.
<Daemon404>
elenril, is that in 8.0?
<elenril>
no, the sixth seal is not even deprecated yet
<elenril>
patches welcome
<elenril>
mwahaha, filtergraph chaining done
<Lynne>
elenril: how does that work?
<elenril>
one filtergraph -> another filtergraph
<Lynne>
so it handles stuff like sink/buffer setup?
<Daemon404>
> Moving to c11 is bad, really bad. This is a dangerous road to follow, don't trust ISO on that matter which is literaly doing planned obsolescence on 5-10 years cycle with computer language feature creeps. C has to be simplified then going towards eternal stability, not the other way around. I suspect some toxic/scammy people got in (or brain washed).
<Daemon404>
gotta love HN
<j-b>
Daemon404: more clever than ISO
deus0ww has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
<jamrial>
just use the -no-iso-shadiness gcc option when compiling
* Sean_McG
laughs
<Marth64>
i saw some ffmpeg 7.0 release article too, so sad it was obviously ai generated
<Sean_McG>
shouldn't expect much more than that these days
<Sean_McG>
I'd love to know what this individual's concerns were with C11
<Marth64>
probably an old timer scarred by an unrelated situation and now biased on it (which i honestly understand sometimes)
<Marth64>
i've had this attitude the past few months on macOS. mostly because there are unremovable daemons that pull news/weather/telemetry/etc I don't want. now I am biased and don't trust the OS at all
<haasn>
oh I see, higher bit depth versions also allow lower bit depth
<jamrial>
haasn: any benefit of choosing 160 over 155? just the not_init_thread_safe flag?
<haasn>
jamrial: and the msvc exclusive configure check
<JEEB>
basically you for x265 manually build 12bit, 10bit and 10bit editions
<jamrial>
ah
<JEEB>
then ADDLIB them together with ar :D
<haasn>
but we can re-introduce those two and go down to an older version, it doesn't really matter
<haasn>
JEEB: yikes
<jamrial>
requiring 155 will let you build ffmpeg 7.1 on ubuntu 20.04 with the system x264, so maybe go for that
<jamrial>
we can bump to 160 or whatever next year once it's EOLd
<haasn>
jamrial: if you bumped instead to v2.0.1 we could drop the `supports_monochrome` check
<haasn>
fair
qwertyttyert has joined #ffmpeg-devel
<haasn>
jamrial: src/libavcodec/libaomenc.c:680:23: error: redefinition of ‘flags’
<haasn>
680 | aom_codec_flags_t flags = 0;
<cone-764>
ffmpeg James Almer master:81b3a82fae0d: avcodec/libaomenc: remove variable redefinition
<jamrial>
haasn: fixed, sorry about that
<elenril>
sigh, now I remember all that HEVClcList insanity
HarshK23 has quit [Quit: Connection closed for inactivity]
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
Poorvagaikar2003 has joined #ffmpeg-devel
<qwertyttyert>
libxvid -flag gmc = "Undefined constant or missing '(' in 'gmc'" as far as I understand, gmc is not possible to use? https://ffmpeg.org/ffmpeg-codecs.html cltr+f gmc
<qwertyttyert>
libxvid -flags gmc
<qwertyttyert>
in windows with xvid directshov gmc can be enabled only by changing the level profile to "Advance Simple"
<qwertyttyert>
directshow
<elenril>
ffmpeg -h full -> look for gmc
<elenril>
also, >encoding xvid in 2024
<elenril>
haasn: cool
<haasn>
elenril: just saw your series, am I correct in understanding that this has nothing to do with the hacky way we currently access enc_ctx options from ffmpeg_filter.c?
<haasn>
because that will need to change for the new API to work properly
<elenril>
all access to enc_ctx is removed from ffmpeg_filter
<haasn>
(so that enc_ctx->strict_std_compliance is valid)
<haasn>
hrm
<haasn>
well, my series adds several new accesses to enc_ctd to ffmpeg_filter
<elenril>
I think it should be straightforward to adapt
<qwertyttyert>
I will not answer.
<haasn>
oh I see, you moved it to ffmpeg_mux_init
Livio has quit [Quit: leaving]
buzz_ has joined #ffmpeg-devel
buzz_ has quit [Changing host]
buzz_ has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
buzz_ has quit [Client Quit]
<qwertyttyert>
"-c:v libxvid -gmc 0 or 1" with this option is enabled. "-c:v libxvid -flags gmc" This is not right?
Krowl has quit [Read error: Connection reset by peer]
<qwertyttyert>
"-c:v libxvid -gmc 0 or 1" - encodes and does not show error
<jamrial>
-flags gmc does not exist
kasper93 has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
<qwertyttyert>
It is not clear from the instructions. Maybe because of the transfer. https://ffmpeg.org/ffmpeg-codecs.html 9.19.1 Options. "-c:v libxvid -flags gray" - ok and others, I haven't checked all of them.
<qwertyttyert>
Maybe because of translation/
<qwertyttyert>
"-c:v libxvid -gmc 0 or 1" is that right?
<qwertyttyert>
gmc - Enable the use of global motion compensation
IndecisiveTurtle has joined #ffmpeg-devel
Poorvagaikar2003 has quit [Ping timeout: 260 seconds]
<qwertyttyert>
what is 0 and what is 1? on, off or ...?
<qwertyttyert>
the instructions on the website need to be corrected
<elenril>
stop spamming, you got your answer already and this is not the place for user questions in the first place
<qwertyttyert>
ffmpeg -h full = -gmc <int> E..V....... use GMC (from 0 to 1) (default 0) . https://ffmpeg.org/ffmpeg-codecs.html 9.19.1 Options. = "-flags gmc"
Sean_McG has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Sean_McG has joined #ffmpeg-devel
<cone-764>
ffmpeg James Almer master:16ba7bdd764f: doc/encoders: remove non-existent flag
<cone-764>
ffmpeg James Almer release/7.0:6c701b5f6cda: doc/encoders: remove non-existent flag
IndecisiveTurtle has quit [Remote host closed the connection]
Raz- has quit [Ping timeout: 260 seconds]
<cone-764>
ffmpeg James Almer master:6f13f5dd5967: doc/encoders: add missing libxvid option
<cone-764>
ffmpeg James Almer release/7.0:d38bf5e08e76: doc/encoders: add missing libxvid option
mkver has joined #ffmpeg-devel
<nevcairiel>
jamrial: fwiw i can reproduce your d3d11 bottleneck quite similarly. guess i'll go poke at it for a bit.
<qwertyttyert>
-_-
qwertyttyert has quit [Quit: Leaving]
hbbs has quit [Quit: bye]
<nevcairiel>
jamrial: well, got it faster then all others. you know what it is? the stupid low-precision timers and sleeps. added timeBeginPeriod in ffmpeg.c main and its now 6400 fps =P
<jamrial>
hah, nice
hbbs has joined #ffmpeg-devel
hbbs has quit [Changing host]
hbbs has joined #ffmpeg-devel
<nevcairiel>
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/dxva2.c;h=6eb66c02e404699ea9d66d304fbf5f53bca0a49f;hb=HEAD#l936 this one in particular, i guess dxva2 doesnt trigger this, and d3d12 uses a different path entirely
<nevcairiel>
well nothing for me to worry about then, video players should be setting that anyway, someone can argue about doing so in ffmpeg cli
<BtbN>
"Starting with Windows 11, if a window-owning process becomes fully occluded, minimized, or otherwise invisible or inaudible to the end user, Windows does not guarantee a higher resolution than the default system resolution."
<BtbN>
hm, so, CLI applications can just get lost anyway
<nevcairiel>
if you dont have a window, maybe they just leave you be
Sean_McG has quit [Ping timeout: 264 seconds]
Marth64 has quit [Ping timeout: 255 seconds]
Marth64 has joined #ffmpeg-devel
<blb>
does gyan join this channel?
<BtbN>
I think I've seen him at least once? But not sure, definitely not a regular.
<blb>
i think his 7.0 "full-shared" build contains the dlls for 6.1 as well. not sure how to tell him.
<BtbN>
Just write an E-Mail?
Marth64 has quit [Ping timeout: 260 seconds]
sudden has quit [Ping timeout: 260 seconds]
<andrewrk>
my 10 years old music player library code wraps ffmpeg and basically reimplements the filter graph
<andrewrk>
oops that was meant to reply to <wbs> I saw one case of someone using ffmpeg, via a javascript api wrapping...
<andrewrk>
anyway I think this time around I'll just depend on ffmpeg directly instead of trying to wrap it too much :)
<andrewrk>
6.5 KLOC of C code, I almost have feature-complete equivalent functionality completed with 900 lines of zig because all the wrapping/encapsulation boilerplate is gone
sudden has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]