[FFmpeg-user] Error messages when generating ProRes from 16-Bit TIFF

[Wiesinger, Konstantin - StA]

Dear Ted,

> I only have a generic suggestion to offer; as always, try updating to the current code, or a nightly build.
Will do so next occasion and post if output changes
>> Log:
> >
>> ffmpeg started on 2020-09-10 at 14:21:31
>> Report written to "ffmpeg-20200910-142131.log"
> >Log level: 48
>> Command line:
>> "C:\\Temp\\ffmpeg\\bin\\ffmpeg.exe" -report -i "D:\\Artus\\tif\\0%05d.tif" -c:v prores_ks -profile:v 4444 -vf "scale=2048x1550" -pix_fmt yuv444p10le neu.mov
>> ffmpeg version git-2020-06-15-9d80f3e Copyright (c) 2000-2020 the FFmpeg developers
>>  built with gcc 9.3.1 (GCC) 20200523
>>  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus >>--enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable->>libvmaf --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --disable-w32threads --enable-libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth -->>enable-libopenmpt --enable-amf
>I was curious about a few things though, why might someone add "--disable-w32threads"? Can you use posix threads instead?
As I'm quite new to ffmpeg and cli I'm not sure I get this correctly. I just used the zeranoe build so I wasn't even aware of such "details" like "--Dis...". Posix thread means output for example via Cygwin on a win machine?

>Also, is 2048x1550 not a typo? (1550 doesn't factor very well, 2×25×31)
>I can't articulate a clear rationale for this (and so it might not be optimal) but I would personally convert formats then change the size, putting the format filter before scale instead of pix_fmt. Or more likely I wouldn't even think of that and expect ffmpeg to figure that part out for me.
I tried to reproduce an external  contractors file: Resizing an original ~6k Tiff to a certain section/aperture and this resulted in this odd ratio. Your suggestions would be something like: -I xxx -c:v prores_ks -profile:v 4444 -formatfilter -vf "scale=xxx"?
So you would let ffmpeg decide the default pix_fmt? Do you have any specific filters in mind?
>> [AVIOContext @ 00000219ad3f0c40] Statistics: 146089658 bytes read, 0 seeks
>> [tiff @ 00000219ad19ea80] compression: 1
>> frame=    0 fps=0.0 q=0.0 size=       0kB time=-577014:32:22.77 bitrate=  -0.0kbits/s speed=N/A
>> cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)
>Again, not sure what it means if anything at all, but the time looks like it rolled over.
Sorry, but what do you mean by "time ... rolled over"?


Kind regards
Konstantin