Difference between revisions of "Technical Directions On OSX"

From MythTV Official Wiki
Jump to: navigation, search
m (consolidate redundant Mac categories to MacOS)
((Badly) Outdated)
Line 1: Line 1:
{{Outdated2 | Many of the concerns expressed on this page have been addressed in recent releases.  This page should be substantially revised or deleted.}}
= Qt Version =
= Qt Version =

Latest revision as of 01:47, 10 March 2016

Time.png Outdated: Many of the concerns expressed on this page have been addressed in recent releases. This page should be substantially revised or deleted.

Qt Version

MythTV use of qt-opensource-mac (32 bit) should be replaced with the new Cocoa-native version of "Qt for Mac" (32-bit) ( http://qt.nokia.com/products/platform/qt-for-mac ) because Nokia likely will or has discontinue(d) qt-opensource-mac. Simply transitioning to Cocoa-native Qt will not fully permit 64-bit Myth applications though.

We should make a conditional 32-bit/64-bit MythBackEnd/JobTools? (just by switching to Qt 4.6, which is not a recompile but also not weeks of code) and probably leave MythFrontEnd? alone (to preserve all of their hard work on the PowerPC DVD chip support, etc. and all the gorgeous hardware it supports) as 32-bit forever, forking off a new branch of to become the Cocoa version (Qt 4.6) that will later go on to become 64-bit.

Video Playback Optimization

The mac port of MythFrontEnd? on 10.6 should detect its on a Mac, query the database for current playback video settings and prompt the user if it wants to initialize them to the most optimal profile (because there are only 2 or 3 different video chips used by the various Macs, as opposed to infinite hardware/X11 combinations for the other platforms.) Presently, the user is left to experiment and may get it wrong, without looking at the source code to find out what's been optimized. This needs to be done at runtime, but it is an osx-packager.pl type artifact (because osx-packager is selecting the ffmpeg, x264 build-settings, etc.) Not something anyone else could do.

Switching Calls from Carbon to Quartz and Cocoa

Thus to complete transition to 64-bit, aside from transition to Qt for Mac, as neil/astralbodies and others know, we need to fork the code so the Intel versions that make direct calls to 32-bit-only Carbon API (ie, to show/hide the Mac menu bar, etc..) instead call equivalent Cocoa or Quartz APIs (though it would be nice if the PowerPC version could remain indefinitely, especially in light of the three years of work they did on the DVD-hardware decode); however,

Newer OSX Technologies

OpenCL and Grand Central Dispatch

In Snow Leopard, there is a new Mac OS X API to allow general purpose code to run on the GPU (OpenCL) and to better exploit SMP (Grand Central Dispatch).

QuickTime X

But rather than re-factor the MythTV code to run in those APIs (thereby diverging significantly from the other platforms), it might make more sense to use another new feature of Snow Leopard, QuickTime X, that already exploits the former two technologies. (See also http://www.apple.com/macosx/technology/ ) In other words, while removing all 32-bit-only Carbon code from the Intel-only version of MythTV, MythTV could replace the video-decode + playback feature with calls to QuickTime X Internet Streaming, keeping the Qt-for-Mac on Cocoa code just for the non-playback UI.

Rendering comments

This might involve scaling the playback-window to inset within the Program Guide and rendering the !MythTV OSD (menu, guide, program-info but not closed-captioning) into the MPEG stream being fed to QuickTime X (using some kind of software-genlock/multiplexer ala Video LAN Client does).

Potential For Encrypted Streams

Lastly, if there is any hope of EVENTUALLY getting CableCARD or Switched Video support inside of MythTV (to enable playback of encrypted digital cable channels), it will likely be Mac-only and involve routing the video streams coming in from future APIs that pull from CableCARD/Switched Video USB-devices and implement TiVo-like hardware encryption tied to the network adapter's MAC address and further encode the streams to require an HDCP playback device. Perhaps using !Quicktime X Internet Streaming as part of the transition to 64-bit native binaries would ease the transition to such future technologies. Further note that it might be possible for a third-party such as Elgato.com, or anyone else, to license CableCARD/Switched Video devices for use on Macs and export a post-DRM-only developer API using QuickTime plug-ins even if Apple does not. Such an effort would be decidedly non-GPL/open source like much of the rest of Mac OS X (CoreVideo?, CoreAudio?, etc..)