SIF Codec added to FFMPEG

[BlackQ]

We have added SIF Codec support to FFMPEG. You can download it here: https://sifcodec.com/downloads
New SIF Codec version 2.07 and libraries / utilities are available too.

Current version is faster and support better psycho-visual model.
Two new presets are added:
Fast: 25 frames/s encoding for FHD
Faster: 30 frames/s encoding for FHD

[autodidact]

Thank you for the update. The Linux console programs are working as expected. However, using the same input file and command line with the Windows program is giving an error.

Fatal: Encode lib can't be initialize

I also compiled a 64-bit ffmpeg for Windows with the codec patches and it also gives an error.

Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height

I did place the libraries with ffmpeg as the readme file instructed and a -codec list from the binary shows that sif1 is indeed available.
Perhaps I am doing something wrong?

[BlackQ]

Hi autodidact,

Give us a moment to check and we'll return to you shortly.

[El Heggunte]

The VfW edition needs a serious rework...
it makes the 32-bit VirtualDub(2) crash while being opened by the operating system (64-bit Windows 7).

Crash details (best guess as to cause):

An instruction not supported by the CPU was executed in module 'Sif1_vfw'...
...while opening video codec with FOURCC "sif1" (compchoose.cpp:344)...
...while enumerating video codecs (compchoose.cpp:332).

[LigH.de]

That sounds to me like some assembler code relies on x86-64 instructions or registers only available in x86-64 mode, despite running in x86 mode only...

[BlackQ]

Hi autodidact,

You need to have encoder and decoder libraries within FFmpeg folder.
You can find them on our site with version 2.07:
- libsif1dec.dll and libsif1enc.dll for Windows
- libsif1dec.so and libsif1enc.so for Linux

Without them error will come: "lib can't be initialize"

Those libs are 64-bit so FFmpeg should be compiled as 64-bit

[BlackQ]

Hi El Heggunte

We use SSE 4.1 instructions in the current version and it will not work on the systems without SSE 4.1 support
This is only temporarily since we did not finish some functions on pure C. It will be corrected in upcoming versions

Also codec may hit memory limitation in 32-bit version for hi-res encoding like 4k

[Neiromaster]

However, using the same input file and command line with the Windows program is giving an error.

This is possible if you have compiled FFmpeg for Windows using GCC and mingw64.

This was tested when compiling under Windows using Visual Studio.
Compiled using this guide.
https://www.roxlu.com/2019/062/compiling-ffmpeg-with-x264-on-windows-10-using-msvc

For mingw compilation аdditional definitions of library loading functions are required.

[Neiromaster]

I attach the addition for compilation under mingv.
This code has not been tested.
If the compilation problem under mingv leaves after these changes, the code posted on the site will be changed

[LigH.de]

It would be very appreciated if anyone then could help creating extra build scripts to be added to the media-autobuild suite, as it has a kind of "plugin system" for shell scripts preparing the compilation of libraries and adding custom command line options to the compiler call of ffmpeg before executing it.

[El Heggunte]

Hi El Heggunte

We use SSE 4.1 instructions in the current version and it will not work on the systems without SSE 4.1 support
This is only temporarily since we did not finish some functions on pure C. It will be corrected in upcoming versions

Also codec may hit memory limitation in 32-bit version for hi-res encoding like 4k

As the image below shows, the problem was NOT the lack of SSE 4.1 support.
If the SIF codec is "unsuitable" for working on a 32-bit subsystem, then a 32-bit VfW DLL should not even exist, to begin with.


[Attachment 66855 - Click to enlarge]

[LigH.de]

My guess is that some assembler code may refer to a CPU register which is only available in 64 bit mode of the CPU but not in 32 bit mode (here the number of registers is more limited), or a CPU instruction needs to have a different structure, so the assembler code may lack a "bitness switch".

I remember that Multicoreware refused to implement assembler variants for x265 in 32 bit mode due to the double efforts to optimize these routines for these different constraints.

[LigH.de]

