1080 HEVC SDR files choppy on Roku Ultra 2021

viriiguy commented 3 years ago

Describe the bug

When trying to play a 1080 HEVC SDP video file, on a Roku Ultra 2021, the video frame rate is choppy and unwatchable. Watching the exact same file, on a Roku Ultra 2020, on the same network, results in perfect playback. I even went and purchased another, new ultra 2021. Same issue.

JellyFin is hosted on a Windows 10 box and is up to date. All other media, including 4k plays perfectly. But all 1080 HEVC SDR files do this same thing.

To Reproduce

Run a 1080 HEVC SDR video file on the current 1.4 Build 8 of Jellyfin Roku, on a Roku ultra 2021

Expected behavior

Video should run smoothly. It will not. It will be choppy.

Logs

I have been unable to get Jellyfin to spit out any logs, but when I check the status, the video is direct playing, no transcoding.

Screenshots

Additional context

entropicdrifter commented 3 years ago

Have you tried putting the video on an SD card or flash drive and playing it directly on the Roku Ultra 2021? If it's still choppy in that case, it's probably a Roku-specific issue like a driver.

Willsr71 commented 3 years ago

I'm having this same issue on a Roku Express 4K 3941X. Jellyfin is hosted on unraid in docker. Here's an extract of direct play logs from two files that have this issue: https://hastebin.com/ifubamawuq.csharp

Artiume commented 3 years ago

I'm having this same issue on a Roku Express 4K 3941X. Jellyfin is hosted on unraid in docker. Here's an extract of direct play logs from two files that have this issue: https://hastebin.com/ifubamawuq.csharp

@Willsr71 you arent direct playing if ffmpeg is involved. In fact, by your logs, you're transcoding down from hevc to x264.

rikonor commented 3 years ago

Having the same issue. Any idea why transcoding is happening? I even have video transcoding disabled in the User settings. Is there a way to instruct the Jellyfin Roku app to direct play?

Artiume commented 3 years ago

You have to disable audio transcoding and remuxing as well. Clients can't yet force direct play

rikonor commented 3 years ago

@Artiume, I tested on a Roku Streaming Stick+ and the issue seemed to not have presented itself. Are you saying that it's likely a Roku issue and not a Jellyfin issue? I tried looking at the code (VideoPlayer.brs#L244) and I'm trying to understand if this fixable on your end or whether it's an issue with the Roku itself, any ideas or guidance?

Artiume commented 3 years ago

Direct Play is only forcible via the Jellyfin server, I was instructing you on how to force Direct Play. I can't say for sure but so far it does seem to be a Roku issue of some sort.

rikonor commented 3 years ago

I have a Roku Ultra - is there anything I can do to help pin down the root cause of this issue?

neilsb commented 3 years ago

The first thing would probably be to install the beta version if you haven't already, or if you have check it's up to date (new build pushed last night) and check if the issue is still happening. This beta version should be better not forcing transcoding when it's not required.

rikonor commented 3 years ago

Issue still manifests with the Beta build (Roku Jellyfin v1.4.9), even though I disabled any transcoding support for the given user. See Jellyfin logs attached as well.

