Do you have deinterlace turned on (or set to auto - they do the same thing *). Turn it off and I believe the clip will play smoothly for about 5 minutes.
What happens at 5mins is a bit bizarre. The file seems to start duplicating frames. E.g.
Code:
dts=180347000 pts=UNKNOWN size=46444
dts=180389000 pts=UNKNOWN size=89388
dts=180389000 pts=180389000 size=89388
dts=180430000 pts=UNKNOWN size=48652
...
dts=234443000 pts=UNKNOWN size=11824
dts=234484000 pts=UNKNOWN size=88482
dts=234484000 pts=234484000 size=88482
dts=234526000 pts=UNKNOWN size=11088
...
dts=234776000 pts=UNKNOWN size=11887
dts=234818000 pts=UNKNOWN size=86069
dts=234818000 pts=234818000 size=86069
dts=234860000 pts=UNKNOWN size=16346
So, there are two frames of size 89388 at timestamp 180389000.
Obviously duplicating I frames is wasting space in the file and is a bug in the encoder.
But, it also throws out our fps calculation, which keeps the video and hdmi update in sync.
(*) Couple of problems with deinterlace. Both on and auto are treated the same. If deinterlace is on and video is h264, and it uses the right sort of NAL packets it might be able to determine it is not interlaced, and switch it off. For non-h264 it will always be on.
Deinterlacing a video file doubles the framerate (as well as causing a slight blurring). Normally interlaced content is 25 or 30 frames per second and is displayed on a 50 ot 60 Hz display, so framerate syncing works.
For a 24 frames per second video, the deinterlace will produce 48 frames per second which isn't a standard hdmi mode, so it doesn't sync correctly.
I've got a plan to make the auto deinterlace detection more robust, by asking the GPU. However that is complicated as it requires inserting the deinterlace openmax component after the first frame has decoded which will require some rearchitecting of omxplayer.
For now, make sure deinterlace is disabled unless you really need it.
