QTGMC mov 29.970 (Constant fps) Ends up 58.42 FPS rather than 59.940

[VidNew23]

I have this file:

Video
ID                                       : 1
Format                                   : MPEG Video
Commercial name                          : HDV 1080i
Format version                           : Version 2
Format profile                           : Main@High 1440
Format settings                          : CustomMatrix / BVOP
Format settings, BVOP                    : Yes
Format settings, Matrix                  : Custom
Format settings, GOP                     : M=3, N=15
Format settings, picture structure       : Frame
Codec ID                                 : hdv2
Duration                                 : 2 s 536 ms
Source duration                          : 2 s 569 ms
Bit rate mode                            : Constant
Bit rate                                 : 25.0 Mb/s
Width                                    : 1 440 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 29.970 (29970/1000) FPS
Original frame rate                      : 29.970 (30000/1001) FPS
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan type, store method                  : Interleaved fields
Scan order                               : Top Field First
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.536
Stream size                              : 7.63 MiB (93%)
Source stream size                       : 7.71 MiB (94%)
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709
mdhd_Duration                            : 2536
Codec configuration box                  : glbl

When i run it using qtgmc which usually doubles the frame rate, rather then becoming a file with 59.940 fps (which would be the double from the original framrate the clip has) it ends up being 58.42 fps, any idea why this occurs and what i can do to fix it?

Here is my avsmod qtgmc config:

LSMASHVideoSource("cut.mov")
ConvertToYV12() 
AssumeTFF() 
ColorYUV(levels="TV->PC")
QTGMC(preset="Slower", SourceMatch=3, Lossless=2, MatchEnhance=0.75,  Sharpness=0.5, EdiThreads=1)
BilinearResize(1920,1080)
Crop(0,0,-0,-0)

[VidNew23]

Here's an example of a file that does become the proper 59.94 fps frame rate when ran through qtgmc:

Video
Format                                   : MPEG Video
Format version                           : Version 2
Format profile                           : Main@Main
Format settings                          : CustomMatrix / BVOP
Format settings, BVOP                    : Yes
Format settings, Matrix                  : Custom
Format settings, GOP                     : M=3, N=15
Format settings, picture structure       : Frame
Duration                                 : 26 min 51 s
Bit rate mode                            : Variable
Bit rate                                 : 3 926 kb/s
Maximum bit rate                         : 6 000 kb/s
Width                                    : 720 pixels
Height                                   : 480 pixels
Display aspect ratio                     : 4:3
Frame rate                               : 29.970 (30000/1001) FPS
Standard                                 : NTSC
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan order                               : Bottom Field First
Compression mode                         : Lossy
Bits/(Pixel*Frame)                       : 0.379
Time code of first frame                 : 00:30:12:00
GOP, Open/Closed                         : Closed
Stream size                              : 754 MiB (100%)
Color primaries                          : BT.601 NTSC
Transfer characteristics                 : BT.601
Matrix coefficients                      : BT.601

I can see that the clip that converts into faulty frame rate also has a descriptor called "Original frame rate" maybe this is the problem?

All ideas are welcome, i'm very new to all of this, thanks

[hello_hello]

Try this:

LSMASHVideoSource("cut.mov")
Info()

If it's not 30000/1001 you can do this. It adds or drops frames to give you 30000/1001. Adding them in this case, I assume.

LSMASHVideoSource("cut.mov", FPSNum=30000, FPSDen=1001)
Info()

Also, if in doubt try remuxing the mov file as an MKV with MKVToolNix to see what MediaInfo says then, and open that with LWLibavVideoSource. You can still add the frame rate conversion stuff.
LWLibavVideoSource("cut.mkv", FPSNum=30000, FPSDen=1001)

The question is though, is the audio in sync when the output is 58.42 fps? Of so, just leave it. If not it's probably variable frame rate and you'll need to use FPSNum=30000 & FPSDen=1001, otherwise lsmash decodes at the average frame rate.

PS. Why ColorYUV(levels="TV->PC")? Are the levels wrong? The source is already YV12 so you don't need to convert it. From MediaInfo:

Chroma subsampling : 4:2:0

http://avisynth.nl/index.php/Convert

Another thought... 1080i (at 1920x1080) and 720p have roughly the same spacial resolution.
1080i at 29.97fps has a greater temporal resolution than 720p at 29.97fps, but you're doubling the frame rate so you're not losing anything there. It's up to you of course, but as a rule you can de-interlace 1080i and resize to 1280x720 without any detail loss, and when de-interlacing with QTGMC, the 720p version will probably still look better.

[VidNew23]

Try this:

LSMASHVideoSource("cut.mov")
Info()

If it's not 30000/1001 you can do this. It adds or drops frames to give you 30000/1001. Adding them in this case, I assume.

LSMASHVideoSource("cut.mov", FPSNum=30000, FPSDen=1001)
Info()

Also, if in doubt try remuxing the mov file as an MKV with MKVToolNix to see what MediaInfo says then, and open that with LWLibavVideoSource. You can still add the frame rate conversion stuff.

The question is though, is the audio in sync when the output is 58.42 fps? Of so, just leave it. If not it's probably variable frame rate and you'll need to use FPSNum=30000 & FPSDen=1001.

PS. Why ColorYUV(levels="TV->PC")? Are the levels wrong? The source is already YV12 so you don't need to convert it..

Thank you for the reply! Interesting, info() gives me that the FPS is 29.2111 which becomes 58.4222 doubled, so i guess qtgmc is correct doing this then and mediainfo is detecting the fps wrongfully?

I have not yet rendered a long enough file to see if the audio is out of sync, but i was asuming it would be if the fps wasn't correct, but i guess it may be correct then?

