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 _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
