Talk:MythTV on Mac x86

From MythTV Official Wiki
Revision as of 20:22, 2 June 2008 by Rjbrown99 (talk | contribs) (Front Row Integration)

Jump to: navigation, search

Page tidy-up

Isn't a lot of the information on this page redundant now, since 0.20 is out, and builds with additional patches? I think I'll try a tidy up in a few hours, if I've the time.

(tji) Yes, you're right. I cleaned up some of my stuff.

I've shifted a few of the sections around, and I was contemplating losing the 0.19 stuff altogether. Is anyone going to be building the older versions of the code? Particularly as there are some binaries that can be downloaded if you really need them. Also it seems to me that sometimes there's useful information on the topic that's stuck in this discussion page, that should really be on the page itself. What do people think? Bailey 10:41, 29 September 2006 (UTC)

(tji) I would recommend leaving the 0.19 stuff there. A lot of people lag behind a version or two, and since 0.20 pretty much just works, there wouldn't be much info without the 0.19 stuff. I moved the MMX section on the article down to the 0.19 section. The 0.20 release now correctly recognizes the Core CPUs and sets the MMX flags correctly. They also updated the MMX assembly, so the patch is not needed, and the MMX colorspace code was added late in the cycle.

Plugin Support

How do you get plugins installed on this frontend?

(nigel) The script bundles up all the plugins that currently compile.

Mac frontend status / development discussion

  • Several people have reported problems displaying HD video on a very high resolution display, like a 1080p LCD panel. I replicated this with my MacBook Pro, but the cause is not clear. Is anyone else seeing this issue?
  • Core Video - A patch to add Core Video video output has been submitted. This may be able to take advantage of some of the more advanced GPU capabilities in the future.

Apple Remote Support

Just wanted to check if there has been any progess on making the apple remote work? Would it be possibly to some how use a different remote with the built in IR port with LIRC or something?

UPDATE: This is now possible using Remote Buddy

Note: Remote Buddy performance during playback is sluggish (~15 second delays). Better results using "Single key press on button press" option, but still not as responsive as using the built-in support & apple remote

(kraney) I've created a patch that adds native support for the apple remote to mythfrontend. The patch and a more detailed description can be found in the mythtv trac ticket

(Bailey) The aforementioned patch made it into the 0.20 release, so the remote works out of the box.

Binary Packages?

File Version Options Download link
1 (Tux541) 0.19-fixes without MMX mythfrontend
2 (tji) 0.19-fixes With MMX MythFrontend-MMX
3 (mmead) 0.19 With MMX Mythfrontend-0.19-intel-mmx.dmg.bz2
4 (mmead) 0.19-fixes With MMX Mythfrontend-0.19-fixes-20060407-intel-mmx.dmg.bz2
5 (mmead) 0.19-fixes With MMX and Apple Remote Mythfrontend-0.19-fixes-20060407-intel-mmx-remotepatch.dmg.bz2


(tji) My 1.66GHz Core Duo Mini handles both 1080i and 720p material with plenty of CPU headroom left (65-80% CPU utilization of one core). My display output resolution is 720p, and in this setup everything appears to work well, smooth video with deinterlacing, no obvious tearing or judder effects. I had a lot of issues with HD playback on my Linux+Nvidia frontend box, and have found the Mini to have better playback quality.

All Intel-based Macs should be at or above the speed of this Mini, so playback should be good - other than the below mentioned high resolution issues. The one exception to this is the short-live "Core Solo" Mini, with one core at 1.5GHz. Has anyone tried HD playback on one of these? Please report your results.

High Resolution Playback Issues 1080i & 1080p

(flaggz) It's a 1.66GHZ core due Mac Mini w/1GB RAM. The video hardware is the internal Intel GMA 950 that comes on the Mini. I only see the issue when my screen resolution is set to 1920x1080, which is weird because no scaling whatsoever should be required (it's 1080i material). I'm currently running at 1600x900 and the issue seems to be gone (performance is acceptable, but I haven't run shark to see if the YUV2RGB function drops out of the profile data at this res, yet). Obviously, I'd prefer to be at 1920x1080. tji and others, what resolution are you running on this hardware? Can you try 1920x1080 and see if you can reproduce what I reported above?

(nigel) The 1920x1080 material might actually be 1920x1088 or similar. They sometimes do that to make it divisible by 16 for the macroblocks or something.

(justin) I see very choppy performance at 1080i with file 4 on a 1.66GHz Core Duo mini. Turning off scale video as necessary results in much better performance, but standard def video becomes postage stamp sized.

(jesse) 1.66 Ghz core duo Mac Mini w/ 1GB RAM. 1080i LiveTV playback is perfect if I disable 'scale video as necessary', but if it is enabled WindowServer shoots to 30% CPU. The mini can handle the 30% cpu overhead for SD or 720p LiveTV, but the mini can't keep up the necessary frame rate for 1080i. What's strange is that my display is native 1080p so no scaling should be necessary. I'm using the 20070304 pre-built binary from .

(acronce) I've struggled since December 2006 to get reasonable 1080i performance on a 1.66 Ghz Core Duo Mini with 512MB of RAM using the stock 0.20 MythFrontend. After messing around in the code I found what I think are scaling related bugs that caused dropped frames at 1080i. I worked around these problems by changing the code. If you're interested, that effort is chronicled here: Unfortunately even though my code hacks fixed the obvious dropped frames problem, I ultimately got frustrated with interlace and tearing artifacts. So now I've fallen back to 720p and the stock MythFrontend.

(tji) Another possibly related playback issue was discussed on the Myth Mailing list ( ). But, that issue seemed to be related to internal displays and a high default refresh rate used, 150Hz.

(tji) I finally got access to a system with a high enough resolution display to duplicate the problem (1920x1200 display on an iMac). I tested the 150Hz refresh rate thing, and that had no effect. But, changing the 1080/1088 resolution recognition helped somewhat (more detail is available in the thread acronce references above).

(tji) A patch suggested by Mino on the mythtv-users list looks good in initial testing. Anyone else that can test/confirm the fix would be helpful. It gives a bit more tolerance in the non-square aspect ratio detection, to avoid the scaling issues.

Index: videoout_quartz.cpp
--- videoout_quartz.cpp (revision 14063)
+++ videoout_quartz.cpp (working copy)
@@ -307,7 +307,7 @@

     // scale for non-square pixels
-    if (fabsf(aspect - (sw * 1.0 / sh)) > 0.01)
+    if (fabsf(aspect - (sw * 1.0 / sh)) > 0.015)
         if (parentData->scaleUpVideo)

(ted) My experiences lead me to believe the scaling is the issue. I am running .20.2 on a 2 GHz iMac with a second 1920x1200 monitor. If I do not scale the output, 1080i streams play flawlessly. If I do scale, the image size changes (a couple of pixels taller) and playback becomes choppy. As I don't have the source (and am far more comfortable in Java than C), I can't say for sure that the code above fragment would fix it, but the concept seems on target. Rather than checking if the stream is exactly the resolution of the output device, allow for a tolerance [(resolution-stream)/resolution > 0.02 to set a 2% tolerance] and only scale if outside that tolerance.

Build Status

(JSP) is currently broken (When was this? script works fine for me. 5/23/07)

  • It tries to download libdecss, but it cannot. You have to edit the script to get around this. (the library can be gotten from fink)
  • The KDE install seems to be hard coded, I installed a KDE package for OSX, but it cannot find the headers
  • The installer README should probably indicate that you need to install X and KDE before running the script
  • From the messages, it looks like the backend build is disabled. Can this be enabled and still use the script?

I haven't had much time to spend debugging this, but I wanted to pass along this info.

(tji) My current status:

  • 0.20 Release:

Builds without any need for modifications, using the script. Performance is improved with the new mmx colorspace code, and the Apple remote works by default.

Occasionally I do find that download links fail, as JSP mentioned above. Either a version number is changed and the URL needs to be updated, or sometimes the host is not up or is no longer hosting the project. These issues can be addressed by going to the project page and selecting a new mirror host.

Front Row Integration

(~kraney) You can get the music on your mythbackend to show up in iTunes and Front Row using mt-daapd.

Macs also use DAAP to serve movies, but mt-daapd doesn't support that yet.

What would be nice is DAAP and DPAP support that get metadata from mythbackend or directly from mysql. It should be possible to get all of the myth music/gallery/video/tv content on the backend to show up directly in Front Row as 'shared' content.

Instructions for adding a "Front Row" menu item to myth are now on the Myth_on_Mac_x86 page.

(tji) How about the opposite of this, Adding a menu item to Front Row, to allow MythFrontend to be started?

(rjbrown99) Check the Firefly / mt-daapd page for an update - I believe the latest version and/or SVN tree now supports streaming video via DAAP.

iMac Leopard 10.5 Remote Control Support

The remote control doesn't work on Leopard. I've got it working fine on 10.4 but not on 10.5.

I'm going to try recompiling the latest release on my iMac.

Elgato Turbo.264 Support

Has anyone evaluated the use of the Elgato Turbo.264 USB stick with a Mac backend? This is a stick that has Mac drivers and takes uncompressed digital video and accelerates the encoding process to H.264 video. It does this via a QuickTime hook, so the encoder codec is available to any application that happens to call upon it. I have used it with the command-line with QT-Tools and it works fine. It also works with the Perian open source video codecs to help transform the input media stream. What I am hoping to do is to leverage this as a CPU offloader for encoding saved videos/shows.