<br><br><div class="gmail_quote">2009/3/17 Nick F <span dir="ltr"><<a href="mailto:nikos.f@gmail.com">nikos.f@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Tue, Mar 17, 2009 at 9:02 PM, Chase Douglas <span dir="ltr"><<a href="mailto:chasedouglas.lists@gmail.com" target="_blank">chasedouglas.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">This leads me to the following question: Given the pros and cons of each approach, what would other LIKELY users of an iPhone MythTV frontend prefer to see implemented?<br>
<br>Built-in:<br>* High quality (h.264 level 3 + mp3 or aac-he, full resolution and framerate, high bitrates)<br>* Low battery consumption<br>* No commercial skip<br>* No extra controls (for changing channels, etc.)<br><br>
Software Decoding:<br>* Full commercial skip support<br>* Overlay controls are possible<br>* Lower quality (though still very acceptable)<br>* Very high battery consumption<br></blockquote>
</div><div>As an iPhone user - I'd love to see a frontend for it. I'd vote for the 'built-in' decoding though and sacrifice the comm skipping and extra controls. The quality, battery life (and stability?) using the apple player swing it for me.</div>
<div> </div>
<div>(Thanks in advance for doing this!)</div></div>
<br>_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
<a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>
<br></blockquote></div><br>I'll second the vote for the Apple player using the hardware decoding. I'd rather have a partially featured system that worked well, looked good, etc. The other approach would be cool to play with, and probably a more interesting project, but in the end, it wouldn't be all that usable if it killed the battery quickly. If you really wanted commercial skipping, you could incorporate that into the transcoding part on the backend. It wouldn't be perfect, but it'd be better than nothing. <br>