Opened 12 years ago

Closed 7 years ago

#1933 closed defect (needs_more_info)

ffmpeg prores artifacts

Reported by: Martin Dusek Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: prores
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

The ProRes codecs are not working correctly with the image in attachment. The output quicktime has some artifacts in the gray square (see attachment zoomed part of image - out.tif)

ffmpeg -i test.tif -vcodec prores -profile 1 output.mov

ffmpeg 2012-11-05 (git-c995644-win64)
built on win64, but also on OS X 10.6

Attachments (2)

out.tif (795.1 KB ) - added by Martin Dusek 12 years ago.
test.jpg (377.6 KB ) - added by Martin Dusek 12 years ago.

Download all attachments as: .zip

Change History (38)

by Martin Dusek, 12 years ago

Attachment: out.tif added

by Martin Dusek, 12 years ago

Attachment: test.jpg added

comment:1 by Martin Dusek, 12 years ago

I can't attach test.tif, because it is too big. But same problem with attached test.jpg...

comment:2 by Carl Eugen Hoyos, 12 years ago

Keywords: quicktime removed

Please add your command line together with complete, uncut console output.

comment:3 by Carl Eugen Hoyos, 12 years ago

And please upload an input file, see http://ffmpeg.org/bugreports.html or upload to http://www.datafilehost.com/

comment:4 by Martin Dusek, 12 years ago

Ok, original file input uploaded: http://www.datafilehost.com/download-5f72f895.html
Console:

ffmpeg -i test.tif -vcodec prores -profile 1 output.mov
ffmpeg version N-46469-gc995644 Copyright (c) 2000-2012 the FFmpeg developers
  built on Nov  5 2012 18:00:04 with gcc 4.7.2 (GCC)
  configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-
libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable
-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
  libavutil      52.  5.100 / 52.  5.100
  libavcodec     54. 71.100 / 54. 71.100
  libavformat    54. 36.100 / 54. 36.100
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 21.106 /  3. 21.106
  libswscale      2.  1.102 /  2.  1.102
  libswresample   0. 16.100 /  0. 16.100
  libpostproc    52.  1.100 / 52.  1.100
Input #0, image2, from 'test.tif':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: tiff, rgb24, 2048x1556, 25 tbr, 25 tbn, 25 tbc
Please use -profile:a or -profile:v, -profile is ambiguous
Output #0, mov, to 'output.mov':
  Metadata:
    encoder         : Lavf54.36.100
    Stream #0:0: Video: prores (apcs) (apcs / 0x73637061), yuv422p10le, 2048x1556, q=2-31, 200 kb/s, 12800 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (tiff -> prores)
Press [q] to stop, [?] for help
frame=    1 fps=0.0 q=0.0 Lsize=     583kB time=00:00:00.04 bitrate=119348.6kbits/s
video:582kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.120129%
Last edited 12 years ago by Carl Eugen Hoyos (previous) (diff)

comment:5 by Carl Eugen Hoyos, 12 years ago

Is the problem also reproducible for you with the following command line?
$ ffmpeg -i test.tif -vcodec prores_kostya out.mov
(There is an implicit lossy colourspace conversion - -pix_fmt yuv422p10 - involved in your original command line, I am not sure if you are aware of this.)

Alternatively, you could test the following command line to check my theory:
$ ffmpeg -i test.tif -pix_fmt yuv422p -qscale 2 out.jpg

comment:6 by Martin Dusek, 12 years ago

$ ffmpeg -i test.tif -vcodec prores_kostya out.mov
Same artifacts as in "prores"

$ ffmpeg -i test.tif -pix_fmt yuv422p -qscale 2 out.jpg
out.jpg is OK...

comment:7 by Martin Dusek, 12 years ago

$ ffmpeg -i test.tif -vcodec prores_kostya -qscale 15 out.mov
No artifacts in gray square but it is low quality (too much pixelized)
With "prores" there are still artifacts in the square...

comment:8 by Martin Dusek, 12 years ago

I have created 16-bit TIF from 8-bit and it works, no artifacts!!!
test16.tif http://www.datafilehost.com/download-eae732ef.html

So I think that the conversion from 8-bit RGB to k422YpCbCr10CodecType is buggy. Your theory is probably right except that JPEG can't have the Apple YUV 10 bit space, yuv422p != yuv422p10. So JPEG encoding test is usefull...

Last edited 12 years ago by Martin Dusek (previous) (diff)

comment:9 by Martin Dusek, 12 years ago

Oh no, the result is still not correct! The gray square is now OK, but there are new artifacts in the brown square :)

Last edited 12 years ago by Martin Dusek (previous) (diff)

comment:10 by Martin Dusek, 12 years ago

