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 7.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<psykose>
but does it add new symbols the plugins might use :P
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
feiwan12 has quit [Remote host closed the connection]
feiwan12 has joined #ffmpeg-devel
feiwan13 has joined #ffmpeg-devel
feiwan12 has quit [Remote host closed the connection]
feiwan13 has quit [Client Quit]
feiwan1 has joined #ffmpeg-devel
feiwan1 has quit [Changing host]
feiwan1 has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
q66 has quit [Ping timeout: 268 seconds]
feiwan1 has quit [Ping timeout: 256 seconds]
feiwan1 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
_av500_ is now known as av500
signalhunter has quit [Read error: Connection reset by peer]
signalhunter has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<kurosu>
courmisch: re: "fuse multiply-adds", I like seeing improvement numbers in any SIMD commit, even more so when it's an optimization. Could be binary size or checkasm numbers
<courmisch>
kurosu: I would have made them if checkasm looped short functions to get reasonable resolution
<courmisch>
kurosu: but it doesn't and the numbers are too small to see the difference
<courmisch>
I can try to get cycle count on the older board, but it fluctuates
<kurosu>
What do you mean, resolution? Of the timer? And/or, would increasing the number of iterations, or the length of the data processed, alleviate this?
<kurosu>
I don't know the defaults in dav1d, but it was too low, and I remember increasing the log2 by 4+ to make it somewhat more reliable
<kurosu>
(not the same than ffmpeg's, but I can imagine it similarly affected)
<kurosu>
afflicted, really
<courmisch>
kurosu: timer resolution is too low, so we would need to iterate the functions to get reasonable metricd
<kurosu>
Thanks, Ah, so my first interpretation. What a pity.
ngaullier has joined #ffmpeg-devel
michaelni has quit [Ping timeout: 268 seconds]
feiwan1 has quit [Ping timeout: 272 seconds]
feiwan1 has joined #ffmpeg-devel
tufei_ has quit [Ping timeout: 260 seconds]
michaelni has joined #ffmpeg-devel
<elenril>
Marth64: why json?
Krowl has joined #ffmpeg-devel
q66 has joined #ffmpeg-devel
ngaullier has quit [Read error: Connection reset by peer]
feiwan1 has quit [Ping timeout: 240 seconds]
feiwan1 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
IndecisiveTurtle has quit [Ping timeout: 268 seconds]
rossy has quit [Remote host closed the connection]
<ramiro>
kurosu: thank you for checking. I would have preferred no clipping too, but oh, well...
rossy has joined #ffmpeg-devel
unlord has quit [Ping timeout: 268 seconds]
unlord has joined #ffmpeg-devel
<elenril>
jamrial: did you see the mov heif rotation patch?
<jamrial>
elenril: no, but i just found it
<jamrial>
elenril: crazy thought (or not?): stream group side data, so we can insert a displaymatrix side data entry for this :p
<elenril>
stream group codecpar?
<jamrial>
elenril: no, i remember you disliked that when i first implemented it
<jamrial>
so just pointer and size fields for side data
Krowl has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
<IndecisiveTurtle>
Lynne: Hii again, as an update I cleaned up the haar shader over the weekend and switched it to output result to a coefficient buffer and converted all other buffers to BDA, except for some read only LUTs that are uniforms for now. Well now it's time to test before proper quant estimation, but hit a problem, some functions like ff_vk_get_pooled_buffer and ff_vk_qf_init require a hwctx ptr, but it's null here. Is this
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 268 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<elenril>
jamrial: it seems like the same thing to me
<elenril>
if it deserves coded side data, it deserves codec parameters
Krowl has joined #ffmpeg-devel
klaxa has quit [Read error: Connection reset by peer]
<mkver>
Are the relevant people informed that checkasm-sw_yuv2rgb fails on loongarch, making patchwork red?
klaxa has joined #ffmpeg-devel
<jamrial>
elenril: codecpar has a lot of fields that don't belong here, like extradata
<elenril>
side data has a lot of type (the overwhelming majority of them) that don't belong here
<elenril>
that's kinda my point - side data is by definition associated with a coded stream
<elenril>
so is codec parameters
<elenril>
all the arguments for or against putting them in stream groups apply to both
<Marth64>
elenril: re:json, modern and easy to parse but open to ideas
<jamrial>
extradata is exclusively about the coded stream, whereas plenty of side data (including displaymatrix) apply to the final, decoded stream
<elenril>
Marth64: export a C struct that needs no parsing?
<elenril>
parsing is bad
<elenril>
jamrial: there is no "final decoded stream" in a general stream group
<jamrial>
the stream group is made up of several separate streams. no extradata of any kind would make sense in it
<courmisch>
kurosu: there your benchmarks
<jamrial>
elenril: there is for iamf and heif, at least
<Marth64>
elenril: but this is for other applications to consume. example, automation of extraction, GUI, or a player; for example I have a GUI in python. which can understand serialized c struct but ugly and hacky.
<Marth64>
maybe it can be an option
cone-224 has quit [Quit: transmission timeout]
<courmisch>
can I mess with h264_loop_filter.c?
<courmisch>
I take the lack of answers in the past 1 second as a yes
another| has quit [Remote host closed the connection]
<elenril>
jamrial: also by the same argument, plenty of fields in codecpar do apply to the final decoded stream
<elenril>
like dimensions
<jamrial>
yes, like dimensions and ch_layout
<jamrial>
which is why at first i added a codecpar field
<jamrial>
but it was either you or someone else that shut down that idea
<jamrial>
i guess it wasn't you after all :p
<elenril>
to be clear, I'm not arguing for codecpar
<elenril>
I'm saying it should be codecpar rather than just side data
<jamrial>
hence all the relevant fields in the group specific structs
<elenril>
but for this I'd rather keep it simple and go with just rotation
<jamrial>
imo, too late to add codecpar, since the group specific structs already have duplicate fields
<jamrial>
and ok, we can just go with the rotation field as in the patch
<elenril>
hang on, I'll dig out my deprecator t-shirt
<elenril>
Marth64: we are a c library, so I'd say we should export a C API
<elenril>
and leave things like serializing things to strings to our callers
<jamrial>
elenril: i'm sure people will love seeing deprecation warnings about fields added mere months ago :p
<elenril>
any GUI in python already has to do some FFI, this would not be a change
<elenril>
jamrial: we've not been deprecating enough recently, I'm sure distro maintainers are getting complacent
<Marth64>
elenril: I will have to think of an agnostic data structure then to do this for bluray later too, similar concept
<jamrial>
they are still dealing with the fallout of the removal of avframe->{channels,channel_layout}
<elenril>
Marth64: you have to define it for json anyway
<Marth64>
then possibly serialization can be delegated to ffprobe or ffi caller like you said
<Marth64>
i have it defined but just within confines of dvd
<Marth64>
its basically title, chapters, pointer to title, some AVStream info
<elenril>
(not directly, but generally re: string-based APIs are evil)
<Marth64>
really I would have liked to project each title in the disc as an AVProgram in this probing state but that seemed weird. however in doing so naturally ffprobe can serialize the data as well
<Daemon404>
elenril, that's why all my apis only take and return void&
<Daemon404>
er void*
<elenril>
Daemon404: I see you're an E17 connoisseur
<Daemon404>
literally the project iw as thinking of
<ramiro>
Traneptora: regarding 7894904 and c7a57b0, there seem to be a typo in the chunk name (mDCv vs mDVc). https://www.w3.org/TR/png-3/ has the typo as well. do you have any samples from the wild with this chunk, or only what ffmpeg generate?
<Traneptora>
ramiro: mastering display color volume
microchip__ has joined #ffmpeg-devel
<Traneptora>
so mDCv is definitely what it is supposed to be
<elenril>
Daemon404: C could use a better type system though
<JEEB>
sure
<elenril>
like haskell
* elenril
runs away, for real this time
<Marth64>
java
<JEEB>
and I'd like cake, too
<Marth64>
:D
<Daemon404>
the only type you need is register
<elenril>
daring
<elenril>
brave, even
microchip_ has quit [Ping timeout: 268 seconds]
<Traneptora>
java type system has String[] as a subtype of Object[]. so you can do Object[] a = new String[1]; a[0] = new Object(); this crashes at runtime.
<Traneptora>
lovely type system
<elenril>
isn't the whole point of java to not crash?
<elenril>
in theory, at least
<Traneptora>
well it throws an exception that can be caught, the whole process doesn't crash
<Marth64>
the JVM itself is a brick generally. but there is some nasty code and "frameworks" out there
<ramiro>
Traneptora: the variables in png{dec,enc}.c are named mdvc, and so are the tags that are read/written.
<Traneptora>
ramiro: that's a typo. I'll send a patch to fix
<ramiro>
Traneptora: ok, thank you. I was getting confused there for a while :)
<ramiro>
but do you have samples from the wild with those chunks?
<Marth64>
in 2 hours i am actually giving a presentation on Java lol
<Traneptora>
ramiro: they're created by djxl but otherwise I don't know any software that writes them
<elenril>
Marth64: i hope its title starts with 'say no to'
<JEEB>
java felt way too verbose for me, but kotlin made writing JVM byte code less annoying
<Traneptora>
it also writes cLLi
<JEEB>
yea, clli and mdcv go together as "HDR10 metadata"
<Marth64>
elenril: rofl no, it's "Java is cool again" and i need to talk about new versions and features
<JEEB>
nice, so they finally added conformance files
<Daemon404>
yeah but not easy to find
<Marth64>
kotlin destroys java imo. but not everyone has accepted it outside of android
<Daemon404>
i see them referenced on w3c
<JEEB>
aye
microchip__ is now known as microchip_
<JEEB>
Marth64: java is cool for mainframe people now since they get to migrate from ye olden languages
<elenril>
Marth64: cool?
<elenril>
java is the new fortran
<Daemon404>
lol man... w3c list has dropbox urls
<Daemon404>
very professional
<ramiro>
Traneptora: thanks, I'll check djxl out
<Marth64>
Java 18+ is game changer compared to the old stuff
<Marth64>
still not Kotlin but absolutely ahead
<ramiro>
Daemon404: thank you
<Traneptora>
Marth64: what happened in 18
<elenril>
sounds nsfw
<Traneptora>
java is nsfw
<elenril>
then again people tell me how modern fortran is full of hip new features
<JEEB>
ebin
<Marth64>
Record types and some desperately needed shortcuts like Map.of() which come before 18 i believe but after 8
<Marth64>
they also removed some junk modules
<elenril>
thardin: lavu/eval is clearly missing system()
AbleBacon has joined #ffmpeg-devel
<Marth64>
lists and maps are no longer horrifying to make
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
elvis_a_presley has joined #ffmpeg-devel
klaxa has quit [Read error: Connection reset by peer]
<courmisch>
in H.264's filter_mb_edge*() functions, why isn't tc0_table to tc part of the ASM? looks very vectorish to me and we end up spilling the array just to immediately load it back again
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
klaxa has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<pengvado>
probably was written before there were any good shuffle instructions, and just never revisited
<courmisch>
pengvado: I suppose it makes sense if vector size is 64-bit - exactly one coefficient per vector
<courmisch>
(one coeff per 4 pixel sample, 16-bit intermediate precision)
<courmisch>
but now changing the boundary to assembler is tricky, as there are so many different archs
<courmisch>
+ checkasm
Krowl has quit [Read error: Connection reset by peer]
Venemo has quit [Remote host closed the connection]
Sean_McG has joined #ffmpeg-devel
* Sean_McG
peeks in
<ramiro>
mkver: are any of the loongson folks here on irc?
<mkver>
Don't think so.
<AndrewSayers1>
Marth64: one big benefit of JSON is that it's self-documenting. If I'm writing a program that wraps ffmpeg and I see a big binary blob, how do I find the place you hid the explanation?
<Daemon404>
what ffmpeg/ffprove outputs and what the c api outputs are two different things.
AndrewSayers1 is now known as AndrewSayers
<ramiro>
AndrewSayers: self-documenting, except that you can't add comments to JSON :)
<AndrewSayers>
{"comment":"can too :P"}
<Marth64>
I still want json. It makes integration easy for quick jobs
<Marth64>
but I see the point of C structure exposure too. so will see a way to do both
<JEEB>
ffprobe is able to expose C structures as json
<JEEB>
so I'd probably do that, if it's exposing something like AVPrograms
<JEEB>
or chapters
<Marth64>
yeah that is my preference
<Marth64>
kinda awkward to fit a DVD structure into AVPrograms as is but i will study more
<JEEB>
yea if AVPrograms don't match, then other ways could be utilized
<JEEB>
I only mentioned them since you mentioned them :)
<Marth64>
JEEB: nw, definitely my doing. imagination led me there. I'll play with it
<Marth64>
but the broader feedback I agree with. present as a C structure and let callers like ffprobe serialize
<Marth64>
best of both worlds
blb has quit [Quit: brb]
Krowl has joined #ffmpeg-devel
<Marth64>
i want it to be flexible toward bluray and maybe other title/collection type storage formats down the road too
<Marth64>
for example list CD tracks down the road for CDDA
<JEEB>
CD tracks I think in other cases have matched against the concept of chapters
<Marth64>
ah i can see that
blb has joined #ffmpeg-devel
<Lynne>
IndecisiveTurtle: what command line do you use?
IndecisiveTurtle has quit [Remote host closed the connection]
<JEEB>
try not to utilize AVDicts in the C side unless it's literally a random mash-up of key=value pairs
<JEEB>
oh, input_options
<Marth64>
ya it would be, since format/demuxer can be anything in theory
<elenril>
looks suspicious
<elenril>
Marth64: maybe you could first define what it is you're trying to achieve
<elenril>
export multiple chapter sets?
<Marth64>
yeah, I'll write a scope statement. essentially: given a AV container X which then contains different "features" each with different streams, etc., provide a way to get a list of what's inside the container and the parameters for the demuxer to get to a particular "feature"
<Marth64>
in DVD or bluray case, a "feature" is a title
<Marth64>
so a player application can get this structure and let the user pick and choose which to play. or for example, you can list what's inside of a DVD before you ask the demuxer what to extract
<Marth64>
another potential example is maybe an M3U playlist, where each entry is also a feature
<Marth64>
but yeah I'll work on a better writeup here
<elenril>
my first reaction is that you're aiming too high with this
<elenril>
and generalizing something that does not generalize
<elenril>
it might be better to have a private AVOption that exports a list of titles
<Marth64>
that was my original example, confined to the demuxer, but I interpreted your feedback as suggested exposing as a C structure so I got creative and came up with this
<elenril>
or possibly see if the avdevice enumeration stuff couldn't be bent to this end
<elenril>
you can export a pointer to a C struct with an AVOption
<elenril>
it's not super clean, but possible
MetaNova has quit [Ping timeout: 260 seconds]
<elenril>
so I'm not saying it has to be super generic
<elenril>
(it can be, but only to the extent it's actually useful)
<Marth64>
ok, I get it better now. I think I'll take a step back and try to imagine this from the callee side. for example how would say, mpv get and process this data
<Marth64>
I think you're saying it's not necessary to be a high level AVxxx abstraction but it also isn't necessary to "fix" it to json
<Marth64>
if I understand better now
<elenril>
it can be an AVDVDTitleSet
<elenril>
or appropriately generalized to DVD/BD
<Marth64>
but if Blu-ray will be about the same, this is why I called it Feature
<elenril>
but I don't see how it generalizes beyond that
<elenril>
and your Feature seems going overboard with genericness
MetaNova has joined #ffmpeg-devel
<elenril>
afk
<Marth64>
yeah because it just allows wildcard format/input options
<Marth64>
kk..thanks for the feedback
<Marth64>
i'll iterate
Krowl has quit [Read error: Connection reset by peer]
Arsen has quit [Quit: Quit.]
IndecisiveTurtle has joined #ffmpeg-devel
Arsen has joined #ffmpeg-devel
Arsen is now known as Guest702
Guest702 has quit [Changing host]
Guest702 has joined #ffmpeg-devel
<courmisch>
looks to me that a lot of h264 C DSP functions for HDR are identical and replicated for all 4 bit depths :shrug:
Guest702 has quit [Quit: Quit.]
Arsen has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]