mingv

Minimalist GNU for Windows

[autodidact]

Hi autodidact,

You need to have encoder and decoder libraries within FFmpeg folder.
You can find them on our site with version 2.07:
- libsif1dec.dll and libsif1enc.dll for Windows
- libsif1dec.so and libsif1enc.so for Linux

Without them error will come: "lib can't be initialize"

Those libs are 64-bit so FFmpeg should be compiled as 64-bit

As mentioned in my original post, I did have those libraries in place and I compiled 64-bit but also with MINGW/GCC so I will try again with the above patch.
But my original error was with the ConsoleEnc.exe on Windows which didn't behave like its Linux counterpart and instead gave "lib can't be initialize".

[autodidact]

It would be very appreciated if anyone then could help creating extra build scripts to be added to the media-autobuild suite, as it has a kind of "plugin system" for shell scripts preparing the compilation of libraries and adding custom command line options to the compiler call of ffmpeg before executing it.

I modified an example in the custom patches section of the README with the following code placed in ffmpeg_extra.sh script:
https://github.com/m-ab-s/media-autobuild_suite/blob/master/README.md

#!/bin/bash

# Force to the suite to think the package has updates to recompile.
# Alternatively, you can use "touch recompile" for a similar effect.
touch custom_updated

_pre_configure(){
    # Apply a local patch inside the directory where is "ffmpeg_extra.sh"
    patch -p1 -i "$LOCALBUILDDIR/0001-avcodec-SIF1-video-encode-decode-support-via-externa.patch"
    patch -p1 -i "$LOCALBUILDDIR/0002-avcodec-SIF1-video-encode-decode-support-via-externa.patch"
    patch -p1 -i "$LOCALBUILDDIR/0003-avcodec-SIF1-patch-for-mingv-compilation.patch"
}

Place the script and the patches in the build directory. I'm currently compiling with the new patch so no word yet on if this works.

[autodidact]

It looks like SSE4.1 was the issue on the machine where I tested ConsoleEnc.exe so thank you for that information.

[autodidact]

With the latest patch ffmpeg is now working with the SIF libraries. Thank you!

[Neiromaster]

[QUOTE=El Heggunte;2667706]

Hi El Heggunte

If the SIF codec is "unsuitable" for working on a 32-bit subsystem, then a 32-bit VfW DLL should not even exist, to begin with.


[Attachment 66855 - Click to enlarge]

I regularly test 32-bit codec build + constantly use Virtual Dub & 32bit VfW .
Everything works great.

I found a problem.
In compiler options for 32-bit build, has been added compilation key /arch:AVX2

Here's the corrected build

[El Heggunte]

@Neiromaster: thanks for your efforts.

NOW the 32-bit DLL doesn't make the 32-bit VirtualDub crash.

BUT... the test encode that I've just run is problematic.

First, it is decoded WITHOUT CRASHES only through the VfW interface (VirtualDub, both 32-bit and 64-bit).
When opened by a DirectShow media player, the application crashes after playing 1 or 2 seconds of the video.
ALSO: the first frames of the test video were compressed wrongly.
Below is the difference between what the first frame of the re-encode should look like and what the SIF1 codec produced.

[Neiromaster]

When opened by a DirectShow media player, the application crashes after playing 1 or 2 seconds of the video.

Yes. While adding support for FFmpeg, added bugs to the color space conversion function.

Fixed all the bugs that I found, but perhaps there are still...

[LigH.de]

I modified an example in the custom patches section of the README with the following code placed in ffmpeg_extra.sh script:
...

Place the script and the patches in the build directory. I'm currently compiling with the new patch so no word yet on if this works.

This seems to require the dynamic loading of external libraries. So the resulting ffmpeg is not a completely static single EXE, which I would prefer. But alright, I will try that one. At least it appears to be a pretty simple solution for now.

It should also be mentioned that when the codec is not licensed under GPL, ffmpeg must also be compiled with non-free license and must not be distributed.

[Neiromaster]

