[thakalas]

Got a weird one here. With a 59.94 or 60 FPS video file and SRT or SSA (could be others, only tested these 2) subtitles A/V sync gets really strange. Resolution doesn't matter as far as I can tell, nor do any h.264 settings. Everything from 3.0 baseline to 4.1 high does the same thing as long as it's up around 60 fps.

After variable amount of time, but usually no more than 30 seconds, playback will hiccup. On Gotham builds it was literally a hiccup, audio would cut for a split second and the video would jump a fraction and then playback would resume. With OpenELEC 5+ the video gets really fast for a second or two. Watching the codecinfo overlay I can see on the C line where it says a/v it will slowly count up 3 full numbers. Say, from 2.000 to 5.000 or -1.000 to 2.000. At that point it jumps back to the number it started on, and the audio and video hiccup. If there is a section with no subtitles displayed a/v sync will count down until more subtitles come up. If I turn subtitles off it plays perfectly of course. If I re-encode as a 30fps (or 29.97) it plays fine with subtitles. The cpu usage never rises above 90ish.

I always assumed the hiccups were due to the rpi being just a bit too slow to handle it. I got a pi 2 to play with, and it did exactly the same thing with no more than 15% on any core. This doesn't seem to be cpu bound. Since I had to use one of the newer builds for the pi 2 I had access to the acceleration options. This wierdness only occurs with omxplayer. If I uncheck omxplayer and only allow MMAL everthing works as expected. It runs poorly on the old pi with just MMAL but it doesn't hiccup from subtitles.

I've searched for a while looking for similar problems, but I didn't see any like this. Any help would be appreciated.

[popcornmix]

Could you provide a sample file (plus sub file) that shows the issue? E.g. create a couple of minutes long sample and upload somewhere (e.g. dropbox or google drive).

[thakalas]

These are recorded off of my Directv box by a Hauppauge HDPVR, transcoded with ffmpeg and muxed with mkvmerge. SRT is in the container.

https://drive.google.com/open?id=0ByuI4D...authuser=0

[thakalas]

Playing around with the Milhouse builds I found that #224 (OpenELEC-RPi.arm-Milhouse-20150224234406-#0224-g24ed310) and beyond fixes the subtitle issue, but unfortunately seeking has become very slow and stuttery. It takes almost a second for it to respond to the seek command and then it tends to play slow then really fast before it starts working right. Previous builds (223 and earlier) seeking worked instantly with no troubles.

[popcornmix]

Playing around with the Milhouse builds I found that #224 (OpenELEC-RPi.arm-Milhouse-20150224234406-#0224-g24ed310) and beyond fixes the subtitle issue, but unfortunately seeking has become very slow and stuttery. It takes almost a second for it to respond to the seek command and then it tends to play slow then really fast before it starts working right. Previous builds (223 and earlier) seeking worked instantly with no troubles.

Ah - I wondered if it had been fixed. I had a play earlier (with newclock4 tree used by Milhouse builds) and couldn't see your issue.
I guess the subtitle rate limited has helped.

The slow seeking may be smart seeking.
I think if you disable all but one of the seek settings, then it reverts to the old "instant seek" behaviour.

[thakalas]

The slow seeking may be smart seeking.
I think if you disable all but one of the seek settings, then it reverts to the old "instant seek" behaviour.

Ahaha, yes. In fast my "almost a second" matches up rather nicely with the default 750ms doesn't it. That's all perfect. The rate limiting makes a lot of sense from the different behaviors I observed with the different video framerates. It would struggle to get beyond 45fps or so which would cause the 60 fps videos to go weird, but 30fps videos were fine. I'm still confused about where the slowdown was, since it wasn't maxing out the cpu. But meh, as long as it's fixed.

Thanks for taking the time to look.