Sony X900H 8.6.0 refresh rate switching 25 fps stutters

Plex Players Streaming Devices
,
1

Server Version#: Synology 1.20.2.3370
Player Version#: 8.6.0.20351

Attempting to watch 4K 25 fps 48 Mbps HEVC 153 Main 3 content using my new Sony X900H with Android TV.

The content looks great, but appears to be skipping a frame or appearing to stutter at repeated intervals.

I’ve turned on Refresh Rate Switching in the Advanced menu and this TV should support a variety of refresh rates.

I really want to watch this gorgeous 4K HDR content on my new TV, but this stuttering/juddering issue is making it too annoying to watch right now.

I also should note I’m using 1 Gbps Ethernet .

2

From Googling your TV, I don’t see that 25 is supported. Can you restart the Plex app, reproduce the problem, then get me the log. That should indicate what is or is not supported. Android, Android TV, Fire TV Logs | Plex Support

3

Here are some of the logs from playback today.

[mod edit] - removed

4

Please provide the log info as a text file.

5

logging-Sony-65X900H-AndroidTV.log (2.1 MB)
Log attached.

6

Your logs only show 1 display mode. 1920x0180 @ 60Hz.

It also shows you are trying to play a ~50 Mbps 4K video with PGS subtitles. TV have fairly low processing power. Older 1080p TVs have significantly lower powered processors than 4K TVs. My guess is your TV just can’t handle this file and it may not have anything to do with the refresh rate.

Do you see the same issue with 1080p videos at 24 fps?

7

That’s strange the log only shows 1920x1080 @ 60Hz. Plex interface shows “4K HDR” during playback. I have Refresh Rate Switch and Resolution Switching both turned.

The TV is this the Sony 65-inch X900H or XH90 in the U.K. A 2020 model TV with 4K @ 120 Hz max resolution.

Anyways, my diagnosis is that some combination of the Plex app and Android TV does not like 25fps files. Zero of the dozens of 4K 24fps or 1080 24fps files I’ve played back have the same issue. My Amazon Fire TV 4K plays the 25fps content back a bit better but I still notice a little bit of stutter/judder every second where as the Plex on Android TV has very noticeable stutter/judder occur exactly every 6 seconds.

I’ve resolved to just sticking to 4K @ 24fps content. Maybe we’ll see a bug fix in the future from either Android TV developers or Plex app developers for Android TV will resolve this problem.

8

This is also the case for shield 2019 pro, 25fps playback has very bad studder.
You can use the old player , (if it will start the file and not crash) the playback will be better.

9

Sorry, I meant 1080p 25 fps videos. Trying to see if it’s the 25 fps or a combination of 25 fps and the really high bit rate.

Ok, I see that the app detected the change in resolution to 4K but it wasn’t able to detect this prior to playback starting. Check your Android TV settings and see if there is something that is forcing the TV to run at 1080p 60Hz. If there is, try changing it to automatic (if available).

Although I still don’t think your TV will support 25 fps. If I’m right, then a 25 fps file is always going to have some issues.

10

FYI. I am having the same issues with my 65" X900H. Hopefully this is a bug that gets fixed soon.

11

I am having a similar issue with my Sony A8H that I suspected was with 25fps content. After coming across this thread I’ve been trying to encode my own video which encounters the issue using ffmpeg with no success.

I have a 15 second clip which I can reliably reproduce the issue on. I extracted this clip from the original material with the following command:

ffmpeg -ss 00:01:00 -to 00:01:15 -i SOURCE.mkv -c copy clip.mkv

The closet copy I’ve been able to make from this source is via the following command:

ffmpeg \
  -i clip.mkv \
  -map 0 \
  -c:a copy \
  -c:v libx265 \
  -x265-params hdr-opt=1:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:master-display="G(0,0)B(0,0)R(0,0)WP(0,0)L(0,0):chromaloc=2:level-idc=51" \
  -crf 4 \
  -preset veryfast \
  -pix_fmt yuv420p10le \
  tmp.mkv

The output of ffmpeg -i FILENAME against the two files differs only in the following ways

@@ -10,11 +10,11 @@
   libswscale      5.  7.100 /  5.  7.100
   libswresample   3.  7.100 /  3.  7.100
   libpostproc    55.  7.100 / 55.  7.100
-Input #0, matroska,webm, from 'clip.mkv':
+Input #0, matroska,webm, from 'tmp.mkv':
   Metadata:
     ENCODER         : Lavf58.45.100
-  Duration: 00:00:15.76, start: 0.000000, bitrate: 38921 kb/s
+  Duration: 00:00:15.76, start: 0.000000, bitrate: 36939 kb/s
     Chapter #0:0: start 0.000000, end 572.719600
     Metadata:
       title           :
@@ -30,7 +30,7 @@
     Chapter #0:4: start 2500.799521, end 2882.563000
     Metadata:
       title           :
