R1 Star Trek Deep Space Nine framerate issues

I have the R1 DVDs of ST: DS9, and I’ve just looked at a few episodes via their mkv backups (which have had no post-processing applied) and noticed the following behaviour: playback starts with a framerate of 29.97 according to the playback stats, and then at some point, it switches to 30. At that point I get picture and sound dropout as my TV adjusts. On some episodes, the initial framerate is 59.94, but then it switches to 60, again causing a second or two of interrupted playback. I have seen the same behaviour on a LibreELEC Pi with MMAL playback.

I know these episodes are tricky due to the combination of standards-converted film with video effects, but ideally, playback would be at a fixed 29.97 or 59.94 rate. Perhaps this is a disc authoring issue and I’m stuck with this? Just wondered if anyone has had any success in playing this type of source or has any suggestions. Thanks.

Which OSMC devices do you experience this with?

I’ve made changes to adapt to frame rate changes on the Vero 4K. This is necessary or you can have problems with Live TV.

If you don’t use passthrough, then a workaround could be to use Sync Playback to Display.

The only OSMC device I have in production is a Vero 4K, though I have an OSMC Pi I can dig out for testing. The Vero is configured for passthrough audio and preserving framerate of the source. I have never look at the DS9 files before today.

As mentioned, MMAL playback on a LibreELEC Pi has the same problems. OMX playback does not, and just sticks with 29.97, but then I find that OMX is not very good at adapting when content changes (e.g. I have recordings of BBC HD broadcasts where OMX does not switch into deinterlacing for studio scenes because the recording starts with a “filmised” ident which does not need deinterlacing, and OMX doesn’t bother to switch thereafter - this happens with OMX under OSMC as well I think). Hence I disable OMX on my Pi’s so that they get deinterlacing right on live TV material, though when OMX does get it right, it does a good job.

I would prefer to keep audio set to passthrough on the Vero if possible, but if I just need a workaround for one show out of my entire collection, not a big deal.

I believe OpenMAX requires playback details to be set upon initialisation and it cannot adapt. It is a ‘dumb’ player but as such performs better in lower resource situations; as more is offloaded to RIL components.

Send me a PM. I’d like to analyse a sample. But if the framerate does indeed change in the clip, then it sounds like Vero 4K is responding correctly. I’ll certainly see what can be done

Thanks Sam, PM was sent, appreciate the great support for OSMC.

Cheers – I’ll look in to this shortly.

A follow up observation that I just chanced upon: after the framerate switches from 29.97 to 30 via continuous playback from the start, playback is stuck at 30 if I do not intervene. But if I stop and resume playback, framerate switches back to the correct speed of 29.97. I’ve also been able to induce a 29.97-to-30 switch under reverse scrubbing, where otherwise a switch had not occurred. Does this suggest a bug, or perhaps poor authoring of the source?

Hi

Thanks for your patience – been a busy a couple of days.
From (admittedly quick) testing, it seems that Vero 4K is correctly adapting to the source and that’s why you see the black screen.

I did disable framerate switching temporarily to assess if this was feasible, but soon you get discontinuities. This may not be visible in most situations, but still doesn’t seem like the right approach. I’ll see if it can be refined; but for now remuxing the video may help your situation.

I’ve had similar issues as the OP describes and from my experience this is a Kodi issue. I’ve encountered it on other builds of Kodi, as well as SPMC on NVIDIA Shield, but only with a handful of NTSC DVD rips and Live TV recordings. I’ve managed to overcome the issue by adding an advancedsettings.xml file with the following content:

<advancedsettings>
<video>
<adjustrefreshrate>
    <override>
      <fps>23.976</fps>       <!-- if the fps is between 23.966 and 23.986 -->
      <refresh>23.976</refresh> <!-- 24p -->
    </override>
    <fallback>
      <refresh>60.0</refresh> <!-- everything else 60hz -->
    </fallback>
</adjustrefreshrate>
</video>
</advancedsettings>

Doing this will cause OSMC to ignore the mid video change you mention and keep to your default refresh rate (unless it’s 24hz content). I’ve found that this fix completely solved the problem for me. I hope it works for you.

It will work but will cause discontinuities.
If these clips don’t use passthrough you will probably get away with it.

If you later encounter playback issues however, this is the first thing I would suggest to revert

Sam

Thanks for looking into this. I also looked at a R1-sourced West Wing episode and that too had a framerate glitch, playback started at 29.97 and then the screen blanked and came back at 60 according to the playback stats. Motion was quite juddery. But whereas my LE Pi had the same issue with the DS9 episode, it was fine with the West Wing episode that glitched the Vero’s framerate. I’ve not had chance yet to try this on an OSMC Pi.

So in summary Kodi does not play nice with NTSC DVDs? Most of my NTSC DVDs that have not been replaced by blu rays have been detelecined to 24p via Handbrake, but that’s not possible with DS9. My old Panasonic blu ray player is fine with the mkv files that trip Kodi, though it’s less user-friendly, so I guess I’ll use that for this part of my collection unless some day there is a fix for Kodi.

I’ll see if I can dig in to this more. You shouldn’t see frequent refresh rate changes (if ever) with most files.

PTS is probably no good, so we use a fallback framerate to start until it’s worked out later. Is this an AVI file?

Sam

I have sent you a PM. What is PTS ?

Presentation Time Stamp

The issue is really that Kodi is trying to de-interlace and remove pulldown. If the source isn’t really 100% film that has had pulldown applied to make it 30fps NTSC, then you get the framerate changes, as sometimes it’s 24p NTSC with pulldown added, and sometimes it’s straight 30fps NTSC.

The solution is to disable pulldown removal, but keep de-interlacing enabled. This will keep the framerate fixed at 30fps NTSC. I don’t know how to do this with Kodi, but it’s the only way to really solve the issue.

Thanks to everyone who chipped in to this discussion. Per PM exchanges with Sam, I have just tried Kodi 18, and the playback glitches I’ve seen so far with NTSC are resolved. Only limited testing so far, will look into this some more over the weekend.

In the meantime, a simple fix I found from another thread that at least works for West Wing is to set MPEG2 acceleration to HD and up. Still have issues with DS9 though.

This whole discussion has reminded me of something I noticed when I first started trying Kodi: I can’t see a function for Kodi to output NTSC as 24p. I have several old blu ray players that all do that just fine (an occasional disc might cause that to stumble but it generally works). It would be a nice feature to have.

I have the same issue with mentioned DS9 encodes. First I had encodes with x264 10 bit, which resulted in lip sync issues because that encode has to be software decoded. Then I probably got the same encodes as you, which are proberly hardware decoded by the Vero 4k but go to a brief blank screen after 5-10 seconds, which is also a quite annoying. A third encode I got finally has no issues (x264 at 23.976fps) but has the least quality. I guess I need to use my DVDs in this case… which is also annoying because I hate physical media lol :smiley:

This issue was fixed some time ago. If you have the DVDs you need to use MakeMKV and create your own rips instead of resorting to “other unmentionable” sources.

It’s fixed in Kodi 18, but not in OSMC 2018.06-1 which I’m currently running on my Vero 4K. My files are direct from original DVDs via makemkv, no other processing. Just went back to series 1 Ep 1, and around 40 seconds in, screen blanks as a framerate change is triggered for no obvious reason.