Changes between Version 8 and Version 10 of Ticket #9781


Ignore:
Timestamp:
May 13, 2022, 1:20:42 PM (4 years ago)
Author:
Llyw
Comment:

Agreed. (I can understand a desire to close new issues as fast as possible, but I don't think that it's the right way forward in this case. The relevant code in the z.lib/zimg API showing that it is possible to compute the input slice's active area precisely is at ​​https://github.com/sekrit-twc/zimg/blob/release-3.0.4/src/zimg/api/zimg.h#L568)

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #9781

    • Property Resolution → fixed
    • Property Status reopened → closed

  • Ticket #9781 – Description

    v8 v10  
    1 Agreed. (I can understand a desire to close new issues as fast as possible, but I don't think that it's the right way forward in this case.)
     1I noticed that the zscale filter can introduce distortion (by either cutting or crushing of the image, I have not been able to pinpoint the exact type of distortion yet) when resampling video input using [https://github.com/FFmpeg/FFmpeg/commit/30e2bb0f64 FFmpeg@30e2bb0f64], but not when using FFmpeg 5.0.1:
    22
    3 I think the actual root-cause for the distortion is the fact that the coordinates for the active area in the input slice is approximated using integer arithmetic, whereas the z.lib/zimg API actually stores these coordinates as double precision floating-point values, see https://github.com/sekrit-twc/zimg/blob/release-3.0.4/src/zimg/api/zimg.h#L568.
     3Take, for example, the 720p VP9 WebM version of Blender Foundation's Elephants Dream at https://upload.wikimedia.org/wikipedia/commons/transcoded/2/28/Elephants_Dream_%282006%29_1080p24.webm/Elephants_Dream_%282006%29_1080p24.webm.720p.vp9.webm.
    44
    5 So it should be possible to compute and assign these coordinates (without any integer/rounding operations) in double precision floating-point arithmetic.
     5At roughly 7 minutes, 2 seconds a stills image of this video looks like this in VLC 3.0.17.4:
     6[[Image(https://trac.ffmpeg.org/attachment/ticket/9781/Original.png)]]
     7
     8
     9Then, resample to 480x272 pixels with a display aspect ratio of 16:9 and a sample aspect ratio of 136:135:
     10{{{
     11ffmpeg -i 'Elephants_Dream_(2006)_1080p24.webm.720p.vp9.webm' -vf 'zscale=w=480:h=272:f=lanczos,setdar=dar=16/9' -pix_fmt yuv420p Output_Distorted.mp4
     12}}}
     13The corresponding stills image will look like this when resizing the video port to show a 720p resolution:
     14[[Image(https://trac.ffmpeg.org/attachment/ticket/9781/Output_Distorted.png)]]
     15
     16I understand that there is some movement in this scene but if you look at the background you should clearly see the distortion I was talking about.
     17
     18
     19Compare this with the same operation done using FFmpeg's `scale` filter:
     20{{{
     21ffmpeg -i 'Elephants_Dream_(2006)_1080p24.webm.720p.vp9.webm' -vf 'scale=w=480:h=272:flags=lanczos+accurate_rnd,setdar=dar=16/9' -pix_fmt yuv420p Output_Undistorted.mp4
     22}}}
     23Here, the corresponding stills image looks like this and does not show significant distortion when comparing with the stills image of the input video (some minor mismatch is obviously expected due to the strong resampling and movement in the scene):
     24[[Image(https://trac.ffmpeg.org/attachment/ticket/9781/Output_Undistorted.png)]]
     25
     26I am assuming that this might have something to do with the recent-ish efforts to parallelize the `zscale` filter and would appreciate it, if this behavior is investigated.