-    Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 23.98 tbc (default)
+    Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 25 tbc (default)
     Metadata:
       BPS-eng         : 44712655
       DURATION-eng    : 00:49:02.560000000
@@ -39,6 +39,7 @@
       _STATISTICS_WRITING_APP-eng: mkvmerge v23.0.0 ('The Bride Said No') 64-bit
       _STATISTICS_WRITING_DATE_UTC-eng: 2018-07-03 15:56:58
       _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
+      ENCODER         : Lavc58.91.100 libx265
       DURATION        : 00:00:15.760000000
     Stream #0:1(eng): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s32p (24 bit) (default)
     Metadata:

Additionally the output of mediainfo FILENAME differs only in the following ways:

@@ -1,12 +1,12 @@
 General
-Unique ID                                : 119244307629973144509392521206569066714 (0x59B59E4759D6DB7F29A6852BED2F60DA)
-Complete name                            : clip.mkv
+Unique ID                                : 233430700465692920000581663236344472961 (0xAF9D1E1ACFD6312CF5EB189560376581)
+Complete name                            : tmp.mkv
 Format                                   : Matroska
 Format version                           : Version 4
-File size                                : 73.1 MiB
+File size                                : 69.4 MiB
 Duration                                 : 15 s 760 ms
 Overall bit rate mode                    : Variable
-Overall bit rate                         : 38.9 Mb/s
+Overall bit rate                         : 36.9 Mb/s
 Writing application                      : Lavf58.45.100
 Writing library                          : Lavf58.45.100
@@ -26,12 +26,14 @@
 Display aspect ratio                     : 16:9
 Frame rate mode                          : Variable
 Frame rate                               : 4 667.766 FPS
-Original frame rate                      : 23.976 (24000/1001) FPS
+Original frame rate                      : 25.000 FPS
 Color space                              : YUV
 Chroma subsampling                       : 4:2:0 (Type 2)
 Bit depth                                : 10 bits
 Bits/(Pixel*Frame)                       : 0.001
 Stream size                              : 15.3 GiB
