YouTube HDR... finally

[Kuschelmonschter]

YouTube HDR content is finally available!

You will find a playlist here. However, these clips will be played as SDR on Sonys for now.

With youtube-dl you can find vp9.2 encodings for those clips:

330          webm       256x144    144p60  156k , vp9.2, 60fps, video only, 2.38MiB
331          webm       426x240    240p60  256k , vp9.2, 60fps, video only, 3.87MiB
332          webm       640x360    360p60  485k , vp9.2, 60fps, video only, 7.35MiB
333          webm       854x480    480p60  909k , vp9.2, 60fps, video only, 13.83MiB
334          webm       1280x720   720p60 1991k , vp9.2, 60fps, video only, 28.18MiB
335          webm       1920x1080  1080p60 3201k , vp9.2, 60fps, video only, 49.70MiB
336          webm       2560x1440  1440p60 11166k , vp9.2, 60fps, video only, 170.23MiB
337          webm       3840x2160  2160p60 20122k , vp9.2, 60fps, video only, 335.45MiB

Those are webm however which the native Video app won't play.

We will see whether we will get support for it soon, even for the early 2016 models with the old MediaTek SoC from last year. At least Sony promised that back at CES:

Spoiler

YouTube will also start streaming in HDR quality later this year, using a new VP9-Profile 2 codec that brings HDR support to Google’s VP9 video format. Sony’s Motoi Kawamura, Head of TV Product Planning for Sony Europe, confirmed to FlatpanelsHD that the 2016 models will support VP9-Profile 2 and be capable of streaming YouTube in HDR. We saw a demo at CES and it looked very good.

Source

[Jecht_Sin]

Ok, I have done the test with v2.0. Always the same video, "The World in HDR in 4K" and bizarre enough today it plays at 1440p@60.. It's a CPU sucker indeed:

Mem: 1411356K used, 202356K free, 95196K shrd, 704K buff, 279904K cached
CPU: 44.1% usr 24.2% sys  0.1% nic 29.8% idle  0.0% io  0.0% irq  1.5% sirq
Load average: 39.47 38.28 37.30 6/2712 14196
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
11282  1244 u0_a140  R    1387m 87.8   1 50.1 {roid.youtube.tv} com.google.android.youtube.tv
 1235     1 system   D <   169m 10.7   0  4.1 /system/bin/surfaceflinger
 1272     1 media    S     264m 16.7   0  3.2 /system/bin/mediaserver
 1711     2 root     DW       0  0.0   3  2.1 [NR main loop]
 1319     2 root     SW       0  0.0   0  1.1 [VDEC  4]

Videos running at 1080@60 didn't have much better performances.

Back to version 1.3.11 the same video plays at 1080p max, no mention of the frame rate. And this is the CPU usage:

Mem: 1499308K used, 114404K free, 101416K shrd, 7620K buff, 294740K cached
CPU: 25.7% usr 26.7% sys 10.4% nic 23.2% idle 11.9% io  0.0% irq  1.8% sirq
Load average: 40.56 38.96 37.76 5/2813 15479
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
14987  1244 u0_a140  S    1312m 83.0   0 16.3 {roid.youtube.tv} com.google.android.youtube.tv
14662  1244 u0_a57   S    1227m 77.6   0 12.3 {android.vending} com.android.vending
 1754  1244 system   S    1873m118.5   1  8.5 system_server
 1235     1 system   S <   142m  9.0   0  3.9 /system/bin/surfaceflinger
 2688  1096 media_rw S     8236  0.5   0  3.8 /system/bin/sdcard -u 1023 -g 1023 -m -w /data/media emulated
 1272     1 media    S     265m 16.8   1  3.2 /system/bin/mediaserver

Playing videos at 2160p it just gets a bit higher:

