Opened 5 years ago

Closed 5 years ago

#4017 closed defect (fixed)

noise filter breaks when combined with scaling

Reported by: rmk Owned by:
Priority: normal Component: avfilter
Version: git-master Keywords: noise
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

The following command line generates a video which has only noise in the right half of the picture and the noise has patterns that are completely different from the filter's behaviour when used without scaling:

./ffmpeg -f lavfi -i testsrc=s=1920x1080 -vf format=pix_fmts=yuv422p10le,scale=3840:2160,noise=c0s=10:allf=t -vcodec prores -q:v 0 -t 1 /Volumes/LPTest4_Mac/playground/transcoding/noise_upscale_ffmpeg.mov

ffmpeg version N-66701-g33db995 Copyright (c) 2000-2014 the FFmpeg developers

built on Oct 8 2014 19:07:01 with Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
configuration:
libavutil 54. 9.100 / 54. 9.100
libavcodec 56. 3.101 / 56. 3.101
libavformat 56. 7.104 / 56. 7.104
libavdevice 56. 1.100 / 56. 1.100
libavfilter 5. 1.103 / 5. 1.103
libswscale 3. 1.100 / 3. 1.100
libswresample 1. 1.100 / 1. 1.100

Input #0, lavfi, from 'testsrc=s=1920x1080':

Duration: N/A, start: 0.000000, bitrate: N/A

Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 1920x1080 [SAR 1:1 DAR 16:9], 25 tbr, 25 tbn, 25 tbc

File '/Volumes/LPTest4_Mac/playground/transcoding/noise_upscale_ffmpeg.mov' already exists. Overwrite ? [y/N] y
[prores @ 0x7fd260881400] encoding with ProRes? standard (apcn) profile
[prores @ 0x7fd260865a00] encoding with ProRes? standard (apcn) profile
[prores @ 0x7fd260838200] encoding with ProRes? standard (apcn) profile
[prores @ 0x7fd260838800] encoding with ProRes? standard (apcn) profile
[prores @ 0x7fd26081b200] encoding with ProRes? standard (apcn) profile
[prores @ 0x7fd26081b800] encoding with ProRes? standard (apcn) profile
[prores @ 0x7fd2608e8e00] encoding with ProRes? standard (apcn) profile
[prores @ 0x7fd2608eb600] encoding with ProRes? standard (apcn) profile
[prores @ 0x7fd261002200] encoding with ProRes? standard (apcn) profile
Output #0, mov, to '/Volumes/LPTest4_Mac/playground/transcoding/noise_upscale_ffmpeg.mov':

Metadata:

encoder : Lavf56.7.104
Stream #0:0: Video: prores (apcn) (apcn / 0x6E637061), yuv422p10le, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 12800 tbn, 25 tbc
Metadata:

encoder : Lavc56.3.101 prores

Stream mapping:

Stream #0:0 -> #0:0 (rawvideo (native) -> prores (native))

Press [q] to stop, ? for help
frame= 25 fps=8.5 q=0.0 Lsize= 77807kB time=00:00:01.00 bitrate=637393.6kbits/s
video:77806kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.001156%

For comparison, the same command line without the scaling results in the expected evenly distributed luma noise without those patterns. I used this pixel format because I am simulating the case where I ran into this, i.e. while transcoding and upscaling a prores 422 file.

Attachments (6)

Change History (19)

comment:1 Changed 5 years ago by rmk

I just noticed that it is not the upscaling but the sheer size. Just using a testsrc with 4k resolution shows the same effect so the ticket title is wrong.

comment:2 Changed 5 years ago by cehoyos

  • Keywords noise added
  • Version changed from unspecified to git-master

I don't think I can reproduce the issue and since yuv422p10le is not supported by the noise filter and encoding with a slightly unusual encoder is not ideal imo: Could you provide a simpler command line with -vcodec mpeg4 or with ffplay?

comment:3 Changed 5 years ago by rmk

I am attaching screenshots clipped out of the output, so you see what I mean. The difference is not subtle. When using yuv420p and mpeg4, the noise pattern is as expected. So it may be a side-effect of implicit pixel format conversions but someone else should make that analysis as i am only guessing here.

Command lines used:

ffmpeg -f lavfi -i testsrc=s=3840x2160 -vf format=pix_fmts=yuv422p10le,noise=c0s=10:allf=t -vcodec prores -q:v 0 -t 1 ~/tmp/noise_422p10le_prores.mov

vs.

ffmpeg -f lavfi -i testsrc=s=3840x2160 -vf format=pix_fmts=yuv420p,noise=c0s=10:allf=t -vcodec mpeg4 -q:v 0 -t 1 ~/tmp/noise_420p_mpeg4.mov

Changed 5 years ago by rmk

Changed 5 years ago by rmk

Changed 5 years ago by rmk

Changed 5 years ago by rmk

comment:4 Changed 5 years ago by rmk

Just compare the respective versions of ..._clip1.png and ..._clip2.png clipped out of the 4k output frames.

I have to correct myself. Pixel format conversion does not really make sense as an explanation as that should also occur when doing the same with 1920x1080 (attaching clips from output frames as well).

Changed 5 years ago by rmk

Changed 5 years ago by rmk

comment:5 Changed 5 years ago by cehoyos

Is the original issue not reproducible with the the following command?

$ ffmpeg -i ~/tmp/noise_420p_mpeg4.mov -vcodec prores -q:v 0 out.mov

comment:6 Changed 5 years ago by rmk

No, the result from that looks fine.

I originally ran into this when doing the same thing in an application using libavfilter for the filtering and Apple APIs for encoding prores, so I did not think ffmpeg's prores encoder was the problem.

The problem is also there when using v210 as a codec:

ffmpeg -f lavfi -i testsrc=s=3840x2160 -vf format=pix_fmts=yuv422p10le,noise=c0s=10:allf=t -vcodec v210 -q:v 0 -t 1 ~/tmp/noise_422p10le_v210.mov

comment:7 Changed 5 years ago by cehoyos

That is very strange. I will try again to reproduce myself: So far I didn't really see the difference but I wonder now what the issue is: maybe the format filter does something bad (with the inserted scaler), this can be checked with a higher log level.
Is the issue also reproducible if you simply remove the format filter from all command lines?

comment:8 Changed 5 years ago by rmk

No.

comment:9 Changed 5 years ago by cehoyos

Iiuc, the issue is that the noise filter does claim to support yuv422p16 but the output is not what you expect.
Could you test the following command line?

$ ffmpeg -f lavfi -i testsrc=s=3840x2160 -vf format=yuv422p16le,noise=c0s=10:allf=t -vcodec mpeg4 -qscale 2 -t 1 out.mov

I believe I see the issue now myself.

Last edited 5 years ago by cehoyos (previous) (diff)

comment:10 Changed 5 years ago by rmk

Yes, it shows exactly that effect.

comment:11 Changed 5 years ago by cehoyos

Patch that disables 16bit sent, use format=yuv422p as a workaround.

comment:12 Changed 5 years ago by rmk

The weird thing here is that the same command line has an ok result when using 1920x1080 for the resolution instead of 4k. So it does not seem that the pixel format is inherently the problem.

comment:13 Changed 5 years ago by michael

  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.