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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
lexano has quit [Remote host closed the connection]
<Lynne>
mkver: yeah
<Lynne>
I had just woken up -_-
<Lynne>
I don't think anyone will go after us for some low-res 5 second footage of lotr in realvideo 8 though
<Lynne>
knowing the format, its probably bitrotten to all but our decoders, so they'll likely decode garbage out anyway
<Lynne>
"its realvideo, must be porn", they'll say, "with full-screen censoring"
lexano has joined #ffmpeg-devel
Livio has quit [Ping timeout: 268 seconds]
Livio has joined #ffmpeg-devel
<haasn>
Lynne: did you hear anything from the two gsoc students you are mentoring?
<Lynne>
yup, I keep in touch with Petro pretty much every day (via matrix)
<Lynne>
IndecisiveTurtle seems busy with exams, but the coding period starts in 5 days or so
Luna_Usagi_ has left #ffmpeg-devel [Going down the hole]
<haasn>
okay, good
<haasn>
let me know if there's anything I should look at
<cone-108>
ffmpeg Nuo Mi master:1289da924445: avcodec/vvcdec: misc, inter, use is_chroma instead of is_luma
<cone-108>
ffmpeg Nuo Mi master:bc099afc8d76: avcodec/vvcdec: refact, unify {luma, chroma}_mc to mc
<cone-108>
ffmpeg Nuo Mi master:6769fe1614e6: avcodec/vvcdec: refact, unify {luma, chroma}_mc_uni to mc_uni
<cone-108>
ffmpeg Nuo Mi master:84a93d91d17d: avcodec/vvcdec: refact, unify {luma, chroma}_mc_bi to mc_bi
<cone-108>
ffmpeg Nuo Mi master:875fa9692cb8: avcodec/vvcdec: misc, remove unused EMULATED_EDGE_{LUMA, CHROMA}, EMULATED_EDGE_DMVR_{LUAM, CHROMA}
<cone-108>
ffmpeg Nuo Mi master:44bbafb69fa6: avcodec/vvcdec: refact, unify pred_regular_{luma, chroma} to pred_regular
<cone-108>
ffmpeg Nuo Mi master:66c6bee061d3: avcodec/vvcdec: refact out VVCRefPic from RefPicList
<cone-108>
ffmpeg Nuo Mi master:08ad51ece660: avcodec/vvcdec: refact, pred_get_refs return VVCRefPic instead of VVCFrame
<cone-108>
ffmpeg Nuo Mi master:aa8d5c6e7ed3: avcodec/vvcdec: add vvc inter filters for RPR
<cone-108>
ffmpeg Nuo Mi master:e70225e0a887: avcodec/vvcdec: emulated_edge, use reference frame's sps and pps
<cone-108>
ffmpeg Nuo Mi master:deda59a9964f: avcodec/vvcdec: add RPR dsp
<cone-108>
ffmpeg Nuo Mi master:77acd0a0dd93: avcodec/vvcdec: inter, wait reference with a different resolution
<cone-108>
ffmpeg Nuo Mi master:ac4575594f37: avcodec/vvcdec: fix dmvr, bdof, cb_prof for RPR
<cone-108>
ffmpeg Nuo Mi master:77d971c34828: avcodec/vvcdec: refact out luma_prof from luma_prof_bi
<cone-108>
ffmpeg Nuo Mi master:7904ec2d34a4: avcodec/vvcdec: refact, remove hf_idx and vf_idx from mc_xxx's param list
<cone-108>
ffmpeg Nuo Mi master:cae0b01282d0: avcodec/vvcdec: increase edge_emu_buffer for RPR
<cone-108>
ffmpeg Nuo Mi master:1b33c9a50a90: avcodec/vvcdec: support Reference Picture Resampling
<cone-108>
ffmpeg Nuo Mi master:b8eb8b4f1964: Changelog: add DVB compatible information for VVC decoder
<cone-108>
ffmpeg Martin Storsjö master:a9dc7dd7fde3: checkasm: vvc_alf: Limit benchmarking to a reasonable subset of functions
<Lynne>
haasn: petro is dealing with adding hwaccel support for diracdec, he just finished with it and is now going into the shaders
<BBB>
courmisch: I find "Nack all VVC checksam from my behalf." a bit unnecessary, we can be nice about this, it's not like it's on purpose...
<BBB>
I wonder if a general checkasm runtime-adjustable bench iteration-count multiplier would be useful? so if you really want to bench everything (which may or may not be ideal), you could add a 0.1 count multiplier to make it faster. Gramner, wbs, wdyt?
<wbs>
BBB: jdek suggested a runtime parameter for choosing the absolute number of iterations recently
<BBB>
right, that would be fine also
<wbs>
(as some functions may require more or less iterations to be benched reasonably)
<BBB>
I agree it's not sper-useful for individual function tuning, probably the opposite. but for what courmisch was doing, a lower bench count should be accptable
markh has quit [Ping timeout: 268 seconds]
mark4o has joined #ffmpeg-devel
mark4o is now known as markh
<Lynne>
rather than a multiplier, I've found that 1 << N exponentiation works best
<Gramner>
yeah a command line argument seems fine
<BBB>
"By the way, does anybody know if we could skip benchmarking C functions for which zero optimisations are available" didn't we have a solution for that in dav1d already?
<jdek>
Lynne: that's fine too, honestly I don't really care about the specifics. I just want to be able to specify some value without having to rebuild checkasm
IndecisiveTurtle has joined #ffmpeg-devel
<BBB>
I remember there used to be a --bench-c argument or so
<jdek>
if we have a function which requires a lot more samples than others and are also modifying this function, it could end up that the sample count needs to be changed if the implementation does. Sure you could do it with metrics but you would essentially need to rerun the metrics every time the function has a significant change
<BBB>
jdek: it's fine
<BBB>
it's not ideal. it can probably even be improved
<BBB>
but it's better than before
<BBB>
ergo: it's fine
<jdek>
can swap the iterator to uint64_t as well but I'll do that on push if there are no further comments since it's trivial
<Lynne>
I would like a different metric than a simple runs argument
<Lynne>
setting runs exactly in decimal will be annoying
<Lynne>
especially because --bench reports timings on every power of two runs
<jdek>
Lynne: 'rejecting anything large enough to overflow' is kinda non-trivial no?
<BBB>
Lynne: huh? isn't that START/STOP_TIMER?
<BBB>
bench has a single output per function
<Lynne>
jdek: if (runs_ptwo > 31) exit(11)?
<jdek>
sure I guess
<BBB>
1<<31 overflows int :-p
<BBB>
but it's fine
<aleek>
hello guys! Just so you know, you forgot av_aes_free() for av_aes_alloc(), so when decrypting mpeg dash, the whole ffmpeg leaks like hell :D
<BBB>
can you send a patch or file a bug report for us to reproduce?
<jdek>
should be free'd in hls_close, probably need a sample
<jamrial>
there's no such thing as av_aes_free()
<Lynne>
jdek: if you repost it on the ml I'll lgtm it
<Lynne>
BBB: 1 << 31 doesn't overflow an int, there's still a bit left for the sign
<aleek>
sure, I'll send a bug report cause we're not sure where to free the context :)
<wbs>
Lynne: no, 1<<31 shifts the bit into the sign bit
<wbs>
also, as BBB said, "--bench reports timings on every power of
<wbs>
two" isn't true
<wbs>
that may be the case of the standalone fft test tool, that uses START/STOP_TIMER
<BBB>
aleek: I just checked also, afaics there's relevant free()s where needed, so please provide sample and commandline
<mkver>
Lynne, wbs: Shifting into the sign bit is UB. Use 1U<<31 instead
<BBB>
indeed :)
<Lynne>
really? gcc doesn't warn on 1 << 31, but warns on 1 << 32
<Lynne>
weird it wouldn't warn on shifting into the sign bit, but oh well, you learn something new every day about trusting compilers
<jamrial>
Lynne: maybe it's a -pedantic warning
<mkver>
Lynne: Yes. "If E1 has a signed
<mkver>
type and nonnegative value, and E1 × 2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined." (C11, 6.5.7 (4))
<mkver>
s/2E2/2^E2/
kurosu has joined #ffmpeg-devel
<Gramner>
BBB: the --bench-c paramater would just enable/disable printing of results. the actual measurement were always performed. this was kind of pointless so we removed it. by the time the c code is tested we don't know if there are any other implementations, so trying to skip the tests/benchs for c-only code would probably require a fair amount of changes
<wbs>
Gramner: you'd need to skip benching the first time around, and then bench both ref and "new" on the second round
<BBB>
ah I see, ok tnx
<courmisch>
BBB: and I take it that calling me a troll on the mailing list was not unnecessary, since it did not ellicit any comments from you, eh
<BBB>
did I call you a troll?
<BBB>
if I did, I apologize, I try to be nice
<courmisch>
I was called a troll, it was reported to CC, and nothing happened[3~
<BBB>
by me?
<courmisch>
I have had enough of the one-sided moral lessons
<jdek>
Lynne: oh i didnt change the main commit message, can fix on push if nothing else
<courmisch>
BBB: Why do you feel the need to pick on me now while you don't care when someone else behaves way worse? I have a history of being on the receiving end of double standards.
<courmisch>
and while I don't disagree that I was "not being nice", I think it's completely reasonable to refuse to add more tests to a suite that is already overloaded
<BBB>
no it is not
<courmisch>
When all is being said and done, nobody seemed to cared when jamrial was being "nice" about it.
<courmisch>
Well we can disagree, and you're welcome to fund and provide hardware in my stead.
<jamrial>
i what now?
<courmisch>
you complained "nicely" about VVC benchmarks being too heavy
<jamrial>
ah
<courmisch>
and you were completely ignored by everyone (myself included to be fair)
<kurosu>
wbs: I would expect VVC to be more complex than AV1 (maybe a coincindence, but the current patch set is for a feature not in AV1 or AV2). On the other hand, I have no idea how far along they are implementing the standard. In any case, I would be rather cautious about what is and what is not possible. Not sure eg the conformance bitstreams will exercice every possible combination of dimensions, but that might be a start.
<BBB>
kurosu: it's bench vs check
<courmisch>
kurosu: wbs is *not* disabling tests, only benchmarks
<BBB>
kurosu: we check all dimensions, but we don't necessarily (need to) bench them
<BBB>
exactly
<BBB>
dav1d is same, we check much more than we bench
<kurosu>
Ah ok, within the benchasm
<BBB>
yes
<kurosu>
Makes sense then
<kurosu>
That's the kind of things where you get drowned by the numbers, so too much detail is counterproductive anyway
<BBB>
right
<courmisch>
err, that's a mild way to put it
fsimonfc has joined #ffmpeg-devel
<courmisch>
my hardware literally overheated due to the excessive benchmarks
wyatt8750 has quit [Ping timeout: 268 seconds]
<courmisch>
well for one reason or another, it crashed hard, heat or not
<wbs>
on my machine, "checkasm --bench" took 22 minutes, where it used to take 33 seconds with vvc_alf disabled
fsimonfc has quit [Client Quit]
<jamrial>
courmisch: i mean, it should not overheat and crash at all in any such scenario...
Livio has quit [Ping timeout: 268 seconds]
<courmisch>
jamrial: yeah well call me when Linux is robust against overload
<BBB>
wbs: and after "a9dc7dd7fde3: checkasm: vvc_alf: Limit benchmarking to a reasonable subset of functions"?
<BBB>
wbs: I assume it's closer to 33 seconds again?
<wbs>
BBB: yes
<jamrial>
i just tried and it took 2m25s on a i7 12700k, on win64
<BBB>
courmisch: anything else to complain about that we should look at?
<jamrial>
vvc_alf alone is 6 seconds
<courmisch>
Ironically we being passive aggressive got the issue fixed much faster than jamrial, much as I expected
<courmisch>
s/we/me/
<BBB>
I'm trying to be nice and give you the benefit of the doubt, don't push it
<courmisch>
I don't deny being not nice, I said so twice already
<BBB>
then fix it
<BBB>
you're worse than my teenage kid
<BBB>
I expect better from a professional like you
wyatt8740 has joined #ffmpeg-devel
<BBB>
you don't have to like me (or anyone here), but you can at least try being occaisonally polite
<courmisch>
I fail to see where I was being impolite.
<courmisch>
Although you're basically insulting me, so that's pretty rich
<courmisch>
-> "you're worse than my teenage kid"
<BBB>
you're being unnecessarily passive aggressive, as you admitted yourself: "[10:18:10] <courmisch> Ironically we being passive aggressive got the issue fixed much faster than jamrial, much as I expected". I also asked you earlier to not be unnecessarily rude on the mailinglist with things like "Nack all VVC checksam from my behalf".
<BBB>
I'm asking you to tone it down a bit and keep it polite
<BBB>
so rather than retorting me - again, exactly like my teenage kid does on a regular basis - with "[10:18:50] <courmisch> I don't deny being not nice, I said so twice already", I'm asking you to stop admitting that you're not nice and instead try being nice
<courmisch>
I was being deliberately passive aggression, and sadly but expectedly it seems to have been necessary and sufficient to solving my problem.
<courmisch>
s/aggression/aggressive/
<courmisch>
As we can all see that the nice approach had already been tried and achieved nothing
Traneptora has quit [Quit: Quit]
<courmisch>
BBB: you're confusing politeness and kindness here
<courmisch>
now bench takes 202 seconds here, so wbs solved it
<BBB>
in situations like this, I would teach my kid to say "thank you"
<courmisch>
tack så mycket actually
<courmisch>
it's going to take a while to get it from the K230 still though. My guess is 40 minutes or so
<BBB>
<3
<BBB>
let's get back to work now
<courmisch>
no way, I'm in EEST and working hours are over
wyatt8740 has quit [Ping timeout: 240 seconds]
wyatt8740 has joined #ffmpeg-devel
<courmisch>
is it intended that we have a lot of AV_GCC_VERSION_AT_LEAST(3, still?
<courmisch>
presumably __GNUC__ would work just as well
<cone-108>
ffmpeg J. Dekker master:b1adf6d1d02c: checkasm: add runs argument to adjust during bench
<courmisch>
okay, 1800s sharp for K230, so my recollection was right
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
I take it back - definitely not the same cores, the f3 has had improvements in parts outside of vectors
<courmisch>
well, they might simply run at different frequencies
<Lynne>
I thought this was with rdcycle, so it gives you clocks?
AbleBacon has joined #ffmpeg-devel
<courmisch>
Lynne: RDCYCLE is blanked on F3, so that's RDTIME
<Lynne>
ah, ok
<Lynne>
sad, those things must clock down pretty aggressively to get by on a few watts at most, and IIRC performance counters are optional (and maybe even proprietary/unstandardized, I can't remember)
System_Error has quit [Remote host closed the connection]
<courmisch>
Lynne: pretty sure it's to avoid side channel attacks against crypto, not power management
<cone-108>
ffmpeg Lynne master:d43e1238374e: checkasm: print bench runs when benchmarking
<Lynne>
err, the downclocking, or the lack of standard performance counters?
<courmisch>
the lack of cycle counter
<courmisch>
or rather the inaccessibility
<Lynne>
if they're privileged, shouldn't that at least make them secure-er?
<Lynne>
or are they betting (correctly) that someone will run something important as root?
<courmisch>
I haven't looked at the system sw architecture
<courmisch>
I doubt that it's possible for the kernel to enable them per process, it's probably a machine mode setting
<courmisch>
not sure though
<courmisch>
Lynne: and you can boot F3 from TF. In fact, vendor armbian does not support the eMMC ...
<cone-108>
ffmpeg Martin Storsjö master:6093367147b7: checkasm: h264dsp: Avoid out of buffer writes when benchmarking
merbanan has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
jarthur has joined #ffmpeg-devel
jarthur has quit [Quit: jarthur]
jarthur has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
Krowl has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
DevinDev has joined #ffmpeg-devel
<DevinDev>
Hello
<DevinDev>
I have some questions regarding a currently unsupported video container.
<DevinDev>
At least thats what I assume the problem is
<DevinDev>
The file format I was hoping to use with ffmpeg is called DPG and is used by The Nintendo DS.
<JEEB>
yea, start with trying to figure out the structure of the file format :)
<JEEB>
possible header structure, packet structure etc
<JEEB>
multimedia.cx wiki at least doesn't have info on it, since the only dot-dpg there is a german game format
<DevinDev>
Ill see what I can do. I know that it uses mpeg1 and mp2 and that audio header seems to be missing at least according to ffmpeg as is.
<JEEB>
I would expect that if it's a popular enough format on the platform, someone has documented the format
<DevinDev>
I found the source code for the existing video converter would it be safe to use that as reference? Seems open source.
<frankplow>
Anyone have advice for getting pkgconfig working on MSYS2? I have the pkgconf and libxml2-devel MSYS2 packages installed. The configure script warns cl : Command line warning D9002 : ignoring unknown option '-libpath:C:/msys64/usr/lib', then it fails to find the .lib.
<JEEB>
well it does have documentation on the format in the header file
<DevinDev>
Nice
kurosu has quit [Quit: Connection closed for inactivity]
<JEEB>
frankplow: I've had pkg-config and pkgconf work on msys2, but MSVC can be a special snowflake
<JEEB>
you might need to make sure the linker and compiler flags are passed in whatever manner it wants
<JEEB>
sometimes it wants / instead of - etc. I think pkgconf even had some support for MSVC specifically?
<JEEB>
I also know msys2's shell will do fun stuff like attempting to convert some things like slashes in certain locations... but yea, when you get tired - try using clang instead of cl, since it works with the MS SDK just fine
<frankplow>
Yeah MSVC wants /LIBPATH not -libpath. This is particularly a pain as it's a CI machine so can't poke around. Want to test MSVC so clang isn't an option as well.
<DevinDev>
When you have a moment if you could please tell me where would a nooby like me can start with making/moddifying a reader/writer for this format?
<JEEB>
DevinDev: start with building current FFmpeg master, if you have a shell, compiler and nasm (if you're on x86) then after cloning the repo, `mkdir -p le_build && cd le_build && ../configure` should give you a basic configuration successfully
<JEEB>
after that just `make -jx` where x is something like the amount of cores you have
<JEEB>
after that finishes, check out libavformat/yuv4mpegdec.c for example
<JEEB>
that's one of the basic format readers in avformat
<JEEB>
you can see its definition at the end of the file (FFInputFormat) which contains function pointer definitions like read_probe, read_header, read_packet and read_seek for example :)
<DevinDev>
Thank you very much
System_Error has quit [Remote host closed the connection]
<JEEB>
libavformat/allformats.c contains references to these, and Makefile has the reference to the file that it needs to get compiled :)
<DevinDev>
Nice
<compn>
frankplow, i'd spend time looking for a msys2 already packaged with pkg-config , all you have to do is unzip it
<compn>
frankplow, trying to debug windows / msys stuff is trouble :\
<JEEB>
msys2 has pkgconf already packaged
<JEEB>
it has a package manager and all :)
<JEEB>
his problem is that it's outputting not-caps stuff :P
<compn>
s/packaged/working
<JEEB>
or wait, could it be configure doing that
<JEEB>
> -L*) echo -libpath:${flag#-L} ;;
<JEEB>
frankplow: check that line out in FFmpeg's configure just out of interest :)
ccawley2011 has joined #ffmpeg-devel
<JEEB>
compn: I think it's working enough, it generally just outputs the options listed in the .pc file for linker flags and compiler flags
<JEEB>
and that's what it's doing
<JEEB>
then configure is rewriting stuff apparently for something that at some point worked with MSVC?
<courmisch>
eh, that is much better than I would expect from doubling the vlen
<compn>
dont @ me i'm not involved
<JEEB>
?
<JEEB>
you commented on it
<compn>
i'm running away
<courmisch>
frankplow: wouldn't it be simpler to build using MingW under WSL?
<cone-108>
ffmpeg Rémi Denis-Courmont master:d452db841025: lavc/vc1dsp: R-V V vc1_unescape_buffer
<JEEB>
compn: yeh, just noting that you're barking at the wrong dog there, pkgconf is not the component at fault
<jdek>
frankplow: isnt there a clang frontend for msvc
<JEEB>
there is a normie clang and clang_cl, which is clang with cl option syntax, I think?
<compn>
JEEB, feel free to zip up your msys2 ffmpeg build enviro so people dont have to reinvent the wheel. they can just download and unzip and run
<compn>
dockers and virtual machines, everywhere
<JEEB>
the FFmpeg configure is literally rewriting linker flags supposedly for msvc, yet that is not working for frankplow :P
<JEEB>
so I pointed him towards the fact that such line exists
compn has left #ffmpeg-devel [Leaving]
<courmisch>
hawaiiantel.net
<courmisch>
hmmmmmm
<JEEB>
that was really weird, I thought I was civil enough and just wanted to point out that it was not pkgconf that was the problem at hand here
<JEEB>
oh well
<JEEB>
courmisch: even msys2 mingw-w64 compiler or heck - even the clang using MS SDK would be simpler
<JEEB>
frankplow has chosen the fun ride of trying to utilize msvc for a non-basic build
Livio has joined #ffmpeg-devel
<courmisch>
Not my definition of fun,
mkver has quit [Ping timeout: 264 seconds]
<cone-108>
ffmpeg Rémi Denis-Courmont master:7591eb4055df: Revert "lavc/sbrdsp: R-V V neg_odd_64"
<frankplow>
courmisch: Could well be. I've had a trivial configuration working on this runner for some time but trying to add this has me pulling my hair out.
<jdek>
clang exposes a cl.exe interface not the other way around
<cone-108>
ffmpeg sunyuechi master:0c1304ae11b0: lavc/vp9dsp: R-V V mc avg
System_Error has joined #ffmpeg-devel
<JEEB>
frankplow: I hope you noticed my mention that configure script has the rewrite from -Lstuff to -libpath
<JEEB>
so if it's just caps vs non-caps, modifying that should help
<frankplow>
Yeah, just tried changing it, job is running now.
<courmisch>
MUST... RESIST... REVECTORITIS
<Lynne>
hey, you just got a new toy to play with, surely you're not happy just seeing it sit there running suboptimal code?
<courmisch>
Lynne: not good manners to revector code while someone else has pending patches on the same
<courmisch>
so I have a, err, interesting question
<Lynne>
"when are you working on the FFT asm"?
<courmisch>
how do I have a static variable in each fflib, without breaking static linking
<Lynne>
a static variable with the same name?
<Lynne>
or do you want a shared variable?
<JEEB>
there was a way where for static you only have one definition, and for shared the thing can be defined in both
<courmisch>
Lynne: an extern hidden variable, yes
<Lynne>
av_ or avpriv_ prefix
<courmisch>
that will cause dup symbols when linking statically no?
<JEEB>
SHLIBOBJs "objects duplicated from other libraries for shared builds"
<JEEB>
so you have a .c file which includes the same thing from wherever the source of truth is
<courmisch>
or actually, one symbol should be picked, but it depends how the .a files are linked in
<courmisch>
oh I see, okay
<JEEB>
see libavformat/ac3_channel_layout_tab.c for example, which is just a #include of the avcodec thing
<JEEB>
and with SHLIBOBJS it gets compiled into avformat conditionally in the shared lib case
<JEEB>
vOv
<courmisch>
SHLIBOJBS for dyn linking and STLIBOBJS for static linking ?
<JEEB>
seems like it yes
<JEEB>
(I only remember this stuff since I recall once doing this stuff to share certain definitions between avformat and avcodec)
<frankplow>
JEEB: No dice. I think perhaps because /LIBPATH is a flag for the linker it needs to come after a /link flag?
<JEEB>
also as a really basic question: are you sure link.exe you're calling is the linker and not msys2 link.exe :D
* Sean_McG
peeks in
<frankplow>
Idk, really annoying not having an interactive shell here
Krowl has joined #ffmpeg-devel
Livio has quit [Ping timeout: 264 seconds]
<BBB>
jkqxz: ping
<jkqxz>
Pong.
<BBB>
can I ask you a few avm questions?
<jkqxz>
Sure.
<BBB>
if I'm looking at the CTC presets, what partition structures does this search?
<BBB>
and which of these are recursive?
<BBB>
it seems like there's a *lot* of partitions and it searches everything (which I guess is good), but it also seems like almost all are recursive (which is meh), and there is no caching of results (which is kinda shit)
<BBB>
I'm trying to see how much I got right in that sentence (if any)
ngaullie has joined #ffmpeg-devel
<jkqxz>
I am not particularly familiar with the function of AVM, but I know it has to do a lot of pruning to avoid ludicrous runtime.
<BBB>
and I assume that is disabled at cpu-used=0?
<jkqxz>
Partitions are horizontal, vertical, H-split in both orientations, 1:4:2:1 in either direction and orientation. All are recursive, though some cases are banned.
<BBB>
the "all are recursive" is indeed what I'm seeing also, and that is pretty creepy
<BBB>
in the "holy shit this is very slow" kind of way
ngaullier has quit [Ping timeout: 252 seconds]
<JEEB>
sounds like research code base
<jkqxz>
No, some pruning is always enabled because it wouldn't be usable at all without it.
<BBB>
I guess we over-use the term "exponential complexity explosion" pretty freely, which means when it actually happens, nobody cares
<jkqxz>
The CTC settings take something like two weeks for the largest 130-frame sequence.
<BBB>
the boy who cried wolf
<BBB>
hm...
<jkqxz>
A blistering 0.0001 fps.
<BBB>
I was calculating pixels per second earlier
<BBB>
and I got to 0.1px/sec I think? in a local test
<JEEB>
reminds me of encoding some stuff with the HM reference encoder on university's c2d workstations back in the day
<JEEB>
I think I achieved a speed of like 1 frame per minute
<JEEB>
(I think this was not even HD content back then)
<BBB>
although 2 weeks is more like 0.001px/sec
<jkqxz>
0.1 sounds too slow? I think that's ~800 pixels/second.
<BBB>
1.5*130*3840*2160=1.6billion
<BBB>
in 1.2 million seconds
<BBB>
so ~1kpx/sec, yes
<BBB>
if I separate luma and chroma :) maybe a bit cheaty
<BBB>
it's actually (no joke) 1337
<BBB>
I think someone is pulling a prank on me here
<BBB>
1.5*130*3840*2160/(2*7*24*60*60)=1337.14...
<wbs>
is AVM a continuation of libaom, but for av2 research?
<jkqxz>
Yes.
<BtbN>
Well, that's a fun name collision
<BBB>
jkqxz: I assume people are already working on optimizing the partition search? seems that's the obvious place to go, at first
<jkqxz>
I would definitely not assume that research people work on sensible things.
<BBB>
:]
<JEEB>
"optimization is left to the production implementations"
<BBB>
ok thank you for the insight
<jkqxz>
We promise that people will be able to implement an 8K60 encoder in hardware, because hardware is totally seven orders of magnitude faster than the useless CPUs this is running on.
<Lynne>
to fansubbers, 0.3 frames a second was considered acceptable
<JEEB>
yea, although I think I was closer to 0.6fps :)
<Lynne>
I'm sure that's not the reason why fansubbing is not as alive anymore
compn has joined #ffmpeg-devel
<BBB>
"Partitions are horizontal, vertical, H-split in both orientations, 1:4:2:1 in either direction and orientation. All are recursive, though some cases are banned." also where is regular split?
<JEEB>
or well, my "this is quick enough for background encoding" limit
<JEEB>
nowadays I seem to be quite a bit less patient though ^^;
<jkqxz>
You do horizontal then vertical, or the other way around. Also you want to search both because they will code the blocks in a different order and one might be better than the other in the entropy coding!
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<BBB>
oh I see
<BBB>
oh boy
<BBB>
uhm
<BBB>
right
<BBB>
o_O
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
I wish monty's modelling work was continued, it would have set a precedence to create and maintain accurate weights that let you find the distortion of a block with a few lookups and arithmetic ops
Krowl has joined #ffmpeg-devel
ngaullie has quit [Ping timeout: 240 seconds]
Krowl has quit [Read error: Connection reset by peer]
shadowless has quit [Ping timeout: 255 seconds]
shadowless has joined #ffmpeg-devel
<frankplow>
Managed to work out a couple problems: 1. FFmpeg seems to use a non-standard include path libxml2/libxml/xmlversion.h, as opposed to the more typical libxml/xmlversion.h. It works out fine most of the time because other included libraries are likely to include the parent of that libxml2 folder, but I think breaks configurations where libxml2 is the only library.
cubicibo has joined #ffmpeg-devel
<frankplow>
Then 2. is that -l* is always translated to *.lib for MSVC, but in fact I have libxml2.dll.a
<JEEB>
.dll.a is mingw-specific I think? so I guess you built xml2 with mingw and then are utilizing it from msvc? but cool that it works
MikhailAMD has quit [Read error: Connection reset by peer]
MikhailAMD has joined #ffmpeg-devel
<nevcairiel>
yeah .dll.a is not a thing in the msvc ecosystem
cone-108 has quit [Quit: transmission timeout]
System_Error has quit [Remote host closed the connection]