Hi Torsten,
On 04.01.21 16:59, Torsten Duwe wrote:
On Mon, 4 Jan 2021 15:50:48 +0100
Stefan Seyfried <[email protected]> wrote:
Since VAAPI is buggy for MPEG-2, the current PC decodes it on a <1GHz
CPU core and sends it to the Radeon HD 6xxx (or so) for scaling. (H.264
does work via VAAPI and hardware)
OK, so if you have the software already hooked up for decoding, then you
might also have success with such a box and open drivers.
But beware that even the tuner drivers (or the "glue" demux and stuff)
are often closed source.
As you might remember, I come from the "I have drivers where I just
select audio and video PID and then issue VIDEO_PLAY ioctl" corner ;-)
I would probably use a raspberry pi with a SAT>IP box in your case (when
you are not limited to software that just does "ioctl(fd, VIDEO_PLAY)"
to get that PES stream decoded on the screen ;-))
I'm running a Telestar Digibit R1 SAT>IP box as a frontend for a
(headless) VDR box and sometime to experiment with VDR on raspbian
(there is both an SAT>IP input plugin and a rpihddevice output plugin).
Back then this was the cheapest way to get 4 DVB-S2 Tuners (for about
100€), this is now running since years without a hitch. Unfortunately
they seem to be no longer readily available, or only in dumbed down
versions.
Today with boxes like the ferguson available in the 100€ price range,
these could at least be repurposed as a SAT>IP server if the rest of the
hardware is a PITA ;-)
Panfrost is the code name for Mali-6xx / Mali-7xx GPUs in Mesa/kernel,
and I estimated a Cortex-A53 with ASIMD should be capable, with some
help from the T720MP, to decode H.264 in software. The specialised
video engine is an indicator that it would at least run a little hot
trying to do it this way.
Ok, but hooking this up for live tv might be complicated.
One even gets the choice between android TV, debian and enigma2.
Ferguson is a Polish company BTW.
Doesn't matter who sells the box, they are all the same AFAICT and IMVHO
they are all the same crap ;-)
The only difference is some more bling bling on the box, and some
vendors have drivers that crash less often or do actually get updates
from time to time.
But I would also not hope for a recent kernel, a documented boot
mechanism, good drivers.
And do not even dream about open source drivers ;-)
I did when I saw the mainline kernel support :(
Oh, the CPU runs probably fine with the mainline kernel. The ethernet
chip and the USB controller might actually work with it. It's just
highly unlikely that the pieces of hardware you want to use have even
drivers available.
Reminds me of some "SLES9 certified laptops" about 15 years ago. The
certification clearly stated that WiFI, bluetooth and graphics drivers
did *not* work (and so did power management) ;-)
But for the unlikely case that I'm wrong and the box has all that,
then I'd be interested to hear about your success, my STI7111 boxes
are growing old now and the platform is long abandoned by ST ;-)
Yes, it's hard. For the record: the runner-up company was Vu+, but the
only 64-bit box they made[1] is deprecated and I don't feel like
running Tumbleweed or building another 32-bit distro locally[2].
The only realistic way forward is building your own openembedded distro
anyway (i used yocto poky), so the 32bits should not matter.
OK, you could just use your own kernel and the vendors u-boot, and use
openSUSE userspace, but it would probably not be fun.
The next thing with 64bit is, if their drivers even work with 64 bit. So
if the openPLI and friends do not use 64bit OS, then you can forget
about that as well, because even if there are 64bit drivers, they are
completely untested.
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman