switch --seek in avs and vpy direct input modes.

[ghost]

Hi @msg7086

When using --seek nnn with an avs or vpy direct input source, the x265 encoder will actually seem to begin encoding at the frame nnn, and will encode the proper number of frames specified with --frames, but the resulting video will actually start at frame 0 of the source, and not frame nnn.

Example (with AVS, and with VPY it's the same result).

Command line:

x265.exe --crf 24 --output-depth 10 --seek 200 --frames 980 --output Chunk2_out.hevc "Timecode sample - 25fps.avs"

Output Info of the encoding process:

avs+ [info]: AviSynth+ 3.6.2 (r3341, master, x86_64)
avs+ [info]: Video colorspace: YUV420 (YV12)
avs+ [info]: Video depth: 8
avs+ [info]: Video resolution: 856x480
avs+ [info]: Video framerate: 25/1
avs+ [info]: Video framecount: 1960
avs+ [info]: 856x480 fps 25/1 i420p8 frames 200 - 1179 of 1960
raw  [info]: output file: C:\Temp\_StaxRip\Timecode sample - 25fps_temp\Chunk2_out.hevc
x265 [info]: HEVC encoder version x265M 3.4+28-419182243
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices                              : 1
x265 [info]: frame threads / pool features       : 3 / wpp(8 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge         : hex / 57 / 2 / 3
x265 [info]: Keyframe min / max / scenecut / bias  : 25 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt        : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb       : 1 / 1 / 0
x265 [info]: References / ref-limit  cu / depth  : 3 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree  : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress            : CRF-24.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao
x265 [info]: frame I:      4, Avg QP:22.39  kb/s: 1197.05                        351.98 KB
x265 [info]: frame P:    198, Avg QP:27.64  kb/s: 129.82
x265 [info]: frame B:    778, Avg QP:31.24  kb/s: 51.67
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 1.5% 2.0% 1.5% 0.0% 95.0%

encoded 980 frames in 8.00s (122.44 fps), 72.13 kb/s, Avg QP:30.48

As you see the frames that appear to be processed are 200 to 1179, and that's what's expected OK.

Encoded output video It is expected to start at source frame 200. The encoded video does NOT start at frame 200 of source video. It starts at frame 0. (I have used a video showing timecodes in order to have accurate readings)

Question: Is that any way this could work correctly ? Or is it an absolute limitation ?

[DJATOM]

It's definitely possible and in my plans for vpyInput, but if @msg7086 will be faster, I'll cherry-pick that solution.

[ghost]

@DJATOM Nice to hear that ! Are there any plans for AVS ?

[DJATOM]

Implemented in my repo, AVS didn't yet cherry-picked from Yuuki-Asuna mod. You can get my mod with seeking on vpy here.

[ghost]

@DJATOM Amazing. That was fast. Tested OK. The frames are being seeked and counted properly !

[msg7086]

Picked DJATOM's commit and also added avs seeking in f9c3b280. I haven't had any time to test, but I guess I eventually will do.

[ghost]

@DJATOM @msg7086 Thank you both of you!

Currently, the only build that I got that has both AVS and VPY is a test build made (yesterday) by @Patman86, and I tested it thoroughly. I have of course tested VPY in @DJATOM 's build. All my tests showed success, fortunately.