CPU requirements for decoding Blu-Ray?

[speedsix]

Hi all,

I'm sure this must have been answered elsewhere but I can't find any sort of solid reply.

Can anyone confirm the requirements for smooth playback of even the highest bitrate discs?

I'm thinking of starting with a C2D 2.66GHz E7300 and overclocking (if necessary)


Many thanks

[ggking7]

Even with my AMD X2 3.1ghz overclocked to 3.3ghz it's far from perfect.

[Sagekilla]

My dual core Opteron 170 (2 GHz, fairly old CPU) decodes Blu-ray discs flawlessly using CoreAVC. Same goes for my laptop (C2D @ 2.16 GHz), and that doesn't have CoreAVC installed. You should be fine with any modern CPU

[speedsix]

I've just noticed that PureVideo support has been released in beta form for the new nvidia drivers. Given the right gpu that should help alot.

Might not need as high end cpu as I initial thought.

How well does CoreAVC work in Linux?

[ggking7]

Go for the PureVideo support for sure, but make sure your card is on the supported list. My card supports PureVideo but isn't on the supported list for acceleration.

[HymnToLife]

How well does CoreAVC work in Linux?

Xine support is broken atm, but it works perfectly well in mplayer.

[nm]

You can also compile MPlayer with the libavcodec library from ffmpeg-mt (http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt). While not quite as fast as CoreAVC, it should be enough to decode most H.264 streams on current dual core CPUs (except Atom 330). Blu-ray is usually sliced though, so the normal FFmpeg H.264 decoder may give similar results on dual cores. Just remember to run MPlayer with "-lavdopts threads=2"

Building MPlayer with the ffmpeg-mt libavcodec:
(I'm not sure if libavformat and libavutil have been changed in the ffmpeg-mt branch, but let's get them too)

# Install the normal development tools, subversion, git and X.org development libraries if you haven't got them already. For example on Ubuntu (use sudo) and Debian (run as root):
# apt-get install build-essential subversion git-core xorg-dev

# Fetch the latest MPlayer and ffmpeg-mt revisions from their code repositories
svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
git clone http://git.gitorious.org/ffmpeg/ffmpeg-mt.git

# Replace the libav* libraries with those from ffmpeg-mt:
cd mplayer
rm -rf libavcodec libavformat libavutil
cp -a ../ffmpeg-mt/libavcodec .
cp -a ../ffmpeg-mt/libavformat .
cp -a ../ffmpeg-mt/libavutil .

# Build MPlayer and MEncoder
./configure
make

# Run as root or with sudo to install MPlayer and MEncoder to the /usr/local hierarchy
make install

Usage:
mplayer -lavdopts threads=N file # N = number of threads to use, 2 for dual and 4 for quad cores

Make sure you don't have other MPlayer binaries installed on the system, or if you need them, use the full path to run the custom build: /usr/local/bin/mplayer

If there are problems playing MPEG-TS streams (video doesn't show up), try using the demuxer from libavformat instead of MPlayer's own by setting -demuxer lavf

[sl1pkn07]

that there are differences between normal and Mpay mplayer-mt?

sorry my english

[HymnToLife]

that there are differences between normal and Mpay mplayer-mt?

mt = multi-threaded.

That means it will take advantage of the multiple cores of your CPU (stock libavcodec will not).

[sl1pkn07]

but use same branch? or is a independent development

[nm]

That means it will take advantage of the multiple cores of your CPU (stock libavcodec will not).
Normal libavcodec can also use multiple threads (and therefore cores) to decode multi-sliced H.264. I haven't compared that to the ffmpeg-mt implementation, but the latter should be more efficient with sliced streams and much more efficient with single-sliced streams on multi-core CPUs.

but use same branch? or is a independent development
ffmpeg-mt (http://gitorious.org/projects/ffmpeg/repos/ffmpeg-mt) is a Google SoC project (http://code.google.com/soc/2008/ffmpeg/appinfo.html?csaid=9FD2BF705A5D5DBB) for FFmpeg that will probably be merged with the main FFmpeg branch at some point. The multithreading code has been written by Alexander Strange during the past year. He syncs the git tree with FFmpeg mainline every now and then to keep the rest of the code up to date.