svt-av1 (AV1 FFmpeg) significantly slower on PySceneDetect vs Equal Chunking

[RimasRaV1]

svt-av1 (AV1 FFmpeg) performs significantly slower on PySceneDetect vs Equal Chunking.

Steps to reproduce:
Load large file (for example 1 hour 4k video), turn on Splitting Method: PysceneDetect, select svt-av1 (AV1 FFmpeg), select destination, add to queue, start encode - observe encoding time larger that than with Equal Chunking and it getting larger over time.

Expected behavior
Time of encoding is constant. Encoding is as fast as Equal Chunking

Screenshots

Log File

Desktop (please complete the following information):

• OS: Win 11 22H2 64-bit AMD Ryzen 5 2600 Six-Core Processor 3.40 GHz 16,0 GB RAM, Nvidia RTX 3060, encoding is done on 1TB M.2 drive.
• NEAV1E Version: 2.0.9 (this behavior was on previous versions too).

Additional context
I think it might be related to not splitting into chunks prior to encoding, but instead gathering timestamps in an excel file. File seeking might be the bottleneck. My suggestion would be - to cut the initial file into chunks by excel timestamps before encoding. (It will prolong the initial phase a little bit, but it could give a lot shorter encoding time.
I like this splitting method more because this gives the output without visible "seams". Equal Chunking gives visible seams here and there, especially on lower bitrate encodes.

[Alkl58]

My suggestion would be - to cut the initial file into chunks by excel timestamps before encoding

It would be even slower if we did it that way, as now instead of seeking during encoding, we have to do the entire seeking before encoding, meaning just shifting the issue to a different step IMO.

The best way of mitigating the issue is to use Input Seeking (option in the program settings), which should drastically improve seeking times; however in the past it was prone to frame losses (according to the FFmpeg wiki it should be frame accurate).

PySceneDetect has an integrated function for splitting with FFmpeg or MKVMerge. When using FFmpeg in PySceneDetect it also invokes it for each scene seperately, the main difference being that they use Input Seeking. MKVMerge would be a different option, however the way how its invoked can and will hit the char limit of the console, if there are too many scenes.

[RimasRaV1]

Thank you for your response. Tested Input Seeking on a few clips. It is indeed faster and the quality feels better than with equal chunking. But I saw other problems ocuring: one clip was generated with variable framerate when the source had constant framerate and the other had audio/video synchronization issues. Well, we have to wait for tools to improve/other tools to emerge, I guess.

[RimasRaV1]

MKVMerge would be a different option, however the way how its invoked can and will hit the char limit of the console, if there are too many scenes.

Just had another thought: maybe PySceneDetect with MKV could couple small scenes (for example: less than 10sec) into one so it would not hit the char limit? Maybe increase PySceneDetect treshhold could do that too? Or maybe if the scene count is too high, just do equal chunking (into large chunks) before PySceneDetect?

[foxx1337]

I'm seeing this as well - the encodes get exponentially slower, reaching a point where I only have continous disk usage from ffmpeg reading at 30-40 megabytes per second for hours and hours:

[dravenar]

I've also noticed that PySceneDetect is slower than Equal Chunking on encoding. Not when splitting in chunks, there is super fast. But when encoding, at first, it has 4-5fps average. But when reaches 10-20% of the total, its begins to get swlower up to 1fps, and even less, getting exponential the encode time