Well, it
is a source fault. More specifically, the frame rate of the video stream is
irregular: there are
dropped frames in the video stream.
MediaInfo (and MediaInfo.NET) shows (incorrectly) that it has 23.976 (24000/1001) fps, but if you look into the file using
ffprobe, you get the following info:
Therefore, if you encode this file using FFmpeg (or other FFmpeg based apps like Handbrake, etc.), the video encoder automatically fills in the dropped frames by duplicating frames appropriately.
In reality, if you run the following simple FFmpeg command in CMD, you'll verify it in the real time log message of FFmpeg.
Code:
ffmpeg -hide_banner -i Test.vob -c:v libx264 -crf 22.0 -preset medium -c:a aac -ac 2 -b:a 128k -sn -map_metadata -1 -map_chapters -1 -y Test.mp4
[Log]
In StaxRip (and other AVS based apps), the video stream frame rate info differs depending on what kind of source filter you use for this file (29.97 for DGSource, 24 for FFVideoSource, etc.), and that's what makes the problem complicated in this case.
Then, how can we make StaxRip fill in dropped frames by duplicating frames?
Well, in theory, putting
ChangeFPS(30000, 1001) in the AVS script is expected to solve this out-of-sync problem, but in reality, it doesn't. Since StaxRip splits video and audio and deals with them separately, video/audio sync is not tackled appropriately by this method.
In my experience,
piping via FFmpeg along with a forced frame rate seems to be more effective for out-of-sync problems.
Suppose you want to encode an HEVC video stream via NVEnc, but you want to fix this dropped frame issue as well.
In this case, instead of piping via avs2pipemod, select
Command Line encoder and edit the code like this:
You can
force the frame rate by using this
-r option in ffmpeg.
(This is why you need to create a Command Line encoder profile instead of choosing
ffmpeg (DXVA2) decoder in NVEnc options.
Technically, choosing
ffmpeg (DXVA2) decoder in NVEnc options is exactly the same as the above Command Line encoder code except for the
-r option.
I think it'd be good if @stax76 implemented this additional item in NVEnc
ffmpeg (DXVA2) decoder option.
)
Choose your own audio encoding.
After muxing is done, you will see the final sync is a little bit off: video is a little delayed behind audio. But as
ffprobe tells us, the video starts at 0.280633 second, i.e., about 281 milliseconds.
So, you need to remux video (hevc) and audio by delaying the audio by 281 milliseconds.
Now you'll see the output is fully in sync.