[14:35:48] [INF] [285] Jellyfin.Api.Controllers.MediaInfoController: GetPostedPlaybackInfo profile: {"Name": null, "Id": null, "Identification": null, "FriendlyName": null, "Manufacturer": null, "ManufacturerUrl": null, "ModelName": null, "ModelDescription": null, "ModelNumber": null, "ModelUrl": null, "SerialNumber": null, "EnableAlbumArtInDidl": false, "EnableSingleAlbumArtLimit": false, "EnableSingleSubtitleLimit": false, "SupportedMediaTypes": "Audio,Photo,Video", "UserId": null, "AlbumArtPn": null, "MaxAlbumArtWidth": 0, "MaxAlbumArtHeight": 0, "MaxIconWidth": null, "MaxIconHeight": null, "MaxStreamingBitrate": 120000000, "MaxStaticBitrate": 100000000, "MusicStreamingTranscodingBitrate": 192000, "MaxStaticMusicBitrate": null, "SonyAggregationFlags": null, "ProtocolInfo": null, "TimelineOffsetSeconds": 0, "RequiresPlainVideoItems": false, "RequiresPlainFolders": false, "EnableMSMediaReceiverRegistrar": false, "IgnoreTranscodeByteRangeRequests": false, "XmlRootAttributes": [], "DirectPlayProfiles": [{"Container": "mp4,m4v,mov", "AudioCodec": "mp3,pcm,lpcm,wav,ac3,alac,aac", "VideoCodec": "h264,h265", "Type": "Video", "$type": "DirectPlayProfile"}, {"Container": "mkv,webm", "AudioCodec": "mp3,pcm,lpcm,wav,ac3,flac,alac,aac,opus,dts,vorbis,eac3", "VideoCodec": "h264,vp8,h265,vp9", "Type": "Video", "$type": "DirectPlayProfile"}, {"Container": "mp3,pcm,lpcm,wav,ac3,wma,flac,alac,aac,dts,wmapro", "AudioCodec": null, "VideoCodec": null, "Type": "Audio", "$type": "DirectPlayProfile"}], "TranscodingProfiles": [{"Container": "aac", "Type": "Audio", "VideoCodec": null, "AudioCodec": "aac", "Protocol": "http", "EstimateContentLength": false, "EnableMpegtsM2TsMode": false, "TranscodeSeekInfo": "Auto", "CopyTimestamps": false, "Context": "Streaming", "EnableSubtitlesInManifest": false, "MaxAudioChannels": " 6", "MinSegments": 0, "SegmentLength": 0, "BreakOnNonKeyFrames": false, "$type": "TranscodingProfile"}, {"Container": "mp3", "Type": "Audio", "VideoCodec": null, "AudioCodec": "mp3", "Protocol": "http", "EstimateContentLength": false, "EnableMpegtsM2TsMode": false, "TranscodeSeekInfo": "Auto", "CopyTimestamps": false, "Context": "Streaming", "EnableSubtitlesInManifest": false, "MaxAudioChannels": "2", "MinSegments": 0, "SegmentLength": 0, "BreakOnNonKeyFrames": false, "$type": "TranscodingProfile"}, {"Container": "mp3", "Type": "Audio", "VideoCodec": null, "AudioCodec": "mp3", "Protocol": "http", "EstimateContentLength": false, "EnableMpegtsM2TsMode": false, "TranscodeSeekInfo": "Auto", "CopyTimestamps": false, "Context": "Static", "EnableSubtitlesInManifest": false, "MaxAudioChannels": "2", "MinSegments": 0, "SegmentLength": 0, "BreakOnNonKeyFrames": false, "$type": "TranscodingProfile"}, {"Container": "aac", "Type": "Audio", "VideoCodec": null, "AudioCodec": "aac", "Protocol": "http", "EstimateContentLength": false, "EnableMpegtsM2TsMode": false, "TranscodeSeekInfo": "Auto", "CopyTimestamps": false, "Context": "Static", "EnableSubtitlesInManifest": false, "MaxAudioChannels": " 6", "MinSegments": 0, "SegmentLength": 0, "BreakOnNonKeyFrames": false, "$type": "TranscodingProfile"}, {"Container": "ts", "Type": "Video", "VideoCodec": "h264", "AudioCodec": "aac", "Protocol": "hls", "EstimateContentLength": false, "EnableMpegtsM2TsMode": false, "TranscodeSeekInfo": "Auto", "CopyTimestamps": false, "Context": "Streaming", "EnableSubtitlesInManifest": false, "MaxAudioChannels": " 6", "MinSegments": 1, "SegmentLength": 0, "BreakOnNonKeyFrames": true, "$type": "TranscodingProfile"}, {"Container": "mp4", "Type": "Video", "VideoCodec": "h264", "AudioCodec": "aac,opus,flac,vorbis", "Protocol": "http", "EstimateContentLength": false, "EnableMpegtsM2TsMode": false, "TranscodeSeekInfo": "Auto", "CopyTimestamps": false, "Context": "Static", "EnableSubtitlesInManifest": false, "MaxAudioChannels": null, "MinSegments": 0, "SegmentLength": 0, "BreakOnNonKeyFrames": false, "$type": "TranscodingProfile"}], "ContainerProfiles": [], "CodecProfiles": [{"Type": "VideoAudio", "Conditions": [{"Condition": "Equals", "Property": "IsSecondaryAudio", "Value": "false", "IsRequired": false, "$type": "ProfileCondition"}], "ApplyConditions": [], "Codec": "aac", "Container": null, "$type": "CodecProfile"}, {"Type": "Video", "Conditions": [{"Condition": "EqualsAny", "Property": "VideoProfile", "Value": "high|main|baseline|constrained baseline", "IsRequired": false, "$type": "ProfileCondition"}, {"Condition": "LessThanEqual", "Property": "VideoLevel", "Value": "51", "IsRequired": false, "$type": "ProfileCondition"}], "ApplyConditions": [], "Codec": "h264", "Container": null, "$type": "CodecProfile"}], "ResponseProfiles": [], "SubtitleProfiles": [{"Format": "vtt", "Method": "External", "DidlMode": null, "Language": null, "Container": null, "$type": "SubtitleProfile"}, {"Format": "srt", "Method": "External", "DidlMode": null, "Language": null, "Container": null, "$type": "SubtitleProfile"}, {"Format": "ttml", "Method": "External", "DidlMode": null, "Language": null, "Container": null, "$type": "SubtitleProfile"}], "$type": "DeviceProfile"}
[14:35:48] [INF] [285] Jellyfin.Api.Helpers.MediaInfoHelper: User policy for dany. EnablePlaybackRemuxing: False EnableVideoPlaybackTranscoding: False EnableAudioPlaybackTranscoding: False
[14:35:48] [INF] [285] Jellyfin.Api.Helpers.MediaInfoHelper: Profile: Unknown Profile, Path: /path/to/file.mp4, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
[14:35:48] [INF] [285] Jellyfin.Api.Helpers.MediaInfoHelper: Profile: Unknown Profile, Path: /path/to/file.mp4, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
[14:35:48] [INF] [285] Jellyfin.Api.Helpers.MediaInfoHelper: Profile: Unknown Profile, Path: /path/to/file.mp4, isEligibleForDirectPlay: True, isEligibleForDirectStream: True
[14:35:48] [INF] [302] Jellyfin.Plugin.KodiSyncQueue.EntryPoints.UserSyncNotification: Starting User Changes Sync...
[14:35:48] [INF] [302] Jellyfin.Plugin.KodiSyncQueue.EntryPoints.UserSyncNotification: "USERSYNC" User e255e7764ea14255b3036bf782d1e738(dany) posted 2 Updates: da073ffe853d44843003cffefa8bf7a2,996642f857847609f7b52bbc490b27cd
[14:35:48] [INF] [302] Jellyfin.Plugin.KodiSyncQueue.EntryPoints.UserSyncNotification: User Changes Sync Finished Taking 00:00:00.0323732
[14:35:58] [INF] [301] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app Jellyfin Roku 1.4.9 playing Dumbo. Stopped at 8000 ms
[14:35:58] [INF] [301] Jellyfin.Plugin.KodiSyncQueue.EntryPoints.UserSyncNotification: Starting User Changes Sync...
[14:35:58] [INF] [301] Jellyfin.Plugin.KodiSyncQueue.EntryPoints.UserSyncNotification: "USERSYNC" User e255e7764ea14255b3036bf782d1e738(dany) posted 2 Updates: da073ffe853d44843003cffefa8bf7a2,996642f857847609f7b52bbc490b27cd
[14:35:58] [INF] [301] Jellyfin.Plugin.KodiSyncQueue.EntryPoints.UserSyncNotification: User Changes Sync Finished Taking 00:00:00.0166090

