I have this file:
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?Code: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
Here is my avsmod qtgmc config:
Code: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)
+ Reply to Thread
Results 1 to 10 of 10
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
All ideas are welcome, i'm very new to all of this, thanks
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)
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
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.
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
You can do this:
A = LSMASHVideoSource("cut.mov")
B = LSMASHAudioSource("cut.mov")
A = LWLibavVideoSource("cut.mkv")
B = LWLibavAudioSource("cut.mkv")
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.
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!
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.
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.
Last edited by emcodem; 7th Apr 2021 at 15:58.
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.