Issue with slower presets

[3gMan]

Good greetings! Do you know the reason I get this pixelation and artifacts in the image only when using slower presets. They come and go, possibly they appear when the image is more complicated and requires a higher bitrate. The slower settings really help image quality and color banding otherwise.
Edit: Veryslow and placebo both do it so far. Running a longer test on slower. Tried with both fastdecode and zerolatency checked and unchecked. CRF 16, but tried lower just in case.

[nagadomi]

That setting is just passed to pyav (ffmpeg libx264).
I think there is a lot of information on the internet about H.264 video encoding settings.

doc
https://trac.ffmpeg.org/wiki/Encode/H.264
https://x265.readthedocs.io/en/master/presets.html

EDIT:
The second link may not correct because it's x265.

[nagadomi]

This could be a problem with the decoder, so I would suggest eliminating that possibility first.
If changing the video player or turning off the hardware accelerator option produces the same result, it may be an encoder problem.

[3gMan]

These show it much better. It doesn't do this in handbrake with the same settings.

[3gMan]

This could be a problem with the decoder, so I would suggest eliminating that possibility first. If changing the video player or turning off the hardware accelerator option produces the same result, it may be an encoder problem.

Appreciate the help. Especially if it's not an iw3 issue. It is baked into the file so I guess encoder issue? Do you have any suggestions where to start with fixing that?

[nagadomi]

I am not familiar with video encoding so I have no useful advice.
I can simply say to use medium.

The following thread I saw has a similar problem, but seems to be caused by a hardware decoder.
https://forum.videohelp.com/threads/411090-Artifacts-on-4k-video-encoded-with-ffmpeg-placebo-preset

[3gMan]

Someone pointed out to me i haven't updated Nvidia drivers in quite awhile. I'll try that out.

[nagadomi]

I have added a note in the README about a hardware decoder problem that can occur when using preset=slower|veryslow|placebo.

[3gMan]

I have added a note in the README about a hardware decoder problem that can occur when using preset=slower|veryslow|placebo.

Thanks. I am using slower with no issues yet. Very Slow and Placebo both produce the artifacts readily. On two separate PCs, but with the iw3 folder copied over to the other.

[nagadomi]

I recommend turning off hardware decoding in your video player to check. I don't know where that setting is in your video player.

If you can use ffmpeg, you can output frame images with the following command (this should use a software decoder).

mkdir out
ffmpeg -i input_video.mp4 ./out/%06d.png

[nagadomi]

If you can use ffmpeg

An easier way is to Export that video with iw3.
Frame images are stored in the rgb/ folder. It is the result of software decoding.

[3gMan]

You got it, thanks! That worked in vlc turning hardware decoding from auto to off. I would rather have it work on as any devices as possible though. So if very slow/placebo create issues with hardware decoding, I will stick with slower. Weird as Handbrake doesn't have this issue.

[nagadomi]

I have no idea what Handbrake is doing, but maybe the preset or profile is different. It can be edited, but iw3 simply uses ffmpeg's default settings.

Also, it may be related to the video resolution. Does the same problem occur with low-resolution video?
h264 only supports up to 4K on spec. 4K to SBS is twice that size.
It can encode in practice, but there may be player/decoder that cannot play it correctly.

[andy500]

l would use Shutter Encoder it more better Handbrake l use it for all my 2d to 3d work it is free to use and nagadomi l love your software it is the best 2d to 3d software out there great work
https://www.shutterencoder.com