HEVC Main 10 1080p Stuttering on Roku Ultra

Moving the conversation over here so we don’t bog down the MPEG2 thread! I didn’t see any dropped frames on the first file I checked. My Roku Ultra Plex Preview version is 6.4.14.6276-d1658ba87 (Slightly older than the one @JuiceWSA lists at the top for some reason, possibly because I’ve left the app open and idle for weeks).

No artificial smoothing is enabled on the TV. I do not have “auto adjust frame rate” enabled on the Roku for unrelated reasons. Pans seem smooth at the usual film frame rate, no obvious signs of dropped frames. But I haven’t watched the whole movie yet. I’ll try a few more files when I have more time on my hands.

I’m testing with A Few Good Men. It was originally an MPEG2 Blu-Ray that I’ve encoded to 10-bit HEVC with AC3 and PGS passthrough via Handbrake. Here are the details on the file via Plex’s info for comparison:

Media
Duration 2:18:01
Bitrate 3040 kbps
Width 1920
Height 816
Aspect Ratio 2.35
Video Resolution 1080p
Container MKV
Video Frame Rate 24p
Video Profile main 10
Part
Duration 2:18:01
File A Few Good Men (1993).mkv
Size 2.93 GB
Container MKV
Video Profile main 10
Codec HEVC
Bitrate 2325 kbps
Bit Depth 10
Chroma Subsampling 4:2:0
Color Primaries bt709
Color Range tv
Color Space bt709
Color Trc bt709
Frame Rate 23.976 fps
Height 816
Level 4.0
Profile main 10
Ref Frames 1
Width 1920
Display Title 1080p (HEVC Main 10)
Codec AC3
Channels 6
Bitrate 640 kbps
Language English
Audio Channel Layout 5.1(side)
Sampling Rate 48000 Hz
Title Surround
Display Title English (AC3 5.1)
Codec PGS
Bitrate 75 kbps
Language English
Display Title English (PGS)
1 Like

@Cafe_Diem ~ want to try this sample? It’s not always easy to see. It could also be something specific to the encode, maybe even the fact the height of the sample is much closer to 1080 vertical lines compared 816 in yours.

1080p_HEVC_MAIN10_stutter.mp4.zip (5.1 MB)

I can confirm this is not a Plex app related issue. This sample above replicates from within Roku’s media player. We do have an open issue with Roku for them to investigate.

1 Like

Thank you, I’d love to! I’ll download and test it later today if I can. I couldn’t rule out that the motion in my video was subtle enough that it just wasn’t very noticeable in the sample I watched.

2 Likes

I most definitely see the dropped frames in the sample file on a Roku Ultra. I’ll see if I can reproduce with any HEVC 10-bit files encoded in my collection (I’ll look for faster pans).

2 Likes

There is pretty much the same discussion going on multiple threads and multiple devices about HEVC 10 files having jittery playback. For instance this Apple TV thread Example of stuttering HEVC playback on Apple TV 4K.

Yep - a whole lot of the same songs in this playlist…
Seems a whole lot of people just found out what HEVC Main 10 is…
…after having previously said they could handle it - in error - apparently…

I don’t have that movie, but I took the clip provided and intentionally transcoded it again to 10-bit HEVC using my method, mainly just for fun, to see if it still dropped frames. It did not. Sample provided.

2.0 1080P Hevc Main10 Stutter m4v hevc10.m4v.zip (6.5 MB)

(I added the 2.0 in front just to make it easy to find in the video folder)

I did only a quick browse to compare the video properties. The difference that stood out at first glance: My encode is using a color space of bt709. It doesn’t look like the original video provides a color space field.

There are some other differences.
I’ll defer to a higher source - like the guy involved in the repair…lol

(I’m readying the launch pad for your test file - more later)

Yep, the color space was simply the difference that stood out first. I would fool with it further and try some process of elimination, but my time is limited today.

But it does explain why my other 10-bit HEVC files are not displaying these symptoms on the Roku.

At the minimum, if it’s not a problem endemic to the codec overall, we could at least research and perhaps learn the specifics of what’s causing this during encoding.

Not on Roku, But have tested the sample file on Xbox One X with Official Plex app, I see the stuttering/jumpy playback in the sample file. I also tried the Plex for Kodi addon on Xbox One X, & the sample file plays perfectly fine.

I know Infuse was having trouble playing these files too on IOS, & Has identified the issue with these 1080p HEVC 10-bit files, Should be getting the fix soon, If not already.

I know you say this is not a Plex app issue, But considering many Plex player apps on different devices all have the same issue (Some apps other than Plex on the same devices play the files just fine), This has to be a Plex player app issue.

1 Like

