[mythtv-users] Raspberry Pi now ships with 512MB RAM

[Leigh Anthony]

On 17/10/2012, at 2:00 PM, Michael T. Dean wrote:

> On 10/16/2012 04:35 PM, Jay Ashworth wrote:
>> From: "Michael T. Dean"
>>> +1 ... You can't consider your frontend low-power when it relies on an
>>> extremely-power-hungry backend running all the time.
>> I rarely disagree with you, Mike, but I'll make an exception here. :-)
>> 
>> You can if your backend is supporting 10 or 12 $35 front ends all around
>> your house.  And I think "extremely power hungry" was a bit of a strawman,
>> anyway.  ;-)
> 
> The post I quoted and agreed with (that you've cut out) was one that said it's not a good idea to have a huge backend transcoding every single recording from MPEG-2 (or whatever) to H.264 just so you can use an RPi frontend with its built-in hardware H.264 decoder.  At that point, you /must/ consider some portion of that backend power usage as frontend power usage because the only reason for the transcoding is to allow the use of a poor-choice of frontend.  Granted, it's even worse idea when you can get an MPEG-2 license for the RPi for a couple bucks, but the point is that when the backend is constantly running at 100% to do a slower-than-realtime transcode of all content to H.264 just so you can use an inappropriately-chosen frontend system that can't play back "normal" content, you shouldn't be considering that frontend to be low power.
> 
> And, yes, a system that's transcoding everything to H.264 (versus storing it in its native recording format) does make for an extremely power hungry system.
> 
> Mike

I've tried to work out a scenario for transcoding everything (Australian TV is all mpeg2 and my touchpad won't do that) but its quite hard, even with plenty of power available.

You don't really want to not be able to watch live TV or have to delay watching something because its hasn't finished transcoding.

What you really want is on-the-fly transcoding (ffmpeg & mpeg4 rather than two-pass h264, probably), but where the transcode is saved back to the server as well as being served up to the client.

You also want the server to be able to pause transcoding if it is no longer being watched, otherwise you could quickly max-out the cpu by starting to watch multiple programs.

It might be nice to pull in frontends or a desktop to handle some of the work (if they are strong enough and switched on) but you can quickly max out your network bandwidth doing that - especially if your frontend is a wireless at the other end of the house.  Your backend has no way of knowing you are trying to copy an ISO at the same time as it wants to send a file to & from a frontend for transcoding.

The best solution is for the tv networks to add h264 versions of their mpeg2 channels!

In the interim, I leave everything as mpeg2 for TV (transient) recordings and only convert long-term content to mp4 - films for the kids to watch on the tablet or streamed to a frontend running vlc over http.

I do have a power-hungry backend, but I console myself with the fact that its about the same as a single bright lightbulb.  Compared to the electric oil heater sitting next to me  or boiling the kettle for a hot drink or making a batch of granola in the oven, its fairly trivial.

Leigh