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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
MrZeus_ has quit [Ping timeout: 268 seconds]
mkver has quit [Ping timeout: 255 seconds]
deus0ww has quit [Ping timeout: 255 seconds]
deus0ww has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
navi has quit [Quit: WeeChat 4.0.4]
thilo has quit [Ping timeout: 245 seconds]
thilo has joined #ffmpeg-devel
bilboed has quit [Ping timeout: 255 seconds]
bilboed has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
jamrial has quit []
<compn>
"ricecapades"
<compn>
everyone hates j2k :D
kurosu has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
durandal_1707 has quit [Ping timeout: 255 seconds]
durandal_1707 has joined #ffmpeg-devel
<compn>
ffv1 to the future!
<rix>
does ffmpeg have parser for EMDF metadata format as defined in ETSI TS 102 366, Annex H?
kurosu has quit [Quit: Connection closed for inactivity]
qeed has quit [Quit: Leaving]
<Lynne>
durandal_1707: had to fix some exptab stuff
<Lynne>
how the hell is unpckhps **slower** than shufps on alder lake?
<Lynne>
intel... are you alright over there?
AbleBacon has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
mkver has quit [Ping timeout: 276 seconds]
<jdek>
courmisch: should be fine regardless right, I mean the main distinction is asm vs intrinsics imo. gas should be widely supported, and worst case not difficult to adapt to rv non-isa spec in any case?
<JEEB>
rix: nope
Krowl has quit [Read error: Connection reset by peer]
<rix>
ok
<courmisch>
jdek: problem is that gas accepts stuff that spec and LLVM don't
<jdek>
is there a flag we can give gas to force it to conform? would make it easier to specify rv non-isa
<jdek>
or we just macro the gas specific stuff to produce errors?
<courmisch>
not that I'm aware of, and that sounds difficult
<durandal_1707>
Lynne: please send patches to ML
<jdek>
courmisch: will update the doc then to specify rv non-isa with a note saying it can be used as a subset of gas
<Lynne>
the syntax is one thing, but support for macros is another
<jdek>
usually the only way to write it is with editor macros or lots of copy/paste too
___nick___ has quit [Client Quit]
<Lynne>
at the very least, they're needed to remove ABI boilerplate on each function
<jdek>
Lynne: non-isa supports macros as well no?
<Lynne>
they should, gas syntax is pretty portable
<Lynne>
even on riscv, macros help, since you can just template out a function that does both floats and doubles
___nick___ has joined #ffmpeg-devel
<j-b>
kierank: no problem. AI is a big topic.
<j-b>
kierank: it's less problematic than crypto
<elenril>
AI is a meme
<elenril>
or rather "AI"
<j-b>
AI is not.
<j-b>
genAI is doing actual things
<j-b>
Whisper is an actual thing
<elenril>
most of these things are of marginal actual utility
<elenril>
it's a vastly overrated bubble
<j-b>
Whisper can do pretty good STT
<j-b>
libopus uses a NN to improve the quality
<j-b>
segment-anything is quite effective compared to OpenCV
<courmisch>
Lynne: not really; there's always one thing that changes, like the pointer arithmetic.
<courmisch>
you end up with ifs and elses and it's illegible
<Lynne>
you can macro the function suffixes for the type and a number for the pointer offset, is there anything more needed?
<courmisch>
typically it's not a pointer offset, it's a shift amount that will change which Zba instructions you use in any given place
<courmisch>
worst case, you have a shift of 3 for float and 4 for double. You end up using SH3ADD for float, and having multiple instructions for double...
<courmisch>
and so you start adding ifs and elses and it makes a mess
<Lynne>
can't you make that macro an argument to the function macro?
<courmisch>
you may or may not need an additional register in the double case
<courmisch>
and you may or may not want to improve the instruction scheduling
<Lynne>
gas supports optional arguments
<courmisch>
it gets really messy
<Lynne>
for macros
<courmisch>
there's no generally good way to express "SH4ADD"
<courmisch>
you could do two SH3ADDs but that would be bad scheduling
<courmisch>
or one SLLI and one ADD, but then you need to clobber an additional register
<durandal_1707>
Lynne: ignore those pointless irc talks, and finish tx support
<Lynne>
ah, well, rip
Krowl has joined #ffmpeg-devel
<Lynne>
you could still just macro out the loop of the function and paste it in 2 boilerplates
<Lynne>
or the processing part of it
<courmisch>
in the extreme you can always reduce it to .if single SINGLE CODE .else DOUBLE CODE .endif
<courmisch>
so you "can" do it, but IME, it always ends up making a low-legibility mess
<courmisch>
so far, macros have been used for variants of the same function at a given size, not really for varying element sizes
<durandal_1707>
Lynne: the removal flag i did is bad as it actually disables that asm function, do you have fix for this scalling issue?
cone-865 has joined #ffmpeg-devel
<cone-865>
ffmpeg Anton Khirnov master:c6483f1c2ac4: lavfi/buffersink: avoid leaking peeked_frame on uninit
<cone-865>
ffmpeg Anton Khirnov master:1d536e028372: fftools/ffmpeg_filter: track input/output index in {Input,Output}FilterPriv
<cone-865>
ffmpeg Anton Khirnov master:99d2fa38ad62: fftools/ffmpeg: make sure FrameData is writable when we modify it
<Lynne>
durandal_1707: err, which flag?
<durandal_1707>
preshuffle?
<durandal_1707>
in rdft_init
<Lynne>
no, that flag has to be there, since all asm-call functions are preshuffle-only
<Lynne>
if you remove it, nothing will be found, and it'll just go back to C code for the RDFT
<durandal_1707>
Lynne: yes i found that
<durandal_1707>
but afir output with that patch is out of [-1.f, 1.f]
<cone-865>
ffmpeg Paul B Mahol master:d793af982ec2: avfilter/asrc_flite: switch to activate
<cone-865>
ffmpeg Paul B Mahol master:ebfd3912e980: avfilter/asrc_flite: use streaming function
<durandal_1707>
Lynne: working on c2r already? when to expect this big RDFT boost to be pushed to FFmpeg?
<durandal_1707>
elenril: small packets are still doing big overhead within ffmpeg.c
dellas has joined #ffmpeg-devel
<elenril>
sorry, can't fix everything at once
<elenril>
especially while fighting certain people on ML
<durandal_1707>
elenril: NG? i wonder why is NG still there, should be banned 10y ago
<elenril>
disagreeing is not a bannable offence
<durandal_1707>
good luck
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
durandal_1707: soon, sooner if you can review it when I post it
<elenril>
durandal_1707: nobody finds these random ramblings funny
<elenril>
stop them
cone-865 has quit [Quit: transmission timeout]
MrZeus has joined #ffmpeg-devel
<elenril>
okay, I'm just going to go ahead and push it
<elenril>
he's not suggesting any reasonable alternative
navi has joined #ffmpeg-devel
<Lynne>
which one?
<elenril>
the CLI threading set
<Lynne>
sure, sounds good
<Lynne>
we can fix any bugs and issues as we go
<elenril>
it's not even a bug
<elenril>
I considered putting it to a TC vote, but there's not even anything to vote on
<JEEB>
should I ping the avctx side data set?
<JEEB>
I'd like to possibly move onto general framework level stuff like codec id specific general logic which would then remove the possible requirement of each AVCodec implementing the side data stuff
<courmisch>
what? NG is not able to reverse MD5?
<courmisch>
I am soooo disappoint
Krowl has quit [Read error: Connection reset by peer]
NuoMi has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<BBB>
the ML is toxic again today...
<BBB>
ok, so, CC members
<BBB>
we have ops on IRC. do we have admin control over the ML?
<courmisch>
also the sky is blue today
<elenril>
I think you should start with warnings
<BBB>
I wasn't going to ban yet
<courmisch>
</sarcasm>
<BBB>
but if I'm going to threaten to ban, I need a tool to execute said bans when it comes down to it
<elenril>
but yes, a good point
<elenril>
michaelni: did you update [ct]c@ aliases yet?
<elenril>
assuming it's you who manages them
<courmisch>
sooo, how do I review patches sent as attachment?
<JEEB>
I look if patchwork has shown it
<elenril>
clearly your email client sucks if it cannot do that
<jamrial>
courmisch: paste the attachment as quote to your reply
<courmisch>
jamrial: that's illegible, without the >
<jamrial>
that's what i meant with "as quote"
<jamrial>
thunderbird lets you paste text prefixing every line with >, for example
<courmisch>
ENOSYS
<jamrial>
a text editor should let you do that, too
<psykose>
ez to prefix all lines in vim
<jamrial>
you're working around you client not inlining Content-Type: text/x-patch, so be creative :p
<courmisch>
psykose: I like vim to edit my source code, not my mails
<Lynne>
has anyone looked at how well our avx code runs on rosetta?
<Lynne>
jsut curious
<jamrial>
nice background
<courmisch>
elenril: I am told that reading/writing white on black is bad for your eyes
<elenril>
lies
<courmisch>
I need those eyes for another 4 decades or so, so I prefer to be careful with them
<Lynne>
with such low contrast, I don't think there's a difference between black on white or vice versa
<elenril>
(the window is dimmed because it doesn't have focus)
<Gramner>
Lynne: afaik rosetta doesn't support avx
ccawley2011 has quit [Read error: Connection reset by peer]
<Lynne>
ah, right, patent reasons
Kei_N has quit [Ping timeout: 264 seconds]
<Gramner>
no idea if that's the reason. wouldn't some the latest sse extensions be patented too?
Kei_N has joined #ffmpeg-devel
<Gramner>
and they're not old enough for patents to have expired
<Lynne>
maybe it's just apple writing what fits the hardware rather than fully emulating
<Lynne>
after all valgrind contains avx emulation code and fedora/rhel still packages it
<Gramner>
they could've just noticed that most software works without avx support so why bother. it's just intended as a good enough stopgap measure, not a 100% perfect emulator
<wbs>
and emulating avx might end up slower than emulating sse or scalar code
<courmisch>
isn't SSE much more translatable in NEON than AVX?
<jkqxz>
Shouldn't the alignment setting for av_malloc() and friends be derived at runtime from the CPU, not at build time?
<courmisch>
allocations have to be aligned enough for the typdef
<jkqxz>
The doxy says: "Allocate a memory block with alignment suitable for all memory accesses (including vectors if available on the CPU)."
<courmisch>
the problem is that av_malloc() has no alignment parameter
<jkqxz>
It doens't say that it should be set by what FFmpeg was configured with.
<courmisch>
FFmpeg can't override the C compiler requirement
<courmisch>
if a type has an alignment of 32, FFmpeg has to allocate it on 32 bytes, even if it's completely pointless for the given CPU
<jkqxz>
Where is there a case where the compiler would have a type which requires an alignment greater than that which could be supported by the CPU it's going to run on?
<jkqxz>
I see that could theoretically be a problem if it used the low bytes of pointers to do naughty things, but for any sensible case that's not a thing.
<jkqxz>
*low bits of pointers
<courmisch>
whenever a member of the struct states an alignment like that
<courmisch>
it's all in the ML already
<jkqxz>
Stating that alignment is an error if you then call malloc() in a situation which doesn't give you that alignment.
<Lynne>
alloc_frame has an alignment field, though
<courmisch>
yes the correct fix is to not use malloc() for structure with an explicit alignment
<Gramner>
is overaligning things even a big deal? e.g. would there be any meaningful downsides to just always allocating some buffer with a 32-byte alignment if an avx implementation exists instead of using complicated logic for figuring out which alignment to use?
<courmisch>
but good luck fixing that accross the code base
<nevcairiel>
if the cpu doesnt do avx, its not going to have any functions available that require 32 byte alignment, but the overhead of aligning to 16 or 32 is extremely minimal, and doing it at runtime is orthogonal to the patch anyway, because its already 32 in most cases, except on some special ricer platforms with wrong build flags :P
<jkqxz>
(Though you are allowed to fix it up manually, as e.g. libc does to use vectors for memcpy() even though memcpy has no alignment constraints.)
<Lynne>
othweise av_malloc's alignment is just a randomly picked value from close to 20 years ago deemed to be good enough
<courmisch>
Gramner: heap performance can drop dramatically
NuoMi has quit [Quit: Leaving]
<courmisch>
Gramner: on shitty OS that I don't personally care about, but still
<nevcairiel>
obviously the trac issue is from a gentoo user, and gentoos configuration of ffmpeg is bizarre at best, most users wont even be impacted by the patch at all. If you want to propose runtime changes of the alignment, independent patch :)
<jkqxz>
Overalignment costs a lot of overhead for things which do many small allocations.
<elenril>
haasn: I see you're not building with --assert-level=2
<haasn>
shouldn't that be the default when compiling without optimizations?
<elenril>
no
<haasn>
I suppose ffmpeg build system disagrees
AbleBacon has joined #ffmpeg-devel
<elenril>
watches are probably pelcome
mkver has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
<haasn>
switch to meson /s
<haasn>
(I actually hate meson)
<nevcairiel>
meson was so promising, but it turned into a build-system :P
<ePirat>
let's write the successor to meson where we finally do everything right! </s>
<ePirat>
can't be that hard!
<Lynne>
I kinda like meson, specifically because of subprojects
<Lynne>
being able to compile a huge project with tens of dependencies all at once and install it is awesome for automation and not relying on packagers to have git master of all projects you're interested in
<ePirat>
I like meson the most from the available popular options, it's not perfect by any means, neither are the other options though…
<Lynne>
yeah, trying to get automatically generated headers to be installed for avtransport (spec -> headers+parsing) turned into a mess
<Lynne>
it does work, but it's a hack and requires parsing the spec document twice
Krowl has joined #ffmpeg-devel
<elenril>
our build system could be split and generalized into something decent
<ePirat>
would required someone to understand it fully in the first place
<elenril>
it's not particularly complicated
<ePirat>
elenril, I would appreciate a review of my Makefile Doxygen fix patch then
<ePirat>
as far as I can tell its ok but I am not really sure how to be absolutely sure about it
<elenril>
you can be absolutely sure that you cannot be absolutely sure about anything
<jamrial>
ok yoda
<elenril>
i was just trying to shortcircuit all the robots here
<psykose>
i hear paul fizzling
derpydoo has joined #ffmpeg-devel
<BBB>
when I read ok yoda it sounded to me like ok boomer
<elenril>
also, I was more trying to channel my inner gödel
dellas has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 264 seconds]
<j-b>
Good morning my favorite trolls
<elenril>
we live in dramatic times
<j-b>
Are you talking about middle-east, Ukraine, Taiwan, Venezuela-Guyana or just Mexican gangs?
<elenril>
the ML mainly, but some of these as well
* j-b
has not seen the ML since lunch
<elenril>
good for you?
<j-b>
dunno
<j-b>
I was at a horrible Open Source Conference
<j-b>
ML cannot be worse than that
<elenril>
I see you are new to our ML
<jamrial>
one of those had ng
<j-b>
oh
<j-b>
I'm on it.
<j-b>
An essay again...
<j-b>
He is arguing it was not broken?
<j-b>
WTF.
<j-b>
It's non-deterministic.
<elenril>
motivated reasoning and confirmation bias are like meth and cocaine
<j-b>
OK, TC it is.
<elenril>
see my latest email
<j-b>
michaelni: did you update the tc@ or cc@ aliases?
<courmisch>
elenril: not much point in UEFI if you don't have upstream OS support for the hardware
<courmisch>
and I'd like to see a mobile phone with proper upstream kernel support
<elenril>
j-b: ?
<j-b>
elenril: AI. watch it.
<elenril>
I did
<elenril>
eh
<j-b>
the video is 6min long
<j-b>
it's nuts
<another|>
"Tell me what you see." - "I see the ffmpeg mailinglist. It's not a nice place to be."
<courmisch>
inb4 "some AI said that you are [INSULT] but since it's the AI who said it, it's totally not my fault"
<michaelni>
elenril, j-b CC & TC aliases should be updated, ill update the GA alias next. for TC ATM i added Jan and Niklas it seemed to do no harm to if Niklas can participate in dicsussions even if he doesnt vote, but iam happy to change that if people prefer
<j-b>
michaelni: that's a good idea. Get them both on the TC mail and get only the vote to Jan.
<j-b>
courmisch: I love that excuse
<j-b>
courmisch: you can add in your signature "email modified by AI - no harm or insults intended" and then attack eople
* another|
stabs j-b (with AI)
<courmisch>
yeah no need to train an AI to make an elenril bot
<courmisch>
just have the bot stab whoever said something at a pseudo-random interval
<elenril>
i suppose that does count as AI these days
<BtbN>
Just claim it was a software issue. Lots of people get away with outrageous shit by claiming that.
<cone-797>
ffmpeg James Almer release/5.1:ae14d9c06bcd: fftools/ffprobe: support 2D arrays in print_list_fmt()
MrZeus_ has joined #ffmpeg-devel
MrZeus__ has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 252 seconds]
MrZeus_ has quit [Ping timeout: 246 seconds]
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #ffmpeg-devel
MrZeus_ has joined #ffmpeg-devel
MikhailAMD has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 246 seconds]
<elenril>
shouldn't effadce6c756247ea8bae32dc13bb3e6f464f0eb be backported to all the releases?
qeed has joined #ffmpeg-devel
<JEEB>
elenril: in case of backwards compatibility... probably?
durandal_1707 has left #ffmpeg-devel [#ffmpeg-devel]
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
<elenril>
wow, the SEETHING is palpable
<jamrial>
?
<jamrial>
oh, ng
kurosu has joined #ffmpeg-devel
<elenril>
I'm also not quite sure who he thinks his side is
<ePirat>
of course everyone who disagrees with him!
<ePirat>
(seriously, I have no idea what he is going on about…)
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
cone-797 has quit [Quit: transmission timeout]
<cosminaught>
the comment for sub2video heartbeat says `This is a temporary solution until libavfilter gets real subtitles support`. What is the "real subtitles support" needed in libavfilter to remove the need for this hack?
<JEEB>
AVFrames for subtitles
<JEEB>
subtitles are still in their own structures
<JEEB>
there was some work on that done, but unfortunately (yet understandably) that developer decided that he didn't want to do any additional changes to the patch set
<Traneptora>
FFmpeg's internal sub representation is mostly ASS, right?
<JEEB>
textual stuff, yea
<Traneptora>
iirc there was an issue with ASS only having 0.01s precision
<Traneptora>
could we theoretically change the internal sub representation to allow higher precision
<JEEB>
I think that is already so at least on the AVPacket level
<cosminaught>
JEEB: let me see if I can find the patch set and how much work was left to be done on it
<JEEB>
AVSubtitle I don't recall what its limits were, but it has separate pts|end fields
<JEEB>
so we are not actually dealing with ASS for the timings
<Traneptora>
since parsers can't error out, how do we test parsers of invalid structures?
<wbs>
not sure that one can get rid of the heartbeats anyway; even with avframe based subtitles, I would expect that the heartbeat stuff is necessary to make things work as the subtitles are sparse compared to audio/video
<JEEB>
yea
<Traneptora>
I'm working on more jpegxl_parser tests but I want to test how it handles invalid streams too. currently it throws up its hands and just packetizes the remaining stream
<JEEB>
you would have to have the heartbeats just in avfilter or so
<Traneptora>
if the file is invalid
<JEEB>
Traneptora: yea with parser handling invalid data is meh right now. I heard at one point that the parsing stuff would be moved to how CBS is right now, but that's not where we are right now
<Traneptora>
should I worry about parsing invalid data once the AVParser api is overhaulted?
<JEEB>
cosminaught: yea you can take a look; I think one of the biggest question marks was regarding it just duplicating AVSubtitle values into AVFrame, even though AVFrame already had members that did similar enough
<Traneptora>
overhauled*
<Traneptora>
I thought jamrial said something about that happening soon but idk
<JEEB>
I don't know either :D
<JEEB>
but yea, I noticed it with mpeg-ts muxes where people don't care about PES packet starts to start packets
<JEEB>
so you have some amount of garbage
<JEEB>
and then start code at some point
<JEEB>
and the classic parser just spits a buffer back at you first
<JEEB>
not sure if there's a way to signal in the AVPacket created then that the data is btw not good
<JEEB>
or well, if the parser can
<JEEB>
since you need to have the parser inform you first, then you pass on the data to the thing creating AVPacket from it
<JEEB>
this is actually why at least for two codecs in the mp4 writer there's specific code to ignore invalid initial packets >_>
<JEEB>
which to me sounds so wrong
<JEEB>
those invalid packets should be dropped earlier in the flo
<JEEB>
*flow
ccawley2011 has quit [Quit: Leaving]
<cosminaught>
wbs: I'm not clear why "heartbeats" are needed, it seems like the sparseness could be handled with start time + duration, and having "empty" subtitle frames to cover durations where there are no subtitles to display
<wbs>
cosminaught: it's probably not so much about that, as it is about synchronizing multiple streams (consider interleaving queues etc); if you'd have a 60 second gap between subtitles, you'd end up buffering all audio/video for 60 seconds before you get the next packet in the subtitle stream, so you know which packet in which stream to mux next
<wbs>
so I would expect heartbeats help with that, indicating that we don't really have any packet, but we _know_ there's not a packet up to time X
<wbs>
I haven't really spent any effort on this so I might be totally off here, but that's at least my general hunch for what heartbeats can help work around
qeed has quit [Read error: Connection reset by peer]
qeed has joined #ffmpeg-devel
<JEEB>
yea
<cosminaught>
ok, I think this heartbeat is the same as the empty subtitle frame I'm imagining. Whether it has to be issued periodically with multiple empty frames say every 0.1s or one long one I think depends whether you are dealing with some kind of a live input where you can't seek ahead to find the next subtitle and cover the whole empty duration with one frame