It should also be mentioned that when the codec is not licensed under GPL, ffmpeg must also be compiled with non-free license and must not be distributed.

Why? FFmpeg with this patch is fully functional and does not use SIF libraries until the user tries to work with the SIF1 stream. If it does not find the necessary libraries, then it reports it correctly.
That is, the use of external libraries is no different from the use of the external windows API. The patch code itself is published on the GPL.
No third-party code is required for compilation except for the patch.

However, we made this patch for internal needs and simply published it for everyone.

[LigH.de]

Ah, well, that could be right, as long as the codec is not linked statically.

My first test was not successful. Compiling passed but patching libavcodec/allcodecs.c failed. My file contains also some codecs not selected by default, like ff_libsvt_vp9_encoder, so I patched the patch file to my choice and the correct line number in my case, now trying again...
_

PS: This time it worked and encodes.

Quality is not that bad. Did a quick run with the evil Derf test clip in_to_tree_420_720p50.y4m and IMHO the artifacts of SIF1 (viz_dist 50) don't look much worse than those of x264 (crf 27), with quite similar bitrates (each ~2.5 Mbps).

[Neiromaster]

Quality is not that bad. Did a quick run with the evil Derf test clip in_to_tree_420_720p50.y4m and IMHO the artifacts of SIF1 (viz_dist 50) don't look much worse than those of x264 (crf 27), with quite similar bitrates (each ~2.5 Mbps).

Yes, it encodes comparable to x264 on medium bitrates and somewhat better on low, but worse than x265.
But it is worth considering that this is a zero-latency codec.

And yes, the kernel of this codec is very outdated, and need to make a new kernel to match the current level.

Please note that this is the only technology in the world that does not use a standard compression pipeline, where all technologies are written from scratch and at the same time comparable to mainstream codecs.

[LigH.de]

I could agree to saying it seems to be one of the better Wavelet motion codecs yet. And there are not many.

[El Heggunte]

UPDATE:

The DirectShow filters don't crash anymore, which is good.
BUT...
well, the VfW encoder doesn't like VirtualDub's Fast Recompress feature.
If I use this, then SIF1 generates artifacts on the first 5 frames.
ALSO: the first test-encode of today went 100% O.K.,
but in the next test-encodes the first five frames of the video are always replaced with a copy of the last frame of the original source /selection.

Sadly this codec still is very-far from the "production-model" level.

[Neiromaster]

the first five frames of the video are always replaced with a copy of the last frame of the original source /selection.

This is not possible for this codec. Check which filters you are using in the Direct Show pipeline or for the source.

Something like a subtitle filter adds delay.

There are no 5 frame buffers in all code of this codec

Sadly this codec still is very-far from the "production-model" level.

As you wish.

Thanks for the testing - I would not have been able to find such bugs.

[Neiromaster]

VfW encoder doesn't like VirtualDub's Fast Recompress feature.

No that supports.
YUV12, I420, I420p10(10bit), I420p16(16 bit),P010_16( 10 bit)

What you need to support fast recompress?


[Attachment 66876 - Click to enlarge]


[Attachment 66877 - Click to enlarge]

[El Heggunte]

This is not possible for this codec. Check which filters you are using in the Direct Show pipeline or for the source.

First of all: this problem has nothing to do with DirectShow.
Secondly: yes you are right, the problem of duplicating the last frame into the first five frames has nothing to do with SIF1 itself,
it has to do with VirtualDub. Which was royally-skrewed by your crappily-coded-and-compiled DLLs;
now EVERY CODEC with which I encode through VirtualDub has that problem.
Fortunately VirtualDub2 was not affected by your evil DLLs,
so now I can finally ""upgrade"".

GOOD-BYE.

[Neiromaster]

Which was royally-skrewed by your crappily-coded-and-compiled DLLs;
now EVERY CODEC with which I encode through VirtualDub has that problem.

Anyone who knows how VFW works will say it's impossible

But thanks again for the kind and open-minded attitude.