High bitdepth (> 8): Could not find a strategy for crc32c_8x8!

[L4cache]

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. https://github.com/L4cache/uvg266/commit/484f5aa2cbe7a74e76e3da0ff264ebe74b245f67

[Jovasa]

Yes, we are aware of this and will fix it eventually. We haven't had the time to put too much effort on 10 bit encoding, thus there might be some problems with it.

[L4cache]

Thanks, but before the real fix happens, is my workaround safe to use though? At least it can make the encoder produce bitstream rather than exits immediately, but I see Windows logs error in event log whenever the high bitdepth encoder "finishes" encode, I'm not sure if it's gonna break my encoding result. By the way, the 8-bit encoder outputs bitstream with Main10 profile... I know it's in spec, but is it intentional?

[Jovasa]

Thanks, but before the real fix happens, is my workaround safe to use though?

As long as you don't use IBC, it should be OK.

At least it can make the encoder produce bitstream rather

Have you verified with VTM that the encoded bistream is valid?

I see Windows logs error in event log whenever the high bitdepth encoder "finishes" encode, I'm not sure if it's gonna break my encoding result.

Sound like the encoder might crash on when closing itself. This should not affect the produced bitstream. If I have time next week I'll try to investigate.

By the way, the 8-bit encoder outputs bitstream with Main10 profile... I know it's in spec, but is it intentional?

Currently the profile is hard coded so it defaults to the one that allows widest range of outputs.

[fador]

By the way, the 8-bit encoder outputs bitstream with Main10 profile... I know it's in spec, but is it intentional?

I can add to this that I believe the Main profile used in previous standards was removed and Main10 is the new basic profile to be used also for 8-bit coding.

[L4cache]

Hi, I found that the "crash on exit" is caused by this https://github.com/ultravideo/uvg266/blob/3e66a897d490da5c297197fd326c79a58d037be9/src/encoder.c#L697-L699

Not 100% sure, in fact, because I don't understand why. But there're no longer crash reports after I comment out this piece of code.

[Eric3495]

邮件发到~~

[Jovasa]

Thanks, I just pushed cc1fd00 that should fix the crash and also introduces a temporary fix for the strategy not found.

[L4cache]

Thanks, that works well. Shall I keep this issue open because the strategy not found fix is temporary?

[Jamaika1]

For UVG_BIT_DEPTH=10

transform.c: In function 'uvg_chroma_transform_search':
transform.c:717:31: warning: passing argument 2 of 'uvg_pixels_blit' from incompatible pointer type [-Wincompatible-pointer-types]
  717 |       uvg_pixels_blit(u_pred, &u_recon[trans_offset * i], width, height, width, width);
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |                               |
      |                               uint8_t * {aka unsigned char *}
In file included from cu.h:42,
                 from transform.h:41,
                 from transform.c:33:
image.h:118:56: note: expected 'uvg_pixel *' {aka 'short unsigned int *'} but argument is of type 'uint8_t *' {aka 'unsigned char *'}
  118 | void uvg_pixels_blit(const uvg_pixel* orig, uvg_pixel *dst,
      |                                             ~~~~~~~~~~~^~~
transform.c:758:31: warning: passing argument 2 of 'uvg_pixels_blit' from incompatible pointer type [-Wincompatible-pointer-types]
  758 |       uvg_pixels_blit(v_pred, &v_recon[trans_offset * i], width, height, width, width);
      |                               ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |                               |
      |                               uint8_t * {aka unsigned char *}
In file included from cu.h:42,
                 from transform.h:41,
                 from transform.c:33:
image.h:118:56: note: expected 'uvg_pixel *' {aka 'short unsigned int *'} but argument is of type 'uint8_t *' {aka 'unsigned char *'}
  118 | void uvg_pixels_blit(const uvg_pixel* orig, uvg_pixel *dst,
      |                                             ~~~~~~~~~~~^~~
transform.c:762:56: warning: passing argument 2 of 'uvg_pixels_calc_ssd' from incompatible pointer type [-Wincompatible-pointer-types]
  762 |       ssd_u = uvg_pixels_calc_ssd(&lcu->ref.u[offset], &u_recon[trans_offset * i],
      |                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                        |
      |                                                        uint8_t * {aka unsigned char *}
transform.c:762:56: note: expected 'const uvg_pixel * const' {aka 'const short unsigned int * const'} but argument is of type 'uint8_t *' {aka 'unsigned char *'}
transform.c:765:56: warning: passing argument 2 of 'uvg_pixels_calc_ssd' from incompatible pointer type [-Wincompatible-pointer-types]
  765 |       ssd_v = uvg_pixels_calc_ssd(&lcu->ref.v[offset], &v_recon[trans_offset * i],
      |                                                        ^~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                        |
      |                                                        uint8_t * {aka unsigned char *}
transform.c:765:56: note: expected 'const uvg_pixel * const' {aka 'const short unsigned int * const'} but argument is of type 'uint8_t *' {aka 'unsigned char *'}

Mayby:

if UVG_BIT_DEPTH == 8

ALIGNED(64) uint8_t u_recon[LCU_WIDTH_C LCU_WIDTH_C 5]; ALIGNED(64) uint8_t v_recon[LCU_WIDTH_C LCU_WIDTH_C 5];

else

ALIGNED(64) uint16_t u_recon[LCU_WIDTH_C LCU_WIDTH_C 5]; ALIGNED(64) uint16_t v_recon[LCU_WIDTH_C LCU_WIDTH_C 5];

endif

[Jamaika1]

ffmpeg_avx.exe -v verbose -hwaccel opencl -init_hw_device opencl=gpu:0.0 -filter_hw_device gpu -i "input.mp4" -y -c:v libuvg266 -vb 3000k -c:a aac -ac 2 -ar 48000 -ab 128k -s 1920x1080 -frames:v 1000 -pix_fmt yuv420p10le output_uvg266.mkv

Assertion ((dst_linesize) >= 0 ? (dst_linesize) : (-(dst_linesize))) >= bytewidth failed at imgutils.c:351 frame= 0 fps=0.0 q=0.0 size= 1KiB time=N/A bitrate=N/A speed=N/A

[L4cache]

ffmpeg_avx.exe -v verbose -hwaccel opencl -init_hw_device opencl=gpu:0.0 -filter_hw_device gpu -i "input.mp4" -y -c:v libuvg266 -vb 3000k -c:a aac -ac 2 -ar 48000 -ab 128k -s 1920x1080 -frames:v 1000 -pix_fmt yuv420p10le output_uvg266.mkv

Assertion ((dst_linesize) >= 0 ? (dst_linesize) : (-(dst_linesize))) >= bytewidth failed at imgutils.c:351 frame= 0 fps=0.0 q=0.0 size= 1KiB time=N/A bitrate=N/A speed=N/A

Where can I get the ffmpeg integration patch?

[Jamaika1]

ffmpeg 8bit uvg266 https://www.sendspace.com/file/yvyxkj plugins uvg266 https://github.com/Jamaika1/plugins_ffmpeg_vvc_evc_htj2k/commit/cdb27363877b39811c17bd2c26c2d237422fccf1

[fador]

This issue should be fixed with the latest commits so closing