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 change in that area. We discussed that a while ago, but adding software deinterlacing to the drmprime render chain in kodi is quite tricky...
so long,
Hias
No change in that area. We discussed that a while ago, but adding software deinterlacing to the drmprime render chain in kodi is quite tricky...
so long,
Hias
And I guess the old MMAL stuff can't be repurposed because of the new video pipeline stuff ?
And I guess the old MMAL stuff can't be repurposed because of the new video pipeline stuff ?
Yes, exactly.
so long,
Hias
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?
RPi4 code is still under heavy development, with new features and bugfixes coming in at a quite regular pace, so RPi4 builds should be considered stable-beta even if LE 10.0 final is released (as also announced in the blog posts).
The recent kernel update was quite a disruptive change, not only adding 4kp60 support but also switching the internal audio driver code, so any feedback on nightly builds is highly welcome. I'd expect future kernel changes to be far less disruptive, more focusing on ironing out remaining bugs.
so long,
Hias
my only issue with le10 beta is when i use AMBER skin auto completion keyboad ( it freazes kodi and reboot ), it fixed my issue with unstable cec response in LE9... other then that im using it as my daily driver.. great work guys..
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! ***
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)
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).
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.
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.
I think it's tricky even to classify the Videocore as a GPU, it's more like an FPGA or a programmable DSP.
It's amazing we got 'software' decoding of HEVC on the RPi3, and that was on an older Videocore that had no business handling that logic.
Hi, I just tried the last matrix build for my rpi4 4 gb and everything plays fine (even 130 GB mkvs!). Most of my files are in MKV format created with makemkv stored in a NAS, but two of the tvs at home are still 1080p. Files plays fine, but the colors are obviously washed out.
Is it planned to support tone mapping so colors can be "downscaled"?
Thanks.
Hi, I just tried the last matrix build for my rpi4 4 gb and everything plays fine (even 130 GB mkvs!). Most of my files are in MKV format created with makemkv stored in a NAS, but two of the tvs at home are still 1080p. Files plays fine, but the colors are obviously washed out.
Is it planned to support tone mapping so colors can be "downscaled"?
Thanks.
Yep - tone mapping Rec 2020 HDR to Rec 709 SDR is a requirement for playback of Rec 2020 HDR content nicely on Rec 709 SDR TVs.
(Rec 709 vs Rec 2020 is the colour gamut, SDR vs HDR is the dynamic range - both need to be handled)
However it's important not to assume it's a UHD 2160p vs HD 1080p thing - there are UHD TVs that need tone mapping as they are Rec 709 SDR only (early 4K TVs weren't Wide Colour Gamut or HDR), and there are 1080p HD TVs that don't need tone mapping, just downscaling (as they are Rec 2020 HDR compatible)
Yep - tone mapping Rec 2020 HDR to Rec 709 SDR is a requirement for playback of Rec 2020 HDR content nicely on Rec 709 SDR TVs.
(Rec 709 vs Rec 2020 is the colour gamut, SDR vs HDR is the dynamic range - both need to be handled)
However it's important not to assume it's a UHD 2160p vs HD 1080p thing - there are UHD TVs that need tone mapping as they are Rec 709 SDR only (early 4K TVs weren't Wide Colour Gamut or HDR), and there are 1080p HD TVs that don't need tone mapping, just downscaling (as they are Rec 2020 HDR compatible)
Ok thanks for your help.
Hi there,
newbie here.
Is there an option to disable Hdr?
im not happy with some of my HDR Video Files and i like them better when i turn HDR off.
I cannot switch it off on my TV, so it seems Libreelec is forcing it.
Not the End of the world since i can use older builds for those files, but it would be a nice option
Hi,
What is the expected behaviour when I play a Dolby Vision HEVC video on RPI4, if my TV supports Dolby Vision (LG OLED 55 CX)? Using LibreELEC 10.0 RC1 (9.97.1) I see a greenish picture on my TV. I think Dolby Vision is not supported because of the licensing...
Thank you.
Display MoreHi there,
newbie here.
Is there an option to disable Hdr?
im not happy with some of my HDR Video Files and i like them better when i turn HDR off.
I cannot switch it off on my TV, so it seems Libreelec is forcing it.
Not the End of the world since i can use older builds for those files, but it would be a nice option
What do you mean by 'disable HDR'?
Do you mean convert HDR10 to SDR and output SDR (i.e. tone map)?
HDR10 (Rec 2020 with a PQ EOTF) video played back unconverted in SDR (Rec 709 with an SDR EOTF) will look unwatchable bad.
(HLG is a bit different as the HLG EOTF is compatible with an SDR EOTF - though Rec 2020 content played back unconverted and displayed as Rec 709 still looks awful)
i dont know.
The older versions without HDR support would play my HDR video files just fine.
Maybe a possibility to play those files like libreelec used to do it before the HDR support
Hi,
Thanks for all the work on the testbuild. I have only been testing it for a few days as I just got an HDR tv.
Up to now it's all smooth and HDR playback works great.
The issue I have is when stopping HDR playback the GUI is stuck in HDR mode. Playing SDR content keeps it in HDR mode. Only option I found was rebooting Libreelec and then it shows the GUI in SDR.
Display settings are in 1920x1080p, GUI resolution limit is set to 1080.
This doesn't happen all the time but 9 out of 10 times it's stuck.
