There has been a lot of discussions in the past few months about patents on video codecs and how Ogg Theora fits into the picture. Most recently I read Ralph Giles' blog post, and I feel the need to help clarify the concerns about Ogg Theora because I do not think he quite grasps it yet. Or, maybe he does, but he just does not accept it, placing higher value on different points.

Modern video codecs are complex and implement quite a few concepts. There are patents on most of the algorithms implementing these concepts. During the standardization process of MPEG-2 and MPEG-4, the majority of the patents are revealed, and then the patent holders establish a means for paying a royalty/fee for a right grant on the whole pool of patents. On the other hand, On2 only made VP3 available royalty free for their own patents. Considering how Theora is not revolutionary and implements a lot of the same concepts used in ITU and MPEG codecs, there is a good chance some other parties hold patents on some of these algorithms.

I do not describe these as "submarine "patents. This is not about submarines, and that term is being used in a loaded manner of tone. It is a simple matter of facts, probability, and risk. Considering the nature of the technology, there are many things that can be covered by a patent. While there is still some risk with the MPEG codecs (there is always some risk), there is a low probability that something is not covered by the patent license pool. With VP3 and Theora, only some smaller subset is covered by On2 patents.

Yes, the software patent situation does suck. What sucks most is perhaps the uncertainty and fear of litigation. So, yes, this is a matter of FUD and for good reason. To me, it makes more sense to choose something with a known risk that is easily mitigated. I do not think we can simply feel safe just because On2 says we are safe from them. So, what Theora patents not claimed by On2 am I talking about? I do not know, but considering it is a rather traditional video codec, I'd hazard a guess that it's a decent amount, and they may not surface until they near their expiration.

When you combine this risk with Theora's lackluster quality, I just do not see a compelling reason to advocate or use it. On the other hand, Dirac and Schrodinger seems like a great way forward! This is a true win-win situation because, for one, BBC forgoes its patents and with it being a less traditional codec, it has a smaller area of exposure thereby reducing its risk. Additionally, you do not have to financially reward the crummy software patent system.

Think some people drive pretty bad while using their cell phone?

How about riding dirt bikes and quads in the ghetto?
What about doing wheelies nearly the entire time riding said dirt bikes?
OK, then, what about using the cell phone while wheelying your quad through the ghetto:

http://www.youtube.com/watch?v=z-KMsYTSHu8

Living in California, I miss Cincinnati Chili, a unique and special dish. Instead of having cans of Skyline shipped, which is expensive, I learned to make it myself. If you are not familiar with Cincinnati Chili, its history, and how to serve it, please read this other recipe.

Using a Crock Pot, set it on High, and add: 

2.5 cups water
~1.33 pounds 90% lean ground beef
10 ounces tomato paste (not quite a whole 12oz can)
1 medium onion, diced finely (I use a food processor)
1/2 tsp garlic powder
2 or 3 dashes Worcestershire sauce (to me, a dash is a shake of the bottle with its sprinkle top on)
1 tsp vinegar
1 tsp allspice
1 bay leaf or 1/2 tsp chopped bay leaves
1/2 tsp cayenne pepper hot sauce
1 tbsp chili powder
1 tsp ground cinnamon
2 tsp ground cumin
3/4 tsp ground black pepper
2 tsp salt
1 tbsp unsweetened chocolate

I think it is important to add the water and meat first. After that, I just dump in all the remaining ingredients in no specific order. Then, I just use a potato masher to mash and mix this. Cincinnati chili has a fine texture; the ground beef should not be in chunks. Let it cook one hour, stirring occassionally.

In addition to serving over pasta and cheese coneys (chili cheese dog), I often put it in a soft flour tortilla with cheese and hot sauce--a chilito. When I run out of hot dog buns, I just put sliced wieners on bread with chili and cheese on top, then eat with a fork--"open face." With a hot dog bun, often the wiener is quite large; so, I slice it longways and put half of the wiener on the bun to leave more room for the chili. Oh, and do not forget the awesome chip dip! Spread cream cheese on the bottom of a casserole dish, add warm-to-hot chili, and top with grated cheddar cheese. Let the cheese melt or put it in a warm oven a short while to melt the cheese.

