ultravideo / uvg266 Goto Github PK

Sorry for being so late, I encountered this problem several months ago.
Build is successful but when actually running the built binary the error occurs.
(mingw-w64 is used for building)
I've made a simple workaround, which appears to bypass the problem.
L4cache@484f5aa

https://github.com/ultravideo/uvg266/blob/master/CMakeLists.txt#L227

the .pc file is installed into $PREFIX/share/pkgconfig, however, nothing uses that directory, the most common subdirectory is lib/pkgconfig and is usually used as the default for pkg-config

One option to address this would be something like

-install(FILES ${PROJECT_SOURCE_DIR}/src/uvg266.pc DESTINATION ${CMAKE_INSTALL_PREFIX}/share/pkgconfig)
+install(FILES ${PROJECT_SOURCE_DIR}/src/uvg266.pc DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/pkgconfig)

another would be

-install(FILES ${PROJECT_SOURCE_DIR}/src/uvg266.pc DESTINATION ${CMAKE_INSTALL_PREFIX}/share/pkgconfig)
+install(FILES src/uvg266.pc DESTINATION lib/pkgconfig)

as according to cmake's docs, https://cmake.org/cmake/help/latest/command/install.html,

DESTINATION

Specify the directory on disk to which a file will be installed. Arguments can be relative or absolute paths.

If a relative path is given it is interpreted relative to the value of the CMAKE_INSTALL_PREFIX variable
...
The FILES form specifies rules for installing files for a project. File names given as relative paths are interpreted with respect to the current source directory.

and another alternative that would probably be preferred would be to use the GNUInstallDirs module which has been provided by CMake for a while https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html and it would look something like

include(GNUInstallDirs)
...

install(FILES src/uvg266.pc DESTINATION ${LIBDIR}/pkgconfig)

as that would handle distro specific quirks related to their lib directory such as lib32 or lib64 etc, so long as the distro sends their changes upstream and so on.

As far as I can tell, there is no way to pipe input into the encoder, making it difficult to use. Any chance we could see this in the future?

I have a problem with video decoding. https://www.sendspace.com/file/204ph0
I use gcc 12.0.1 20220429. http://msystem.waw.pl/x265/mingw-gcc1201-20220429.7z
I use plugins for gcc thread/mutex/future/condition_variable
https://github.com/Jamaika1/mingw_std_threads

euvg266.exe -i "113.y4m" -o "output_10bit.vvc" --no-info --input-bitdepth 8 --threads 4 --input-res 1280x720 --input-fps 30000/1001 --input-format P420 --ref 15 --gop lp-g16d5t3 -p 256 --bitrate 3000000 -n 200 --preset medium

https://github.com/fraunhoferhhi/vvdec
VVDecoderApp.exe -b output_10bit.266 -o rrr.yuv

ERROR: In function "void vvdec::InputBitstream::read(uint32_t, uint32_t&)" in BitStream.cpp:283: Exceeded FIFO size
ERROR CONDITION: m_fifo_idx + num_bytes_to_load >= m_fifo.size()

And presumably on all non x86_64 architectures.

See build log.

(OS: openSUSE Tumbleweed)

When using the encoder option --stats-file-prefix, the stats files get created but not created.

From looking at the code in src/rate_control.c, where all the file manipulation seems to happen from what I could understand, it seems the files get created when the uvg_get_rc_data functions get called and they get written when the function uvg_update_after_picture gets called.

However, the function uvg_update_after_picture never seems to get called, leading to the files never being written. I've confirmed that the function doesn't get called by placing a dummy print inside and it never prints anything out. I've also grepped the src directory and seems this function is just never invoked anywhere.

To add this functionality where would it make the most sense to call the update function so that we get the stats printed to the file?

Thanks for the help in advance :)!

1. Your build sequence documented in the repo's readme generates not a makefile but a build.ninja instead; so you may replace make by ninja.
2. Many files fail compiling, error messages relate to intrinsics. I guess this requires different configuration options? (I tested that in an interactive shell of an MSYS2/MinGW64 environment provided and kept up-to-date by the media-autobuild suite.)

$ ninja > linja.log
...
E:/MABS/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/11.3.0/include/tmmintrin.h:40:1: error: inlining failed in call to 'always_inline' '_mm_hadd_epi16': target specific option mismatch
   40 | _mm_hadd_epi16 (__m128i __X, __m128i __Y)
      | ^~~~~~~~~~~~~~
E:/MABS/build/uvg266-git/src/strategies/sse41/alf-sse41.c:140:7: note: called from here
  140 |       _mm_storeu_si128((__m128i*) & colSums[i >> 1][j], _mm_hadd_epi16(t, all));
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from E:/MABS/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/11.3.0/include/immintrin.h:39,
                 from E:/MABS/build/uvg266-git/src/strategies/sse41/alf-sse41.c:40:
E:/MABS/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/11.3.0/include/smmintrin.h:166:1: error: inlining failed in call to 'always_inline' '_mm_blend_epi16': target specific option mismatch
  166 | _mm_blend_epi16 (__m128i __X, __m128i __Y, const int __M)
      | ^~~~~~~~~~~~~~~
E:/MABS/build/uvg266-git/src/strategies/sse41/alf-sse41.c:139:25: note: called from here
  139 |       const __m128i t = _mm_blend_epi16(all, prev, 0xaa);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

ninja.log

subj

I want to congratulate with the author for this project. This library takes half of the time to execute a compression task compared to the other ones!

I play the videos through a VLC plugin. Is very convenient, but I'm not sure is really the best way.
This is how I do the compression:
./ffmpeg -i "input.mp4" -pix_fmt yuv420p "input.yuv"
./uvg266 -i "input.yuv" --input-res=1920x1080 --input-fps=30 --qp=30 --preset=veryslow -o "input.vvc"

I have some questions.

• 1080p videos lags while playing. Is there a particular setting I could apply to the conversion process in order to fix this? Or any other change I could do to the source before the conversion? Or any other post compression task? When compressed in AV1, the videos play perfectly well.
• Is there some other settings I could apply to the conversion (and to the source too) to obtain an higher compression ratio?
• How can I enable seeking? Once the video starts I can only see from the beginning to the end.
• I saw that the job is done through CPU. Is there a way to utilize Nvidia GPU?

Many thanks

I wonder what are pthread.cpp and semaphore.cpp for?
I compiled the add-ons in C++11 and was unable to merge the codec.
I had to use libpthread. Is that good thinking?

It could be nice to support P444 as an input to have proper lossless encoding, e.g. given some PNGs. Thx for your work!

subj

This is not an actual issue but a question. Is a prebuilt windows version of UVG266 available for download? I did not see any available assets on the Appveyor build page.