Lossless h.264 video output not lossless because 4:2:0 chroma subsampling is applied. #61569

New Issue

Eduardo Guerras · 2019-02-15T11:14:01+01:00

Eduardo Guerras commented

2019-02-15 11:14:01 +01:00

System Information
Operating system:
Graphics card:

Blender Version
Broken:
(example: 2.79b release)
(example: 2.80, edbf15d3c0, blender2.8, 2018-11-28, as found on the splash screen)
Worked: (optional)

Tested only from the VSE and Blender 2.79b. Rendering to lossless h.264 applies 4:2:0 subsampling. This is not a problem for videos that are originally 4:2:0 as is the usual case. However if your footage is, e.g. 4:2:2 (usually the case with analog capture cards) the output will be downsampled to 4:2:0 and hence not lossless.

This happens only with lossless h.264. The other lossless output formats (i.e. HuffYUV and FFmpeg #1) do not suffer this problem.

Exact steps for others to reproduce the error

Import this example image to the VSE:
http://www.ozone3d.net/public/jegx/201412/chroma-subsampling-test-4k-tv.png
Extend it as a video strip to an arbitrary length, e.g. 10 seconds, and adjust the start and end frames accordingly.
In the properties ares, unfold ENCODING, choose container Matroska, Codec: H.264, Output quality: LOSSLESS
Then choose in Render menu, RENDER ANIMATION.
Watch the rendered video and see how the chroma has been subsampled and the characters appear blurry.
Redo steps 3 to 5 but choosing Codec: HuffYUV, and watch how the results are satisfactory and no subsampling is applied in the output video.

**System Information** Operating system: Graphics card: **Blender Version** Broken: (example: 2.79b release) (example: 2.80, edbf15d3c044, blender2.8, 2018-11-28, as found on the splash screen) Worked: (optional) Tested only from the VSE and Blender 2.79b. Rendering to lossless h.264 applies 4:2:0 subsampling. This is not a problem for videos that are originally 4:2:0 as is the usual case. However if your footage is, e.g. 4:2:2 (usually the case with analog capture cards) the output will be downsampled to 4:2:0 and hence not lossless. This happens only with lossless h.264. The other lossless output formats (i.e. HuffYUV and FFmpeg #1) do not suffer this problem. **Exact steps for others to reproduce the error** 1. Import this example image to the VSE: http://www.ozone3d.net/public/jegx/201412/chroma-subsampling-test-4k-tv.png 2. Extend it as a video strip to an arbitrary length, e.g. 10 seconds, and adjust the start and end frames accordingly. 3. In the properties ares, unfold ENCODING, choose container Matroska, Codec: H.264, Output quality: LOSSLESS 4. Then choose in Render menu, RENDER ANIMATION. 5. Watch the rendered video and see how the chroma has been subsampled and the characters appear blurry. 6. Redo steps 3 to 5 but choosing Codec: HuffYUV, and watch how the results are satisfactory and no subsampling is applied in the output video.

Eduardo Guerras commented

2019-02-15 11:14:01 +01:00

Added subscriber: @eguerras-2

Sebastian Parborg commented

2019-02-15 14:18:18 +01:00

Added subscribers: @iss, @ZedDB

Sebastian Parborg commented

2019-02-15 14:18:18 +01:00

@iss is this for you?

Richard Antalik commented

2019-02-15 15:12:07 +01:00

Added subscriber: @Sergey

Richard Antalik commented

2019-02-15 15:12:07 +01:00

@Sergey would be better to decide what to do with this.

We are converting all color formats to RGBA using ffmpeg's swscale with flags SWS_FAST_BILINEAR | SWS_PRINT_INFO | SWS_FULL_CHR_H_INT

I am not very experienced with FFMPEG. After quick google I got this clue:
From https://github.com/FFmpeg/FFmpeg/blob/master/doc/swscale.txt

Input to YUV Converter
When the input to the main path is not planar 8 bits per component YUV or 8-bit gray, it is converted to planar 8-bit YUV. Two sets of converters
exist for this currently: One performs horizontal downscaling by 2 before the conversion, the other leaves the full chroma resolution, but is slightly slower. The scaler will try to preserve full chroma when the output uses it. It is possible to force full chroma with SWS_FULL_CHR_H_INP even for cases where the scaler thinks it is useless.

similar tasks: #57397 (in video editor, clips get blurred) #60947 (FFMpeg color offset)

@Sergey would be better to decide what to do with this. We are converting all color formats to RGBA using ffmpeg's swscale with flags SWS_FAST_BILINEAR | SWS_PRINT_INFO | SWS_FULL_CHR_H_INT I am not very experienced with FFMPEG. After quick google I got this clue: From https://github.com/FFmpeg/FFmpeg/blob/master/doc/swscale.txt ``` Input to YUV Converter When the input to the main path is not planar 8 bits per component YUV or 8-bit gray, it is converted to planar 8-bit YUV. Two sets of converters exist for this currently: One performs horizontal downscaling by 2 before the conversion, the other leaves the full chroma resolution, but is slightly slower. The scaler will try to preserve full chroma when the output uses it. It is possible to force full chroma with SWS_FULL_CHR_H_INP even for cases where the scaler thinks it is useless. ``` similar tasks: #57397 (in video editor, clips get blurred) #60947 (FFMpeg color offset)

Sebastian Parborg commented

2019-02-16 11:20:08 +01:00

Closed as duplicate of #57397

Sebastian Parborg closed this issue

2019-02-16 11:20:08 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Lossless h.264 video output not lossless because 4:2:0 chroma subsampling is applied. #61569