in video editor, clips get blurred #57397

Closed
opened 4 years ago by stevefredpatrick · 16 comments

Look at my last comment for more accurate report!!!

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:
AfterBlender.png
Here's how it should look:
beforeBlender.png

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:
demo.blend
M17-0001_short.mov

**Look at my last comment for more accurate report!!!** **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: ![AfterBlender.png](https://archive.blender.org/developer/F5246546/AfterBlender.png) Here's how it should look: ![beforeBlender.png](https://archive.blender.org/developer/F5246598/beforeBlender.png) 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: [demo.blend](https://archive.blender.org/developer/F5246717/demo.blend) [M17-0001_short.mov](https://archive.blender.org/developer/F5246723/M17-0001_short.mov)
Poster

Added subscriber: @stevefredpatrick

Added subscriber: @stevefredpatrick
Collaborator

#61569 was marked as duplicate of this issue

#61569 was marked as duplicate of this issue
ZedDB commented 4 years ago
Collaborator

Added subscribers: @iss, @ZedDB

Added subscribers: @iss, @ZedDB
iss was assigned by ZedDB 4 years ago
ZedDB commented 4 years ago
Collaborator

@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)

@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)
iss commented 4 years ago
Collaborator

@ZedDB That shouldn't be the case.

@stevefredpatrick 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...

@ZedDB That shouldn't be the case. @stevefredpatrick 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...
ZedDB commented 4 years ago
Collaborator

@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?

@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?
iss commented 4 years ago
Collaborator

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

Sorry it tried to embed movie, but I can't display it... I see it now, will test again.
iss commented 4 years ago
Collaborator

Added subscriber: @Sergey

