pyTivo Discussion Forum Forum Index pyTivo Discussion Forum
Answers and the development of pyTivo a TiVo transcoding server
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

pyTivo on Solaris 10 SPARC

Post new topic   Reply to topic    pyTivo Discussion Forum Forum Index -> Support
 View previous topic :: View next topic  
Author Message

Joined: 28 Feb 2009
Posts: 4

PostPosted: Sat Feb 28, 2009 5:10 pm    Post subject: pyTivo on Solaris 10 SPARC Reply with quote

Hi All:

I have been a satisfied pyTivo user for a couple months now (thanks to all the contributors for their efforts). My initial testing has been on wgw-2008.10.15-RC1 under WinXP SP3 on a P4 2.8ghz w/HT and 1.5gb RAM. It's been generally fast enough to transcode on the fly for my SD Series2 boxes.

I am very interested in moving this whole setup over to my Sun Blade 2000 workstation, which is running Solaris 10 10/08 SPARC. As my main server, this box already houses the video files in a 1.5TB ZFS RAIDZ and exports them as a Samba share to the PC. I haven't found any single HOWTO on my intended platform, so hopefully this thread will result in a step-by-step guide to getting it done, for the benefit of others.

Here are my major challenges as I see them:

- python. Should be pretty straightforward, I can get the Blastwave build of 2.5.1 and all dependencies via pkg-get.

- ffmpeg. This is where things get a little more hairy. Blastwave has a build of ffmpeg available, but it's ancient (as in, the last formal "release" in '05 before they went strictly to recommending SVN snapshots). Also, it appears to be built without any useful external codecs like libx264 and libxvid. I will try this Blastwave build first, but won't hold my breath; I am already preparing for the need to at least match rev 12665 as found in the ffmpeg_mp2.exe build bundled with wgw in order not to regress in functionality from my PC setup.

Even if/when I do get it running, performance will be a major concern. The target platform is pretty robust by SPARC standards, with dual single-core 64-bit 900mhz/8mb cache UltraSPARC-III+ CPUs and 4gb of RAM. Still, not yet sure how this platform stacks up against the performance on the PC which is 2-3 times faster cycle-for-cycle; cross-arch comparisons can be apples-to-elephants based just on numerical specs and especially when "two threads" means two single-thread cores on one vs one core that can handle 2 threads on the other. But I am taking the safe road and expecting the SPARC box to be slower, so in order to squeeze out as much performance as possible, I intend to use two parallel build environments: one based on Sun Studio 12 and the other based on Blastwave's gcc 3.4.5. I suspect it will be easier to get something running on gcc out of the gate, but the setup would definitely benefit from the optimizations available in the Sun compiler. My main focus will be on Sun Studio first, but I will fall back to gcc if necessary. I'm intimately familiar with Solaris on SPARC, but I'm a tech support engineer not a coder... so compilation is far from my strong suit.

UPDATE: On 3/15 I got FFmpeg (the only part which really required coaxing on Solaris) working--click here to skip down to that part.

- Creation of an SMF manifest. This "cherry-on-top" is desired so that the working service can be integrated into Solaris without legacy rc scripts and managed via svcadm. This should be no problem--there are some handy tools out there like Manifold which make it painless (that one in particular is also written in python, so all the better).

- SVR4-style ("pkgadd") packaging. Purely wishful thinking, and a placeholder in case I'm really bored at some point. Smile But Sunfreeware has a pretty good howto doc on creating them for anyone who's interested.

I guess my only initial question is whether or not I even need external codec support built into ffmpeg if I don't intend to transcode *to* h264 or XVID, only to transcode *from* these source formats solely to mpeg2 for pyTivo streaming. Does ffmpeg have built-in h.264 / XVID decoding by any chance? The less complex the ffmpeg requirements the better since the deck is stacked against me as-is.

Wish me luck. Any comments/tips appreciated. Hope to update soon.


Last edited by astar617 on Wed Mar 18, 2009 1:08 am; edited 3 times in total
Back to top
View user's profile Send private message

