Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The MythTV Thread



Rich Braun wrote:
> I hope to have some discussion here as the end of analog TV approaches in less
> than 6 months.  (Sometimes I get frustrated enough with MythTV that I wonder
> if there is any viable alternative; a co-worker suggested BeyondTV, and a
> friend uses AppleTV, but I don't see that those will deliver the convergence
> goals set out at the top of this message.)

Your message didn't get much attention the first time around due to the 
mail server crash, so here's a belated reply.


> Here's what I could use help with:
> 
> 1. The Number One Issue:  downconverting media (transcoding or by whatever
> technique), in a user-friendly way, so ANYTHING ranging from live HD feeds to
> VHS tapes dubbed to MPEG2 at 2 megabits/sec will play back on ANY frontend. 
> (In my setup, only the Core 2 Quad can handle everything; all the others have
> jittery video even with regular DVDs)

You can set up a user job for that, which MythTV will run automatically.

Of course transcoding can be error prone, resulting in anything from an 
unwatchable video to a crashed machine. I haven't gotten transcoding 
working reliably enough to automate it.

By transcoding for "universal playback" you'll also be trading off space 
efficiency for a format that is less CPU intensive for playback.

The ideal solution would have been to incorporate a capabilities 
negotiation into the MythTV protocol, and a real-time transcoder, like 
VLC, so any content can be viewed on just about any MythTV client. The 
mvpmc (custom firmware for the MediaMVP set-top-box) community has long 
wished for such a solution, as the hardware is limited to MPEG2 
playback. (Which requires storing all video in space inefficient MPEG2, 
or using VLC outside of MythTV to view content.)


> 3. My unencrypted Comcast channels show up black and unviewable.

I haven't deployed my HDHR digital tuner yet, but when testing it with 
Comcast I haven't noticed that.


> 2. The MiniMyth-based setups are prone to X11 crashes and sometimes other
> instability.
> ...
> 8. Aside from the underpowered EPIA motherboard, most useful frontend devices
> use a LOT of electricity and I need to figure out a way to conveniently turn
> them off and on (including any attached display/sound devices) via a remote.

The MediaMVP is very low powered, but it doesn't run the stock MythTV 
front-end. It has its own version of a MythTV client (with a UI that's 
in many ways superior in usability).


> 9. I'd love to be able to get some hard data and benchmark software for video
> performance using the different software settings (xvmc vs. ffmpeg vs. about a
> half-dozen others) and the different hardware (such as the CLE266 mpeg decoder
> on the old EPIA board).  Trial and error is very tedious/slow.

Sounds like a project for the MythTV wiki.


Jarod Wilson wrote:
> Rich Braun wrote:
>> (In my setup, only the Core 2 Quad can handle everything; all the
>> others have jittery video even with regular DVDs)
> 
> ...something's definitely awry if the c2q is the only thing that can
> handle playback. My daily use frontend machine for both hdtv playback
> and ripped dvd playback is a mere 1.66GHz core duo.

True, given that DVDs are just MPEG2, though they may be high bitrate. A 
MediaMVP with a mere 250MHz PowerPC (supplemented with MPEG2 hardware 
acceleration) can play back DVD content fine, usually. Check that your 
LAN isn't getting saturated.


>> 3. My unencrypted Comcast channels show up black and unviewable.
> 
> Could possibly be that you need to be using one of the other two us
> cable frequency tables (there's us-cable, us-cable-irc and
> us-cable-hrc). ...Comcast around here (Tyngsboro) was us-cable-irc...

HRC in my area. I was surprised to see that the digital signals were 
using an HRC frequency offset just like the analog signals. Doesn't make 
a whole lot of sense, as the frequency offset was used originally to 
avoid interferences with over-the-air broadcast frequencies, and there 
isn't an overlap between digital broadcast and digital cable. My guess 
is that they stick with HRC so the new digital channels can be placed 
next to the legacy analog channels while maintaining the same frequency 
spacing.

In any case, when I scanned for digital channels using the wrong offset, 
I just picked up nothing, as I recall.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org