+Writing library                          : x265 0.0:[Mac OS X][clang 12.0.0][64 bit] 10bit
+Encoding settings                        : cpuid=1111039 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=2 / no-allow-non-conformance / repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=15 / lookahead-slices=8 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=1 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=2 / selective-sao=4 / early-skip / rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=4.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / 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=9 / transfer=16 / colormatrix=9 / chromaloc=1 / chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(0,0)B(0,0)R(0,0)WP(0,0)L(0,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 / hdr10 / 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 / decoder-max-rate=0
 Default                                  : Yes
 Forced                                   : No
 Color range                              : Limited

Given that my encoded copy of the 25fps files seem to work, it seems that something else is the culprit of the stutter. Perhaps it has something to do with the framerate of the original file being 25fps, but its tbc being 23.98. I’ve not figured out how to make those numbers match after re-encoding the video.

1 Like
12

I’ve done a little more digging.

First, I verified that the problem is only with the video track. I first tried to remove everything but the video track with ffmpeg, however, the player crashed without an audio track. So here’s my updated command to make the simplest sample video by using a blank audio track and stripping chapters and other metadata:

ffmpeg \
  -hide_banner \
  -f lavfi \
  -i aevalsrc=0 \
  -ss 00:00:32 \
  -to 00:01:00 \
  -i SOURCE.mkv \
  -c:v copy \
  -c:a aac \
  -map 1:v \
  -map 0:a \
  -shortest \
  -map_chapters -1 \
  -map_metadata -1 \
  clip.mkv

Using the mkvmerge tool, I was able to fix the video playback losslessly by changing the framerate. Changing to both 23.98fps, and 24fps seems to have resolved the issue (of course that’ll cause audio issues):

mkvmerge --default-duration 0:24000/1001fps --fix-bitstream-timing-information 0 clip.mkv -o 23.mkv
mkvmerge --default-duration 0:24fps --fix-bitstream-timing-information 0 clip.mkv -o tmp.mkv

To take it a step further I wanted to see if I could break a working 23.98fps video by changing to 25fps. I downloaded the following video and confirmed it works on my setup:
https://www.makemkv.com/download/dvtest/P4_LG_Dolby_Trailer_4K_Demo.mkv

I then converted it to 25fps via:

mkvmerge --default-duration 0:25fps --fix-bitstream-timing-information 0 P4_LG_Dolby_Trailer_4K_Demo.mkv -o 25fps.mkv

I confirmed the video displayed the stuttering issue.

It’s important to note that videos which are encoded completely in 25fps work fine, which is why I couldn’t reproduce the issue last night. It appears to be only the videos whose timing has been changed to from 23.98fps to 25fps:

    Stream #0:0(eng): Video: hevc (Main 10), yuv420p10le(tv), 3840x2160 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 23.98 tbc

To take it one step further I wanted to test with a 1080p HEVC file. From any 1080p source video I ran:

ffmpeg -r 23.976 -i SOURCE.mkv -map 0 -c:a copy -c:v libx265 test.mkv

I verified that file plays fine. I then converted it to 25fps as so:

mkvmerge --default-duration 0:25fps --fix-bitstream-timing-information 0 test.mkv -o test_25.mkv

This file displays similar timing information as the original 4K file I noticed the issue with:

    Stream #0:0(eng): Video: hevc (Main), yuv420p(tv), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 23.98 tbc (default)

I suspect if I used the x264 encoder the problem wouldn’t show up, so it’s probably an issue pertaining to the HEVC decoder used by Plex on these TVs. I haven’t had time to verify that suspicion yet.

1 Like
13

Another update. I confirmed that the problem does not exist if I take a x264 file at 23.98fps, and adjust the framerate with mkvmerge to 25fps. The output looks a little different though as tbc is now a multiple of fps.:

    Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 1k tbn, 50 tbc (default)

The source starts out as:

    Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

I also confirmed that there is nothing special with 25fps when using HEVC. The issue exists if I take a 24fps file and adjust the framerate to 30fps.

24fps source (no playback issues):

    Stream #0:0(eng): Video: hevc (Main), yuv420p(tv), 1920x1080 [SAR 1:1 DAR 16:9], 24 fps, 24 tbr, 1k tbn, 24 tbc (default)

30fps (playback issues):

    Stream #0:0(eng): Video: hevc (Main), yuv420p(tv), 1920x1080 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 1k tbn, 24 tbc (default)

Due to a bigger gap in the number of frames available and the desired fps (4 in this case), the jitters happen more frequently (about every second), whereas they were about every 3 seconds before. It seems like the HEVC decoder used by Plex on our Sony devices is introducing extra frames in an unfortunately visible way. Aside from expected audio sync issues introduced by these experiments, VLC plays these videos smoothly. I’ll test Plex via my Roku shortly.

@anon18523487 does this give you more actionable information?

1 Like
14

Nice investigative work. Unfortunately, it’s beyond me. I’ll bring it up with our transcoder guru.

Please note that it’s not a Plex decoder. The Plex app uses the decoder that comes on the device. If it is an issue with the decoder, it’ll need a fix by Sony.

1 Like
15

Huh, bizarre; looks like the codec’s internal time base (the “tbc” you see there) doesn’t match the frame rate specified in the container… though it’s weird that it would manifest in the way you’re seeing. What’s the file actually supposed to be? How many actual frames are there per actual second?
I’m not sure what we can really do about this other than possibly detecting it and forcing a transcode on affected files, tbh.

16

The encoder notes that they used a 23.976 fps video source with the audio stream from a 25fps source. Personally I’m not sure why any of that would be necessary assuming the duration of the video source is the same as the duration of the audio source.

The framerate of the video, subtitles and chapters has been changed from 23.976fps to 25fps to match that of the audio.

To add a little more context, I verified that Plex via Roku Ultra plays these videos without the noticeable jitter. Additionally, the Sony media player app has trouble directly playing these files. The videos actually completely stop playing either immediately, or after the location where the first jitter would have occurred. Now that I know the decoder is device specific, perhaps Plex is simply recovering more gracefully from a decoder error?

17

Was this Frankenstein’s-monster of a file produced by taking the video from a release in an NTSC region, and the audio from a PAL region, and stapling them together, perhaps?

18

Yes, that seems correct. Based on some reading I just did (Correctly recode PAL 25fps dvds to standard 23.976 fps - www.makemkv.com) it seems like it’s somewhat common for the speed to simply be sped up (going NTSC to PAL) or slowed down (PAL to NTSC). So it seems like the desired outcome of this merging was to slightly speed up the video so that its duration matches the slightly shorter duration of the PAL audio.

19

I meant to say initially - your diff output was a truly lovely thing.

I think this victim encountered a different fate. As you said - I imagine the video and audio have matching durations. These streams weren’t encoded together, they were remuxed from different sources. The result is a chimera, a platypus.

But with different timecodes for each steam, the TV is trying to dance a waltz (video) and a cha cha (audio) at the same time, and it’s tripping on its toes.

There are many different ways to synchronize video and audio streams for playback, and it sounds like the Sony’s method assumes that the timecodes will match. But if I worked at Sony and QA told me this file didn’t play, I would tell them WONTFIX.

You could probably reencode the audio to match the video, but it would lose the HD/Spatial audio features. Probably better to go back to the source and get a less-weird file.

20

Thanks! The form software automatically syntax highlighted the diff between sets of ```.

Any idea where the best place is to reach them about such an issue? I think it’s worth reaching out, even if it goes nowhere.

I’ll use Plex via a Roku Ultra than using the Plex app directly on my TV. I was hoping to avoid needing an external device but it seems like the best solution for the time being.