John Galea's Blog

Just another weblog

Converting old home movies

If your like me you have some old video tapes. Mine are home movies of my daughter when she was young. They are precious and I didn’t want to loose them. Some are more than 15 years old and I was concerned they would eventually degrade so I wanted to digitize them to keep them for all time, as well as make them more convenient to watch. So I looked around a bit and found a cheap USB video capture adapter on Amazon. It was supposed to come with uLead but came with a barely functional PVR from a company called Honetech. I dug out the VCR (actually had to borrow one from a friend the drive belt on mine had disintegrated), found the cables and hooked it up. The code once installed is super basic but does work. I didn’t bother trying to edit the captured video, rather simply pressed play and pause and separated the videos by topic. On default settings here are the capture settings:
The captured video ends up being 16.3M/min. So a 55 min video ends up around 900MB. This works out to only be around .27M/s so a USB 2 device is more than adequate. All of the encoding is done in hardware by the device so you don’t need anything too powerful to do the capture. The file once captured seems to require a video codec that isn’t there by default on Windows. Kodi had no issue playing it on a variety of platforms. DVD players also had no issues with it. At the end of the day the output is adequate and well worth the time to preserve important videos. The capture adapter was cheap, $20 so well worth it. Time wise it is very time consuming. 1hr takes 1hr (thanks Captain Obvious).

January 30, 2017 Posted by | Mutlimedia, Other reviews, Uncategorized, Video Encoding | 2 Comments

Video Encoding (update)

A while back I did an article on video encoding comparing a number of processors and encode time. What I am doing is measuring the time it takes to take an AVI in DIVX 4 format and re-code it for an iPod into MP4 format using Media coder. This program is very well written and takes advantage of multi processors and multi threading. At the time I did the comparison with all the systems I had in the house. Well a new computer has found it’s way into the house and I have moved to Windows 7. So let’s see what this brings.

The video file is a 349MB XVID 40:50 long.

The reining champion is a dual, quad core (8 processor) Xenon processor running Windows 2008 R2 (so 64bit) in a VM on ESX 4.1. This puppy just chews through video files. On this machine the re-encode took 577 seconds.

The second fastest was a dual core P4 processor. which took 1265 seconds

The new contender in the house is a brand spanking new Core I5 dual core processor running 32 bit Windows 7. It took 384 seconds! Holy crap. The improvement is unbelievable. A whole 33% improvement! Impressive given dual core Vs 8 cores!

As a point of reference my laptop took 1190 seconds to encode the same video and got up to a whopping 101C.

December 27, 2010 Posted by | Other reviews, Video Encoding | Leave a comment

Video Encoding

One of the things that you often need to do is to re-encode movies. For iPodsiPhones for example they always need to be MPEG4. I’ve played with a number of encoders in the past and few support multi processors. Leaving a single core to sit and be a spectator while you wait. In the past I used but it only supported the single thread.

It seemed to me that re-encoding ought to easily be a multi threading app given key frames. Then Sean Liu pointed me in the direction of and open source encoder. Low and behold it supports multi threading. I’ve also wondered the difference in encoding speeds of between say an Xeon (server processor) and a Pentium 4 (desktop processor).

So I have two machines, one is a Pentium 4 based 3.2GHZ processor running Windows 2008. The other machine is a vmware ESX 4.0 based Xeon dual quad core 1.6GHZ. I ran some testing encoding a 340MB DIVX video file and converted it to MPG4. I constrained the number of processors simply by using the task manager affinity control. Here are the results


2 processors took 1232 seconds 51% (vs 50% theoretical)

1 processor took 2399 seconds

Xeon VM .16GHZ

4 processors took 648 seconds 27% (vs 25% theoretical)

3 processors took 826 seconds 35% (vs 33% theoretical)

2 processors took 1191 seconds 50% (vs 50% theoretical)

1 processor took 2394 seconds

As you can see it scales REALLY well!

As you can also see in spite of being a 3.2 G P4 Vs a 1.6 G Xeon there is only a 3% difference in encoding times proving the old adage GHZ is not everything!

You can also see that vmware is excellent at passing the CPU through to the guest. It’s a pitty there is a limit at 4 CPUs to the free version. I’d love to have all 8!

UPDATE: I have been able to redo the testing on this with all 8 VCPUs now. The results are VERY interesting: Here’s the raw data for encode time of a 1 hour 41 min XVID movie. For details of the movie and the encode see below:

1 CPU 6604 sec
2 CPU 3296 2.0
3 CPU 2314 2.9
4 CPU 1710 3.9
5 CPU 1426 4.6
6 CPU 1246 5.3
7 CPU 1155 5.7
8 CPU 1119 5.9

It really is quite stunning to see how well this actually tracks. You can see though, adding more and more processors starts to yield less and less results.

As an interesting test I also ran the same movie through a 64 bit version of the code (all the rest of the tests were done with a 32 bit host/client). The host had 4 processor. The same movie encoded in 1861 (Vs. 1710) seconds meaning no benefit (and some penalty in fact) to 64 bit.

The graph of actual performance Vs the number of CPUs looks like this:

August 31, 2009 Posted by | Other reviews, Video Encoding | 1 Comment