Skip to content
This repository has been archived by the owner on Jul 29, 2024. It is now read-only.

[bug] degradation after scene change #596

Open
Josua-Pannier opened this issue May 28, 2021 · 6 comments
Open

[bug] degradation after scene change #596

Josua-Pannier opened this issue May 28, 2021 · 6 comments
Labels
bug Something isn't working

Comments

@Josua-Pannier
Copy link

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

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.

@tianjunwork tianjunwork added the bug Something isn't working label Jun 14, 2021
@Josua-Pannier
Copy link
Author

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

@Josua-Pannier
Copy link
Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants