The world is progressing!

So, in that short clip, I am holding, for the first time in my life, an electronic airline ticket. It's apparently on my frequent flyer card, and my baggage tag is stuck on the back of same card.


Nevermind the card is expired, it seemed to have worked fine so far.

We are one step closer to my dream of not having any documentation at all. All the world needs now is to install iris scanners everywhere, and link all this information electronically. No more passports, no more visas!

JVC PX100BAG - what a disappointment!

Ah, it's been a year since I posted anything here.
It's been a busy year.
After the death of the Panasonic, I went shopping online, and after much, much searching, I thought I found the perfect camera for me.
Small, lightweight, good video camera, and also takes good pictures, if the online reviews were to be believed.

I think they were all paid to write a better review than what the device would have gotten on it's own, or did not test it properly.

Not too long ago, the JVC was dropped, and it's LCD screen got a crack in it. Rather than repair it, I thought I would just get another camera that is not such a huge disappointment.

I'm quite happy with the Canon 70D, which does actually do what I want. Don't get me wrong, the JVC does have a couple of tricks that I will miss, like extremely fast framerate, or auto time-lapse.

However, that does not make up for poor picture quality.
Here is what I am talking about:


This is a cropped part of an image of my wife's canon Rebel Xti,
Click on the image for native resolution.

 

Below is a crop from near the center of the image from the JVC, taken at the same time, at the same event. Notice the poor picture quality on the boy's hair, and the compression artifacts on the tree. 

 

Unfortunately, that's not the worst of it. 

What drove me really batty was the amount of light bleeding over in high contrast areas. See the blue shine on the tree?

 Terrible for something that costs over $1,000.00, especially when it was touted as a cross between a DSLR and a camcorder.

So, what is the video quality like?
The poor optics really did not help the video, either:
I froze a frame, exported it and cropped it:

Here is the same scene, but from the Canon 70D.
It's a bit of an unfair comparison, the camera has just been released, and is twice the price of the JVC.

 In conclusion...
1. I'm happy with the Canon 70D.
2. Don't believe everything you read online. 
3. Your mileage may vary
4. If you know of someone that stocks spare parts for JVC/Kenwood, I would like to know.

;)

Panasonic HDC TM-900, RIP.

Ah, this camera served me really well, and it will be remembered fondly.
With aftermarket batteries and a 128GB Sd card, it was able to record most of my holidays without too much hassle.

It's footage will live on...

Unfortunately, it's not very dust-proof, and considering that I spend a lot of my time playing in the sand, it was only a matter of time. The other annoyance it developed was the habit of having a really sticky zoom when left alone for a couple of days, or when brought from an air-conditioned space to high temperature and humidity outside.

The construction of the camera is such that it is impossible to clear dust out of the zoom areas and apply grease without de-soldering some really thin flex cable.

In my soldering of the flex cable I must have destroyed a connection in the flex, and now the camera just does not show an image any more when powered up.

Commands for ffmpeg to speed up or slow down framerate

http://blog.grio.com/2012/01/fast-and-slow-motion-video-with-ffmpeg.html

That link points to the right and proper way to do speed ups and slow motion with ffmpeg.

I might actually go a little further and post another explanation of the command.

ffmpeg -i input.mp4 -vf “setpts=(1/X)*PTS” output.mp4

details:

ffmpeg        - calls ffmpeg program 
-i input.mp4  - file input name of the
-vf           - command required for the
"setpts=      - command sets the type.
(1/x)         - speeds up the  video
(x/1)         - slows down the video
*PTS"         - closes command.

output.mp4    - file name of output video


There are some refinements to this command, though. 

You can set the framerate stamped on the output video with 
-r   to stop ffmpeg dropping frames, with a bit of math. 

What good is all this without a few examples.

My GoPro Hero3 will output 240fps in WVGA mode. 
To convert that to 25fps slomo, I use the following command:
ffmpeg -i input.mp4 -r 25 -vf "setpts=(9.6/1)*PTS" output.mp4


That's maybe a little extreme... say you want to take some 960p footage down from 100fps to 25fps slowmo:

ffmpeg -i input.mp4 -r 25 -vf "setpts=(4/1)*PTS" output.mp4


