Scribefire and other firefox extensions

Ok, so Scribefire did a much better job of rapidly dumping my new text on blogger this time. So not a lot of excuse for not posting now ;-)
About FF extensions, I love them! They are extremely useful and I am occasionally looking for new ones to add. However, I am recently considering removing Sage, which I have used successfully for quite some time. That's because I have started playing with google reader. Since I use several different computers daily, this is a great tool so that i do not have to mentally synchronize what I've already read. Like it a lot!
Speaking of RSS feeds I must also mention Wizz. I have tried it a few of times and while my last experience (a couple of weeks ago) was at least passable I must say that it is a feature-rich RSS reader that fails to satisfy in the usability department. They even have a part in their online help saying "For some reason many people find it difficult to add feeds to Wizz" (from memory, probably not the exactly correct quote), and proceed to let you know how easy it is. However, dear developers, if many people have a problem, maybe it isn't as easy as you think it is? The problem I have is that it is hit and miss whether I get the desired RSS feed. It might even look like it's been added but Wizz doesn't display the contents, or other strange behaviours. With Sage, all I do is click on the live bookmark link in the address bar , select the feed and select the feed folder that Sage looks at. Boom ,it works. With Wizz you have to hunt down the rss feed link (xml file) and for some reason that is not directly present on a lot of pages so you have to search for it. At least I can't find it on about half of the pages I read. If I drag the assumed rss feed link/icon it isn't always the correct one (don't know why), or at least it doesn't work. Using a workaround, saving as a live bookmark and then importing into Wizz has worked every time, but that is clearly not optimal. I don't consider myself stupid, but Wizz just doesn't seem to work for me. So it goes.
And I tried Twittytunes last week. Fun, but caused my FF on Win2kSP4 at work to become unable to load *any* links after a restart, while it works fine at home (FF on WinXPSP2).

Powered by ScribeFire.

Welcome to the social (no not the Zune)

I have been away for a long time... But that's what happens when you have kids, a job, friends (yes, yes, I pay for them ;-) )and are interested in tinkering with "stuff". Time disappears.

Anyway, this is mainly a test post to see if Scribefire works better than last time. It didn't seem to support blogger very well. Or blogger didn't like Scibefire, I don't know...

By the way, I have been trying out some of these social networking sites, and while somewhat fun and potentially useful I do not see how any of them are going to survive for any extended period of time. Twitter is fun and doesn't require lots of energy (and isn't really what I'd call social networking), but Facebook and others can, if you let it, suck horrendous amounts of time. It might be the fact that not a lot of people I know are on Facebook at all, but I don't find it terribly interesting after about a week or so. Anyway, I'll probably sign up for more of these sites, just to try them out.

Powered by ScribeFire.

Compiling gcc 4.1.2 under mingw

I have as many others been annoyed by the message that ffmpeg compiled under current mingw displays when started. It says: "Compiler did not align stack variables. Libavcodec has been miscompiled and may be very slow or crash. This is not a bug in libavcodec, but in the compiler. Do not report crashes to FFmpeg developers."

Googling reveals that this has been fixed in gcc 4.2 which is not released yet so you'd have to compile it yourself from svn source. Now, there are instructions for compiling (experimental) 4.1 so for the sake of exercise I decided to try that. As it turns out, the error message is actually gone when ffmpeg (and all external libraries that I use) are compiled with this new version. Someone is bound to know why, but I haven't figured it out yet - IIRC I have read that the error is NOT supposed to disappear with 4.1.2. Well, what do I know. Anyway below are the steps that I followed, lifted from the mingw wiki and slightly modified:

1. Download latest stable gcc tarball
2. Install latest MSYS/Mingw according to the "FFmpeg on Windows" wiki. However, use the latest updates from the Mingw site
3. Install the additional stuff mentioned in the mingw wiki
   
