Hello, whenever I try to output a file at 8k resolution (8192x4096) and encode it with ffv1 I get an error: a red message text saying “resolution error”.
I have to use ProRes 422 HQ instead which is a lossy codec. I would prefer to have a lossless file created and then encode that down on my own. There are video metric target quality encoding software that only accept yuv 420 color inputs, so I can’t use pro res files with them.
I have used other programs with ffmpeg back ends and ffmpeg itself to create 4096p ffv1 files without problems. It seems like this is an issue specific to Topaz Video.
It was reported by another user here over a year ago in a thread titled “FFV1 & 8K”
I am using Topaz Video v1.0.4
Hi, as a temporary workaround until this is fixed, you could pipe uncompressed video from the modified Topaz ffmpeg (which has this bug) into the standard ffmpeg (which presumably works fine).
Only as an example, here’s a previous post which was regarding x264 / x265 compression. But the same principle applies.
@Chamberhouse Thanks, I think they got rid of that functionality on newer versions though.
@kyle.topazlabs Awesome. I hope it is a simple fix. I don’t do video editing after topaz so the smaller file size and higher quality video from ffv1 will be appreciated.
I think I might have some good news. I tried upscaling to 8K ffv1 on both my Mac and and old underpowered Windows machine for a short preview. Unsurprisingly, I got a “resolution error”. However, as I never trust Topaz to show the most informative error in the UI, I tried it via the CLI to see the actual ffmpeg error output. THAT showed the EXACT error:
“Unsupported number 4 of slices requested, please specify a supported number with -slices (ex:4,6,9,12,16, …)”
When I increased “slices” to 9 - IT WORKED on Mac and Windows. I can’t remember off-hand which file contains the default ffmpeg parameters. If you were to find that and change the slices parameter from 4 to 9, you should then be able to get 8K ffv1 working in the UI, without needing to use the CLI.
TOPAZ - yet another good reason to let us ordinary personal licence users carry on using the CLI. I wouldn’t have found this otherwise (unless I tried looking in the very difficult to read log file, perhaps).
The file I was trying to remember is “Video-encoders.json”, in Windows it’s in:
C:\ProgramData\Topaz Labs LLC\Topaz Video\models
If you find the “slices” line for your preferred ffv1 colour depth and subsampling combination(s), then change the slices from 4 to 9, that should sort it - at least for 8K output. Other numbers higher than 9 might work too.
Testing it out now and I will post the results when it’s done rendering. Thanks again!
According the ffmpeg: “Each frame is split into this number of slices. This affects multithreading performance, as well as filesize: Increasing the number of slices might speed up performance, but also increases the filesize.” So I’m just going to use 9 slices. I tried 6 but it gave the error message.
The program did render out the video to ffv1 without any issues. Final file size was 252 GiB vs 202 GiB for the Pro Res file I believe.
The main benefit I have noticed is that I am able to encode the video with 2 workers on a chunked encode now since I don’t have the overhead from filtering the 422 colors on my ram.
You could use a pipeline. You dont have to double encode. That amount of disk space this would need too, omg!
You can just make a pipeline like this:
ffmpeg “-hide_banner” “-i” “D:/Musik6/Suno/Die letzte Runde/kling_20251219_Image_to_Video_The_fast_d_1076_0.mp4” “-sws_flags” “spline+accurate_rnd+full_chroma_int” “-filter_complex” “tvai_fi=model=apo-8:slowmo=1:rdt=0.01:fps=60:device=-2:vram=1:instances=1,tvai_up=model=prob-4:scale=0:w=1176:h=1764:preblur=0:noise=-0.75:details=0:halo=0:blur=0:compression=0:estimate=8:blend=0.2:device=-2:vram=1:instances=1” “-level” “3” “-c:v” “ffv1” “-pix_fmt” “yuv420p” “-slices” “4” “-slicecrc” “1” “-g” “1” “-an” “-map_metadata” “0” “-map_metadata:s:v” “0:s:v” “-fps_mode:v” “passthrough” “-map” “0:s?” “-c:s” “copy” “-movflags” “frag_keyframe+empty_moov+delay_moov+use_metadata_tags+write_colr” “-bf” “0” “-metadata” “videoai=Framerate changed to 60 using apo-8 replacing duplicate frames. Enhanced using prob-4; mode: relative to auto; revert compression at 0; recover details at 0; sharpen at 0; reduce noise at -75; dehalo at 0; anti-alias/deblur at 0; focus fix Off; and recover original detail at 20” “-f” “mp4” “-” | “d:\Programme\ffmpeg-2025-08-25-git-1b62f9d3ae-full_build\bin\ffmpeg.exe” “-i” “-” “-fps_mode” “cfr” “-c:v” “libx265” “-pix_fmt” “yuv420p” “-preset” “slow” “-x265-params” “crf=20:no-open-gop=1:keyint=240:aq-mode=3:rc-lookahead=60:no-strong-intra-smoothing=1” “D:/Musik6/Suno/Die letzte Runde/kling_20251219_Image_to_Video_The_fast_d_1076_0_202878885-x265.mp4”
Then ffv1 doesnt waste your diskspace at all and its pipelined directly to x265 in one single go!
Normally you dont have to put every command into “ “. But thats how the “show export command” gives you the command. So it’s easier for me to follow this scheme
But if you’re going to pipe the Topaz ffmpeg output to the standard ffmpeg for x265 / x264 encoding (losslessly if required), you might as well use the rawvideo format in a nut container instead of ffv1. Below is a reply I made about this in 2023.