Experiment with it a little. I already have two scripts to make conversion easy for the two commonly available GoPro Hero3 output framerates available in Europe. Americans might have to do a little more math to get a clean conversion with no frames dropped or duplicated, as far as slomo goes. 


For some reason I am unable to reply to comments. So, in response to the comment below:

Nope, forget completely about duration.
Old fps is 6, new fps is 24. 24/6 = 4, so you want your video to play 4 times as fast.

You would use something like this command:

ffmpeg -i input.mp4 -r 25 -vf "setpts=(1/4)*PTS" output.mp4

Good luck!
P.S. Sorry for the long time to reply. I had to figure out how....

Sorcerer Changes

Recently Kyle has been investigating ways of reducing disk I/O in Sorcery.

I have been testing his changes, and breaking my Sorcerer box often.

For those who don't know, Sorcerer is a Linux distribution.
What sets it apart from the other distro's out there is not that it's source-based. There are a few other distrobutions out there that downloads sources directly from the software author's released source code.

Sorcerer has the unique ability to create patches to source code on the fly, and updates to software that is already installed comes in the form of a really tiny sdelta file that is compressed with xz, and it updates the local tarball to the latest released version.

However, not even that is it's most distinguishing feature. It's most distinguishing feature is it's rapid evolution. Looking back at when Lunar Linux and SourceMage forked and Sorcerer changed it's license, a recent Sorcerer install only bears a slight resemblance.

We have started using cgroups and cpu.shares to finely control Sorcerer's impact on user experience while updating software. Init-scripts were changed almost beyond recognition, and while technically still a System V type init, it's much improved, and more dynamic.

Git support was built into the grimoire recently, and Sorcerer now supports pulling git updates directly from git repositories. There is still some kinks in the system, but it already works.

So, back to the latest disk I/O focus.
Kyle wrote a utility to limit disk I/O, but I have it uninstalled as I run my disks flat out for a long time, and don't want it limited. Different strokes for different folks, I guess. Anyways, we have moved the compilation location from /usr/src/sorcery to /var/cache/sorcery. Ccache implementation has been broken and fixed a few times, and right now we are working the last kinks out of the brand new "familiar" feature.

So...it's evolving, very quickly. Not many people like this type of fluidity, as weird things break all the time. Hence the Sorcerer community is tiny, and we don't do web updates all too often. Even documentation is neglected as whatever is written is out of date almost as soon as it was written. So, even though Sorcerer might appear dead to the world, it's actually quite active.

I learned more about Linux running Sorcery than any manual could ever teach.

Just to add a piccy, here is a recent screenshot of mine:























While this snapshot was taken on the 25th of September, and it's now only the 27th of September, it's out of date again, as the scry utility changed, and it's output now looks different. Which just underlines my point about the rapid evolution of Sorcerery. 

Sand Storm...

There is this sand storm ravaging our home town of Walvis Bay, and with my house right on the edge of the desert, it's taking the full brunt of the storm. 

Isolde was sweeping up some of the sand today, as the wind does not start until midday, and mentioned that our house reminded her of Kolmanskuppe, a ghost town that we went to see on our tour of the South of Namibia in 2010. 

So, here are a couple from that town. 

:)

 

Our house does not look quite as bad, but only because we are very diligent in removing the sand when it blows in. 

Living Software...

Here is something that I noticed that I am sure will unnerve a few people.

With the sources-based Linux that I am using, I see updates all the time... Buttons shifting, colors changing. Dynamic. My desktop is almost never the same two days in a row. The most stable thing is my desktop background... it has not changed in more than a year!

I remember not too long ago that software felt like it was cast in stone. Windows 95 was just that... sure, you could move your icons around on the desktop, but generally the thing stayed the way it was made, and any update is a major disruption.

These days, I pull updates at least once a week, and I see small, incremental changes all over the place as developers fine-tune the applications that have taken their fancy.

I'm starting to wonder what the next constant is... What are all these people coding to? Why does my computer still feel useful, even though it's changing all the time? It's like there is a deeper intuition going on, and that everyone subtly share it, even without knowing.

Or is it simply that humans are basically all made the same way, and that the place a developer puts a new button is just where I would look for it? Maybe we are all getting a sense of a computer mind....


;)