Error when encoding VFR video

[jagabo]

I get the following via AviSynths Info() function:

LWlibavVideoSource("0001.ts")                            # 39026 frames, 29.97 (30000/1001) fps

LWlibavVideoSource("0001.ts", fpsnum=30000, fpsden=1001) # 39037 frames at 29.97 (30000/1001) fps.

ffVideoSource("0001.ts")                                 # 37459 frames, 28.7588 fps

ffVideoSource("0001.ts", fpsnum=30000, fpsden=1001)      # 39037 frames, 29.97 (30000/1001) fps

The version of LSMASHSource.dll I have is about two years old, ffms2.dll about three years old.

[naoto89]

If your sample was processed with LWLibavVideoSource, I don't understand how you got 23.976 fps. When I use LWLibavVideoSource I get 28.759 (TFM) and 23.007 fps (TDecimate).

Your LSmash version might be old/buggy ?

https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/releases

I don't think so, It's been a long time since I made changes on plugins folder because until now I had not needed it.

It's because by default LWLibavVideoSource decodes in VFR mode, but outputs the average frame rate for Avisynth. Each gap decreases the average frame rate a little. If the video was progressive you could extract the timecodes and use them for a VFR encode (retaining the gaps when encoding) but because you need to apply IVTC the number of frames will change so the original timecodes won't work.
As jagabo said, use FPSNum and FPSDen to force decoding at a constant frame rate of 29.970fps and LWLibavVideoSource will fill in the gaps by repeating frames. Unless you remux the TS file as an MKV while retaining the gaps (remuxing with MKVToolNix should be fine) you'll have to use the TS file as the source.

After having updated L-smash, the framerate changed to normal numbers and I didn't have to force the framerate but still the same problem

[hello_hello]

After having updated L-smash, the framerate changed to normal numbers and I didn't have to force the framerate but still the same problem

Does "same problem" refer to the A/V sync? You'll still have to force the frame rate, otherwise lsmash will still skip the gaps even if for some reason it's outputting the original frame rate. Comparing the total number of frames with and without frame rate conversion will tell you if something is changing.

The attached file was created with the following script.
The audio was extracted from the TS file with eac3to.
The two were combined with MKVToolNix without applying any audio delay.

LWLibavVideoSource("D:\0001.ts", cachefile="D:\0001.ts.lwi", fpsnum=30000, fpsden=1001)
TFM()
TDecimate(denoise=true)
CropResize(480,360, InDAR=4.0/3.0)

[jagabo]

Encoding:

LWlibavVideoSource("0001.ts", cache=false, fpsnum=30000, fpsden=1001) 
TFM()
TDecimate(Denoise=true)

and comparing the result with hello_hello's file in post #30, there's a perfect match frame-for-frame (aside from the resizing and encoding differences).

[naoto89]

Does "same problem" refer to the A/V sync? You'll still have to force the frame rate, otherwise lsmash will still skip the gaps even if for some reason it's outputting the original frame rate. Comparing the total number of frames with and without frame rate conversion will tell you if something is changing.

I was doubting about force the framerate as that could cause jerky. And what exactly does TDecimate's denoise parameter do?

[naoto89]

Friends, I need your help again regarding this same problem but now with a TS from Japan. I have repeated the deinterlaced//decimated methods that I used previously but the results are not good and the video is out of sync with the audio. Even if I use L-SMASH as recommended in previous messages, the duration of the output video is extended to 10 more seconds, which should not happen. I leave this sample of almost 2 minutes for you to check.

[jagabo]

I get the same length (1:57) and smooth 23.976 fps using:

LWLibavVideoSource("117s.ts") 
TFM()
TDecimate(Denoise=true)

[naoto89]

I get the same length (1:57) and smooth 23.976 fps using:

LWLibavVideoSource("117s.ts") 
TFM()
TDecimate(Denoise=true)

Being only 2 minutes of sample it's very possible that desync problems will not be noticed in the output video but if I encode the entire 30-minute video (the source weighs 2.37GB), the desync does become evident. And as I mentioned before, if I add fpsnum/fpsden in the line to open video, it increases the output video by 10 seconds. Something I forgot to mention is that DGIndex detects field order transition when creating the D2V index file. I'm not sure what to do and that's why I avoid using it.

[jagabo]

If I can't duplicate your problem I can't give you a definitive fix. But try this:

a = LWLibavAudioSource("117s.ts") 
v = LWLibavVideoSource("117s.ts", fpsnum=30000, fpsden=1001) 
AudioDub(v, a)
TFM()
TDecimate(Denoise=true)

Is the resulting audio in sync throughout the video?

By the way, the Denoise=true in TDecimate() makes it use a denoised version of the video for determining which frames to delete. That can help it delete the correct frames with noisy video (where the noise can make identical frames look different). The output of the filter isn't denoised.

[naoto89]

I discovered something when trying these lines

DGSource(DD.dgi)                                                              # Trim(527,55792), 55266 frames, 00:30:43.967, 29.970 fps
LWLibavVideoSource(DD.ts)                                                # Trim(534,55494), 54961 frames, 00:30:33.832, 29.970 fps
LWLibavVideoSource(DD.ts, fpsnum=30000, fpsden=1001)   # Trim(535,55800), 55266 frames, 00:30:44.009, 29.970 fps
ffVideoSource(DD.ts)                                                          # Trim(532,55492), 54961 frames, 00:30:45.392, 29.782 fps
ffVideoSource(DD.ts, fpsnum=30000, fpsden=1001)             # Trim(532,55797), 55266 frames, 00:30:44.009, 29.970 fps

I didn't understand why the 10 seconds but then I realized that I was wrong to make cuts to audio with the LWLibavVideoSource(DD.ts) trim. I had to cut audio again but this time use the DGSource(DD.ts) trim. I make the audio cuts with a VBS script that generates a .bat file that runs MKVmerge. About AudioDub, whether I use the audio direct from the source or the audio cutted, I realized that there is a delay of more or less 500 ms, although that shouldn't happen if I'm cut into the desired parts. If it's the delay, I just have to get the number or the audio extracted by DGIndex.