Kodi Community Forum
Android "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Discussions (https://forum.kodi.tv/forumdisplay.php?fid=222)
+--- Forum: Hardware (https://forum.kodi.tv/forumdisplay.php?fid=112)
+--- Thread: Android "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI (/showthread.php?tid=357396)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-12

Could you please make the samples a bit longer? :-) I just see a first picture - no idea if it's stuttering or not.


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - Tamas.Toth.ebola - 2021-01-13

Your request is understandable, but basically you could identify the problem from that 3 sec. That 3 sec. is an animated 'D' logo with fluidly moving parts on it. With Kodi on GCGTV the 8 bit variant is fluid but the 10 bit is just one all-in-all 2-3 frame slideshow. With casting the same file to GCGTV we get fluid animation on both of them but with Kodi the 10 bit one is just a 'slideshow'. Also in debugging mode the top-left frame rate overlay clearly shows 1-2 frame per sec. playing performance instead of the 'proper values' with the 8bit version.

On my old Sony Android tablet I got same results. 8 bit absolutely fine, 10 bit is almost still image or slideshow.

Some other 10 bit HEVC files works fine but seems that these are also error less files just a little bit different. I think because just some different header data Kodi 'send these files' to SW renderer instead of HW, but of course this is just a tip, could be totally different reason.

But of course I re-uploaded that 2 slices with 1 min. duration instead the original 3 sec.

Very lot of thanks for your continuous effort!!!


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-13

Thanks. Runs fine on my FireTV Cube. Will test and check on chromecast at the end of the week.

Edit: From your log I have seen, that you scale down to 1080p. Do we already know if it works fine if output at 4K? Perhaps someone else in that thread could test that - cause my chromecast is only connected to a 1080p TV as well.


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - Tamas.Toth.ebola - 2021-01-13

(2021-01-13, 13:34)fritsch Wrote: Thanks. Runs fine on my FireTV Cube. Will test and check on chromecast at the end of the week.

Edit: From your log I have seen, that you scale down to 1080p. Do we already know if it works fine if output at 4K? Perhaps someone else in that thread could test that - cause my chromecast is only connected to a 1080p TV as well.

Yes, you saw it right. As I wrote before sadly my current TV is just an old Samsung - 55D7000 [1080p SDR] TV, what should be really upgraded in this yearSmile Therefore I simply can can not check what is the result with 4k TV. The other 'problem' of course is the SDR. While the TV is SDR the video itself is HDR. Both of these 2 differences mentioned before to make the situation clear. So in the corresponding process line there is one 'forced' downscaling and also (if it possible) one tonemapping (or any other like dynamic compression).

The interested side of it that 4k 8bit files works fine (so could be the forced HDR>SDR conversion the reason of the overload), as there is also downscaling without problems, and seems that there is no real HDR>SDR conversion as the result is color off picture with very high dark levels.
But what is really confirm that not the HDR>SDR conversion is the reason that other 4k HDR files works. Not all but there are.

There are simply working 4k HDR HEVC files (not just one... more, much...) and there are simply not working 4k HDR HEVC files (not just one, more, much). I simply could not determine yet that important difference what could be the reason of the problem.
4k SDR files are all working (yet).

The problem is clearly visible as other persons also wrote. Max 1-2 frame per sec. playing performance, and overloaded Kodi sometimes with really frozen Kodi or Chromecast. Seems absolutely overloaded clearly CPU based rendering, but this is just what I see.

Hope this is clear now.

Thanks again...


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - en6ads - 2021-01-13

Can it play 3d MVC ISOs or MKV files?


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-13

(2021-01-13, 14:49)Tamas.Toth.ebola Wrote:
(2021-01-13, 13:34)fritsch Wrote: Thanks. Runs fine on my FireTV Cube. Will test and check on chromecast at the end of the week.

Edit: From your log I have seen, that you scale down to 1080p. Do we already know if it works fine if output at 4K? Perhaps someone else in that thread could test that - cause my chromecast is only connected to a 1080p TV as well.

Yes, you saw it right. As I wrote before sadly my current TV is just an old Samsung - 55D7000 [1080p SDR] TV, what should be really upgraded in this yearSmile Therefore I simply can can not check what is the result with 4k TV. The other 'problem' of course is the SDR. While the TV is SDR the video itself is HDR. Both of these 2 differences mentioned before to make the situation clear. So in the corresponding process line there is one 'forced' downscaling and also (if it possible) one tonemapping (or any other like dynamic compression).

The interested side of it that 4k 8bit files works fine (so could be the forced HDR>SDR conversion the reason of the overload), as there is also downscaling without problems, and seems that there is no real HDR>SDR conversion as the result is color off picture with very high dark levels.
But what is really confirm that not the HDR>SDR conversion is the reason that other 4k HDR files works. Not all but there are.

