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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue has quit [Ping timeout: 246 seconds]
rvalue has joined #ffmpeg-devel
jamrial has quit [Read error: Connection reset by peer]
jamrial has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
mkver has quit [Ping timeout: 268 seconds]
kurosu has quit [Quit: Connection closed for inactivity]
Traneptora has quit [Remote host closed the connection]
<cone-441>
ffmpeg Michael Niedermayer master:d344a4191c39: tools/target_dec_fuzzer: Adjust Threshold for VP6A
<cone-441>
ffmpeg Michael Niedermayer master:c72a20f01a61: avcodec/jpeglsdec: Check Jpeg-LS LSE
<cone-441>
ffmpeg Michael Niedermayer master:cfc0a68d4d31: avformat/mov: do not set sign bit for chunk_offsets
<cone-441>
ffmpeg Michael Niedermayer master:f1dc7b92576d: tools/target_dec_fuzzer: Adjust threshold for QPEG
<cone-441>
ffmpeg Michael Niedermayer master:5f88458bea69: avcodec/jpegxl_parser: Add padding to cs_buffer
<cone-441>
ffmpeg Michael Niedermayer master:d909d8e5e0fb: avcodec/leaddec: Check remaining bits in decode_block()
<cone-441>
ffmpeg Michael Niedermayer master:aec67d3d7d28: avfilter/af_stereowiden: Round length to nearest
<cone-441>
ffmpeg Michael Niedermayer master:ab0fdaedd1e7: avfilter/avf_showspectrum: fix off by 1 error
<cone-441>
ffmpeg Michael Niedermayer master:e4d2666bdc3d: avfilter/vf_gradfun: Do not overread last line
<cone-441>
ffmpeg Paul B Mahol master:e6459abfadab: avfilter/af_stereotools: round-up max size of buffer
<cone-441>
ffmpeg Michael Niedermayer master:c443658d26d2: avfilter/edge_template: Fix small inputs with gaussian_blur()
<cone-441>
ffmpeg Michael Niedermayer master:0ecc1f0e4893: avfilter/vf_weave: Fix odd height handling
thilo has quit [Ping timeout: 256 seconds]
Traneptora has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
markh has quit [Remote host closed the connection]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
navi has quit [Quit: WeeChat 4.0.4]
markh has joined #ffmpeg-devel
jamrial has quit []
derpydoo has quit [Ping timeout: 256 seconds]
cone-441 has quit [Quit: transmission timeout]
cone-071 has joined #ffmpeg-devel
<cone-071>
ffmpeg Haihao Xiang release/6.1:d596225a57f1: lavc/qsvdec: return 0 if more data is required
feiw2 has quit [Remote host closed the connection]
feiw2 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
cone-071 has quit [Quit: transmission timeout]
Krowl has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
Blackhex has joined #ffmpeg-devel
<Blackhex>
Hello everyone. What is the inteded way for executing FATE tests on Windows target when the ffmpeg package was cross-build on Linux host?
Krowl has joined #ffmpeg-devel
<JEEB>
some tests require compilation so you need the source and build roots in any case
<JEEB>
the two types of windows testing we currently have in FATE automation are a) cross-compile and wine b) native build with MSVC and running the tests on windows
<JEEB>
technically I think you could try to utilize the wrapper setup such that it would remotely call the windows host via ssh or something else
<JEEB>
if it was just "run the cli over these commands" it'd be simpler, but there are tests that are compiled and then executed separately, so just having the ffmpeg cli is not enough
<JEEB>
right, target-exec is the configure option for adding wrappers like wine etc
<Blackhex>
@JEEB: Thank you for the info. So far I am building the package on the Linux host using `make` and GCC compiler, then downloading the tests data using `make fate-rsync SAMPLES=fate-suite/`, then packing the entire sources and build folder and transfering it to the Windows machine and then trying to execute `make fate SAMPLES=fate-suite/` there using bash.exe. This obviously fails as the Makefile contains lots of absolute paths rele
<Blackhex>
vant to the build host filesystem.
<JEEB>
yea
<JEEB>
ah yes, the qemu using FATE instances are probably closer :D
<JEEB>
where target-exec is utilized to literally run binaries within qemu
<JEEB>
your use case is surprisingly similar to this :P
<Blackhex>
Using ssh to execute the tests on the Windows machine is the least preferable option to me as I am building it as a Github Actions workflow so I'd rather prefer to modify the Makefile so it can be executed on the target out of the box.
<JEEB>
yea, it's just that you will need to compile stuff during `make fate` :D
<JEEB>
and even if you got those targets compiled
<JEEB>
well, ok. at that point it would probably be pretty close?
<Blackhex>
Thank you for the information about the QEMU option. I am actually testing our experimental aarch64 GCC compiler to build ffmpeg and although QEMU already supports aarch64 (https://www.linaro.org/blog/emulate-windows-on-arm/), I am little bit affraid I'll rather encounter issues with the emulation rather than real issue that our toolchain is producing invalid code (which I what I want to prove).
<JEEB>
and yea, normalizing the paths between your windows and lunix setup is probably the least bad alternative, with something like msys2 or cygwin, which allows for unix-like paths within that shell (and then translates that more or less badly to the underlying binary)
<JEEB>
yea a bunch of the runners on https://fate.ffmpeg.org/ are already aarch64 windows clang since wbs is nice enough to run that for us
<JEEB>
so your use case sounds quite close to that
<Blackhex>
@JEEB: Should I understand this that Clang bluild is also beeing cross-build for Windows Arm64 on Linux and the tests are executed on the Windows machine as well? Because in contrary to our toolchain wich is cross-compilation only, the Clang has also the native build option available.
<JEEB>
they are cross-compiles and then either run with wine or qemu
<Blackhex>
OK, thank you for the information.
<JEEB>
so there is no attempt at running the makefiles from another system, but rather generally just target-exec being utilized to prefix built binary execution with something
<Blackhex>
Understood, thank you.
AbleBacon has quit [Read error: Connection reset by peer]
tmm1_ has joined #ffmpeg-devel
tmm1 has quit [Ping timeout: 246 seconds]
dellas has joined #ffmpeg-devel
<wbs>
Blackhex: for testing compilers, running ffmpeg in wine is quite adequate. it doesn't usually run into issues with emulation
<wbs>
Blackhex: the emulation isn't exact; there are issues that it won't complain about though. e.g. if you're missing stack probing (__chkstk), wine won't usually notice but real windows will. and windows on arm64 refuses to load binaries that don't have the dynamicbase flag set, which doesn't hold for x86. but for regression testing and code generation issues, testing ffmpeg in wine is quite adequate. and
<wbs>
if you want to, run "make checkasm", copy ...
<wbs>
... out the built tests/checkasm/checkasm.exe and run it manually on real windows for an extra check
jamrial has joined #ffmpeg-devel
<Blackhex>
wbs: Thank you for this isnsight as well. We have implemented _chkstk for the aarch64-w64-mingw32 GCC target as well so it would be adequate to test it's working properly as well.
Teukka has quit [Read error: Connection reset by peer]
<wbs>
Blackhex: ok, good. I hope you aligned with the existing aarch64-mingw ABI and call it "__chkstk"?
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
<cone-348>
ffmpeg Nuo Mi release/6.1:0ecd15b83931: avcodec/cbs_h266: more restrictive check on pps_tile_idx_delta_val
<cone-348>
ffmpeg Pierre-Anthony Lemieux release/6.1:fb724ad64e2d: avcodec/jpeg2000htdec: check if block decoding will exceed internal precision
<cone-348>
ffmpeg Brad Smith release/6.1:4f879d26e1e8: configure: Enable section_data_rel_ro for FreeBSD and NetBSD aarch64 / arm
<cone-348>
ffmpeg Michael Niedermayer release/6.1:bb84cbfd0c0f: avcodec/osq: Implement flush()
<cone-348>
ffmpeg Michael Niedermayer release/6.1:45cd69a27669: avcodec/jpeglsdec: Check Jpeg-LS LSE
<cone-348>
ffmpeg Michael Niedermayer release/6.1:84f78ac3eac5: avformat/mov: do not set sign bit for chunk_offsets
<cone-348>
ffmpeg Michael Niedermayer release/6.1:bf2d7b20ea1c: avcodec/jpegxl_parser: Add padding to cs_buffer
<cone-348>
ffmpeg Michael Niedermayer release/6.1:3061bf668fef: avfilter/avf_showspectrum: fix off by 1 error
<cone-348>
ffmpeg Michael Niedermayer release/6.1:e809c23786fe: avfilter/vf_gradfun: Do not overread last line
<cone-348>
ffmpeg Michael Niedermayer release/6.1:162b4c60c8f7: avfilter/edge_template: Fix small inputs with gaussian_blur()
<cone-348>
ffmpeg Michael Niedermayer release/6.1:8b8b4bdef311: avfilter/vf_weave: Fix odd height handling
<cone-348>
ffmpeg Michael Niedermayer release/6.1:c02d56b3cf9d: Update for 6.1.1
ccawley2011 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Blackhex>
wbs: The answer from my colleage: "
<Blackhex>
__chkstk is generated by MSVC compiler and provides an implementation for stack probing. Stack probing calculates how many pages are allocated on the stack and touches them one by one from bottom to top to map all pages to the memory. It is not exclusive to the Windows ABI; it is also supported by other operating systems. It can be enabled in GCC by using the "stack-check" with STATIC_BUILTIN_STACK_CHECK.
<Blackhex>
<Blackhex>
The difference between GCC and MSVC generation is that MSVC generates the __chkstk function, while GCC uses an inline implementation. The GCC approach might provide better performance; however, it generates inline stack probing in the prolog for every function that allocates more than one page on the stack. Since it is not common for every function to allocate more than one page on the stack, in terms of size, it should also be fin
<thardin>
has there ever been a discussion of enabling -Werror?
<nevcairiel>
I dont like Werror, compiler updates and your project doesnt build anymore from some new bogus warning
<j-b>
Werror should only be used on CI and debug and never in prod and releases.
<j-b>
Because you don't know all compilers, including future ones.
<JEEB>
yea
<JEEB>
CI Werror is not the worst idea, but means you have to deal with existing warnings first
<JEEB>
(either by explicitly ignoring or fixing)
derpydoo has joined #ffmpeg-devel
<j-b>
yes, it's tricky in CI
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 268 seconds]
navi has joined #ffmpeg-devel
<Lynne>
werror is pure malice
<Lynne>
sway and wlroots gets broken on every single gcc version
<Lynne>
linux perf gets broken too
<Lynne>
perf gets a bonus for having an awful build system which makes it hard to disable iirc
<Lynne>
every single developer I've spoken to asking them to stop it has said "nah, you're wrong, werror is good, we're never going to stop using it and you cannot convice us otherwise"
<psykose>
for sway/wlr it's at least the default meson option so -Dwerror=false is all you need
cosimone has joined #ffmpeg-devel
<Lynne>
-Dyesiwanttocompile=true
<Lynne>
ah, but it's meson, which means true != enabled, so it may be -Dyesiwanttocompile=enabled