Saturday, April 24, 2010

Simple video edit using PiTiVi

I am not a professional video editor and my needs are really quite basic.

I have a few short videos in avi format that came from a Canon point and click. What I would like to do, is take the important segment, and bin the rest.

There are command line tools I am sure to do this, but it seemed a good opportunity to try out a new tool that appears in Ubuntu Lucid - the PiTiVi video editor.

Sound and Video -> PiTiVi video editor

Video is 1 minute long and takes about 75 megabytes but we shall soon shrink it down by cutting off the excess using Timeline -> Split

Now I cut it into three pieces and keep the middle portion (40:00 to 54:00)

The top left are is labelled 'Clip Library' and from there you should drag your clip downward into the 'Timeline' area (You will know it is done when the audio and video bottom sections are non empty)

Now there is something wrong in the picture above. When I dragged my clip I did not drag it to the zero line.
It will make things easier for me to drag to zero, as I am looking to retain a segment which runs 40:00 to 54:00, and so starting off-zero makes things more difficult.

drag to zero then split at 40...

Now splitting at 54:00 and hovering over the middle bit shows grey markers at each split:

Now shove the timeline vertical line into each of the segments you wish to lose, and use the menu to Timeline -> Delete

What I am left with is the portion I wish to keep...

...which I now drag to the left so that it lines up with zero, before I then 'Render' the project

Now the .ogv file has been output and in the file browser shows that size has come down to 20 megabytes. File -> Properties shows some information about the framerate.

Note: PiTiVi is version 0.13.4 on my system. This is an early release, so is usable, but not necessarily perfect or bug free.
File/Properties (and vlc) says 60 fps whereas the PiTiVi output dialogue indicated 25 fps.

What you should see is Video codec: Theora         Audio codec: Vorbis

( If your output file does not show Video codec and Audio codec as expected, then check Project -> Project Settings really does show theoraenc and vorbisenc before you ask PiTiVi to 'Render' )

I look forward to version 1.0 of PiTiVi later this year.

There is a quick start manual for PiTiVi in .odt format for further reading.

Note: In this early release of PiTiVi there is a known bug that can be overcome by seeking forward in your clip. If you selected 'Render' and nothing happens then this is a known bug and the workaround is to seek forward in your clip before you render. Not ideal but then version 0.13.4 still has plenty of development left before version 1.0 (production ready)

I never witnessed this error myself, I preview before rendering, as it is part of my work style. However if you are just using PiTiVi for conversion rather than 'editing' then you might well hit 'Render' and nothing happens (bug 603102)

Checking Frames per Second using VLC:

Clicking 'Tools -> Codec Information' from within vlc player whilst playing your clip will give you a dialog that provides information about the video and audio codec:

I chose to use VLC to report on Frame rate, rather than use Totem Movie Player or other tools that, I felt, were more likely to share underlying playback libraries with Nautilus.

Notes about unnecessary packages theoraenc or ogmtools:

Although 'Project -> Project Settings' shows theoraenc and vorbisenc, this does not mean that you need to install ogmtools package or ogmrip package.
PiTiVi is, I think, using libraries rather than /usr/bin/theoraenc to do it's encoding.

Output of dpkg (below) just to clarify that my system rendered .ogv theora/vorbis, and has libtheora0 installed, but did not require packages ogmtools or ogmrip from *universe/multiverse:

*This makes sense really, as PiTiVi is now available as part of official Ubuntu, and so should not have dependencies other than packages maintained by Canonical.

Explicit copy function

Following a buzz link earlier to "When copyright goes bad" (youtube), spurred me on to look up "the right to read" - the only Stallman essay I have read.

It is painted quite dark in places, but I think of that, as perhaps saying "Danger cliff ahead", when you reckon people should pause for thought.

An extract from this fictional essay below.

For Dan Halbert, the road to Tycho began in college—when Lissa Lenz asked to borrow his computer. Hers had broken down, and unless she could borrow another, she would fail her midterm project. There was no one she dared ask, except Dan.

This put Dan in a dilemma. He had to help her—but if he lent her his computer, she might read his books. Aside from the fact that you could go to prison for many years for letting someone else read your books, the very idea shocked him at first. Like everyone, he had been taught since elementary school that sharing books was nasty and wrong—something that only pirates would do.

If all students were given Apple's latest book reading device, would we be moving closer to this fiction?

In "When copyright goes bad" there is an important point I think, which says that, when we moved from tape recordings to drag 'n' drop music libraries, we changed things in an important way...we introduced an explicit copy function (music store -> local computer).

Replacing school books with slates or similar, that are populated from online book stores, again introduces an explicit copy function. With that explicit function, you welcome into your school increased control by another outside authority.

If the device was simply a book reader but nothing else, and the school distributed electronic materials themselves to all devices, then you would maybe not require some login and 'personal rights'. Perhaps you could even (at a state level) negotiate campus wide access agreements to educational materials, rather than a per student system.

Including internet access on the device, would likely result in a login requirement, and that makes things real convenient for organisations who favour personal "right to read" restrictions for books.

Links and further reading:

The extract featuring the characters Dan Halbert and Lissa Lenz, is from an essay by Richard Stallman, from the February 1997 issue of Communications of the ACM (Volume 40, Number 2).