Added subscriber: @Sergey
iss commented 4 years ago
Collaborator

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
diff2.png

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 #60947 (FFMpeg color offset) but not sure...

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

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 ![diff2.png](https://archive.blender.org/developer/F6522271/diff2.png) 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 #60947 (FFMpeg color offset) but not sure... I will look at this later this week and see if I will be able to fix this.
ZedDB commented 4 years ago
Collaborator

Added subscriber: @eguerras-2

Added subscriber: @eguerras-2

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:
http://www.ozone3d.net/public/jegx/201412/chroma-subsampling-test-4k-tv.png

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.

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: http://www.ozone3d.net/public/jegx/201412/chroma-subsampling-test-4k-tv.png 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 0e78e3038d, Linux 64-bit. Please see the attached .blend files, both rendering a 1 min video of the attached picture chroma.png.
chroma.h264.blend

chroma.huffyuv.blend

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:
screen.capture.of.h.264.video.png

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

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.

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. [chroma.h264.blend](https://archive.blender.org/developer/F6917202/chroma.h264.blend) [chroma.huffyuv.blend](https://archive.blender.org/developer/F6917201/chroma.huffyuv.blend) ![chroma.png](https://archive.blender.org/developer/F6917200/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: ![screen.capture.of.h.264.video.png](https://archive.blender.org/developer/F6917205/screen.capture.of.h.264.video.png) And this is the result of creating a huffyuv lossless video. See the text crisp and clear: ![screen.capture.of.huffyuv.video.png](https://archive.blender.org/developer/F6917206/screen.capture.of.huffyuv.video.png) 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.
Poster

Ok I went back to this. The colour difference in the example is my mistake, I think I originally took a screenshot of GNOME video player (it changes the colours when no one asks it to).

Complete method to replicate the bug:

  1. Set blender resolution to 2880x1080, 100%

  2. Enter video editor mode

  3. Import the video sample I provided in first post

  4. Render a frame, save it as a PNG

  5. Open that clip in VLC and take a snapshot, will save a PNG

  6. Compare

Here is a clearer comparison I made using this method:

Video_VLC.png

Video_Blender.png

To me it looks like actual blurring, not just chroma 4:2:0 conversion. But I may be wrong. At least there is no colour difference, sorry for the original low quality report.

In #57397#614243, @iss wrote:
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
diff2.png

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.

I think you are completely right about this!

It is a bit odd that resizing is done even when the image does not need to be resized.

Ok I went back to this. The colour difference in the example is my mistake, I think I originally took a screenshot of GNOME video player (it changes the colours when no one asks it to). Complete method to replicate the bug: 1. Set blender resolution to 2880x1080, 100% 2. Enter video editor mode 3. Import the video sample I provided in first post 4. Render a frame, save it as a PNG 5. Open that clip in VLC and take a snapshot, will save a PNG 6. Compare Here is a clearer comparison I made using this method: ![Video_VLC.png](https://archive.blender.org/developer/F7681999/Video_VLC.png) ![Video_Blender.png](https://archive.blender.org/developer/F7682005/Video_Blender.png) To me it looks like actual blurring, not just chroma 4:2:0 conversion. But I may be wrong. At least there is no colour difference, sorry for the original low quality report. > In #57397#614243, @iss wrote: > 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 > ![diff2.png](https://archive.blender.org/developer/F6522271/diff2.png) > > 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. > I think you are completely right about this! It is a bit odd that resizing is done even when the image does not need to be resized.
iss was unassigned by dfelinto 3 years ago
Collaborator

This issue was referenced by 13ab6b7bb6

This issue was referenced by 13ab6b7bb60c3af82c6f99c2177f2fb2576ccd22
Collaborator

This issue was referenced by 1f55786791

This issue was referenced by 1f557867916bd6ab43ced4b4fd651a7d1d11f8ac
iss commented 2 years ago
Collaborator

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
iss closed this issue 2 years ago
iss self-assigned this 2 years ago
Sign in to join this conversation.
No Label
Interest/Alembic
Interest/Animation & Rigging
Interest/Asset Browser
Interest/Asset Browser Project Overview
Interest/Audio
Interest/Automated Testing
Interest/Blender Asset Bundle
Interest/Collada
Interest/Compositing
Interest/Core
Interest/Cycles
Interest/Dependency Graph
Interest/Development Management
Interest/Eevee & Viewport
Interest/Freestyle
Interest/Geometry Nodes
Interest/Grease Pencil
Interest/ID Management
Interest/Images & Movies
Interest/Import/Export
Interest/Line Art
Interest/Masking
Interest/Modeling
Interest/Modifiers
Interest/Motion Tracking
Interest/Nodes & Physics
Interest/Overrides
Interest/Performance
Interest/Performance
Interest/Physics
Interest/Pipeline, Assets & I/O
Interest/Platforms, Builds, Tests & Devices
Interest/Python API
Interest/Render & Cycles
Interest/Render Pipeline
Interest/Sculpt, Paint & Texture
Interest/Text Editor
Interest/Translations
Interest/Triaging
Interest/Undo
Interest/USD
Interest/User Interface
Interest/UV Editing
Interest/VFX & Video
Interest/Video Sequencer
Interest/Virtual Reality
legacy module/Animation & Rigging
legacy module/Core
legacy module/Development Management
legacy module/Eevee & Viewport
legacy module/Grease Pencil
legacy module/Modeling
legacy module/Nodes & Physics
legacy module/Pipeline, Assets & IO
legacy module/Platforms, Builds, Tests & Devices
legacy module/Python API
legacy module/Rendering & Cycles
legacy module/Sculpt, Paint & Texture
legacy module/Triaging
legacy module/User Interface
legacy module/VFX & Video
legacy project/1.0.0-beta.2
legacy project/Asset Browser (Archived)
legacy project/BF Blender: 2.8
legacy project/BF Blender: After Release
legacy project/BF Blender: Next
legacy project/BF Blender: Regressions
legacy project/BF Blender: Unconfirmed
legacy project/Blender 2.70
legacy project/Code Quest
legacy project/Datablocks and Libraries
legacy project/Eevee
legacy project/Game Animation
legacy project/Game Audio
legacy project/Game Data Conversion
legacy project/Game Engine
legacy project/Game Logic
legacy project/Game Physics
legacy project/Game Python
legacy project/Game Rendering
legacy project/Game UI
legacy project/GPU / Viewport
legacy project/GSoC
legacy project/Infrastructure: Websites
legacy project/LibOverrides - Usability and UX
legacy project/Milestone 1: Basic, Local Asset Browser
legacy project/Nodes
legacy project/OpenGL Error
legacy project/Papercut
legacy project/Pose Library Basics
legacy project/Retrospective
legacy project/Tracker Curfew
legacy project/Wintab High Frequency
Meta/Good First Issue
Meta/Papercut
migration/requires-manual-verification
Module › Animation & Rigging
Module › Core
Module › Development Management
Module › Eevee & Viewport
Module › Grease Pencil
Module › Modeling
Module › Nodes & Physics
Module › Pipeline, Assets & IO
Module › Platforms, Builds, Tests & Devices
Module › Python API
Module › Render & Cycles
Module › Sculpt, Paint & Texture
Module › Triaging
Module › User Interface
Module › VFX & Video
Platform/FreeBSD
Platform/Linux
Platform/macOS
Platform/Windows
Priority › High
Priority › Low
Priority › Normal
Priority › Unbreak Now!
Status › Archived
Status › Confirmed
Status › Duplicate
Status › Needs Information from Developers
Status › Needs Information from User
Status › Needs Triage
Status › Resolved
Type › Bug
Type › Design
Type › Known Issue
Type › Patch
Type › Report
Type › To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#57397
Loading…
There is no content yet.