4. Create two directories in the msys directory, one for the clean source (I called it gccsource) and one work directory where the actual compile happens
5. Unpack the gcc tarball in the source directory
6. cd to the work directory and run the following (prefix is where the new gcc should be installed):
   
   ../gccsource/configure --prefix=/gcc412 --includedir=/mingw/include --libdir=/mingw/lib --host=mingw32 --target=mingw32 --program-prefix="" --with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe --with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --without-x --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
   
   make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s bootstrap2
   
   make install
   
   PATH=/gcc412/bin:$PATH
   
   gcc -v (to check things worked)
   

When I followed the instructions verbatim I had errors indicating that gcc wasn't able to find certain paths during the process, which is one of the reasons it is important to keep all directories in the MSYS directory as various mingw specific patches have (obviously) not been applied. This means that gcc does not handle virtual paths like /c/.... In addition I had to add --includedir=/mingw/include --libdir=/mingw/lib to make sure include files and libraries were found.

Also, remember to modify PATH so the new version is used if you want. Don't replace the old mingw version of gcc in case you run into problems.

So there it is. With the new version I recompiled all external libraries and ffmpeg itself and have had no problems at all. Your mileage may vary. OTOH you might want to wait for mingw to release its patched gcc 4.2, which apparently should happen relatively soon after it is formally released.

Subversion on Windows - duuuhhhh!

I am most likely one of the less sharp knives in the drawer. As I wrote in another post I can compile ffmpeg using a set of nice instructions someone else has put together. One problem I could not figure out was however that the versions I made were always "SVN-rUnknown". I mentioned that the subversion I was using was the one in Cygwin and it finally dawned on me that the ffmpeg build process needs Subversion to figure out the correct version - and obviously since the MSYS environment had no knowledge of svn it'd be pretty darned difficult to use it. At first
I thought I'd have to build it myself, but luckily I stopped to think. And so I finally understood that the apps in the MSYS environment do not run sort of like in a virtual machine but natively (duhh! kind of like why mingw exists, innit?!?) and that the MSYS shell is just a shell and I should be able to run command line applications from anywhere in the file system. So I just dropped the command line version of Subversion for win32 in a directory and added the path to the bin directory to my PATH environment variable so I could run svn from anywhere - and there was no problem using it in the MSYS shell. Thus I recompiled ffmpeg and hey, presto, now the binary included from which svn version it was built instead of being "Unknown"!

"The wheel is spinning but the hamster is dead"

"Somewhere, a village is missing its idiot"

"The lights are on, but there's no one at home"

These are just some of the things I feel like telling myself. Anyway. Now you know.

Oh yeah, perhaps the biggest "duh" of all is that the instructions linked in the earlier post actually included instructions for installing subversion as well so someone just mindlessly following all the steps would have gotten it right right away... Gaaah! I've got to stop (trying) to think apparently! OTOH, now I finally understood several things that will help me using mingw/MSYS and I hope you do too!

ffmpeg command line example again

Ok, I have this 64MB M2 memory card that is available for video, so therefore I try to compress stuff quite heavily while keeping good quality - I have recorded the first season of Rome (but I missed episode two unfortunately) and after getting rid of the commercials they're about 50 minutes long. With the following (new and improved ;-)) commands I get very nice quality epsiodes that fit snugly onto the 64MB card. With the previous examples I too often got fuzzy faces in particular (even in some close-up scenes) and in the slightly more demanding episodes I still get that, but with these settings I'm fairly happy.

Now, audio could be even more compressed as I'm not too worried about quality when I'm anyway most likely watching in a noisy environment so fine audio details would tend to get lost anyway.

In practice, what I do here is that I write a batch file that converts all .mpg files (in this case) in a directory, and then I redo it for those files that turn out a lot smaller with a better constant quality setting, and for the too big ones with a lower quality. The lines below can be put into a batch file on which you just drop a single file, which is then converted. There's obviously no error handling so don't use without thinking, or you may delete files that you really wanted to keep. If anything at all happens due to your use of this example it is due to your own stupidity or bad luck. I accept no responsibility whatsoever for your use of my example...

@echo off

ffmpeg -y -i %1 -acodec aac -ab 32k -ar 32000 -croptop 72 -cropbottom 56 -vcodec mpeg4 -flags trell -trellis 2 -g 300 -qscale 10 -cmp satd -subcmp satd -mbcmp satd -precmp satd -s 320x192 -pass 1 -passlogfile "%~dpn1" "%~dpn1.mp4"

