<cone-581>
ffmpeg Paul B Mahol master:deb4c28dcc9c: avcodec/mlpenc: add 3.1 ch layout support for truehd
<cone-581>
ffmpeg Paul B Mahol master:210e844def9d: avcodec/mlpdec: support for truehd with channels not representable with 5bit field in second stream
<cone-581>
ffmpeg Paul B Mahol master:36eb774ad49b: avcodec/mlpenc: try different filter parameters in case of out of range output from LPC
<cone-581>
ffmpeg Paul B Mahol master:567af48fba19: avcodec/mlpenc: add support for 4.0/4.1 ch layout
<elenril>
durandal_1707: seems to work
<elenril>
can't really comment on the code though
<durandal_1707>
elenril: push it
elastic_dog has quit [Ping timeout: 258 seconds]
elastic_dog has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<BossTanaka>
push it, baby, push it! push it real good!
<durandal_1707>
pull it
<JEEB>
time to properly report that memory ballooning case with codec copy + trim
<JEEB>
so that if someone looks at trac issues it might get noticed
<JEEB>
but this used to work until trim got updated :D
<durandal_1707>
you are basically creating thumbnail
<durandal_1707>
single thumbnail
<durandal_1707>
how that is supposed to be interleaved with rest of streams in final outut?
<durandal_1707>
*output
<JEEB>
it's a separate output
<JEEB>
until 90fba27743041a896bde618d99633c418ebc2a45 it would not balloon :)
<JEEB>
now something is buffering even though there is an EOF
<JEEB>
anyways, I will try without the split, but at least until now using split like this has worked
ismail has quit [Quit: Connection closed for inactivity]
<JEEB>
to my understanding it would have just eaten the frames before instead of EOF, which technically is dumb, but at least didn't balloon the memory usage :D
<durandal_1707>
JEEB: that is ffmpeg.c stupidity
<JEEB>
sure
<JEEB>
anyways, that's why I want to now properly report it :P
<JEEB>
anyways, if you think the split is the culprit I can attempt to simplify the filter chain to not have the split there and see if I still get it :P
<durandal_1707>
JEEB: more buffersrc is culprit
novaphoenix has quit [Quit: i quit]
<JEEB>
yea something like that is what I expected, something generic (either ffmpeg cli or buffersrc or something) not handling the EOF
novaphoenix has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<cone-581>
ffmpeg James Almer master:4b8404815de4: avutil/channel_layout: rename 7.1(top) channel layout to 5.1.2
<cone-581>
ffmpeg James Almer master:8d46cbce4f15: avutil/channel_layout: add a 5.1.4 channel layout
<cone-581>
ffmpeg James Almer master:a41c4b923dbc: avutil/channel_layout: add a 7.1.2 channel layout
<cone-581>
ffmpeg Will Wolcott master:e9397ae0544d: avutil/channel_layout: add a 7.1.4 channel layout
<cone-581>
ffmpeg James Almer master:35b06853d1ba: avutil/channel_layout: add a 3.1.2 channel layout
<cone-581>
ffmpeg James Almer master:52a976426046: avutil: bump minor version after recent commits
Krowl has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 258 seconds]
Kei_N has joined #ffmpeg-devel
<durandal_1707>
JEEB: fixed memory leak, now it instead errors out
<JEEB>
oh
<JEEB>
can you show how you poked at it? or should it appear in patchwork in a bit?
<durandal_1707>
now fixed error out to, instead of EINVAL now returns AVERROR_EOF on EOF
<durandal_1707>
JEEB: on ML
<JEEB>
cheers
<JEEB>
durandal_1707: tested that change and I'm still getting > Maximum resident set size (kbytes): 609456
<JEEB>
the previous value was > Maximum resident set size (kbytes): 62636
dellas has quit [Remote host closed the connection]
<durandal_1707>
JEEB: on master ?
<JEEB>
yea
<JEEB>
I mean, 62 megs before you switched trim to activate
<JEEB>
and if I revert that change
<JEEB>
then 609 with pure master and with your AVERROR_EOF
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
deus0ww has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
<durandal_1707>
JEEB: you need both patches
<JEEB>
oh it was two
<JEEB>
I only saw one in patchwork
<JEEB>
sorry
<durandal_1707>
patchwork is crap
<durandal_1707>
here memory usage of ffmpeg stays bellow <2 % all the time
<durandal_1707>
without patches it rises to GBs in few seconds
<JEEB>
durandal_1707: yup, muchos bättre > Maximum resident set size (kbytes): 62608
<JEEB>
(this is /usr/bin/time -v)
<durandal_1707>
also it should be faster? once it creats thumnail no more it decodes frames.
<JEEB>
yea if it now works a proper EOF it should no longer be dumb and continue :D
<durandal_1707>
tehnically you could seek into input instead of using trim=start=X , and that would be even faster. But may give different results.
<durandal_1707>
either via -ss or via -f lavfi -i movie=sp=X
<JEEB>
yea since this use case specifically has codec copy and image output I kinda wanted to not have ss in there :)
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #ffmpeg-devel
Traneptora_ has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
<elenril>
JEEB: i don't see the email address you're objecting to in .mailmap fwiw
BossTanaka is now known as microchip_
lexano has quit [Ping timeout: 260 seconds]
<elenril>
huh, spinning on pthread_cond_timedwait() that timeouts immediately is not as slow as I would have thunk
<elenril>
in other news, I totally missed that it takes an absolute time as a parameter
lexano has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
<haasn>
the real open question is, how do YUVA formats work
<philipl>
Lynne: i will look today. Need to make sure mpv doesn't rely on that.
<elenril>
haasn: fucking yuvas how do they work
Krowl has quit [Read error: Connection reset by peer]
elastic_dog has quit [Ping timeout: 248 seconds]
<haasn>
well according to swscale yuva A plane is just copied as-is to RGBA
<haasn>
so that means it should be full range, I guess
<Lynne>
yup, alpha should always be full range
MajorBiscuit has quit [Quit: WeeChat 4.1.0]
Krowl has joined #ffmpeg-devel
<elenril>
on that topic, the copy should be eliminatable with refcounting
elastic_dog has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
cone-581 has quit [Quit: transmission timeout]
<haasn>
elenril: not for rgba formats
<haasn>
(which is what I was looking at)
<elenril>
yeah, you still need to interleave then
<JEEB>
elenril: ibrecall there being a patch regarding that. i will check again after I get home
<haasn>
vf_alphamerge seems fundamentally broken
<JEEB>
aand ended up checking on phone and you're right; there's another one there
<haasn>
ah, no, it accepts gray8 only, so just need to warn if range mismatch
user23 has joined #ffmpeg-devel
aljazmc_ has joined #ffmpeg-devel
aljazmc has quit [Remote host closed the connection]
Krowl has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
<haasn>
yikes, vf_scale is more broken than I thought
<haasn>
copying pc range yuv to pc range yuv only works because two bugs interact and cancel each other out
<elenril>
one must be an antibug
<haasn>
time to rewrite
<elenril>
unified chromadynamics
AbleBacon has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
microchip_ has quit [Quit: There is no spoon!]
dellas has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
cone-686 has joined #ffmpeg-devel
<cone-686>
ffmpeg Michael Niedermayer master:ffac64a270a7: avcodec/bitstream_template: Basic documentation for read_vlc_multi()
<cone-686>
ffmpeg Michael Niedermayer master:9b546a071764: avcodec/vlc: merge lost 16bit end of array check
<cone-686>
ffmpeg Michael Niedermayer master:4ddf4f5001ca: avcodec/magicyuv: correct end of array check in multi VLC parsing
<cone-686>
ffmpeg Michael Niedermayer master:a23d527ec5d5: avcodec/magicyuv: remove redundant check in inner loop
<cone-686>
ffmpeg Michael Niedermayer master:9690d71f114a: avcodec/vlc: dont pass nb_elems into multi vlc code
<cone-686>
ffmpeg Michael Niedermayer master:88453250dbe9: avcodec/jpeg2000dec: Check image offset
<cone-686>
ffmpeg Michael Niedermayer master:907743239d83: avutil/tx_template: fix integer ovberflwo in fft3()
<cone-686>
ffmpeg Michael Niedermayer master:e4d5ac8d7d2a: avformat/rtsp: Use rtsp_st->stream_index
lexano has quit [Ping timeout: 260 seconds]
<philipl>
Lynne: it looks good, I have acked on the ML. Do you want me to merge it?
<Lynne>
I think Zhao has push access
lexano has joined #ffmpeg-devel
<philipl>
Lynne: great
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
<haasn>
sent a bunch of preliminary fixes for YUVJ removal
<haasn>
most of this will become nicer once range negotiation is in avfilter but I need to get all of the bug fixes out of the way, if only for my own sanity
<JEEB>
sounds good
HarshK23 has joined #ffmpeg-devel
lexano has quit [Ping timeout: 252 seconds]
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
user23 has quit [Ping timeout: 248 seconds]
user23 has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
user23 has quit [Remote host closed the connection]
<durandal_1707>
Lynne: do you know any fast way to get IIR (numerator / denominator coefficients) that approximate spectrum of input audio frame?
<Lynne>
err, what does IIR have to do with it?
<Daemon404>
Lynne, oh woops. I'm heading back to the UK today so I'll be able to check finally - been travelling.
<Lynne>
cool, thanks
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
<durandal_1707>
Lynne: it compress better than only FIR
<Lynne>
no surprises there, but what do you mean by IIR coefficients to estimate the spectrum of an input audio frame?
<Lynne>
do you mean to say that the IIR filter acts as a way to shape the audio spectrum back to what it should be?
<Lynne>
(the way Opus uses it)
<durandal_1707>
Lynne: imagine there is noise in audio and also bass, using curve that approximate spectrum and reversing it (mirror it) and encoding it would give better compression ratio, in decoding case: one just reverse denominator and numerator to get same input audio when decoded
<durandal_1707>
at least this is how patent describes dvd-audio codec
<Lynne>
oh wow, mlp supports that?
<Lynne>
up to what order do the coeffs have to be?
<durandal_1707>
numerator + denominator <= 8
<Lynne>
how many coeffs?
<BBB>
if I want to export frame headers to users, should I be using the cbs infrastructure for that? e.g. in dav1d we export the frame hdr struct directly with the frame data itself, so that's quite different in terms of how things work
<Lynne>
if you do it directly from decoders, you don't need cbs, otherwise, yeah, with cbs you'll only need a few lines
<durandal_1707>
so coeff is get_bits(5) << get_bits(3)
<durandal_1707>
Lynne: our LPC gives FIR only
<durandal_1707>
so coeff is get_sbits(5) *(1 << get_bits(3))
<durandal_1707>
Lynne: how RDFT can give coefficients?
<Lynne>
durandal_1707: now that I think about it, does the codec make any guarantees about the filter needing to be stable?
<Lynne>
iir filters can explode easily
<Lynne>
I think given that you have a limited resolution anyway, you should just generate a bunch of coefficients known to be stable, and switch them during runtime based on how the signal looks like
<durandal_1707>
(2^5)*(2^3)*8*7
<durandal_1707>
14336
<durandal_1707>
14336 possible combinations if i got math right
<BBB>
so if I add code to frame decoding to include a sps/pps/vps/seqhdr/frmhdr... will people kill me?
<BBB>
like how dav1d does it
<durandal_1707>
not all of them useful
<durandal_1707>
BBB: #dav1d
<Lynne>
durandal_1707: I bet a lot of them are unstable, and a lot of them would have equal compression gains
<Lynne>
give it a go as an experiment, if it works, it can be expanded
<Lynne>
you can always add new coefficient presents known to be stable
<Lynne>
*and help with compression
<BBB>
durandal_1707: no, ffmpeg
<BBB>
I want ffmpeg to export frame/seqhds and xpss like dav1d does. ffmpeg feature. dav1d good
<BBB>
I code dav1d stuff in ffmpeg
<BBB>
so #ffmpeg
<BBB>
because dav1d idea = good idea
<BBB>
and I wnt ffmpeg to be full of good ideas also
<elenril>
BBB: your explanation sucks
<elenril>
very very badly
<elenril>
i have no idea what it is you want to do
<BBB>
hm... ok...
<elenril>
i have no idea what dav1d does, so it tells me nothing
<BBB>
ok, I apologize for that
<elenril>
clarity first, jokes second
<elenril>
if you actually want a serious reply
<elenril>
if not, carry on
<jamrial>
dav1d exports pointers to structs containing fields that represent every element in av1 frame headers and sequence headers
<BBB>
so, dav1d has Dav1dPicture, which is like AVFrame. in that, we have pointers to Dav1dSequenceHeader and Dav1dFrameHeader, which are what the tin says. I'm wondering if it would be ok to have something like that in ffmpeg's AVFrame to expose e.g. vps or pps, maybe as side-data
<jamrial>
so i guess he wants the same for AVFrame
<BBB>
I type slow, it seems. that ^^
<jamrial>
you, i'm just a man of few words :p
<elenril>
what's the use case?
<BBB>
e.g. write an analyzer for ffmpeg and know what frame header belongs to what AVFrame.
<elenril>
does it make much sense to do it as a part of decoding process?
<BBB>
mostly to not add additional overhead. we already do it anyway. that way we don't do it twice. but not an absolute requirement
<elenril>
you have to do a bunch of allocs and maybe memcpies to attach it to a frame
<jamrial>
if it's done as side data, it can be enabled conditionally
<jamrial>
like film grain and video enc params
<elenril>
yeah, I get that
<elenril>
the question is more - if it's about performance, then does it actually help you much?
<elenril>
and if it's about avoiding code duplication, then I'm wondering if an analyzer doesn't need to know so much about the bitstream that header parsing is trivial in comparison
<BBB>
you're probably right, yes
<BBB>
I wasn't gonna alloc/memcpy
<BBB>
I was gonna make them refcounted
<BBB>
but I agree it's irrelevant in terms of overall overhead, so we can ignore that part I think
<BBB>
it's mostly about what kind of interface you'd be ok with
<elenril>
to be clear - I'm not objecting if it's useful
<elenril>
parsed headers attached as side data are fine with me
<BBB>
ok... then a 2nd thing that will come up, the haeders are different per codec. so what would be a good way to expose that ... (de)serialization spec to the user
<BBB>
so assuming the frmhdr is struct bla { int is_frame_type; int is_b_frame; int num_refs; }; - I have 3 values at offset 0, 4 and 8 of type AV_OPT_TYPE_INT. is that something I could statically insert somewhere?
<jkqxz>
Export XML and add API to fetch the XML schema from the codec. Obviously.
<BBB>
right. let's vote. what I just said, or xml. you have two days to vote
<BBB>
go GA. I have no voting right so it's fair
<elenril>
do you want it to be a single "generic" struct for all codecs?
<BBB>
actually, isn't the meaning of the xml called something else?
<BBB>
no
<elenril>
does that make sense at all?
<BBB>
no, not at all
<elenril>
why do you care about serialization then?
<elenril>
serializatin is the bitstream, no?
<elenril>
+o
<BBB>
I'd like to display all codec-specific info in the UI
<BBB>
but in. way where I can add support for new codecs without changes to the application
<BBB>
ffmpeg-style
<elenril>
AVOptions are poor man's XML
<BBB>
it doesn't have to be exactly AVOptions, but something-like-that would suit the bill here
<elenril>
or rather poor man's XML schema
<BBB>
would that be ok?
<BBB>
schema! that's the thing, yes
<elenril>
I mean literally AVOptions
<elenril>
and I'm actually serious
<BBB>
hm...
<BBB>
I hadn't actually thought about that, but maybe you're right
<BBB>
ok, I can dig that, actually. need to think a bit but I think you may be right
<jkqxz>
Alternatively JSON.
<BBB>
so you're ok with that living somewhere statically in the AVCodec or similar?
<elenril>
sure
<elenril>
mkver will want it to be disableable, but otherwise why not
<mkver>
What are we talking about?
<elenril>
I've also considered AVOption-based side data serialization in the past
<elenril>
mkver: API for exporting parsed headers in side data
cone-686 has quit [Quit: transmission timeout]
<durandal_1707>
Lynne: i guess i can start with few preset types and once one of them is better than others try variants of that preset and then variants of that variant of preset
<durandal_1707>
but how to make those presets?
<durandal_1707>
lowshelf/highshelf of certain dB with cetral freq in middle?
<durandal_1707>
this is like making types for noise shaping curves
<haasn>
I'm still trying to figure out if there's a way we could ban AVCOL_SPC/RANGE_UNSPECIFIED
<haasn>
how would people feel about avfilter not supporting unspecified values here?
<BBB>
ok. so here's another question then. if I wanted to do a stream analyzer also, would you guys be ok if I added sth similar (auto-off, of course) for block data? it's a bit like AV_FRAME_DATA_MOTION_VECTORS but for everything
<haasn>
I mean it makes about as much sense as adding AV_PIX_FMT_UNKNOWn
<haasn>
and expecting filters to deal with it
<elenril>
BBB: but how can you add it when we already have that
<BBB>
mvs has no concept of interintrablendtype or warpcontext or palette values and indices
<BBB>
I mean everything
<BBB>
including all the stupid stuff
<BBB>
not just av1, also hevc/vvc etc.
<JEEB>
AV_FRAME_DATA_CBS_EXPORT
<BBB>
cbs is frame-data, this is block-data. (or do you think they should be shared?)
<elenril>
there's AVVideoEncParams
<JEEB>
and that would then have "CBS structures" list or so
<BBB>
there's also a possibility of having multiple of these per frame, e.g. one for block data and another for cdef indices or sao config or looprestoration config
<JEEB>
BBB: long term we probably should just have one type of side data :D but this was mostly just a naming example
<elenril>
also, how will you protect yourself from assassination by the analyzer mafia
<BBB>
each of which have a different resolution and are overlapping
<BBB>
wdym. i *am* the analyzer mafia
<JEEB>
BBB: the side data should contain the list of all the exposed structures
<BBB>
I'm assasinating by embracing, extending and then winning
<JEEB>
in theory you could have multiple, but it sounds initially better that for each CBS'd packet you get a "result" side data
<elenril>
I mean the people who charge 10k per month for a license
<JEEB>
and that contains a set of CBS results
<elenril>
or whatever the actual prices are
<BBB>
I'll take their wrath. move on buddies
<BBB>
nothing for you to worry about
<JEEB>
elenril: those things that don't even check if a PES packet's contents match the timing of the packets?
* JEEB
has had 15 frame DTS/PTS differences where the contents has 32 coded pictures
<elenril>
dunno, never used any of these
<JEEB>
and apparently all analyzers were a-OK
<elenril>
I just heard about them in some talk
<BBB>
(I'm serious there. competition here is sorely needed. analyzers suck ass and are indeed super-expensive)
<elenril>
probably at VDD
<elenril>
probably by BBB
<BBB>
yes
<BBB>
I showed mine, which also sucks. we're trying to fix that :)
<elenril>
GUI programs all suck
<elenril>
oh, I know
<elenril>
I'll integrate an analyzer into my email client
<durandal_1707>
use xxd
<elenril>
>I don't even see the code anymore
<elenril>
>here's an SPS, that's a slice header
<BBB>
but I do believe that having an appropriate interface for that in ffmpeg would be helpful
<BBB>
when properly accessible and effectively semi-scriptable like cbs trace_headers
<JEEB>
yea
<JEEB>
I have had that same idea of having trace_headers-like BSF put a list of "things that you generate via CBS", which an analyzer can then utilize
<JEEB>
or even make the dumping of trace_headers no longer be just av_log
<elenril>
tbh I have doubts that it wouldn't be easier for the callers to just parse the stuff themselves
<elenril>
but don't let that discourage you
<durandal_1707>
write analyzer for ever codec in FFmpeg
<BBB>
parse the stuff... you mean have a bitstream decoder?
<BBB>
I don't disagree
<BBB>
it's more about having it in ffmpeg, yes
<durandal_1707>
you will get 2k different structures representing encoding bitstream
<BBB>
so that we don't have to worry about "which codecs do I support" or "how do I add bink support"
<BBB>
which is important
<elenril>
but we do have decoders already
<elenril>
the question is, can we export this to the users in a way they will actually find useful?
<JEEB>
durandal_1707: the idea is that it's something that an API client can iterate over
<JEEB>
like, in the worst case it's a string or key, value thing
<elenril>
and which will be less hassle for such a user to use than reimplementing the decoder themselves
<BBB>
elenril: that's the experiment. I agree if I can't do that, it shouldn't be merged
<durandal_1707>
JEEB: sure, write realy xml encoder
<elenril>
okay, go ahead then
<elenril>
have fun
<BBB>
just trying to make sure the starting point isn't total poo
<durandal_1707>
do not add new structures, instead use xml/dictionary thing
<JEEB>
durandal_1707: libxml2 is already in the code base, so no need to NIH
<BBB>
because then I have to write it twice :) well, 3x, since I already wrote it once and that's not mergeable :-p
<JEEB>
although XML is meh. maybe go with EBML? 8)
<elenril>
must mean you got extremely efficient at it
* JEEB
takes himself to the back of the barn
<durandal_1707>
this is more like database then dictionary
<elenril>
a database is like a fancy dictionary
<durandal_1707>
the kind where you define own structs fields and fill them
* JEEB
stares at his mac doing the 14.1 update for the second hour
* durandal_1707
bans all mac users here
<BBB>
we're the majority
<BBB>
try us
* JEEB
only started getting macs to test OSS on them
<durandal_1707>
we do not need mac users, mac users are self-loved narcisist psychos
<BBB>
I love you too kostya
<elenril>
i wouldn't go so far
<elenril>
but strictly speaking there is no proof apple users have souls
lexano has quit [Ping timeout: 240 seconds]
<kierank>
durandal_1707: only winxp?
<kierank>
or win7?
<BBB>
and would it be ok if I add a dummy "type" string to things like "blockinfo" or "header" to be able to distinguish vps/sps/pps or seqhdr/frmhdr or blockdata/cdefdata/lrdata/saodata?
<BBB>
it's random but at least makes it somewhat easy to distinguish which one is which in the multiple siddatas of each type
darkapex has quit [Ping timeout: 246 seconds]
<BBB>
I'll just try it and see who objects :D
<elenril>
BBB: do you plan to have the same side data type for everything or what
<jkqxz>
I find it difficult to imagine how an external-to-ffmpeg analyser wouldn't be a huge mess of "oh no I want this thing too, I'll add AV_FRAME_SIDE_DATA_BLOCK_METADATA_FOR_MY_ANALYSER_WHICH_NOONE_ELSE_CARES_ABOUT_42 so the decoder can give it to me".
<BBB>
elenril: yes
<courmisch>
while (index >= c->phase_count) {
<courmisch>
index -= c->phase_count;
<elenril>
that sounds painful
<courmisch>
}
<courmisch>
sample_index++;
<mindfreeze>
elenril: last i heard from for a multicodec license from a vendor after academic discount(50% off) was $25k
<BBB>
jkqxz: no no it would be something that is generally useful
<courmisch>
^^ did Euclid kill somebody's mom?
darkapex has joined #ffmpeg-devel
<BBB>
jkqxz: I'm specifically trying to make it not be like that. I mean, that's what I have now :D
<jkqxz>
Making the analyser inside ffmpeg seems much more sensible to me, since you can interrogate the internal structures to get whatever random thing you want as you realise you need it.
<BBB>
I'm trying to be a good boy here
<elenril>
mindfreeze: huh, not so far off
<elenril>
jkqxz: it must be an avfilter
<BBB>
yes, the analyzer interface would be in ffmpeg. the ui would be outside of course, but it would be cli-accessible like trace_headers
<elenril>
it draws the gui on the frame, then you can play it with any video player
<durandal_1707>
kierank: putin likes ms and windows same like you
<BBB>
dunno about avfilter. I'll leave that for a gsoc student
<elenril>
blasphemy
<mindfreeze>
BBB: are you saying you making backend of your analyzer oss:P
<BBB>
maybe, something like that, a bit, sort of
<BBB>
but not sucky
___nick___ has quit [Ping timeout: 252 seconds]
<durandal_1707>
i'm all for this this backend, if properly and non-intrusively done.
<durandal_1707>
Lynne: how to get those first few presets and by what heuristic than to make further presets (more complicated) to try?
kurosu has joined #ffmpeg-devel
<durandal_1707>
patent mentions some of them using 2/2 coefficients
<durandal_1707>
only 2/2
lexano has joined #ffmpeg-devel
<courmisch>
is PSHUFB Mordorlang for VTBL?
<JEEB>
I read shuffling there
<kierank>
courmisch: yes
<wbs>
except pshufb is kinda fast afaik, while vtbl generally is slow-ish
<courmisch>
it should randomise the byte order, so the name would actually make sense
<Lynne>
durandal_1707: most audio is going to have a laplacian frequency distribution, so that's a good place to start
<Lynne>
you should write something to bruteforce a good combination and make sure the filter doesn't explode
<durandal_1707>
Lynne: but audio spectrum changes in every frame
<durandal_1707>
once is all bass, next is all treble
<BBB>
mordorlang
<durandal_1707>
use rust
Krowl has joined #ffmpeg-devel
<j-b>
good morning folks
<j-b>
Hello durandal_1707, Master!
tufei_ has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
<durandal_1707>
j-b: chief President on bridge!
<kierank>
durandal_1707: master chief
<durandal_1707>
kierank: who?
<kierank>
halo
<Lynne>
durandal_1707: what does the fraunhofer/dobly encoders put as the coefficients?
<Lynne>
do they vary, or do they skip that feature?
<durandal_1707>
Lynne: use various combinations, only FIR, IIR with different number of numberators/denominators
<durandal_1707>
IIR mostly help with high dynamic range and with higher sample rates
<durandal_1707>
Lynne: lol, found newer patent that expires in 2033, about same coding
Krowl has quit [Read error: Connection reset by peer]
MisterMinister has quit [Ping timeout: 245 seconds]
qeed_ has joined #ffmpeg-devel
<Lynne>
"After many years of discussions by different standards bodies, in November 2022, at the 27th General Conference on Weights and Measures, it was decided to abandon the leap second by or before 2035."
<Lynne>
finally, but I bet they'll add a leap second in 2033 just out of spite
qeed has quit [Ping timeout: 255 seconds]
<Lynne>
at least they decided on something, the european union decided to give a serious talk about getting rid of DST before they completely stopped