[mythtv-users] Lowest power HD frontend?

[Joseph Fry]

On Wed, Jun 5, 2013 at 8:48 PM, Gary Buhrmaster
<gary.buhrmaster at gmail.com>wrote:

> On Wed, Jun 5, 2013 at 11:25 PM, Joseph Fry <joe at thefrys.com> wrote:
> ...
> > I wonder if any of these would fit the bill:
> >
> http://dx.com/c/consumer-electronics-199/hd-media-players-103/android-hd-players-191
> .
> > I know Ubuntu will install on some android phones/devices... though I'm
> not
> > sure how it would work on these.
>
> Some thoughts:
>
> - Few of these ARM devices can do hardware temporial/spatial
>   de-interlacing.  Interlaced content is common on many
>   locations.  None of the ARM devices with their limited
>   capability decoders (that I am aware of) can do High
>   Def content temporal/spatial de-interlacing in software.
>   That may be fine on a 4" screen, where either low
>   resolution bob/weave can be acceptable (or even throwing
>   away every other frame), but is may not be acceptable on
>   that 65" OLED (your tolerance to low quality will vary)
>

> - Some of the hardware decoders have no linux driver
>   support.
>
> - Most of the TV's mentioned have dedicate hardware
>   decoders (and post processing HW), without the
>   additional overhead of all the GPU that nVidia
>   offers (when doing just decode, only a small
>   dedicated part of the GPU chip is being used,
>   although as implemented by nVidia, the GPU is
>   used for deinterlacing, so one ends up needing a
>   powerful GPU).  There are chips available on the
>   market for hardware decode and encode (and
>   would make great small, cheap, low power
>   transcoders) with advanced de-interlacing capability.
>   Those chips are often used in dedicated solutions,
>   including TVs.  Note that there are also some
>   FPGA cores available if you are into build your
>   own FPGA solution (probably not scalable).
>
> - Alternatives are to transcode all content to
>   progressive (either immediately at capture,
>   or post-processing).  In any transcode, there
>   will be some quality loss, some of the time,
>   and some people will find that unacceptable,
>   or will not be happy about the time or resources
>   needed on the transcoding host.
>

Agreed, however, assuming that the device can support it, you could output
an interlaced signal and let the TV handle the deinterlacing... as it would
have if it had received the transmitted signal in the first place.  I know
some people don't like their TV's deinterlacer, they can always opt for the
"fat" frontend.


>
> - Mythfrontend has a lot of capabilities that simply
>   require a lot of processing power.  That means
>   large(r), and needing more resources.  While it
>   certainly could be slimmed down, one would first
>   have to agree on what one should throw out.
>   That might be an interesting conversation to
>   start.  What features should a frontend have?
>   Clearly (from other posts) some find the XBMC
>   feature set adequate.  While some others
>   want more and more features added to the
>   frontend.  Can the community agree on what
>   features you want to deprecate, or what content
>   types you are willing to abandon.
>

I agree that cutting features is a VERY hard thing to do.  What is easier
is to do create a "light" version or versions, or make some features easily
disabled (which is already the case for the most part).

Most of the features that the frontend has over, say XBMC, are not
particularly demanding features... organization, media management, etc.  In
fact the most demanding thing I can think of on my frontend is actually
more of a function of the theme rather than the frontend itself.  Things
like channel icons, coverart, etc.

While I hate to say it, because I actually like the MythFrontend interface,
but I would love to see some serious development to getting XBMC to the
point where it can replace most of the functional capabilities found in
mythfrontend.  The ONLY reason I would like to see it is to leverage the
large pool of developers working on getting good playback on such a broad
range of devices, not to mention their theme developers (though I like the
themes I use).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130605/c8937f6c/attachment.html>