Server Version#: 1.32.6.7468
Player Version#:9.31.0.3817 (fb6a731)
When playing standard DVD content (ripped to MKV container) on my Sheild Pro, it seems to struggle maintaining the proper frame rate. Scenes sort of “stutter” from time to time. Note, this does not happen with HD or UHD content. Only DVD (MPEG2). I’ve tried every setting I can on the Shield but cannot seem to fix the issue. Everything is Direct Play.
Ok. I’m also seeing this on recorded content using my HDHomeRun tuner - which coincidentally is also MPEG2 content. Any ideas?
I’m also experiencing this. I’ve tried adjusting every setting I can think of but it persists. I wonder if it has something to do with interlaced content?
Thanks for confirming this. I know a lot of people using Plex transcode their content. so they may not be seeing this. I prefer to keep all my content native. But this issue is so annoying that I am considering transcoding my DVD content (since it’s not the highest quality anyway…) to h265 just to avoid this annoying issue…
I am considering the same solution. But like you, I prefer to deal in remuxes only so haven’t done that yet. It wasn’t always this way, but has been for some time now. I used to notice combing artifacts from time to time with DVD content and I think it’s about the same time those went away that this started which is why I suspect something to do with interlacing. DVDs are a pain since they often mix interlaced and progressive frames. I’m not surprised playback is challenging.
There is an issue w/ the MPEG2 decoder on the NVidia shields both Pro and Tube.(The decoder in WMC7 works much better) I notice it when I am watching live TV directly from my HDHR tuners. There are a few networks/content producers that seem to be using a very poor MPEG2 encoder that doesn’t handle the interlacing and 3:2 telecining properly. I notice it quite a bit on commercials and on Discovery & AMC networks as well as some OTA channels with both SD & HD content, but it is always the interlaced video.(720p works perfectly) I have tried Plex for live TV and noticed a reduction in the stuttering, tearing and ripping when Plex was set to transcode everything. I don’t use Plex for Live TV due to DRM on some of my cable channels that my Shields can handle fine. Some (but very few) of my SD DVD rips had this issue. As someone mentioned above, I ran them through handbrake and that cleared up the issue. I don’t know if NVidia is going to correct the issue. I mentioned on their forums that a background process that monitored the video stream for interlaced content, and when detected would engage a software decoder just to deinterlace the video stream could probably work. An NVidia moderator said the shields don’t have enough processing power to do that. Maybe there will be an updated version of the Shields coming out that can handle the poor MPEG2 encoding but right now it doesn’t look like that is happening.
Here’s the thing though - it used to work fine. So something has changed. I’m to the point that I am probably going to transcode all my SD content to h265. I like to avoid transcoding, but at least it’s SD content so I’m not that concerned about loss of quality, etc. I tried streaming a few BD’s that are MPEG2-encoded and didn’t see any issue.
If you do transcode all of your SD content the deinterlacing and proper frame rate would be the most important part of the conversion.
Something else interesting that I noticed - it’s not 100% reproducible with the same sections of video. For example, if I see the low framerate issue and then rewind 10 seconds, it won’t necessarily keep occuring. So, it seems the decoder must enter a bad state due to some series of inputs and does not recover as it should. But, rewinding a bit and restarting must clear whatever state is bad… it’s interesting. I don’t want to promise anything but time permitting I will try some test encodes to see if I can nail down a specific repro.
Agreed. It’s not consistent.
Having this issue too. Plex please fix this.
Did a bit of testing. Using the repeat first field (RFF) flag seems to cause the problem. I wasn’t able to reproduce it any other way so far. Unfortunately it continues to be a flaky repro. Sometimes the test clip will have a low framerate from the start, sometimes the low frame-rate problem starts in the middle, and other times it won’t happen at all. But I watched the same clip encoded in different ways many times over and only the one using the RFF flag ever showed the problem. I also played the same clips using VLC on the Shield which has the option to turn on and off hardware decoding. I was unable to reproduce the same issue there regardless of config.
The RFF flag probably requires some explanation to understand. This explanation comes with the disclaimer that encoding video has never been my job and my knowledge has been acquired via hobby (e.g. I’m doing my best. But welcome anyone more knowledgeable to correct any mistakes).
NTSC DVDs are required to produce a 30fps (29.97fps technically) interlaced output (30i). But compressing video frames as interlaced fields is less efficient than compressing progressive frames. Additionally, a lot of content is 24fps and a process known as “telecine” is used to up-convert it to 30i by repeating image data. A specific form of this process is 3:2 pulldown. It would again be an inefficiency to store this repeated data on the disc. So instead, the mpeg2 standard offers the RFF flag which allows the video bitstream to tell the decoder to repeat specific frame information. This way it’s possible to store a 24fps progressive video on the disc without repeating data, but still comply with the DVD standard by instructing the decoder to assemble a 30i output during the decoding process.
I’m also experiencing the problem with content recorded over the air, which appears to be recorded at 29.97fps. Any idea for a workaround?
Nothing comes to mind as a workaround yet, other than transcoding 
Are you able to share an example file that’s giving you trouble?
Here is one. Recorded over the air: The Irrational (2023) - S01E04 - Zero Sum.ts
This file is using the RFF flag too. Using mediainfo you can see it (**'s inserted by me to highlight the relevant fields).
General
ID : 1 (0x1)
Complete name : The Irrational (2023) - S01E04 - Zero Sum.ts
Format : MPEG-TS
File size : 1.65 GiB
Duration : 42 min 12 s
Overall bit rate mode : Variable
Overall bit rate : 5 591 kb/s
Movie name : The Voice
Law rating : TV-14 (LV)
Video
ID : 256 (0x100)
Menu ID : 1 (0x1)
Format : MPEG Video
Format version : Version 2
Format profile : Main@High
Format settings : CustomMatrix / BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : Variable
Codec ID : 2
Duration : 42 min 12 s
Bit rate mode : Variable
Bit rate : 4 733 kb/s
Maximum bit rate : 15.6 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Active Format Description : Full frame 16:9 image
**Frame rate : 23.976 (24000/1001) FPS**
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
**Scan type : Progressive**
**Scan order : 2:3 Pulldown**
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.095
Time code of first frame : 22:27:23;26
Time code source : Group of pictures header
GOP, Open/Closed : Open
Stream size : 1.40 GiB (85%)
I did just try removing the RFF flags (in /theory/ there should be a 24fps progressive stream in the file that you can view without the pulldown) but it seems to have messed up the key frames which isn’t going to be acceptable. I’ll keep playing.
This post was started in September. Hoping someone from Plex will acknowledge this issue. It’s very annoying having to drop quality so the file transcodes to watch without stuttering at random spots during playback.
This is not an issue with Plex. It is an issue with how the file was encoded and the decoder that is on the Shield. Having Plex transcode from interlaced to progressive during recording may solve the issue.
I disagree. This issue occurs with NATIVE ripped DVD’s and over the air recorded content. Does Plex expect us to transcode every over-the-air recorded item? The Shield is supposedly the “flagship” client for Plex - certainly Plex can work with them to resolve this issue.