Regarding ColorYUV, no reason really, i have no idea what i am doing, it added more "contrast" to the output and made the image look "less dull".

I will try to render a long clip and see if it puts the audio out of sync

[hello_hello]

You can do this:

A = LSMASHVideoSource("cut.mov")
B = LSMASHAudioSource("cut.mov")
AudioDub(A, B)

or

A = LWLibavVideoSource("cut.mkv")
B = LWLibavAudioSource("cut.mkv")
AudioDub(A, B)

That'll give you video and audio. You should be able to open the script with VirtualDub2 or MPC-HC to see if they're in sync, as long as your PC can decode the video in real time. Do it without QTGMC de-interlacing though because it's slow, or use something like Yadif(Mode=1) for de-interlacing while you're testing, then replace it with QTGMC.

Can you post a screenshot of your source? The levels may be okay but it's not displaying correctly on your PC. Does it look as though there's not enough contrast when you play it with a standalone player and your TV?

I added some stiff to my previous post if you're interested.

[poisondeathray]

old lsmash version ?

This one is slightly older but pretty stable
https://github.com/HolyWu/L-SMASH-Works/releases

[VidNew23]

Another thought... 1080i (at 1920x1080) and 720p have roughly the same spacial resolution.
1080i at 29.97fps has a greater temporal resolution than 720p at 29.97fps, but you're doubling the frame rate so you're not losing anything there. It's up to you of course, but as a rule you can de-interlace 1080i and resize to 1280x720 without any detail loss, and when de-interlacing with QTGMC, the 720p version will probably still look better.

Thanks for the tip! So you're saying that whenever a video 1080i its actually better to qtgmc them to 720p rather then 1080p?

I will try the other thing you wrote regarding audio sync, my comp is busy doing some other work right now before i can test this out, thanks for all the tips!

[hello_hello]

Thanks for the tip! So you're saying that whenever a video 1080i its actually better to qtgmc them to 720p rather then 1080p?

When I referred to the 720p version looking better after de-interlacing with QTGMC, I meant it'll look better than the original 1080i if you view that being de-interlaced by a hardware player or TV etc, as QTGMC's de-interlacing is generally higher quality.

Assuming you de-interlace with QTGMC each time, de-interlacing and then downscaling to 720p won't look better than de-interlacing and keeping it at 1080p, but I doubt it'll look any worse because 1080i has roughly the same spacial resolution as 720p. Or to put it another way, 1080i doesn't have the same spacial resolution as 1080p, so you probably won't lose any detail by downscaling a bit after de-interlacing.

Try a small encode at both resolutions and run them full screen to compare them to see if you can see much/any difference.

[emcodem]

In theory it is true that 720p50 contains the same spatial information than 1080i25. But as usual the problem lies in the details.

You will always loose details after downscaling, for example imagine a thin lined wire fence or similar image content. As we first need to deinterlace and only after it, we can scale, the scaling process is of course always very lossy. We would potentially loose some of the thin wires of the fence when scaling the width and therefore greatly change the image content actually.

The "Frame rate" from mediainfo is a calculated value that cannot be trusted. Our good @hello_hello already took part of the same discussion here: https://forum.doom9.org/showthread.php?t=172086#:~:text=MediaInfo%20shouldn't%20be%20m...0ffmpegsource2.

The bottom line is that the mediainfo value for "Frame Rate" is just a guess by mediainfo, it cannot really be trusted. So my recommendation is to use assumefps because the original problem is just that the original framerate was detected incorrectly. We do not want the decoder to throw away or double any frames but just tell avisynth what is the actual framerate.

[hello_hello]

For 1080i, there's no full frames.The top field displays, then the bottom field, then the top field etc. The top field is (lets assume) all the even scanlines. The bottom field contains all the odd scan-lines. In the CRT days the TV would alternate between refreshing the even and odd scanlines, but in a progressive world we need whole frames.

So the de-interlacer has to fill in gaps and interpolate the missing scan lines, turning fields into full frames and doubling the frame rate. It's not just a matter of filling in the missing scanliness though. Maybe the de-interfacer borrows from the surrounding fields..... I don't fully understand how that works, but each field is a unique moment in time, so there's probably shimmer repair and anti aliasing to worry about, and that can destroy fine detail long before downscaling. There's no escaping the fact that a field only has 540 scan lines of real picture to contribute to a 1080p frame, and the other 540 scan lines are faked.

There's a standard def example attached below. The source was 576i (PAL), de interlaced to 50fps and downscaled to 480p. I think the 480p downscale looks better than the source being de-interlaced by my TV. Any loss of fine detail would be due to some light denoising rather than the downscaling, but the wire tray on the desk (as the camera pans) looks better after it's de-interlaced and downscaled. As do the window blinds in the background.

For the frame rate issue...
MedfiaInfo has nothing to do with it. If anything it's reporting the frame rate we'd like to have, but it's Avisynth reporting a frame rate of 29.2111 fps. We still have no idea if the video and audio are in sync and at what frame rate etc, so there's no way to know how to handle it yet.

I've been through this exact situation many, many times, and I know once Lsmash spreads the existing frames out at the average frame rate, you can use AssumeFPS to your heart's content but all that does is change the total video duration and if the A/V sync is out, it'll probably make it worse.

It's possible the frame rate really should be 29.2111 and the A/V sync is fine. It's also possible the audio is already out of sync and adjusting the frame rate to 29.97fps with AssumeFPS() will fix it. VidNew23 hasn't said the audio is out of sync in the source though, so assuming it's okay, either 29.2111fps is the correct frame rate, or Lsmash needs to replace null frames for 29.97fps instead of decoding at the average rate. AssumeFPS() always changes the A/V sync because it changes the video duration, whereas specifying a frame rate for Lsmash changes the frame count instead.