This thread is specific to the Roku, so when I was saying it’s not a Plex app issue, I was referring specifically to the Plex channel on the Roku. There is literally nothing we can do when the Roku direct plays, as the Roku firmware handles this. The player stack is not something developers can modify on this platform. This is why RMP (Roku Media Player) exhibits the same issue, completely outside of Plex. We could potentially force a transcode of this media, if we find the key reason these specific encodes stutter. That however is not an optimal solution. I’m hopeful Roku will identify and fix this issue in their firmware.

3 Likes

I’m getting a feeling that:

  1. 10 months ago Roku Ultras could play HEVC Main 10
    or
  2. 10 months ago HEVC Main 10 files were different than the 200+/- I’ve acquired recently (indicating this ‘issue’ isn’t ‘going to go away’) - 'cause none of 'em will play stutter free at this time.

These were encoded with FFMPEG, right? Do you have the original encoding parameters? This problem definitely isn’t reproducible with my personal HVC1 encodes on Handbrake and I’d love to compare the specifics. Do you have the parameters, @ljunkie?

If everyone’s HVC1 files were failing like this, this forum would be melting under the stress of the number of posts. It’s a really popular codec. So it’s very clearly a problem, but it’s not a ubiquitous problem with all encodes. It would probably help to know the encoding parameters to see if the exact cause can be narrowed down.

I quoted the MediaInfo above for the ‘original’ file that caused all the rukus around the house - and now I have about 200 of them - with no signs of slowing down - or getting a ‘Re-Pack’ (which ALWAYS happens if something is horribly wrong).

I predict in the very near future if ‘these files’ aren’t a problem - they will be.

:wink:

Oh, here it is again - knew I was forgetting something:

General
Complete name                            : D:\Acquisitions\Signs (2002) [1080p]\Signs (2002) [1080p HEVC].mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom (isom/iso2/mp41)
File size                                : 1.66 GiB
Duration                                 : 1 h 46 min
Overall bit rate                         : 2 231 kb/s
Encoded date                             : UTC 2020-03-26 19:53:38
Tagged date                              : UTC 2020-03-26 19:53:38
Writing application                      : Lavf58.20.100

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L4@Main
Codec ID                                 : hev1
Codec ID/Info                            : High Efficiency Video Coding
Duration                                 : 1 h 46 min
Bit rate                                 : 2 000 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 036 pixels
Display aspect ratio                     : 1.85:1
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits
Bits/(Pixel*Frame)                       : 0.042
Stream size                              : 1.49 GiB (90%)
Writing library                          : x265 3.3+4-rarbg-30eb4de83092:[Linux][GCC 8.3.1][64 bit] 10bit
Encoding settings                        : cpuid=1111039 / frame-threads=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1036 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=4 / selective-sao=0 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=2000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0
Encoded date                             : UTC 2020-03-26 19:53:38
Tagged date                              : UTC 2020-03-26 19:53:38
Codec configuration box                  : hvcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Codec ID                                 : mp4a-40-2
Duration                                 : 1 h 46 min
Bit rate mode                            : Constant
Bit rate                                 : 224 kb/s
Channel(s)                               : 6 channels
Channel layout                           : C L R Ls Rs LFE
Sampling rate                            : 48.0 kHz
Frame rate                               : 46.875 FPS (1024 SPF)
Compression mode                         : Lossy
Stream size                              : 171 MiB (10%)
Language                                 : English
Default                                  : Yes
Alternate group                          : 1
Encoded date                             : UTC 2020-03-26 19:53:38
Tagged date                              : UTC 2020-03-26 19:53:38

… and as always - if you need an original file (remuxed now to MKV, but otherwise intact) - say the word and you’ll have it. I seem to have a population explosion in progress.

I’ve experienced the same issue, with the same encoded files, on an Xbox One and posted about it here:

Indeed! I’m actively watching my HVC1’s to see if I can reproduce this, I have a lot of them and use Roku’s regularly. A mystery like this drives me crazy. The dropped-frames problem is extremely easy to see, too. I’d love to track this down.

Also, I may take you up on that soon. I was using the previous sample from Signs for experimentation but the original source would be useful. Would this just be the full-quality remux of that 30-second clip?

I have something enroute…

What’s really a bummer, is if I want to watch one of these things right now - there is nothing in the Plexiverse that can play them - at my house anyway. PMP has ‘the jerks’ along with everything else so let’s transcode one… but wait.

The first transcoding option for my Roku is 720 @ 2Mbps.

The first transcoding option for the FireTV is ‘Convert Automatically’ and that creates a 1080p 10Mbps transcoded AVC version - which looks a ■■■■■-ton better than 720 @ 2Mbps. An Imperial ■■■■■-Ton, no less.

In the Plex Client try disabling allow direct play under video settings, this forces plex server to transcode both the video and audio into h264 and AC3, on both of my roku tv’s (5 series and 6 series) it fixed the stuttering (running Plex on synology DS718+)

1 Like

Ah… right… forgot about that one… hard to say what you might learn by reading other people’s mail…lol

if the Roku will transcode a nice, fat version - that’ll do for now…