+- 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)
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - noggin - 2021-01-01
(2021-01-01, 11:18)fritsch Wrote: No. Stereo is still sent as float. Only multi channel sources are sent as 16 bit as this is what for now all multi channel capable devices support.
I will enable multi channel float again after v20 is branched. 24 bit is a pain on its own, depending on how it is tunneled in 32 bit.
Got you - thanks for the clarification.
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-01
Btw. I did not find any API to output 24 bit or even 32 bit integer with audiotrack. Do I overlook something?
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - noggin - 2021-01-01
(2021-01-01, 18:22)fritsch Wrote: Btw. I did not find any API to output 24 bit or even 32 bit integer with audiotrack. Do I overlook something?If you're referring to my API references in my previous post - it was to do with them not supporting 32 bit float output properly as multichannel 16-bit or 24-bit PCM (i.e. fixed).
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-01
From my understanding. The intermediate format in Android itself since v23 or even v22 is float. That means the sound server itself is converting everything to that anyways. As it has to mix probably multiple apps at once. Therefore I highly wonder what they do for multi-channel ... maybe, they don't trust the float values they receive? :-)
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - noggin - 2021-01-01
(2021-01-01, 19:00)fritsch Wrote: From my understanding. The intermediate format in Android itself since v23 or even v22 is float. That means the sound server itself is converting everything to that anyways. As it has to mix probably multiple apps at once. Therefore I highly wonder what they do for multi-channel ... maybe, they don't trust the float values they receive? :-)It does feel as if they are living in a pre-eARC, pre-HDMI audio world where there were only 1.5Mbs audio pathways for 48/16 PCM 2.0 max, or DD/DTS/DD+ at SPDIF bitrates...
If they want to do a TV platform, they need to do it properly.
1. Handle multiple refresh rate outputs sensibly.
2. Handle multichannel audio sensibly. (HD Audio is an issue as there is still no official route for this content to hit a Chromecast with Google TV - but AAC 5.1, FLAC 5.1 etc. is all legitimately out there)
3. Handle SDR/HDR10/HLG/DV and Rec 709/Rec 2020 sensibly.
None of this is easy - but it is possible... (Apple have a better handle on this in tvOS it seems)
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-01
And to add: These things can be solved once and for all and forever ...
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - Tamas.Toth.ebola - 2021-01-02
(2020-12-31, 08:46)fritsch Wrote: Does multi-channel work for no one?
Hi!
While my main goal for today originally was the 4k HEVC test between 8bit and 10bit (on 1080p SDR TV) with appropriate logs, I read through the last some posts about audio 'problems' and as I just facing myself something same like situation I did my further test on that question circle.
Here are my 'deep' (never could be deep enough
) test reports on this 'topic':Until now I used just the stable 18.x Kodi from Play Store on my GCGTV but now I installed your 19.x test build. With the 'old' version if I remember correctly there was no DTS-HD option in passhthrough settings, so I was glad when I saw it in the test build. Also until now I just used 'optimized' output type (never tried the 'best match' and 'fixed' option).
My receiver is Pioneer - SC-1223 with capability of almost all 'normal' formats except Atmos as the device was released at 2013. Limitations in short: Atmos; DTX X; only DSD64; no high-res multichannel from network (but of course capable through HDMI).
One of my reason to start my testings is that when I tried to play one 4 channel 24/96 MLP file (MLP stream in .MKA container) I got just stereo output nothing more. Of course from network stream I did not expect proper result as the receiver could not handle multichannel high-res streams, but with Kodi the file is directly decoded by Kodi so I absolutely expected 4 channel high-res PCM audio. This was my main reason but have some other interesting things. With DTS XYZ audio streams (HD MA, HD HRA) I got just got normal DTS results in the past. As I known (from multiple sources) that GCGTV could not handle high-res audio passthrough I though it was normal. BUT #1 now!!! with the test build and with DTS-HD passthrough enabled I get DTS-HD HRA on my receiver what I could never yet. This is really glad news for me (however just in theory as I have no DTS-HD HRA data sources except my test files
). BUT #2 now, with test build where I got normal DTS results with originally DTS-HD MA audio streams with 'old Kodi' now I getting simply no audio. Thinking-thinking. Ok, I realized that I switched my output config from 'optimized' to 'best match', so check it again:- With 'best match' I get no audio with only DTS-HD MA streams but get DTS-HD HRA result (what I could not get in the past) with the corresponding stream
- One interesting thing here: if I tried to play DTS-HD MA audio stream from an only audio file (from .MKA or directly as a .DTS file) I got normal DTS result. But if the same DTS-HD MA audio stream is in a video file I got no audio. Don't really understand as it seems that there should be some stream identification errors or so.
- With 'optimized' I get normal DTS result with DTS-HD MA streams and get also DTS-HD HRA result (what I could not get in the past) with the corresponding stream
After the above also tried the same with 'Android output layer' (or whatever it's name) instead of 'Kodi output layer'. With this config I get normal DTS results with any type of DTS-HD audio streams. Could not get DTS-HD MA, or DTS-HD HRA. The result is something like I got with 'old Kodi'.
At this point I was happy as I could get DTS-HD HRA what I simply could not in the past, but not yet DTS-HD MA (although never got).
Let's check the other formats mainly what was my main reason. With my 4 channel 24/96 MLP audio stream (enclosured into .MKA container) I just get also stereo results so there is no changes compared to 'old Kodi'. This is interesting for me.
At this point - as I thought the reason of the problem could be the MLP stream itself - I downloaded some sample high-res multichannel FLAC files, to check the results. With the test build I simply could not get any sound with 24/96 5.1 FLAC files
. There is no problem with the stereo files, 384kHz still fine but just if only 2 channel. So:- Mulichannel 24/96 MLP give just stereo sound
- while multichannel 24/96 FLAC give me no sound.
All these last tests made with 'best match' output settings.
With 'fixed' output settings I get simply no sound. Never. With any type of settings. I don't know why.
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-02
With the nightlies from after yesterday, all multi channel should work again for you: given that there is a proper device connected via hdmi that can consume it. Means: ARC won't work, but direct connection to an AVR.
For dts hd ma, it's clear sadly. Firmware limitation, you can see that nicely that this codec is also only doing dts when played via the system RAW sink (kodi v19 RAW or setting).
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-03
We tested internally the playback of 4K HEVC 10 bit files and actually of them were working, including the 59.94p version.
Could you please post a mediainfo from a file that does not work, please?
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - colinjones - 2021-01-03
(2020-09-30, 20:20)RockerC Wrote: This new "Google TV" UI is all about content aggregation. Project lead said "Think of Google TV as your personal TV curation" during her presentation Google TV.
Hi all - does anyone know if it's possible for Kodi to "push" content into the GCWGTV content aggregation API, so it can be surfaced on the home screen like with other apps? Maybe an add in, or perhaps something the Devs might consider for the future?
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-03
Best is: implement it yourself. We have run out of _all_ Android developers, therefore external contributions are the best bet to get it implemented.
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - Tamas.Toth.ebola - 2021-01-04
(2021-01-02, 19:15)fritsch Wrote: With the nightlies from after yesterday, all multi channel should work again for you: given that there is a proper device connected via hdmi that can consume it. Means: ARC won't work, but direct connection to an AVR.
For dts hd ma, it's clear sadly. Firmware limitation, you can see that nicely that this codec is also only doing dts when played via the system RAW sink (kodi v19 RAW or setting).
Dear @fritsch !
My previous (2021-01-02, 16:56) post was a little bit unfinished, rough-and-ready as my family had started to 'hit' my back to skip my test processes and play some family games or watch some family movies instead of that. But later I start again my tests to give you the proper quality test results what I previously planned. Meanwhile (before the tests) I installed the - then hot-fresh - 'kodi-20210102-a71d8ffe-master-armeabi-v7a.apk', as you wrote the new nightly builds got back the abilities to play multi channel audios.
Check below my really properly detailed test results where I defined where could I find interesting, or maybe wrong results (you can comment it if you want as I do it also at some place):
https://docs.google.com/spreadsheets/d/1dTq7qbeCD_090u2UTPNOrL0fCySALZE9vxG_PZsZ49c/edit?usp=sharing
The table clearly shows the practical capabilities of current Kodi on GCGTV.
As summarize I could tell you the followings:
1. Kodi does not always 'force' proper input changes when we use it. I simply could not catch the problematic pattern, but while I made my test (for really 'lot' of hours), there were be more cases when after I changed Kodi settings it did not changed the receiver's 'input source'. I needed to switch back and forth sometimes the channel settings and 2-3 tries later I got correct result. There were such cases also when only the exit of Kodi and restart it was the only successful process to 'apply my new settings'. This is really a stable experience. The only 100% sure way to switch Kodi's audio mode is to restart it. It reality we just need in the 15-20% of the situations but for 100% result easier to exit and restart as investigate that the result is really fine or not. This is not a real problem in practice but a constant experience during my tests.
2. In the table I show the problems with 3 color mode.
a. Thin orange is basically working results but not 100% what we expect in theory (But of course you already wrote that the DTS-HD MA passthrough is impossible yet. Anyway is this really the mentioned GCGTV firmware bug as if I read somewhere that HD audio passthrough is basically HW impossible with this AmLogic chipset... (but hey, DTS-HD HRA is working now what is very good news as this is also multichannel HD stream even already losslessly compressed yet)).
b. Thin red is such problem what really problem but not the problem of Kodi
c. Bold red is what from my aspect is really a problem and really unexpected for me
3. And the last thing is a little bit complex as maybe relevant to instable input switching background or to the bold red results:
a. If we want multichannel audio the best bet is the 'fixed 5.1' audio mode (without passthrough) where we also need to manually limit the sampling rate to 48kHz as every higher options just give me simply 'no sound'. I thought that 96-192kHz stereo streams will work fine here but in practice not. If we choose 5.1, I need to limit the sampling rate to 48kHz to get any type of audio. But the result from this point is constant. Almost everything works but of course as lo-res audio.
b. If we want high-res audio the best bet is 'fixed 2.0/2.1' audio mode (without passthrough) where we will never get multichannel of course but will get really high-res results without problems.
c. Sadly I don't remember where is less the stuttering if there is (but there is a clear winner
). If Kodi needs to downsample the high-res 5.1 streams to 48kHz, or when Kodi needs to downmix the high-res 5.1 streams to 2.0?!...d. Seems that high-res multichannel streams works interestingly if we do not use 'fixed' audio output. 4.0 and 4.1 high-res streams played as stereo streams what somewhere I expected if we need to accept that no nigh-res multichannel now. But 5.1 give constant no sound what is really unexpected. At this point you can see that if the corresponding DTS stream is high-res stream (DTS-HD MA 24/96 or HDS-HD HRA) we get also no sound as with the other higher then 4.1 channel high-res streams.
So I'm happy to get DTS-HD HRA working while sad that could not get DTS-HD MA. I'm also happy to get 24/96 or higher 4.0, 4.1, 5.1 MLP, DSD, FLAC playable but sad that those are just works with passthrough off while would be better to use the receiver's own capabilities where we can.
I hope you can really use my experiences.
(Also tried with this build the 10bit 4k HEVC and the result is still GCGTV 'eater' slow and overloaded result but as the audio tests above 'stole' my time I need to ask your patience to next weekend to test that with proper logs.)
Continuously thanks for your efforts in advance, and wish a Happy New Year in retrospect as I forgot wrote in my speedy last post
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-04
Sorry I don't read such amount of text I simply don't have the time doing so.
Therefore, please use a "tl;dr:" summary.
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - fritsch - 2021-01-10
1.) Dependend on setting Optimized or Best Match kodi won't change anything. Reason: If you are in the menues and outputting 2 channel 44.1 khz to the AVR, nothing will change neither if you change the speaker number nor something else. It will change for Fixed (e.g. 2.0 to 5.1, but also only in the case you are not currently on 5.1 which was set by optmized), also toggeling stereo mix up will change the output, but also only if it was not change by Optimized before. Why does Optimized exist? If you think of LiveTV, you watch a movie which is 5.1 and then it switches to commercials, but commercials are only 2.0 - this will reconfigure audio, some samples are lost, you could hear it, that's why the Optimized keeps a "more is better" policy, if it eg. changes from 2.0 midstream or after audio change in music playllist to 5.1, it will stay there to give the user a seamless experience. For Best-Match it will change for every input change to the best matching input. So if you change from a 5.1 flac title to a 2.0 stereo title, it will change - while it would stay on 5.1 (with SL,SR,FC,FL reciving zeros).
2.) I linked the pdf somewhere and can see there enough "bandwidth" possibilities to get dts-hd, truehd working. Also similar chipsets running Linux with amlogic do work, right? DTS-HRA is a nice example for this: As it is transmitted via 2 channels and 192 khz (one does not talk about channels really in bitstream passthrough, it's rather a bandwidth thing: 2 * 16 bit * 192 khz == bandwidth needed to transfer DTS-HD-HR, for DTS you might need: 2 * 16 bit * 48 khz and so on, EAC3 192 khz again for the 7.1 version). Limitation here: 8 channel IEC format support, which e.g. the shield has. Btw. I sent the spec and the request for 8 channel IEC to my Android Audio contact. As I pinged him twice already I don't really feel to ping him again :-). But - hey - if you read this here: How about the 8 channel IEC change?
3.) I think I have fixed that in the nightlies, while reducing the 32 bit format to 16 bit. Could you retry a v19 nightly build for that?
Best regards
Edit: One minor I have forgotten: Kodi only acts for itself! It creates new AudioTrack Sink and a proper stream for it. IF Android system decides otherwise (e.g. to downmix, resample, whatever, ..) - we have no possibility to change that for PCM output, while passthrough is exclusiv and the system has to care.
RE: "Google Chromecast with Google TV" dongle with a new "Google TV" ecosystem and UI - Tamas.Toth.ebola - 2021-01-12
(2021-01-03, 01:11)fritsch Wrote: We tested internally the playback of 4K HEVC 10 bit files and actually of them were working, including the 59.94p version.
Could you please post a mediainfo from a file that does not work, please?
As I promised, here are all required informations:
https://drive.google.com/drive/folders/1VrJn2lhn5p_QqHgECkzVnIH5XtzLICuA?usp=sharing
- There are 2 precisely cutted log records about playing with Kodi the problem less 8bit and the problematic 10bit files,
- and 2 small slices from those corresponding videos, witch are more than enough for testing, as with ~1 frame per sec performance the problem could be realized immediately. (The colors are 'misaligned' (purple like background behind the 'D' logo, instead of the original blue and 'of course' too high dark levels (I mean 'of course' without without dynamic compression)), but those are the next and less annoying things...)
Over on these I really can confirm that there are 10bit HEVC files what are truly working! But there are such - problematic - files also. Not just one, more, much, and they are problemless with other 'player solutions'... Sadly I could not determine yet what is the relevant difference (basic color space/gamut informations is only 'TV' on working files and 'TV, BT.2020...' on the problematic but don't think this could be the source of the problem) why Kodi seems to play the problematic files with SW decoding instead of HW.
Hope it could help you, and of course for us also.
Lot of thanks in advance!