VideoHelp Forum

+ Reply to Thread
Results 1 to 30 of 30
Thread
  1. 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
    Quote Quote  
  2. Member
    Join Date
    Feb 2004
    Location
    United States
    Search Comp PM
    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.

    Code:
    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.

    Code:
    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?
    PB
    Quote Quote  
  3. Hi autodidact,

    Give us a moment to check and we'll return to you shortly.
    Quote Quote  
  4. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    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).

    Code:
    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).
    Last edited by El Heggunte; 17th Sep 2022 at 22:11. Reason: better wording
    "Programmers are human-shaped machines that transform alcohol into bugs."
    Quote Quote  
  5. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    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...
    Quote Quote  
  6. 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
    Quote Quote  
  7. 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
    Quote Quote  
  8. Originally Posted by autodidact View Post
    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.
    Quote Quote  
  9. 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
    Image Attached Files
    Quote Quote  
  10. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    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.
    Quote Quote  
  11. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by BlackQ View Post
    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.

    Image
    [Attachment 66855 - Click to enlarge]
    "Programmers are human-shaped machines that transform alcohol into bugs."
    Quote Quote  
  12. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    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.
    Quote Quote  
  13. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Originally Posted by Neiromaster View Post
    mingv
    Minimalist GNU for Windows
    Quote Quote  
  14. Member
    Join Date
    Feb 2004
    Location
    United States
    Search Comp PM
    Originally Posted by BlackQ View Post
    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".
    PB
    Quote Quote  
  15. Member
    Join Date
    Feb 2004
    Location
    United States
    Search Comp PM
    Originally Posted by LigH.de View Post
    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

    Code:
    #!/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.
    Last edited by autodidact; 18th Sep 2022 at 18:43.
    PB
    Quote Quote  
  16. Member
    Join Date
    Feb 2004
    Location
    United States
    Search Comp PM
    It looks like SSE4.1 was the issue on the machine where I tested ConsoleEnc.exe so thank you for that information.
    PB
    Quote Quote  
  17. Member
    Join Date
    Feb 2004
    Location
    United States
    Search Comp PM
    With the latest patch ffmpeg is now working with the SIF libraries. Thank you!
    PB
    Quote Quote  
  18. [QUOTE=El Heggunte;2667706]
    Originally Posted by BlackQ View Post
    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.

    Image
    [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
    Image Attached Files
    Quote Quote  
  19. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    @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.
    Image Attached Thumbnails Click image for larger version

Name:	DX50-source.png
Views:	7
Size:	72.5 KB
ID:	66861  

    Click image for larger version

Name:	SIF1-result.png
Views:	8
Size:	2.37 MB
ID:	66862  

    "Programmers are human-shaped machines that transform alcohol into bugs."
    Quote Quote  
  20. Originally Posted by El Heggunte View Post
    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...
    Image Attached Files
    Quote Quote  
  21. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    Originally Posted by autodidact View Post
    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.
    Last edited by LigH.de; 19th Sep 2022 at 03:41.
    Quote Quote  
  22. Originally Posted by LigH.de View Post
    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.
    Quote Quote  
  23. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    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).
    Last edited by LigH.de; 19th Sep 2022 at 09:51.
    Quote Quote  
  24. Originally Posted by LigH.de View Post

    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.
    Quote Quote  
  25. Member
    Join Date
    Aug 2013
    Location
    Central Germany
    Search PM
    I could agree to saying it seems to be one of the better Wavelet motion codecs yet. And there are not many.
    Quote Quote  
  26. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    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.
    "Programmers are human-shaped machines that transform alcohol into bugs."
    Quote Quote  
  27. Originally Posted by El Heggunte View Post
    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

    Originally Posted by El Heggunte View Post

    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.
    Quote Quote  
  28. Originally Posted by El Heggunte View Post

    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?

    Image
    [Attachment 66876 - Click to enlarge]


    Image
    [Attachment 66877 - Click to enlarge]
    Last edited by Neiromaster; 19th Sep 2022 at 13:22.
    Quote Quote  
  29. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by Neiromaster View Post
    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.
    "Programmers are human-shaped machines that transform alcohol into bugs."
    Quote Quote  
  30. Originally Posted by El Heggunte View Post
    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.
    Quote Quote  



Similar Threads