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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<cone-723>
ffmpeg Michael Niedermayer master:b4d165c68fe7: doc: replace http/git by https urls
<cone-723>
ffmpeg Michael Niedermayer master:98c178837088: avcodec/ffv1enc: replace 3 double precision log2() by 1 single precision log2()
<cone-723>
ffmpeg Michael Niedermayer master:4aeaee1f4e9d: avcodec/ffv1enc: replace the remaining log2() by magic
<cone-723>
ffmpeg Michael Niedermayer master:d5ad860cd8e3: tests/checkasm/checkasm.c: Assert that aligned_w/h do not overflow
<cone-978>
ffmpeg Andreas Rheinhardt master:5e947cc32075: postproc/postprocess: Remove unused b02
<cone-978>
ffmpeg Andreas Rheinhardt master:2b9b4dde9335: avcodec/aac/aacdec_lpd: Make ff_aac_lpd_mode_tab static
<cone-978>
ffmpeg Andreas Rheinhardt master:132a55fd7c54: postproc/postprocess_template: Use immediate instead of memory load
<cone-978>
ffmpeg Andreas Rheinhardt master:f5007a07d8cd: avcodec/aac/aacdec_lpd: Remove dead code
<cone-978>
ffmpeg Andreas Rheinhardt master:664aef361a38: avcodec/aactab: Remove unused arrays
<cone-978>
ffmpeg Andreas Rheinhardt master:2e962fb08032: avcodec/vulkan_video: Remove unused ff_vk_h26[45]_profile_to_av()
<cone-978>
ffmpeg Andreas Rheinhardt master:3693acb85523: avcodec/x86/h26x/h265dsp: Remove unused functions
<cone-978>
ffmpeg Andreas Rheinhardt master:265e0d3e249a: avfilter/palette: Remove unused ff_srgb_u8_to_linear_int()
<cone-978>
ffmpeg Andreas Rheinhardt master:1479c2ec2774: doc/{in,out}devs: Remove documentation for removed devices
<cone-978>
ffmpeg Andreas Rheinhardt master:52d766e5c271: avcodec/vdpau: Only include mpegvideodec.h when used
<cone-978>
ffmpeg Andreas Rheinhardt master:1722f08acf80: avutil/Makefile: Only include half2float, float2half when needed
Guest49 has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
Guest49 has quit [Quit: Client closed]
wyatt8740 has quit [Ping timeout: 272 seconds]
wyatt8740 has joined #ffmpeg-devel
greyash_dave has quit [Quit: Client closed]
mkver has quit [Ping timeout: 248 seconds]
Anthony_ZO has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
averne_ has joined #ffmpeg-devel
averne has quit [Ping timeout: 248 seconds]
averne_ is now known as averne
cone-978 has quit [Quit: transmission timeout]
ngaullier has joined #ffmpeg-devel
usagi_mimi has joined #ffmpeg-devel
martinr2 has quit [Ping timeout: 268 seconds]
usagi_mimi has quit [Quit: WeeChat 4.5.2]
usagi_mimi has joined #ffmpeg-devel
usagi_mimi has quit [Client Quit]
Anthony_ZO has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
<haasn>
ramiro: pushed an update to nuke pack.type completely
<haasn>
instead you now have a sequence of pack/unpack + convert
<haasn>
which should not make a difference in the most cases except when it can be then merged with another conversion afterwards
<ramiro>
haasn: I'm having a look, but now I get some failures. I think get_packed_type() should check for > instead of >=. bgr8 for example should return u8, not u16.
<haasn>
oh, yes
sm2n has quit [Remote host closed the connection]
OctopusET has quit [Remote host closed the connection]
OctopusET has joined #ffmpeg-devel
sm2n has joined #ffmpeg-devel
<ramiro>
haasn: thanks, it's much cleaner now! I also removed all my convert/pack/unpack optimizations, since they gave at best 2 fewer instructions, and the amount of code to take care of that was substantial
<ramiro>
haasn: btw, bgra<>argb (which is basically just a shuffle) has half the speed from my asmjit code. when linesize==width it basically just does one call. I can check in assembly for linesize==width to optimize this (also it should check if dither was used, because in that case having x and y is important). but it could be helpful if op_pass_run() could populate this kind of helpful information in exec.
<ramiro>
*half the speed from _legacy to_ my asmjit code...
<ramiro>
the idea is to first compile the function normally, as if dithering was used and exec.[xy] mattered between runs, then have chain->entry actually be a dispatcher that checks linesize==width at runtime
<ramiro>
this is pretty much using nuscale to better select the optimized assembly already existing in swscale :P. instead of a fragile list of srcfmt->dstfmt, it would check if the operations list is load(packed, u8)+swizzle(3012)+store(packed, u8)
<ramiro>
which then is also almost the same for ayuv<>vuya, without having to specify it in a list
<haasn>
ramiro: I'm not sure I follow
<haasn>
but yeah basically that was the plan initially, back in swscale3 I had op table entries for specific conversions like that as well
Anthony_ZO has quit [Ping timeout: 245 seconds]
<haasn>
because the nature of the SwsOps framework makes it kinda impossible to keep mixed data in a single vector
<haasn>
I suppose in theory we could compile some of those ops down to read { u32 } + swap_bytes + write { u32 }
<haasn>
we could generalize swap_bytes to some arbitrary byte order shuffle
<haasn>
and use it as a fast path for in-place swizzling of packed data like that
<haasn>
basically outsourcing the logic from the backend to the optimizer
<haasn>
where it IMO belongs
<haasn>
can you explain what extra metadata you want and what you think the dispatch wrapper should be doing / not doing?
<haasn>
good point about the x/y coordinates not being needed though
<haasn>
ramiro: how about this: add a SwsOpChain.needed_info containing a bitmask of exec state that must be populated (x coord, y coord, N input planes, N output planes, etc)
<haasn>
and the dispatch code will pick a suitable dispatch wrapper from a table of variants?
<haasn>
we can automate the generation of dispatch wrappers fairly easily using an av_always_inline function that takes the needed_info mask from a const parameter that is then instantiated at different values using macros
<haasn>
alternatively it may be nice if the backend can provide the dispatch wrapper itself, that way we can use e.g. AVX2 code to bump all four pointers at once
odrling has quit [Read error: Connection reset by peer]
nitroxis has quit [Read error: Connection reset by peer]
odrling_ has joined #ffmpeg-devel
rossy_ has joined #ffmpeg-devel
Flat has quit [Ping timeout: 260 seconds]
mindfreeze_ has joined #ffmpeg-devel
ocrete has joined #ffmpeg-devel
ocrete has quit [Quit: Ping timeout (120 seconds)]
nitroxis_ has joined #ffmpeg-devel
rom1v_ has joined #ffmpeg-devel
SuperFashi_ has joined #ffmpeg-devel
thilo_ has joined #ffmpeg-devel
thilo_ has joined #ffmpeg-devel
Wallboy_ has joined #ffmpeg-devel
r0dn3y has joined #ffmpeg-devel
steven-netint_ has joined #ffmpeg-devel
SuperFashi has quit [Quit: No Ping reply in 180 seconds.]
Wallboy has quit [Ping timeout: 272 seconds]
rossy has quit [Read error: Connection reset by peer]
steven-netint has quit [Ping timeout: 268 seconds]
mindfreeze has quit [Read error: Connection reset by peer]
rom1v has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
thilo has quit [Ping timeout: 268 seconds]
k777 has quit [Read error: Connection reset by peer]
steven-netint_ is now known as steven-netint
fflogger has quit [Ping timeout: 248 seconds]
Rodn3y has quit [Ping timeout: 248 seconds]
mindfreeze_ is now known as mindfreeze
odrling_ is now known as odrling
rossy_ is now known as rossy
k777 has joined #ffmpeg-devel
Flat has joined #ffmpeg-devel
Flat has quit [Ping timeout: 268 seconds]
Flat has joined #ffmpeg-devel
blb has quit [Ping timeout: 272 seconds]
blb has joined #ffmpeg-devel
abdu has joined #ffmpeg-devel
pross has quit [Ping timeout: 252 seconds]
System_Error has quit [Remote host closed the connection]
<ramiro>
haasn: sorry, my last few messages were indeed confusing :). even for me, reading them back now a couple of hours later.
<ramiro>
haasn: I don't think we need to worry about the "read { u32 } + swap_bytes + write { u32 }" case right now.
<ramiro>
In general as we implement more code in the backends we will see more patterns that could be moved to the general optimizer. but for now it's good that it stays simple like it is
<haasn>
true
<haasn>
I will write a dedicated "byte shuffle solver" in the x86 backend I think, for handling any case of read {packed}, swizzle, write {packed}
<haasn>
which can all be turned into a read + pshufb + write sequence
<ramiro>
the one case of needed info I can think of right now is linesize==width. It *could* be calculated in the backend, but it would probably be useful to all backends. so it could be calculated in the C code, and wouldn't need to be reimplemented in asm again.
<haasn>
I am not sure what exactly you mean by this case; what needs to be handled separately about it?
<ramiro>
because if linesize==width, this means there is no padding. and if I don't need to dither, where x and y matter, this means that I can turn the entire function into one single loop. I calculate len = (x_end - x) * (y_end - y), and loop 'len' times.
<cone-201>
ffmpeg Niklas Haas master:46762c8b82b8: avfilter/vf_libplacebo: don't explode on zero FPS information
<ramiro>
it could also help to have a padding[4] field (which is just linesize - width). this way I do the horizontal loop until x_end, then add padding[i] to each plane, and loop vertically.
<haasn>
I tested that and it was slower for me
<haasn>
ramiro: well, one complication arises when we will start having subsampled inputs
<haasn>
because the luma and chroma lines can increment at different rates
<haasn>
that's why I wrote the code to recalculate the line on every iter
<ramiro>
haasn: yes, indeed. subsampled formats will bring in a whole bunch of more complexity.
<haasn>
in general, I think doing this code once a line is not a huge deal, in practice lines are going to be very large
<haasn>
same deal with the linesize=width case, is that really going to be so relevant normally?
<ramiro>
haasn: I can guarantee it is big deal :)
<haasn>
hmm
<haasn>
I mean we if we allow choosing the dispatch wrapper based on the type of conversion being performed we can just make a special case for subsampled inputs when they become relevant
<haasn>
here's an idea
<haasn>
what if we make the load/store functions responsible for bumping pointers
<ramiro>
in the argb<>rgba conversion, the simple fact of having to break out of the kernel at each line made the entire conversion take twice as long (and I had already implemented horizontal loop in asm).
<haasn>
they already load the address, they might as well increment and write it back
<haasn>
they also can hard code the correct size
<ramiro>
in aarch64 neon, we can post-increment the read/write pointers in the read/write instructions themselves, so this is already what I'm doing. but in my case I don't need to write it back to exec.
<haasn>
yeah, then that seems like it will definitely be the way to go
<haasn>
completely unrelated to everything, but what's a typical size of an audio frame?
<haasn>
(in number of samples)
<haasn>
Something like 1k ~= 20 ms?
<haasn>
since that would roughly match the duration of a video frame
minimal has joined #ffmpeg-devel
k777_ has quit [Quit: Leaving]
k777__ has quit [Quit: Leaving]
k777 has quit [Quit: Leaving]
k777 has joined #ffmpeg-devel
abdu65 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
abdu has quit [Ping timeout: 240 seconds]
abdu36 has joined #ffmpeg-devel
abdu65 has quit [Ping timeout: 240 seconds]
abdu11 has joined #ffmpeg-devel
abdu36 has quit [Ping timeout: 240 seconds]
martinr1 has joined #ffmpeg-devel
martinr1 has quit [Ping timeout: 248 seconds]
martinr1 has joined #ffmpeg-devel
steven-netint has quit [Changing host]
steven-netint has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 245 seconds]
martinr1 has quit [Ping timeout: 244 seconds]
fflogger has joined #ffmpeg-devel
mkver has quit [Ping timeout: 244 seconds]
<haasn>
also why do we have two completely separate EBU R128 implementations? f_ebur128.c and ebur128.c
mkver has joined #ffmpeg-devel
<Lynne>
one measures loudness, one applies loudness
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
martinr1 has joined #ffmpeg-devel
martinr1 has quit [Ping timeout: 268 seconds]
<haasn>
that.. doesn't really justify anything
<haasn>
maybe we should rip out f_ebur128 in favor of making it just a wrapper around ebur128.h
<haasn>
though I did find the code in the former easier to follow than the latter :)
cone-201 has quit [Quit: transmission timeout]
<kylophone>
@haasn I think I had something to do with that.
<kylophone>
That was the suggestion at the time, but the f_ebur128 author objected.
<kylophone>
Could be something to revisit now, though.
IndecisiveTurtle has quit [Ping timeout: 244 seconds]
NormieLeader has joined #ffmpeg-devel
<NormieLeader>
haasn: do not listen to fake news
<NormieLeader>
f_ebur128.c have video output support
<NormieLeader>
see librempeg solution, i completely rewrote loudnorm filter and removed ebur128.h
<NormieLeader>
and i not going to fight with windmills any more...
<haasn>
I saw that, but the video output is just printing the same data that it could get from ebur128.h
<NormieLeader>
video output have graphs
odrling has quit [Remote host closed the connection]
<NormieLeader>
also its native implementation, unlike copy of old ebur128.h
odrling has joined #ffmpeg-devel
<kierank>
NormieLeader: wb!!!
<kierank>
I've missed you
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 244 seconds]
martinr1 has joined #ffmpeg-devel
<ramiro>
haasn: ok, I ended up adding padding information to exec, like this: "exec->(in/out)_padding[i] = (in/out)_base->linesize[i] - (in/out)_linesizes[i];" where "(in/out)_linesizes[i]" was obtained with av_image_fill_linesizes().
rvalue- is now known as rvalue
martinr1 has quit [Ping timeout: 265 seconds]
<ramiro>
this way I can do the vertical loop correctly in asm. then I can also check if all padding is zero, which means I can do just the inner loop as if len = (width*height), and just 1 "line"
<ramiro>
also, swscale doesn't check if linesize==width, it checks if srcstride==dststride. it will then happily convert the entire padding :)
<NormieLeader>
in single memcpy? that should crash, no?