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
<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]