Use PTS differences for _Duration props

[arch1t3cht]

frame->duration is often just computed from the track-wide frame rate and hence unreliable.

For the last frame, where no following PTS is available, the logic just matches the previous frames's duration. In theory the track's duration could be referenced instead, but the current logic matches FFMS2.

[myrsloik]

Test this with a shitty m2ts stream where the PTS is unavailable for many frames. Not a bad idea but I'm not sure it's all the way there in realiability.

[cubicibo]

H.222 says that, if a PTS is not specified, it is is the responsibility of the decoder to interpolate the missing timestamps. I.e If libavcodec marks unspecified PTS appropriately (UINT_MAX iirc?), then you can use the estimated frame duration. Arguably it is FFmpeg job to do it.

For audio streams in TS container, it is somewhat common.

[myrsloik]

H.222 says that, if a PTS is not specified, it is is the responsibility of the decoder to interpolate the missing timestamps. I.e If libavcodec marks unspecified PTS appropriately (UINT_MAX iirc?), then you can use the estimated frame duration. Arguably it is FFmpeg job to do it.

For audio streams in TS container, it is somewhat common.

FFmpeg doesn't do it. Without code to take unknown PTS into account you'll get very weird values out of this one sometimes.

[cubicibo]

libavformat mpegts.c always resets the PTS to AV_NOPTS_VALUE. Unless a higher level block mendles with the field, you can watch for this value and switch to interpolation.

FWIW this PR may also lead to incorrect _Duration at the splice point of a concatenated TS. But I don't expect trunk or other software to always return a reasonable value in these case.

[arch1t3cht]

Does VS allow leaving _Duration unset or set to some explicit "Unknown" value like AV_NOPTS_VALUE? If so that might be preferable rather than making up timestamps.
If not, should there be some _DurationGuessed flag to mark frames whose _Duration was guessed?

Also, do you know where I can find samples for m2ts streams with missing PTSs for many frames? I have a few files that are missing timestamps for one or two frames, but not for more.

[cubicibo]

I don't have such samples. H.222 states that a decoder must be able to interpolate timestamps for as long as 700 ms. Broadcasters are generally well behaved and avoid it or stick to small gaps.

If _Duration is merely informative, I would just set it to some undefined value and call it a day. A proper fix must consider neighbouring PTSs. You wouldn't want to interpolate a PTS ahead of the next frame, which sets the values properly.

[myrsloik]

cit "Unknown" value like AV_NOPTS_VALUE? If so that might be preferable rather than making up timestamps. If not, should there be some _DurationGuessed flag to mark frames whose _Duration was guessed?

Also, do you know where I can find samples for m2ts stream

Just leave _Duration unset. The worst offenders are usually CFR transport streams anyway.

[radpopl]

Also, do you know where I can find samples for m2ts streams with missing PTSs for many frames? I have a few files that are missing timestamps for one or two frames, but not for more.

I have a few of these M2TS downloaded from a Digital8 camera. Since they are private, I can only provide a link to one of them via email. MAGIX Vegas reads them correctly, ffmpeg recodes them correctly, MPC plays them correctly -- but none of the AviSynth plugins can read them correctly without desync the video from the audio.

[arch1t3cht]

Took a while, but I updated this now. As discussed it just leaves _Duration unset now when it can't be reliably computed.