29.97 fps get out of sync after encoding with Megui

[wthreex]

I have a video with this fps:

Frame rate : 29.970 (30000/1001) FPS
Original frame rate : 29.970 (29970/1000) FPS

and after encode, Megui changes the fps to:

Frame rate : 25.000 FPS

and hence video gets out of sync , how to solve this problem?

[SaurusX]

Has to be a script issue. Post the script.

[wthreex]

@SaurusX I dont change anything , I'd open the file via File indexer (FFMSIndex) and load it as oneclick encoder as save the current script:


LoadPlugin("C:\Users\Dio\Downloads\Programs\MeGui\tools\ffms\ffms2.dll")
FFVideoSource("C:\Users\Dio\Downloads\video.mkv", fpsnum=30000, fpsden=1001, threads=1)
#deinterlace
#crop
#resize
#denoise


Mediainfo:



Complete name : C:\Users\Dio\Downloads\video.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 77.9 MiB
Duration : 2 min 31 s
Overall bit rate : 4 313 kb/s
Writing application : Lavf57.71.100
Writing library : Lavf57.71.100
ErrorDetectionType : Per level 1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2 min 31 s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Original frame rate : 29.970 (29970/1000) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Default : Yes
Forced : No
DURATION : 00:02:31.483000000

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 2 min 31 s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 spf)
Compression mode : Lossy
Delay relative to video : -5 s 736 ms
Default : Yes
Forced : No
DURATION : 00:02:25.754000000



and Here (https://mega.nz/#!cgEhHCpY!8_aHv1q5nraq7bv94V2yoIIZKIB6xkQ_ZrvQCa5yO-M) is my video if you would want to test it manually thanks!

[SaurusX]

You can either try a new source filter like LWLibavVideoSource or add assumefps(30000,1001) at the end of your script. The latter will definitely work, but it might be the source filter is the root cause.

[wthreex]

Didnt work.

[manolito]

This made me curious, did a few tests converting it to an NTSC DVD, here is what I got:

The problem with this source is the huge negative audio delay of -5736 ms. The different souce filters have different ways how they deal with this delay.

1. DSS2Mod for video and DirectShowSource for audio:
You need to NOT honor the audio delay.

2. FFMS2 for both audio and video:
Same as before. The audio delay must be discarded.

3. LWLibavVideoSource and LWLibavAudioSource:
The audio delay needs to be honored for perfect sync.

Script:
Audio = LWLibavAudioSource("C:\Download\video.mkv", stream_index=-1)
Video = LWLibavVideoSource("C:\Download\video.mkv", stream_index=-1, format="YUV420P8", seek_mode=0).ChangeFPS(29.97)

Video = Video.ConvertToYV12()
Video = Video.Spline36Resize(720,480)

Audio = Audio.ConvertAudioToFloat.SSRC(48000)
Audio = Audio.DelayAudio(-5.736)

AudioDub(Video, Audio)
Please note the "ChangeFPS" call after the video source filter. The alternative to use fpsnum and fpsden results in very choppy playback.

I am not familiar with MEGui, but it should have a checkbox somewhere which lets you discard the audio delay.


Cheers
manolito

[StainlessS]

I've learnt something today,
you can call delayaudio on an audio only clip, I presumed that it adjusted timing of audio relative to video rather than adjusting timestamps soley in the audio clip.
So, thanks for the lesson Mani.
However, I have a habit of using trim(0,0) on pretty much every clip, which either chops off overlong audio, or pads out short audio, to match video length.
Unless there is a good reason not to, I suggest also adding Trim(0,0) to end of script.
[It also causes any following processors not to make any assumptions as they will find completely aligned video/audio]

[Sharc]

Simple remuxing with mkvtoolnix solved the issue here.
I got a frozen picture (black or the 1st frame, depending on the player) for 5s at the beginning with audio only, and afterwards video and audio are is in sync.

[manolito]

Simple remuxing with mkvtoolnix solved the issue here.
I got a frozen picture (black or the 1st frame, depending on the player) for 5s at the beginning with audio only, and afterwards video and audio are is in sync.

Maybe for playback (which also worked before), but not for reencoding... :devil:

The remuxed MKV still shows the same audio delay in MediaInfo, and reencoding using either DSS2Mod or ffms2 still only is in sync if the audio delay is explicitly discarded.

[Sharc]

Maybe for playback (which also worked before), but not for reencoding... :devil:

Ooops, I missed that the OP wants to re-encode (and frame rate convert?) for some reason.

[manolito]

I've learnt something today,
you can call delayaudio on an audio only clip, I presumed that it adjusted timing of audio relative to video rather than adjusting timestamps soley in the audio clip.
So, thanks for the lesson Mani.
You need to thank MrC instead of me, this code was generated by AVStoDVD.

However, I have a habit of using trim(0,0) on pretty much every clip, which either chops off overlong audio, or pads out short audio, to match video length.
Unless there is a good reason not to, I suggest also adding Trim(0,0) to end of script.
[It also causes any following processors not to make any assumptions as they will find completely aligned video/audio]
Nice idea, but it does not help with this clip... :eek:
For DSS2Mod as well as for ffms2 adding a "Trim(0,0)" to the end of the script has no effect on the audio delay handling. If you do not explicitly discard the delay which is reported by MediaInfo then your result will not be in sync.

[StainlessS]

To clarify,
adding Trim(0,0) to end of script.
Was not suggesting replace of AudioDelay with trim.
Are you saying that trim(0,0) would make it cease to work correctly after Delayaudio() ?
[EDIT: I like to add trim(0,0) at END of every script]

[manolito]

To make it absolutely clear:

Adding "Trim(0,0)" to the end of the script made no difference at all for the audio sync of the result.

For DSS2Mod and for ffms2 the "DelayAudio" command needs to be commented out for perfect sync. Does not matter if the trim command is there or not. And for LWLibav the "DelayAudio" needs to be there for perfect sync, and again the Trim command at the end of the script does not make any difference.

[StainlessS]

OK, thanks, but it does chops off any eg extraneous silent audio that you sometimes get at end of clip where video stops but clip seemingly continues till silent audio teminates.
Was not aware that ffms and LSmash handle delay differently, again thanking you nicely. :)

[manolito]

I recall an older discussion with DG about the different source filter philosophy about how to deal with negative audio delays at the beginning of a file. (Can't find the posts right now)

The DG source filters keep the leading audio because the audio information might be important, instead they repeat the first video frame until the audio catches up. Looks like LWLibav does the same.

All DirectShow based source filters and ffms2 cut off the leading audio instead. I have no opinion which method is the better one, I just wish that the source filter authors could agree on just one of these two methods...

[wthreex]

Hello folks, I appreciated to all of your responses to thread, Accepting Delay to video solved the problem, @manolito may i ask how did you find the exact delay amount?

[StainlessS]

how did you find the exact delay amount?


Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 2 min 31 s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 spf)
Compression mode : Lossy
Delay relative to video : -5 s 736 ms # ie -5736 ms OR -5.736 secs
Default : Yes
Forced : No
DURATION : 00:02:25.754000000

[manolito]

Maybe for playback (which also worked before), but not for reencoding... :devil:

The remuxed MKV still shows the same audio delay in MediaInfo, and reencoding using either DSS2Mod or ffms2 still only is in sync if the audio delay is explicitly discarded.
I might have misunderstood you...

Loading the original MKV and just remultiplexing it does indeed behave as I said. But first extracting the streams with gMKVExtractGUI and then adding the streams to MKVMerge (preserving the delay in the extracted file names) and muxing them results in an MKV with only a very small audio delay which behaves perfectly with all source filters I tried.