Page MenuHome

in video editor, clips get blurred
Open, Confirmed, MediumPublic


System Information
Ubuntu 18.10, running on intel haswell graphics.

Blender Version
Broken: 2.79 release from Ubuntu Apt. 2.8 build from 4th October had this problem as well.

Short description of error
When a video is passed through blender video editor, the detail is reduced(gets blurred), as if it is averaging 2x2 pixels for each one or something. The resolution in blender is identical to that of the video clip, so it should not do any scaling that could cause that. The resolution of my video is 2880x1080.

Exact steps for others to reproduce the error
Here is a frame after passing through blender:

Here's how it should look:

Open them in browser tabs and do Ctrl+tab between them to see the difference clearly - focus on the cars and road lines to see detail loss, also zoom in if screen resolution is lower than video.

Blend file and shortened video:



Event Timeline

Sebastian Parborg (zeddb) triaged this task as Confirmed, Medium priority.

@Richard Antalik (ISS) I'm guessing this is because we don't just take the raw input and output it? (There is some conversions going on in the pipeline first)

Richard Antalik (ISS) lowered the priority of this task from Confirmed, Medium to Needs Information from User.

@Sebastian Parborg (zeddb) That shouldn't be the case.

@ilia sibiryakov (ilia3101) Can not reproduce (2.8 build) this when exporting image provided to PNG.
Can you send .blend with export settings that would reproduce issue? Maybe short movie with the same codec, if this is movie->PNG issue.
There is some color shift too, which shouldn't be there with settings of .blend file you provided...

Nice lens though...

@Richard Antalik (ISS) I used the provided .blend file and saved the provided video clip in the same folder.
Then I compared the output to the "how it should look" image.
Did you also use the .mov file?

Sorry it tried to embed movie, but I can't display it... I see it now, will test again.

Richard Antalik (ISS) raised the priority of this task from Needs Information from User to Confirmed, Medium.

Ok, so I can confirm this. There are 2 issues:

Pixel format conversion glitch:
In this image(top 3 pixels is reference image, bottom 3 "decoded" image), it is clear, that image is stretched by 1 pixel

Issue is in FFMPEG's swscale in anim_movie.c when converting to AV_PIX_FMT_RGBA, as changing flag SWS_FAST_BILINEAR to SWS_BILINEAR or SWS_BICUBIC seems to produce correct result.
swscale with any of those 3 flags was done in about 60ms.

Invalid colorspace:
May be same/similar to T60947: FFMpeg color offset but not sure...

I will look at this later this week and see if I will be able to fix this.

Please read this, because it it of key importance here:

  1. This blurring does NOT happen when choosing Codec: HuffYUV. The output in HuffYUV codec is lossless, pixel by pixel.
  2. This blurring does NOT happen if the original video has chroma subsampling 4:2:0.
  3. To see this blurring, you need both the following characteristics:

(a) Original footage that was either 4:2:2 or 4:4:4, and
(b) Rendering to lossless H.264 Codec (though I have not tried any codecs other than H.264 and HuffYUV).

Hence, the problem is as follows: when encoding in H.264, a 4:2:0 chroma subsampling is applied, no matter if the user chooses the 'lossless' option. If the HuffYUV codec (lossless) is chosen, the output is 4:4:4 and the full resolution is preserved.

Tested in Blender 2.79b. To reproduce, just import this image and make a few seconds video out of it:

Try the codec HuffYUV, and compare with H.264 lossless (Codec: H.264, Output quality: Lossless).

Many users do not notice this problem because most domestic cameras, and well as any footage ripped from DVD, Bluray and YouTube, is 4:2:0. You'll notice the subsampling only when you import pictures or get 4:2:2 footage from capturing video with special devices. I am getting around it by encoding to HuffYUV and then transcoding the final video externally.

This is confirmed in 2.80, hash 0e78e3038d02, Linux 64-bit. Please see the attached .blend files, both rendering a 1 min video of the attached picture chroma.png.

I attach the corresponding screen captures where the results can be compared:

This is the result of creating a h.264 allegedly lossless video:

And this is the result of creating a huffyuv lossless video. See the text crisp and clear:

The importance of this bug has been deemed only 'medium', probably because there the workaround of using HuffYUV to later transcode outside Blender, but those HuffYUV files are enormous.