Nyanmisaka
> Well I found the cause. GCC generated code sequences from `_mm256_extract_epi32` and `_mm_extract_epi32` intrinsics includes optimizations that do not play well with windows and will cause access violation. By...
> Well it turns out that it is not that simple. > > Now I really believe it is due to gcc+windows. I can workaround this issue by reducing the...
Have you seen these? MingGW-W64 seems to be quite fragile in handling AVX. https://stackoverflow.com/questions/71859992/what-is-causing-this-memory-access-violation-error-0xc0000005-when-using-eigen https://stackoverflow.com/questions/30928265/mingw64-is-incapable-of-32-byte-stack-alignment-required-for-avx-on-windows-x64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 edit: If this is the reason, a workaround is to add the compiler option...
> > Have you seen these? MingGW-W64 seems to be quite fragile in handling AVX. > > https://stackoverflow.com/questions/71859992/what-is-causing-this-memory-access-violation-error-0xc0000005-when-using-eigen > > https://stackoverflow.com/questions/30928265/mingw64-is-incapable-of-32-byte-stack-alignment-required-for-avx-on-windows-x64 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412 > > Well it is worse...
> A question about the yuv420p implementation: If most of the software decoder and encoders are not expecting p01x frames, isn't it safe to just drop the support for such...
> I "fixed" the access violation on Windows by refactoring the memory store logic and using more stable range clipping. > > The new memory store logic improved performance for...
This is file specific, please provide a clip so we can investigate.
Received. You can remove the link.
> I've been meaning to retest this after the recent jellyfin-ffmpeg 7.x releases, but I unfortunately can no longer do so. My motherboard (Supermicro X13SAE-F) failed and I replaced it...
> A lot of the context used in this file is missing in the upstream. Is it possible to have this upstreamed? The existence of vf_libplacebo makes it more difficult...