Mem: 1463808K used, 149904K free, 90532K shrd, 1148K buff, 358904K cached
CPU: 23.7% usr 21.3% sys  0.0% nic 47.0% idle  3.5% io  0.0% irq  4.2% sirq
Load average: 38.98 38.90 38.16 3/2671 17287
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
15602  1244 u0_a140  S    1285m 81.3   2 21.4 {roid.youtube.tv} com.google.android.youtube.tv
 2688  1096 media_rw S     8236  0.5   3  4.2 /system/bin/sdcard -u 1023 -g 1023 -m -w /data/media emulated
 1235     1 system   S <   126m  7.9   0  3.4 /system/bin/surfaceflinger
 1272     1 media    S     265m 16.8   0  3.2 /system/bin/mediaserver
 1711     2 root     DW       0  0.0   3  2.8 [NR main loop]
 1754  1244 system   S    1875m118.7   3  2.3 system_server

I think there is more than one reasons if Google didn't publish update yet...

Instead, is it me ot Google is spamming ads in YouTube, lately?

[Kuschelmonschter]

I did some more tests with "The World in HDR" now. I didn't know that when you copy ffmpeg into the same directory as youtube-dl, you can easily download your desired AV streams with automatic muxing...

2160p60 VP9 + Opus Audio:

youtube-dl -f 315+251 https://www.youtube.com/watch?v=tO01J-M3g0U

2160p60 VP9 + Vorbis:

youtube-dl -f 315+171 https://www.youtube.com/watch?v=tO01J-M3g0U

I played both videos inside Kodi. They played absolutely judder free (60fps@60Hz) at minimal CPU usage:

User 17%, System 15%, IOW 0%, IRQ 0%
User 38 + Nice 0 + Sys 34 + Idle 150 + IOW 0 + IRQ 0 + SIRQ 0 = 222

  PID PR CPU% S  #THR     VSS     RSS PCY UID      Name
22027  0  12% S    44 1180284K 167328K  fg u0_a164  org.xbmc.kodi
 1132  0   6% S    25 124540K  12176K  fg system   /system/bin/surfaceflinger
 1140  0   2% S    47 161996K   8368K  fg media    /system/bin/mediaserver

Looks easy...

[Jecht_Sin]

I am not sure, but I thought Opus and Vorbis aren't supported by the TV. I know that Kodi is able to transcode the unsupported formats, since it plays a demo with DTS-HD (mute in any other player). And that would be CPU costly.

Anyway, I did a fast check with Kodi myself yesterday and a couple of videos did drop frames. I just went through my UHD HDR folder via DLNA. They all play smoothly in Video, though (unless there is a buffering due to network bandwidth. It seems in some points they may go above 100Mbps).

PS: YouTube version 2.0.18 has been leaked in apkmirror. But it is for arm64 only. I have setup the pushbullet notifications in apk mirror for the YouTube updates. That's how I know in real time.

[Kuschelmonschter]

---

Jecht_Sin schrieb:
I am not sure, but I thought Opus and Vorbis aren't supported by the TV.

---

You can software-decode any format and output as PCM. It is not costly at all.

