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 8.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<Traneptora>
jamrial: I think it may just be a bug in qemu
<Traneptora>
if I take the bugged 32-bit static binary and just run it on my x86_64 host it works as expected
<Traneptora>
after some testing I got it to take a non-NaN float, angle, do -angle, and get NaN
<Traneptora>
did some testing with uint64_t anglex; memcpy(&anglex, &angle, sizeof(angle)); and got that angle was being passed but most attempts to do much with it ended up as NaN
<Traneptora>
but running the produced binary in qemu-system-x86_64 and also in qemu-system-i386 produced bugged results, but running it on the host did not
NullSound has joined #ffmpeg-devel
<jamrial>
well no, i can reproduce it on my native mingw-w64 toolchain
<jamrial>
there is something funky going on, and it seems to be with png only
<jamrial>
i worked around it by using tiff instead, but it should be looked at anyway since png is a lot more common
<mkver>
jamrial: Is the generated png fine or not? What does "exiftool -Orientation -n <png file>" say?
<jamrial>
mkver: i don't know if it's fine, but the systems where this can't be reproduced generate the same png (see the relevant CI jobs)
<Traneptora>
jamrial: interesting, but I really don't think it's PNG
<jamrial>
mkver: Orientation : 5
<mkver>
As it should.
<jamrial>
yes
<Traneptora>
yea, the PNG itself is fine
<Traneptora>
the problem is reading it back
<Traneptora>
although I've since managed to reproduce the issue on my host computer using the 32-bit binary
<Traneptora>
I think pngdec is unlikely to be the source, it's just that it happens to hit the right code path / alignment in this case
<Traneptora>
I changed av_display_rotation_set in the following way
<Traneptora>
following was printed to stderr: longboi: 4056800000000000, angle: 90.000000, lb2: 7ff8000000000000, mangle: nan, radians: nan
<Traneptora>
this is only if I added --extra-cflags=-march=i386
<Traneptora>
then I got 0xfff80..... instead for both
<jamrial>
i extended that to also print c and s, and got "longboi: 4056800000000000, angle: 90.000000, lb2: c056800000000000, mangle: -90.000000, radians: -1.570796, c: nan, s: nan"
<mkver>
Maybe an emms issue?
<jamrial>
on x86_64?
<jamrial>
well, -cpuflags 0 changes the above to c: 0.000000, s: -1.000000 and it seems to work
<jamrial>
so i guess you may be onto something
<mkver>
There is mmxext code for add_paeth_prediction.
<jamrial>
yeah, but there's also ssse3
<mkver>
jamrial: The ssse3 version also uses INIT_MMX.
<mkver>
So both use mmx registers.
<jamrial>
ah
<jamrial>
that did it
<jamrial>
ffs
<jamrial>
and it never broke anything else?
<mkver>
Why does an SSSE3 function use mmx registers instead of SSE?
<jamrial>
because pabsw works on mmx regs, and whoever wrote this didn't want to rewrite it for xmm regs
<jamrial>
also, i thought floats on x86_64 did not use x87
<beastd>
BtbN: Yes, importing all tickets from Trac is questionable. Let's keep em in Trac for a bit longer and see what we want to do. Could maybe at some point make a read only static html of it and decide to shutdown Trac.
<BtbN>
Could you chime in on the ML thread about it?
<beastd>
Probably. Just wanted to look what's up there. Couldn't follow the ML for a while :(
skinkie has quit [Ping timeout: 248 seconds]
lemourin has quit [Ping timeout: 248 seconds]
skinkie has joined #ffmpeg-devel
<Lynne>
the wiki is very outdated in spots too
<beastd>
Lynne,BtbN: wiki is sure outdated in spots. kind of always will be. though i think it is overall a net benefit and we should migrate it to forgejo if we go with forgejo
<Lynne>
fair
<BtbN>
I edit it myself from time to time
<BtbN>
Yeah, the Wiki is at least partially maintained
<beastd>
If you see places where the wiki is outdated, consider to add a notice (or event correct it if you can be bothered)
<BtbN>
most recently I added gfxcapture to it when it was merged
lemourin has joined #ffmpeg-devel
<beastd>
For ffmpeg where we do not have "good" defaults, the wiki is also the most easy, central place to get useful parameters (second best are random blogs if you find them or stack overflow if you are lucky)
<kasper93>
so, it was emms issue. Funky.
<beastd>
kasper93: tricky. which one?
<kasper93>
the "png" issue discovered in #20522
<kasper93>
(fixed by 57a29f2e7dd2374a1df27316c6cf7c0225e86758)
<JEEB>
alright, and tested the edge case for ttml in fragmented mp4 that consists of encoding ASS into TTML and muxing only that stream into movflags +cmaf mp4. of course, it ends up in a single final packet since you don't have a control stream according to which you should fragment. of course doing manual fragmentation with API should work JustFine
<JEEB>
and all PR CI does pass, so time to finish this part :)
<mkver>
kasper93: The mmx code violates the ABI by design. This actually increases complexity, because the programmer touching code must be aware to call emms_c() after DSP functions that may have used MMX without emms before using floating point operations or code that may use them (some libc do (did) also rely on it for memory allocations, so one must call emms_c before anything that may allocate something).
<mkver>
This is frequently violated; adding av_assert0_fpu() to av_free(), av_malloc() and av_realloc() makes lots of FATE tests fail.
<JEEB>
yea, emms usage seems quite messy
<JEEB>
small commit message fixup (noticed a commit originally added in 2019 still had `avcodec/avpacket` as prefix :D (while the current files are packet.c and packet_internal.h)
<beastd>
ah yes, forgotten emms is a classic unfortunately. strictly needs to be called before we call into any 3rd party code that doesn't give other guarantees
<Lynne>
maybe we should hide all MMX code behind a config-time --enable flag?
<beastd>
OTOH hand we leave out emms on purpose to not have to pay the costs. so it kind of magnets the forgotten emms problem
<beastd>
Lynne: Does that help the problem? Or is it making it worse?
<Lynne>
it helps by helping us not care about it as much
<beastd>
so more in the sense of "dropping MMX"
rix has quit [Ping timeout: 248 seconds]
emersion has quit [Ping timeout: 248 seconds]
OctopusET has quit [Ping timeout: 248 seconds]
redzic has quit [Ping timeout: 248 seconds]
_whitelogger has quit [Ping timeout: 248 seconds]
Moon_Rabbit has quit [*.net *.split]
_whitelogger_ has joined #ffmpeg-devel
kurufu_ is now known as kurufu
Moon_Rabbit has joined #ffmpeg-devel
Xe has joined #ffmpeg-devel
Xe has quit [Max SendQ exceeded]
Xe has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<BtbN>
hm, even after migrating it to activate, if the captured window is a flat 0 fps, the filter will block forever
<BtbN>
something external to it will keep calling the activate function until it returns a frame, and only once a frame was returned will check if exit was requested by hitting q on the ffmpeg.c cli
<kasper93>
JEEB: TTML changes seem to leak memory
<JEEB>
-_-
<JEEB>
any general location?
Traneptora_ has joined #ffmpeg-devel
<kasper93>
check fate
<JEEB>
k
<JEEB>
pretty sure I did a valgrind run in one of the iterations
<mkver>
ePirat: The vorbis comments get applied in read_header. If AVFormatContext.metadata is empty after read_header, then the id3v2 metadata will be used. Furthermore id3v2 apics and chapters and "private tags" will be applied (regardless of whether read_header had metadata or not).
microchip_ has quit [Remote host closed the connection]
microchip_ has joined #ffmpeg-devel
funkylab_ has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
BBB_ has joined #ffmpeg-devel
<JEEB>
kasper93: will attempt to check today/tomorrow, could be something dumb like never cleaning up some packet queue at the end. have had bad sleep last night so I might end up dropping out early today
<BtbN>
ah, so the new flags didn't make it into the threads avctx after all
<jamrial_>
the way mkver wrote it was for pthread_frame to have their own pictype and intra_flags. the rework linked above removed setting them from pthread_frame, leaving those fields as write only
<jamrial_>
trying to set them again from pthread_frame doesn't work because ff_decode_receive_frame_internal will overwrite the values from the thread avctx's DecodeContext, which is pretty much blank
abdo has quit [*.net *.split]
graphitemaster has quit [*.net *.split]
rossy has quit [*.net *.split]
kurufu has quit [*.net *.split]
_whitelogger_ has quit [*.net *.split]
redzic has quit [*.net *.split]
jamrial has quit [*.net *.split]
fennewald has quit [*.net *.split]
Teukka has quit [*.net *.split]
MisterMinister has quit [*.net *.split]
rvalue has quit [*.net *.split]
philipl has quit [*.net *.split]
srikanth has quit [*.net *.split]
devinheitmueller has quit [*.net *.split]
Gramner has quit [*.net *.split]
tortoise has quit [*.net *.split]
Fenrir has quit [*.net *.split]
haxar has quit [*.net *.split]
paulk-bis has quit [*.net *.split]
kepstin has quit [*.net *.split]
Compn has quit [*.net *.split]
kurufu_ is now known as kurufu
<jamrial_>
so i just made it sync the latter
MisterMinister has joined #ffmpeg-devel
<mkver>
jamrial: Aren't your new PerThreadContext write-only?
<kasper93>
haasn: why read_planar_u32() calls clear_1110_f32() in checkasm test? Shouldn't it prefer clear_1110_u32? I didn't unwrap what happens in compile_tables, so maybe it's expected?
<mkver>
nevcairiel, nevcairiel_: Once upon a time, checkasm pulled all of lavfi or all of lavc in and therefore also these avpriv fonts which are marked as being exported from lavu and imported into all the other libs, leading to linking failures with shared MSVC builds. But nowadays we get other linking errors with shared MSVC builds, see https://fate.ffmpeg.org/report.cgi?time=20250916173243&slot=x86_32-msvc14-dll-windows-native.
<JEEB>
jamrial_: yea I started looking into it already; will see if I can figure it out tomorrow
<JEEB>
and I did do valgrind passes on this somewhere along the way, but this has been in this review state since around 2021 so things around it may have changed
<JEEB>
and/or I may have done something dumb like forgotten to flush a packet queue