michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Livio has quit [Ping timeout: 264 seconds]
Livio has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
Livio has quit [Ping timeout: 252 seconds]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
iive has quit [Quit: They came for me...]
lexano has quit [Ping timeout: 256 seconds]
thilo has quit [Ping timeout: 264 seconds]
thilo has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
hamzah has joined #ffmpeg-devel
<cone-984>
ffmpeg James Almer master:aca7037e018d: tools/target_dec_fuzzer: force experimental flag for decoders that need it
Gramner has quit [Remote host closed the connection]
Gramner has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
jamrial has quit []
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
AbleBacon has quit [Read error: Connection reset by peer]
<aaabbb>
getting some memory corruption on the latest BtbN build, sometimes segfaults, sometimes "malloc(): corrupted top size", sometimes "invalid fastbin entry (free)". i'm going to find a miminal way to reproduce it then post it along with a stack trace
<aaabbb>
does not happen with a 2x1 grid, or if the source is testsrc rather than testsrc2, or if the scale is even it seems
<aaabbb>
oh, no debugging symbols
agrosant has quit [Ping timeout: 264 seconds]
<aaabbb>
too busy to get more for now, i know it's probably not very helpful but https://bpa.st/QJDQ (has more symbols than the BtbN build, that one is 5.1.4-0+deb12u1, which reproduces it identically to the latest build)
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
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
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
Livio has joined #ffmpeg-devel
<another|>
btw: anyone at CLT?
elastic_dog has quit [Ping timeout: 256 seconds]
elastic_dog has joined #ffmpeg-devel
Livio has quit [Ping timeout: 260 seconds]
mkver has joined #ffmpeg-devel
<BtbN>
If you get memory corruption with vastly different versions and builds, the first thing I'd do is check the machine for hardware issues, and try to reproduce on a different machine and even arch
<aaabbb>
BtbN: hardware is fine
<aaabbb>
and the corruption is consitent (always at the same place)
<aaabbb>
cannot reproduce for 32bit i686 (4.4.2, old), can reprouce with the same binary on another computer
Livio has joined #ffmpeg-devel
cone-772 has quit [Quit: transmission timeout]
<BtbN>
Well, there were a lot of "sometimes" that made it sound like it's non-deterministic
<aaabbb>
you're right, i spoke poorly. it changes based on the contents of the filtergraph (like fps, scale, etc)
<aaabbb>
but for "testsrc2,scale=-1:459,split=4[a][b][c][d];[a][b][c][d]xstack=grid=2x2[out0]" it is always "invalid fastbin entry (free)"
<BtbN>
hm, would be very strange for such a big issue to just have been there for so long
<aaabbb>
does not happen if i do scale=-1:460 or scale=-1:458
<aaabbb>
are you able to reproduce it?
<BtbN>
I haven't tried yet
<BtbN>
It also crashes on some random old Ubuntu version at least
<BtbN>
And also ffplay on Windows
<aaabbb>
it's strange that it doesn't happen with testsrc, only testsrc2, and only with 459 (also a few other odd numbers i tried), and only with xstack 2x2, not with hstack+vstack
<BtbN>
This got to be some place that needs an even number for width/height, but fails to check it, right?
<aaabbb>
1459 does not fail at least
<aaabbb>
401 gives "invalid fastbin entry (free)" and 403 gives just a segfault, so it's definitely some memory corruption
<BtbN>
Or it's some over-reading of the buffer where the buffer is too small, and depending on its size, it's sometimes fine and sometimes not
<BtbN>
Or over-writing even
<aaabbb>
and "malloc_consolidate(): invalid chunk siz" for 201
<BtbN>
I'd probably ask asan
<BtbN>
huh, in asan mode, there's a million undefined references to all the assembly functions
<BtbN>
i.e. the main av_image_copy_plane in vf_stack overwrites
<BtbN>
Specifically if the input is of size 612x459
psykose has quit [Remote host closed the connection]
lexano has joined #ffmpeg-devel
<Lynne>
mkver: it is a cleanup which I need to implement xhe cleaner, and the size increase isn't that drastic, but I'd much rather figure out what got duplicated and save the size
<Lynne>
in my dirty branch, I got a size decrease, but after all the refactoring, I don't know what caused it to baloon
<Lynne>
my current guess is that it might be the window tables, though it's still a bit too big for it to be just that
<BtbN>
I _think_ the issue is that the height is not divisible by 2. I.e. for the subsampled planes, the height of 459 gets turned into 230
<aaabbb>
BtbN: then why would it not crash with testsrc?
<aaabbb>
they output the same dimensions
<BtbN>
Cause it's rgb and not subsampled
<aaabbb>
maybe because yuv420p, is not rgb
<aaabbb>
ah
<aaabbb>
you're right, turning it into testsrc,format=yuv420p crashes
<BtbN>
height of 918 gets subsampled to 459, and you simply cannot fit two same size frames into that, without either leaving an empty line, or over-writing
<BtbN>
and vf_stack... overwrites
<BtbN>
I'm not sure how a subsampled frame with e height of 459 can even exist. It kinda has to be even
<BtbN>
All those AV_CEIL_RSHIFT in config_output() probably need to be replaced with something that rounds DOWN
<BtbN>
but I'm not sure if it's correct. Or if the filter should instead just bail if it gets a subsampled input with non-even dimensions? Why doesn't the scale filter bail on those?
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
sudden has quit [Ping timeout: 246 seconds]
sudden has joined #ffmpeg-devel
qeed has joined #ffmpeg-devel
CAT_S is now known as CATS
* Sean_McG
peeks in
<Sean_McG>
so my dad went and bought an M3 iMac, guess who gets to help him set it up?
<Marth64>
designated Family IT department
<Marth64>
;D
<Sean_McG>
basically.
<qeed>
apple genius man
<Marth64>
my only hard nope is printers
<Marth64>
printers are satanic
<Marth64>
but i end up doing them anyway
<Sean_McG>
he has a laser printer, but it does not have network capability, just USB
<Sean_McG>
which, now that I think of it, could be a problem. Ugh. It's not USB3.x
<BtbN>
I don't see why that'd be a problem for a printer
<BtbN>
You plan to pump gigabytes of data to it?
<Sean_McG>
the M3 iMac only has USB3 ports, IIRC
<Marth64>
yeah it should be ok except dongles
<BtbN>
so?
<Sean_McG>
I think it's the micro/mini connector
<BtbN>
Every modern PC only has USB3
<Sean_McG>
I should have been more specific, he doesn't have an adapter for it... I guess I'd better go get one.
<BtbN>
So you mean USB-C?
<Sean_McG>
yes
<BtbN>
Well yes, for any modern Apple Laptop you need an adapter-tree to do anything useful with them
<Sean_McG>
OK, I'm glad I realized that before I went over
<Marth64>
once again,
<Marth64>
printers be evil and show their true colors
<Marth64>
even though this isn't the printers fault
<Marth64>
i hate printers lolol
Krowl has joined #ffmpeg-devel
<BBB>
oof, a non-static "dec_init" symbol in ffmpeg... yikes
<BBB>
10 points off gryffindor
<Sean_McG>
*laughs*
<BtbN>
BBB: it's inside of the fftools, not in the libraries
<BBB>
yeah I saw
<BBB>
but still
<BtbN>
I don't see anything wrong with naming a symbol that inside of an executable
<BtbN>
I do see an issue with naming a symbol that in a library however
<BBB>
even non-library symbols should use cautious naming standards
<BBB>
similar to password standards, basically
<BBB>
to prevent clashes with any dependencies
<BtbN>
To account for libraries that do it wrong? If there's one place to use generic function names, it's in executable problems
<BtbN>
*programs
<BBB>
yes, to account for dependencies that are also wrong
<BBB>
you only need two wrongs to fail a build
<BtbN>
Also, it's only an issue when you statically link that library
<BtbN>
it's not an exported symbol in either of the two
<BBB>
these are all "it's only an issue half of the time" arguments
<BBB>
I agree
<BBB>
but it's still an issue
<BtbN>
Yes, in libbr
<BBB>
we should not have non-static symbols that have 7 characters of entropy
<BBB>
the likelihood of a symbol collision is just too big
<BBB>
even if that's only an issue in 50% of 50% of the cases
<BBB>
it's still not worth the risk
<BtbN>
I mean, nothing bad will happen luckily
<BtbN>
the linker notices it instead of making a wild mix
<BBB>
another 10 points off gryffindor is all you get, fortunately
<BBB>
it could be much worse
<BBB>
oh, and you get a mmild verbal spanking from BBB on IRC
<BtbN>
I just really don't see anything wrong with using generic function names in executables
<BtbN>
In a library it's a big no-no, unless you straight up say you don't supports static linking
<BBB>
haasn: re: the libdav1d patch, I thought dav1d exported the color_range etc. thingies in the sequence header?
<BBB>
so we should be able to set them to something else than "unspecified"
microchip_ has quit [Quit: There is no spoon!]
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
Krowl has quit [Read error: Connection reset by peer]
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<Marth64>
more CC fixes coming today
<Marth64>
including not using PAL resolutions as a base when trying to calculate position...
HarshK23 has joined #ffmpeg-devel
<haasn>
BBB: I guess I can do that; though I'm not sure it makes sense for these fields to be set for AV1 streams?
<haasn>
the purpose of these fields is to disambiguate between multiple alternate sets for AFGS1 streams
<haasn>
e.g. if they offer a different film grain param set for application in YUV space vs application in RGB space
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
<Lynne>
jkqxz: friendly ping
qeed has quit [Quit: Leaving]
hamzah has joined #ffmpeg-devel
cone-597 has joined #ffmpeg-devel
<cone-597>
ffmpeg Marton Balint master:9c2c0c37f8c7: avformat/pcm: factorize and improve determining the default packet size
<cone-597>
ffmpeg Marton Balint master:44b276961924: avformat/pcm: decrease target audio frame per sec to 10
<cone-597>
ffmpeg Marton Balint master:05936403f9c4: avformat/wavdec: use ff_pcm_default_packet_size for the default packet size
<BBB>
haasn: I don't know about that. I'm just saying setting them to unknown feels wrong because we actually know what they are, sometimes
<BBB>
but if that doesn't matter then maybe it doesn't matter :)
<cone-597>
ffmpeg Marton Balint master:b2b22c2d1aef: avutil/tests/channel_layout: make printing results part of the tests
<cone-597>
ffmpeg Marton Balint master:0b3b8a19187c: avutil/tests/channel_layout: add some av_channel_from_string and av_channel_layout_from_string tests
<cone-597>
ffmpeg Marton Balint master:95d31db82c12: avutil/channel_layout: factorize parsing list of channel names
<cone-597>
ffmpeg Marton Balint master:a688fbfb8877: avutil/channel_layout: fix some (un)initialization issues in av_channel_layout_from_string()
<cone-597>
ffmpeg Marton Balint master:a4fc3311181a: avutil/channel_layout: add specific text versions for unknown and unused channels
<cone-597>
ffmpeg Marton Balint master:d35b6fda4536: avformat/mxfdec: signal channel layouts using the new channel layout api
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
agrosant has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
agrosant has joined #ffmpeg-devel
<cone-597>
ffmpeg Stone Chen master:de2fb43e7857: doc/filters: Change rdiv (vf_convolution) documentation to reflect actual behavior
<Lynne>
does the C language require you to always put a break after statements in switches, even if the statement is return; or abort()?
<JEEB>
I think return etc are just fine? since break just otherwise forcibly stops the logic.
<Lynne>
what about switch() which always returns in a non-void function which only has the switch()?
<Lynne>
do you still need to return?
<BtbN>
I have trouble parsing that sentence
<BtbN>
If you return from within a switch, you don't need a break after that return, if it's the only possible branch
<Lynne>
I mean "int fn(int num) { switch (num) { default: return 0; } }"
<Lynne>
do you need a return outside the switch in this case, according to the spec?
<JEEB>
the switch has a default case so I don't see any reason for there having to be a separate return after it
<Gramner>
as long as you always return a value it's fine
<BtbN>
I'd probably just move the default stuff to after the switch for good measure
<BtbN>
But most compilers should be smart enough to understand that you can't leave from that switch
<Gramner>
reaching the end of a non-void function without returning is UB, as long as you don't end up doing so that's within the spec. most compilers will warn if they think that can happen
<Lynne>
ok, that's good enough for me, as long as it's UB and not a language parsing error
<ramiro__>
Lynne: is this question purely to better understand the C language or are you looking into some kind of optimization?
<Lynne>
just wondering how pedantic the spec is with respec to it, that's all
<sdc>
this is my first time writing raw asm so any comments welcome
<Lynne>
scrap prefetches, they never help ever, they just clog up the instruction decoding pipeline with noops
<ramiro>
Lynne: a long time ago we would have rich felker or mans rullgard to answer all pedantic spec-related questions... it seemed like they just knew all of it by heart. it was impressive.
<Gramner>
sdc: you're probably better off that kind of width branching in asm rather than c. having three code paths (w=4, w=8, w>8) could very well be ideal for avx2 but that's an implementation detail that may vary from one arch and/or instruction set to the next
<Lynne>
sdc: it would be faster to do in-lane permutes followed by vperm2i128 + punpck or similar, pshufb isn't fast, and most CPUs only have a single pshuf port
<Gramner>
also if you're not doing either address calculations nor any kind of SIMD operations on the data gathers are probably not going to be very useful performance-wise compared to doing it in scalar
<Lynne>
yeah, intel killed gather performance, and gatherdd was IIRC always slower than manual gathers
<Gramner>
you wont magically be able to do more loads per cycle with gathers than with scalar loads - quite the opposite
<Lynne>
also, if you have spare registers, it's best to put any tables you use during the loop into a register and use that instead of giving each instruction an address
<Gramner>
the benefit of gathers is that it allows for doing address calculations in SIMD and load data into SIMD registers without having to first move the addresses one-by-one to scalar registers and then insert elements one-by-one into SIMD regs
<Gramner>
if the addresses aren't in SIMD registers to begin with, and you don't need the data in SIMD registers afterwards, there isn't really any point
<Gramner>
you could perhaps look into merging that entire DSP functiion with either the code that does the address calculation and/or the code that uses the data afterwards
<sdc>
re: width branching, that makes sense, just have like a jump inside and merge the two functions together?
<sdc>
or I guess just merge everything together like you just mentioned haha
<sdc>
for in-lane permutes, that'd be vpermilps? is there a resource for finding out how many execution ports cpus have? I've mainly been going off stuff like intel intrinsics guide and trial and error lol
<Lynne>
I use agner's instruction listings
<Gramner>
in general if you can do more stuff while data in is still in registers instead of writing to some buffer and then immediately reading it back that's a win
<Gramner>
and agner, yes. most intel cpus have three simd ports (p0, p1, p5) and amd ones have 4 (fp0, fp1, fp2, fp3)
<Gramner>
but not all ports are the same. different instructions execute on some subset of those
<sdc>
oh awesome thank you both, I have some reading to do it seems
<sdc>
and yeah def makes sense trying to merge the dsp function to keep as many calcs in registers as possible, mainly was doing this to keep the scope small while I'm learning ffmpeg/asm
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]