I have received many requests to use the recording date and time or timecode in Kino's Titler. Well, nuisance is the mother of invention. I implemented it tonight, but it is not yet committed to CVS. Click the image to get the full resolution.

Sometimes, there is a very poignant post in the Kino discussion forum that I think would be very appropriate for the blog. Like this one:

I guess, this is my major gripe (amongst a few others) I have regarding open source software: project lifetime seems to be rather short - with its first "official" release 1.x in March 2007, kino's feature development has already ceased as it will be replaced by "kdenlive/MLT" (which looks very much like a clone to cinelerra).

In my eyes, kino is (was?) the perfect easy to learn tool for the down to earth hobby video filmer who just wants to convert dv-material to dvd mpeg with a few effects and doesn't want to hassle with a "fully featured" (overloaded?) software like cinelerra. After all, there has been lots of praise by the linux world for just those reasons.

As of now, kdenlive/MLT doesn't even have a titler effect like kino, much less the requested effect of titling the timestamp stored within the dv stream. It will be interesting to see if kdenlive will survive long enough to implement that feature.

Me, for my part, I will stick with kino and use the titler feature.

Kind regards
sanplis

Kino was always just a "practice" for me and has been in development for over 6 years! That is not such a short lifetime for an "exercise." Also, a 1.0 release for many projects indicates achievement of a certain level of features and stability. That holds true for Kino as well. Also, it is quite common that major new releases represent a major rewrite of a significant portion of the codebase. After all, what's in a name and number? You can think of kdenlive/MLT as work towards Kino 2.0 if it makes you feel any better.

Kino 1.x still represents what you describe as what you like about it. My approach towards continuing that achievement is to limit it purely to bug fixes and keeping current with dependencies. I do not want to sacrifice stability for growth in the Kino codebase.

BTW, kdenlive/MLT does have a titler, and it already has the ability to use metadata "variables!" It's just not yet putting the DV metadata into the stream for what you want.

+-DRD-+
Lead Kino Developer

Some of us have taken up new hobbies:

• Amy is taking ballet. There are pictures from her Spring Showcase. I did not take pictures or video during the show as there was professional videographer, which I had to respect.
• Lauren is taking Tae Kwon Do (picture) and has advanced a couple of belts already.
• I have resumed--after 25 years--riding a motocross bike (pictures). Riding has not returned to me as easily as I thought it would. I have been out 3 days so far and have had a (minor) accident each time. On the first one, I smiled because I knew I was pushing myself. I had the same objective 25 years ago--to have a minor accident each time. My new goal is to not wreck as they are taking their toll on a much older me as well as the bike.
  

dvgrab 3.0 will be released soon. Dan Streetman contributed patches adding MPEG2-TS support (via libiec61883, of course). This benefits users of HDV camcorders and digital TV settop boxes. My contribution was to merge, address regressions and bugs, simplify options, minor changes to improve settop box support, update documentation, and test. I do not own a HDV camera, so I test against the settop boxes as well as regression testing DV. Testing is almost done.

Users of settop boxes have been struggling along on libiec61883's test-mpeg2 utility for capture or, more recently, mythtv's firewire integration, which works marvelously, I should add. However, if you are not running mythtv, or want to experiment prior to mythtv, then you want a little command line utility. Well, settop boxes require some connection management before they will start transmitting, and users have learned from me to use some arcane incantation using the plugctl utility. Not only that, but they would frequently encounter problems with dropped packets as disk I/O interleaves with firewire I/O. dvgrab 3.0 addresses all of these problems. You do not even need to know the guid (euid) of the box either. You just need to know a couple of simple options, and the man page contains a concise example.

You can get a preview of dvgrab 3.0 in the Kino CVS.