ffmpeg -y -i %1 -acodec aac -ab 32k -ar 32000 -croptop 72 -cropbottom 56 -vcodec mpeg4 -flags trell -trellis 2 -g 300 -qscale 10 -cmp satd -subcmp satd -mbcmp satd -precmp satd -s 320x192 -pass 2 -passlogfile "%~dpn1" "%~dpn1-final.mp4"

DEL "%~dpn1.mp4"
DEL "%~dpn1-0.log"

PAUSE

A couple of caveats exist of course. The cropping I do before encoding is adapted to the black borders of these particular recordings. You'll have to see what cropping fits best for your files. It only saves a couple of MB per file (for these files) so you might want to skip cropping completely if you're happy with the results anyway. And I should note that regarding the trellis option and flags I really don't know what the effects are since I cannot figure out what values "-trellis" accepts (it's an integer, but that doesn't really tell me anything), and what the relation between "-flags trell" and "-trellis int"is. It might also be interesting to experiment more with these and some others that I believe are related, like "-dia" (the diamond size used as the basis for trellis calculations). But as I am reasonably happy now I'll hold off on the experimentation for a while - anyone feel up for it? Leave a comment...

Subversive behaviour

Ok, regarding Subversion, I could of course use a windows client (like TortoiseSVN) - which might make more sense (and it is very user-friendly), but I actually had problems with line endings in ./configure after running an update so I don't quite trust it. Might try it again though.

Meanwhile, I'll try to understand what mingw does to make it different from cygwin so I might at some point figure out the compile errors.

Transcoding video for Sony Ericsson phones with ffmpeg

I have been playing with ffmpeg on Windows to transcode video for local use on my Sony Ericsson W950i (UIQ3/Symbian-based smartphone) and in the process set up an MSYS/Mingw development environment based on instructions here. I still haven't understood why I can't compile with Cygwin, but I still use the Cygwin environment to update the code with Subversion - since as far as my very limited studies show it's not part of mingw... Feel free to correct me since that is currently all I use Cygwin for and it does take up quite some space!

So, without further ado, here are some working commandlines to get video that works on a Sony Ericsson phone (my input files are mpeg2 files recorded with GBPVR low quality setting, possibly your mileage may vary if you have other types of input files), and also gives reasonable file sizes:

ffmpeg -y -i infile -acodec aac -ab 32k -ar 32000 -vcodec mpeg4 -g 300 -s 320x240 -qscale 10 outfile.mp4

If you want to run the movie on lower powered devices (smaller screen for instance) adapt the size like this:

ffmpeg -y -i infile -acodec aac -ab 32k -ar 32000 -vcodec mpeg4 -g 300 -s qcif -qscale 10 outfile.mp4

The latter line gave a file that played fine on a Sony Ericsson Z1010. To get better sound quality you could use "-ab 64k" instead and then probably lose the "-ar 32000" part for best quality (not sure, but I think so), but don't go higher than that as there are some limitations in the phones when you have video files with audio (which usually is the case with TV recordings). The "-qscale 10" is a parameter you could play with (values are 2-31, 2 is best quality) and for some inputs it's overkill as the default video bit rate of 200 kbps is more than enough to get good quality, It depends on the amount of movement present in the video.

Also, you might want to use two-pass encoding but in my limited experience it doesn't matter much - but it will depend on the original input.

You can output .3gp files (just use a .3gp file extension), but I sometimes have problems with those, so in that case I just run:

mp4box -tmp path-to-temp-dir -add 3gp-file -3gp new-3gp-file

For some reason that often works... Anyway, 3gp files are just mp4 files but without extra information and tracks so you might save a few K, but with my files that is not much so the mp4 format is fine at least for local playback. mp4box does no further transcoding so it has something to do with how the container is written. The reason to use the -tmp flag is to make sure that mp4box' temp files are written to someplace where you have rights to write, otherwise you'll get strange errors ("failed to clone input stream" or some such). If you run with administrative rights you can leave out that flag.

Good luck!