[infinity85]

Yep - the Pi has an option to let you output HSBS and HTAB as Frame Packed (rather than as HSBS/HTAB)

I don't think Pi converts HSBS/HTAB to frame packing 3D output. It just codes the AVI InfoFrame for the appropriate 3D format (which will put the display in 3D mode).

Perhaps I'm misunderstanding what say, so my apologies in advance if that is so. But... the Pi apparently transmits the decoded 3D videostream with FramePacking method, even for HTAB and HSBS, like seen here:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

As mentioned before, this output shows the FramePacked (FP) display mode when playing a simple H-SBS mkv. As FramePacking is (afaik) only some kind of transfer-protocol over HDMI, it may apparently contain any video (2D and 3D, and HSBS, MVC,HTAB). And as it is primary made for 3D, it will always turn on the TVs 3D mode. However, I think I misunderstood your post and it is not in conflict with what I just wrote? Somehow the Pi or Odroid would still need to tell the TV, whether it has to turn on SBS or TAB 3D in its FramePacked mode. Or does the TV detect SBS or TAB depending on blank lines in vertical or horizontal and switch to the corresponding mode then?

[noggin]

Yep - the Pi has an option to let you output HSBS and HTAB as Frame Packed (rather than as HSBS/HTAB)

I don't think Pi converts HSBS/HTAB to frame packing 3D output. It just codes the AVI InfoFrame for the appropriate 3D format (which will put the display in 3D mode).

Perhaps I'm misunderstanding what say, so my apologies in advance if that is so. But... the Pi apparently transmits the decoded 3D videostream with FramePacking method, even for HTAB and HSBS, like seen here:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

As mentioned before, this output shows the FramePacked (FP) display mode when playing a simple H-SBS mkv. As FramePacking is (afaik) only some kind of transfer-protocol over HDMI, it may apparently contain any video (2D and 3D, and HSBS, MVC,HTAB). And as it is primary made for 3D, it will always turn on the TVs 3D mode. However, I think I misunderstood your post and it is not in conflict with what I just wrote? Somehow the Pi or Odroid would still need to tell the TV, whether it has to turn on SBS or TAB 3D in its FramePacked mode. Or does the TV detect SBS or TAB depending on blank lines in vertical or horizontal and switch to the corresponding mode then?

wesk05 is suggesting that rather than the Pi scaling HSBS and HTAB internally to 1080p 3D and outputting as Frame Packed (1920x2205p), that the Pi instead outputs HSBS or HTAB as normal 1920x1080p BUT flags that they are 3D HSBS/HTAB in the HDMI infoframe (which would also trigger a 3D TV into 3D mode)

The tvservice response seems to suggest that it outputs Frame Packed. If I get a chance I'll have a look. My AVR may well tell me the difference.

[wesk05]

wesk05 is suggesting that rather than the Pi scaling HSBS and HTAB internally to 1080p 3D and outputting as Frame Packed (1920x2205p), that the Pi instead outputs HSBS or HTAB as normal 1920x1080p BUT flags that they are 3D HSBS/HTAB in the HDMI infoframe (which would also trigger a 3D TV into 3D mode)
The tvservice response seems to suggest that it outputs Frame Packed. If I get a chance I'll have a look. My AVR may well tell me the difference.

Yes, that's exactly what I meant. The last time I checked (several months ago), it was not converting all 3D input formats to frame packing output. tvservice response suggests that is not the case now.

@infinity85: HDMI 1.4a specs define mandatory 3D formats that all 3D capable devices should support. Frame packing, Side-by-Side (Half) and Top-Bottom are all mandatory formats and there are specific 3D structure codes for each one of them that can be specified in the InfoFrame. 3D displays can detect that and switch to 3D mode automatically.

[noggin]

wesk05 is suggesting that rather than the Pi scaling HSBS and HTAB internally to 1080p 3D and outputting as Frame Packed (1920x2205p), that the Pi instead outputs HSBS or HTAB as normal 1920x1080p BUT flags that they are 3D HSBS/HTAB in the HDMI infoframe (which would also trigger a 3D TV into 3D mode)
The tvservice response seems to suggest that it outputs Frame Packed. If I get a chance I'll have a look. My AVR may well tell me the difference.

