Posts by noggin

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

  • Information Regarding Linux on Rockchip SoC's

    Quote from wrxtasy

    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 :

    Code
    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/m2

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

  • XBOX One DVB Tuner and LibreElec 8.1.1 ?

    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.

  • Information Regarding Linux on Rockchip SoC's

    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)

  • Regular Kodi crashes on popcorn Transformer.

    Quote from Sm3ghead

    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.

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

    Quote from Liffeyman

    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?

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

    Quote from Liffeyman

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

  • Raspberry composite output

    Quote from Anard

    Thanks. I tried to edit the config.txt file but it can't in ssh as if I wasn't root. The only way is to remove the SD card and edit... Is it normal ?

    It's not a problem if it wouldn't work for composite but I like to understand...

    Finally, sure I'll use a HDMI to Scart or composite converter, video quality will be much better, but waiting for the converter, I'll continue to use it with my jack connection.

    You probably need to mount /flash as RW. I think it's RO by default in LibreElec - like most of the LE filesystem?

    Details here in the wiki : Raspberry Pi Config.txt [LibreELEC.wiki]