Definitely it is not a problem with color space conversion. I have converted the image into YCbCr space in my c++ program, but output image still has artifacts...

comment:11 by Elon Musk, 12 years ago

It would be best if you try with v210 input. (which is packed 10bit yuv422)

Last edited 12 years ago by Elon Musk (previous) (diff)

comment:12 by Martin Dusek, 12 years ago

Thanks, I made several attemps:
AV_PIX_FMT_YUV422P - no artifacts
AV_PIX_FMT_YUV444P - no artifacts
AV_PIX_FMT_RGB24 - artifacts
AV_PIX_FMT_YUV422P10LE - artifacts, IMHO this format would be ProRes native, I was playing only with luma component.

So I've changed my opinion, the problem could be in built-in color space conversion :o)

BTW ProResLT has lower quality then the original Apple ProResLT, is it possible to set bitrate? It seems that it completely ignores -b parameter...

comment:13 by Elon Musk, 12 years ago

I'm confused by your reply, v210 files have tag v210 and are in mov container

FFmpeg use internal YUV422P10 pix format to decode such files.

Please give ffmpeg output with v210 as input codec.

comment:14 by Martin Dusek, 12 years ago

pixfmt.h:
#define AV_PIX_FMT_YUV422P10 AV_PIX_FMT_NE(YUV422P10BE, YUV422P10LE)

YUV422P10 = AV_PIX_FMT_YUV422P10LE on Win32

I see artifacts in the output video when using YUV422P10 directly in my program...
BTW is it possible to store video in YUV422P10 without Apple ProRes? I've tried h.264, but it only auto-selects yuv422p

Last edited 12 years ago by Martin Dusek (previous) (diff)

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

Replying to rivierakid:

BTW is it possible to store video in YUV422P10 without Apple ProRes?

-vcodec v210

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

Replying to rivierakid:

BTW is it possible to store video in YUV422P10 without Apple ProRes? I've tried h.264, but it only auto-selects yuv422p

That is because you have not compiled you local copy of x264 with 10-bit encoding support. dnxhd, ffv1 and libopenjpeg also support yuv422p10, but they are either not lossless or less common.

Version 0, edited 12 years ago by Carl Eugen Hoyos (next)

comment:17 by Martin Dusek, 12 years ago

Testing with test.tif http://www.datafilehost.com/download-5f72f895.html
-vcodec 210 no artifacts
-vcodec prores artifacts in gray square

I wonder about bitrate settings, for prores_kostya there is a global_quality parameter (prores_kostya.c), which controls the bitrate (there is a four items-bitrates tab for every profile). But I don't know how to control quality in "prores"? Is it equal to "prores_anatolyi"? Because I can't find a source code for it and seems that "prores_anatolyi" auto-selects the quality...

comment:18 by Elon Musk, 12 years ago

I'm not interested in encoding to v210 codec, you did not give command output.
I'm interested in encoding from v210 to prores.

comment:19 by Martin Dusek, 12 years ago

ffmpeg -i test.tif -vcodec v210 v210.mov
Output: http://www.datafilehost.com/download-5832388c.html

ffmpeg -i v210.mov -vcodec prores -profile 1 out.mov

out.mov: there is a pixel pattern in "one color" gray square.
v210.mov is OK

comment:20 by Elon Musk, 12 years ago

so both prores encoders are bad?

comment:21 by Martin Dusek, 12 years ago

Yes for v210 same buggy behaviour, but now I prefer prores_kostya because it has more settings (quality-bitrate).

Hmm, converting first into yuv444p and then to prores_kostya is OK...

ffmpeg -i test.tif -vcodec h264 -pix_fmt yuv444p 444.mov
ffmpeg -i 444.mov -vcodec prores_kostya -profile 1 out.mov

It's really strange :o)

comment:22 by Elon Musk, 12 years ago

So lt profile is broken only for 422?

comment:23 by Martin Dusek, 12 years ago

Not only LT, HQ and probably other profiles are broken too.
Not sure if it's broken only for 422.
444 seems to work great, but tested only for single image...

Last edited 12 years ago by Martin Dusek (previous) (diff)

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

Replying to rivierakid:

444 seems to work great, but tested only for single image...

You originally wrote 'Same artifacts as in "prores"' ...
Since I see several statements that possibly contradict each-other, please try to clarify which command lines allow you to reproduce the problem and which work fine.
If possible, do not try to involve x264, it is a lossy codec and may affect your test results.

comment:25 by Martin Dusek, 12 years ago

That was not for 444 format, but I've made many tests and you're right that it's little bit unclear :)

Reproducing problem:
test.tif http://www.datafilehost.com/download-5f72f895.html

