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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
vipyne_ has quit [Quit: leaving]
vipyne_ has joined #ffmpeg-devel
vipyne_ has quit [Client Quit]
thilo_ has quit [Ping timeout: 260 seconds]
thilo_ has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
System_Error has quit [Ping timeout: 260 seconds]
cone-482 has joined #ffmpeg-devel
<cone-482> ffmpeg Zhao Zhili master:0ba9e8d0d492: aarch64/vvc: Add w_avg
<cone-482> ffmpeg Zhao Zhili master:5988a2729bc2: aarch64/vvc: Add dmvr
<cone-482> ffmpeg Zhao Zhili master:bcd65ebd8fcd: aarch64/vvc: Add dmvr_hv
jamrial has quit []
System_Error has joined #ffmpeg-devel
paulk-bis has joined #ffmpeg-devel
paulk has quit [Read error: Connection reset by peer]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 265 seconds]
arch1t3cht9 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 248 seconds]
arch1t3cht9 is now known as arch1t3cht
vipyne has quit [Quit: Leaving.]
<cone-482> ffmpeg Zhao Zhili master:240c16bbc6ef: avcodec/vvc: Don't use large array on stack
av500 has joined #ffmpeg-devel
DauntlessOne has quit [Remote host closed the connection]
IndecisiveTurtle has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
tufei_ has joined #ffmpeg-devel
tufei__ has quit [Ping timeout: 260 seconds]
av500 has quit [Ping timeout: 265 seconds]
cone-482 has quit [Quit: transmission timeout]
arbitercoin has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Workl2 has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 265 seconds]
Workl has quit [Ping timeout: 252 seconds]
ngaullier has joined #ffmpeg-devel
mark4o has joined #ffmpeg-devel
Workl2 has quit [Read error: Connection reset by peer]
markh has quit [Ping timeout: 264 seconds]
mark4o is now known as markh
av500 has joined #ffmpeg-devel
cone-487 has joined #ffmpeg-devel
<cone-487> ffmpeg Anton Khirnov master:041d992060ce: lavu/class: improve AVClass doxy
<cone-487> ffmpeg Anton Khirnov master:0d09645cfe88: lavu/opt: combine option type size+name into a single descriptor
<cone-487> ffmpeg Anton Khirnov master:3785b27b7622: lavu/opt: consolidate common prologue for av_opt_set*()
<cone-487> ffmpeg Anton Khirnov master:262e6f8430a8: lavfi/avfilter: export AVFilter initialization state
<cone-487> ffmpeg Anton Khirnov master:0548ab2e4257: lavu/log,opt: detect setting non-runtime options post-init
Krowl has joined #ffmpeg-devel
lexano has quit [Ping timeout: 252 seconds]
psykose has joined #ffmpeg-devel
psykose has quit [Remote host closed the connection]
derpydoo has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
arbitercoin has quit [Read error: Connection reset by peer]
pnm has joined #ffmpeg-devel
pnm has quit [Client Quit]
derpydoo has quit [Quit: derpydoo]
Krowl has quit [Read error: Connection reset by peer]
<elenril> $ git grep '\<FILTER_QUERY_FUNC\>'|wc -l -> 82
<elenril> $ git grep '\<FILTER_QUERY_FUNC2\>'|wc -l -> 98
<elenril> getting there
cone-487 has quit [Quit: transmission timeout]
ngaullier has quit [Ping timeout: 260 seconds]
jamrial has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
<jamrial> elenril: there seems to be a hard lock going on in fate-hevc-mv-position under tsan with slice threading
<jamrial> also a bunch of races in other hevc tests, for that matter
<elenril> wpp is racy
<elenril> it is known
<jamrial> yeah, those are old, but the hard lock in mv-position is new
<jamrial> there are also lots of old races in frame threading with h264 and mpeg4
<elenril> how can you tell it's a deadlock
<elenril> tsan doesn't complain at all here
<jamrial> because it got killed after several hours of runtime doing nothing
<elenril> hours?
<elenril> configure says --target-exec='timeout -s KILL 5m'
<jamrial> ubitux mentioned those runs have a timeout of about 3 hours before a process is killed
<jamrial> oh nevermind, 5m for the tsan ones
<elenril> ok, can see it now
<nevcairiel> the 5m timeout is actually new on the latest run, i guess ubitux added it
<jamrial> yeah
<jamrial> because it was hardlocking every other fate run, hence the couple weeks with no reports
<jamrial> with no tsan
<elenril> sigh, this garbage should never have been accepted
<jamrial> which one?
<elenril> wpp
<elenril> "ff_thread_report_progress2"
System_Error has quit [Ping timeout: 260 seconds]
* elenril facepalms
<elenril> this code starting to look even worse than I though
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<BBB> I didn't realize h264 frame-mt had races left
<BBB> with fate-samples?
<jamrial> yeah, those have been there for a long time
<elenril> BBB: those are new ones
<BBB> new races? or new samples?
<elenril> new races
<BBB> ok
<BBB> I was pretty sure I had gone through h264 frame-mt many (10?) years ago and fixed them all
<elenril> our design makes it easy to add races
<elenril> and people don't understand threading
<elenril> or just don't care as long as it doesn't break their sample
<mkver> jamrial: IIRC they have been added by michaelni when he changed the handling of grey/unavailable frames.
<jamrial> yeah, just saw that
<jamrial> last year. funny, it felt like longer
<mkver> No. h264 mt was race-free for a long time (in the absence of errors?).
Krowl has quit [Read error: Connection reset by peer]
blb has quit [Ping timeout: 260 seconds]
blb has joined #ffmpeg-devel
<mkver> BBB: Can you explain 7f05c5cea04112471d8147487aa3b44141922d09 to me? With frame-threading we will call this function (usually) only once per frame, otherwise multiple times. Why does this even work?
<BBB> I don't recall :(
<Daemon404> you dont even sound sure in the commit message :D
<kurosu> Poor Ronald, caught before the statute of limitations occurred :-/
Krowl has joined #ffmpeg-devel
microlappy has joined #ffmpeg-devel
microlappy has quit [Client Quit]
s55 has quit [Remote host closed the connection]
s55 has joined #ffmpeg-devel
deus0ww has quit [Ping timeout: 248 seconds]
deus0ww has joined #ffmpeg-devel
witchymary has quit [Ping timeout: 244 seconds]
<BtbN> How does the get_buffer.video callback of a filter inlink work? It's toggled between ff_null_get_video_buffer and ff_default_get_video_buffer, based on passthrough mode in scale_cuda.
<BtbN> Now the problem is, with this new cropping thing, it's not known at init time if a frame can actually be passed through
<BtbN> So do I now just have to always use ff_default_get_video_buffer? Where is that even called, I can't make sense of all the indirection in video.c on who actually ends up calling that function to allocate a buffer.
<BtbN> The preceeding filter?
<jamrial> each filter has to allocate its own buffer, unless it's a metadata only filter, afaik
___nick___ has quit [Ping timeout: 244 seconds]
<BtbN> But what's AVFilterPad::get_buffer.video/audio for then?
<jamrial> BtbN: if by new cropping thing you mean the code in ffmpeg_filter.c that autoinserts the crop filter, for hwaccel formats it will just set the AVFrame fields accordingly
<BtbN> I'm talking about making scale_cuda actually evaluate the crop fields
<jamrial> in case you want a filter to not use ff_default_get_video_buffer, it will use whatever function you set in get_buffer.video/audio
<BtbN> It has an optimization where it skips most of all processing if it determines the input to already be in the output format
<jamrial> assuming said filter calls ff_get_video_buffer()
<jamrial> it's a bit roundabout, yeah
<BtbN> And if it detects that case in init, it set a passthrough flag, and if that flag is set AVFilterPad::get_buffer.video of the input pad is changed from ff_null_get_video_buffer to ff_default_get_video_buffer
<BBB> to be fair, if it stayed in, it presumably fixed the race. otherwise wouldn't we have reverted it?
<BBB> back then, I had a pretty solid understanding of how frame-mt worked in the relevant codecs (h264, vp89)
<BtbN> But I assume that is filter_frame is called, the buffer is already allocated? So unsetting passthrough is too late at that point?
<BtbN> *if
<BtbN> jamrial: scale_cuda never calls anything except av_hwframe_get_buffer(). Is defining AVFilterPad::get_buffer.video just redundant then?
<BtbN> I can't immediately tell from the code in video.c if it's called from the preceeding filter or something
<BtbN> Like, I see that ff_get_video_buffer can call link->dstpad->get_buffer.video can call ff_null_get_video_buffer which calls ff_get_video_buffer, and I'm confused
___nick___ has joined #ffmpeg-devel
<BtbN> reading the code, it really seems like if you call ff_get_buffer in a filter, it'll go to the dstpad on the next filter in the chain, and call the get_buffer function it defines
beastd has joined #ffmpeg-devel
cone-462 has joined #ffmpeg-devel
<cone-462> ffmpeg Tomas Härdin master:649ac17efd96: lavf/mxfdec: Speed up mxf_edit_unit_absolute_offset()
<cone-462> ffmpeg Tomas Härdin master:e3fa469a55a0: lavf/mxfdec: Speed up klv_read_packet()
<cone-462> ffmpeg Tomas Härdin master:25d605d0808b: lavf/mxfdec: Remove a call to avio_tell() in klv_read_packet()
___nick___ has quit [Read error: Connection reset by peer]
___nick___ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
beastd has quit [Ping timeout: 265 seconds]
witchymary has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
<elenril> BtbN: AFAIK the get_buffer infrastructure for filtering is only harlf there
<BtbN> well, but it exists, and it seems like a bit of a chicken/egg problem here
<elenril> sure, it does exist, but it does not really do what it was intended to do
<elenril> so trying to understand it can be very confusing
<BtbN> The problem is, I don't know ahead of time if scale_cuda will need to do cropping
<BtbN> The cropping also behaves very weird, so I'm not sure if the patch is implemented correctly
<BtbN> As in, crop=100:100,scale_cuda results in a video in the input resolution, but with a cropped 100x100 section scaled back up to the input res
<jamrial> that'd be ffmpeg.c ensuring every output frame has the same dimensions as the first frame, right?
<BtbN> no, that's just what scale_cuda does if you don't specify the target size
<BtbN> so I feel like the patch is missing to update the target size if unspecified but cropping is happening
<BtbN> Just a plain sw -vf crop=100:100 results in a 100x100 video, so I'd expect crop=100:100,scale_cuda to result in the same
<BtbN> Yeah w and h are just "iw" and "ih" by default
<BtbN> But that's a difficult problem to solve, since at the time that's parsed, it again has no clue if cropping is happening
<BtbN> or are you just expected to always do crop=A:B,scale_filter=A:B?
ccawley2011 has quit [Ping timeout: 248 seconds]
<jamrial> BtbN: the crop filter actually crops the video if the pixfmt is software (it changes the offsets of the data pointers)
<jamrial> it's only for hw formats that it sets the crop fields in avframe
<jamrial> and leaves the data pointers alone
<jamrial> so the behavior is not the same
<BtbN> yes, but I'd still expect the behaviour to be the same as a user
<jamrial> BtbN: maybe vf_crop could set the outlink dimensions for hw formats too, then?
<jamrial> scale_cuda should make something with the cropping information if so
<BtbN> hm, wouldn't that mess with things? Not sure what and where reads those
<BtbN> But it sounds like a possible solution
<jamrial> those are used by the alloc buffer calls, mainly (and exported by buffersink av_buffersink_get_{w,h}). so as long as every hw aware filter is actually aware of it and acts accordingly, it could be fine
vipyne has quit [Quit: Leaving.]
vipyne has joined #ffmpeg-devel
vipyne has quit [Client Quit]
<cone-462> ffmpeg Michael Niedermayer master:417b163c0055: avcodec/ffv1enc: 2Pass mode is not possible with golomb coding
<cone-462> ffmpeg Michael Niedermayer master:7d514655bfa4: avcodec/ffv1enc: Slice combination is unsupported
<cone-462> ffmpeg Michael Niedermayer master:7151081e3342: avcodec/ffv1: Store and reuse sx/sy
IndecisiveTurtle has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
___nick___ has quit [Remote host closed the connection]
ccawley2011 has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
Warcop has quit [Remote host closed the connection]
mkver has quit [Ping timeout: 252 seconds]
deus0ww has quit [Ping timeout: 265 seconds]
deus0ww has joined #ffmpeg-devel
cone-462 has quit [Quit: transmission timeout]
mkver has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
ccawley2011 has quit [Read error: Connection reset by peer]
vipyne has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
Warcop has joined #ffmpeg-devel
Warcop has quit [Remote host closed the connection]
mkver has quit [Ping timeout: 276 seconds]