Dendraspis
commented
4 months ago As these are valid parameters that are passed to the encoder, this is more likely a tool issue, either SvtAv1EncApp or mkvmerge.
But at least your log file shows, that you have a 9s long video and using --keyint 10s, so that could be a potential culprit in such case. Additionally using --irefresh-type 1 as an Open GOP setting could lead to such issues as it's more likely to have a Closed GOP in that case.
On the other side I had also a short sample file and couldn't reproduce it with 2 chunks.
xx005fs
Describe the bug I downloaded the most recent version and tried running the same workflow as before using SVT AV1 to encode some videos with chunk encoding (currently set to 2 chunks). SVT AV1 settings are as follows:
--rc 0 --crf 38 --progress 3 --pin 1 --preset 3 --tune 0 --keyint 10s --irefresh-type 1 --scd 1 --tile-rows 1 --tile-columns 1for which all is the same as the old version I was running (2.36) except--pinand--irefresh-type. Once the encode of the video finished, no error messages were produced. However, the first half of the video is able to seek perfectly fine, while seeking the second half would always jump to the half way mark of the video regardless where it's skipped to. The output is configured to use MKV container. This behavior is shown in VLC player with hardware decoding disabled, and didn't appear with ones encoded with SVT AV1 in version 2.36 under the same environment.Expected behavior Seek should function as normal for the chunk 2 section of the video just like the first chunk.
How to reproduce the issue The issue appears on a variety of different input file types for me, whether the input is mkv or mov or mp4. Just by running through this encoding workflow it will generate a problematic output.
Provide information CPU: Ryzen 9 7950X3D, GPU: RTX 4090, OS: Windows 11 Home, Staxrip Version: 2.41.0 Log File: https://pastebin.com/uakNVvwU