There are simply working 4k HDR HEVC files (not just one... more, much...) and there are simply not working 4k HDR HEVC files (not just one, more, much). I simply could not determine yet that important difference what could be the reason of the problem.
4k SDR files are all working (yet).

The problem is clearly visible as other persons also wrote. Max 1-2 frame per sec. playing performance, and overloaded Kodi sometimes with really frozen Kodi or Chromecast. Seems absolutely overloaded clearly CPU based rendering, but this is just what I see.

Hope this is clear now.

Thanks again...

Jep. In any way: We (in kodi) won't be able to fix that. As it's the "black box" path MediaCodec Surface. If it works, it works, else not :-) ...


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - noggin - 2021-01-13

(2021-01-13, 18:06)fritsch Wrote: Jep. In any way: We (in kodi) won't be able to fix that. As it's the "black box" path MediaCodec Surface. If it works, it works, else not :-) ...

In other words - you send the compressed video to MediaCodec Surface and leave Google's Android TV implementation to handle hardware accelerated decode and output rendering for the display resolution, colour gamut and dynamic range (so Android TV handles Rec 2020->Rec 709 gamut conversion, HDR->SDR conversion, and down conversion from 2160p/4K to 1080p/720p)?

Kodi just sends MPEG2/h.264/h.265 compressed video to Google's Android TV black-box implementation of MediaCodec Surface?


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - Tamas.Toth.ebola - 2021-01-13

(2021-01-13, 18:06)fritsch Wrote:
(2021-01-13, 14:49)Tamas.Toth.ebola Wrote:
(2021-01-13, 13:34)fritsch Wrote: Thanks. Runs fine on my FireTV Cube. Will test and check on chromecast at the end of the week.

Edit: From your log I have seen, that you scale down to 1080p. Do we already know if it works fine if output at 4K? Perhaps someone else in that thread could test that - cause my chromecast is only connected to a 1080p TV as well.

Yes, you saw it right. As I wrote before sadly my current TV is just an old Samsung - 55D7000 [1080p SDR] TV, what should be really upgraded in this yearSmile Therefore I simply can can not check what is the result with 4k TV. The other 'problem' of course is the SDR. While the TV is SDR the video itself is HDR. Both of these 2 differences mentioned before to make the situation clear. So in the corresponding process line there is one 'forced' downscaling and also (if it possible) one tonemapping (or any other like dynamic compression).

The interested side of it that 4k 8bit files works fine (so could be the forced HDR>SDR conversion the reason of the overload), as there is also downscaling without problems, and seems that there is no real HDR>SDR conversion as the result is color off picture with very high dark levels.
But what is really confirm that not the HDR>SDR conversion is the reason that other 4k HDR files works. Not all but there are.

There are simply working 4k HDR HEVC files (not just one... more, much...) and there are simply not working 4k HDR HEVC files (not just one, more, much). I simply could not determine yet that important difference what could be the reason of the problem.
4k SDR files are all working (yet).

The problem is clearly visible as other persons also wrote. Max 1-2 frame per sec. playing performance, and overloaded Kodi sometimes with really frozen Kodi or Chromecast. Seems absolutely overloaded clearly CPU based rendering, but this is just what I see.

Hope this is clear now.

Thanks again...

Jep. In any way: We (in kodi) won't be able to fix that. As it's the "black box" path MediaCodec Surface. If it works, it works, else not :-) ...
In this case when we use the integrated cast functionality of GCGTV that way uses a different approach to render videos? As with classic chromecasting, the same 'problematic' videos are totally fine. The same GCGTV render problemlessly the same video what is problematic with Kodi. I'm not criticizing, please do not misundertand. Just showing the facts what I experienced. If you could not fix it, no problem. It was just a try.


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-13

Classic Chromecasting is a totally different technology. Especially towards "whom" decodes ...

What does VLC do on your device?
In kodi you can disable Mediacodec Surface (just the Surface part) then we scale it - but most likely the device is too slow for EGL import, scale and rendering again.

Edit: Did you post the adb logcat somewhere already? Perhaps the stick itself tells something what it does not like.


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - madmax2 - 2021-01-14

Can someone tell how well this plays local files from SMB share via ethernet/wifi and that is 4K HEVC 10bit / 8 bit  and with HDR/without HDR?


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - noggin - 2021-01-14

(2021-01-14, 09:06)madmax2 Wrote: Can someone tell how well this plays local files from SMB share via ethernet/wifi and that is 4K HEVC 10bit / 8 bit  and with HDR/without HDR?

