Krowl has quit [Read error: Connection reset by peer]
kurosu has quit [Quit: Connection closed for inactivity]
dellas has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<Daemon404>
Traneptora, no its a bunch of hex
Krowl has joined #ffmpeg-devel
<JEEB>
yea it's a box
<Daemon404>
a bunch if hex in a string in a box :p
<Daemon404>
of*
<JEEB>
> string in a box
<JEEB>
-_-
jamrial has quit [Ping timeout: 246 seconds]
<nevcairiel>
speaking of mov metadata, who do i complain to that we dont support stream-level tags at all? :D (they just get read into global metadata, replacing each other if multiple tracks have the same, nevermidn that many tags are just not mapped)
<JEEB>
nevcairiel: yea I noticed that at some point and started trying to adjust that but so much stuff required adjusting...
<JEEB>
(also FATE tests and the muxer needed adjustment most likely)
lexano has joined #ffmpeg-devel
<JEEB>
not sure I have a branch for that on github, I possibly noticed it with the 3GPP titl work...
<JEEB>
Daemon404: not only that what you think, but we also have a lack of people with mental capacity to do reviews. for example I still haven't been able to go through the ambient light mp4 (de)mux patch set
<Daemon404>
tbh i tend to lose stuff i cam review into noise
<Daemon404>
i check the ml maybe knce a day or other day
<Daemon404>
something something gitlab when
<wbs>
also, having something like gitlab would make it _much_ easier to pick up reviews when one can't attend them right away
* Daemon404
runs
<Daemon404>
hah
<Daemon404>
jinx
<JEEB>
wbs: ditto.
<Daemon404>
literally that.
<wbs>
and then when one tries to look at it one week later, the patch turns out to have corrupted whitespace and can't be applied
<Daemon404>
often ive seen a patch, thought i shoyld reply, but got busy
<Daemon404>
then its gone into the ether
<Daemon404>
1000 messages down
<nevcairiel>
i always hated the ML for reviews, its like a 30 year old paradigm when everyone used text clients, people claim i need better tools to manage it, and i tell them that tool is gitlab or whatever :P
<Daemon404>
i dont even like gitlab at all, its just less bad enough id orefer it
<wbs>
it used to be more manageable 10-15 years ago IMO
<Daemon404>
prefer*
<JEEB>
Daemon404: "least bad alternative paradigm"
<wbs>
either a change in total flow of traffic, or the amount of attention I can devote to it
<Daemon404>
yes
<Daemon404>
wbs, both
<JEEB>
wbs: or both
<JEEB>
yea
<Daemon404>
we got old man
<elenril>
your tools suck
* elenril
ducks
<Daemon404>
i shouldnt need sets of tools to augment a bad systen
<wbs>
but really, with non-mail tools, I would hope that one could get a lot more actual comments directly on the patches, for trivial acknowledgements and such, rather than having to reply "N.N. acked this on irc" oneself to the ML
<wbs>
because I can ask for a look by someone on irc, but I know it's extra effort for the reviewer to get that into the proper paper trail for the patch
<Daemon404>
PATCH v15
jamrial has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
BetweenUs has quit [Read error: Connection reset by peer]
qeed has joined #ffmpeg-devel
qeed_ has quit [Ping timeout: 272 seconds]
qeed has quit [Quit: qeed]
qeed has joined #ffmpeg-devel
<durandal_1707>
JEEB: please reply to NG, i cant deal with his behaviour.
<JEEB>
yea I will, still at $dayjob
<durandal_1707>
when it is about trolling he always reply promptly, what a dick.
AbleBacon has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
SystemError has quit [Remote host closed the connection]
Krowl has joined #ffmpeg-devel
SystemError has joined #ffmpeg-devel
<Daemon404>
i feel like asking people to engage with NG is asking them to self-harm
<JEEB>
sure
<JEEB>
but I still did it
<JEEB>
since I kinda would like that boog to get fixed since it probably affects a bunch of other filters which were ported to activate
<JEEB>
durandal_1707: dunno why, but I did respond :)
<jamrial>
JEEB: you were, but that's unlikely to make him be less condescending
<JEEB>
I know that, I've got experience with trying to deal with him
<JEEB>
back from the XML escaping stuff for the TTML writer
<Daemon404>
can anyone explain to me why NG is allowed to act like a raging a-hole and still remain allowed to be a part of the community with no repercussion?
<Daemon404>
cause he is old guard?
<Daemon404>
cause he is pals with Leader?
<Daemon404>
i dont get it
justHaunted is now known as justache
<Daemon404>
(i expect the usual deafening silence)
<jamrial>
Daemon404: i mean, how do we go about kicking someone?
<Daemon404>
weve banned plenty of people from the ml before
<Daemon404>
without discussion even
<Daemon404>
like angry colorspace man
<Daemon404>
thilo simply banned him
<Daemon404>
it's a double standard
<jamrial>
that said, what he's saying here is that paul hasn't explained how his fix fixes anything, and that it could simply be hiding the problem in his specific testcase
<jamrial>
if that's true i don't know, but maybe an explanation in the commit message would help?
<Daemon404>
i agree but that does not excuse nicolas years long assholeism
<Daemon404>
and direct attacks
<jamrial>
agree
<durandal_1707>
jamrial: its in 2nd patch
<durandal_1707>
also in that same thread
<Daemon404>
one problem is we always insist at solely looking at The Latest Incient
<Daemon404>
and This Specific TIme
<Daemon404>
rather than repeate behavior or patterns
<JEEB>
anyways nowadays in *theory* how these should go is that if it's just attacks or not following the rules in general -> you report it to the community council
<Daemon404>
i had people at demuxed tell me NG specificlaly made them not contribute
<JEEB>
just like if someone is just nope'ing your stuff without a clear explanation you can raise it to TC
<JEEB>
so that you get out of the "yes!" "no!" spiral
<Daemon404>
TC and CC are toothless and broken atm
<Daemon404>
reluctant to even take any action
<JEEB>
I may not disagree on that but I'm just saying how it *should* work
<jamrial>
then lets get on with the cc integration vote
<JEEB>
> and I used it to see that it does not fix the issue
<JEEB>
huh
<JEEB>
so he says the test case I posted and which got improved on two systems did not improve on his side
<Daemon404>
how does that make sense unless moonbeans are flipping bits
<JEEB>
due to this being NG I'm not sure how to take that in. Either he is deliberately being very specific with the word "fix" (in other words, he saw the improvement but he then did not see it fixing some overarching problem), or it really did not improve on his system
<Daemon404>
jamrial, i will eat my QuickTime is not a Codec hat if post-vote CC is any more toothful
<Daemon404>
what we need is a written list of rules like ban times, etc
<Daemon404>
like VLC has
<jamrial>
we don't have that? i recall this being discussed before
<jamrial>
and maybe patches sent
<Daemon404>
people objected iirc
<Daemon404>
(exactly who you think)
<jamrial>
JEEB: ask him what he sees if it's not "fixed". still too much memory consumed? some other error? etc
<JEEB>
anyways the worst bit of this thread is that this takes all the focus away from whether the patches are good or not
<JEEB>
instead it moves into very specifics
<JEEB>
jamrial: I'd rather work on the patch set that has been stuck in "rewrite due to review commits" N times
<JEEB>
as I'd like avctx encoder HDR10 support be in before 7.0
<JEEB>
lol
<jamrial>
durandal_1707, JEEB: he seems to be getting EAGAIN returned when it evidently shouldn't
<JEEB>
alright, hopefully that gets the thread back on rails towards actually pointing out the issues with the patches
<Daemon404>
jamrial the professional NG interpreter
<durandal_1707>
jamrial: --assert-level=2
MisterMinister has joined #ffmpeg-devel
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 248 seconds]
navi has quit [Read error: Connection reset by peer]
<Daemon404>
what an asshole
<elenril>
Daemon404: pics or it does not exist
<elenril>
Lynne: i'm currently doing last touchups for cli threading
<elenril>
i'll look at your set after that's done
<Daemon404>
lew
<Daemon404>
d
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
cone-930 has joined #ffmpeg-devel
<cone-930>
ffmpeg Michael Niedermayer master:68cc1744db82: avcodec/evc_parse: Check tid
<cone-930>
ffmpeg Michael Niedermayer master:d35eecd24fb6: avcodec/evc_parse: remove pow() and log2()
<cone-930>
ffmpeg Michael Niedermayer master:98c2711b58ce: avformat/mov: Check that is_still_picture_avif has no trak based streams
<cone-930>
ffmpeg Michael Niedermayer master:2def61778777: avcodec/apedec: Fix integer overflow in predictor_decode_stereo_3950()
<cone-930>
ffmpeg Michael Niedermayer master:c2f2bf82c1b3: tools/target_dec_fuzzer: Adjust threshold for CSCD
<cone-930>
ffmpeg Michael Niedermayer master:2817efbba331: avcodec/dovi_rpu: Use 64 bit in get_us/se_coeff()
<cone-930>
ffmpeg Michael Niedermayer master:356b1ba76562: avcodec/vlc: Skip subtable entries in multi VLC
<cone-930>
ffmpeg Michael Niedermayer master:8516609edde9: avcodec/vlc: Replace mysterious max computation code in multi vlc
<cone-930>
ffmpeg Michael Niedermayer master:a5259f326bca: avcodec/vlc: Pass VLC_MULTI_ELEM directly not by pointer
tufei has joined #ffmpeg-devel
<mkver>
elenril: Are you ok with me committing the refstruct-pool stuff without the threading-stuff?
<elenril>
without the what?
<courmisch>
Lynne: I have the board
<courmisch>
elenril: the stuff without the stuff, obviously
<courmisch>
mkver: my question was not what about heap allocation failure, but if it would be considered a memory leak - since you can't free a one-time allocation
<mkver>
Without the ProgressFrame stuff.
<mkver>
Why don't you just use a buffer with static storage duration like the rest of the code?
<courmisch>
because I only know the size at run-time
<mkver>
What exactly are we talking about?
<mkver>
Does it have to do with third-party libs?
<elenril>
mkver: sure
<JEEB>
riscv has variable length vector stuff
<courmisch>
mkver: the sbr noise table; the amount of necessary duplication varies with the CPU
<courmisch>
currently it's hard-coded to 8 entries
<mkver>
Is there no reasonable upper bound?
<courmisch>
well, 32 KiB or so
<courmisch>
that's quite a lot compared to the current 32 bytes
<courmisch>
or 64 bytes
<courmisch>
of course, we could just double the array size always and be done with it
Krowl has quit [Read error: Connection reset by peer]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
dellas83 has quit [Remote host closed the connection]
Krowl has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 264 seconds]
<cone-930>
ffmpeg Rémi Denis-Courmont master:b2a441a3bed2: lavc/jpeg2000dsp: make coefficients extern
<cone-930>
ffmpeg Rémi Denis-Courmont master:73dea2bb9174: lavc/jpeg2000dsp: R-V V ict_float
<cone-930>
ffmpeg Rémi Denis-Courmont master:28840cf499ad: lavc/jpeg2000dsp: R-V V rct_int
darkapex has quit [Ping timeout: 252 seconds]
darkapex has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
<cone-930>
ffmpeg Rémi Denis-Courmont master:92bcc6703acf: lavc/pixblockdsp: remove R-V V get_pixels_16
qeed_ has quit [Ping timeout: 255 seconds]
qeed has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
ccawley2011 has quit [Read error: Connection reset by peer]
dellas has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
courmisch: nice, did it boot up? what's the cpuflags situation like?
<courmisch>
Lynne: boot up, ues
<courmisch>
Lynne: but on the wrong core
<courmisch>
Lynne: obviously people want an RTOS on the big core and Linux on the small core. Obviously.
<courmisch>
Did I mention that it was obvious
<courmisch>
sorry not RTOS, it's "RTSMART". Clearly that makes it better
<courmisch>
kierank: at least it's just buildroot, not Yocto
dellas has joined #ffmpeg-devel
<Lynne>
Daemon404: you've never been in a bad part of town, haven't you?
<elenril>
don't they teach you this stuff in school?
rvalue has joined #ffmpeg-devel
<courmisch>
Daemon404: what kind of sheltered life have you been living?
<elenril>
they told us in elementary school to be careful with solvents because they are addictive and make holes in your brain
<courmisch>
even I, who has never willingly taken any illegal drug, know that you can sniff glue from school days
<Daemon404>
Lynne, the bad parts of town where i grew up are now fentanyl.
<Daemon404>
slightly stronger than glue.
<Daemon404>
glue is comically tame.
<elenril>
eew
<elenril>
the edgy kids from my high school just smoked
<Daemon404>
so the answer is maybe "less sheltere than you"
<courmisch>
elenril: my country side (or very sparse and remote suburban) high school had drug sellers around
<courmisch>
probably still does, not that I'd know
<elenril>
i thought amanita muscaria is finnish national food
<courmisch>
I did my education in Northern France, FYI
<courmisch>
except for the last 3 years in affluent parisian suburbs with El Presidente
qeed has joined #ffmpeg-devel
Sebastinas has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
elastic_dog has quit [Ping timeout: 255 seconds]
<courmisch>
Ok, we have working RVV 1.0 hardware
<JEEB>
noice
<courmisch>
only four hours to figure out how to build the firmware yesterday and 1.5 to fix it today
<Lynne>
🎉
<Lynne>
instruction timing wise, does it look like it's any different than rvv 0.71?
elastic_dog has joined #ffmpeg-devel
<cone-930>
ffmpeg Andreas Rheinhardt master:26c0a7321fde: avcodec/refstruct: Add RefStruct pool API
<cone-930>
ffmpeg Andreas Rheinhardt master:736b510fcc38: avcodec/h264dec: Use RefStruct-pool API instead of AVBufferPool API
<cone-930>
ffmpeg Andreas Rheinhardt master:fd2e65871c6f: avcodec/hevcdec: Use RefStruct-pool API instead of AVBufferPool API
<cone-930>
ffmpeg Andreas Rheinhardt master:e01e30ede1d0: avcodec/nvdec: Use RefStruct-pool API for decoder pool
<cone-930>
ffmpeg Andreas Rheinhardt master:090d9956fd09: avcodec/refstruct: Allow to always return zeroed pool entries
<cone-930>
ffmpeg Andreas Rheinhardt master:8c0350f57ef4: avcodec/vp9: Use RefStruct-pool API for extradata
<cone-930>
ffmpeg Andreas Rheinhardt master:92abc7266b5a: avcodec/vaapi_encode: Use RefStruct pool API, stop abusing AVBuffer API
<cone-930>
ffmpeg Andreas Rheinhardt master:0c44f63b0282: avcodec/refstruct: Allow to share pools
<cone-930>
ffmpeg Andreas Rheinhardt master:eba73142adc7: avcodec/vp9: Join extradata buffer pools
averne11 has joined #ffmpeg-devel
<courmisch>
Lynne: scalar is a lot worse, and vector is maybe 25% better. Assuming that this is due to lower frequency, that means vector are actually a lot better now
<averne11>
Hi all, I have some questions regarding the usage of the HWACCEL_CAP_THREAD_SAFE flag that was added in 6.1. What are the constraints that a hwaccel must fulfill for it?
<averne11>
In particular, my hwaccels maintains memory-mapped buffers containing codec data. Does this need to be copied over within the update_thread_context callback?
<averne11>
I tried to just add the flag and it didn't seem to cause any visible issues, at least for the files I tested
<courmisch>
wbs: LD1 requires alignment to the element size of the vector operand or... ?
<wbs>
courmisch: not entirely sure; either element size alignment, or no alignment required at all
<elenril>
averne11: if every thread needs its own instance, then yes
<Lynne>
averne11: which hwaccel?
<Lynne>
in general, vulkan, which is the only hwaccel to use it, keeps references to each resource it uses for each submission
<Lynne>
those references are only unref'd once the same decode thread decodes again
<averne11>
docs, what these actually contain is opaque.
<Lynne>
oh, right, that's you, now I remember
<averne11>
Yep we already discussed some other stuff
<Lynne>
yeah, if you're using a threaded hwaccel, just do what vulkan does, except without the multiqueue stuff, but rather pin a single queue to a single decode context if you have multiple queuess
<Lynne>
keep all resources around in each context until the next time that context decodes
<cone-930>
ffmpeg Rémi Denis-Courmont master:86bee424730b: lavc/sbrdsp: R-V V sum64x5
<cone-930>
ffmpeg Rémi Denis-Courmont master:b0aba7dd0c1e: lavc/sbrdsp: R-V V sum_square
<cone-930>
ffmpeg Rémi Denis-Courmont master:d06fd18f8f4c: lavc/sbrdsp: R-V V neg_odd_64
<averne11>
Right, I'll need to take a look at what Vulkan does
<averne11>
Another question, in the case of the Switch, there is a single hardware engine processing jobs serially. Can I expect any speedup with HWACCEL_CAP_THREAD_SAFE, or am I wasting my time?
<Lynne>
you'll get some speedup, as each thread will be constructing the command data independently
<Lynne>
but you have to have a queue underneath
<Lynne>
if you don't have a kernel to queue all the commands into, but rather you send the commands directly to the hw, you're wasting your time
<wbs>
not sure if relevant/related or not, but isn't one aspect also, that you don't explicitly want to do it threaded for performance, but users who might want to fallback from hwaccel to sw decoding want threading enabled (in order not to have to reinit the decoder if falling back to sw), thus the hw codepaths ideally need to be threadsafe as well
<kierank>
mkver: I think we should use SPI money for a bounty for removal of mmx
<mkver>
What is it that you dislike it for? The fact of its existence or the fact that current usage does not abide by the ABI?
<averne11>
>if you don't have a kernel to queue all the commands into, but rather you send the commands directly to the hw, you're wasting your time
<averne11>
the commands are sent to a hardware engine called host1x which does manages interrupts/register writes, but it doesn't do any fancy stuff like scheduling or whatnot. In fact, on tegras with several nvdec instances, the load balancing is done on the userspace driver side
<averne11>
I'll see if this threadsafe stuff is complicated to implement, but I suspect in the end the buffer copies will end up eating more CPU for a negligible speed boost
<kierank>
mkver: The fact it's used in 2023. Also xmms
<kierank>
emms*
<kierank>
by removal of mmx I mean rewriting all reasonable code to sse2
<Daemon404>
i would think compiler vectorization could maybe make faster code than forcing mmx asm to run by now...
<courmisch>
realistically, it's the same hardware running AVX or SSE that emulates MMX
ccawley2011 has quit [Read error: Connection reset by peer]
dlb76 has quit [Ping timeout: 240 seconds]
ocrete2 has quit [Ping timeout: 240 seconds]
ocrete2 has joined #ffmpeg-devel
dlb76 has joined #ffmpeg-devel
<Lynne>
Daemon404: so, about the mov patch I sent, could you review it?
<Daemon404>
i will look tomorrow, but i was hoping elenril also woul yay/nay it
<Daemon404>
my brain is mush from $dayjob
<Daemon404>
opened it in a tab so ill see it when i sign on
SystemError has quit [Ping timeout: 256 seconds]
Sean_McG has joined #ffmpeg-devel
SystemError has joined #ffmpeg-devel
mkver has quit [Ping timeout: 248 seconds]
<Daemon404>
the implementation is probably fine, i just need to put some thought into the related patchset first (and ping derf about one thing)
SystemError has quit [Ping timeout: 256 seconds]
<Daemon404>
Lynne, have you mainly been testing with that fdk file?
<Lynne>
yes
<Daemon404>
i ask since i noticed there is some nuance to the files is makes
<Lynne>
though I run the patchset on my system's ffmpeg
<Lynne>
so far, I haven't seen anything different
<Daemon404>
2nd: were you testing decode after seek or intial decode (priming+delay)
<Lynne>
both
<Lynne>
the patch doesn't affect seeks though
<Lynne>
(and it shouldn't)
<Daemon404>
right
averne11 has quit [Quit: Client closed]
<Daemon404>
so i noticed by default that the cli tool does *not* include sbr delay in the mp4 metadata
<Daemon404>
there is a option for it
<Daemon404>
because it's techncally a wrong mp4 not o
<Daemon404>
however itunes needs these wrong mp4s...
<Daemon404>
at least according to the readme.
<Daemon404>
also were you using he v2?
<Lynne>
yes
<Daemon404>
ok
<Lynne>
parametric stereo doesn't make a difference though
<Daemon404>
im curious if you test both files (with/without) if one of them works.
<Daemon404>
fdk also has an option to write elst/sgpd, which i use to confirm values
dellas has quit [Remote host closed the connection]
<Daemon404>
if you stll have fdk: 1. ./fdkaac -G 1 -p 29 -o no.mp4 --bitrate 128 a.wav 2. ./fdkaac -G 1 -p 29 --include-sbr-delay -o yes.mp4 --bitrate 128 a.wav
<Daemon404>
sbr delay seems to be 481 samples
<Lynne>
oh no, I was using aac_he v1
<Daemon404>
oh
<Daemon404>
well -p 5 then
<Lynne>
v2 creates a larger gap
<Daemon404>
yes
<Lynne>
WHYYY
<j-b>
To annoy you.
<j-b>
ON PURPOSE.
<Daemon404>
also probably important to check if your patch is working pre or post upsampling
<Daemon404>
i.e. if you have to double the delay samples
<Lynne>
what do you mean?
<Lynne>
it works on the output
<Lynne>
which is post-sampled
<Daemon404>
delay is pe.
<Daemon404>
pre*
<Lynne>
what delay?
<Daemon404>
in mp4
<Lynne>
so skip_samples?
<Daemon404>
timestamps and elst represent pre-upsampling for sbr
<Daemon404>
iirc
<Daemon404>
thats why the sbr delay is coded as 481 and not 962
<Lynne>
why would I care about any of that?
<Lynne>
zero is zero in any timebase
<Daemon404>
because youll skip the wron amount of sampls
<Daemon404>
if you apply a delay in one timebase to another
<Lynne>
I only care about what's in the side data, is the muxer wrong or is it not wrong?
<Daemon404>
it is correct because that is how it works
<Daemon404>
for he you likely need to *2
elastic_dog has quit [Ping timeout: 264 seconds]
<Lynne>
so I need to override the side data and multiply it by two?
<Lynne>
if it's there?
<Daemon404>
only for he-aac
<Lynne>
for aac-he, but only v2
<Daemon404>
i think anythin with sb
<Daemon404>
sbr*
<Lynne>
can't the demuxer do that?
<Lynne>
I think it should adjust the duration such that it's accurate for the output timebase
<Daemon404>
he has different timebase after decoding than muxing
<Daemon404>
than demuxing*
<Daemon404>
unless we already compensate for this in lavf
<Daemon404>
oh right... sbr is one of those things that has two incompatible ways to be signalle in mp4
<Daemon404>
might need a demuxer option to toggle the two
<Lynne>
side data should be generic, so I think the demuxer should do it
<Daemon404>
i would confirm im even rigth re: *2 first
<Lynne>
by the way, the SBR delay I'm seeing in he_v1 is 3010 samples, not 962 or 481
tufei_ has quit [Remote host closed the connection]
<Daemon404>
that seems way off to me
<Daemon404>
he has a standard delay
<Lynne>
that is the standard delay I'm seeing
tufei_ has joined #ffmpeg-devel
<Daemon404>
from where
<Lynne>
the algorithmic delay, the spec says 3010 samples (or 3009, excluding one)
<Daemon404>
eh? every spec ive ever read says 481/962
<Daemon404>
(as in just the extra sbr delay)
<Lynne>
ISO_IEC-14496-3
<Lynne>
1.6.7.2 Handling of composition time stamps