Opened 9 years ago

Last modified 5 years ago

#4261 new defect

Systematic artefacts from 10bit Source

Reported by: solidghost Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: mpeg2video
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

When encoding from a 10 bit source file or Prores 422 or 4444, compression / color artefacts appear. From what I can see, the problem lies in the "dc precision" command "-dc". I have tried different combinations and these are my results.

On HD encodings ”-dc8” will give you nice clean solid colors without artifacts. But gradients and shading will suffer and be rougher.

On HD encodings ”-dc11” will give you bad compression and color artifacts that look very systematic as you can see in the picture in the link. But the Gradients looks nice and smooth.

On SD encodings ”-dc8” will give you nice clean solid colors without artifacts. But gradients and shading will suffer and be rougher.

On SD encodings ”-dc9” will give you bad compression and color artifacts that look very systematic. But the Gradients looks nice and smooth.

One theory is that FFmpeg uses an intermediate pix format that differs from the source when interpolating the pixels...

From other encoding software’s if I mimic the settings, all the encodings looks nice in all cases. So it seems that there is a bug in ffmpeg.

Here is an example of the ffmpeg command I use:

ffmpeg -i HD_uncompressed422_10bit.mov -vcodec mpeg2video -aspect {$aspectRatio} -r 25 -pix_fmt yuv422p -timecode_frame_start 0 -minrate 150000k -maxrate 150000k -b 150000k -intra -flags +cgop -flags2 +ivlc+non_linear_q -dc 11 -sc_threshold 1000000000 -qscale 1 -qmin 1 -qmax 12 -bufsize 47185920 -rc_init_occupancy 47185920 -rc_buf_aggressivity 0.25 -s {$resolution} -vframes {$frameDuration} -an OUTPUT.m2v

ffmpeg version 2.5.2 and older

Example Picture. Download and zoom in. Specially on the left side grey area.https://images.creativecow.net/279525/artefacts_from_10_bit_source.png

Attachments (1)

Ticket_4261_TestFiles.zip (515.1 KB ) - added by solidghost 9 years ago.
Source File & Output File

Download all attachments as: .zip

Change History (20)

comment:1 by Kieran Kunhya, 9 years ago

Ignore me.

Last edited 9 years ago by Kieran Kunhya (previous) (diff)

comment:2 by Michael Niedermayer, 9 years ago

Can you provide the input file so this can be reproduced?
Also a minimal testcase could help us if you have one

comment:3 by solidghost, 9 years ago

Here you can download a ZIP-File containing som 10_bit files and ProRes.

https://www.filecentral.se/filecentral/app/sv/pub-downloadForm.html?uuid=7d66aaaf-04c5-4485-a7f3-e679a27fffc9

1: Use the files above with the command line below.

ffmpeg -i INPUT.mov -vcodec mpeg2video -aspect {$aspectRatio} -r 25 -pix_fmt yuv422p -timecode_frame_start 0 -minrate 150000k -maxrate 150000k -b 150000k -intra -flags +cgop -flags2 +ivlc+non_linear_q -dc 11 -sc_threshold 1000000000 -qscale 1 -qmin 1 -qmax 12 -bufsize 47185920 -rc_init_occupancy 47185920 -rc_buf_aggressivity 0.25 -s {$resolution} -vframes {$frameDuration} -an OUTPUT.m2v

2: Open the .m2v file in a software that you can zoom in. Like Adobe After Effects.

3: At the end of the footage you will see some color bars. Zoom-in to the upper left grey column. There and other places you can see the systematic artefact pixels. Looks like a checker board.

comment:4 by solidghost, 9 years ago

Any news regarding this ticket?

by solidghost, 9 years ago

Attachment: Ticket_4261_TestFiles.zip added

Source File & Output File

comment:5 by solidghost, 9 years ago

I have Now Attached a ZIP-File containing an Uncompressed YUV 10 bit 422 file & the resulting Output .m2v file. Below is the command I used.

You need to Zoom in a lot, specially in the grey areas. Then you will see the artefacts. I used After Effects to Zoom.

The only way to get rid of the Artefacts was to use "-dc 8". "-dc 9" and higher always gives bad artefacts no matter if you transcode SD or HD.

ffmpeg -y -i Uncompressed_YUV_10_bit_422.mov -vcodec mpeg2video -aspect 16:9 -r 25 -pix_fmt yuv422p -timecode_frame_start 0 -minrate 150000k -maxrate 150000k -b:v 150000k -intra -flags +ildct+ilme+cgop -intra_vlc 1 -non_linear_quant 1 -dc 9 -sc_threshold 1000000000 -q:v 1 -qmin 1 -qmax 12 -bufsize 47185920 -rc_init_occupancy 47185920 -rc_buf_aggressivity 0.25 -top 1 -s 720x576 -an OUTPUT.m2v

Worth mentioning are that the artefacts appear in both mpeg2video and libx264.

Last edited 9 years ago by solidghost (previous) (diff)

comment:6 by Carl Eugen Hoyos, 9 years ago

Component: ffmpegundetermined
Keywords: artefact removed

Is the issue also reproducible if you use rawvideo as encoder / are you reporting a scaler issue?

comment:7 by solidghost, 9 years ago

Im having trouble opening the output-RAW-file so I can not confirm if the problem still exists there. But As described, the problem occurs in both mpeg2video and libx264.

It happens when:
HD to HD
SD to SD

So no actual scaling taking place in form of resolution.

comment:8 by Carl Eugen Hoyos, 9 years ago

Which command line did you test?

comment:9 by solidghost, 9 years ago

I used this one. Im not sure its the correct one...