Yes, that's exactly what I meant. The last time I checked (several months ago), it was not converting all 3D input formats to frame packing output. tvservice response suggests that is not the case now.

@infinity85: HDMI 1.4a specs define mandatory 3D formats that all 3D capable devices should support. Frame packing, Side-by-Side (Half) and Top-Bottom are all mandatory formats and there are specific 3D structure codes for each one of them that can be specified in the InfoFrame. 3D displays can detect that and switch to 3D mode automatically.

Yep - though that was what you meant. The Pi VPU/GPU devs really seem to have a much better handle on HDMI flagging and 3D MVC than any other ARM dev team it seems. They also seem to be actively developing stuff (MVC was added, deinterlacing was improved, shifted partially to the GPU and improved further in efficiency terms, HEVC GPU compute decode etc.)

[leo5111]

Hi,
I have been using libreelec version 8.0.1 lately and while it's working fantastically, the blinking blue LED is back. Is there any way to disable that?

Yep do a .tar update with this version

LibreELEC-Odroid_C2.aarch64-8.0.1.Nougat.tar

is this android or is it straight libreelec?

[nickr]

Hi,
I have been using libreelec version 8.0.1 lately and while it's working fantastically, the blinking blue LED is back. Is there any way to disable that?

Yep do a .tar update with this version

LibreELEC-Odroid_C2.aarch64-8.0.1.Nougat.tar

is this android or is it straight libreelec?

The clue is in the filename.

LibreELEC-Odroid_C2.aarch64-8.0.1.Nougat.tar

Think about it.

[noggin]

Yep do a .tar update with this version

LibreELEC-Odroid_C2.aarch64-8.0.1.Nougat.tar

is this android or is it straight libreelec?

The clue is in the filename.

LibreELEC-Odroid_C2.aarch64-8.0.1.Nougat.tar

Think about it.

I guess the fact that the file name has both a LibreElec reference and an Android reference (Nougat) explains the confusion a little...

[infinity85]

@leo5111
It is LibreELEC, hence the usual Linux, not Android. Just the Kernel is something adapted from more recent Android builds.

@noggin and wask05How great is all this info and knowledge you drop here. I really appreciate reading this kind of technical insight!!

@wrxtasy and all
Have you seen this today: $40 NanoPi K2 Board Powered by Amlogic S905 Processor Competes with ODROID-C2, Raspberry Pi 3
Basically an Odroid C2, but with additional Wifi and Bluetooth Chip.
I guess it will still be a from-scratch work to adapt LibreELEC to it to the same quality as seen now on our C2?

Wondering why they didn't choose an S912 or so, for having an SBC form-factor Odroid C2 competitor with HDR capability finally.

[wrxtasy]

NanoPi K2:

Whilst the WiFi may look like a worthy addition - being 2.4GHz only really is a token effort.
You would not use 2.4GHz only WiFi for reliable video streaming media player in a modern Electromagnetic household environment.

Bluetooth - its dirt cheap to add via USB.

Include a Heatsink and your at $46, same price as a C2.

As with any development board, the make or brake factor is the community support that builds around a product.

The Linux Open Source guys do not get very interested at all if development code sources are not published and GPL licences are abused.
This can kill a product's community support outright, especially when it comes to Kodi or LibreELEC.

Exhibit A, would be Rockchip from years past.

AMLogic S912's have no open sourced Linux Mali-T820 GPU drivers.
S905 was chosen for Gigabit Ethernet.

[noggin]

NanoPi K2:

Whilst the WiFi may look like a worthy addition - being 2.4GHz only really is a token effort.
You would not use 2.4GHz only WiFi for reliable video streaming media player in a modern Electromagnetic household environment.

Bluetooth - its dirt cheap to add via USB.

Include a Heatsink and your at $46, same price as a C2.

As with any development board, the make or brake factor is the community support that builds around a product.

The Linux Open Source guys do not get very interested at all if development code sources are not published and GPL licences are abused.
This can kill a product's community support outright, especially when it comes to Kodi or LibreELEC.

Exhibit A, would be Rockchip from years past.

AMLogic S912's have no open sourced Linux Mali-T820 GPU drivers.
S905 was chosen for Gigabit Ethernet.

Yep - though the K2 is S905 based ?

[wesk05]

The tvservice response seems to suggest that it outputs Frame Packed. If I get a chance I'll have a look. My AVR may well tell me the difference.

Perhaps I'm misunderstanding what say, so my apologies in advance if that is so. But... the Pi apparently transmits the decoded 3D videostream with FramePacking method, even for HTAB and HSBS, like seen here:
Somehow the Pi or Odroid would still need to tell the TV, whether it has to turn on SBS or TAB 3D in its FramePacked mode. Or does the TV detect SBS or TAB depending on blank lines in vertical or horizontal and switch to the corresponding mode then?

I checked this again on the Pi2. When you enable "Use Full HD modes for 3D" the output is Frame Packing for all 3D formats. When you disable the "Full HD 3D" mode, the output can be H-TAB/H-SBS. H-TAB triggers 3D mode automatically, but H-SBS seems to be iffy. It doesn't work always.

[infinity85]

[..]

AMLogic S912's have no open sourced Linux Mali-T820 GPU drivers.
S905 was chosen for Gigabit Ethernet.

And I thought that Mali GPUs had open source drivers, since odroid has also a mali, though an old one. Good to know now! However S912 should have got GBLan integrated afaik. It's about time to see some good SOCs with USB3.

[...]
I checked this again on the Pi2. When you enable "Use Full HD modes for 3D" the output is Frame Packing for all 3D formats. When you disable the "Full HD 3D" mode, the output can be H-TAB/H-SBS. H-TAB triggers 3D mode automatically, but H-SBS seems to be iffy. It doesn't work always.

That's it. I always ticked this use Full HD 3D Modes, since I didn't see any issues with although mostly playing H-TAB material on my passive TV. Thanks for pointing that out.

[aiko]

Can anyone here advise if this device can decode chroma subsampling 4:2:2 or 4:4:4?

[noggin]

Can anyone here advise if this device can decode chroma subsampling 4:2:2 or 4:4:4?

No hardware acceleration for 4:2:2 or 4:4:4 content - so realistically no.

There are no (Kodi-friendly) ARM SoCs that I know of with support for 4:2:2 or 4:4:4 decode - presumably because all regular consumer video (*) like DVD, Blu-ray, DVB/ATSC/ISDB broadcasts are MPEG2, H264 or H265 with 4:2:0 subsampling.

I HAVE seen some non-Kodi boxes that do MPEG2 4:2:2 in hardware (one generation of the Western Digital WDTV Live boxes for example) but support is vanishingly rare. I end up CPU decoding on Intel when I need to play 4:2:2 stuff (or off-line transcoding to 4:2:0). For 1080/50i 4:2:2 content I de-interlace to 1080/50p and re-encode to 4:2:0 to retain the chroma resolution.

[wrxtasy]

A few more bug fixes in this release:

- Kodi 17.2RC1
- Using S905 standard Kernel Audio code this time..
- AML ALSA Kodi Audio patch using an old Codesnake Davilla aka MrMC workaround
- @kszaq trial fix for Dolby Atmos passthrough & more.
- A few video playback improvements and GUI improvements
- the 'Fake it" Fractional display modes in Kodi Video Output settings shown.
So as to not confuse RPi upgraders wondering if AML supports 23.976, 29.97, 59.94fps video output (AML uses Frame Rate Automation BTW)

- known widespread playback bug - an annoying random stalling of video playback when skipping backwards thru video.

LibreELEC-Odroid_C2.aarch64-8.0.1.Audio.fixes.tar

W.