Posts by noggin

The serial UART handling on the Pi 3B and 3B+ (and Zero W) changed compared to previous models to allow for the internal Bluetooth.

If the OP has previously enabled it on a Pi2 or lower then there is a change.

I have found this pi 3 - How do I make serial work on the Raspberry Pi3 , Pi3B+, PiZeroW - Raspberry Pi Stack Exchange :

Quote

The BCM2837 on the Raspberry Pi3 , Pi3B+, PiZeroW has 2 UARTs (as did its predecessors), however to support the Bluetooth functionality the fully featured PL011 UART was moved from the header pins to the Bluetooth chip and the mini UART made available on header pins 8 & 10.

This has a number of consequences for users of the serial interface.

The /dev/ttyAMA0 previously used to access the UART now connects to Bluetooth.

The miniUART is now available on /dev/ttyS0.

In the latest operating system software there is a /dev/serial0 which selects the appropriate device so you can replace /dev/ttyAMA0 with /dev/serial0 and use the same software on the Pi3 and earlier models.

For some bizarre reason the default for Pi3 using the latest 4.4.9 kernel is to DISABLE UART. To enable it you need to change enable_uart=1 in /boot/config.txt. (This also fixes the core_freq so this is no longer necessary.)

Display More

The new release looks great. Still some issues with deinterlacing h.264 1080i25 (aka 1080/50i) content though.

Both Freeview HD (which is 1080i25/1080p25 dynamically on-the-fly switched) and Freesat HD (which is permanent 1080i25) are doing strange things - almost shot-by-shot the deinterlacing is switching from either TFF to BFF (so suddenly motion gets jerky) or from treating the content as interlaced to progressive.

Just installed the latest update and my Rock64 is correctly flagging HLG HDR to my Sony UHD TV.

Unlike other bits of kit (Amazon Fire TV Stick 4K and Roku Streaming Sick Plus) that needed an HD Fury Vertex in the way to add an HLG Support Flag via EDID (not sure why - an EDID dump of my UHD TV EDID shows it is flagging both PQ and HLG EOTF support) - the Rock64 works fine connected direct.

Unfortunately I can't get MPEG DASH streaming to work to test it with the live iPlayer test stream here :

uhd_stream_05.mpd

Quote from RayW

Would love to know a legal way then to watch UK TV as I am really willing to pay for a legal internet service as I really do need my UK TV service here reliably and legally too.

There is no legal way of watching BBC One/BBC Two/ITV/C4/C5 outside of the UK apart from the cable companies in Benelux, Switzerland etc. who have a formal agreement with UK broadcasters to retransmit their services. (Unless you are a member of UK armed forces...)

The BBC only negotiate UK and Ireland Public Service Rights for content they broadcast - be that bought-in or co-produced shows, shows they commission from independent production companies (which is most BBC drama these days), and music, archive, stills, talent etc. they include in their own productions. A key element to this is 'Public Service'. Once the BBC start selling content commercially, the rules change radically... (Their Public Service Rights contracts include a small clause that allows for small-scale Benelux/Switzerland 'cable rights') It is totally against the contracts the BBC have signed to make their content available outside the UK - in fact it is now incumbent on the BBC to mitigate illegal viewing I believe (by blocking commercial VPN providers)

