Posts by noggin

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    Quote from LOLinger78

    noggin

    No, I am NOT using it standalone. Instead I also use it as the source/media center for my TV.

    And yes, I did only try LibreElec so far. I thought this was especially geared towards the "bare minimum" as you say.

    Yes - it's bare minimum for media playback duties. Once you start throwing PVR backends at it - it's not really bare minimum. It's also not optimised for that.

    I'd see how you go running just Raspberry Pi OS Lite and TV Headend on a Pi 4B and see if you still get thousands of continuity errors. It's only a MicroSDc card flash away.

    I wouldn't be running on a Pi 3B+ or earlier because of the USB LAN implementation that CvH mentioned. (The Pi 4B doesn't use its USB bus for LAN connectivity)

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    Quote from elonesna

    @noggin: I admit that my knowledge is lower than that of CvH, but that does not prevent me from disagreeing, based on my experience, with some of their statements. It is the first rule that is learned in universities and for me that happened 48 years ago.

    Yes - but accusing someone of unfounded alarm isn't respectfully disagreeing based on experience is it? This is a forum operated by volunteers.

    A bit of respect goes a long way - rather than accusations - particularly when someone is trying to help you...

    I was also taught at my universit.y that the plural of anecdote isn't anecdata...

    I have the same SAT>IP tuner and ran it for 6 months constantly recording BBC One HD, BBC Two HD, ITV HD, Channel Four HD, Channel Five HD and the part time BBC Four HD channel to a TV Headend system (so I always had the last 10 days or so of those channels archived). I had very few continuity errors (most recordings were 100% error free). This was using a Celeron PC connected to the same unmanaged switch as the SAT>IP tuner.

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    Quote from elonesna

    In short, I think the alarms generated by CvH are excessive and unfounded.

    Not sure what you mean by this?

    CvH is a well respected contributor on these things and they're trying to help.

    Continuity errors are just that - errors. AIUI they are flagged when the MPEG2 Transport Stream headers in a transport stream are discontinuous. (i.e. they indicate corruption in the received stream)

    Continuity errors on directly attached tuners (i.e. USB tuners or a Pi DVB-T2 TV Hat) usually indicate poor signal - but on network attached tuners (like SAT>IP) they can also indicate network issues due to packet loss. SAT>IP is UDP-based not TCP-based - so once a packet is lost, it's lost (TCP would allow a re-request, but UDP is 'faster' as it doesn't continuously handshake)

    Whatever the cause - you shouldn't be having continuity errors. Whether it's because your TV Headend server running on the Pi can't keep up (I'm assuming you're running on a Pi 4B but you don't say which model?

    Also are you running TV Headend on a standalone Pi (i.e. Raspberry Pi OS - formerly Raspbian - Lite + TV Headend either installed via apt or built from source) or are you using LibreElec as your OS for your Pi TV Headend server? I'd recommend the former not the latter - as for a TV Headend server you want the bare minimum. (Media Vault + TV Headend can be a nice lightweight combo though).

  • general performance questions (and rare artefacts on HD channels with Sat>IP)

    Continuity errors in TV Headend mean that the stream from your SAT>IP server is not 100% error free - each one of those continuity errors is an error in the transport stream being received - which could mean corrupt video and/or audio. Different h.264 decoders will behave differently with corrupt video streams - some will mask errors better than others. You need to get rid of those continuity errors whatever you do.

    I have a Kathrein EXIP 418 - though because of building work it's not currently running - but I use a Celeron Linux box as my TV Headend server platform and have it next to the Kathrein server connected via a small 8-port Ubiquiti managed switch. I have only very occasional continuity errors with that set-up. (A couple of them a day at most?)

  • RPi4 testbuild with HDR support

    Quote from jernej

    No, Allwinner and Rockchip implements it. Main requirement is v4l2 deinterlacing driver. LE uses out-of-tree ffmpeg v4l2 deinterlace filter implementation, written mostly by me. Kodi then uses standard ffmpeg infrastructure - first it decodes frame in DRMPRIME format and if content needs deinterlacing, it pushes frame through deinterlace filter. If not, it's displayed directly. It's still considered tech demo, since there are known corner cases, which don't work (mostly frame dropping).

    Thanks for the clarification, and for taking the time to post.

  • RPi4 testbuild with HDR support

    Quote from camelreef

    So the SoC has no hardware deinterlacing filter? Bummer!
    Getting out of the hardware chain is probably crap...

    Is handing over interlaced content to be deinterlaced downstream just as crappy to achieve?

    I think it's more complicated than that - which is why it's non-trivial to support it.

    AIUI the Pi series are not quite typical ARM SoCs. Effectively they were designed initially as a GPU that happened to have an ARM core on it too. (My understanding is that the Videocore GPU boots first and then boots the ARM CPU - though I may be wrong)

    Whatever the complexity - there is a way of running code on the Videocore GPU from the ARM CPU - and one of the routes to doing that is using an API called MMAL. GPU deinterlacing (which some may call 'hardware' deinterlacing - though in reality it's code running on the GPU rather than the CPU - which is how accelerated deinterelacing has improved over the years on the Pi series) still takes the workload away from the CPU (rather than what would be considered 'CPU' or 'software' deinterlacing where the CPU handles the code entirely.

    AIUI the issue is that the new video pipeline that Linux and LibreElec are using moving forward, which avoids bespoke workarounds for different GPU/VPU architectures (instead relying on platform developers/maintainers to implement a compliant driver framework?), wouldn't allow them to graft on the old MMAL deinterlacing system?

    I don't THINK this means it's the end of accelerated deinterlacing on the Pi - but it will require a Pi dev to implement it somehow?

    Or has handling of interlaced content been somewhat abandoned with the new framework (I hope not - it's still used for a large chunk of ATSC and DVB TV, plus DVD and Blu-ray)

    *** PEOPLE IN THIS THREAD KNOW A LOT MORE ABOUT THIS THAN ME - PLEASE CORRECT ME! ***

  • RPi4 testbuild with HDR support

    Quote from HiassofT

    No changes regarding 10/12-bit output yet, but we just merged a huge set of kernel and ffmpeg changes. They improve H265 decoding performance, fix a couple of H264 decoding issues and add 4kp60 output.

    so long,

    Hias

    Great progress if we have 2160p60 output support.

    How is h.264 1080i interlaced support now? (I use a lot of my Pi 4Bs as DVB-T2/S2 UK TV Headend clients)

  • No 4K resolution on RPI4

    The Pi 4B doesn't support 4K60 HDMI output with 4:2:0 subsampling - which is the only format some UHD TVs support at 4K60. If your TV is one of them - you're unfortunately out of luck.

    If your TV supports RGB (and I think YCbCr 4:4:4:) 8-bit at 4K60 then it should work OK. Similarly 4K30 and below at RGB 8-bit.

    Also - some TVs support different levels of 4K on different HDMI ports. My Sony supports more on HDMI 2 and 3 than it does on HDMI 1 and 4. (Though this is usually related to 4K60 4:2:2 12-bit support - which is higher bandwidth. The Pi 4B doesn't currently support 4K60 4:2:2 output - but there is hope it will.)

  • RPi4 testbuild with HD audio passtrhough (Atmos etc)

    Quote from Technix

    Extreme bummer..

    So no it isn't and it seems all the forum crawling I've been doing doesn't seem to give any hope to those wanting a Raspberry Pi 4 to do frame packed 3D MVC formatted files.

    I saw a mention of LE 9.2.6, but no conclusive evidence that it does beyond half frame TAB/SBS 3D.

    Suppose I'll give it a try on my RPi400 and cross my fingers...

    I think the LE 9.2.6 reference was for Pi3B+ and earlier models, because it uses the legacy, and bespoke?, video decoder sub-systems that were supported on the Pi 3B+ and earlier that supported MVC decode. (Not sure if 1080p24 frame packed HDMI output is linked or separate to that)


    AIUI the Pi 4B has never supported the legacy approaches, and the newer Pi 3B+ and earlier builds using the new video structures don't support them either, as they both use the mainline V4L2 approach.

  • RPi4 testbuild with HDR support

    Quote from poeBaer

    I run a mix of consoles and a gaming PC (and a NUC for my main LibreELEC player), so it's mostly been RGB full. My AMLogic boxes (S912 and S905X3) don't seem to trigger any sort of switch, and just washes out videos, so I need to manually switch TV modes when I use them

    Ah - I thought most platforms properly supported the Full/Limited Infoframe signalling these days. It was added to Intel HDMI drivers many years ago. (Ivy Bridge era or earlier ISTR)

    I run everything in Limited - as that's what SDR and HDR video (*) standards are based on - and they are my primary viewing on my main TV. I'm not convinced I can see the improvement with having 30 or so additional quantisation levels with a switch to full level for gaming (though Windows PC support for 16-235 can be 'interesting')

    (*) Dolby Vision Single layer can use 0-1023 levels with IPTPQc2 instead of YCbCr - but I'm not sure how that interacts with HDMI LLDV interconnects. (And it's a non-issue for the Pi 4B)

  • RPi4 testbuild with HDR support

    Quote from poeBaer

    How "bad" is the dithering to 8-bit? I have a 10-bit FRC panel, so it's basically an 8-bit panel anyway, wondering if I'd even notice the difference, or if I should wait for the 4:2:2 mode/fix

    Currently I'm using an AMLogic device/build for my HDR files, but their SoCs don't support full color (0-255), which all my other devices on my receiver are set to, so I constantly need to switch my TV settings back and forth. Would love to just switch to my Pi 4 full time

    Do we know if the 10-bit to 8-bit conversion uses dithering rather than just truncation? Looking at the HLG HDR bars I ran the Rec 2020 tests on, the luminance sweep it looked like it was suffering from truncation rather than dither.

    I have a 10-bit native panel in my TV (not 8-bit + FRC)

    Out of interest why are you running 0-255 (or 1-254) rather than 16-235 - is it because one source is a games console ? In theory mixed 16-235 and 0/1-255/254 sources can co-exist if their InfoFrames correctly signal their range.

    I usually try and keep everything 16-235 for as long as possible to avoid multiple re-scales.

  • Raspberry pi 4 - Wait for 4k HDR support or buy another board?

    Quote from jernej

    I tend to disagree (except about AML part) :) AW and RK support deinterlacing while RPi does not. RK is also almost on pair regarding HDR. In short, each platform has features that are not necessarily implemented on others. But I agree that RPi development progresses much faster.

    What's the status of HD Audio bit streaming on RK and AW? (I've got a couple of RKs that sit in a cupboard getting dusty)

  • Raspberry pi 4 - Wait for 4k HDR support or buy another board?

    Quote from slappy

    RPI4 development is a big deception. No 3D mvc support and no HDR after over one year. We will have it running at the same time everything will move to 8k or other newest tech. In the 2000 years the RPI development was able to catch up but not anymore. Better to go Vero 4k or stick with PC with madvr for 3D and 4K hdr.

    I think it's deeply unfair to accuse the developers of 'deception'. They've always been pretty clear that these features will take time to implement and that time was not weeks but likely to be months or years.

    The time it takes developers to implement features and support new hardware is simply the time it takes to do that. The more of us who work on supporting our colleagues in adding these features, or providing useful feedback, the better. None of us pay anything for Kodi or LibreElec - it's not a commercial product. We can't expect stuff to happen instantly just because we want it to.

    HDR (HDR10 and HLG) with Rec 2020 Wide Colour Gamut colour is implemented for 2160p30 and below output in Pi4B nightlies and is working effectively. AIUI this is working using the mainline V4L2 Linux framework that should continue to be supported long-term. Most other HDR implementations on Linux are using workarounds that are likely to no longer be supported moving forward AIUI.

    HD Audio bit streaming has also been supported in nightlies for quite a while now. progress.

    I don't think HDR and HBR now working on a Pi 4B in nightlies is 'deception', it's a sign of good progress...

  • RPi4 testbuild with HDR support

    Quote from CvH
    Post

    RE: LE10 & deinterlacing in RPi4

    […]

    Hi , Just tested 9.95.2 and found out that de-interlacing is not available yet. (Clearly "alpha" fits the description :) )

    I just want to make sure you know de-interlacing is Top priority for PVR usage (and even playing old DVDs).

    Not only without de-interlacing the playback is jaggy we are viewing it half fps which make a lot of content unwatchable.

    While saying that keep up the great work and hoping to se de-interlacing support gets bumped up (I can help with testing if needed).
    hagaygo
    April 23, 2021 at 11:05 AM

    Understood - and if it's all interlaced content - then that's pretty much everything I watch in Kodi!

    TV Headend h.264 1080i25 stuff is the bulk of my viewing on my Pi Kodi clients.

    (I'm not complaining - I know interlaced video is a pain and one that many wish would go away, but it hasn't yet..)