My son got a toy Melman at McDonalds in a happy meal a while ago. He love the thing. He pounds it on EVERYTHING. When you pound it, Melman says one of three phrases. Recently, however, Melman's voice started to give out. So I thought I'd replace the batteries. Should be easy, right, since those toys are just held together with a couple of screws.
Turns out it wasn't quite so easy. The screws are triangular. This means that a regular screw driver wouldn't work. I tried forcing it with some precision screw drivers I had, but they were all just the wrong size. A few google searches later and I found a few places that have them. The cheapest one sells bits for about $3.00. Currently, there's a catalog link here, but who knows how long it will last. I also found amermeida who sells through amazon that sells a screw driver for the triangle recessed screws for $2.00, but with $5.00 for shipping. I wound up ordering there.
Once the screw driver arrived, I removed the screws. There were L738H cells in place that were drained. I didn't have any of these cells on hand, and it was a cold night, so I raided my watch battery drawer in my shop. I had Energizer 392's. These were about 1-2mm thinner than the L738, but were close enough. I was able to bend the battery holder a bit and they slid right in. I snapped Melman back together, and I had a happy 2-year-old again.
Maybe I'll be able to repair other toys with this screw driver. I hope so, since I don't think the original toy itself cost $7.00. There's a couple of cars that he has which are held together with the same type of screw.
More on FreeBSD/mips another time...
20090129
20090127
Alchemy Au1550 status update
I'm in the very early stages of bringing FreeBSD/mips on the Alchemy Au1550. Plat'Home was kind enough to put an OpenMicroServer into my hands for the port. After months of sitting idle, I've started putting the board to use again. I test booted my first kernel tonight. It is still early days, but I thought I'd mention that I'd committed the very preliminary code to the project/mips tree in svn.
As an aside, the FreeBSD/mips main development has moved from the so-called "mips2" tree in perforce to the projects/mips tree in svn. This move allows us to more easily share the work in progress mips ports that people have been asking for in the past. We'll see how well this works out and see if theory matches reality or not.
As an aside, the FreeBSD/mips main development has moved from the so-called "mips2" tree in perforce to the projects/mips tree in svn. This move allows us to more easily share the work in progress mips ports that people have been asking for in the past. We'll see how well this works out and see if theory matches reality or not.
20090125
More Video Creation hacks
I believe that I've blogged before about my video creation on FreeBSD. Here's some interesting tips for DIVX players that I've found.
First, to recap: I tape a lot of hockey games with my DV camera. I use
Recently, I had my DVD player of many years die on me. It refused to play disks. So I went out gone one that would play DivX disks, as well as normal DVDs. This one also has a USB port on it. Through trial and error, I discovered that I could save myself a lot of disks by putting the videos I wanted to test on a flash drive.
DivX videos, for those that don't know, are basically MPEG-4 AVI encoded rather than MPEGE-2 encoded like DVD movies. While DVD movies can play as low as about 4 or 5kbps, they are generally encoded at more like 10kbps. At that rate, the average single layer disc can hold about 2 hours of video. DivX movies are encoded at more like 1-2kbps, so are about 3-6 times smaller than their DVD encoded counterparts. Of course, these are gross generalizations, but good enough for people to understand.
Now, my problem is that I have about 18 hours of hockey games that I'd like to distribute to the parents of the other players. For my son's benefit, I had made one DVD per game, but with 11 other parents, the thought of making 200 DVDs filled me with dread: it was too much time, too much hassle and it was starting to get expensive.
So, I started experimenting with DivX encoded videos. I tried to get ffmpeg working, but ran into a number of snags that I basically punted on. I had used mplayer for years to watch other videos and DVDs, so I thought about using mencoder. kino had a mode that would encode the DV movies to something else, so I played around with it. I created two test videos. One was at 854x480. This is what you get when you film in 16:9 aspect ratio with a DV camera that has a resolution of 720x480. Google for anamorphic for all the reasons for this, but they can be summarized as non-square pixels converted to square pixels. For the curious, I used:
One of these days, I'll need to learn how to do the fancy two-pass encoding to ring every bit of quality I can out of my source material. But for now, I'm doing good to get things encoded. I also need to find some way to tame the insane complexity of this problem. The above commands were basically minor tweaks to ones I found in kino's scripts to encode the video.
As for the DivX disk, I just copied the files over, and they played in alphabetical order. No way I could see to create a menu. No way to encode them in the .divx format that has menus and such in it, since I couldn't find the equivalent to dvdauthor for divx movies (please leave comments if you know of one for FreeBSD/Linux). For the hockey games for the parents, this is likely good enough. For other things, I'd like to do better...
First, to recap: I tape a lot of hockey games with my DV camera. I use
fwcontrol -R name.dv -M dvto read in the tapes. I then use the kino port to do some editing and convert the .dv files into mpeg 2 files for the DVDs of the games I make. I convert the mpeg2 files to dvds using dvdauthor. When I want to be fancy, I use dvdstyler to create themes for the DVDs.
Recently, I had my DVD player of many years die on me. It refused to play disks. So I went out gone one that would play DivX disks, as well as normal DVDs. This one also has a USB port on it. Through trial and error, I discovered that I could save myself a lot of disks by putting the videos I wanted to test on a flash drive.
DivX videos, for those that don't know, are basically MPEG-4 AVI encoded rather than MPEGE-2 encoded like DVD movies. While DVD movies can play as low as about 4 or 5kbps, they are generally encoded at more like 10kbps. At that rate, the average single layer disc can hold about 2 hours of video. DivX movies are encoded at more like 1-2kbps, so are about 3-6 times smaller than their DVD encoded counterparts. Of course, these are gross generalizations, but good enough for people to understand.
Now, my problem is that I have about 18 hours of hockey games that I'd like to distribute to the parents of the other players. For my son's benefit, I had made one DVD per game, but with 11 other parents, the thought of making 200 DVDs filled me with dread: it was too much time, too much hassle and it was starting to get expensive.
So, I started experimenting with DivX encoded videos. I tried to get ffmpeg working, but ran into a number of snags that I basically punted on. I had used mplayer for years to watch other videos and DVDs, so I thought about using mencoder. kino had a mode that would encode the DV movies to something else, so I played around with it. I created two test videos. One was at 854x480. This is what you get when you film in 16:9 aspect ratio with a DV camera that has a resolution of 720x480. Google for anamorphic for all the reasons for this, but they can be summarized as non-square pixels converted to square pixels. For the curious, I used:
mencoder sample.mpeg -cache 8192 -aspect 16:9 -vf harddup,pp=ci,scale=854:480 \to encode the DVD-quality images into divx. This encoding resulted in a factor of 3-4 saving in file sizes. This was fairly good, but didn't get my 40GB of mpeg's to fit on one DVD. In addition, the DVD player I bought didn't like this resolution at all. I figured other people's DVD players wouldn't like it either. Next, I tried a reduced resolution version. I used
-ovc xvid -oac mp3lame -lameopts preset=192 -xvidencopts bitrate=2048 -ffourcc DX50 \
-o high.avi
mencoder - -demuxer rawdv -quiet -cache 8192 -aspect 16:9 -vf harddup,pp=ci,scale=426:240 \which resulted in a space savings more like 6-10, which puts the encoding project within striking distance of one DVD. It is well under the DL DVD range, and might be very close to the single layer limit of 4.7GB. We'll have to see how the encoding goes. It is moving about 4x faster than the previous encoding as well.
-af-adv force=1 -srate 44100 -ovc xvid -oac mp3lame -lameopts preset=medium \
-xvidencopts fixed_quant=4 -ffourcc DX50 -o medium.avi
One of these days, I'll need to learn how to do the fancy two-pass encoding to ring every bit of quality I can out of my source material. But for now, I'm doing good to get things encoded. I also need to find some way to tame the insane complexity of this problem. The above commands were basically minor tweaks to ones I found in kino's scripts to encode the video.
As for the DivX disk, I just copied the files over, and they played in alphabetical order. No way I could see to create a menu. No way to encode them in the .divx format that has menus and such in it, since I couldn't find the equivalent to dvdauthor for divx movies (please leave comments if you know of one for FreeBSD/Linux). For the hockey games for the parents, this is likely good enough. For other things, I'd like to do better...
20090123
Quick Mac OS X hack: Time Machine
I have two macs in my house. One has a 750GB drive on it for backups, plus its normal disk. It had been setup for Time Machine before and was working well. I also have a MacBook Pro that needs to be backed up. I didn't want to swap the disk back and forth between the two, since that would significantly erode the value of Time Machine's automatic backups. I didn't see any place where this was well documented, so I thought a quick note would be helpful to people. Most of the references I've seen have talked about different hacks to make this happen, or that it is only on a specialized Apple product that I didn't have.
I'm running Mac OS X 10.5.6 on both machines.
First, I went to the store and bought a 750GB drive. I plugged it into the mac mini that I have sitting on my desk. I configured it for Time Machine on the Mac Mini. I did a couple of time machine backups.
Next, I exported 750GB disk using the 'Sharing.' I clicked on 'File Sharing' tab to enable it. I clicked on the '+' button under the "Shared Folders" menus. I selected the volume that I had setup for Time Machine. I made sure that I was sharing via "AFP" in the "Options..." dialog.
Once I had things shared this way, I went to the other mac. I went to "Finder" and selected "Go->Connet to Server.." tab. Here I explicitly typed "afp://ipaddr/" and connected. Once I was connected this way, I proceeded to enable Time Machine. The remote disk appeared on the list of choices, so I just selected it and started it up.
I discovered that I have a 100Mbps switch, rather than a GigE switch. This made the initial backup very slow, on the order of 10GB/hr, which means I'm looking at a 10 hour backup time. Maybe it makes sense to head off to staples/best buy to get a GigE switch to plug them both into.
I've not tried to do this wirelessly, so I don't know how painful that will be. I've also not tried to connect this to the Samba server that I have running FreeBSD. I can normally see that volume on the macs without needing to do the manual step.
UPDATE: A GigE switch does help quite a bit. It was more like 6GB/hr with the 100Mbps switch, but with GigE I'm getting about 22GB/hr... So I have about 3 hours left in the backup now... 22GB/hr is about 6MB/s which seems way too slow (the hard disks are limited to about 15MB/s on each side, and the network to 125MB/s, so why the fall off in speed).
I'm running Mac OS X 10.5.6 on both machines.
First, I went to the store and bought a 750GB drive. I plugged it into the mac mini that I have sitting on my desk. I configured it for Time Machine on the Mac Mini. I did a couple of time machine backups.
Next, I exported 750GB disk using the 'Sharing.' I clicked on 'File Sharing' tab to enable it. I clicked on the '+' button under the "Shared Folders" menus. I selected the volume that I had setup for Time Machine. I made sure that I was sharing via "AFP" in the "Options..." dialog.
Once I had things shared this way, I went to the other mac. I went to "Finder" and selected "Go->Connet to Server.." tab. Here I explicitly typed "afp://ipaddr/" and connected. Once I was connected this way, I proceeded to enable Time Machine. The remote disk appeared on the list of choices, so I just selected it and started it up.
I discovered that I have a 100Mbps switch, rather than a GigE switch. This made the initial backup very slow, on the order of 10GB/hr, which means I'm looking at a 10 hour backup time. Maybe it makes sense to head off to staples/best buy to get a GigE switch to plug them both into.
I've not tried to do this wirelessly, so I don't know how painful that will be. I've also not tried to connect this to the Samba server that I have running FreeBSD. I can normally see that volume on the macs without needing to do the manual step.
UPDATE: A GigE switch does help quite a bit. It was more like 6GB/hr with the 100Mbps switch, but with GigE I'm getting about 22GB/hr... So I have about 3 hours left in the backup now... 22GB/hr is about 6MB/s which seems way too slow (the hard disks are limited to about 15MB/s on each side, and the network to 125MB/s, so why the fall off in speed).
20090122
Minor at91 hacking
The recent changes to the SD/MMC stack broke AT91. It seems like there was an assumption that was bogusly baked into the driver. We had assumed that the only data transfer commands would be 512 bytes.
The problem is that the newer stack does commands that are 16 and 64 bytes long. These aren't really needed for basic support of the stack, but to get things like SDHC and high speed transfers working, they are needed.
I've fixed this, and now things work again. I've also taken this opportunity to do some minor cleanups to the at91 mmc/sd driver.
The problem is that the newer stack does commands that are 16 and 64 bytes long. These aren't really needed for basic support of the stack, but to get things like SDHC and high speed transfers working, they are needed.
I've fixed this, and now things work again. I've also taken this opportunity to do some minor cleanups to the at91 mmc/sd driver.
Subscribe to:
Posts (Atom)