Youtube + MPEG-DASH stutters with low-complexity video @ 60fps

Help and Support
1

I’m honestly not certain whether this is an issue with OSMC or with Inputstream Adaptive, but I only seem to be having this problem with my RPi3 running OSMC and not with either my Macbook or my desktop Windows machine, so I figured I’d bring it up here and see if there might be any solutions.

The basics: When I’m watching a 60fps Youtube video with MPEG DASH enabled, when the video is in relatively low-complexity spots where not much on the screen is being updated, the frame rate on the video drops to about 2fps. I have done everything I can think of to see why this is the case, and here’s what I’ve figured out:

  1. This happens no matter what the resolution chosen, so if I choose to lower the resolution (and thus the bandwidth), it still stutters.
  2. If I flip the option for “Force 30fps,” the issue goes away.
  3. If I disable MPEG DASH, the issue goes away.

Frankly, I’m assuming the issue has something to do with 60fps videos and Inputstream Adaptive, since the problem goes away if I’m not using it or if I’m watching a 30fps video. I’m also assuming that bandwidth is not relevant either, since it keeps up just fine when the screen is higher complexity and thus more bandwidth is required. If it were a bandwidth issue, the stutter would happen at moments of high complexity, not low.

If I pause the video, the stuttering stops and the video actually continues for several frames after I’ve hit the pause button, until it has caught up to where it’s supposed to be. At the moment I unpause the video, it resumes playing smoothly for a second or two, but then begins stuttering again (I assume once the buffer has played itself out).

Log files: http://paste.osmc.tv/emanekajit

The example video I used was this Kurzgesagt video. The stuttering happens at about 20 seconds in and happens for several seconds. I played the video from the beginning to about the 25-26 second mark and then stopped it.

It also happens in this video, at the 3:50 mark when the screen goes blank. The emblem in the lower-right corner is supposed to smoothly flip on its vertical axis, but it stutters. Once the fade-out ends and action begins on the screen, it is very low-framerate for a second or two and then catches up with itself.

I’m honestly at a complete loss here. I don’t want to limit myself to 720p videos, nor to 30fps versions of 60fps videos, if I don’t have to. I’m not sure who else to go to, so if anybody has ANY ideas, I’m open to hearing them.

Thank you!

2

Try enabling OMX player (settings>player>videos>allow hardware acceleration - OMXPlayer). Note that this setting may cause issues with playing some videos elsewhere. I can actually play those without issue just with MMAL enabled as long as I don’t have the OSD showing (where they then perform as you described). You could also disable hardware offloading which would also get rid of the issue but I don’t think your CPU could keep up at 1080P as my 3 b+ was almost maxed out when I tested it.

3

I was so excited because I knew I’d had OMX player disabled—the Netflix addon required that you use MMAL only—and when I tried re-enabling OMX, Netflix still worked, so it looks like they’ve got that bit fixed, at least. But then when I went to play that same Kurzgesagt video, the same thing happened with OMX enabled. :frowning: So it looks like that’s not a fix, unfortunately. Thanks for the attempt, though.

4

60fps YT videos are normally, at least if at 1080p or higher resolution, only available encoded with VP9. This can’t be hardware decoded by RPi. Stutter would be a logical consequence - no matter which player you choose.

5

Your assertion would make sense IF it weren’t for the fact that it plays busier aspects of the videos with no problem whatsoever. It ONLY stutters when there’s very LITTLE decoding to do. If what you’re suggesting is actually the case, then exactly the opposite would be true—it would play the low-complexity stuff just fine and then it would choke as the data stream got less compressed.

I should also point out that everything is playing in h.264, still—my processor usage is also low as hell, so I don’t believe that I’m reading VP9. It’s also configured not to use that codec in Inputstream Adaptive, so my guess is that what’s coming directly from Youtube is absolutely the h264 codec.

EDIT: I guess there isn’t an option in Inputstream to decide which codec you want to use, though I could have sworn there used to be. At any rate, what I’m seeing is h.264 and my processor usage is nowhere close to pegged while I’m watching videos, so I’m pretty sure that it’s still going through the hardware decoder instead of on-the-fly decoding VP9 into h.264.

8

Had another go and decided to try it with the Amber skin your using and it looks like that is where the issue is coming from. I bumped up my GPU memory to 320 and that improved things a bit but there was still stutter. Maybe better results with more but you can test that yourself if you’re so inclined. Estuary has a lot less overhead and it works fine there as I said earlier.

Low bit rate does not mean it is less work to decode. Less busy scenes may be more work and/or memory precisely because they allowed for more efficient encoding that happens to be more complex to put back together.

9

Ah, yeah, you do have a point there. Thanks for looking further into it—I’ll see if bumping up my GPU memory helps at all.

Thanks!

10

Welp, yup. Updated gpu_mem to 384 and tried boosting the core_freq to 480—no effect. Switched to Estuary and everything was better. Sigh. I guess it’s all the fault of this skin, which sucks because I VASTLY prefer Amber over anything else.

Thanks, I guess this isn’t a problem with OSMC and is just a hardware limitation, given the overhead necessary for the skin. Guess there’s not much I can do about it.

1 Like