I'd just like to know. Is it possible to get a definite answer to this question? Or is it a secret? So far I don't get it running with my AVR. But maybe I'm doing something wrong.
It works with Windows though.
Light please.
Kodi supports DD+ passthrough, so LibreElec support will depend on the hardware support in the surrounding Linux ecosystem that LibreElec uses, which means it's based on the hardware platform you are running.
Yes, thats a good idea, i will try to do handle all videos with software and report back!
The RK3399 has quite a powerful CPU - it may do quite well with h.264 stuff up to 1080p?
If i use Netflix, Hyperion works very good!!! Just the upper Led line doesnt work
But why not live tv and films??
Boblight does the same... it works in Netflix, but not in film and tv. But Boblight uses all Led´s
I'm not a Hyperion user - but Netflix will be using software decoding (where the CPU has access to all the decoded video as standard), whereas regular movie and TV watching will be using hardware decoding (where code will need to find a way of accessing the decoded video to analyse it's average colour for external LED control)
My guess is that this is hw vs sw decode related at the moment?
Netherlands is using 1080p50 HEVC/h.265 via DVB-T2 now isn't it, like Germany?
That may be pushing the Pi a bit too hard? How does the latest HEVC optimisation cope with 1080p50?
DIGITALBITRATE : Digital channels bitrate Satellite, Dtt and more - DTT NEDERLAND HEERENVEEN - rts-bouquet1-drenthe suggests that NPO1-3 are indeed 1080p50 (not 1080i25) HEVC
Display MoreWhats the performance like then ? Comparing to say the PI ?
Does it handle 4K ?
VOB (Mpeg 2) ok ?
Normal Dobly Passthrough ok ?
Gapless Flac and Mp3 ok ?
How about photo display ? 20MP photos are they snappy ?
These are reports from Rock64/RockPro64 but should be valid.
4K yes - HDR10 and HLG are played back with the correct EOTF flags (so trigger HDR modes on TVs) but HDR10 mastering and MaxCLL/FALL metadata isn't currently passed.
VOB seems to be OK. (Including interlaced content)
DD / DTS SPDIF-quality passthrough may work depending on your AVR. It may not be being sent fully correctly - but my AVR copes with it.
Dolby True HD/DTS HD (including Atmos and DTS:x) doesn't bitstream. Decoding the non-Atmos/DTS:x stuff to PCM 5.1/7.1 is an option and works OK.
Should also add that 1080i h.264 Live TV is deinterlaced OK, and 1080i25 Blu-Ray rips of European TV series play OK too.
OK - my Australian geography sucks - but if you are in Mid North Coast it looks, at first glance, as if you are quite a long way from Sydney? Australia does use VHF - which 'goes further' than UHF - as well as UHF - but I'm used to coverage areas being in the <80 km radius even for high power transmitters)
The fact that you only have one successfully scanned Mux (OK) and the others haven't successfully scanned (FAIL) suggests one of three things :
1. You have the wrong frequencies and just hit one that was right by good luck.
2. You have a terrible signal (but if the aerial/antenna feed that you are feeding your tuner works fine with a regular TV that's unlikely)
3. Your tuner is lousy. (The X Box One isn't the world's best, but for DVB-T I'd expect it to be OK)
The key thing is to find out the frequencies of the TV transmitter that serves your area. Add muxes on those frequencies manually, and you may have more luck.
You add muxes in the Configuration->DVB Inputs->Muxes tab - where there are ADD, DELETE and EDIT options. If you have one MUX that works, then editing that and Creating rather than Applying will save the edited version as a new mux (very useful for quickly adding a bunch of frequencies with the same DVB-T parameters)
Australia uses 7MHz Bandwidth according to the ACMA site, and I'd expect 8K carriers. You'll probably find you can leave the other details on AUTO. (But, if not, 64QAM is a good bet )
mySwitch looks to be a useful Australian TV frequency/coverage checker site. Enter your post code/zip code and it will tell you your coverage. HOWEVER if you look below where it says the level of coverage there is a little link called 'Channels for...' (which tells you which channels you should receive) - if you click on that it not only tells you the channels but also returns the frequencies for each multiplex (i.e. the frequencie each group of channels is broadcast on)
I chose a random 'Mid North Coast' town - Port Macquarie - and entered it in the my switch coverage checker. It suggests the Manning River location for this served by the Middle Brother main TV transmitter with the following frequencies :
184.5MHz for the ABC channels
177.5MHz for the SBS channels
191.5MHz for the Prime (aka Seven?) channels
226.5MHz for the NBN channels
219.5MHz for the Southern Cross channels
Those are all VHF channels (Australia uses VHF massively - whereas those of us in Europe often have mainly UHF services. In the UK we have no TV in VHF, whereas in places like Sweden you may have just one of the 6 or 7 muxes in VHF)
Obviously you may well be somewhere very different on the Mid North Coast - so don't take those numbers as correct.
tvradio_handbook_electronic_edition-pdf.pdf?la=en is a comprehensive list of TV transmitter frequencies by region etc. which may help you find your frequencies if you know the name of your local transmitter. It also tells you the broadcast power of each transmitter - as they vary massively depending on whether they are 'main' transmitters or just little local fill-in transmitters to fill a small coverage gap.
Also if you know the official call sign of your TV stations (i.e. ABC7, SBS6) then the number at the end of the call sign is the RF channel of the station you are trying to receive. You can map the RF channel number to a frequency with the table on p. 403. However it is possible Australia, like other countries, uses small +ve or -ve offsets (125kHz I think) so you are better advised to use the actual frequencies if you can find them.
Display MoreOk, I have Tvheadend setup!
I am only receiving 7 channels however - none of which I watch either.
???
nb. I am using the cable from the tv which receives over 20 channels.
I put in a power booster for the cable - no difference!
Re-scanning channels brings nothing new.
How do I trouble shoot this?
Should I try Mythtv instead?
What is your country and city?
What is your TV Platform (antenna/aerial/DVB-T/T2 or cable/DVB-C)?
Do you know the frequencies of the multiplexes you want to tune - or does your TV provider have a website with 'type in your postcode to find out your frequencies'?
I usually end up adding each mux manually rather than using a pre-populated list as sometimes the pre-populated lists are out of date.
Remember that TV Headend doesn't 'scan for channels' like a TV does. It doesn't check every frequency in turn. Instead it tunes the frequencies it is told to in the multiplex list. If tunes to a multiplex and successfully discovers services AND if the TV providers co-operate (or the platform is run by a single operator) the DVB stream may contain data about other frequencies to tune in your area and it may add more muxes. However this isn't always the case.
If you can't find out your mux frequency details - then if you install the DVB Tools add-on and can SSH into your machine you may be able to do a full band scan to find out the frequencies using w_scan or scan. In the UK, Ireland, Sweden, Norway, Estonia, Finland, Denmark, Germany etc. I've never had to do this as I've always found the right details manually (I take a little portable TV Headend and DVB build with me on holiday as I've stayed in hotels with terrible TV services in the past. I can usually get an HDMI feed into the room TV and take it out of hotel mode if the HDMI port is blocked...)
(There is a known bug with the X Box DVB-T/T2 tuner I think that means some frequencies cause it issues.)
Display MoreRe-edited this post again after some testing and tweaking on the RK3399 - developer board ODROID N1:
It depends what priorities a user requires at this point in time for use with the very latest Kodi Leia nightly...
Rockchip - RK3399:
Limitations:
- HDR is not fully supported, limited to only set EOTF in the HDMI infoframe metadata. See noggin 's explanation HERE
- DD+ and DTS-HD MA/HRA, Dolby TrueHD audio passthrough not working, which means no Atmos as well.
- HD audio decoded to 7.1 LPCM, which works well as a workaround.
RK 3399 surprises:
- 1080p 10bit h264 aka Hi10P Anime is hardware decoded
- 1080p video playback is possible when using the Kodi Leia Netflix Addon
Read the most up to date Rockhip discussion info over HERE
Amlogic - S912 & S905(X/D):
Limitations I can think of now when using the very latest nightly Leia (CoreELEC):
- S905 only chipset will never have HDR support
- HDR MaxFALL/MaxCLL metadata not yet send to HDR capable displays from the AML Linux Kernel.
- Only 720p Max. video playback possible when using the Kodi Leia Netflix Addon
- S912 LE / CE Kodi video playback stuttering when using external Subtitles (due to non optimal Libhybris <> Android GPU driver)
- Workaround for that is disabling Kodi Dirty Regions in advancedsettings.xml (easily done.)
I will let chewitt detail developments that will need to be ticked off for LE 10.x / Kodi v19 M going forward for both platforms...
Should add my tests were on Rock64 not RockPro64 - so are based on experience of the RK3328 not the RK3399.
I'll test the RockPro64 next...
**EDIT - RockPro64 seems to behave a little differently. Silence rather than static when playing bitstreamed HD audio - from 1080i sources - into the same AVR - but end result is neither play bistreamed HD stuff. I have only checked TV Blu-rays not movies so far... **EDIT 2 - 24p movies output at 1080p24 behave the same.
Also h.264 50i Blu-Ray content seems to be a bit stuttery with the RK3399, I'd say - at first glance - the RK3328 on the Rock64 was doing better with this content
Same HDR metadata issues observed as with the RK3328 Rock64. 1080i 50Hz native TV recordings are deinterlaced to 50p as per the Rock64 RK3328 and are entirely watchable at first glance (only a few minutes)
The File Manager is useable to do this too - but you have to get your head round the two-panel-structure (I think it's a bit like Midnight Commander in some ways?) For quick updates I always use the SMB network share route.
The CTA-861-G standard states: "The data in Data Bytes 3 – 26 are arranged into groups, as indicated in Table 45 Static Metadata Descriptor Type 1 above. When all of the Data Bytes in a group are set to zero, then the Sink shall interpret the data for that group as unknown." and "For MaxCLL and MaxFALL, this may occur when information about the content light level has not been, or cannot be, provided - for example, content that is rendered or broadcast in real-time, or pre-processed content that was delivered without information about the content light level.", this mean that TVs should support missing metadata, and I expect the result is that no optimization of light levels can be done.
Yes - this is the reason PQ HDR is seen as a bit of a 'non-starter' for broadcast applications - particularly live TV production, and why almost all broadcast HDR is delivered to the viewer using HLG not PQ. (Though in many cases it's produced in SLog)
I'm guessing if you have an HDR PQ ST.2084 signal without light level / mastering metadata the TV behaves in much the same way is it would if you 'forced' HDR10 rendering (as you can with my Sony TV)?
Is your box on a network? It's usually much easier to use a PC or Mac find the LIBRELEC network share that is automatically created on your network, navigate to the UPDATE folder and copy the update file to that folder over the network.
That was next the question I was going to ask you.
In user friendly English can you tell us what a normal 4K HDR user would see visually with LE Rockchip at the moment ?
ie. color, brightness - what more than Max/Average light level may be missing ?
is it the same as Vero 4K or S912 with a HDR supported Kernel for example ?
After a quick check the situation isn't the same as the S905X/D and S912.
The Rockchip Rock64 LE 9.0.0 image I've used isn't sending any HDR metadata - it's just flagging the EOTF.
The AMLogic image I'm using is sending the mastering HDR metadata, but not the Average/Max CLL stuff.
When I send a file with the following metadata :
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0005 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 400 cd/m2The RockChip doesn't send anything other than that the signal has BT.2020 colour primaries and flags a PQ (aka ST.2084) EOTF.
No mastering display (mastering primaries or min.max display luminance) metadata is sent, nor is the MaxCLL or MaxFALL data.
The AMLogic sends the BT.2020 primaries flag, the DCI-P35 D65 mastering primaries, and also the Mastering Display Min and Max Luminance metadata correctly (i.e. tells you what the monitor the colourist was using was calibrated to show them), but doesn't send the MaxCLL or MaxFALL (so you know nothing about the content you are playing other than what settings/performance monitor it was graded on).
The reason we have HDR metadata is to tell a display what to expect from the content in light level range terms, as PQ dictates an absolute relationship between video signals and display light levels on a pixel-by-pixel basis. This allows it to optimise it's approach to tone-mapping out-of-range (i.e. too bright - or possibly too dark?) content. Without it - the display has no idea what to expect from the content and thus how to cope with content that is out of range for it.
This is the downside to PQ - you have to have metadata to get the best quality display of PQ content on a display that can't cope with the full PQ range (and consumer displays are a long way from being able to handle the full PQ 10,000 nits range that can be carried by that EOTF) If stuff isn't mastered above 1,000 nits things get easier - but even then you need MaxCLL/MaxFALL to optimise within this range if your TV can't sustain 1,000 nits.
My understanding is that in practice not carrying the correct mastering and content metadata means your TV, and in particular an HDR projector, won't optimally process and display HDR content that is out of the range of your display - and is more likely to clip details rather than alter the tone mapping to preserve detail.
How the absence of metadata is handled by displays will presumably vary. The Rockchip is definitely in a worse case - as you have no idea at all of the source video range (or even the primary colour volume it was mastered within inside the BT.2020 colour space), nor do you know the min/max levels of the mastering display (below and above which you wouldn't expect valid content?)
hdr.pdf This may not be 100% accurate in all regards - but is worth a read.
The Xbox One Tuner has a Panasonic chipset - which is why it is reported as a Panasonic device. Are the mux frequencies in your muxes list the correct frequencies for your area, and are the DVB-T parameters correct?
I have a couple of them in the UK - and they aren't the most sensitive of tuners and there seems to be a driver bug that means a popular UK frequency doesn't tune at all well.
Just tested the LibreElec 9.0.0 Rock64 release and can confirm the issues I had with 50i h.264 content have been solved so far.
h.264 1080i25 (aka 50i) separate field (early BBC HD Blu-ray releases) and MBAFF (more recently BBC HD Blu-rays and Live TV) all seem to play OK.
50Hz native content is being deinterlaced correctly without field dominance issues.
(DTS HD MA bitstreaming is broken with my Denon AVR, but DTS core and 5.1 PCM are OK. Interesting the DD and DTS bitstreams are being reported as PCM 2.0 not Bitstream via my HD Fury Vertex, so I wonder if not all flags are being set correctly. The Fury won't analyse the audio content - just the metadata)
HDR stuff - ST.2084 PQ stuff flags the EOTF but doesn't flag Max/Average light level metadata (I think this was correctly passed in a previous release?) HLG stuff is correctly flagged with an HLG EOTF (which makes Rockchips the only Kodi devices that do this I think)
RK3328 and RK3399 share same DW-HDMI TX core and can both send Dynamic Range and Mastering InfoFrame with EOTF/MaxFALL/MaxCLL metadata.
Yep - the Rock Chip devices are the first Kodi platforms that I've seen pass an HLG EOTF correctly over HDMI for HLG HDR content too.
the only difference I found was:
Bits/(Pixel*Frame) . the one that played wrong was 0.098 the other which all played fine was 0.099, this led me to try different zoom settings.
That figure is just a measure of how much the source has been compressed.
It's literally the number of bits used to encode each pixel - on average - across the file, which for a given encoder implementation can give you an idea of the relative quality. (For reference - an uncompressed studio master at 8-bit 4:2:2 will have a figure of 16, and 8-bit 4:2:0 of 12. A high quality compressed broadcast master will have a figure of around 4 or 5. DVDs and HD Blu-rays are around 0.5)
It shouldn't have any major impact on the replay of content, particularly when they are so close, if everything else is equal.
thanks for the feedback, the box actually has the s905x2 soc. done some googling on it and everywhere is saying it has Gigabit Ethernet.
Beelink GT1 MINI S905X2 TV Box Ships with a Voice Air Mouse
if not this box, would you have any recommendations. just looking for something that Gigabit Ethernet and future support
The S905X2 is a very different SoC to the S905X.
I don't know if there is any significant support for it in LibreElec yet?
looking for a s905x with 1g LAN. found the Beelink GT1 MINI for 50 euro on aliexpress.looking for other recommendations
thanks
Paul
Don't think the S905X has GigE functionality in the SoC (the S905D does - which is why the Vero switched from the 100Mbs S905X of the Vero 4K to the S905D for the Vero 4K+ to add GigE)
If an S905X device is being sold with GigE it's either using an on-board USB2.0->GigE adaptor (with ~300Mbs max throughput) or it's a mistake in the specs...
