Posted by Skrud at Tuesday, November 1st 2005 at 10:23am
The problem with having courses about really interesting stuff is that I (and my lack of priorities) can very easily get sidetracked while “studying.” The irony of it is that the sidetracking starts with something that I’m studying. Tonight I was reading about NFS and figured it would be a really handy way of sharing files between my Linux box and my laptop.
So I looked up a few guides and got it working, added an automount rule to my NetInfo Database – but I couldn’t get write access. Something about how NFS treats uid’s … which coincidentally is what’s wrong with it as a secure protocol in general, which is why I was studying it in the first place…
Then I learned that I can set up Apple File Protocol on Linux with netatalk. Using howl, I can have Zeroconf Networking (à la Bonjour) between my Linux and Apple computers. There was even a tutorial on the Gentoo Wiki that took only a few minutes. Now my home directory is easily mounted as a Network drive on my PowerBook’s desktop. I can even tunnel the connection over SSH when I’m not home for secure operation. Which is pretty sweet, and totally painless to set up. It’s even running over TCP, so I didn’t have to bother with getting an AppleTalk server running.
The problem is that I did all this starting at 3am. I didn’t get much sleep (in fact, I’m not sure I even fell asleep). And what’s worse is I have to stay at ConU until about 10pm tonight… sigh…
Tags: geek, linux, mac, school, tech | 6 comments
Posted by Skrud at Monday, October 17th 2005 at 5:38pm
I can just imagine everyone seeing the title of post and shaking their heads, shriveling their brows and frowning. I bet they’re thinking “Skrud, you should be writing in Java. It’s cross platform.” Well, I haven’t even begun to tell you about my nightmare yet.
It’s a complete myth that the cross-platformability of any code is dependent upon the programming language it’s written in. It drives me crazy when people tell me that Java is wonderfully cross platform. That’s just marketing. In case you don’t believe me, take a look at the platforms that Sun releases Java for: Solaris Sparc (Sun’s own platform), Intel i586, AMD64. What about Java on Alpha? Well there are builds by HP. Java on PowerPC? Apple has its own builds. So you see, Java is as portable as the VM, and Sun only releases the VM for their own Sparcs and the popular Intel platform. All the other platform builds are released by third parties. How exactly is this different from having a C compiler on different platforms? Or even just telling gcc to cross-compile. How many platforms is GCC released for? I don’t know, why don’t you count.
But this isn’t about any language being better than any other, and this also isn’t about the JVM. Again, being cross-platform means writing portable code. You can write portable code in any language. (Java included). You can also not write portable code in any language, Java included. Portable code has no platform-dependent aspects and will run smoothly with a negligible effort of porting. Portable code has a limit, and it has to be able to adapt to different platform specific properties. This means that for each target you’ll have some source code files that need to be reimplemented, changed, etc. In the case of operating systems, this is unavoidable. By nature, an operating system needs to interface with hardware. You must have processor-dependent source code for the parts that need to be processor-dependent. Take a look at the Linux kernel. A lot of the processor dependent features are handled through macros that automatically replace certain snippets of code with the processor-dependent feature that is needed. There are also different source trees for different platforms. These separate source code files are not portable, which means that your entire product can only run on as many platforms as you’ve manually configured it for. In the case of Java, you have standard implementations of awt, swing, and swt that make your life easier. Because these are environments that exist on virtually every platform that Java does.
But I’m not talking about operating systems either. What I’m talking about is Java3D. Java3D is supposed to be a development platform for 3D graphics and “Advanced Imaging” for Java. It is not cross platform. A program is certainly not cross-platform if it can only be built on Sparc, i586 or AMD64. i586 and AMD64 are both versions of the i386 platform anyway. So they’re really the same thing. If you want them to run on a different platform, you’ll need to build the libraries yourself. If the code is written portably, you should have no problems compiling the source code, linking against your own system’s libraries, and having a nice custom version that will work on your PC. Unfortunately Java3D isn’t written like that.
You know something is wrong if the build instructions look like:
- Add this to the j3d-core/build.xml file:
<condition property="isMacOSXOnPPC">
<os family="mac" arch="ppc"/>
</condition>
- Add a build target for Mac OS X, too:
<target name="setupMacOSX" if="isMacOSXOnPPC">
<property name="ostype" value="macosx"/>
<property name="platform" value="macosx-ppc"/>
</target>
- Re-implement
javax.media.j3d.J3DGraphicsConfig, javax.media.j3d.NativeScreenInfo, javax.media.j3d.NativeWSInfo to use MacDrawingSurface.
And to boot these aren’t official build instructions, I found them on a forum. There are no official build instructions for OS X. You know, there actually _is_ a sun.awt.MacDrawingSurface class that they could’ve used. There’s also an X11 implementation for OS X that they could’ve used, since the Linux version of Java3D uses X11 it shouldn’t be too difficult to port. But a better question would be: why are they not using portable windowing code to begin with? Probably for speed/performance reasons, but still – what’s the point of a Java API that only works on 2 different platforms? (And seriously, how many people use Sparcs?)
This comes as I’m trying to get more involved with the UGENE project, and while talking with Jon Benn this afternoon I was trying to get Java3D to build on my PowerBook. Since Mac OS X is one of our target platforms, if it really does prove to be infeasable to build on OS X we’ll have to move to a platform other than Java3D. He suggested OGRE 3D, which is a C++ API. Looks like the foray into Java has come to a grinding halt.
Tags: code, geek, linux, mac, tech | 5 comments
Posted by Skrud at Saturday, October 15th 2005 at 3:33am
I had a bitch of a time trying to convert a PAL version of the (most awesome) Thai movie, The Bodyguard, to a locally playable NTSC encoded disc. After much googling and reading many guides and tutorials and other various things I realized that it would be much simpler to just buy an all region DVD player. I still agree. But after two days of wrestling with mplayer, mjpegtools, ffmpeg, and dvdauthor I’m proud to say that I’ve emerged victorious, and I can’t wait to watch The Bodyguard with friends and all.
I figured I’d help the next poor soul goolging for PAL -> NTSC conversions by describing what worked for me. In short, these are the steps:
- Use ffmpeg to reencode the video and (if necessary) audio.
- Use spumux for DVD Menus (although it’s not that important).
- Use dvdauthor for authoring the DVD.
Originally I had tried using a method I read about in this forum involving mplayer and mjpegtools, but this left me with out of sync audio (and, on top of that, mplayer would downmix the 5.1 AC3 Audio track to 2.0 channels).
I’m going to assume that you already have the DVD ripped and are dealing with straight VOB files now, and there are plenty of real guides out there for ripping/decrypting DVDs. vobcopy works great. You can then use mplayer to play the VOBs directly so you know which ones you want to convert (or you can just convert them all … totally up to you).
You can actually use ffmpeg to reencode and resize the video and audio together in one shot. Just like this:
ffmpeg -i /path/to/vobfile -target ntsc-dvd -r '30000/1001' -aspect 16:9 -acodec copy outputfile.mpg
Obviously -i takes the input files as a paramenter, and -target ntsc-dvd is fairly straightforward. The -r option tells ffmpeg to encode at the standard NTSC framerate which is 29.997 fps (or, more accurately, 30000/1001) as oppose to PAL’s 25 fps. Meanwhile -aspect forces the output to be in a 16:9 (NTSC Widescreen) format. You could also use 4:3 for standard NTSC TV format. The -acodec copy option tells ffmpeg to copy the audio stream from the source. If you want, you can reencode it by using the -ar, -ab and -ac options…. check ffmpeg’s help for that. And finally you give it an output file. Remember, the main feature of a DVD can often take up more than one VOB file, so make sure you’re not forgetting any. Having more than one mpg file is fine, you can always string them together with DVDAuthor.
I’m not going to bother dealing with menus, because it can be really tedious (especially if you’re trying to rip the menus off an original DVD) or even make your own … but this tutorial explains it much better than I could, and it’s what I followed.
The man page for dvdauthor was my best friend during the next process, and I had to make many small changes to the XML file to get it to work just right. dvdauthor is a neat little program that takes an XML file as input and produces an authored DVD ready to be burned. It’s kind of tricky doing this by hand, so I would suggest just using one of the many frontends available from the list on the dvdauthor website. The only time a frontend wouldn’t really help you is if you’re making your own menus, or you’re trying to have a movie in a menu …
Anyway, the XML file is fairly straightforward. This is what the one I used looked like:
<dvdauthor dest="/home/skrud/bodyguard_vts">
<vmgm>
<menus>
<video format="ntsc" aspect="16:9" widescreen="nopanscan" />
<audio format="ac3" channels="2" samplerate="48khz" />
<pgc entry="title">
<vob file="momentum_asia.mpg" />
<vob file="momentum_pictures.mpg" />
<vob file="piracy.mpg" />
<post>jump titleset 1 menu;</post>
</pgc>
</menus>
</vmgm>
<titleset>
<menus>
<pgc entry="root">
<vob file="spu_main_menu.mpg" />
<button name="play">jump title 1 chapter 1;</button>
<button name="bonus">jump title 2 chapter 1;</button>
</pgc>
</menus>
<titles>
<pgc>
<vob file="movie_1.mpg" />
<vob file="movie_2.mpg" />
<vob file="movie_3.mpg" />
<vob file="movie_4.mpg" />
<post>call menu;</post>
</pgc>
<pgc>
<vob file="making_of.mpg" />
<vob file="trailer_borntofight.mpg" />
<vob file="trailer_ongbak.mpg" />
<post>call menu;</post>
</pgc>
</titles>
</titleset>
</dvdauthor>
The dest attribute in the root tag is the directory where your output will go to.
Giving those menus the “title” and “root” names will link them up to your DVD Player’s Title and Root Menu buttons. The VMGM tag specifies what gets played as soon as you pop the DVD in. In this case, the studio’s logos and an anti-piracy ad. (The video and audio tags are optional, but there’s more detail on them in the dvdauthor man page). Each pgc tag declares a new title, and each vob entry implicitly declares a chapter. If you want to painstakingly set up chapters and times and crazy things like that, then follow another tutorial. Because I’m too lazy, and as you can see, I didn’t bother.
The post tag under pgc contains an action (in dvdauthor’s language) on what to do once everything in that pgc has finished playing. By the same token, there’s a pre tag that will let you set up an action to do something before a pgc starts playing. The vob tags just take a video file as an argument. In this case, following the anti-piracy ad, the DVD will jump to the “root” menu, which it recognizes as being the menu of the first titleset tag. A dvdauthor XML file can have plenty of titleset tags. And the jump command will take a number of “targets” as a parameter. Namely: titleset <n> menu; (play the menu from titleset number n) or titleset <n> title <m>; (play title m in titleset n). More details again are in the man page. You’ll notice there is also a call function. This works similarly to jump, only it can be used to jump to a menu from a different titleset, which the jump command won’t do.
You’ll notice my root menu actually has buttons defined. The button names correspond to the names given in the spumux configuarion XML file that I used to create the menu mpg. dvdauthor and spumux are bundled together, so they understand each other when it comes to that kind of stuff. But again, I don’t want to go into detail about spumux, because imo it’s a bit of a waste of time and you’ll be better off using a frontend for it anyway. (I actually handcoded menu highlight images using The GIMP of all things …. it was really cool, but still quite tedious).
Then all you have to do is run dvdauthor:
dvdauthor -x <xml file>
And then use growisofs to burn a DVD image:
growisofs -dvd-video -Z /dev/dvdrw /folder/with/video_ts
Anyway, I hope this helps someone out sometime! Really, the meat of the operation is done with that one ffmpeg command, and everything else is can be done with a dvd authoring tool… Good luck!
Tags: apps, geek, linux, movies, tech | 7 comments
Posted by Skrud at Thursday, August 4th 2005 at 8:37pm
I’m the Linux Fairy, happily prancing about with penguin wings, tossing free Ubuntu Linux CDs to all in my wake!
I ordered some 200 Install CDs from Ubuntu (they’re free!) after giving away all the CDs that Nadia ordered long ago. They finally arrived today. Only instead of going to ECA (which is where I ship parcels addresses to CCSS), they were delivered to the Department of Computer Science. So I got this weird e-mail from Dr. Lam (the chair) saying that there was a parcel of 200 Linux CDs with my name on it in the CSE Department Office.
Now, when you receive 200 CDs from Ubuntu, it comes in a big ass box:
(I made a little mess in the CCSS Office… sorry folks!)
So now we are 200 Ubuntu CDs richer. Well, 150 x86 CDs, 25 PPC and 25 AMD64 CDs. Mike suggested putting them in Frosh bags. I think that’s an awesome idea, that way every Froshie will get a nice, fresh copy of Linux as soon as they come to Concordia. Excellent way to set them on the right foot.
There was a ~$10 delivery charge that Canada Post tacked on, likely due to the fact that the box was pretty damned big. The department happily footed the bill, which was awfully nice of them! So a huge thanks to the CSE department from me!
Tags: ccss, concordia, geek, linux, school | 6 comments
Posted by Skrud at Wednesday, July 13th 2005 at 4:15pm
I used to stay away from amaroK like it was the plague – mainly because it used to crash literally every 5 seconds. Not a very useful music player in that sense ;) But recently I’ve started using it again. Until now I’ve been using Rhythmbox for my Linux music needs, because it comes stock with Ubuntu and Gnome, but I find Rhythmbox to have a very primitive interface which is not very configurable. It acts a lot lile iTunes but nearly as smoothly or as fluidly – and worst of all it would crash in the middle of the night.
What I did like about Rhythmbox though was that with the right GStreamer plugins it would play anything at all. And that’s kind of important because my music tends to be in a ton of formats other than the “typical” MP3 and OGG. That includes AAC/M4A (thanks to iTunes + my PowerBook), Musepack, AC3, etc. JuK, the most simplistic and versatile music player for KDE – and my favourite – just couldn’t handle these files, despite the fact that it should support anything that GStreamer supports.
So I gave amaroK a shot. And it doesn’t crash as often anymore – which is a good thing. The GStreamer engine still had some trouble with AAC files so I hooked up the Xine engine. The best part about Xine is that it supports 5.1 surround sound… so those AC3 DVD rips of Nightwish’s Once come through much better than they did before. So far so good :)
Tags: apps, linux, music, tech | 2 comments
