What about the interlaced source and -vf bwdif ? about av1an

[master-of-zen]

@balaccord When you set filter it produced 50 fps output. Frame checker detected it and posted Frame Count Differ for Source and as you can see it report that encode have twice the frames.
I can recommend just suppress it with --no_check :)

[master-of-zen]

--probe_framerate 50 is for target_vmaf it should not be here)

[balaccord]

The warnings are the least sorrow's cause :) The parts durations are way TOO different so the encoding starts fast but then constantly slows down when the number of workers decreases. I would prefer the chunks were more or less equal in size to they complete more or less simultaneously. Is it possible to do something with it?

Am I properly understand the av1an takes the stream duration from the headers? If it's so then It's ok while there are no filters there changing the frame rate. But when such a kind of filter is in the chain, then...

[n9Mtq4]

You are already using the -xs 500 options and that further split scenes greater than 500 frames long. That should help. You can try reducing that number even more and setting -tr lower than 30. It is difficult to make all chunks take the same amount of time since the complexity of the frames also effects how long it takes to encode. There will always be encodes that take longer than others so there will always be an encode that finishes last, while all the other workers are idle. Av1an sorts the chunks by file size so the ones that take the longest start first in the hopes that they will be done by the time the many smaller ones are done.

Av1an gets the number of frames from OpenCV. I don't know exactly how it gets the number of frames, but it doesn't use ffmpeg, so no filters are applied.

Changing the framerate with filters causes many problems with the scene splitting. Without going into the process in which both methods work and how they fail with changing the framerate, splitting with PySceneDetect will cause frames to be missing in the final output and using aom_keyframes will split on the wrong frames. I also don't have any ideas that would be able to fix the those problems and work with the wide number of filters that can change framerates.

In your case, I would recommend losslessly transcoding to h264 with the filters. Then run Av1an on that.

[balaccord]

n9Mtq4, well, the question was how to "explain" to av1an that we use the filter chain that's changes (i.e. doubles in our case) the frame rate/number? For now it "thinks" the fps/frame count is that are written in the movie header while they are twice of these

-ff " -vf bwdif" seems to be ignoring at the stage of splitting. Of course, it would slow down the process. But maybe it was worth to add the option about the final frame rate? Or just expand the meaning of the the existing --probe_framerate?

My very movie is the single scene, opencv doesn't detect the scene change so I used -xx 500

I also used -w 6 so it could be split up to 6 chunks. The movie length is ~53 sec, to be exact, 2704 bwdif-fed frames (ffmpeg -i 20191011-154902-00003.MTS -vf bwdif -map 0:v -f null -). I.e. at least 5 chunks by ~500 frames each. As I wrote above, the keyframes are 2 fps so it's possible to split well accurately so the chunks were +/- equal. Well, it even would be kind of acceptable if the chunks were 500+500+500+500+704

But what we've got was four workers instead of 5 or 6 and chunks are 438+438+466+1348. Rather huge rounding error, isn't it? :)

Changing the framerate with filters causes many problems with the scene splitting

Of course - in general. But not sure it's meaningful in my case

[n9Mtq4]

Are you specifying a split method with --split_method or is it the default?

Also, does bwdif double every frame or does it insert new frames between existing frames? For a video with 2 interlaced frames would bwdif give 3 or 4 frames?

[balaccord]

--split_method is default, i.e. pyscene for I use 1-pass encoding

The full command is
python av1an.py -w 6 --ff " -sn -vf bwdif" -a " -an" -xs 500 -enc aom -p 1 --probe_framerate 50 -v " --threads=12 --end-usage=q --cq-level=43 --cpu-used=4" -i $FILENAME

-xs 500 is for the test purpose only, the thought was to use some script which would calculate the number based on the video length
-an -sn - the idea was to process the subs/audio by myself

About bwdif - I don't know exactly what and how it's doing with such short videos. My only subject of video processing - our own family videos, so I simply never been thinking in this direction. From my sight it's just the "thingie that makes 50p from 50i"

I've uploaded the shortest source I have as an example of what format are all of them of. The video stream duration is 3.54 sec or 182 interlaced frame. Please, don't appraise the quality :)

https://yadi.sk/i/ExFr9sQiuGbfOQ

[megapro17]

куда не встану?
ладно.