Kodi can even transcode to AC3, so decode any format and encode to AC3. Even this does not cost a lot of CPU time. I am already doing it for Live TV to get multi-channel audio where you need resampling to adapt to the live stream speed (as you can't vary the speed of a DVB stream). So Kodi does decode audio > resample audio > transcode to AC3. All that in software.

[Jecht_Sin]

I honestly know very little about audio (and video) decoding. But if it is SW decoded something must run that SW?I thought that was taking quite some resources.

I mean, I know that if I play the same videos in my Mac, which surely has a much more capable CPU (just the Intel I5, but there should be little comparison with the MT5891 CPU), the CPU goes crazy at 100% and beyond! If the videos get even played, that's it. But that's what happens when I play 4K videos in YouTube with Chrome (the YouTube's player in  Safari isn't allowed to go 4K it seems).

Then any idea why Video doesn't play the DTS-HD audio? I have been surprised that Kodi managed (and quite well) to play, audio included, this La La Land Trailer, which is also UHD HDR. Video and Plex simply refuse to play the audio. This is what I get from top:

Mem: 1470896K used, 142816K free, 104512K shrd, 3892K buff, 258640K cached
CPU: 26.3% usr 22.6% sys  0.1% nic 41.4% idle  0.0% io  0.0% irq  9.4% sirq
Load average: 37.17 36.19 36.05 9/2565 15518
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
28168  1242 u0_a158  S    1576m 99.7   3 37.5 org.xbmc.kodi
 1233     1 system   D <   147m  9.3   1  6.7 /system/bin/surfaceflinger

It's 465 MB for 64 seconds. So, using simple arithmetic, I suppose a bitrate of 58Mbps. But I am sure you would know better!

[Kuschelmonschter]

Decoding video in SW is quite demanding indeed. 4K HEVC or VP9 is hardly feasible on even latest computers unless GPUs have a dedicated ASIC for it. Some kbps of audio on the other hand is easy even for the slow ARM CPUs inside Sony. CPU usage is in the lower single digit area, even when transcoding to AC3. You can easily decode video in HW while decoding audio in SW...

---

Then any idea why Video doesn't play the DTS-HD audio? I have been surprised that Kodi managed (and quite well) to play, audio included, this La La Land Trailer, which is also UHD HDR. Video and Plex simply refuse to play the audio.

---

AFAIK, ffmpeg (which Kodi uses) can decode DTS HD and output it as stereo PCM. It is not an open standard. So the bitstream had to be reverse-engineered which was completed not a long time ago. Suppose Plex can't do it.

I think that DTS HD mandates to have DTS compatible core inside. So Plex should at least be able to decode that. It probably tries passthrough which is a problem on Sony. The MediaTek driver neither implements ENCODING_DTS nor ENCODING_IEC61937 to get DTS out of the TV. The only possibility is the PCM hack which is supported by some Kodi custom builds or SPMC in IEC mode. You can find some more info about it here.

[Jecht_Sin]

All right, thanks! I have checked your other post as well and I have a slightly better idea, now. So as usual it's due to Mediatek. I knew, it, as soon as I discovered that this was an Android TV with a Mediatek SoC I thought: Oh well, I am - insert your most favorite derogatory word in here -!

I promised myself years ago to never ever buy another Android device not mounting a Qualcomm SoC. And there we are. I mean, the lack of DTS-HD isn't really a major issue to me. But when a couple of weeks ago I was at MediaWorld (Media Markt), talking with a Bravia representative and the settings in a 2700€ Bravia XE94 (same SoC of my XD80 as you know) took 5 seconds to show up I laughed for not crying. He wasn't very happy either... 

This has all the potential to end up like Nokia with Windows Phone.

[Kuschelmonschter]

Thanks to Kodi and its ffmpeg, you can play almost any audio. Just disable passthrough and it will ouptut everyting as decoded stereo PCM, even DTS HD (probably not the newer things like DTS:X or Dolby Atmos).

As for passthrough you have to know quite some things due to broken MediaTek drivers...

Lollipop features ENCODING_AC3 and ENCODING_EAC3 APIs which both work with Sony. Older FWs could not do 640kbps AC3. Newer FWs fixed that.

Marshmallow and Nougat feature ENCODING_AC3, ENCODING_EAC3 and also the new ENCODING_DTS APIs. The MediaTek driver does not support ENCODING_DTS.

On Nougat, apps can alternatively use ENCODING_IEC61937 for all bitstream audio (apps are responsible for packaging audio instead of the OS). Kodi Krypton uses it for example. Again the MediaTek driver does not support the new API. So you can't passthrough any compressed audio, neither Dolby nor DTS. Apps that use the old APIs can still output Dolby at least.

The last resort is PCM hack which I don't recommend though. It misuses ENCODING_PCM to output compressed audio...

As for HD audio, you can't passthrough that via S/PDIF or ARC at all. But both, DTS HD and Dolby True HD have a DTS and AC3 compatible core for passthrough. Above restrictions also apply here.

[Jecht_Sin]

Ok, thanks! That has been quite informative.

Instead, back to the performances issue.. I have updated to the latest Plex version. Not touching the settings it does play all my HDR demos in HDR (I tested a dozen). And I have confirmatuon now that the high CPU usage is due to the.. downloading!!

Indeed playing the video while streaming the Plex CPU usage was at about 50-60%. Allowing the player to download the full video, and the play it, it went down to 10-15%. 

I have posted the issue in the Plex forum, with all CPU monitoring. I wanted to add the link here but after editing it to add some tags, I have got the message that my post needs to be approved.

Actually I see I have it in the web cache (I mean, going back). This is what I have wrote (sorry for the ugly format but these forums are a pain):

------------ 

And it is still quite high even with 720p or 1080p videos. I used "busybox top" for the measurement in my Bravia 49XD8099. Plex version: 6.2.1.1036, the latest one in the Play Store.

When I play any UHD (HDR or less) video I get a similar CPU usage, with idle time always near 0%. Needless to say the videos lose frames, some even stutter:

Mem: 1294304K used, 319408K free, 89508K shrd, 11980K buff, 249128K cached
CPU: 55.9% usr 27.3% sys 2.7% nic 6.6% idle 0.1% io 0.0% irq 7.2% sirq
Load average: 41.58 40.05 39.43 13/2460 24302
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
20808 1242 u0_a169 R 1987m125.7 0 57.8 {plexapp.android} com.plexapp.android
1233 1 system R < 155m 9.8 0 9.2 /system/bin/surfaceflinger
1265 1 media S 129m 8.2 3 4.6 /system/bin/mediaserver
1085 1 logd S N 17956 1.1 1 2.7 /system/bin/logd
13720 2 root DW 0 0.0 2 2.0 [SonySOPQCtrlVdo]

Pausing the video I still get quite an high CPU usage (Plex should be just reading the video ahead):

Mem: 1454824K used, 158888K free, 88800K shrd, 6872K buff, 256992K cached
CPU: 43.6% usr 26.8% sys 2.3% nic 19.1% idle 0.0% io 0.0% irq 7.9% sirq
Load average: 40.03 40.11 39.52 3/2446 24469
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
20808 1242 u0_a169 R 2170m137.3 0 46.8 {plexapp.android} com.plexapp.android

All these videos just played fine with version 5.10.x.y. Buffering apart (that would be another issue. Often it doesn't use the full LAN bandwidth - 100Mbps). I decided to update (also for testing) and I have seen that updating it keeps my previous settings, and it doesn't trigger the 4K transcoding bug. So unless it breaks again I'll keep it as it is.

Actually, no. It IS due to the downloading! If I pause the video waiting until it is all in memory, while playing the video I get this other CPU usage:

Mem: 1440380K used, 173332K free, 91200K shrd, 4376K buff, 234412K cached
CPU: 14.1% usr 16.7% sys 0.3% nic 68.7% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 38.39 37.41 38.35 3/2508 25436
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
20808 1242 u0_a169 S 2148m135.9 2 10.0 {plexapp.android} com.plexapp.android

So what is it, to download 8-9MByte/s sits down the CPU?

[Kuschelmonschter]

Networking and MediaTek... we know that story... However, this also looks like a regression in Plex...

I am not really a big Plex fan. I played around with it a lot. Different clients, different software versions. There has always been regressions here and there. The transcoding possibility is quite sexy, but my NAS is not fast enough for that. Even though the TV would support most formats to be played via Direct Stream or Direct Play, Plex server unnecessarily transcoded certain content, especially MPEGTS. That's why I use Kodi which simply accesses shares on my NAS and plays everything back without any transcoding. I mostly watch stuff at home on my TV anyway. For mobile viewing, I still have Netflix and Amazon Prime...

However, for my above tests, I played video from USB3. I might also try playing the above samples via DLNA and NFS...