The BBC negotiate separate deals on content to allow their shows to be re-sold (in some cases re-editing them to remove music, stills, archive they can't afford to commercially licence) overseas or on their non-UK commercial channels (BBC Brit, BBC Knowledge, BBC Entertainment etc.)

Implementing an internationally iPlayer that the BBC can legally operate is a non-trivial task, and would cost a significant amount of money. The experimental International iPlayer service (I think it ran in Australia) wasn't a success...

Deeply dull - but if you have an IPTV service available outside the UK offering you BBC One, BBC Two, ITV, C4 or C5 - it's very likely to be an illegal service...

CvH I've DM-ed you a Dropbox link to three Freeview HD interlaced recordings.

Quote from CvH

Could you grab an stream sample (.TS)?

Yes - will do that now. BBC One HD and ITV HD are both on PSB3 and both use the i/p switching encoders - recording both now during News shows which include native interlaced content. Also recording an entertainment show this evening on BBC Two HD that is native interlaced.

My experience seems to be :

MPEG2 576i25 content on BBC One SD - also known as 576/50i - with native 50Hz interlaced motion is de-interlaced correctly to 576p50 and scaled - as would be expected.

H264 1080i25 content - also known as 1080/50i - with native 50Hz interlaced motion (actually the same sports match on BBC One HD) is jumping around all over the place between correctly deinterlaced and incorrectly deinterlaced. I got some fluid motion, followed by jerky reverse field-dominance motion (where the fields look to have been temporally swapped over and thus you get worse judder than just i25->p25 rather than i25->p50 deinterlacing)

(One thing that MAY be an unusual use case on UK DVB-T2 H264 HD content is that the H264 encoders used dynamically switch between 1080p25 and 1080i25 (MBAFF) on a GOP-by-GOP basis based on the content feeding the encoders (this is done by the encoders dynamically detected intra-frame motion and switching to 1080i encoding if they detect it, but if there is no intra-frame motion and the content is 1080p25 within a 1080i25 wrapped - the encoders switch to p25 encoding for that GOP) This has been the case for many years on UK HD DVB-T2.)

Quote from djnice

Thanks for your test, I noticed all of the MBAFF interlaced videos are wrong (25i, 29.97i too).

Yes - all UK HD TV broadcasting is MBAFF. UK Freeview HD also uses dynamic, on-the-fly, 1080p25/1080i25 encoder switching based on source content.

Thought I'd give the LibreElec (Leia) v8.90.007 Alpha a go. I'm testing via a Denon UHD (HLG/HDR10/DV friendly) AVR and into a Sony UHD HDR TV. (XF9005 aka X900F)

Positive aspects in italics, negative aspects in bold

Frame rate and resolution switching via the the Whitelist works well - 720p output at 720p, 1080p output 1080p, 2160p output at 2160p.

CEC control worked with remote commands from my TV passed to LibreElec, and volume commands passed from LibreElec to my AVR.

2160/23.976p 10bit HEVC Rec 2020 HDR10 HDR content was output at 2160/23.976p 12-bit 4:2:2 Rec 2020 correctly flagged as ST.2084 EOTF (i.e.HDR10). However it looks like the HDR10 average/peak light level metadata wasn't passed (my HD Fury Vertex flagged them as 0/0)

2160/50p 10bit HEVC Rec 2020 HLG HDR content was output at 2160/50p 10-bit 4:2:0 Rec 2020 flagged as SDR, not flagged as HLG. (I've not seen any Kodi device flag HLG as HLG yet)

Audio passthrough of any bitstreamed audio caused nasty stuttering noise to come via my amp - rather than triggering the amp into passthrough. Disabling passthrough I got 48k/16bit PCM 2.0/5.1 etc. output

1080i25 H264 BBC One HD recorded native interlaced content from DSat (permanent 1080i25) was deinterlaced with the wrong field dominance so was very juddery, at least at times.

Watching Live TV SD MPEG2 576i25 native interlaced stuff seemed to be OK for the brief period I watched.  Live TV HD H264 1080i25 native interlaced stuff seemed to drift between correct and incorrect field dominance deinterlacing

Yes - there are a lot of changes going on in the UK at the moment.

COM7 and COM8 - the two 'temporary' HD muxes that seem to have lasted for quite a while (they carry BBC News HD, BBC Four HD/CBeebies HD etc.) are migrating to a UK-wide SFN (Single Frequency Network) on channels 55 and 56.

(This is out-of-band for many existing aerials - so if your analogue-era aerial was fine for Freeview, but you find you've now lost some of these channels, it could be because your aerial is now not effective enough at their new frequencies. We've lost both muxes in West London from Crystal Palace - presumably because we have a 20+ year old Group A aerial...)

Quote from HiassofT

Another big plus of the TV uHAT is that it works with the stock Linux kernels out of the box - no need to mess around with the out-of-tree DVB drivers.

so long,

Hias

Yes - and as it is a full HAT with an onboard ID EEPROM - it identifies itself automatically so not even a need to manually edit config.txt to add a device tree.

Hi all

Just to let everyone know that the new DVB-T/T2 Raspberry Pi TV uHAT (released recently by Raspberry Pi) works fine in recent builds of LibreElec on a Pi 3B+ (it works on a Zero too - though it's a little sluggish) with the standard LibreElec TV Headend server.

The TV uHAT is neat, as it uses an SPI connection to the Pi, rather than using the single USB bus, so it removes the DVB I/O from that bus (which can be a bottleneck). It will stream a full DVB-T/T2 mux across the SPI - so you can stream (and I guess record - subject to USB bandwidth if you're recording to USB storage) all the channels on a given mux. In the UK this is neat as all the main 'big 5' HD services are on the same mux (PSB 3/BBC B)

It's pretty good value at £20incVAT

If you are looking for a neat, single DVB-T/T2 tuner it's worth a look.

Quote from Flole

The image was LibreELEC-TinkerBoard.arm-9.0-nightly-20180709-2f5a3b0-rk3288 found on the testing page. I have already removed it from my sdcard, and if you consider it "no problem" I'm totally fine with that. Good luck trying to find someone who agrees with you and likes to watch slowmotion video where audio and video are completely out of sync.

You are missing the point I think.

You're running an alpha release of software that is actively being developed and in doing so you are effectively agreeing to help developers fault find it, as they are sure it has loads of bugs in it (that's what running Alpha software is all about)

For your fault report to be investigated you need to upload a log for developers to have any hope of fixing it. That's the quid pro quo for developers making nice stuff that we get to use for free...

You'll find no log = no problem is a common attitude for developers here. Log files are vital to troubleshoot issues - as they tell developers far more about an issue.

Apologies for necro-posting - but I've been playing with this on a Pi 3B+ with an Adafruit 128x128 1.5" OLED display (SPI and supported nicely by fbtft)

This plugin is really encouraging - did it move forward?

Quote from MadScientist

Getting the graphics version recognised would be a big step forward. However, is there a version of LE that handles HDR10 correctly and forwards the required flags to the display? If not, there's little point in taking things forward when there are more established solutions around.

If you want HDR10 support under Linux, you are currently pretty much limited to ARM solutions.

The AMLogic S912 and S905X both support HDR10 flagging and up-to 2160/60p HEVC decode and output.

For x86 HDR, at the moment you are stuck with Windows, and it's not as straightforward.

At the moment I've not seen anything that flags HLG HDR output over HDMI, though hopefully as HLG takes off this will change.

The BBC iPlayer is doing a number of 2160/50p HLG HDR shows this year I believe, and have already shown Blue Planet II and a minor live Rugby League match (as a quiet test) this year.

Quote from chewitt

Kodi supports 'status' output to VFD type displays but there's no function for external controls like that.

At one point weren't there LCDProc drivers for simple VGA screens? (At least on PCs)

AIUI the Pi + Touch screen + HDMI is more complex, as whilst you can run both separately (as you can HDMI and a GPIO VGA/LCD screen) there are quite heavy limitations (one is really only available for OMX?)

Quote from tuep

It's a Samsung LE40C750.

I am assuming the TV is just fine. With raspberry there have been never issues like that.

Ah - I thought you were running 4K. My bad.

Quote from tuep

So beside the issue with loosing the hdmi output which can be luckily fixed also by restarting tv instead of pulling cables I still have another issue with this build.

Under Milhouse build I could enable 25Hz mode. With your Build piotrasd I don't have to work with the whitelist but the 25Hz mode is not available. This leeds to stuttering playback when the display mode is set to 50Hz I don't know why this is, because it should just display a frame two times, but it is very noticeable and not possible to enjoy.

Edit: I tried to get everything as much as to default as possible. So I deleted my autotstart.sh, I created the xorg.conf like you suggested, run getedid delete, and later getedid create.

Now I have output on start, the 25Hz movies are still displayed with 50Hz but now the stuttering is gone. If the driver patch comes, it is nearly perfect, beside one bug.

But on one movie I have a new bug that during playback a mouse cursor appears in the center of the screen.

You don't have a Panasonic OLED TV do you? There have been known issues with some models in 50Hz mode - enabling GAME mode removes them (but then displays 24p at 3:2 60p)

There's also a known issue with the Sony XE900 series in 50 and 59.94Hz modes where pairs of frames are dropped, then different pairs are repeated (as a pair - so you get a motion judder on native 50Hz stuff) It usually happens on cuts. GAME mode removes it... (Sony are about to swap out me XE9005 for an XF9005 because of this)