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
<boogieboogie>
is it possible to mainline this codec to ffmpeg? because it depends on vendor kernel this is always wellcome in open source projects
<boogieboogie>
not always*
<Lynne>
boogieboogie: I don't think it's possible to add fields to the DRM structs right now
<jkqxz>
In intra-only? That number seems too big to do any sort of inter prediction in the memory bandwidth available.
<Lynne>
sizeof(AVDRMFrameDescriptor) is fixed in the ABI
<jkqxz>
rkmppdec is already in mainline ffmpeg.
<Lynne>
that's why vulkan etc. have a function to allocate their desc structs
<boogieboogie>
Lynne ok jkqxz provided an excellent solution
<boogieboogie>
actually it was my misinterpretation there was no need at all
<Lynne>
yup, just mentioning
<boogieboogie>
and thanks a lot i was really sceptical on changing the drm_desc because it really breaks the api
<Lynne>
keep in mind the crop fields are somewhat sketchy in how we support them
<boogieboogie>
ok let me dig in to the code
<Lynne>
because we're lazy and to support them properly we'd need to update their use everywhere
<boogieboogie>
:)
rvalue has quit [Ping timeout: 264 seconds]
<nevcairiel>
as long as its just lines off the top it should be relatively easy, well, hope its an even number of lines or subsampling makes you cry
<jkqxz>
Looks like it's combined into a single opaque plane anyway, so any subsampling is hidden away.
<boogieboogie>
exactly
<jkqxz>
Which will be fine for the decoder->display use-case, and it sounds like nothing else is going to support this format anyway.
<boogieboogie>
the encoder uses it,
<boogieboogie>
but i think currently it is only afbc capable encoder
<jkqxz>
Does that mean that Vulkan or something can draw to it?
<boogieboogie>
EGL can but dont know vulkan about much because this platform does not have vulkan
<boogieboogie>
but definetely EGL renders
<jkqxz>
Do you know where you put the number when doing EGL import? (Does it look like a crop, or is it some special magic?)
<boogieboogie>
let me double check, but i think EGL just wraps the KMS plane props
<boogieboogie>
seems like EGL does not support offsetting by pixel
<jkqxz>
Yeah, OFFSET there is the start of the plane for if the object contains multiple planes.
<boogieboogie>
yeah thats byte offset that does not help in afbc
<jkqxz>
If you need to carry that then it will need some extra attribute.
<boogieboogie>
yep but may be, GL implmentations always had the decoder in past, they never needed that because gl provider already knew a possible pixel offset and dealt with it with shaders or soemthing, just an idea
<jkqxz>
Maybe magic global state carried the information separately. (The traditional GL way.)
darkapex has quit [Remote host closed the connection]
kurosu has joined #ffmpeg-devel
darkapex has joined #ffmpeg-devel
durandal_1707 has quit [Ping timeout: 276 seconds]
durandal_1707 has joined #ffmpeg-devel
user23 has quit [Remote host closed the connection]
marth64 has quit [Quit: Leaving]
MetaNova has quit [Ping timeout: 260 seconds]
thilo has quit [Ping timeout: 245 seconds]
MetaNova has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
<boogieboogie>
jkqxz Lynne nevcairiel it works like a magic with the crop fields, i will guard the usage of crop fields in the client with DRM PRIME, single plane formats for prevention buffer overshooting or misaligned linesize cases inc ase some other decoder or internals does not handle the crops fields properly, thanks again for your help
boogieboogie has quit [Quit: Client closed]
swamprt5000 has joined #ffmpeg-devel
<swamprt5000>
hi. i am trying to ./configure --enable-tls to get LibreSSL support on iOS
<swamprt5000>
but i get ERROR: libtls not found using pkg-config
<swamprt5000>
wat do?
<swamprt5000>
oof, classic rubber ducky debugging right there
<swamprt5000>
i needed --enable-openssl, iOS renamed it to openssl, even though its actually libressl under the hood
<swamprt5000>
actually i dont even know if thats true. i just tried it with that flag and it worked. maybe its using the openssl i have on macports..... i wont know until its done building
<swamprt5000>
anyway ill shut up now lol.
<aaabbb>
try asking in #ffmpeg
<aaabbb>
since this isn't strictly about developing for ffmpeg, just compiling it
<swamprt5000>
yeah it was using the macports version
<swamprt5000>
is there a way to statically link openssl to each of the ffmpeg shared libs?
kurosu has quit [Quit: Connection closed for inactivity]
<swamprt5000>
aaabbb: based on the stuff i said before your message, i agree, but i think this is ontopic now
navi has quit [Quit: WeeChat 4.0.4]
<swamprt5000>
also for context, for my project, im building ffmpeg and openssl from source. openssl is statically linked to my app's executable, and ffmpeg is in dynamic libraries to comply with LGPL
<swamprt5000>
but for this case it seems like im gonna have to statically link openssl to my app's executable AND each ofc the ffmpeg dynamic libraries
<swamprt5000>
each of*
dellas has quit [Remote host closed the connection]
<compnn>
what kind of project are you doing swamprt5000 ?
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
darkapex has quit [Ping timeout: 256 seconds]
<swamprt5000>
proprietary MPV for ios
<swamprt5000>
is the 4 word pitch
<swamprt5000>
with streaming over SSH
<swamprt5000>
mpv over ssh basically
klaxa_ has joined #ffmpeg-devel
jamrial has quit []
klaxa has quit [Quit: Life's too short.]
klaxa_ is now known as klaxa
<Lynne>
durandal_1707: I don't get it, I optimized c2r more by skipping an entire copy, yet it's slower than r2c
<Lynne>
r2c does a whole preshuffle just to get the coeffs in order before the transform, yet it's somehow less expensive than not doing one at all??
vtorri has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
<durandal_1707>
Lynne: patch? I did just c2r reusing r2c code.
<cone-502>
ffmpeg Marth64 master:34a47b97de9d: libavutil/timecode: fix parameter order in documentation
<durandal_1707>
Lynne: denormals? do not use small numbers when testing
beastd has joined #ffmpeg-devel
mkver has quit [Ping timeout: 256 seconds]
<durandal_1707>
FFmpeg is deprecated
<jamrial>
durandal_1707: make sure to bump minor for it
dellas has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
user23 has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
jamrial has quit []
user23 has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 264 seconds]
vtorri has joined #ffmpeg-devel
cone-502 has quit [Quit: transmission timeout]
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Ping timeout: 260 seconds]
marth64 has joined #ffmpeg-devel
<marth64>
Hypothetically speaking. Could an AVStreamGroup have mixed stream types? I'm thinking about the possibility of Closed Captions being exposed in a stream group alongside the video itself
<marth64>
608/708
<marth64>
I want to invest in subtitle improvements since it's somewhere I can be useful
<BtbN>
hm, do I really just push that memory alignment patch? And then check how red fate turns? That does not feel right :D
<Lynne>
if it breaks you can ninja fix it
<Lynne>
I think it'll be fine
<BtbN>
I know it works on gcc/clang, and breaks on msvc, which is dealt with in the patch
<BtbN>
Or does someone have a briliant idea how to portably implement a preprocessor FFMIN()?
dellas has quit [Remote host closed the connection]
jarthur has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
<jkqxz>
Why is the answer not to fix the incorrect instances of DECLARE_ALIGNED?
<BtbN>
How? By just making the memory not aligned?
<BtbN>
There's over 100 throughouth the entire codebase as well
<jkqxz>
By changing to say the alignment they actually want?
<jkqxz>
Either they don't need 32, in which case don't ask for it.
<BtbN>
They usually do actually want that alignment, but the assembly using it can be turned off
<BtbN>
And right now, if that assembly is turned off, we reduce the alignment guarantee from av_malloc
<jkqxz>
Or they are using some particular assembly which wants 32, in which case that should be relying on the knowledge of what the highest alignment at runtime is.
<BtbN>
That's how it works right now
<BtbN>
av_malloc aligns to the highest possible alignment any activated SIMD might use
<BtbN>
This only gets funny if the SIMD is turned off, but someone still builds ffmpeg with -march=native or -mavx or something, but has the avx assembly turned off
<BtbN>
in which case the malloc guarantee is removed, but the structs allocated by it are still marked to have that alignment
<jkqxz>
And that means that they should be allocated at runtime, not embedded in some other case where they have a compile-time alignment.
<BtbN>
But they are allocated at runtime?!
Wenbin_Chen__ has joined #ffmpeg-devel
<jkqxz>
They are allocated at runtime incorrectly, because the allocator isn't told that they actually want higher alignment because of weird internal properties of the structure.
<BtbN>
well, right now we have over 150 such instances in fact, and ffmpeg builds on non-x86 are all very much in UB territory there
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
<BtbN>
I'm not going to work my way through all those cases, understand them, and then try to fix them
<jkqxz>
The problem case is where the alignment requirement inside the structure isn't propagated because it is allocated in some other way which doesn't have an explicit alignment.
<jkqxz>
If you want to fix the UB then that is the answer, isn't it? Hacking the top-level to do something else is papering over the problem.
<BtbN>
I want ffmpeg to not crash. And I don't have the time or understanding to work through all those hundred or more cases. The potential I break something is much higher than anything else.
<BtbN>
There is also an additional layer to the problem: In the case where it crashes, no element that's directly involved declares any alignment
<BtbN>
it's just cause some struct in some sub-struct has a member declared with an alignment, which gives the compiler the go-ahead to assume the entire struct is
zsoltiv_ has joined #ffmpeg-devel
<jkqxz>
Yes, because embedding the alignment requirement inside the structure and then not using it in the allocation is invalid.
<BtbN>
And I'm not going to go into the h265 decoder (which is where the struct is coming from) and just randomly remove some alignment from its structs
<jkqxz>
And we will just see the same problem again in some other case if those aren't fixed.
<BtbN>
that will crash and burn badly
<BtbN>
And there are legitimately hundreds of such instances. I'm not the one who is going to work through all of those to try and change them.
<BtbN>
So if you aren't okay with the other approach, ffmpeg will keep crashing
<jkqxz>
Um, why would you just remove the alignment? That makes no sense.
<jkqxz>
The aligned elements need to be moved somewhere else which can be allocated with explicit alignment.
<BtbN>
Which would be a MASSIVE change which would affect large parts of the entire codebase
<BtbN>
Cause those structs are used in tons of places
<BtbN>
all the hwaccels, lots of assembly, ...
<jkqxz>
And would also fix the problem properly.
<BtbN>
Yes, sure it would. But I won't do that. I lack the knowledge and time.
<courmisch>
there are non-trivial performance implication to over-alignment. It is not reasonable to do it blindly for everything when this should only be applied to some integer or float arrays
<courmisch>
in other words, your argument cuts both ways
<BtbN>
I wonder if one could just run __alignof__() on the struct on allocation, and be done with it. But even then, the majority of those cases are cause someone embedded one of those structs into the priv data of some filter/codec, which gets allocated for them.
<courmisch>
the alignment of a compound is always a multiple of the alignment of any member of the compound
<courmisch>
of course, that won't help if the member is a void pointer
<courmisch>
but then it needs to be allocated separately anyway in most practical cases
<courmisch>
In practice, I can't see alignof() helping much. For regular structure, you can just as well call malloc() or use max_align_t
<courmisch>
and for arrays that are processed by SIMD, alignof() will give a lower value that really needed
kasper93 has quit [Remote host closed the connection]
kurosu has quit [Quit: Connection closed for inactivity]
Krowl has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Remote host closed the connection]
kasper93 has joined #ffmpeg-devel
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
cosimone has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
marth64 has quit [Quit: Leaving]
Wenbin_Chen_ has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
cosimone has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)]
MrZeus has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
MrZeus_ has joined #ffmpeg-devel
epony has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 252 seconds]
<BtbN>
so, what's the status of C11 support?
<durandal_1707>
deprecated
<Lynne>
last year, no one had any objections to depending on c17 to build whence msvc with support for it got widespread enough
<BtbN>
Cause prior to c11, there was no standard way to get the alignment of stuff
<Lynne>
send a patch? it's been 4 years since msvc got support for c17, should be at least somewhat likelier to get accepted now
<Lynne>
I'd prefer c17, since it's just a bugfix for c11 that everything supports/ed anyway
<Lynne>
(and would make it maybe easier to move to c23 in the future which is amazing)
dellas has quit [Remote host closed the connection]
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
dellas has joined #ffmpeg-devel
<kierank>
17:37:50 <Marth64> Hypothetically speaking. Could an AVStreamGroup have mixed stream types? I'm thinking about the possibility of Closed Captions being exposed in a stream group alongside the video itself
<kierank>
if it's cea608 stream flavour, sure
<kierank>
but not frame attached flavour
mkver has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
ccawley2011 has quit [Read error: Connection reset by peer]
AbleBacon has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]