Any ideas how to debug further?

Artiume commented 3 years ago

so the audio in that file looks like aac 5.1, that might be part of the issue. we've recently noticed aac 2.0 and 5.1 issues with the new OS update

rikonor commented 3 years ago

Are you guys able to reproduce this issue on your end? I'm happy to run some test files through my Roku here if you have any.

Artiume commented 3 years ago

yes, we can reproduce it. i don't have any files to readily share. for testing in your end, try and see if you can isolate the issue to specific audio types.

sbappudi commented 3 years ago

I think this issue is specific to 10 bit HEVC files. If I re-encode these files to be 8 bit HEVC (Audio stream untouched, AAC 5.1 in both files), I no longer have this stutter issue on my Roku TV. Edit: Perhaps the issue is with AAC and 10 bit HEVC in combination, as I have other 10 bit HEVC that play fine, but the audio stream is Opus

Judman commented 3 years ago

Hey all,

Not running the beta, just 1.4 on a Roku Ultra 2021, but I am experiencing the same stuttering issues with some files as well.

Noticed it first on a movie with this codec info. https://pastebin.com/9my5vNAJ

Then again later with this movie. https://pastebin.com/BHf1P2Pw

However, this movie plays just fine. https://pastebin.com/V1YTd9EK

Here are the logs. https://pastebin.com/mCDc2Ckr

pinovecs commented 3 years ago

One comment I will make on this was I was having an issue similar to this, I won't say its the same, but in my case a 4K (or 1080p) x265 video file was choppy if it was an .mp4 file. If I took the file and recompiled it as an .mkv file it played with no issues. No other changes were made to the device, server, or application.

hkdd commented 2 years ago

I'm experiencing this as well on a Roku Ultra. I'm attaching the output from mediainfo in case it is helpful, let me know if you need anything else.

Also, weirdly, I'm not able to change the audio track. No matter which one I select before playing it plays it in French.

jellyfin_roku_stutter.txt

And just to add, this same file plays w/o issue on an NVIDIA Shield running Jellyfin sitting right next to the Roku Ultra. Also plays normally via Jellyfin via Firefox. So the problem is exclusive to the Roku app. I'm also using the regular app as well as testing with the Jellyfin Beta app on Roku. Same behavior in either version.

Didn't want to reply again but I'm in the same boat as @rikonor below this post. HEVC is a very common format these days.

rikonor commented 2 years ago

To one of the developers, would it be helpful if one of the reporters provided a file that you could use to try and reproduce this? It kinda makes Jellyfin on Roku Ultra useless (at least for me) which is unfortunate.

neilsb commented 2 years ago

To one of the developers, would it be helpful if one of the reporters provided a file that you could use to try and reproduce this? It kinda makes Jellyfin on Roku Ultra useless (at least for me) which is unfortunate.

If you have a video that demonstrates the issue, when it would be useful if you could make it available for testing.

hkdd commented 2 years ago

@neilsb I can provide you with an example, what's the best way to get it to you? I can take a few second clip from an affected file so it won't be too large.

neilsb commented 2 years ago

@rikonor If you are able to provide a file - that would be very useful

@hkdd I think a source file that exhibited this problem would be useful. A video of the stuttering probably wouldn't provide much insight.

You can email me at jf-contact@altmails.com

rikonor commented 2 years ago

@neilsb Just shot you an email with a link to a test file. Thanks for looking into this!

neilsb commented 2 years ago

@rikonor Thanks. Got the file and will try to have a look at it later on today and get back to you.

rikonor commented 2 years ago

Thanks so much, @neilsb!

neilsb commented 2 years ago

