kvazaar icon indicating copy to clipboard operation
kvazaar copied to clipboard

mosaic appears when encoded with --bitrate option

Open KayTsao opened this issue 6 years ago • 3 comments

Hi, I'm using kvazaar to encode tiled video content. Everything's OK when I use -q to encode, however if I set the target bitrate by --bitrate, some of the output frames will be contaminated by mosaic. I'm using the following command: kvazaar -i video.yuv --input-res 3584x1792 -o video_10M.hvc --tiles-width-split u8 --tiles-height-split u4 --slices tiles --mv-constraint frametilemargin --bitrate 10000000 --period 30 --input-fps 30 (when I use the default qp(22) to encode, the output bitrate is about 10Mbps.) I tried to encode without tiling, but the mosaic still exist. Any idea what's going wrong? May I avoid this by changing some configs? Thanks a lot!

KayTsao avatar Aug 31 '18 08:08 KayTsao

Hi,

I guess you mean you are seeing tile borders since you talk about mosaic.

Rate control in Kvazaar is not particularly smart and it seems to be broken with tiles. This is prone to be fixed at some point.

Nevertheless, encoding with small tiles can be a bit problematic especially if there is a lot of movement. There will be huge artifacts if Kvazaar can not stay within the given bitrate limit.

You could try to set one of the slower presets. Probably not going to make a huge difference but who knows.

Also, rate control seems to be quite a lot more accurate with intra frames. It might be worth a shot to try some ridiculously low intra periods (even as low as 1).

Hope this helps.

Arizer avatar Sep 03 '18 17:09 Arizer

Thank you for the tips!

Yep, the tile borders can be seen sometimes, but I'm seeing blocking artifacts much smaller than tile size.

I tried to encode without tiling:

  1. Encode using kvazaar kvazaar -i Video.yuv --input-res 896x896 -o kvz_1M.hvc --bitrate 1000000 --period 30 --input-fps 30
  2. Convert to mp4 ffmpeg -i kvz_1M.hvc -c:v copy kvz_1M.mp4
  3. Encode using libx265(for comparison) ffmpeg -s 896x896 -r 30 -pix_fmt yuv420p -i Video.yuv -c:v libx265 -x265-params keyint=30:no-open-gop -b:v 1M x265_1M.mp4

Artifacts can be found at 00:00:05 in kvz_1M.mp4, I extracted the 150th frame from kvz_1M.mp4 and x265_1M.mp4 as frame#150_kvz.png and frame#150_x265.png.

Files mentioned above are uploaded for clarity. https://www.dropbox.com/sh/dwpc41mrg913so1/AAA3qoRUFWOXg_KmNBJhbvOya?dl=0

I noticed that during the artifacts, 'gop_target_bits' calculated by gop_allocate_bits() was negative and clipped to 200. Is this the reason?

Thanks!

KayTsao avatar Sep 04 '18 03:09 KayTsao

Hi,

Thanks for the example files, they are very helpful. There seems to be multiple things that throw the rate estimation off. Therefore Kvazaar runs out of bits to use and sets the QP to the maximum value and the blocks become visible.

Unfortunately I could not think of a nice and reliable workaround for this issue. We just need a more intelligent rate control, which is hopefully implemented during the next few months. The current one might not be good enough even when fixed.

Best solution for the example video at the moment is probably to encode the intro and the rest separately (--seek option) and concatenate the bitstreams afterwards with lets say FFmpeg. This way the rate control does not have to cope with the scenecut. There is no scenecut detection implemented yet.

PS. The allocated bits are not actually clipped to 200. That part ensures that there will be at least 200 bits budget. Great observation though.

Arizer avatar Sep 24 '18 12:09 Arizer