Example of stuttering HEVC playback on Apple TV 4K

Plex Players Streaming Devices
61

Because the streams play normally when packaged differently, or are passed through an alternative setup, I’m inclined to consider them to be to spec. What we’re seeing is an edge case brought about by the combination of:

  • an apparently valid HEVC stream constructed in a particular way
  • packaged in a particular, well-known, standard format
  • passed through a specific decode and playback path

With the first two we could figure out what’s triggering the fault, but we’re flying blind with the third and most critical component. Has there been any movement on this internally @DaveBinM, or are we doing all the work for you?

62

I think I might have found the source of the issue with these files.

I noticed when RARBG first started releasing these files, MKVToolNix (v44) would produce a messed up file after re-muxing, and as mentioned in this thread, version 45 no longer causes an issue, and in fact resolves it for many players.

So I reviewed what they changed in MKVToolNix v45, and saw two noteworthy entries:

  • mkvmerge: H.265/HEVC packetizer: fixed changing the NALU size length, it was using the wrong offset into the hevcC structure.
  • mkvmerge: MP4 reader: if there’s no frame offset table (ctts atom) present for H.265/HEVC video tracks, mkvmerge will determine the timestamp order itself instead of relying on the timestamps in the MP4 being in the presentation order required by Matroska. Fixes #2777.

Promising that the original reporter of the issue is posting based on a new RARBG upload.

If you read through Moritz Bunkus’ Post Here. He explains the technical nature of the problem, apparently the MP4 files are missing a ctts atom (frame offset table), which in itself is not a fatal error, but appear to be relied upon in many cases.

This is why re-muxing the file with MKVToolNix v45 resolves the issue, because it’s throwing out the bogus time-stamp information, and recreates it from scratch.

Other players that are handling these files successfully must be handing the missing ctts atom differently. In the short term, what will make these files work is running them through mkvmerge so it can rebuild the raw h.265 stream with appropriate timestamps.

Also, shout out to Moritz and MKVToolsNix for being awesome, support them if you can :slight_smile:

5 Likes
63

I’ve been downloading all RARBG’s newly encoded x265 files as well and just noticed what looks like the frame drops on my Hisense Roku TV. And like some already, have already done a vast amount of my library. Has anyone contacted support for RARBG to see if they are aware of their issue? Or noticed if it’s been resolved in new releases?

64

I’ve spent far too much of today working on this, but I concur this appears to be the root cause. The problem as described matches with what appears to be happening with playback of frames jumping around in sequence. I’m still working on an automated method to fix these in a batch, but the following commands work for me using mkvtoolnix v45 and ffmpeg 4.2.2 from homebrew in macOS 10.14.6, I’d expect it to work in other POSIX compliant environments at least.

mkvmerge -d 0 -A -S -o <temp.file.mkv> <original.file.mp4>
ffmpeg -i <original.file.mp4> -i <temp.file.mkv> -map 1 -map 0 -map -0:v:0 -map -1:v:1 -map_metadata 0 -c copy -tag:v:0 hvc1 -movflags +faststart -f mp4 <corrected.file.m4v>

Some of the options could be omitted, but this exact sequence works for me (placeholder filenames are <> inclusive, substitute as appropriate).

I’ve attempted to pass info through their forums, but they restrict what can be posted and delete any attempts to troubleshoot. I’m not aware of any other support channel, official or otherwise.

I’ve not found any that work as expected out of the box, but it would be interesting to check releases with a source post 2020-04-04 when v45 dropped.

1 Like
65

I can verify as of now, a file from 2020-04-18 was not fixed. Still has frame issues. I’ll try and reach out to RARBG. If you figure out an automated solution that doesn’t require re-downloading all the source files please keep me posted. As of now, I used XR to go to AC3 so all my files aren’t original anymore.

66

This was the reply I got from RARBG after I describe the mp4 issue we’re having with their encodes. Guess we can expect to use the temp fix until someone notices it’s been addressed in a future release.

Screenshot_20200425-031941_Gmail
Screenshot_20200425-031941_Gmail948×527 63 KB

1 Like
67

This hot mess of a bash script appears to be fixing my collection, burned through around a dozen so far.

#! /bin/bash

MKVMerge="/usr/local/bin/mkvmerge"
FFMPEG="/usr/local/bin/ffmpeg"
SrcDir="/Volumes/Scratch/orig/"
TmpDir="/Volumes/Scratch/temp/"
DstDir="/Volumes/Scratch/fixed/"