Joined: 28 Feb 2009
Posts: 4

PostPosted: Sat Mar 07, 2009 6:42 pm    Post subject: First attempt... Reply with quote

OK here is the 1st update. Last night I got everything in order and decided to take a "lowest common denominator" crack at it (for those who care about the Solaris bits--I am using wholeroot zones atop ZFS datasets to make environment rollbacks easier).

Current notes:

- Python was no sweat. I set up Blastwave (made a note to explore package tree differences in Blastwave vs OpenCSW since the project appears to have forked) and installed 2.5.1 plus dependencies as planned.

- FFmpeg had expected drawbacks but also some hopeful surprises. It appears to handle any video type I'd generally expect to throw at it, but the output is saturated green. However, I've already found anecdotal evidence that building without --mlib-enable might resolve this. Also, transcoding on my hardware is ~8fps single-threaded and ~12-13fps with "-threads 2" set. The most obvious optimization I'd need to make would be "-mcpu=v8", which is not allowing UltraSPARC optimization (SPARC v9) to occur. The biggest surprise though: turns out while the package info page for Blastwave's build looks like it uses the last "stable" code from 4 years ago, it actually is SVN r12629 built on gcc 3.4.5 last year, which is right behind the ffmpeg_mp2 build of r12665 I've been using with no problem on PC. This means that the build problems for current revs are probably not as bad as I anticipated. So the current plan is to try to get r12629 rebuilt with --mlib-enable removed and -mcpu=v9, first on gcc then Sun Studio 12. If I can get past that, I'll try the same on r12665.

- pyTivo itself was a breeze. Testing on the latest wgw snapshot, no gotchas there.

So as expected, ffmpeg is the biggest hurdle but doesn't appear insurmountable, even for a novice compiler like myself.

More soon...
Back to top
View user's profile Send private message

Joined: 28 Feb 2009
Posts: 4

PostPosted: Tue Mar 17, 2009 8:53 am    Post subject: It's Working... Reply with quote

OK as of this past weekend, I'm glad to report I got FFmpeg built for Solaris on SPARC and thus have a working setup Smile It's rough around the edges as illustrated below, but it is a functioning proof of concept. A lot happened since my last post to make this possible. Building was a headache but not a dealbreaker just like I predicted before.

I'll try to outline my environment, but YMMV based on other factors. My intent was to run as fast and lean on my SB2000 as possible. Absolutely zero consideration was given to portability / universal application on other platforms--you have been warned. I will clean this up as I go back and test again.

- I used Blastwave's build (CSWgcc4core) of GCC 4.0.2. Neither Sun's build (SUNW0gccfss) of GCC 4.0.2 especially for SPARC systems nor Blastwave's build (CSWgcc3core) of GCC 3.4.5 yielded successful FFmpeg builds.

- I used Blastwave's build (CSWgmake) of GNU Make 3.81. This is a requirement of the current FFmpeg makefile format; the gmake which ships with Solaris 10 is 3.80 and won't cut it.

- Starting with anecdotal experience elsewhere on the net as a base, I used the following PATH statement:
(Because of the requirement for gmake 3.81 to be invoked before the older version in /usr/sfw/bin, I just symlinked the proper gmake into /opt/gmake/bin and inserted it into the front of the PATH statement. Maybe I could have just thrown /opt/csw/bin up front, but this worked)