ffmpeg -i Uncompressed_YUV_10_bit_422.mov -dc 9 -f rawvideo -vcodec rawvideo raw.mov 


But if you follow my command and use my source file from my comment I posted 4 days ago you will most definitively see what I am talking about :)

comment:10 by Carl Eugen Hoyos, 9 years ago

This is missing -pix_fmt yuv422p (and please remove -dc 9 for -vcodec rawvideo).
Unfortunately, you cannot put yuv422p rawvideo into mov (this is not FFmpeg-related), avi and yuv4mpegpipe should work fine.

comment:11 by Carl Eugen Hoyos, 9 years ago

How did you test for artefacts in your original report? With FFplay or ffmpeg -i input -qscale 2 out.jpg?

in reply to:  9 comment:12 by Carl Eugen Hoyos, 9 years ago

Replying to solidghost:

But if you follow my command and use my source file from my comment I posted 4 days ago you will most definitively see what I am talking about :)

Unfortunately not: Neither does your command line work here, nor did you post complete, uncut console output which is necessary for a valid ticket.

Last edited 9 years ago by Carl Eugen Hoyos (previous) (diff)

comment:13 by Carl Eugen Hoyos, 9 years ago

I tested the following command line but I am unable to see artefacts in the output file:

$ ffmpeg -i SD_PAL_Uncompressed_10bit.mov -qscale 2 -dc 11 out.m2v

comment:14 by solidghost, 9 years ago

Hello Again. Im still having trouble opening the Raw-file correct. I can open it in ffplay. But I dont know if I can zoom there.

I tried your command:

ffmpeg -i SD_PAL_Uncompressed_10bit.mov -qscale 2 -dc 11 out.m2v

And it also produced the artefacts. You need to zoom in 400-800% to really see them. But when you do, you will see that they are very systematic. I only managed to open the m2v-file in Adobe products, Adobe After Effects, Adobe Premiere & Adobe Photoshop. If you don't have any of them you can also...

  1. Open the m2v-file in VLC
  2. Zoom to the maximum
  3. Take a print screen
  4. Open that picture in your picture viewer.
  5. Zoom in the picture viewer a lot.

Remember to zoom into the grey solid colour ( Coulumn ) to the right.

comment:15 by Carl Eugen Hoyos, 9 years ago

I tested the following:

$ ffmpeg -r 0.1 -i Uncompressed_YUV_10_bit_422.mov -qscale 2 -dc 11 -r 25 out.m2v
$ ffmpeg -i out.m2v -vf crop=100:100:0:0,scale=1000:1000 -qscale 2 -vframes 1 out.jpg
$ ffmpeg -i out.m2v -sws_flags lanczos+accurate_rnd+full_chroma_int+full_chroma_inp -vf crop=100:100:0:0,scale=1000:1000 -qscale 2 -vframes 1 out2.jpg

And I have difficulties seeing systematic artefacts visible in out.jpg and even less in out2.jpg indicating you are reporting a scaler issue in your decoding application.
Additionally, I tested:

$ ffmpeg -i out.m2v -f xv -vf crop=100:100:0:0,scale=1000:1000,format=yuyv422 -

And the output looks essentially gray here.

(I think) I also tested with my hardware scaler:

$ ffmpeg -i out.m2v -f xv -vf crop=100:100:0:0,format=yuyv422 -

Enlarging the small window to my hd1080 screen shows no artefacts here.

I also tested the following but I don't think ffplay is a good application for this test (it doesn't support yuv422 and depends on an external library):

$ ffplay out.m2v -vf crop=100:100:0:0,scale=1000:1000

comment:16 by Carl Eugen Hoyos, 9 years ago

You could also test the following:

$ ffmpeg -i out.m2v -f sdl -vf crop=100:100:0:0,format=yuyv422 -

Do you see the issue you are reporting if you enlarge the output window?

comment:17 by solidghost, 9 years ago

Im sorry but my ffmpeg build cant use those "sdl" & "xv".

But I have testet your code below.

ffmpeg -i out.m2v -vf crop=100:100:0:0,scale=1000:1000 -qscale 2 -vframes 1 out.jpg

1: if you use the m2v-file that was coded from the 10 bit source using "-dc 11" it will absolutely have artefacts.
2: if you use the same command but uses the 10 bit source instead of the m2v file, that jpg will look clean.

Just compare those 2 jpg pictures. Its hard to see but the one from the m2v-file, if you look very closely will look almost little green every second column of pixels. And if you take both of these pictures to any program that can measure pixel colour values you will see when dragging your mouse over them that the one from the m2v-file will have color changes. Small but still they are not constant as the other .jpg created from the 10bit source mov.

comment:18 by Elon Musk, 5 years ago

Is this still reproducible?

comment:19 by Carl Eugen Hoyos, 5 years ago

Component: undeterminedavcodec
Keywords: mpeg2video added
Version: unspecifiedgit-master

I can reproduce different visual output for these two conversions (both with and without strict -2):

$ ffmpeg -i Uncompressed_YUV_10_bit_422.mov -qscale 2 -dc 11 -r 25 out.m2v
$ ffmpeg -i out.m2v -vf crop=100:100:0:0,scale=1000:1000 -qscale 2 -vframes 1 -strict -2 out8.jpg
$ ffmpeg -i Uncompressed_YUV_10_bit_422.mov -vf format=yuv422p,scale,crop=100:100:0:0,scale=1000:1000 -qscale 2 -vframes 1 -strict -2 out10.jpg

I believe that the same (or very similar) filter chains are used in both cases, so there may be an issue. I don't see much of a difference for different -dc values though.

Note: See TracTickets for help on using tickets.