<div dir="ltr"><div><div><div><div><div><div>I have a Habey EPC-6568, I believe this meets all of the OP requirements since:<br></div>- SFF<br></div><div>- fanless<br></div>- decodes 1080i with Advanced detinterlacing (on board nvidia chipset)<br>
</div>- Low power: 20w idle, 26w during video playback as measured from the wall. Cron to power off at night/restart in the am<br></div>- Low cost (~$250US with memory as I recall. I netboot so no hard drive)<br></div><div>
- Prebuilt (just add memory)<br></div><div><br></div>An added bonus is that it's built to run digital billboards so it's durable. I've had it out on my porch for 2 years in a cabinet with a small ventilation hole and no fan. I live in an area with very high humidity and it routinely reaches 100F in the summer.<br>
<br></div><div>Its the best solution I could find a few years back, and from reading this thread, still may be until new technology arrives. The particular model I bought is discontinued but I'm sure there's a new one now.<br>
</div><div><br></div><div>Dave<br></div><div><br></div><br><div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 1:27 AM, John Morris <span dir="ltr"><<a href="mailto:jmorris@beau.org" target="_blank">jmorris@beau.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, 2013-06-06 at 00:48 +0000, Gary Buhrmaster wrote:<br>
> Some thoughts:<br>
><br>
> - Few of these ARM devices can do hardware temporial/spatial<br>
> de-interlacing. Interlaced content is common on many<br>
> locations. None of the ARM devices with their limited<br>
> capability decoders (that I am aware of) can do High<br>
> Def content temporal/spatial de-interlacing in software.<br>
> That may be fine on a 4" screen, where either low<br>
> resolution bob/weave can be acceptable (or even throwing<br>
> away every other frame), but is may not be acceptable on<br>
> that 65" OLED (your tolerance to low quality will vary)<br>
><br>
> - Some of the hardware decoders have no linux driver<br>
> support.<br>
<br>
</div>Most have no proper Linux support. Initial attempts at open source<br>
drivers for a couple but nothing production ready yet. I have read of<br>
some people getting the binary blobs distributed with Android going on<br>
some, but haven't heard about accelerated video decode, only EGL. After<br>
all, modern desktops are pretty much useless without 3D so that seems to<br>
be the initial thrust of development. Had hoped that at least one<br>
vendor would have realized there was enough of a market from us Linux<br>
folk they would have at least released an Nvidia style binary blob that<br>
fully supported their device under X. Alas.<br>
<br>
But I suspect there ARE chips that can do quality video playback. Too<br>
many consumer video products are using many of the same SoC elements,<br>
including BluRay players. The cut down ultra low power parts that go to<br>
phones might not produce perfect playback on a large TV but I was<br>
talking about units marketed as settop boxes. I'd expect them to have<br>
pretty good hardware video since software decode, deinterlace, etc. is<br>
pretty much out of the question on an ARM.<br>
<div class="im"><br>
> - Mythfrontend has a lot of capabilities that simply<br>
> require a lot of processing power. That means<br>
> large(r), and needing more resources. While it<br>
> certainly could be slimmed down, one would first<br>
> have to agree on what one should throw out.<br>
> That might be an interesting conversation to<br>
> start. What features should a frontend have?<br>
> Clearly (from other posts) some find the XBMC<br>
> feature set adequate. While some others<br>
> want more and more features added to the<br>
> frontend. Can the community agree on what<br>
> features you want to deprecate, or what content<br>
> types you are willing to abandon.<br>
<br>
</div>Not really. Unless you are talking about non-TV plugins like MythGame,<br>
the basic frontend shouldn't consume much in the way of resources. Even<br>
the browser wouldn't be a problem. The use case these machines are sold<br>
for includes running a browser after all... in an environment mostly<br>
written in Java; Qt is slim compared to that sort of resource waste.<br>
Modern ARM parts are more than fast enough for drawing a UI. And would<br>
make running a FE without moving parts very achievable without being<br>
expensive.<br>
<br>
But like I mentioned earlier, transcoding and commercial detection would<br>
be an issue on a combined FE/BE. It could probably manage commercial<br>
detection, it would just take longer. Transcoding might need hardware<br>
assistance, and it certainly would if you wanted to stream via http.<br>
<br>
All we need is somebody to sell hardware that a mainstream distro can<br>
run on and actually use the full hardware feature set. And that seems<br>
to be a showstopper for now.<br>
<br>_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/listinfo/mythtv-users</a><br>
<br></blockquote></div><br></div>