That extract in original form appears here and includes the trailer
"Verbatim copying and distribution of this entire article is permitted in any medium without royalty provided this notice is preserved."

My short commentary is of little merit really, but as I included an extract, the above notice applies.

The comments I make are personal opinions, and I include the essay extract, as it stimulated my thoughts. Please read the original essay in its original form. It is not my intention to dilute or paraphrase "the right to read" or "When copyright goes bad" in any negative way. I will be happy to remove my article entirely if the authors feel my comments have this effect.
Non login contact available at

Thursday, April 22, 2010

Ubuntu Lucid - Monitor Resolution check

My experience with Nvidia graphics card and iiyama 24 inch monitor has been good and bad with Ubuntu Lucid (beta).

Here I list a few steps to confirm that things are working as they should be. These might give you some clues if you are having intermittent 'out of range' messages in beta of Ubuntu Lucid.

From within Ubuntu Graphical desktop, click the display properties icon in the panel:

...and select 'Configure Display Settings' which will open a dialog box like this:

( System -> Control Centre -> Monitors ) will get you 'display properties' if your panel is missing the clickable icon.

During my earlier problems with getting a working display the 'Refresh rate' box showed 0Hz which is nonsense.

If you have your monitor manual to hand then you can check the 'Refresh rate' for the 'Resolution' to make sure that the systems own guesswork seems reasonable.

Now this Iiyama 24 inch B2403WS monitor has 1920x1200 Vertical Frequency listed as 60Hz.

( If you are not specifically told 'Refresh Rate' then use Vertical Frequency is a good guide as this Wikipedia article may suggest)

So refresh rate 60Hz looks okay to me.

( System -> Administration -> System Testing ) will give you some further information about detected resolutions (when you get to the appropriate test)

[ Technical Term here (feel free to skip what I say in this paragraph) ...Incidentally, if you feel like you need a figure for Video Bandwidth and cannot see it explicitly mentioned then look at the highest value of 'Dot Clock' and use that (162MHz in my case)  ]

In summary, most of what I can see for my monitor setup looks good :)

If you have upgraded your system then you may have a stored monitor configuration in your home directory. If so find the details in ~/.config/monitors.xml (my stored config is shown here):

My stored configuration has the important parts correct (rate 60) but looks a bit lacking for the fields vendor, product, serial.

It has been suggested that removing ~/.config/monitors.xml might help you overcome an 'out of range' message. You might want to keep a personal copy of monitors.xml (under a different name), as this file might be a way of tricking your system into using a fixed refresh rate if auto-detection continues to give you problems.

The poor guesswork in monitors.xml for vendor, product, serial might be because this file is two months old, and was perhaps generated in the Ubuntu Karmic install (which was on this machine before the upgrade to Ubuntu Lucid beta).

One question which is worth a look with any new graphic driver is how good are the Modeline entries that it is using?

Here is some information about the Lucid beta version of Nouveau and Modelines for my monitor:

What is of interest to me is the 'initial mode', and the Modeline which is the closest match to, what the graphical monitor configuration tool reported.

I have used the command 'cvt' to independently generate Modelines with which I can compare.

Looking at the results of the cvt command without --reduced flag generated ( 193.25 ), this differs considerably from my monitor printed manual listing for 1920x1200.
I would only use modeline output from cvt generated with --reduced flag.

This article is intended to act as a series of hints as to what extra information you might consult, if Ubuntu Lucid guesswork for your monitor is producing poor results or intermittent 'out of range' messages.

If you have an Nvidia graphics card and want to compare your /var/log/Xorg.0.log to help your analysis then here is a directory of sample Xorg logs.

In particular here is an example of an Xorg log where Ubuntu Lucid beta worked well.

Note to the people who code the monitor vendor names:

The Japanese company who make my monitor are (in lowercase) iiyama, when you uppercase the first i to become (I), it is sometimes then assumed to be an uppercase L, which might explain your entry in the monitor database.

Here is a link to a websearch that might verify things:
    websearch for monitor company

Saturday, April 3, 2010

Cleaning a trackball with pencil and paper

About 3 months ago I switched from Mouse to Trackball and have been very satisfied with it.

Cleaning is an issue with a Trackball just as it is with a regular Mouse.

Any product which has a ball in contact with your hand or a desk surface, will pick up dust through the gaps.

( Mouse users who dislike having to clean a mouse usually go for an optical mouse - something I considered but rejected in choosing my affordable Trackball T-BC21 from Logitech )

My first thoughts were to pull the red ball upwards and out, but it felt like it was held in, so I instead turned the Trackball over and spotted some screws :)
Reaching for a screwdriver is the wrong thing to do.

On the underside is a hole and all that is required is to insert something non-sharp into the hole to push the ball out until it drops into your hand.

(Poke: If you have a pencil with an eraser on the top, then use the eraser end)

If you must use a pen or other sharp object, then placing a bit of cloth over the end should prevent the sharp end from damaging the ball when pushing.

The holder... where most of the dust will accumulate, in particular, the area around the white dots, is where you should work hardest, as these dots are important for working the trackball smoothly.

The rectangular window... the trackball holder should be dust free, and anything non-sharp (I used the corner of a piece of paper) will do the trick.

Professionals will likely suggest a cotton bud from a cleaning kit, or something similar instead of the pencil and paper I had to hand :)