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 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue has quit [Ping timeout: 264 seconds]
rvalue has joined #ffmpeg-devel
<BtbN>
Why does the macro for the memory alignment not use the SIMD_ALIGN_xx macros?
jarthur has quit [Quit: jarthur]
<BtbN>
hm, I really can't think of any good way to not hardcode the minimum alignment to 32... There just is no portable way to check what the max alignment should be
durandal_1707 has quit [Ping timeout: 276 seconds]
durandal_1707 has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
user23 has joined #ffmpeg-devel
user23 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg-devel
thilo has quit [Ping timeout: 268 seconds]
cone-758 has quit [Quit: transmission timeout]
thilo has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
kurosu has quit [Quit: Connection closed for inactivity]
Marth64[m] has joined #ffmpeg-devel
chainik has quit [Quit: Ping timeout (120 seconds)]
chainik has joined #ffmpeg-devel
Teukka has quit [Read error: Connection reset by peer]
Flat_ has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 245 seconds]
wcpan has quit [Quit: No Ping reply in 180 seconds.]
SuperFashi has quit [Quit: No Ping reply in 180 seconds.]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
wcpan has joined #ffmpeg-devel
SuperFashi has joined #ffmpeg-devel
Flat has quit [Ping timeout: 245 seconds]
Owner__ has joined #ffmpeg-devel
Marth64[m] has quit [Ping timeout: 255 seconds]
Owner__ has quit [Client Quit]
Owner__ has joined #ffmpeg-devel
navi has quit [Quit: WeeChat 4.0.4]
dellas has quit [Remote host closed the connection]
Owner__ is now known as marth64
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
jamrial has quit []
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #ffmpeg-devel
BradleyS has quit [Quit: quit]
BradleyS has joined #ffmpeg-devel
vtorri_ has joined #ffmpeg-devel
<vtorri_>
hello
<vtorri_>
looking at libjxl support in configure, i see :
<vtorri_>
you can see libjxl_cms* files at the bottom of this webpage
otoburb has quit [Ping timeout: 268 seconds]
otoburb has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
<JEEB>
vtorri_: is it advertized in libjxl's pkg-config file when built with it it?
<JEEB>
or can you build it with cms, but then not utilize it by not linking against it?
<JEEB>
because additional libraries etc should be handled with pkg-config so that each time a library updates its linker flags etc you don't have to manually pull that into downstream projectd
<durandal_1707>
index df316d6f07..a7130751b8 100644
<durandal_1707>
@@ -1034,6 +1034,7 @@ static const char *get_avopt_type_name(enum AVOptionType type) case AV_OPT_TYPE_DURATION: return "duration"; case AV_OPT_TYPE_COLOR: return "color"; case AV_OPT_TYPE_CHANNEL_LAYOUT: return "channellayout";
<durandal_1707>
+ case AV_OPT_TYPE_CHLAYOUT: return "channellayout"; case AV_OPT_TYPE_BOOL: return "bool"; case AV_OPT_TYPE_CONST: // fallthrough default:
<JEEB>
there is no anime there. only wind and water.
<durandal_1707>
you cant survive there!
<JEEB>
:D
<durandal_1707>
25km per day? are you looking for aliens?
<JEEB>
just using buses :D
<JEEB>
which means you get somewhere, and then because buses come rarely you walk around
<durandal_1707>
oh, that is shit and sad
<JEEB>
I'm enjoying it, so it's fine :)
<durandal_1707>
stay safe! aliens are hiding everywhere
Krowl has quit [Read error: Connection reset by peer]
<JEEB>
thanks :) so far the only flying saucers rolling around me have the text "US Navy" on them :)
zsoltiv__ has quit [Ping timeout: 264 seconds]
rvalue has quit [Ping timeout: 252 seconds]
navi has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
<Lynne>
durandal_1707: gold plated rolls royce phantom for each line, please
<Lynne>
and no bugattis, they depreciate
zsoltiv has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<durandal_1707>
Lynne: ask Elon, I do not have that many cars.
sudden has quit [Ping timeout: 255 seconds]
<durandal_1707>
Lynne: also I doubt that FFlabs pays more than me
<Lynne>
I'm not involved with fflabs
sudden has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]
Guest76 has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 260 seconds]
Guest76 has quit [Quit: Client closed]
vtorri_ has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 256 seconds]
vtorri_ has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
vtorri_ has quit [Remote host closed the connection]
vtorri_ has joined #ffmpeg-devel
vtorri_ has quit [Remote host closed the connection]
<jamrial>
wonder why some phones use 512x512 tiles when generating heif files. for a 4k photo that's like 48 tiles
<jamrial>
their internal hevc decoders can surely handle images bigger than that, so seems inefficient
<jamrial>
do they fire 48 separate decoders, or send all the tiles to a single decoder in a sequence? the latter sounds like a pain for animated heif
<BBB>
it's presumably for lower-latency (through parallelization) encoding/decoding, in hw also
<BBB>
it makes some sense
<wbs>
how does that compare to having just one bitstream but with tiles the same size (or whatever the corresponding hevc concept is called)?
marth64 has quit [Ping timeout: 264 seconds]
<Lynne>
hevc's loop filter can cross tiles, so it's worse
<Lynne>
hevc's tiling was apparently designed to support cases such as multiple units encoding and dynamically adjusting the tile size based on latency/#units available
<Lynne>
but they did not think of a situation where the output image may be larger than an arbitrary GPU texture size limit, so here we are
<jkqxz>
At least you can turn off the tile boundary filtering in H.265, unlike in AV1 where it is always-on.
dellas has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
if the loopfilter strength is set to 0 on blocks around tile edges via segmentation (or globally), I think you could technically skip it
<jkqxz>
Fair. That does affect a lot more than just the tile boundary, though.
<BBB>
in terms of hw design it doesn't matter much, you have to support cross-tile deblock either way
<BBB>
so if you want to claim "HEVC 120fps4k10" or "AV1 120fps4k10", it's expected it covers that, too
<jkqxz>
For a decoder, yes.
<BBB>
fair, encoder has more freedom
kasper93 has joined #ffmpeg-devel
TheSashmo has joined #ffmpeg-devel
TheSashm_ has quit [Read error: Connection reset by peer]
rvalue has quit [Ping timeout: 245 seconds]
rvalue has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 256 seconds]
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
<durandal_1707>
Lynne: so you are actually paid to NOT work on TX ?
rvalue has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 268 seconds]
kasper93 has joined #ffmpeg-devel
<Lynne>
it was still the holidays until a few days ago
AbleBacon has joined #ffmpeg-devel
kasper93_ has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 260 seconds]
<durandal_1707>
Lynne: it is holidays, its pop time, its sleep time, its eat time, its whatever time ....
qeed_ has joined #ffmpeg-devel
qeed has quit [Remote host closed the connection]
<Lynne>
alright, I'll finish c2r tonight, tomorrow I'll do c-t
<Lynne>
if you answer me this question: which emacs theme do you use?
<durandal_1707>
lol
<durandal_1707>
i'm not emacs user
kasper93_ has quit [Ping timeout: 240 seconds]
<durandal_1707>
last time i run emacs was when i was first time FreeBSD user
kasper93 has joined #ffmpeg-devel
kasper93 has quit [Remote host closed the connection]
<durandal_1707>
i'm now FFT and x86 SIMD expert, but I'm extremely lazy to write SIMD x86 code
<Lynne>
I could earn a spot on the front page of hackernews if I wrote the details about lavc's fft, simd and how it performs, but I'm too lazy (and I blackhole'd it in /etc/hosts months ago because reading it is of no value)
<durandal_1707>
ROTFL
<durandal_1707>
but FFT matters for non-power of 2 sizes too, thats why librempeg beats ffmpeg FFT implementation whenever ffmpeg uses naive(_small) algorithm
<durandal_1707>
and that is big set of numbers
dellas has joined #ffmpeg-devel
<durandal_1707>
i wonder how to add support for odd RDFT sizes
markh has quit [Ping timeout: 268 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]
markh has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
boogieboogie has joined #ffmpeg-devel
<boogieboogie>
I need some consultancy before i send a PR to ffmpeg-devel. I think AVDRMFrameDescriptor is needs to be updated to represent x & y pixel offset, but this requires an api change since hwcontext_drm.h is exported to the system
<boogieboogie>
The actual reason is that AFBC frames require certain offsetting after they are decompressed by the hardware DKMS renderer. And currently there is no way to represent those x,y offsets in FFMpeg
zsoltiv has quit [Remote host closed the connection]
kurosu has quit [Quit: Connection closed for inactivity]
<BtbN>
adding fields at the end is fine
<BtbN>
As long as not doing anything with them doesn't suddenly break stuff
<boogieboogie>
ok, thanks i will send the patch
<jkqxz>
x and y offset of what?
<boogieboogie>
the SRC_X and SRC_Y offsets in the KMS DRM Plane
<boogieboogie>
so when i provide an AFBC frame, which a compressed single plane, the hardware actually puts 3 - 4 pixels of y offset and the compresses, to render it
<boogieboogie>
the plane which renders that AFBC frame must offset the picture by n pixels.
<boogieboogie>
But currently there is no way to transfer this information in AVDRMFrameDescriptor
<boogieboogie>
i think uint32_t x, uint32_t y members AVDRMFrameDescriptor would be appropriate
<boogieboogie>
so the n pixel offset is a decoder hardware behaviour, and since AFBC format is a 16x16 tiled format, you can not present this offset by, AVDRMLayerDescriptor.offset
<jkqxz>
That sounds very strange. Those values are meant to be an offset in the surface so that you scanout without using the whole surface.
<jkqxz>
I can see that FBC might force alignment restrictions, but where would a small offset be coming from?
<boogieboogie>
yes, because of some alignment requirement does not fit the tilessize / ysize, and they start from an offset
<boogieboogie>
this is my theory, but i have a working test setup for this
<boogieboogie>
so i tested it
<jkqxz>
Hmm. Shouldn't this be carried by the modifier? The consumer would see that the modifier indicates some particular mode and applies the offset for that mode.
<jkqxz>
Storing it as an ad-hoc property like this does not seem like a good idea.
<boogieboogie>
whats even worse, some hardware decoders might have n pixel offset on some frames (key frame) and 0 offset in intra frames, so it is frame basis
<boogieboogie>
so not, modifier only stores the generic structure, compression tiles etc, but the offset is dynamic
<boogieboogie>
took me 6 months to figure it out :)
<jkqxz>
Does anything else consume this?
<boogieboogie>
Kodi currently if my PR is accepted
<jkqxz>
If it's used to feed to the surface cropping ability of KMS, maybe you could use the crop fields?
<jkqxz>
(Assuming there isn't some other cropping going on there.)
<boogieboogie>
but how can i know the offset?
<jkqxz>
I mean consumer of those DRM objects, not program using it.
<jkqxz>
Your decoder is giving you the offset, isn't it?
<boogieboogie>
yes
<boogieboogie>
i dont get this consumer notation sorry
<boogieboogie>
didnt*
<jkqxz>
You say that you are going to give the DRM object to KMS for scanout. Is there anything else which you might give it to? Can Vulkan import it, say?
<boogieboogie>
no directly to KMS
<jkqxz>
If KMS is the only consumer then this seems like exactly what the crop fields do.
<jkqxz>
Since you are putting the values into the KMS properties used for cropping.
<boogieboogie>
but how am i going to know how much to crop on each frame, how will i see transfer this information with a DRMPrime descriptor?
<boogieboogie>
with nyanmisaka fro jellyfin developers
<boogieboogie>
from*
<jkqxz>
Hmm, y only. The surface is made slightly larger than normal and magic stuff is stored in the top few lines?
<boogieboogie>
size_t crop_top;
<boogieboogie>
size_t crop_bottom;
<boogieboogie>
size_t crop_left;
<boogieboogie>
size_t crop_right;
<boogieboogie>
my theory it is because of alignment requirement or whatever hantro chip thinks is the best
<jkqxz>
The meaning does seem like "intended data starts N lines from the top", which is exactly what crop_top means.
<boogieboogie>
exactly, i think this will come to v4l2_request and v4l2_m2m codecs as well, there will be one day that this weird chip will be linux mainlined, and then they will spit funky offsets
<jkqxz>
Does v4l2 have any API exposing that information?
<jkqxz>
rkmpp is implmented in userspace so it can easily give you it, but v4l2 is fixed kernel API.
<boogieboogie>
yes but v4l2 only supports old chips which do not supprot AFBC thats one reason. The new AV1 chip is mainlined but there is no proper support for the kernel, so i think the issue was not visible yet
<jkqxz>
Is this on 3588 or something else?
<boogieboogie>
tested with 3588 but shold work for all rockchips with vendor kernel
Lypheo has joined #ffmpeg-devel
Lypheo has quit [Client Quit]
Lypheo has joined #ffmpeg-devel
<boogieboogie>
just like the mainline ffmpeg it relies on the the mpp_service which is only available in the vendor kernel, but with much way better capabilites, it can transcode up 1000fps 4k last time i remember with 3588