Posts by noggin

  • LibreELEC (Leia) 9.2 ALPHA1 with Raspberry Pi 4B Support

    Quote from milhouse

    Just trying to rule out possible causes in an effort to identify what is happening.

    As it happens, there should be a fix for the "washed out" videos in the next release as MMAL required some extra support for the Rec2020 colour space that had been omitted. It would still be very nice if someone could upload a test sample or provide a link to a file that demonstrates the problem so we can fix it at the first attempt.

    Also, stuttering issues with interlaced videos should be fixed in the next release.

    I got my 4GB 4B last night. First boots of both Raspbian and the LibreElec Alpha from the downloads page with my UHD TV connected to HDMI 1 didn't go well, and LibreElec TV ran in 4096x2160p mode with very odd level space (and odd pulsing audio). Disconnected and using HDMI 0 (a tight fit with a Micro HDMI->HDMI adaptor and the USB-C power connector) it worked OK, starting up in 4096x2160/24p but with correct levels.

    2160p60 output is RGB 8-bit currently on my set-up.

    I'll upload some Rec 2020 HLG and HDR10 content once I've tested it. SDR Rec 2020 is pretty rare - I'm not sure I have any. HLG Rec 2020 is backwards compatible with SDR Rec 2020 though - the highlights just look a bit different because of the HLG EOTF differing from BT.1886 once you get past about 75%.

    BTW - other observations. Interlaced 1080i h.264 is very juddery, and 5.1 FLAC is output 2.0 (even with 5.1 configured) Totally understand this is a very early alpha - and not complaining!

    *** EDIT : Watching some 2160p59.94 10-bit HEVC SDR Rec 709 content, played from a locally connected USB 3.0 ExFAT drive, I'm seeing hundreds of dropped frames too *** I'll message you with a DropBox link to some test content.

  • LibreELEC (Leia) 9.2 ALPHA1 with Raspberry Pi 4B Support

    Quote from milhouse

    documentation/hdmi-config.md at master · raspberrypi/documentation · GitHub

    In /flash/config.txt, add the following to enable 4Kp60 support:

    Code
    hdmi_enable_4k=1

    HDR metadata should be ignored for now, so if your display looks washed out try toggling Settings > System > Display > Use limited colour rage (16-235).

    Why would 0-255 or 16-235 be an issue for Rec 2020 HDR10 output flagged as Rec 709 SDR?

    Wouldn't you be better forcing your TV into Rec2020 and HDR10 mode? (My Sony lets you do this in its video settings)

    This won't help cope with the different Rec 709 vs Rec 2020 RGB<->YCrCb matrix (so if any RGB processing takes place it will be a bit out), but will use the required EOTF for HDR10 (i.e. use the right dynamic range) and will switch to Rec 2020 primaries (so that the colours are in the correct gamut) assuming the Pi 4B LibreElec is just treating HDR Rec 2020 stuff as if it is Rec 709 SDR (and not trying to do any gamut or EOTF conversion)

    Or are you saying that the UHD HDR 16-235 content is flagged 0-255 permanently?

  • LibreELEC (Leia) 9.2 ALPHA1 with Raspberry Pi 4B Support

    Quote from muppet007

    Hi all,

    I installed this release on my PI4 2gb and and have a few questions.

    I can play 4K HEVC files fine but as all of them are HDR which isn't supported yet will this result in incorrect playback? They seem to be washed-out and lacking colour but this could be in my mind.

    The maximum refresh rate I can get is 30. In 1080p I can get 60. Is this likely to be down to the HDMI cable I'm using? I seem to remember I had this with my laptop and had to buy a quality cable. I'm using a micro to full size adaptor which I think might be limiting things.

    Thanks in advance for any help.

    If HDR10 HDR with a Rec 2020 gamut content (i.e. UHD Blu-ray material) is played as if it is SDR Rec 709 it will look very washed out as the colour primaries and 'gamma' (for want of a better word) are very different and unless a tone mapping conversion is taking place it will look terrible. You may find you can force your TV into HDR10 and Rec 2020 but this still may not make things 100% correct (as the RGB<->YCrCb matrices for 709 and 2020 are different)

  • LibreELEC (Leia) 9.2 ALPHA1 with Raspberry Pi 4B Support

    Quote from chewitt

    I'm told Atmos should be okay. If you aren't using pass-through you'll only get the DTS core (5.1) anyway and if it is being passed through it's not being decoded and thus a license isn't needed. Or something like that .. IANAL :)

    Don't you mean you'll get either a lossy Dolby Digital accompanying secondary stream (if DD passthrough is enabled but True HD disabled) or Dolby True HD decoded to 5.1PCM (if all passthrough disabled and thus lossless decode - ignoring Atmos extensions - kicks in? ISTR that most True HD + Atmos has a 5.1 True HD core?)

    Not sure where DTS comes from (And True HD technically isn't a DD core + True HD extension is it? Unlike DTS + DTS HD MA - True HD is self contained and there is usually a secondary DD standalone stream - though this is sometimes hidden from view on discs)

  • LibreELEC (Leia) 9.2 ALPHA1 with Raspberry Pi 4B Support

    Quote from cheungie

    Does Dolby Vision also involves metadata passthrough as well?

    DV requires metadata passthrough - and there are different ways of doing this (early DV tunnelled the metadata within the video, which requires displays to extract the DV metadata from the video) Not all displays support all metadata routes (more recent displays only support the low latency DV system that carries metadata separately, I believe similarly to HDR10+?).

    In fact DV's main reason for existence is to pass Dolby metadata through the viewing chain to Dolby licensed processing elements.

  • LibreELEC (Leia) 9.2 ALPHA1 with Raspberry Pi 4B Support

    Quote from Monie

    I understand it has hardware decoding for HEVC content but what about 10 bit? Will it smoothly run 1080 and 4K x265 10 bit content?

    The HEVC/h.265 decode hardware is quoted as supporting 4:4:4 4096x4096 at 10-bit in specs I've seen reported elsewhere.

    That should be fine for 3840x2160 4:2:0 10-bit consumer HEVC/h.265 as used on UHD Blu-ray etc. in decode terms.

    (I don't think anyone would seriously now offer 8-bit limited UHD HEVC/h.265 decoding)

  • My Libreelec is not capable of Dolby Digital Plus DD+ passthrough on Raspberry!

    Quote from novalis

    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. :idea:

    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.

  • Hyperion boblight and rockchip 3399 Rock Pi 4

    Quote from antaril

    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?

  • RockPi4 support?

    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.

  • XBOX One DVB Tuner and LibreElec 8.1.1 ?

    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.

  • XBOX One DVB Tuner and LibreElec 8.1.1 ?

    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.)

  • Choosing a S905 / S905X / S905D / S905W / S912 box guide

    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)

  • Information Regarding Linux on Rockchip SoC's

    Quote from Kwiboo

    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)?