OpenVisualCloud / SVT-HEVC

SVT HEVC encoder. Scalable Video Technology (SVT) is a software-based video coding technology that is highly optimized for Intel® Xeon® processors. Using the open source SVT-HEVC encoder, it is possible to spread video encoding processing across multiple Intel® Xeon® processors to achieve a real advantage of processing efficiency.
Other
507 stars 169 forks source link

[bug] degradation after scene change #596

Open Josua-Pannier opened 3 years ago

Josua-Pannier commented 3 years ago

Hi,

I meet a bug in svt_hevc, in some segments and for some presets and bitrates. I observe a degradation of the image after a scene change. This bug is not determinist, I run differents time my transcoding with the same commands and the errors occurs each time but not necessary on the same preset and bitrates

I join you the original segment : https://www.transfernow.net/dl/20210528AfjyUV0M the segment transcoded in svt_hevc (test1 and test2) : https://www.transfernow.net/dl/20210528f74Bzg2I

To transcode my file, I use this command :

docker run -v /mnt/bench/input_files:/mnt/bench/input_files -v /mnt/bench/svt/m6_hls_221805/1920x1080/25/0/1/great/3M/:/mnt/bench/results openvisualcloud/xeon-ubuntu1804-media-ffmpeg ffmpeg -y -i /mnt/bench/input_files/m6_hls_221805.ts -r 25/1 -s 1920x1080 -pix_fmt yuv420p -filter_complex yadif -f rawvideo -an /mnt/bench/results/input.yuv

docker run -e FFREPORT=level=48:file=/mnt/bench/results/ffmpeg.log -v /mnt/bench/input_files:/mnt/bench/input_files -v /mnt/bench/svt/m6_hls_221805/1920x1080/25/0/1/great/3M/:/mnt/bench/results openvisualcloud/xeon-ubuntu1804-media-ffmpeg /bin/bash -c ( time -p ffmpeg -y -benchmark -psnr -report -r 25/1 -s 1920x1080 -pix_fmt yuv420p -i /mnt/bench/results/input.yuv -an -c:v libsvt_hevc -r 25/1 -s 1920x1080 -pix_fmt yuv420p -rc 1 -tune 1 -b:v 3M -minrate:v 3M -maxrate:v 3M -preset 6 -profile:v 1 -bufsize 6000000.0 -level:v 0 -f mpegts -copyts -start_at_zero /mnt/bench/results/m6_hls_221805-svt-1920x1080-fps_25-profile_1-level_0-3M-preset_great.ts ) &> /mnt/bench/results/time.log

docker run -e FFREPORT=level=48:file=/mnt/bench/results/psnr.log -v /mnt/bench/input_files:/mnt/bench/input_files -v /mnt/bench/svt/m6_hls_221805/1920x1080/25/0/1/great/3M/:/mnt/bench/results openvisualcloud/xeon-ubuntu1804-media-ffmpeg ffmpeg -report -i /mnt/bench/results/m6_hls_221805-svt-1920x1080-fps_25-profile_1-level_0-3M-preset_great.ts -r 25/1 -s 1920x1080 -pix_fmt yuv420p -i /mnt/bench/results/input.yuv -filter_complex psnr -f null -

The first command transforms my input file in a yuv file. In the second, I make the transcoding. And the third command is used to calculate the PSNR

tianjunwork commented 3 years ago

Hi @Josua-Pannier , I found the clips with blocky frames after first scene change in the attachment. Just to confirm, it shows up in 1M - 3M config. With other higher bitrate, video looks good.

Josua-Pannier commented 3 years ago

Hi @tianjunwork Not necessary, in the test2, we can see the same degradation for a balanced preset with the 2M bitrate. For this clip, the degradation occurs "lowest" bitrate but it's not determinist : when I run the same transcoding differents times, the errors not necessary occurs in the same configuration

Josua-Pannier commented 3 years ago

This is the two psnr/bitrate curves I get for test 1 and test2. Test1 and test2 were realised in the same config, with the same command. test 1 : psnr en fonction du bitrate et du preset - test1 test 2 : psnr en fonction du bitrate et du preset - test2

tianjunwork commented 3 years ago

Hi @Josua-Pannier, thank you for adding detailed data. May I ask what does it mean by balanced, fast, great? There may exist a bug in rate control algorithm in low bit-rate budget condition after scene change. It will take some time to figure out.

Josua-Pannier commented 3 years ago

Hi @tianjunwork, of course : balanced mean preset 7, fast preset 8 and great preset 6.

Josua-Pannier commented 3 years ago

I test also on the following segment : https://www.transfernow.net/dl/20210615rpFFWnnZ

image The four tests are realised on the same machine, with the same commands and none other process are running. I check if the CPUs usage change between the test but no ; with the same preset and bitrate, the CPUs usage is the same whatever the test is.

I also did the same test changing the encoder by x264 and x265. In this cases, there are no problem and the results are determinist.

Thanks for your answer, I w'ill make test with higher bit-rate