Shadowplay (H264) files larger than 2.4GiB get A/V desync

[nixxquality]

One of the users of my program reported this issue to me.

I've tested a variety of size'd 20 minute long shadowplay videos (ranging from 2 to 8GB each in size), and got some odd results:

• all ~2.4GB and higher files i tried didn't have audio synced up.
• all ~2.3GB and lower files i tried seemed to be synced up.

Shorter shadowplay files seem to be synced up (tested up to the 2.3GB file size), and even longer (and less in size) files from different sources seem to work with Trim.

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

[myrsloik]

Does it gradually go more out of sync or is it constant?

[sneaker2]

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.

[nixxquality]

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?

[myrsloik]

I guess there could be, there are so many obscure issues lurking in there...

[myrsloik]

It's definitely the audio that's too long, maybe it gets over-padded

[myrsloik]

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...

[CoffeeFlux]

Strongly suspect this is the same issue causing #339.

[myrsloik]

Possibly fixed or improved with the padding toggle. Either way it's a weird file.