- I used the following LD_LIBRARY_PATH statement:
(Please be aware that use of this environment variable is the epitome of a sloppy hack which is generally considered evil and not recommended. Exactly why is well outside the scope of this writeup (read this if you really care), but suffice it to say that this is a side-effect of the fact that I suck at compiling when I'm wide awake, nevermind pulling an all-nighter to figure all this out Very Happy As I look at it now, it doesn't even make sense... one dir appears twice and another is an include? Wow I was tired. In any event, remember that whatever you set needs to be set on the target pyTivo server too, if it's a different host from your FFmpeg build box.)

- I used SVN checkout r15797 of the FFmpeg source. My original goal was to use the newly released version 0.50 code (yes, the FFmpeg team actually published its first new stable "release" in almost 5 years about a week or so ago). After some minor editing it built fine, but the latest code does not appear to behave nicely with the arguments pyTivo passes it by default. After trying to play with ffmpeg_tmpl with no luck, I just dropped FFmpeg back a couple months. The r15797 checkout worked perfect as a drop-in replacement (and does not require any editing to build either).

- I manually fixed the "green tint" issue I described earlier. It was a known issue that using Sun's medialib, which is supposed to provide better performance for Sun platforms, caused many outputs (all, in my testing) to be saturated green and take longer. Simply disabling mlib's use at compile time is a workaround, but not optimal given the fact that squeezing out any extra fps possible is a primary goal. Turns out an engineer at Sun determined the problem was with the manner in which FFmpeg was interfacing with medialib. So I debugged the code in libavcodec/mlib/dsputil_mlib.c manually based on his findings. I'll post a diff patch specifically for r15797 soon. It's worth noting that the fix was never merged back into the FFmpeg trunk so this fix is need on any attempted build with --mlib-enabled.

- I used the following configure flags:
# /ffmpeg15797/configure --disable-ffplay --disable-ffserver --disable-network --enable-gpl --enable-avfilter --arch=sun4u --prefix=/opt/fftest/2 --enable-pthreads --cc=/opt/csw/gcc4/bin/gcc --enable-mlib --extra-cflags="-mcpu=ultrasparc3 -mvis -fPIC -O3 -I /opt/csw/include"
In order...

--disable-ffplay / --disable-ffserver: not interested in either of these executables so disabling them meant much less that could go wrong to keep me from the goal of building ffmpeg.

--disable-network: I got a make error in some code involving UDP, which is probably only needed if you intend to stream with ffserver. Disabled and moved on.

--enable-gpl: Required to build, due to licensing of other surrounding bits.

--enable-avfilter: FFmpeg vhook subsystem is deprecated so you should always have this flag.

--arch=sun4u: don't know if this is required if you aren't trying to cross-compile to a non-native platform, but threw it in there anyway.

--prefix=/opt/fftest/2: my target install directory (In examining the configure script / Makefile, I'm pretty sure this is actually used to make sub-versions in your actual target install directory which itself is defined with some other flag, but in the absence of that flag this works)

--enable-pthreads: needed to take advantage of multiple CPUs/CPU cores.

--cc=/opt/csw/gcc4/bin/gcc: Absolute path declaration of my gcc executable. It was a lot easier to change this when bouncing between three compilers, than to have to mess with the PATH.

--enable-mlib: I obviously want to leverage the benefits of the fixed medialib functionality.

--extra-cflags="-mcpu=ultrasparc3 -mvis -fPIC -O3 -I /opt/csw/include": Mostly architecture optimizations (enabling use of SPARC v9 instructions with optimization for US-III, UltraSPARC Visual Instruction Set extensions, position independent code, and max-level GCC general optimization) with an include path thrown in for good measure because either configure or make was choking without it.

Basically that's it. Running
# make
# make install
should leave you with functioning binary in your defined {prefix}/bin directory:
# file /opt/fftest/2/bin/ffmpeg
/opt/fftest/2/bin/ffmpeg: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, UltraSPARC3 Extensions Required, dynamically linked, stripped
# /opt/fftest/2/bin/ffmpeg --version
FFmpeg version SVN-r15797, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --disable-ffplay --disable-ffserver --disable-network --enable-gpl --enable-avfilter --arch=sun4u --prefix=/opt/fftest/2 --enable-pthreads --cc=/opt/csw/gcc4/bin/gcc --enable-mlib --extra-cflags=-mcpu=ultrasparc3 -mvis -fPIC -O3 -I /opt/csw/include
  libavutil     49.12. 0 / 49.12. 0
  libavcodec    52. 3. 0 / 52. 3. 0
  libavformat   52.23. 1 / 52.23. 1
  libavdevice   52. 1. 0 / 52. 1. 0
  libavfilter    0. 1. 0 /  0. 1. 0
  built on Mar 15 2009 10:21:35, gcc: 4.0.2
/opt/fftest/2/bin/ffmpeg: missing argument for option '--version'

Point pyTivo to it, and you're good to go.


Sadly, performance still does leave a lot to be desired. As I stated before I have a Sun Blade 2000 workstation with dual 900mhz/8mb UltraSPARC-III+ procs and 4gb of RAM. Even with the rather aggressive set of compile-time optimization flags above and -threads 2 at runtime, I'm only getting 20fps under optimal circumstances, 16fps on average (watching pyTivo console when transcoding arbitrary mpeg4 files in my library). Crying or Very sad

So where do I go from here? I will attempt another build with "--enable-threads" instead of "--enable-pthreads" to see if there's a performance difference using the Solaris threads lib instead of the POSIX lib. At some point I will go back and see if I can figure out why Sun's GCC for SPARC was bombing out during make. It was giving an error about a const needing to be between -4096 and 4095. I might try building a 64-bit binary with the -m64 flag, though this might force me to track down (more likely, compile) 64-bit libraries, and even after that it could actually make it run slower depending on how the code is written. I also will attempt a Sun Studio 12 build, which I haven't done yet. Hopefully one of those will get some more speed out of my setup.

After I exhaust compilation options, there's always the possibility that I simply need more horsepower. The whole point of this was not to have to buy another box. But maybe I'll get lucky and find a V480 (up to four 1.2ghz/8mb US-III+) or V490 (up to four dual-core 1.8ghz/8mb US-IV+) cheap, along with another project to better justify spending more money. V480, maybe... V490, yea right Smile Anything physically bigger than that and it's impractical for my home. If at that point I can't get past the performance bit, I will probably have to end up getting a Sun Fire x2200 with a pair of dual-core Opterons or a x2250 with a pair of quad-core Xeons or something and move once and for all to Solaris x86/x64. But it's a good feeling to know that either way I did get it cobbled together on SPARC. Smile

Finally, two additional FYIs worth noting:

- I have been in contact with the current FFmpeg maintainer at OpenCSW (and former Blastwave maintainer) Murray Jensen, and I have made him aware of the mlib fix so that he can integrate this into any of his future CSWffmpeg builds. While he can't provide an ETA, he definitely plans to deliver an updated build based on the 0.50 code soon. Per CSW's mission, this will be suitable for use on any sun4m (SS4, SS5, SS20) / sun4d (SS1000, SC2000... you probably don't have one) / sun4u (All UltraSPARCs) / sun4v (all UltraSPARC T1/T2) hosts running Solaris 8, 9, or 10, and a perfect painless drop-in solution for pyTivo going forward.

- I have also been in contact with Mike Melanson, the guy behind the super-useful FATE (FFmpeg Automated Testing Environment). I noticed both Solaris on any hardware and SPARC under any OS were conspicuously absent from the automated testing, so I offered to run the script on my own hardware so the results of building the latest SVN on Sun products can also be included there, for the benefit of anyone who is feeling up to the task of building their own FFmpeg instead of using the CSW build.

Well, hope some or all the above helps!


Last edited by astar617 on Wed Mar 18, 2009 1:20 am; edited 1 time in total
Back to top
View user's profile Send private message

Joined: 06 Dec 2008
Posts: 152

PostPosted: Wed Mar 18, 2009 12:20 am    Post subject: Reply with quote

Great writeup, interesting read, and congrats on the success.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    pyTivo Discussion Forum Forum Index -> Support All times are GMT
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
Site is in NO WAY affiliated with TiVo Inc

Powered by phpBB © 2001, 2005 phpBB Group

Get pytivo at Fast, secure and Free Open Source software downloads
[ Time: 0.1454s ][ Queries: 12 (0.0146s) ][ GZIP on - Debug on ]