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
englishm has quit [Changing host]
englishm has joined #ffmpeg-devel
Livio has quit [Ping timeout: 256 seconds]
<andrewrk> it would be nice if all those `#include "bsf.h"` could be replaced by `#include <avcodec/bsf.h>` instead, or if bsf.h was moved into bsf/
<andrewrk> as it stands those source files need a special flag in the build script
<mkver> andrewrk: What is so wrong with this special flag in the build script?
<andrewrk> it's annoying to add in my fork with a different build system
<andrewrk> before all the files were treated the same, now they're not
<mkver> Making life easier for forks with custom build systems is not really our goal
<andrewrk> that is completely fair, however, it's a fundamental complexity/nonuniformity that exists in the upstream build script as well
<andrewrk> changing it would be better for both projects
llyyr has quit [Changing host]
llyyr has joined #ffmpeg-devel
<andrewrk> I we can agree that most experienced C programmers gravitate towards fewer -I switches, and making all the #include sites uniform
<andrewrk> it's fine, I'll just slap a -Ilibavcodec in there and rely on there being no conflicting header files
<andrewrk> https://github.com/andrewrk/ffmpeg zig package updated to 7.0
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
lexano has quit [Ping timeout: 272 seconds]
mkver has quit [Ping timeout: 256 seconds]
arch1t3cht4 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 264 seconds]
arch1t3cht4 is now known as arch1t3cht
pengvado has quit [Changing host]
pengvado has joined #ffmpeg-devel
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
lemourin has joined #ffmpeg-devel
arch1t3cht7 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 272 seconds]
arch1t3cht7 is now known as arch1t3cht
Poorvagaikar2003 has quit [Ping timeout: 268 seconds]
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> Lynne: here is a visualization of the data passed to AddRow in fingerprint_calculator.cpp: https://i.imgur.com/rPGUEKk.png
<andrewrk> fpcalc (top) gets a score of 0.96 for this song, my implementation (bottom) gets a score of 0.40
<andrewrk> has the loss been introduced by now? I can't tell
<Lynne> andrewrk: did you find the [1] coeff issue?
deus0ww has quit [Ping timeout: 268 seconds]
<andrewrk> why do you think there is a [1] coeff issue?
<andrewrk> both implementations are using the same ffmpeg version, using the same API, equivalently
<Lynne> because of that text you posted?
deus0ww has joined #ffmpeg-devel
<andrewrk> sorry, I'm not following along, which message are you referring to?
jamrial has quit []
<Lynne> from yesterday, where all coefficients were matching except the second one
<andrewrk> it seems like that is explained by the difference in input (https://i.imgur.com/f9iqfds.png), no?
<Lynne> no, it isn't, everything else mostly matches
AbleBacon has quit [Read error: Connection reset by peer]
<andrewrk> ok but if the input is the same, the function is the same, the ffmpeg version is the same...
<andrewrk> is your suggestion to switch to using av_tx API?
<Lynne> if you can, it would rule out the wrapper having an issue
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 268 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
<andrewrk> ok, on it
<andrewrk> Lynne: it looks like the code in libchromaprint after the call to av_rdft_calc is maybe dealing with that? https://github.com/acoustid/chromaprint/blob/aa67c95b9e486884a6d3ee8b0c91207d8c2b0551/src/fft_lib_avfft.cpp#L37-L44
<andrewrk> I should probably try to understand what this logic is doing before switching the API call
<andrewrk> so you do you call av_tx_init with len=0 to initialize the context?
<andrewrk> hmm av_tx_init is marked cold
<andrewrk> why does it take a function pointer?
<Lynne> you call init with a len, mode, flags and direction and you get back a context and a function pointer
<Lynne> you call the function pointer with the context to perform the transform
<andrewrk> oh I see, it's a double pointer
<andrewrk> heh there's an implementation of function multiversioning here
<andrewrk> it would be really handy if it loaded the scale value from the pointer during init and did not keep that pointer around, but I suppose that's "codelet implementation defined"
<Lynne> it doesn't keep the pointer around
<Lynne> *the scale data
<Lynne> it immediately bakes it into the tables during init
<Lynne> the API was designed this way to eliminate a second deref which would otherwise happen
<Lynne> makes more sense for 2D transforms where you may have thousands of blocks per frame you have to transform
<andrewrk> perfect
<andrewrk> so it looks like av_rdft_init is setting stride to sizeof(AVComplexFloat) but I think I actually want sizeof(float) ?
<andrewrk> could that be perhaps the cause of my bad data
<andrewrk> hmm I think I understand. libchromaprint is passing floats to DFT_R2C, inplace. so the input stride is 4, output stride is 8. that's why it's iterating in pairs over the result
<andrewrk> "For forward transforms (R2C), stride must be the spacing between two samples in bytes."
<andrewrk> s->stride = (trans == DFT_C2R) ? sizeof(float) : sizeof(AVComplexFloat);
<andrewrk> seems like a bug
<Lynne> yeah, that's wrong
<andrewrk> that's in 7.0 too
<Lynne> it's fine, the stride parameter isn't respected thoughy
<Lynne> *though
<andrewrk> oh
<Lynne> this is just for a potential change for when it starts to get respected
qeed__ has joined #ffmpeg-devel
qeed_ has quit [Ping timeout: 268 seconds]
<andrewrk> Lynne: I'm getting the same results as before with av_tx_init. https://codeberg.org/andrewrk/player/src/commit/f3ac3a341c882b8bd0eb00ff50b3889792f9bd2b/src/root.zig#L177
<andrewrk> I'll post a visualization in a moment
<andrewrk> what is the best way to visualize this output?
<Lynne> a single frame, printf the first 16 coeffs, and find out why they don't match would be my way
<andrewrk> aren't they pairs of points though, like frequency and time or something
Poorvagaikar2003 has joined #ffmpeg-devel
<Lynne> they are, but at the end of the day, you want all of them to match
Gramner has quit [Ping timeout: 255 seconds]
<Lynne> andrewrk: looks like it matches, apart from the scale
<Lynne> you should bump the scale parameter until the first DC value matches exactly
Gramner has joined #ffmpeg-devel
<andrewrk> ok
kurosu has joined #ffmpeg-devel
<andrewrk> Lynne: I can't get a better error margin than 0.00000047683716 for the first value
<Lynne> that's good enough for the algorithm, does every coefficient match now?
<andrewrk> yes
<andrewrk> within a small tolerance
<andrewrk> hmm if I scroll down to the bottom though it starts to get out of sync
<andrewrk> neither the waveform input nor the RDFT output looks aligned for the very last window
<andrewrk> oh no
<Lynne> off by one?
<andrewrk> it works now
<andrewrk> that was the only problem
<Lynne> what, 444hz? it's just the regular pitch of the berlin philharmonic orchestra
<andrewrk> lol
<andrewrk> it works fine with 1.0 scale
cone-795 has joined #ffmpeg-devel
<cone-795> ffmpeg Oneric master:0fc975c0d307: avcodec/ass,webvttdec: implement more portable curly brace escapes
<cone-795> ffmpeg Oneric master:7b8b4cdd9654: avcodec/webvttdec: honour bidi marks
<cone-795> ffmpeg Oneric master:baa64fa4e664: avcodec/ass,webvttdec: fix handling of backslashes
<cone-795> ffmpeg Oneric master:57c545090d75: avocdec/ass: simplify linebreaks
<cone-795> ffmpeg Antoine SOULIER master:ad3fcfd0f285: avcodec/liblc3dec: fix typo in macro name, fix compilation
<cone-795> ffmpeg Antoine SOULIER master:6de00dc5f119: avcodec/liblc3dec: fix extradata size
<cone-795> ffmpeg Antoine SOULIER master:4865ea48cc4e: avcodec/liblc3dec: retrieve duration of the last packet from the demuxer
mkver has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 256 seconds]
kekePower has quit [Quit: The Lounge - https://thelounge.chat]
kekePower has joined #ffmpeg-devel
<Lynne> elenril: I implemented a clever interleaving algorithm for avtransport, I'll look into porting it to lavf once it gets a lot of testing
<Lynne> it avoids needing to wait for packets to always be present from each stream by considering the duration and pts of each packet, so if a stream is guaranteed to not be starved, its skipped
<Lynne> it also does all its tuning based on a single bandwidth value, which also serves as a limit
<Lynne> also, it does segmentation and schedules them based on an MTU, but that's not really applicable for lavf (except for maybe mpegts and rtp)
cone-795 has quit [Ping timeout: 260 seconds]
j-b has quit [Ping timeout: 255 seconds]
j-b has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
<elenril> Lynne: at least in cli we cannot assume the timestamps are reliable
<elenril> what we really need is heartbeat packets
Livio has joined #ffmpeg-devel
<Lynne> I wouldn't call timestamps going back in time reliable, but at least in normal use, it should be more optimal
Livio has quit [Ping timeout: 260 seconds]
___nick___ has quit [Ping timeout: 272 seconds]
<elenril> durations are often unreliable
<elenril> because lavf insists on making up something when they are not known
<elenril> I intend to get rid of that, but it takes time
Livio has joined #ffmpeg-devel
<Lynne> if timestamps are bad, durations will also be bad
<Lynne> the way I treat that is I just get them out asap (since that's how I treat control signals and metadata, which have no timestamps)
Poorvagaikar2003 has quit [Ping timeout: 255 seconds]
deus0ww has quit [Ping timeout: 268 seconds]
deus0ww has joined #ffmpeg-devel
<Lynne> jkqxz: nvidia are saying that our saved_order_hints aren't correct - https://0x0.st/XiBs.png
j-b has quit [Changing host]
j-b has joined #ffmpeg-devel
<mkver> haasn: Have you looked at this hevc issue? It has now also been reported on track #10951.
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
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<haasn> mkver: sorry, I forgot about it
<haasn> thanks for the reminder
Raz- has joined #ffmpeg-devel
Raz- has quit [Ping timeout: 256 seconds]
<haasn> this should fix the deeper logic bug as well, by setting out->needs_fg to 0 in any case
<haasn> and also simplifies the check a bit
<mkver> So we allocate a frame for film grain even though we know in advance that it won't be used for film grain?
cone-708 has joined #ffmpeg-devel
<cone-708> ffmpeg Stefano Sabatini master:1cb1f29a0423: lavf/lrc: fix comments in headers
<haasn> mkver: ff_h274_film_grain_params_supported returning false is an edge case due only to our lack of support
<haasn> ideally it wouldn't exist
<mkver> And?
<haasn> and if somebody finds such a sample they should post it to the bug tracker
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<haasn> iirc there's no way to defer the allocation to hevc_frame_end right?
<mkver> The frame in the sample has passed this ff_h274_film_grain_params_supported check and yet av_film_grain_params_select says that there is no usable frame grain.
<mkver> Why?
<haasn> because ff_h274_film_grain_params_supported failed to check all newly added constraints
<haasn> it's either this patch or patching film_grain_params_supported
<haasn> but fgp may be NULL in the case of av1 metadata with wildly incompatible parameters, which is definitely not a hypothetical case
<mkver> How complicated would it be to check this in advance?
<haasn> basically duplicating av_film_grain_params_select() but on the raw SEI struct instead of the parsed AVFilmGrainParams
<haasn> maybe we can attach the side data earlier and use that function instead?
<mkver> Can't we just use av_film_grain_params_select instead of ff_h274_film_grain_params_supported?
<haasn> indeed, we could
<haasn> seems the side data comes from set_side_data() which is just after this logic
<haasn> some rearranging will make it work
<mkver> Wait, this has the downside of exposing us to changes in this function in newer lavu versions.
<mkver> I.e. newer functions may return supported even though lavc may not be able to actually handle this stuff. This needs to be tested as well.
<mkver> Anyway, we can move applying film grain to the outputting thread: https://github.com/mkver/FFmpeg/commit/a993fad0c147324ff2f3b7b7b7b281432dc794d1
<haasn> ff_h274_film_grain_params_supported() will continue guarding us against incompatible lavu versions
<haasn> (no analog is needed for aom film grain at the moment because all possible paths are already handled)
<mkver> Send that to the ML.
<jkqxz> Lynne: They are the one on the right?
<jkqxz> That's obviously incorrect because they are expecting values in SavedOrderHints[i][0], which should not be set. I think they must have missed that SavedOrderHints is indexed by [i][j + LAST_FRAME].
<elenril> Lynne: yes, but durations can be bad even with good timestamps
<elenril> lavf is funky like that
<jkqxz> The ones in the middle with all-zeroes don't look right either. You can see that those entries are order hint 3, so they should have previous values in there.
<jkqxz> (Maybe they have done some sort of filtering based on what frames are actually used, which the vulkan specification does not tell them to do?)
<jkqxz> ((But would probably be harmless if noone looks at those fields anyway.))
novaphoenix has quit [Quit: i quit]
<Lynne> elenril: the current fallback for that case is it calculates the duration as the time it would take to transmit the packet at the current bandwidth value
novaphoenix has joined #ffmpeg-devel
<Lynne> that way there's still some order and packets are less likely to clog up a limited throughput
<Lynne> jkqxz: unfortunately they depend on the values in saved order hints for anything that isn't a keyframe
Venemo has quit [Ping timeout: 240 seconds]
<jkqxz> What is the stream for that? Given the reference structure it would be very easy to work out what SavedOrderHints should contain.
Venemo has joined #ffmpeg-devel
<Lynne> they haven't said, but them being them, it's probably the most vanilla av1 stream you can find
<jkqxz> Oh, I see the problem.
<jkqxz> ref_order_hint is indexed by the slot number.
<jkqxz> SavedOrderHints[i] is indexed by the funny name.
<Lynne> any way of breaking our implementation to use the same way, just for testing?
<Lynne> if I'm going to tell them their whole implementation is wrong, it would be nice to have a conformation
<jkqxz> Get the stream and work out manually what the SavedOrderHints are?
<jkqxz> The reference decoder unfortunately hides that information in a confusing way.
<jkqxz> Oh, hmm. It looks like the ref_order_hint variable name might be misleadingly not what the standard defines that variable as.
StevenLiu has quit [Quit: Leaving]
<Lynne> should I CC you in the conversation?
<jkqxz> That is trying to set OrderHints as in <https://0x0.st/XiB6.png> from the AV1 specification, but it is missing that the index refFrame is i + LAST_FRAME (1).
<jkqxz> Sure.
deus0ww has quit [Ping timeout: 256 seconds]
deus0ww has joined #ffmpeg-devel
<Lynne> enjoy hellthread #7
<haasn> elenril: mkver: how do you feel about adding FF_CODEC_CAP_RANGE_MPEG and FF_CODEC_CAP_RANGE_JPEG to internally mark the range which a codec accepts, for ff_default_get_supported_config() ?
<haasn> to avoid having to overload get_supported_config() for practically every single codec
<mkver> This should not be via a CODEC_CAP, but rather via a dedicated bitfield of its own (the bit is taken from the internal codec caps of course). See how i did AVFilter.formats in lavfi/internal.h
Livio has quit [Ping timeout: 260 seconds]
<jkqxz> Lynne: I answered. There is something confusing going on in lavc, though. The final default case in set_frame_refs is meant to choose the earliest order hint, but it clearly doesn't in that example.
<Lynne> if you send me a diff, I can test
mkver has quit [Ping timeout: 255 seconds]
Sean_McG has joined #ffmpeg-devel
<jkqxz> The frame_refs_short_signaling example in fate always has the full list, because it doesn't set frame_refs_short_signaling unless there is enough frames for it to use.
Raz- has joined #ffmpeg-devel
<jkqxz> I don't think there is a bug in lavc. The way that the selection process is completely different in the standard and in the reference code is not helpful.
cone-708 has quit [Quit: transmission timeout]
qeed_ has joined #ffmpeg-devel
qeed__ has quit [Ping timeout: 264 seconds]
dykai has joined #ffmpeg-devel
dykai has quit [Client Quit]
Livio has joined #ffmpeg-devel
andream has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
<andream> Hi, I'm pinging about my patch 7c123da1-cb8c-4b35-96c2-7569cacd75e6@polimi.it
<andream> Could someone review it?
mkver has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
cone-456 has joined #ffmpeg-devel
<cone-456> ffmpeg Andreas Rheinhardt master:0dbf45120aa0: avcodec/libdav1d: Don't cast const away unnecessarily
Krowl has joined #ffmpeg-devel
pmozil has joined #ffmpeg-devel
<jkqxz> Lynne: SavedOrderHints is meant to be updated after the frame has completed decode, but CBS has run that step already when Vulkan reads it.
tufei has joined #ffmpeg-devel
<BtbN> it took one whole day until someone asked to have 4.4 back.
<Sean_McG> eheh
<jkqxz> Lynne: Do you know how that code deals with invisible frames?
<jkqxz> We need to extract SavedOrderHints at the start of the frame.
deus0ww has quit [Ping timeout: 252 seconds]
pmozil has quit [Remote host closed the connection]
<jkqxz> The problem is that it uses a reference frame in a slot which refresh_frame_flags overwrites, so SavedOrderHints for that slot is old.
<jkqxz> I'm a bit unclear how this works at all, because wouldn't all the other reference properties have been overwritten as well?
deus0ww has joined #ffmpeg-devel
<jkqxz> Oh, I see. It grabs the raw frame header out of CBS to use for other parameters there.
<jkqxz> Yeah, this setup doesn't really work. Invisible frames are always going to get you because you can't extract the state in between the two frames in the packet.
mkver has quit [Ping timeout: 240 seconds]
Livio has quit [Read error: Connection reset by peer]
Livio has joined #ffmpeg-devel
<jkqxz> Lynne: Something like this? <https://0x0.st/XiSm.patch> (Not tested at all, vulkan part may not build.)
<jkqxz> That is computing the information in av1dec as we see each frame; trying to do it on cbs side is doomed because of multiple frames in a packet.
AbleBacon has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
darkapex has quit [Ping timeout: 268 seconds]
Krowl has quit [Read error: Connection reset by peer]
iive has joined #ffmpeg-devel
darkapex has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
qwertyttyert has joined #ffmpeg-devel
Raz- has quit [Ping timeout: 260 seconds]
cone-456 has quit [Quit: transmission timeout]
andream has quit [Remote host closed the connection]
kasper93 has quit [Ping timeout: 268 seconds]
<qwertyttyert> I read it https://trac.ffmpeg.org/wiki/Encode/AV1 https://ffmpeg.org/ffmpeg-codecs.html#libaom_002dav1 What's wrong with it again Raspberry Pi OS (Debian), Raspberry Pi 2B armhf (4x900MHz) and libaom-av1 ? I can't do encode using 4 processor cores, only one is used. Оne processor core is not enough, it does not cope. Maybe and four won't be enough. Has anyone checked if libaom-av1 can be configured to be used in
<qwertyttyert> Raspberry Pi OS witch 4 processor cores for encoding? With Mint (AMD), libaom-av1 uses all the cores in the processor for encoding. I couldn't make it encode using four cores from a processor. With some options -tiles raspberry freezes. Htop does not show that 4 processor cores are being used before freezes. X264 — ok use 4 cores.
<qwertyttyert> With some options -tiles raspberry freezes - the numbers are different.
<andrewrk> is af_afftdn a decent audio filter to look at as a template for creating a new audio filter, from a modern ffmpeg idiomatic code quality perspective?
<qwertyttyert> VVC, EVC, and LCEVC (Oh My!) When in FFmpeg? https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=150729 H.266 or VVC (MPEG-I Part 3) - uuuuuuuuuuuuuuMPEG-I
mkver has quit [Ping timeout: 260 seconds]
<Lynne> jkqxz: it helps a little bit, I think there's a single non-keyframe being output'd, but still the same as before on nvidia
<jkqxz> Are you able to compare parameters with the nvidia sample?
System_Error has quit [Ping timeout: 260 seconds]
<Lynne> not really, can't build it, but I can test with the sample they sent
<jkqxz> I missed a copy step.
<jkqxz> Now checked av1dec values using vaapi as the hwaccel (from logging in that patch).
<jkqxz> You could try <https://0x0.st/XiQD.patch> on nvidia, change the if (1) to if (0) on saved order hints to get the behaviour not matching the specification.
<Lynne> jkqxz: no difference (I did fix int -> uint8_t casting)
System_Error has joined #ffmpeg-devel
<Lynne> alright, give me a sec
<Lynne> no difference, with 1 or 0 too
Marth64 has quit [Ping timeout: 260 seconds]
<qwertyttyert> I'm not talking about video quality, I don't really care much about video quality, size - yes. I am satisfied with the video in MPEG-I format with a resolution of 720x405 3096 kbit/s. I need to compress, view it and delete. I compress using x264 qp26 256x144 15 frames.
<qwertyttyert> MPEG-I Video
<jkqxz> Lynne: Last try: <https://0x0.st/XiQh.patch>. (It was using the current picture rather than the reference picture so all the hints were the same.)
<jkqxz> VAAPI output about the order hints does match what they said they wanted now, as far as I can tell.
MisterMinister has quit [Ping timeout: 246 seconds]
<qwertyttyert> And the load on the processor so that the processor is enough for encoding.
<Lynne> jkqxz: no difference :/
<jkqxz> What is the exact behaviour?
<Lynne> for the foreman sample, all frames output by the decoder show the very first frame
wcpan has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
wcpan has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<jkqxz> That sounds like it must be something else. These values would affect motion field projection, so you've get a mess but the decode should complete.
<qwertyttyert> libxevd
<qwertyttyert> for windows
<qwertyttyert> libxevd and libxeve
<qwertyttyert> host windows guest linux
<Lynne> jkqxz: according to nvidia, that's the only difference in the commands send to the GPU
<another|> qwertyttyert: you're in the wrong channel
<qwertyttyert> no
jamrial has joined #ffmpeg-devel
<sdc> is there anything special I need to do to return a value from x86 asm? besides move the value to eax and using RET.
<Lynne> no, that will do, unless you want to return a float
AbleBacon has quit [Read error: Connection reset by peer]
<qwertyttyert> ffmpeg 7.0, in linux not 7.0, I didn't know that there is MPEG-5 in 7.0
qwertyttyert has quit [Quit: Leaving]
Livio has quit [Ping timeout: 260 seconds]
kasper93 has joined #ffmpeg-devel
jamrial has quit []
jamrial has joined #ffmpeg-devel
<Lynne> shit, av_fopen_utf8 is gone
<Lynne> this early?