[mythtv-users] Secrets for low powered front ends ?
raymond at wagnerrp.com
Wed Oct 12 20:21:07 UTC 2011
On 10/12/2011 15:44, Patrick Ouellette wrote:
> On Wed, Oct 12, 2011 at 03:17:24PM -0400, Raymond Wagner wrote:
>> On 10/12/2011 14:22, Patrick Ouellette wrote:
>>> On Wed, Oct 12, 2011 at 01:53:10PM -0400, Raymond Wagner wrote:
>>>> Don't make the mistake that it is an "equivalent" system though. A
>>>> single 2.4GHz SandyBridge core is going to be considerably more powerful
>>>> than the fastest Atom chip on the market. The point were trying to make
>>>> is that should hardware decoding fail for whatever reason, you have
>>>> nothing to fall back on.
>>> Unless I'm using the system for commercial flagging& transcoding, that extra
>>> processing power is going to go unused. Since the purpose is a frontend,
>>> commercial flagging& transcoding are not going to be happening on it.
>> Yes. The frontend is to be used for playback. If you wish to play any
>> content other than what VDPAU offers support for, you need CPU power.
>> That means codecs not supported, codec options not supported, and even
>> some data corruption from a bad recording that ffmpeg can push through
>> but VDPAU chokes on. If you want to do flash video, which still does
>> not provide hardware accelerated scaling and colorspace merging, you
>> need CPU power. Having a worthwhile CPU offers the flexibility to do
>> something you may not have initially planned for, without having to buy
>> all new hardware.
> Please tell me *what* codec support I need *right now* that is not handled
> by VPDAU other than flash (which I don't watch on my television - I'm a member
> of the "flash is crap" club).
If Google is to be trusted, WebM and VP8 may become popular for web
video, stuff like MythNetvision is designed to handle. The bigger issue
is all the various options that codecs support. VDPAU supports H264
High, Level 4.1. If the video uses too many reference frames, you need
to apply a work-around, forcing the decoder to allocate more of the
GPU's memory for macroblock storage. There are certain reference frame
structures that are not supported. There are certain macroblock sizes
that are not supported. As far as hardware decoders go, VDPAU is
actually fairly permissive as far as these funky options go. The PS3 is
far more limiting.
MPEG2 and VC-1 each have their own wide range of options of which a
hardware decoder can only support a certain subset. While you will
generally be fairly safe in these regards to broadcast TV and Bluray,
you may not be so lucky with things like video cameras, and you
especially have to be careful if encoding your own material.
> If you follow the logic train of "I need to future proof the system I buy" you
> will never buy anything.
Futureproofing is done by having a decent amount of CPU power. Hardware
decoding is great. It lets the CPU idle in low power mode, while
efficiently handling all the decoding tasks. Hardware decoding is
inherently limiting, and can only do what the chip was initially
designed to do. CPU decoding can do whatever the software is capable of
so long as there is sufficient CPU. The software can be upgraded for
free with an FFMPEG sync, while replacement hardware needs to be purchased.
> Data corruption is a red-herring argument, it can and will "adversely affect"
> any system.
Data corruption will happen, and I'm not talking about bitrot, but blips
in transmission or reception of TV. Hardware decoders will not be as
forgiving as software decoders. If FFMPEG hits some garbage data in a
recording, it will just skip over it and continue. If VDPAU hits that
same garbage data, it may crash the player, dropping you back to the menu.
More information about the mythtv-users