Bad quality in a fast moving scenes

[Peyo_H_]

Hello, 

I need help because all my ideas are at the end.

I'm using Media Server Studio Community 2016 with Centos 7.1.

The hardware is Intel(R) Xeon(R) CPU E3-1285L.

The preset is "veryslow", h264 high 4.1 profile with VBR.

In a fast moving scenes - like foorball games, the terrain seems like a green fog. In a slow scenes it is ok. 

The source is high quality h264@13mbps 1080 and I'm trying to produce  720 at around 6mbps. I've tried different presets and

GOP sizes, but with a such bad result. With libx264 I have no "terrain fog" with "film" tine or CRF 28 at 4 mbps, but with SDK at 6 - 8 mbps the result is not in such good quality- it is unacceptable.

Even on 8 mbps the terrain is still a fog in fast scenes, Any suggestions may help. 

I've tried LA with different depths  with no result.

Thank you.

[Jeffrey_M_Intel1]

Hi Peyo,

As you know, there are many factors affecting quality.  Is there a way you could send us some test content showing this behavior?  If you have concerns about distributing your content, can it be reproduced on a publicly available sequence?  This could help us to understand what is happening and offer better suggestions. 

Thanks, Jeff

[Peyo_H_]

Hi Jeffrey,

Original file: http://213.167.17.11:8082/ts/ringbg_1080_original.ts

Media SDK encoded files from the original, 6, 7 and 8 mbps VBR

http://213.167.17.11:8082/ts/ringbg_720_6mbps.ts

http://213.167.17.11:8082/ts/ringbg_720_7mbps.ts

http://213.167.17.11:8082/ts/ringbg_720_8mbps.ts

And libx264 encoded files with different CRF 26 and 28

http://213.167.17.11:8082/ts/ringbg_720_libx264_crf26.ts

http://213.167.17.11:8082/ts/ringbg_720_libx264_crf28.ts

The issue can be clearly seen at 0:40 sec  in the terrain details with camera fast moving.

BRS/

Peyo

[Jeffrey_M_Intel1]

Hi Peyo,

Thanks for the clip and description. I'm hoping to do a few more tests with a broader range of settings, but the first thing to consider is that CRF and VBR/LA are very different algorithms.  VBR and variants like lookahead attempt to maintain a specified bitrate, changing quality to do so.  CRF allows wide variations in bitrate to maintain a quality level.  If those large variations in bitrate are acceptable then a CRF-like algorithm could get better quality.  Media SDK doesn't implement an exact equivalent to CRF, but ICQ and QVBR are much more similar than VBR/LA.

You mentioned "veryslow" as a preset.  Are you comparing x264 and Media SDK within FFmpeg?  If so, could you send the command lines you're using?

[Peyo_H_]

Hi Jeffrey,

Yes. For the files I sent I'm using ffmpeg 3.0.2. Video options are here (additional audio options are not shown):

ffmpeg -loglevel verbose   -i original.ts  -map 0:v -vcodec h264_qsv -profile  high -level 41 -preset veryslow -s 1280x720    -b:v 7000k -minrate 5000k -maxrate 13000k  -bufsize:v 2.8M -pix_fmt nv12 -g 25 -f mpegts output.ts

Just to mention - original file is with TFF interlaced frames, but the output is with progressive frames even no VPP is used in qsvenc.c I don't know why the output is de-interlaced. In the ffmpeg command line I don't have any filters before video settings row.

BTW, here is a file created with x264 and VBR

ffmpeg -loglevel verbose -re  -i original.ts   -map 0:v -vcodec libx264  -profile  high -level 41 -s 1280x720    -b:v 6000k -minrate 1000k -maxrate 10000k  -bufsize:v 2.8M -pix_fmt nv12 -g 25  -map 0:a:0 -c:a:0 mp2  -flush_packets 0 -f mpegts  output.ts

ttp://213.167.17.11:8082/ts/video_720_libx264_vbr_6mbps.ts

BRS/

Peyo

[Peyo_H_]

Hi Jeffrey,

I have some update. 

In this row, 

ffmpeg -loglevel verbose   -i original.ts  -map 0:v -vcodec h264_qsv -profile  high -level 41 -preset veryslow -s 1280x720    -b:v 7000k -minrate 5000k -maxrate 13000k  -bufsize:v 2.8M -pix_fmt nv12 -g 25 -f mpegts output.ts

Two things happens:

1) the default qsv_h264 -look_ahead option is true, so MFX_RATECONTROL_LA is used instead of MFX_RATECONTROL_VBR as I expected

2) because of (1), -maxrate 13000k option is ignored, because MaxKbps info struct member is not valid in LA mode

3) Scaling from original 1920x1080 to 1280x720 (-s 1280x720) always produce progressive output (who did the de-interlace?) . If I do not scale, then the output is interlaced as the original. 

But even then, when VBR is used and the video isn't scaled, I'm not able to produce suitable result. 

PS, I'm unable to try ICQ mode, because it isn't supported on Linux.

BRS 

[Peyo_H_]

Hi Jeffrey,

are you able to reproduce this issue?

Peyo

[Jeffrey_M_Intel1]

I can reproduce.   QP values for macroblocks are higher in the region around 40 seconds in, especially for CRF (for libx264) vs. lookahead (for MSDK, similar to VBR).   However, in many regions of the video Media SDK quality is closer.  I don't know if there is a simple parameter change to suggest to fix this but will keep looking.  Increasing lookahead depth is a good start.

[Peyo_H_]

Hello.

Here is the result with LA depth 100 (max). I'm not sure that the result is better.

http://213.167.17.11:8082/ts/video_720_ladepth_100.ts

[Peyo_H_]

Thank you yups,

deinterlace before scale filter or after that?