Posts by noggin

  • RPi Deinterlacer testbuild

    Quote from HiassofT

    For 4kp50/60 yes, but 4kp30 and below will use 12bit RGB 4:4:4 if supported by the TV.

    So lots of 10-bit videos (eg 4kp24 or 1080p) now can have 50% higher clocks than before.

    so long,

    Hias

    And that higher clock rate can sometimes expose things that you really don't expect to cause problems - like HDMI Cables that can't cope with the increased bandwidth.

    When I installed players that output 4:2:2 2160p50/p59.94 12-bit YCbCr output a couple of my HDMI cables just wouldn't support it, and my TV would fail to display anything (and report no signal or invalid signal). Swapping them out for higher (electrical) quality cables solved the problem. Normally you wouldn't suspect HDMI cables - they usually 'just work' - but the move to higher bandwidth signals does expose limitations in the electrical quality of the cables.

    NB by higher electrical quality cables I don't mean expensive 'Monster' or similar cables, just cables that are certified 'HDMI Premium' with the hologram. They aren't expensive, but are certified to pass the higher bandwidth HDMI 2.0 signals that are required for UHD HDR at all bit depths, frame rates and colour formats...

  • USB Failure Odroid N2+

    Quote from msderganc

    Buyer beware - I have two Odroid N2+ units that have failed within a couple months of each other and HardKernel has basically told me that they won't do anything. I would have to pay shipping both ways (nearly the cost of a new unit) to MAYBE get a replacement. I've never experienced such bad service.

    Out of the blue, the USB ports failed on both devices, which were running Libreelec Kodi Matrix. USB Power was turned off within Kodi. One failed after just about a year, and the other after a year and a few months. I can't find too many threads on this topic, so I'm posting this in case anyone is considering one of these units.

    Hard Kernel has a very poor attitude to failures, and a minimal warranty. I would always recommend to buy through an EU or UK reseller if you're in the EU or UK, as you will potentially have better consumer rights that way.

    I've heard a number of stories of terrible customer service once things break.

  • Digibit R1 vs. TBS6909 with TVHEADEND

    Quote from olympia

    One more question (back to one of the original one): is there any cons compared to having a dedicated tuner card like the TBS6909?

    One big pro is that you can run your TV Headend server on a NAS or a small, low-cost ARM SBC like a Raspberry Pi, you don't need to have an x86 PC with a PCI-E slot that will draw a lot more power when on 24/7.

    The only con is that occasionally my DigiBit R1 has needed to be power cycled - but only occasionally.

    You can also run third party firmware on the R1 (Sat Axe) booted from an external USB device, that allows you to have additional configuration options, and to tune some of the DVB-S2 Multistream services that are used to distribute DVB-T/T2 in France and Italy for instance. (That allows you to receive the main French FTA DVB-T terrestrial services like TF1, FR2 etc. without needing to worry about decryption)

  • RPi4 testbuild with HDR support

    Quote from chewitt

    The concept of "pass-through" doesn't exist for video.

    Precisely this - whilst HD Audio can bit bitstreamed/passed-through retaining the source compression, video is always decompressed from a lossy compressed format (h.264/AVC, h.265/HEVC, VC-1, MPEG2, AV1 etc.) to an uncompressed stream of RGB or YCbCr (ignoring Dolby Vision) carried over HDMI (or similar)

    It's the equivalent of MP3 or AAC being decoded to PCM.

    If you didn't decode the video you wouldn't be easily able to overlay a GUI etc. (unless you sent two video streams over HDMI and your TV composited them together)

    When it comes to HDR PQ / HDR HLG / SDR (*) EOTF and Rec 601, Rec 709 and Rec 2020 Gamut signalling, and then static and dynamic EOTF metadata - different codecs will do this in different ways (I think some codecs have multiple options in some cases?), and each will need to be then decoded, and converted into a format that HDMI Infoframes etc. can carry to a display. This is driver specific AIUI - so different HDMI output systems on different platforms will have different ways of doing this?

  • LibreElec 10 + RPI 4 + Astrometa DVB-T2 = does not detect any channels on MUXes working in VHF

    Quote from elonesna

    In relation to the VHF band, I challenge you to tell me the name of a single public TV broadcast that broadcasts in this band in ATSC, DTMB, DVB-T/DVB-T2 and ISDB-T digital format anywhere in the world ( I obviously exclude military and industrial applications). Will not be able!

    I'm afraid you're very mistaken - it's quite easy to document current VHF TV broadcasts...

    Off the top of my head DVB-T/T2 services in VHF are in use in Australia, were introduced in Sweden with DVB-T2 HD, and have also been used in Finland. ATSC in the US uses VHF widely too.

    In Australia VHF Band III is currently used for DVB across large parts of the country (VHF's wider coverage areas make a lot of sense for a large country like Aus).

    As an example here are the frequencies for DVB-T broadcasts in Perth, Australia : https://www.digitalbitrate.com/dtv.php?mux=SB…live=36&lang=en - all 5 DVB-T muxes are in VHF Band III (177.5MHz to 226.5MHz range) , not the UHF Band IV/V frequency range

    In Sweden their DVB-T2 Nät 7 mux is currently carried on Channels 5,6,7 and 8 in VHF Band III in some parts of the country - such as Skellefteå, where Channel 6 is used (Sweden re-introduced VHF Band III broadcasting, previously only used in TV terms for analogue PAL, when they introduced more muxes for DVB-T2 HD services). (For reference - in Europe, any RF channel below C21 is VHF, with the UHF TV Bands IV and V running from 21-69, though >800MHz has been cleared and >700MHz are being cleared in most countries)

    Swedish TV broadcasting authority link here where you'll see a few transmitters using RF channels 5,6,7 and 8 in VHF Band III for their 7th mux :

    https://www.teracom.se/privat/Support/frekvenstabeller-tv/

    In both Sweden and Australia, Band III is used for both DVB-T/T2 digital TV services and DAB/DAB+ Digital Radio services. (In other European countries like the UK, DVB-T/T2 is only in UHF, and VHF Band III is used for DAB/DAB+ only in consumer broadcasting terms, if it's used at all)

    I'm not sure if Finland is still using VHF - but it was at one point.

    In the US - VHF Band I and Band III are both used for ATSC digital TV.

    Here's the Rabbit Ears listing for New York : https://www.rabbitears.info/market.php?mktid=1

    If you look at the RF Physical Channel numbers you will see there are lots of channels below Channel 14 (which is the first US channel in the US UHF band numbering scheme) - anything below 14 is a VHF channel. VHF Band III contains channels 7 to 13, VHF Band I contains channels 2-6. Even the main ABC station - WABC - is on RF channel 7 (which is around 174MHz).

    (NB The US and Europe use different VHF/UHF channel numbers because the US uses 6MHz wide channels, whereas Europe uses 7MHz in VHF and 8MHz in UHF. I think Aus is 7MHz in both.)

    Quote from Jedrusia

    I have a new RPI 4 set with the "Astrometa" DVB-T2 receiver and the latest LibreElec operating system (LibreELEC-RPi4.arm-10.0.1.img.gz). My problem is that no MUXs operating in the VHF band are detected or scanned (for example in Poland MUX8 in the 184.5MHz band.)

    Is there any way that I can receive signals in this band?

    My receiver is built around integrated circuits: R828D; RTL2832U and Sony CXD2837ER.

    The next question is how (also the VHF band) can I receive FM and DAB + radio signals via the KODI application. ;(

    Where in the world are you based and what channels are you trying to receive.

    The Astrometa DVB-T/T2 tuner is likely to be limited to DVB-T/T2 only (and DVB-T2 may be tricky - at one point only DVB-T was supported because of the split demodulator arrangement and only drivers for the DVB-T demod being originally available)

    Whilst the tuner may also be advertised as supporting FM and DAB radio - that requires the tuner to be used with totally different, SDR-style drivers, which are totally separate to DVB drivers, and I don't think there is any support for running in this mode in TV Headend.

    (I think in Windows there are drivers and custom software to support this?)

  • RPi4 testbuild with HDR support

    Quote from heinzgruber

    hi,

    using Libreelec 10.0.1 on Raspberry Pi 4 with my LG OLED C9 and 4K/HDR looks fantastic! No problems so far.

    I wonder what this means

    • 10/12-bit video output isn’t implemented yet, 10-bit video is displayed in 8 bits

    My movies come with HDR10. So Libreelec plays thos files with 8 bits?

    Thanks

    Yes - in this case the video is output as 8-bit (usually RGB), but accompanied with an HDMI flag to tell your TV that the video isn't to be displayed in SDR but is instead in a PQ HDR dynamic range (which is what HDR10 content uses), and that triggers your TV into an HDR mode. You may see banding that you wouldn't see with a full 10-bit path.

    More recent nightly LE 11 builds will ensure the full 10-bit source is preserved and output, and remove the 8-bit bottleneck.

  • RPi4 testbuild with HDR support

    Quote from marantz

    is there a way to alter the brightness of subtitles only when watching HDR? in a dark room its almost impossible to have subtitles enabled.

    thanks for any help

    I think this is tied into the lack of support for SDR-in-HDR rendering. Same reason the GUI overlays are very bright when playing HDR content.

    I guess the issue is that with SDR content you might have subtitles set for something like peak-white (level 240 in 8-bit decimal) but in HDR10 PQ this would be massively into the HDR range, close to 1000nits - whereas SDR peak white is just 100nits).

    A stop-gap would be to have two or three different subtitle 'colours' for SDR, HDR10 and HLG content - or a real interim would be to chose a much darker grey for subtitles (though this would make them more difficult to read on SDR content I guess)?

  • RPi4 testbuild with HDR support

    Quote from onlyrock

    It appears that most if not all of my HDR10 videos get sent to my receiver using 12bit color. I think the builds prior to 2021.12.18 would send them as 8bit, as I detailed above.

    I thought HDR10 used 10bit color. Is that correct? If so, is there a reason LE outputs them as 12bit?

    UHD HDR10 content is encoded as 2160p (aka 4K) 4:2:0 YCbCr 10-bit with Rec 2020 colour gamut and using the h.265 codec typically.

    When HDR support first arrived on the Pi 4B in LibreElec, HDR10 content was replayed with the 10-bits truncated to 8-bit (losing the lowest 2 LSBs), and output in RGB. This meant that the two lowest bits were truncated which would mean a lower quality picture was being delivered.

    (I think some dither noise may have been added to reduce the visibility of the banding this would introduce on 10-bit capable displays - or those that simulate 10-bits with 8bit panels + FRC)

    This truncation was obviously not ideal, but HDMI 2.0 doesn't support 10-bit RGB in 2160p (aka 4K) at all frame rates - so just increasing the bit-depth and staying RGB wasn't really an option (it would mean no 2160p50 or above support).

    For higher frame rate UHD HDR with at least 10-bits, HDMI 2.0a supports either 4:2:0 YCbCr at 10-bit, or 4:2:2 YCbCr at 12-bit. The Pi 4B won't support 4:2:0 (as it requires both horizontal and vertical subsampling/scaling of chroma which the Pi GPU doesn't handle?), but the Pi 4B does support the horizontal-only scaling/subsampling for 4:2:2 YCbCr at 12-bit, which is now being used instead.

    HDMI 2.0a doesn't include any bit depths for 4:2:2 YCbCr other than 12-bit at UHD resolutions, so YCbCr output at UHD is always 12-bit. 10-bit content is just padded with zeroes in the two LSBs to pad the 10-bit content to 12-bit.

    Most of my UHD replay devices (UHD BD player, Apple TV 4K etc.) are set-up for 12-bit 4:2:2 output just as the Pi outputs, as is my AVR. (My Sky Q is 4:2:0 I think - haven't checked recently)

  • Atmos

    Quote from Nekromantik

    Hello

    Happy New Year all!

    Does LE 10 support Dolby Atmos decoding? Or do you have to passthrough?

    Does passthrough need certain NUCs to work or will NUC6 work?

    Thanks

    As far as I know there is no open source decoder / renderer for the Dolby Atmos Extensions used with Dolby Digital Plus or Dolby True HD - nor is there a majorly standardised route to sending them as PCM to an AVR.

    As a result Passthrough/Bitstream of DD+ with Atmos or True HD with Atmos to an Atmos compatible sound system is the route to getting Atmos decoding and height speaker playback.

    You can decode the DD+ and Dolby True HD stream to regular 5.1 / 7.1 PCM no problem though (as the streams are backwards compatible with non-Atmos decoders, which ignore the Atmos extensions)

  • RPi4 testbuild with HDR support

    I have an AVR-X2400H - I had to enable Enhanced HDMI support on both my TV and my AVR, and have to use HDMI 2 or HDMI 3 on my TV to allow 4:2:2 12-bit 2160p50/59.94 support. (HDMI 1 and HDMI 4 are 4:2:0 only - which the Pi won't support at 2160p50/59.94)

    HDMI 3 is my ARC port so that makes sense anyway.

  • RPi4 testbuild with HDR support

    Quote from onlyrock

    Ive got a few 4k hdr videos that I can play with the 12.18 build but not with newer builds. As far as I can tell the tv doesn't get put in to hdr10 mode in the newer builds. Brava xbr65a8h and denon avrx4300h. I can upload logs if useful.

    On most Sony HDR TVs you can tell if an HDR mode has been enabled by going to Picture Settings whilst the video is playing. If you see an HDR logo on the top right of the menu (there to tell you that you are altering the settings for HDR content on that source, as SDR and HDR picture settings are stored separately) you are in HDR10 or HLG mode.

    The only way of telling for certain if you are specifically in HLG HDR or HDR10 HDR mode is to go to Advanced Video settings and then manually altering Dynamic Range away from AUTO and forcing HLG or HDR10 to see if there is a difference between them and AUTO. (The same is true for Rec 2020 vs Rec 709 gamut switching in the Colour Space menu in the Advanced Video settings options)

    (Some devices will map HLG into HDR10 and output as HDR10, if they don't detect HLG support, I've found in some situations - though I think this was AML or RK, not Raspberry Pi)

  • RPi4 testbuild with HDR support

    frakkin64 Outputting 23.976/24.000Hz content natively in 23.976/24.000 Hz over HDMI shouldn't cause you 'Soap Opera Effect' issues unless your TV either cannot disable Frame Rate interpolation, or can't display 23.976/24.000fps content cleanly (i.e. without itself adding 3:2 or similar artefacts)

    My Sony TVs since my second HDTV set bought in 2007 have all supported native 23.976/24.000 support (my earlier displays used 48Hz refresh - which as they were LCD-based with constant backlight didn't flicker, my current display uses 120Hz 5:5 pulldown, as I have all the MotionFlow junk disabled)

  • RPi4 testbuild with HDR support

    Quote from HiassofT

    FYI: the 10/12-bit video output patches have been merged into the master branch and will be included in the next nightly build (20211219) - please use those for testing when they are available as they include other fixes as well (eg for deinterlace).

    Are nightlies here : https://test.libreelec.tv

    If so the Pi4 build seem to stop on the 18th Dec? Others are there for the 20th and 19th for other platforms. Does it take a while for Pi 4 nightlies to build?

  • RPi4 testbuild with HDR support

    Will have a play with this over the weekend. Have an HD Fury Vertex HDMI analyser so can see precisely what is being output in video terms.

    Great work!

    I guess the following is how the preferences work ?

    2160p30 and below : RGB 12-bit, YCbCr 4:2:2 12-bit, RGB 10-bit, RGB 8-bit

    2160p50 and above : YCbCr 4:2:2 12-bit, RGB 8-bit.

    (There are no 4:4:4/RGB modes at >8 bit supported in 2160p50 and above in HDMI 2.0, and 4:2:2 YCbCr is supported at 12-bit only)

    4:2:2 12-bit YCbCr at 2160p50/60 is often only supported by some (not all) HDMI inputs on some TVs (like my Sony XF9005 - which won't support this format on HDMI 1 and 4, only 2 and 3) and has to be enabled in TV menus. Similarly my Denon AVR has to have support for 4:2:2 12-bit enabled in its menus too. It's often called 'Enhanced HDMI' or similar. It also requires higher performance HDMI cables to work reliably as the bandwidth is pushing the limits of the HDMI 2.0a spec.

  • RPi Deinterlacer testbuild

    Quote from HiassofT

    "MMAL advanced" is borderline/too much for 1080i, therefore it's done using bob which needs fewer resources (memory bandwidth especially).

    I'm not 100% sure about RPi0-3 but ISTR they had similar issues - except for test streams I don't have any 1080i content here.

    RPis don't have a hardware deinterlace block therefore this is being done by software running on the videocore CPU - and that code is the same on all RPis.

    so long,

    Hias

    Ah - I thought there was some GPU acceleration for deinterlace on the Pi (a bit like there is for HEVC on the Pi 3B+ and below) - so not a hardware block for deinterlacing, but some assistance from GPU processing. I've clearly been wrong for years!

    (The MMAL is what made me think MMAL Advanced had some non-CPU support)