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
<desmond-netint>
BtbN: Some tests exercise the API. Others do simple demux+decode. But nothing fancy like demux->decode->filter->encode->mux and validate output. Or check libswscale's color conversion is correct.
<desmond-netint>
I want to add FATE tests for specific ASIC hw. It could exercise basic video decoding/encoding but would only be useful in ensuring that ffmpeg infrastructure changes don't break the libavcodec changes to support the hw. It wouldn't be useful to upstream the FATE changes.
<BtbN>
Always happy for more fate tests
<BtbN>
but it'll be a lot of work to implement it
<desmond-netint>
The FATE tests don't take long to run. I'm wondering if that's by design. Some of our in-house testing runs ffmpeg for hours/days (and we've seen some weird stuff happen when there is a PTS wrap-around). The ffmpeg community wouldn't appreciate FATE tests that run *that* long.
<BtbN>
They're usually made to test one specific thing, as minimal and concise as possible
arbitercoin has joined #ffmpeg-devel
<BtbN>
I couldn't think of anything in ffmpeg that could only be tested by running for hours
<BtbN>
fate aims for coverage, not maximum runtime
<desmond-netint>
Obscure memory leaks. Some companies use ffmpeg for live-streaming or long term camera capture.
<desmond-netint>
But you've answered my question, thanks.
<JEEB>
jamrial: thanks for noting the patch (and to mkver for posting it), will check it out
minimal has joined #ffmpeg-devel
derpydoo has quit [Quit: derpydoo]
mkver has joined #ffmpeg-devel
hbbs has quit [Quit: bye]
hbbs has joined #ffmpeg-devel
hbbs has joined #ffmpeg-devel
hbbs has quit [Changing host]
<mkver>
JEEB: The patch is from Zhao Zhili. I merely informed you of it.
<fjlogger>
[FFmpeg/FFmpeg] New comment on issue #20073 Same videos (frame-to-frame wise) written by different applications produce different PSNR/SSIM/VMAF scores (Implicit vs explicit colorspace difference). (https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20073#issuecomment-10539) by DimkaTsv
lemourin2 has joined #ffmpeg-devel
lemourin has quit [Killed (osmium.libera.chat (Nickname regained by services))]
lemourin2 is now known as lemourin
GewoonLeon has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
fjlogger has quit [Remote host closed the connection]
fjlogger has joined #ffmpeg-devel
MisterMinister has quit [Remote host closed the connection]
<Compn>
if you think about software itself, is there any specific program (not a zip library or a linux kernel, but a specific program) that you still use 24 years later? maybe a cli text editor?
<kasper93>
BtbN: fate caching is again not working, it always downloads Landscape_5.jpg
<BtbN>
not always. Once per runner.
<BtbN>
the cache is not global
<APic>
♥
<BtbN>
Also keep in mind that PRs cannot update the cache, only download it
<kasper93>
how many runners do you have?
<BtbN>
5
<BtbN>
if a certain runner always happens to only run PRs, never runs from master pushes, it might take a hot minute for it to actually update the cache
<kasper93>
1. I'm looking only on master 2. I would think after one week of master jobs it should updated itself,no?
<BtbN>
Yeah
<kasper93>
so, why it doesn't?
<BtbN>
No idea
<BtbN>
That's all handled by the runner
<kasper93>
I mean `Cache Fate-Suite` step never runs
<kasper93>
I wouldn't think it's runner issue
<BtbN>
hm, the only way that could happen is a hash collision
<BtbN>
that seems exceedingly unlikely though, for a sha256 hash to collide like this
<kasper93>
last time I tried to debug it, I inadvertently update the cache and that was end of testing.
<kasper93>
updated*
<BtbN>
like, "find fate-suite -type f | sort | sha256sum | cut -d' ' -f1" has to be returning the hash that's already stored, but missing that file
<kasper93>
BtbN: what I think happens, there is a bug in forgejo and the OLD cache was saved with a NEW hash and now the hashes match, even if the files in cache are old
<BtbN>
That's not up to forgejo
<BtbN>
so that bug would need to exist on Github as well
<kasper93>
github is very picky about updating cache concurently
<kasper93>
it locks the chaches
<kasper93>
here you say it's per runner, so in theory shouldn't be a problem, but I don't know
<kasper93>
one posibility is that the cache was updated on single runner, but reference (hash) of it was updated on all runners. Or something like that. I don't know, but something is not working imho
<ubitux>
mkver: I added your suggested options; seems to have worked
<mkver>
ubitux: Good. Btw: the valgrind-3.23.0 no-undef box was never affected, because it uses --undef-value-errors=no (default valgrind limit is 56, with track-origins it is down to 32 and with --undef-value-errors=no valgrind works by default, so I didn't care to investigate what the limit is for it).