Closed nixxquality closed 11 months ago
Does it gradually go more out of sync or is it constant?
It starts of in-sync. Apart from the vfr video it will desync even with fpsnum/fpsden.
The audio timecodes for the AAC track (1024samples/second) look weird:
[stts: Decoding Time to Sample Box]
position = 3774001020
size = 211496
version = 0
flags = 0x000000
entry_count = 26435
entry[0]
sample_count = 1
sample_delta = 1028
entry[1]
sample_count = 2
sample_delta = 1027
entry[2]
sample_count = 1
sample_delta = 1026
entry[3]
sample_count = 1
sample_delta = 1027
entry[4]
sample_count = 2
sample_delta = 1026
entry[5]
sample_count = 1
sample_delta = 1005
entry[6]
sample_count = 1
sample_delta = 1025
entry[7]
sample_count = 1
sample_delta = 1027
entry[8]
sample_count = 2
sample_delta = 1026
entry[9]
Wonder if that skrews over the sync algo.
I know there were issues with audio sync regarding Shadowplay files earlier (#216) but that's now fixed as long as files are smaller than 2.4GiB.
Could there possibly be a problem with that solution (e893f778) that makes it fail with big files?
I guess there could be, there are so many obscure issues lurking in there...
It's definitely the audio that's too long, maybe it gets over-padded
I had one more look and did some experimentation and still have no idea why it happens. It's definitely not overpadding that causes it either. It's just broken...
Strongly suspect this is the same issue causing #339.
Possibly fixed or improved with the padding toggle. Either way it's a weird file.
One of the users of my program reported this issue to me.
I suggested to him that he remux out parts from one of the >2.4GiB files and see if it has desync, and they didn't. Additionaly, he was able to use that part as an input file to get the parts of the video he needs through ffms2 without A/V desync.
I tested it myself and got the same results. Here is a file provided by that user that you can use to try things yourself: https://drive.google.com/open?id=0B64QzZXFMkpTUE5ISm5xdFlNVTg