MKVMergeOpts="-d 0 -A -S"
FFMPEGOpts="-map 1 -map 0 -map -0:v:0 -map -1:v:1 -map_metadata 0 -c copy -tag:v:0 hvc1 -movflags +faststart -f mp4"

date
for SrcFile in "${SrcDir}"*.m4v ; do
    BaseFile="$(basename ${SrcFile} .m4v)"
    ${MKVMerge} ${MKVMergeOpts} -o ${TmpDir}${BaseFile}.mkv ${SrcFile}
    ${FFMPEG} -i ${SrcFile} -i ${TmpDir}${BaseFile}.mkv ${FFMPEGOpts} ${DstDir}${BaseFile}.m4v
    echo "Clean up…"
    rm -v ${SrcFile} ${TmpDir}${BaseFile}.mkv
    date
done
68

I guess VLC isn’t a supported player either.
(who didn’t see that coming?)

Once these Files go through Xmedia Recode - there’s no fixing them. Period.

That’s why I’m in the process (for days now actually) of re-acquiring 514 broken items - so I can fix them with a first pass through MKVTN V45.0 - after that it’s smooth sailing.

If all I had to do was remux files - I’d be done already.
As it stands - I’m not nearly done - let’s call it halfway (even if we have to lie about it…lol)

69

The notion of a supported player is asinine in this context. Their production path is generating an incomplete and broken product. That said, VLC does play these streams fine unmodified.

I still expect Plex to fix their client to gracefully handle HEVC streams missing their ctts atom, if only to match the functionality Infuse and other clients.

This sounds like Xmedia Recode is adding an incorrect ctts atom to the stream. I’d look into how to strip it so mkvmerge can construct it from scratch.

I’d also like to know how to identify a stream missing its ctts atom.

1 Like
70

Not at my house.
Wait…
Upgraded to VLC 3.0.8 and they do play without the jerks.
Now I wish I hadn’t upgraded - 'cause 2.something told me when they were fixed. Now I have to work on faith until I get 'em in to Plex again… oh well… par for the course. <—now I won’t be able to see if ‘the bgs’ ever fix 'em - I trust someone will let me know when I don’t have to mux-fix any longer…lol

I may have to eventually try to hammer out a way to get the video stream fixed - by any means - 'cause as seeders dry up like spit on the Sahara, I can estimate about 10-15% of these things I’ll never get again now.

71

Since the root cause have been found, I wish Plex would incorporate this fix.

72

Now that we know the files are broken - I wonder what Plex can really do about it… other than perhaps have Plex play the broken files.

Unfortunately that won’t fix the files. <— I cry a little here, 'cause I have 336 of them to fix already waiting - and another 200 or so in download - so I can fix them - 'cause playing around with files I can’t fix waiting to see if Plex will ever play them - isn’t exactly on my list of favorite things to do.

I kinda know how that movie ends.

73

The problem has already been identified, with a fix developed, tested and deployed for Infuse, plus there are many other HEVC decoders which already handled this gracefully. It can easily be handled by repackaging the mp4 on the fly, they already appear to do it for a number of other scenarios.

74

We have multiple Plex clients at home and unfortunately 90% of them are Apple and all devices have stuttering issues. Right now I’m just running all the RARBG x265 through MKVToolnix just to be able to play them properly.

Although I have a couple of Coreelec Kodi boxes which plays them without stutter.

75

I just tested the Apple TV 2.17 (15246) client with an unmodified file, and the HEVC stream plays normally when “Use Old Video Player” is disabled in settings.

From the release notes:

  • The Enhanced Video Player is now available to all users and enabled by default. It can be disabled at any time from the app Advanced Settings.
  • Fixed stuttering when playing videos with the Enhanced Video Player on Apple TV 4th gen.

I consider this to be resolved, at least on tvOS.

1 Like
76

If processing the files through this tool renders them unusable or unrecoverable, it’s a problem with the tool. I’d raise it as an issue with the developer directly.

77

Also tried the IOS versions and its also fixed :slight_smile: Good job!

78

As you can see, you weren’t doing all the work. I was busy testing the fix for the developers, before it was shipped. There are almost 200 different threads on here I’m involved with, so please be patient if it takes a while for me to cycle back through them all :plexheart:

1 Like
79

I appreciate you’re busy, but the last official update we had was two weeks old and that it was still under investigation. No clarification that it had been replicated or a potential fix was being developed and tested.

Could you please confirm the root cause was the missing ctts atom associated with the HEVC stream?

80

I’d need to ask the engineer about that one. I’m not part of our engineering team.