Posts by noggin

    I'm sorry to intrude, but is this specific to Raspberry or is it for all architectures?

    I'm into buying N100 based motherboard, and I'd like to have HW accelerated decoding of h264, h265 and AV1, which is supported by that iGPU. Should I postpone it?

    I believe this discussion is specific to the Pi2/3 HEVC implementation. That platform doesn't have VPU (video processing unit) support for hardware acceleration of HEVC/h.265 but instead uses a combination of CPU and GPU compute (not the same as dedicated VPU support) to allow HEVC content to be played on a platform that otherwise wouldn't be able to.

    The Pi 4 and Pi 5 both have hardware HEVC/h.265 VPU blocks to allow for hardware acceleration - which is supported in newer versions of LE.

    Other platforms like x86 which have 'GPU hardware decode' (which is more like VPU decode on ARM platforms) of HEVC are a different matter and depend on the driver support for that platform. I'd expect recent Intel CPUs to work fine once driver support for newer processors has made its way into the code base.

    Kodi always outputs progressive so you need to enable adjust-refresh and rate doubling, and set the mode whitelist to NOT include 1080p @ 30/29.97/25 modes. Kodi will then switch to 1080@50 with each interlaced half-frame rendered in a single frame. Normal PAL content will be output at 1080@50 too (each frame is rendered twice).

    Ah - I hadn't realised that frame doubling was used as the term to signify i25->p50 deinterlacing vs i25->p25 deinterlacing in settings (for some reason I thought this was a way of implementing 2:2 pulldown for replay of p25/p30 stuff in 50/60Hz output modes as it talks about enabling it for compatibility reasons).

    I'd assumed denterlacing was always at field rate by default (why would anyone do it at frame rate other than if their CPU/GPU couldn't keep up?) I suspect I've always enabled that setting without thinking about it in the past. (I only ever enable 23.976/24/50/59.94/60Hz refresh modes in my Whitelist.)


    *** EDIT - should add that this was, indeed, the issue. h.264 1080i25 native 50Hz interlaced stuff is now replaying fine with full 50Hz motion deinterlaced to 1080p50. BWDIF is the deinterlacer used it seems - which is a good choice. None of my CPU cores were >40% loaded in playback - most were less than this by quite a lot. The Active Cooler PWM fan didn't kick in for the few minutes I tested. ***

    Raspberry Pi 4B plays 2160p HDR (HDR10 and HLG) HEVC content with HD Audio passthrough (DTS HD MA, Dolby True HD, including Atmos extensions etc.) - such as UHD BDs. Would expect the Pi 5 to have the same functionality.

    The hardware h.264 decoder in the Pi4B and earlier topped out at 1080p (it's never supported 4K h.264 hardware decoding - so it's not a case of 'not supported in hardware any more' as it never was). The SoC functionality that supported h.264 decoding on earlier Pis was largely unchanged since the first Pi was released AIUI.

    AIUI there are reports that h.264 2160p content encoded at the kind of bitrates used for web-based content are decoding in software - at least at 2160p24 level. 1080p h.264/VC-1/AV1 all software decodes OK too I believe.

    in ordered the digibit twin, but it seems i cant get any channels, tvheadend finds the 2 devices.

    I think my landlord installed the system and they have more satelites over one cable, is the twin not capable of that?

    Is there a howto for using tvheadend and the digibit twin?

    There are different ways that multiple satellites can be sent over a single cable - you need to know which one your landlord is using so you can configure your receiver and/or software correctly :

    e.d. Diseqc switching a Universal LNB feed, Unicable, Unicable II etc.


    I'm seeing some expensive number for satip boxes. I paid for £15 for mine

    I used an old Linux sat-s2 receiver, Zgemma star s2 and installed satip software onto it. Edited the startup script to boot satip at boot and that's it. Facebook market place is flooded with old sat boxes which can be turned into satip boxes.

    Here's the link for github with all the information

    https://github.com/catalinii/minisatip

    I've been using this method for years without a single problem. Tvheadend picked up the tuners straight away.

    I nearly suggested this route - it's a perfectly sensible approach - and you can now get low-ish cost FBC Enigma boxes that will give you more than 4 tuners.

    would I have any advantages using the R1 with the alternative firmware?

    there are some on ebay atm.

    If you have a need to receive MPLS/Multistream stuff from 5W I think that is only possible with the Sat Axe firmware. Also that gives you a lot more flexibility in config terms (Unicable stuff, tuner vs LNB allocation etc.)

    I paid far less than the current going rate for my Digibit (something like £100?) - if you are spending £300 then the Kathrein Exip 418 is worth a look. 8 tuners... I have one of these fed from a Unicable II Global Invacom GTU fed over the fibre distribution system I have access too (we aren't allowed satellite dishes or TV aerials on our estate as it's in a conservation area so get 28.2 and Freeview via an RF-over-fibre feed)

    There are two aspects to this issue :

    How do you get the four tuners to work independently. You can do this with a Quad or Quattro LNB (with 4 cables to the R1), or a Unicable/Unicable II LNB or Multiswitch (with one cable) - though that latter may require you to use third party firmware like SatAxe and to understand how to configure Unicable/Unicable II. This will allow you to tune to a maximum of 4 satellite transponders.

    How many channels that you want to provide to your network does each transponder have? You can use one tuner and LNB feed/Unicable UB slot to tune more than one channel if it's on the same transponder (though you may not be able to stream ALL of the channels on a transponder). When you tune to a transponder, the R1 will get a data stream with all the channels in that transponder, and will filter out the ones you want. You can usually filter out a number of channels from the same transponder before you hit a processing limit (it depends how hard the R1 is working I think)

    If you want to offer specific channels to your network - you can look at which channels are on which transponder and come up with a plan to use your 4 tuners to decide which 4 transponders make the most sense. Or you can just decide to limit each user to one tuner/transponder and limit it to 4 users. They are two sensible approaches for different reasons.

    noggin Thank you for explaining the possibilities.

    I need DVB-S/S2. So the PI TV Hat is not sufficient.

    There are a lot of options, but I think I understand them.

    For straightforward DVB-S/S2 from a single LNB or simple Diseqc then a SAT>IP server makes a lot of sense, or you may find you can run SAT>IP server software on an Enigma 2-based DVB-S/S2 set top box (ignoring its primary role). These days with FBC tuners giving 8 separate tuners in a single box - it can make a powerful set-up.

    RPi4 is excelently supported, but DVB is an icky topic regardless of hardware. The general recommendation is to separate tuners from the playback device so you can run whatever OS and hacked version of drivers and firmware that works reliably .. with playback on something simple that you can OS bump whenever LE puts out a new release. The moment you put both functions on the same device you can have a reliable player or DVB that works; they are generally mutually exclusive and you have to chose one.

    That means you could revert to a legacy image, e.g. CE or dtech's LE 9.2.8 one for the TVH side. RPi4 is a nice playback device if you can get your hands on one.

    Yes - though the single-tuner DVB-T/T2 TV Hat on the Pi 4B is almost an integrated tuner and is available for £6.30 on Amazon UK at the moment. (In the UK this will allow you to record any or all HD services simultaneously - as they are all on the same frequency here in the PSB3 mux - though I think the SPI interface used does struggle to stream the full 40Mbs of a PSB Mux so you may not be able to record ALL channels simultaneously...). As it's a Raspberry Pi product, driver support on Pi OSs is reasonably good I think, and the Pi team are good at mainlining their driver support AIUI.

    Raspberry Pi TV HAT
    Raspberry Pi TV hat dvb-t/t2 raspberry pi TV hat dvb-t/t2 The Raspberry brand guarantees the highest standards during the production process, to ensure an…
    www.amazon.co.uk

    You can get cases that are designed for the Pi 4B and the TV Hat too.

    However as chewitt says - it's usually better to separate your DVB/ATSC tuner and TV Headend backend from your Kodi playback solution, as it avoids your Kodi playback solution (like LibreElec) needing specific driver support.

    You can also look at HD HomeRun networked DVB-T/T2 tuners (now available again - and available in 2 and 4 tuner flavours - along with ATSC variants in North America) or SAT>IP if you are looking for DVB-S/S2 functionality. These move tuner support to a networked device, meaning you can run TV Headend on Kodi platforms (should you wish) as the driver support is removed from the OS running Kodi, or you can run TV Headend on things like NAS/Unraid/ESXi VM boxes, or a small Pi server that just sits on the network with a hard drive for recording.

    I run HDHomeRuns and SAT>IP mainly these days - with just a couple of USB DVB tuners kicking around for backups, use out and about etc.

    There is no hardware deinterlace in any codec, forcing software deinterlace which is limited (else you hit the CPU limits). I've disabled support for MPEG2/MPEG4 hardware decoding in the latest images (as the hardware decoder is broken) which is why those 'work' now. However, ff those codecs and interlacing are important for your media; you aren't in the narrow band of users who should be using the AMLGX image. I have low expectations on progress because it's basically me solo supporting Amlogic these days, and I don't write driver code.

    576i25 MPEG2 with software decode (and software deinterlace) I guess is working then, but 720p50 h.264 (software decode, but no deinterlace required) may be pushing the CPU to far?

    Without hardware decoding, HD h264 is usually too much for these earlier CPUs, and 720p50 with software decoder is pushing it, and 1080i25 with software decode and software deinterlace almost certainly is.

    I guess the choice now is stick with older builds that had hardware decode and deinterlace support, or change platform to something that supports mainline LE builds, or a newer AML platform and run CE?

    If you want to run CoreElec you need a reasonably current AMLogic SoC in your box or board, it's a distro optimised for AMLogic stuff. (Support for older chipsets disappears as AMLogic cease to update their newer kernel buils with support for older boards - which is I think a consequence of them not using mainline. LibreElec is focused on using mainline I think - which is a major difference between LE and CE)

    I have found the cause.

    Whitelist function, here the function "Allow double refresh rates" was not activated.

    Kodi will play at DVD 576/25 now 576/50.

    Thanks a lot.

    That's odd - you'd expect DVD native 576i25 MPEG2 video to be deinterlaced to 576p50 (as i25 = 50i and will have 50Hz motion if the source has native interlaced motion) and not need the double refresh-rate option (as DVD is MPEG2 576i25 which is a 50Hz not a 25Hz format).

    You'd only expect that double refresh rate option to be needed for Handbrake or similar rips from DVD where the 576i25 MPEG2 has been converted with a deinterlace 576p25 h.264 or similar (which is fine for film-sourced content that is native p25, or p23.976/24 sped-up to p25 for 50Hz DVD), particularly as 576p25 isn't a valid output format for HDMI (HDMI only supports 576i25 and 576p50 - the two different 576 line 50Hz refresh rates)

    Does LE default to a i25->p50 deinterlacing for interlaced i25 MPEG2 and h264 sources (like DVD, DVB 576i25 / 1080i25 etc.), or do you have to manually switch to a '2x' deinterlacer - I can't remember - but I thought it usually defaulted to a frame per field deinterlace?

    I thougth to make the Octagon SF 8008 a TVHeadend server. But I do not know if It will change something.

    Ah - is there an Enigma 2 package to run TV Headend servers on those kinds of receivers? Or are you planning to use the Octagon as a DVB->IP gateways and then use TV Headend server on a secondary computer separate to the Octagon, pulling in the IP streams from the Octagon?

    I think that's the problem, because 576p/50fps is the only CEA supported HDMI mode.

    But the standard for DVD in 50Hz land is 576p/25fps.

    What the CEA does wrong, Linux doesn't have to do wrong too?

    Windows still supports 576p/25fps.

    DVD is 720x576i25 (aka 575/50i) interlaced - not 720x576p25 (aka 576/25p) progressive. The DVD video can contain native 576p25 contents (stored as psf)

    The two standards that are supported over HDMI for 576 line video are 720x576p50 and 1440x576i25 (aka 1440x576/50i)

    576p50 sends 576 active lines 50 times per second, i.e. 50 progressive frames.

    576i25 sends 288 line fields at 50 times per second, sometimes referred to as 576 line interlaced frames at 25 frames per second i.e. 25 interlaced frames made up of 50 interlaced fields.

    HOWEVER the 1440 in the horizontal resolution of the 576i25 interlaced standard is a workaround in the HDMI spec and is based around repeating every 720x576 sample/pixel to get the pixel clock high enough, it doesn't actually give you twice the horizontal resolution. (The HDMI spec doesn't allow for pixel clock as low as would be required for 720x576i25 video without the pixel doubling/repetition)

    Bottom line is that MPEG2 DVDs in Europe are based on MPEG2 interlaced video - 576i25 (aka 576/50i).

    If the DVD contains native interlaced video (with 50Hz motion) then you need to deinterlace to 576p50 for full motion.

    If the DVD contains native 25fps progressive video (say stuff shot on film or HD / UHD at 25fps, or sped up from 24fps) then you can deinterlace to 576p25 and not lose any motion. However 576p25 isn't a valid HDMI mode (and in the days of CRT would have been unwatchable because of flicker) - so you frame repeat to get to 576p50, just as you deinterlace 576i25 native interlaced content to.

    For info CEA-861 modes 17 and 18 are 4:3 and 16:9 720x576p50, and CEA-861 modes 21 and 22 are 4:3 and 16:9 1440x576i25 (which is the pixel repetition route to carrying 720x576i25 video)

    Do you actually have any media outside of 576@25 (PAL) and [email protected] (NTSC) .. because ye olde analogue broadcast standards certainly don't include those refresh rates; which is prob. why Linux doesn't invent/expose them.

    480p23.976 isn't that unusual. If you have movies or TV shows shot at 23.976fps on film, and carried as 3:2 29.97fps interlaced on DVD or in MPEG2, some people will transcode the MPEG2 to h.264/5 480p23.976 to allow the content to replay natively at 23.976fps avoiding 3:2 pull-down judder (or to avoid their TV having to do 3:2 detection and removal).

    Personally I'm fine with this stuff replayed at 1080p23.976 as I doubt my TV's upscaling can make much more of a silk purse from a 480p sow's ear...

    (I don't think 480p23.976 is a CEA supported HDMI mode anyway)

    However in 50Hz land, 576i25 (aka 576/50i) is the most common format - though in Australia they flirted with 576p50 as an 'HDTV' standard for a while... (Long since ditched for 720p50 and/or 1080i25 now)