Lags when playing certain MPEG-4 files (VFR/CFR)

[reyaz006]

Using PotPlayer. There are no lags when using ffmpeg.

First of all, the way how the files are encoded look strange. This is what I see in media info reported by the player:

Frame rate mode: Variable
Minimum frame rate: 14.988 FPS
Maximum frame rate: 90 000.000 FPS

But the video itself is constant 29.97 fps. The output FPS is below that due to lags.

If it helps, here is the encoding info found inside the file: x264 - core 142 r2409M+r890[x86] release1 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:1:1 analyse=0x1:0x111 me=hex subme=6 psy=1 fade_compensate=0.00 psy_rd=0.50:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=0 interlaced=0 bluray_compat=0 constrained_intra=0 fgo=0 bframes=2 b_pyramid=0 b_adapt=1 b_bias=0 direct=3 weightb=1 open_gop=0 weightp=1 keyint=60 keyint_min=31 scenecut=0 intra_refresh=0 rc_lookahead=10 rc=cbr mbtree=1 bitrate=5744 ratetol=1.0 qcomp=0.60 qpmin=5 qpmax=69 qpstep=4 vbv_maxrate=5744 vbv_bufsize=12000 nal_hrd=vbr filler=0 ip_ratio=1.40 aq=1:1.00

Quote from BlueskyFRC developer about this:

LAV Video Decoder Start=00:00:00.0670000, End=00:00:00.1003667 Start=00:00:00.0997333, End=00:00:00.1331000, Duration=00:00:00.0327333 Start=00:00:00.1331000, End=00:00:00.1664667, Duration=00:00:00.0333667 Start=00:00:00.1673666, End=00:00:00.2007333, Duration=00:00:00.0342666 Start=00:00:00.1998333, End=00:00:00.2332000, Duration=00:00:00.0324667 Start=00:00:00.2342000, End=00:00:00.2675667, Duration=00:00:00.0343667 Start=00:00:00.2674666, End=00:00:00.3008333, Duration=00:00:00.0332666 Start=00:00:00.2999333, End=00:00:00.3333000, Duration=00:00:00.0324667 ...... Start=00:00:02.0346333, End=00:00:02.0680000, Duration=00:00:00.0331000 Start=00:00:02.0020000, End=00:00:02.0353667, Duration=-00:00:00.0326333 <= wrong start time Start=00:00:02.1017333, End=00:00:02.1351000, Duration=00:00:00.0997333 Start=00:00:02.1351000, End=00:00:02.1684667, Duration=00:00:00.0333667 Start=00:00:02.1693666, End=00:00:02.2027333, Duration=00:00:00.0342666 Start=00:00:02.2018333, End=00:00:02.2352000, Duration=00:00:00.0324667 ..... Start=00:00:04.0372666, End=00:00:04.0706333, Duration=00:00:00.0336333 Start=00:00:04.0040000, End=00:00:04.0373667, Duration=-00:00:00.0332666 <= wrong start time Start=00:00:04.1037333, End=00:00:04.1371000, Duration=00:00:00.0997333 Start=00:00:04.1371000, End=00:00:04.1704667, Duration=00:00:00.0333667 Start=00:00:04.1713666, End=00:00:04.2047333, Duration=00:00:00.0342666 Start=00:00:04.2038333, End=00:00:04.2372000, Duration=00:00:00.0324667

LAV Video Decoder send samples with wrong start time, so the renderer will drop this sample.

Also, when I re-save the full video or parts of it with VideoReDo TVSuite (witout re-encoding anything), the output files do not have such issues. But they end up having different attributes:

Frame rate mode: Constant
Original frame rate: 29.97 FPS

I'm guessing this is the source of the issue - wrong attributes embedded in header. I wonder if it's possible to just change a few bytes in the original file to fix this.

[clsid2]

Try latest development build, which has newer FFmpeg code: https://files.1f0.de/lavf/nightly/LAVFilters-0.74.1-34.exe

[reyaz006]

Tried this now. It did not solve the issue.

[clsid2]

The LAV developer will need a sample file. Upload to Dropbox, Google drive, or some other free file host like Mediafire/Zippyshare/Sendspace.

You can use this tool to cut a piece if it is too large to upload: http://rationalqm.us/dgsplit/dgsplit12.zip

[reyaz006]

Here (beware, it's nsfw) sample is a piece of the original problematic file. sample_fix is the same file after re-saving (not re-encoding) with VideoReDo TVSuite.

[clsid2]

It plays without lags with MPC-HC at 29.5 fps. But I do see a glitch in the OSD timings graph every two seconds.

It is probably just a badly muxed file.

[reyaz006]

I'm using 60 fps conversion and the lag is more apparent with it since the output is always around 58 fps.

It is probably just a badly muxed file.

I'm not sure if this is equal to few attributes being wrongly set.

Do you mean that I'm supposed to fix this issue by re-muxing such files (re-saving like I did with sample_fix) and there will be no fix in LAV Video? Even though ffmpeg can process them fine as is.

[Nevcairiel]

Unfortunately the sample link expired. Its generally recommended to provide sample links that are available for a bit longer to allow working on such issues on a flexible time schedule.

If you can provide the sample again, I'll look into it.

[reyaz006]

I've updated the link. Did not test with latest 0.75 though.

[ValZapod]

What is THIS? After VideoReDo TVSuite:

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

There is no such thing as 29970/1000!! Only integer devided by 1001 which makes non-integer framerate!!! WTF. This is non-standard and may be the problem here. It is very hard to convert between integer and non integer versions of the same frame rate but here we have even worse situation where we have accurate to the second digit after the point framerate but it is still a little bit different. Also 90000 Hz happens because of the timebase in TS...

[reyaz006]

I don't know if this is related, but since the full file was much bigger, I just cut the rest of the bytes with hex editor. Hence, some data may be incorrectly interpreted by software, depending on how it's calculated. The issue described here was still there after the cut so I thought it's not a problem.

[ValZapod]

No, this is not related. Mediainfo does not read a lot of frames anyway.