ffmpeg -i test.tif -vcodec prores_kostya -profile 1 out.mov

  • result is bad (artifacts)

ffmpeg -i test.tif -vcodec v308 -pix_fmt yuv444p test.mov
ffmpeg -i test.mov -vcodec prores_kostya -profile 1 out1.mov

  • result is OK

Instead of x264 I'm using v308 = uncompressed 4:4:4

Last edited 12 years ago by Martin Dusek (previous) (diff)

in reply to:  25 ; comment:26 by TimNich, 12 years ago

Replying to rivierakid:

That was not for 444 format, but I've made many test and you're right that it's little bit unclear :)

Reproducing problem:
test.tif http://www.datafilehost.com/download-5f72f895.html

ffmpeg -i test.tif -vcodec prores_kostya -profile 1 out.mov

  • result is bad (artifacts)

Where are these artefacts? Not immediately obvious to me when I ran the test.

With -v debug I notice several "Unknown or unsupported tag..." messages for the tif... might they be significant?

ffmpeg -i test.tif -vcodec v308 -pix_fmt yuv444p test.mov
ffmpeg -i test.mov -vcodec prores_kostya -profile 1 out1.mov

  • result is OK

Instead of x264 I'm using v308 = uncompressed 4:4:4

comment:27 by Carl Eugen Hoyos, 12 years ago

Thank your for clarification!

Could you test the following commands?
$ ffmpeg -i test.tif -vcodec v210 out.mov

and

$ ffmpeg -i test.tif -vcodec v308 test.mov
$ ffmpeg -i test.mov -vcodec v210 out1.mov

in reply to:  26 ; comment:28 by Martin Dusek, 12 years ago

Replying to nichot20:

Where are these artefacts? Not immediately obvious to me when I ran the test.

See out.tif in attachment, it is zoomed, there are stripes in a gray single color area.

With -v debug I notice several "Unknown or unsupported tag..." messages for the tif... might they be significant?

I'think no, file was created in Foundry Nuke

comment:29 by Carl Eugen Hoyos, 12 years ago

And one more thing to test would be:
$ ffmpeg -i test.tif -vcodec prores out.mov

(I assume result is bad)

and

$ ffmpeg -i test.tif -vcodec v308 test.mov
$ ffmpeg -i test.mov -vcodec prores out1.mov

comment:30 by Martin Dusek, 12 years ago

$ ffmpeg -i test.tif -vcodec v210 out.mov

  • OK

$ ffmpeg -i test.tif -vcodec v308 test.mov
$ ffmpeg -i test.mov -vcodec v210 out1.mov

  • OK

$ ffmpeg -i test.tif -vcodec prores out.mov

  • bad

$ ffmpeg -i test.tif -vcodec v308 test.mov
$ ffmpeg -i test.mov -vcodec prores out1.mov

  • OK

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

Replying to rivierakid:

$ ffmpeg -i test.tif -vcodec v210 out.mov

  • OK

This indicates that there is no problem with the colourspace conversion from rgb24 to yuv422p10.

$ ffmpeg -i test.tif -vcodec prores out.mov

  • bad

$ ffmpeg -i test.tif -vcodec v308 test.mov
$ ffmpeg -i test.mov -vcodec prores out1.mov

  • OK

This indicates that there is no problem with the prores encoder, only with the (direct) colourspace conversion from rgb24 to yuv422p10.

But I probably miss something...

in reply to:  28 comment:32 by TimNich, 12 years ago

Replying to rivierakid:

Replying to nichot20:

Where are these artefacts? Not immediately obvious to me when I ran the test.

See out.tif in attachment, it is zoomed, there are stripes in a gray single color area.

I see it on yours, but not on mine.....

With -v debug I notice several "Unknown or unsupported tag..." messages for the tif... might they be significant?

I'think no, file was created in Foundry Nuke

comment:33 by Martin Dusek, 12 years ago

And what version are you using?

I've been using many of pre-compiled versions for Win64 from http://ffmpeg.zeranoe.com/builds/
including the lastest 2012-11-20

Last edited 12 years ago by Martin Dusek (previous) (diff)

in reply to:  33 comment:34 by TimNich, 12 years ago

Replying to rivierakid:

And what version are you using?

Just tried on current git HEAD, and I cannot see the patterning.

I've been using many of pre-compiled version for Win64 from http://ffmpeg.zeranoe.com/builds/
including the lastest 2012-11-20

comment:35 by Martin Dusek, 12 years ago

Could you add your command line with console output? And please upload your resulting mov-file.
I'll check it :o)

comment:36 by Elon Musk, 7 years ago

Resolution: needs_more_info
Status: newclosed

Unclear what is real problem.

Note: See TracTickets for help on using tickets.