@rikonor Do you have an external audio decoder connected to you Roku? In your particular case, the file has a 5.1 AAC Audio track, so unless you have an external decoder the server will try and transcode that to a 2 channel AAC. And currently when the server needs to transcode the audio, it will also cause it to transcode the video as well (There's a PR raised on server to fix this jellyfin/jellyfin#6454)

Another quick test you can do is edit the user (via the web interface) and disable the "Allow video playback that requires transcoding" option and try playing the media. That will force the server to only transcode the audio stream an not touch the video stream. If you let me know if that resolves the stuttering for you then it is likely that the fix for this requires that server PR to be merged and then a server 10.8 release should be the permanent fix.

hkdd commented 2 years ago

I just tested this and disabling "Allow video playback that requires transcoding" for the user did not have any noticeable affect, the video was choppy both ways. Device is a Roku Ultra.

This is an HEVC 4K encoded video, I tried both audio streams the DTS 6 and a DD 5.1, both with and without the "Allow video playback that requires transcoding" option enabled, and the same results in every test.

Here's the logfile:

jellyfin_transcode_log.txt

Also I should mention, while this video file has both English and French audio tracks, no matter which I select, it only plays French. This only happens on the Roku, not via the Web App.

rikonor commented 2 years ago

@rikonor Do you have an external audio decoder connected to you Roku? In your particular case, the file has a 5.1 AAC Audio track, so unless you have an external decoder the server will try and transcode that to a 2 channel AAC. And currently when the server needs to transcode the audio, it will also cause it to transcode the video as well (There's a PR raised on server to fix this jellyfin/jellyfin#6454)

Another quick test you can do is edit the user (via the web interface) and disable the "Allow video playback that requires transcoding" option and try playing the media. That will force the server to only transcode the audio stream an not touch the video stream. If you let me know if that resolves the stuttering for you then it is likely that the fix for this requires that server PR to be merged and then a server 10.8 release should be the permanent fix.

At the time of testing, I did not have an external audio output device connected to the Roku. I've since returned my Ultra in favor of a Streaming Stick+ (I think) since it didn't exhibit this issue, but while I had the Ultra, I did try disabling transcoding, see https://github.com/jellyfin/jellyfin-roku/issues/449#issuecomment-875664022.

hkdd commented 2 years ago

I also just tried this from a Roku Streaming Stick 4K+ (2021 version) and have the same experience, choppy video.

countbuggula commented 2 years ago

I'm experiencing it too on a 2021 Roku Ultra. Strangely, Jellyfin says it's compatible and streaming directly without transcoding. Is there a way to force transcoding? Roku is obviously struggling to play these videos but reporting (incorrectly?) that they're compatible.

dark-swordsman commented 2 years ago

Not sure if it's related, but I notice a slight stutter in a lot of stuff I play via direct play. Roku Ultra 2021. Even a 1080p H264 8 bit file with reasonable settings.

It doesn't happen with all media, but it does happen sometimes. Often every 3-5 seconds, it seems like every other frame will be dropped (effectively 12 FPS) for a period of 1 second. I plan to look at the media closer to see if there's any encoding settings or anything that may be causing it.

BenLand100 commented 2 years ago

I've exhaustively tried different combinations of codecs and pixel formats and find that h265 10bit video is the likely cause of this issue. In my case, h265 10bit video stutters (unwatchable) on a 2021 Roku Ultra because Jellyfin tries to direct play it. Manually re-encoding this to almost anything else resolves the issue, because either the Roku will direct play it, or Jellyfin will transcode to something the Roku can play. (I've disabled encoding to h265.)

However, source material in h265 10bit remains unwatchable on the Roku if it's eligible for direct play. Is there some way for force transcoding h265 (10 bit) media to h264? h265 10bit is a common format these days --- being watchable OOTB is far more important than direct play IMO.

BenLand100 commented 2 years ago

A bit more information I don't quite understand:

It's only h265 10bit content with exactly the res 1920x1080 that has stutter on playback. Files with a vertical crop (res 1920x[less than 1080]) appear to play fine. Perhaps this explains inconsistent reports...

pinovecs commented 2 years ago

Benjamin,

Are your files mp4 or mkv files? I had poor experience with mp4, but if I convert them to mkv they are no longer choppy. I never looked at the resolution, but I know these are h265 10bit files.

On Mon, Apr 25, 2022 at 2:41 PM Benjamin Land @.***> wrote:

A bit more information I don't quite understand:

It's only h265 10bit content with exactly the res 1920x1080 that has stutter on playback. Files with a vertical crop (res 1920x[less than 1080]) appear to play fine. Perhaps this explains inconsistent reports...

— Reply to this email directly, view it on GitHub https://github.com/jellyfin/jellyfin-roku/issues/449#issuecomment-1108912933, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS7UNM5MFFPAKAHYJZIJMWDVG3RN3ANCNFSM457WAD5Q . You are receiving this because you commented.Message ID: @.***>

BenLand100 commented 2 years ago

I'm primarily using mp4 files, but repackaging to mkv (without changing the encoding) has no effect on the playback for me.

pinovecs commented 2 years ago

Understood. I found that if I took the mp4, imported it into mkvmerge and then just output the same file as mkv all my choppy videos went away.

On Mon, Apr 25, 2022 at 2:47 PM Benjamin Land @.***> wrote:

I'm primarily using mp4 files, but repackaging to mkv (without changing the encoding) has no effect on the playback for me.

— Reply to this email directly, view it on GitHub https://github.com/jellyfin/jellyfin-roku/issues/449#issuecomment-1108917596, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS7UNMZVNRL6UH244RLPJZLVG3SC3ANCNFSM457WAD5Q . You are receiving this because you commented.Message ID: @.***>

BenLand100 commented 2 years ago

Thanks, I can confirm that passing a media file that stutters through mkvmerge does result in a h265 10bit file that does not stutter. ffmpeg -i in.mp4 -c:v copy -c:a copy out.mkv however, does not have any impact on playback. So something mkvmerge does is fixing these files for playback on roku...

neilsb commented 2 years ago

Very odd. Are either of you able to check if this is something that is specific to the Jellyfin app, or do you see the same problem playing through other media players (e.g. Plex, Emby) or from a Network Share? If it's specific to our app then we'll need to look into it in detail. However if it appears to be a Roku issue then we can pass along the information to Roku directly.

pinovecs commented 2 years ago

Hi all! Since I've moved to be nearly exclusively a Jellyfin app user (THANK YOU!) I didn't think to test this in another application. I don't have PLEX or EMBY running, but I still have TVersity running for home videos (different to sort in Jellyfin in my opinion). I took both versions of a file that has issues in Jellyfin on Roku and tested it using TVersity (streaming not being transcoded) and can confirm it is choppy in the MP4 version of the file and the mkvmerge processed file is fine.

If I understand correctly that means its a Roku issue and not Jellyfin App?

On Tue, Apr 26, 2022 at 4:05 AM Neil Burrows @.***> wrote:

Very odd. Are either of you able to check if this is something that is specific to the Jellyfin app, or do you see the same problem playing through other media players (e.g. Plex, Emby) or from a Network Share? If it's specific to our app then we'll need to look into it in detail. However if it appears to be a Roku issue then we can pass along the information to Roku directly.

— Reply to this email directly, view it on GitHub https://github.com/jellyfin/jellyfin-roku/issues/449#issuecomment-1109482549, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS7UNM3ENO7X7TAYVO6R5GLVG6PWDANCNFSM457WAD5Q . You are receiving this because you commented.Message ID: @.***>

neilsb commented 2 years ago

It certainly means it's very likely to be a roku issue, unless TVersity and Jellyfin are doing something similar that causes it, but when playback starts control is pretty much handed over to Roku. You give it the media source and it handles all the decoding and playback, with very little we can effect. So yes - I'd guess it's roku issue.

@pinovecs I assume you're on a roku ultra too? Could you provide me the model number when convenient, and I'll mention to Roku that several of our users are seeing this problem.

Would anyone be willing to provide a sample of a file that exhibits this issue? If so please reach out to me via email or drop by the Jellyfin Roku Matrix Room and give me a shout (neil)

pinovecs commented 2 years ago

So I have 2 Roku Ultras

I have a 4800X - Ultra - 10.5.0 build-4208-C2 - this one has trouble with some HEVC files unless I run them through mkvmerge and then its fine I have a 4670X - Ultra - 10.5.0 build-4208-46 - this one plays every HEVC file without processing

On Wed, Apr 27, 2022 at 1:11 AM Neil Burrows @.***> wrote:

It certainly means it's very likely to be a roku issue, unless TVersity and Jellyfin are doing something similar that causes it, but when playback starts control is pretty much handed over to Roku. You give it the media source and it handles all the decoding and playback, with very little we can affect. So yes - I'd guess it's roku issue.

@pinovecs https://github.com/pinovecs I assume you're on a roku ultra too? Could you provide me the model number when convenient, and I'll mention to Roku that several of our users are seeing this problem.

Would anyone be willing to provide a sample of a file that exhibits this issue? If so please reach out to me via email @.***> or drop by the Jellyfin Roku Matrix Room https://matrix.to/#/%23jellyfin-dev-roku:matrix.org and give me a shout (neil)

— Reply to this email directly, view it on GitHub https://github.com/jellyfin/jellyfin-roku/issues/449#issuecomment-1110547711, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS7UNM5HVOIEZX7EVPWB6HTVHDD7LANCNFSM457WAD5Q . You are receiving this because you were mentioned.Message ID: @.***>

lakerssuperman commented 2 years ago

So I have 2 Roku Ultras I have a 4800X - Ultra - 10.5.0 build-4208-C2 - this one has trouble with some HEVC files unless I run them through mkvmerge and then its fine I have a 4670X - Ultra - 10.5.0 build-4208-46 - this one plays every HEVC file without processing … On Wed, Apr 27, 2022 at 1:11 AM Neil Burrows @.> wrote: It certainly means it's very likely to be a roku issue, unless TVersity and Jellyfin are doing something similar that causes it, but when playback starts control is pretty much handed over to Roku. You give it the media source and it handles all the decoding and playback, with very little we can affect. So yes - I'd guess it's roku issue. @pinovecs https://github.com/pinovecs I assume you're on a roku ultra too? Could you provide me the model number when convenient, and I'll mention to Roku that several of our users are seeing this problem. Would anyone be willing to provide a sample of a file that exhibits this issue? If so please reach out to me via email @.> or drop by the Jellyfin Roku Matrix Room https://matrix.to/#/%23jellyfin-dev-roku:matrix.org and give me a shout (neil) — Reply to this email directly, view it on GitHub <#449 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS7UNM5HVOIEZX7EVPWB6HTVHDD7LANCNFSM457WAD5Q . You are receiving this because you were mentioned.Message ID: @.***>

So the 4800x between the software and hardware reads mkv files differently than older models. My mkv files with DTS were a big issue when I got the new model. I found that running these files through Avidemux added specific tags to the mkv file that restored smooth playback.

I posted about this in the Roku forums. It seems to be a well known issue they either won't or can't fix. There are posts about it in the Plex forums as well, so it doesn't seem to be a Jellyfin issue as much as it is a 4800x issue.

I also found that mkv files I make with Handbrake have to be edited in MKVToolnix to remove header values from the color info or playback on a 4800x is reddish and distorted.

While not ideal, I have found processing my files with this in mind has resulted in propoer playback on the 4800x. As DTS was my main issue, I didn't have to go crazy editing my entire library.

I have not specifically seen just HEVC be an issue, but if processing these files through an mkv program fixes them, they may have suffered similar issues as I was having.

Here is my post in the Roku forums: https://community.roku.com/t5/Playback-Issues-Audio-Video-Power/Rou-4800x-Stuttering-During-Playback-with-DTS-Audio/td-p/783744

And the posts in the Plex forums about the issue: https://forums.plex.tv/t/movies-with-dts-are-stuttering-on-latest-roku-ultra-2020/653197

JPKribs commented 1 year ago

A bit more information I don't quite understand:

It's only h265 10bit content with exactly the res 1920x1080 that has stutter on playback. Files with a vertical crop (res 1920x[less than 1080]) appear to play fine. Perhaps this explains inconsistent reports...

Just to add to this, I am seeing the exact opposite issue but only with Movies. Anything that is a Show can play in h265 10bit without issue regardless of dimensions. However, when I play the same h265 10bit content but at 1920x[less than 1080] it will stutter and fail as a Movie.

So I thought this could be related to the duration of the file. So I took a full movie and put it into the Shows folder and was seeing the same issue. I don't have shows that go over 60 minutes so this could have been the issue. That being said, I am seeing this impact movies as short as 70 minutes so this could be misleading.

Testing movies, I found that Movies 1920x[less than 1080], using 10bit HEVC stuttered only when exceeding 60 minutes? But I could be missing a key detail that is more likely as a culprit.

I took the file that was having issues and I tried 3 things:

mkvmerge changed the file to a mkv with copied video and audio from mp4 to mkv
- This was successful in playback
Handbrake expanded the video (Upscaling) to be 1920x1080 retaining mp4
- This didn't play at all on Roku. Still played without issue on Jellyfin Web.
Handbrake expanded the video (Upscaling) to be 1920x1080 converted to mkv
- This didn't play at all on Roku. Still played without issue on Jellyfin Web.

As a note, all of these interactions were treated as "Direct Stream." I know the information above is kind of all over the place but hopefully this can help a little bit determine where this issue is being triggered from!

TheBetelgeuze commented 1 year ago

I don't have specifics to share right now however can say that shows are affected by this, I have several. I can dig in further later if it's helpful. Edit: add that one of the shows that exhibits shuttering has a resolution of 1920x960 and the length is around 30 minutes.

From: Joe @.***> Sent: Saturday, December 17, 2022 2:44 PM To: jellyfin/jellyfin-roku Cc: Corey Runge; Manual Subject: Re: [jellyfin/jellyfin-roku] 1080 HEVC SDR files choppy on Roku Ultra 2021 (#449)

A bit more information I don't quite understand:

It's only h265 10bit content with exactly the res 1920x1080 that has stutter on playback. Files with a vertical crop (res 1920x[less than 1080]) appear to play fine. Perhaps this explains inconsistent reports...

Just to add to this, I am seeing the exact opposite issue but only with Movies. Anything that is a Show can play in h265 10bit without issue regardless of dimensions. However, when I play the same h265 10bit content but at 1920x[less than 1080] it will stutter and fail as a Movie.

So I thought this could be related to the duration of the file. So I took a full movie and put it into the Shows folder and was seeing the same issue. I don't have shows that go over 60 minutes so this could have been the issue. That being said, I am seeing this impact movies as short as 70 minutes so this could be misleading.

Testing movies, I found that Movies 1920x[less than 1080], using 10bit HEVC stuttered only when exceeding 60 minutes? But I could be missing a key detail that is more likely as a culprit.

I took the file that was having issues and I tried 3 things:

mkvmerge changed the file to a mkv with copied video and audio from mp4 to mkv
- This was successful in playback
Handbrake expanded the video (Upscaling) to be 1920x1080 retaining mp4
- This didn't play at all on Roku. Still played without issue on Jellyfin Web.
Handbrake expanded the video (Upscaling) to be 1920x1080 converted to mkv
- This didn't play at all on Roku. Still played without issue on Jellyfin Web.

As a note, all of these interactions were treated as "Direct Stream." I know the information above is kind of all over the place but hopefully this can help a little bit determine where this issue is being triggered from!

- Reply to this email directly, view it on GitHubhttps://github.com/jellyfin/jellyfin-roku/issues/449#issuecomment-1356491392, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHDH5OR4XGCAM3XXKYXRM2TWNY64RANCNFSM457WAD5Q. You are receiving this because you are subscribed to this thread.Message ID: @.***>

lakerssuperman commented 1 year ago

A bit more information I don't quite understand: It's only h265 10bit content with exactly the res 1920x1080 that has stutter on playback. Files with a vertical crop (res 1920x[less than 1080]) appear to play fine. Perhaps this explains inconsistent reports...

Just to add to this, I am seeing the exact opposite issue but only with Movies. Anything that is a Show can play in h265 10bit without issue regardless of dimensions. However, when I play the same h265 10bit content but at 1920x[less than 1080] it will stutter and fail as a Movie.

So I thought this could be related to the duration of the file. So I took a full movie and put it into the Shows folder and was seeing the same issue. I don't have shows that go over 60 minutes so this could have been the issue. That being said, I am seeing this impact movies as short as 70 minutes so this could be misleading.

Testing movies, I found that Movies 1920x[less than 1080], using 10bit HEVC stuttered only when exceeding 60 minutes? But I could be missing a key detail that is more likely as a culprit.

I took the file that was having issues and I tried 3 things:
1. mkvmerge changed the file to a mkv with copied video and audio from mp4 to mkv

* This was successful in playback

2. Handbrake expanded the video (Upscaling) to be 1920x1080 retaining mp4

* This didn't play at all on Roku. Still played without issue on Jellyfin Web.

3. Handbrake expanded the video (Upscaling) to be 1920x1080 converted to mkv

* This didn't play at all on Roku. Still played without issue on Jellyfin Web.
As a note, all of these interactions were treated as "Direct Stream." I know the information above is kind of all over the place but hopefully this can help a little bit determine where this issue is being triggered from!

So you're getting stutter with mkv files but not with mp4? If that is the case, can you try to edit one of your affected mkv files like I describe above and see if it fixes it?

JPKribs commented 1 year ago

Sorry about that! I guess we have the same issue. .mp4 is producing the error while .mkv is not. Converting the file to .mkv using mkvmerge resolves this 100% of the time so far.

lakerssuperman commented 1 year ago

Sorry about that! I guess we have the same issue. .mp4 is producing the error while .mkv is not. Converting the file to .mkv using mkvmerge resolves this 100% of the time so far.

No need to be sorry!!

So after I responded to you, I randomly clicked on one of my HEVC movies that was in an .mp4 container that has previously played fine. It was stuttering horrifically. I just converted it to .mkv and it plays back fine. This is a totally different issue than the choppiness I was mentioning above related to .mkv files with DTS and missing headers.

I would open a separate issue about .mp4 containers with HEVC/.mp4 having an issue with smooth playback. Previously (prior to the recent HEVC video playback commits), there wasn't an issue with these films playing back that I can recall.

Zerva5 commented 1 year ago

I've been experiencing this issue with HEVC 10 bit content regardless of container or if it's 1080p. I'm using a Roku built into a TCL TV (TCl C105X) with Jellyfin-Roku 1.6 Build 3.

I have 3 movies: Shrek, 1917, and The Report. All 3 are HEVC 10 bit and AAC audio. Shrek and 1917 are .MP4, The Report is .mkv. Shrek is 1920x1080, 1917 and The Report are 1920x800. All 3 have embedded subtitles, and similar bit rates.

Shrek and The Report both stutter, 1917 plays flawlessly. The Jellyfin Roku transcode information shows they all transcode the audio but direct play the video. I can provide the files for all 3 if needed.

JPKribs commented 1 year ago

I've been experiencing this issue with HEVC 10 bit content regardless of container or if it's 1080p. I'm using a Roku built into a TCL TV (TCl C105X) with Jellyfin-Roku 1.6 Build 3.

I have 3 movies: Shrek, 1917, and The Report. All 3 are HEVC 10 bit and AAC audio. Shrek and 1917 are .MP4, The Report is .mkv. Shrek is 1920x1080, 1917 and The Report are 1920x800. All 3 have embedded subtitles, and similar bit rates.

Shrek and The Report both stutter, 1917 plays flawlessly. The Jellyfin Roku transcode information shows they all transcode the audio but direct play the video. I can provide the files for all 3 if needed.

Would you be able to try running the file through MKVMerge? Even just keeping the same inputs / no transcoding or processing. For whatever reason, this resolved the issue for me. I'd be curious if it works for you.

juanitogan commented 1 year ago

Speaking purely about Roku and not Jellyfin...

I have some experience with fixing playback for the couple Roku I have (a 4400X and a 7117X tv). Specifically, I’m talking about the videos that play fine on VLC but not Roku for mysterious reasons. What I have to add here may or may not help since I don't have one of the Roku in question here. But, it sounds similar to issues I've seen... so I add this intel just in case in helps.

To get to the point, in general, I have found that generating (or regenerating) the PTS timestamps in the video stream fixes a lot of things regarding playback, timing, and editing. I do this with a command like:

ffmpeg -fflags +genpts -i "t.mkv" -c copy "t.mp4"

Note that this command typically does not fix anything if you remux MKV to MKV (and I don't know why; ask ffmpeg). Thus I always go from MKV to MP4, or vice verse, or AVI to MKV, or VOB to MKV, etc.

In particular -fflags +genpts is:

always needed when remuxing AVIs,
often needed when remuxing VOBs,
always needed after using MakeMKV with a DVD... if wanting to later clip the output with accuracy and/or keeping audio in sync (have yet to try a BD).

In other words, while a simple remux of a VOB (via ffmpeg, MakeMKV, or HandBrake, etc) is almost always playable by software players like VLC, they also often appear to have questionable timestamp data that can mess with other players. For example, every video I have checked (so far) coming out of MakeMKV shows slightly different times for the frames in VirtualDub2 before and after running ffmpeg -fflags +genpts on that video -- and the latter always proves more accurate for writing trim commands. One video had significantly different times and the audio fell far out of sync when trimmed before genpts, but trimmed fine after genpts. Thus, I find it best to treat all VOB sources as needing a PTS fix (even if they play fine on Roku without it -- which most, as we know, do).

It got overly interesting just the other day when I ran into an x264 in the wild (from HandBrake 0.9.5 according to the metadata) that played fine on the 4400X as is, but stuttered after re-encoding it to x265. It would skip a frame at a rate of about twice a second. The file had an odd rate of 29.403 FPS and an odd size of 718x480 (8:9). Those, it turns out, after a couple of days of testing twenty or so combinations, including fixing the FPS and size, with and without audio re-encodes, were just red herrings.

Another rule I've learned is that, when in doubt, mux to MP4, as that often gives you better messaging. But that wasn't of much help either in this case. Of course, I also tried applying -fflags +genpts to the x265 outputs but that also didn't help here. It was a stumper of a mystery that demanded solving.

I eventually remembered, however, that I had not tried applying -fflags +genpts to the x264 source before re-encoding to x265 (because I don’t normally re-encode from x264; this one was a bad deint job). Once I tried that, it finally worked! D'oh! Sometimes we forget our own experience. Not only did that simple step fix the x265 re-encode, it fixed it regardless of the funny FPS -- and, weirdly, the FPS flaked about from 29.403 (source) to 29.402 (genpts of source) to 30.303 (x265)... somehow. I wish I knew more about PTS and DTS data to explain that... but I don’t. I dig in deep... but not that deep if I don’t have to.

For the record, when I ran ffmpeg -fflags +genpts ... on the x264 source, I got this message:

[mp4 @ 00000183c495b2c0] track 1: codec frame size is not set

I believe, however, that I’ve seen a smattering of various messages when doing this.

Also, when working with ffmpeg, a message like this one is typically a hint that you need to add -fflags +genpts:

[matroska @ 00000175fe477800] Non-monotonous DTS in output stream 0:0; previous: -474, current: -540; changing to -474. This may result in incorrect timestamps in the output file.

BTW, in this instance, I was using Hybrid to re-encode (which uses x265.exe). To be thorough, I also tested ffmpeg (v6.0) to re-encode (perhaps the same x265 lib but wanted to be sure). I ran into the same issues and same solution with ffmpeg as Hybrid (although, the stuttering timing felt a bit different and more random). I also tried adding -fflags +genpts to the encode step but that didn’t work either: genpts needs to be done to its own intermediate file before encoding.

Given all the above, it is also not surprising to hear that a remux by mkvmerge can sometimes fix similar problems when a similar remux by ffmpeg can’t. On the other hand, I sometimes find that a bare-bones remux by ffmpeg does fix problems (but I do not recall if it has ever fixed a skipping problem or not). Thus, nothing is surprising on this front.

But, to fully test out the mkvmerge idea (in case, by default, it rewrites the timestamp data whereas ffmpeg obviously only rewrites it when you tell it to), I ran mkvmerge on my test files (not my usual tool except that Hybrid uses it). Unfortunately, it didn’t fix the skipping in any of them with a simple remux from MP4 to MKV. Thus, it appears there may be more going on here than PTS issues. Sigh.

Regardless, I give it okay odds (not great, but merely okay) that a better PTS solution could fix the Roku issues here, but others will have to test that theory with ffmpeg -fflags +genpts ... before and/or after the x265 encode. Really, however, someone should take a closer look at a broken 1080p HEVC MP4 remuxed to MKV by ffmpeg (and still broken) versus one remuxed to MKV by mkvmerge (now working). I don’t have one to test (and don’t know yet if my 7117X would find it broken or not).

Other issues I regularly run into on Roku (mostly with the older 4400X):

10-bit color generally works where expected, but not always (but not well tested by me, and I vaguely recall that the issue might have been skipping).
VFR (variable frame rate) rarely works, if ever (and very annoying to see in anything other than tiny video).
HE-AAC never works.
60 fps x265 sometimes works on the 4400X but seems to overload it -- especially when trying to navigate -- and causes various skipping, stalling, and fast-forwarding.

I haven’t chased much of this other stuff out because if one of these edge features (edge to me) doesn’t work on the target Roku, I just re-encode to 8-bit CFR x265 AAC-LC without further ado (my [wimpy]HDR TV isn’t awesome enough to see much difference with 10-bit). These features often travel in gangs... all the more reason for me to throw in the towel early and just accept an unfortuate re-encode is coming. Someday I might dig deeper in to the next 10-bit issue I run into (if indeed it is due to 10-bit and not VFR etc.).

I hope some part of this helps......... somehow, somewhere, someway.

1hitsong commented 9 months ago

If you're still experiencing this issue using the latest Roku client release, please post to the troubleshooting forum. There are tons of great people help who can help dive into issues like this.

https://forum.jellyfin.org/f-troubleshooting

jellyfin / jellyfin-roku

1080 HEVC SDR files choppy on Roku Ultra 2021 #449