Are you playing them on a 4K HDR display, a 4K SDR display or a 1080p or less SDR display?


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - vysygota - 2021-01-15

Hi guys, could you tell me if this device is able to decode dts-hd, dolby true hd with smooth playback? I have 4k hevc movies with dolby true hd and dts-hd audio and I'm wondering if it will be able to downmix it to two channels for example.


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - noggin - 2021-01-15

(2021-01-15, 00:40)vysygota Wrote: Hi guys, could you tell me if this device is able to decode dts-hd, dolby true hd with smooth playback? I have 4k hevc movies with dolby true hd and dts-hd audio and I'm wondering if it will be able to downmix it to two channels for example.

Decoding of Dolby True HD and DTS HD MA/HRA (along with DD, DD+ and DTS) and down mixing to PCM 2.0 is possible and is what happens when a Chromecast with Google TV is plugged directly into a PCM 2.0-only TV  (HD Audio decode and downmix  functionality is built into Kodi, not relying on underlying OS stuff, and the Chromecast with Google TV offers PCM 2.0 output as that is the only format that many TVs will accept).  

Bit streamed output of those HD Audio Codecs for external AVR decoding isn't possible on this device AIUI, but it doesn't sound like you want that.


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - vysygota - 2021-01-15

(2021-01-15, 10:36)noggin Wrote: Decoding of Dolby True HD and DTS HD MA/HRA (along with DD, DD+ and DTS) and down mixing to PCM 2.0 is possible and is what happens when a Chromecast with Google TV is plugged directly into a PCM 2.0-only TV  (HD Audio decode and downmix  functionality is built into Kodi, not relying on underlying OS stuff, and the Chromecast with Google TV offers PCM 2.0 output as that is the only format that many TVs will accept).  

Bit streamed output of those HD Audio Codecs for external AVR decoding isn't possible on this device AIUI, but it doesn't sound like you want that.
yup, thanks for you detailed answer.


RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - Tamas.Toth.ebola - 2021-01-16

(2021-01-13, 21:00)fritsch Wrote: Classic Chromecasting is a totally different technology. Especially towards "whom" decodes ...

What does VLC do on your device?
In kodi you can disable Mediacodec Surface (just the Surface part) then we scale it - but most likely the device is too slow for EGL import, scale and rendering again.

Edit: Did you post the adb logcat somewhere already? Perhaps the stick itself tells something what it does not like.

As a new weekend I had some time for it again with these reports:

- Kodi with 'Media Surface' 'off' seems play the file. Not sure that absolutely fine but seems play. Purple D+ logo still purple instead of blue but at least we got continuous playback.
- With Chromecast casting D+ logo also purple but plays fine.
- With default VLC settings the problem is the same as with Kodi.
  Default settings: HW acc.: automatic; Color format: RGB 16bit; OpenGL ES: Automatic; (there were something forth relevant settings but I simply forgot and already uninstalled VLCSad)
  Changes on any those attributes (forced HW acc.; YUV color; etc...) not help except the OpenGL ES. With forced 'on' of OpenGL ES the video works (while it does not warn but need to restart VLC). (Not sure that on the same way as Kodi does with 'Media Surface' 'off'.) D+ logo still purple but the video playback seems continuous.

My theory still is because some header difference in the file the result is SW rendered instead of HW. The mentioned OpenGL ES difference is not yet understandable by me.

Seems all 10bit D+ files have the same problematic results. Mediainfo of the video streams is the following:

Code:

Video
ID                                       : 1
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L5@Main
Codec ID                                 : V_MPEGH/ISO/HEVC
Duration                                 : 31 min 44 s
Bit rate                                 : 21.2 Mb/s
Width                                    : 3 840 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 16:9
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.107
Stream size                              : 4.71 GiB (95%)
Writing library                          : x265 3.4:[Linux][GCC 7.5.0][64 bit] 10bit
Encoding settings                        : cpuid=1111039 / frame-threads=1 / 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=50 / high-tier=0 / uhd-bd=0 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=48 / keyint=48 / gop-lookahead=0 / bframes=2 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=48 / lookahead-slices=8 / scenecut=0 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=32 / min-cu-size=8 / no-rect / no-amp / max-tu-size=16 / tu-inter-depth=2 / tu-intra-depth=2 / limit-tu=0 / rdoq-level=1 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=44 / 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 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=1 / psy-rd=1.60 / psy-rdoq=5.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=23000 / qcomp=0.75 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=25000 / vbv-bufsize=25000 / vbv-init=0.9 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / no-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=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.00 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-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
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.2020
Transfer characteristics                 : PQ
Matrix coefficients                      : BT.2020 non-constant

What your opinion @fritsch ?