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>
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."
<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]
<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.
<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
<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]
<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/AV1https://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?
<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
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