Closed ghost closed 7 years ago
Wait, it seem that the error is mine. Replacing
vspipe --y4m script.vpy --timecodes tc.dat out.y4m x264 --demuxer y4m --tcfile-in tc.dat --qp 0 -o out.mkv out.y4m
with
vspipe --y4m temp.vpy --timecodes tc.dat - | x264 - --demuxer y4m --qp 0 --sar 32:27 -o out_nnedi3.264 mkvmerge -o out_nnedi3.mkv --timecodes "0:tc.dat" out_nnedi3.264
seem to work everytime.
Nevermind, managed to reproduce it.
Is this with the latest version from git? Or at least my 2.22 rc2 build? 2.21 has a very nasty bug that can make jumping happens once in a clip.
Using 2.21.32 d7dd577, so the latest git.
Hmm... some kind of reordering issue I guess. Can you try 2.20 too? (there have been loads of buggy and breaking changes since that version) I did try it quickly but this may also require some luck to reproduce.
I will be able to retry in one week (currently away from my data).
I actually managed to reproduce it on normal 30000/1001 fps content. Seems like the entire filter is fucked.
Maybe I should change the issue title? Anyway, I'll explain more what I got here:
-ffprobe out.VOB: Stream #0:1[0x1e0]: Video: mpeg2video (Main), yuv420p(tv), 720x480 [SAR 8:9 DAR 4:3], 7500 kb/s, 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc
-temp.vpy:
import vapoursynth as vs
core = vs.get_core()
clip = core.ffms2.Source("out.VOB") clip = core.std.Trim(clip, first=0, length=3000)
clip.set_output()
-The command: vspipe -y temp.vpy - | ffmpeg -r 30000/1001 -i - -c:v libx264 -qp 0 -preset ultrafast out_vs.mkv
Same random problems. Using latest git. I'll try with 2.20. Update: also happens with 2.20. Fuckup n°1, Fuckup n°2, with frameNum
I believe this issue is fixed in latest git. Reopen if not.
The simplest vapoursynth script possible:
Followed by:
As said in the doom9 thread, I got some randomly positioned jerkoffs like this: Original segment, Garbled segment.