And that, my friends, is the last bit needed to get webcams into KDE. This morning around 3 AM or so I finished implementing the VideoDataOutput class in the gstreamer backend. It allows a phonon user to capture frames from a gstreamer stream. That picture was captured with the following code:

Once I test it against some code that doesn’t use video capture, it’ll be golden.

Hey, look, its a working webcam in Phonon. Again. My significant other is away for the week being a camp counsellor, so instead here is a picture of us drawn by an artist we met at Ohayocon earlier this year in Columbus, OH. I appear to be playing Cave Story, and she’s wearing her MOMO costume.

The first picture was much more exciting, I think. But this one still has potential. It was created using the GSOC project I previously discovered. The code is actually one line shorter:

QList devices = Phonon::BackendCapabilities::availableVideoCaptureDevices();
mediaObject->setCurrentSource(devices[0]);

Assuming that no super huge changes happen with the API, I plan to work on the Xine backend once I finish implementing the bits I left out from my code, such as device removal notification and proper device icons. My code is up for ridicule at Gitorious, under my personal repository. Make sure you check out the ‘webcam’ branch.

Before I go, a certain “Steve Schilz” has contacted me with an interest in writing support for the new capture API into the DirectShow backend. I gave him some pointers on where to start, so all those still using Windows can rejoice.

So karma decided to deliver my big box of homemade DDR machine fun from Newegg 2 days earlier. Such is life.

Compared to that merge request, my changes were miniscule, but I feel that I should still explain what I did, what I had planned, and how Casian’s changes fall (more or less) right in line. Hopefully my input will help.

The nucleus of my design was the CaptureDevice. I planned on adding a constructor to the MediaSource that would take this newly invented CaptureDevice class. CaptureDevices would be abstract devices and could represent any well-defined hardware-based source of media. Here’s what I wrote:

I wanted it to be super simple so anyone could just shout, “I need a webcam”, and *bam* you’d get the default webcam instead of the tuner card. Or even better, just ask for any kind of capture device and in 99.99% of user environments, you’d get something with an audio stream. The 0.01% is to account for users without any kind of sound card or sound capturing device. You’ll also note the special “Desktop” type for capturing your desktop. I think its safe to say that pretty much all platforms implement this in their media layer.

In addition, you could pass in some string that the platform could understand (eg. “/dev/video0″ or “plughw:0″). That way, you could grab a Device from Solid and pass that around.

Looking at his code, all that is already there. So the only real difference between my planned design and Casian’s was that there wouldn’t be a distinction between audio and video capture unless you absolutely needed it (such as for changing TV channels), which is what type() is for. The way I thought about it was that with a simple CaptureDevice to cover both cases, there’d only be one place to go for all your capture needs. In retrospect, splitting it up this way is a much better idea. It keeps us from trying to squash the unrelated functions of TV tuning and microphone boosting into one class.

Besides that one detail, his implementation is almost verbatim. I look forward to when the merge request gets accepted so I can jump in and get the gstreamer and xine engines to work with it. The code I wrote for my CaptureDevice is literally one line of original code: gst_element_factory_make("v4l2src", "v4l2src");.

So congratulations and many thanks to Casian for doing what I was supposed to be doing for a while :P. Please direct your thanks to him instead of the comments.

So, cue the drumroll.

Ladies and gentlemen.

I present to you, for your viewing pleasure, the first screenshot of a webcam being used with phonon:

ta da!

That would be Melanie, my girlfriend-turned-test-subject.

Its not much, but thats because it is only 14 lines of code.

Here’s the code, in as few lines as needed:

The other lines not there create a mainwindow, a video widget, etc.

The code in phonon though, is a little ugly. It’ll need cleaned up slightly before I can push out a commit to the git repo. Its also 2 AM, so I’ll post more details about how I’m planning on designing the system tomorrow.

Of course, I could be entirely dancing all over someone else’s toes. I had to drop out of the loop for a good while, but from what I understand, nobody has attempted tackling this since I last tried. Ping me if I’m wrong :).

The recovery console didn’t care about that useful bit of information I’ve lived with comfortably for about a year. My friend told me that Windows sees the first NTFS partition as the C drive, and thats that. Problem was, that windows couldn’t recognize any drives as being my NTFS partition. Linux could *guess* that sda1 had an NTFS header, but the important bits of the header were corrupt so it couldn’t be mounted. In the recovery console, I, J, and O were non-existant. The only drives I could see were two missing floppies, my two DVD drives, and my three hard disk partitions. After an hour of jumping through logical problems such as “If windows marks the drives it sees in alphabetic order, but my windows drive is actually called I in real life, and chkdisk might find a partition, then maybe I’m probably not screwed.”

I gave up¹, rebooted to Linux in single user mode, and ran TestDisk. Problem solved.

Lesson learned here? You can’t use Windows to fix Windows. It just simply isn’t equipped to do so. I’ll gladly stick with software that gives me the tools to do what I want.

¹: My friend actually donated a spare harddrive for the night that I quickly installed a fresh copy of windows to, letting us finally start our game at 2am. I fixed things when I got home later that day.

Having never hacked on xine before, the code isn’t nearly as nice as I want it to be. In fact, you’ll notice around line 215 that I magically multiply the image size by two and it suddenly works. Yay. There’s also a few other interesting bits, such as returning “v4l:/” as the media URI I’m currently playing, despite being told to play /dev/video0. This appears to be the only way to get the v4l demuxer to start demuxing my video stream. After that though, it Just Works.

So right now my plans are to get it included into xine-lib proper, which might mean porting it to the 1.2 unstable branch. In addition, it needs to be able to support more than just one format (including the MPEG streams that some capture devices use), radio devices, closed captioning, OSD output, and probably most importantly, audio. Bits of that sound to me like I’ll have to write a better demuxer, specific to v4l2 to better handle things. I’ve heard demuxers are easy though.

Lastly, in reply to all the comments on my last v4l-in-phonon post, thanks for the links, but the bit about wanting to write a photobooth clone was just a handy introduction to the real goal: getting webcams in phonon. I don’t really think its possible to simply ‘drop in’ one of those many libraries into Phonon to make things work, as those are all C++ (both gstreamer and xine are pure C), and its the backend’s job to handle getting video from the device anyways. But the kopete library is where I started, and its how I learned how video4linux2 works, so thanks for that.

If thats not enough, then here’s some words:

Juuuuuust before the last day of classes before thanksgiving break at Akron, and before the hard freeze I moved device-automounter out of kdereview and into kdebase. The screenshot above shows the configuration page, which is off by default.

A few people might be wondering why, but this mail in the kdereview thread probably explains the background a bit. In my opinion, it just isn’t an easily solvable problem right now. I’m leaving it up to the distros to decide if they want it on/off by default (just hack lib/AutomounterSettingsBase.kcfg or create a proper kded_device_automounterrc config.)

Administrivia aside, the automounter has a little bit of intelligence in it (explained in the SETTINGS file). With all three boxes checked (my recommendation!), the following logic happens whenever it sees devices:

If a device has ever been mounted (specifically, ever mounted while device-automounter was around), it is tagged as ‘familiar’.

Device-automounter only cares if a device is ‘familiar’ if that second checkbox about manually mounted devices is checked. If checked, it only mounts familiar devices. Otherwise, it’ll mount everything. It might sound strange, but its useful to me when I plug in friend’s random devices on my laptop to let them charge, and I don’t want to have to make sure I ‘eject’ or ’safely remove’ or unmount them.

So now we just need some way to get the lower level bits (like DeviceKit) to do this stuff. Then maybe we’ll be a few years closer to catching up to 2009.

As a bonus, the keyboard is detachable and the display can be stuck on your fridge since it has a magnetic back. Has anyone else out there ever heard of this thing?

IRC Nick: tdfischer

IRC Channels: #plasma #kde #fedora-ambassadors #fedora-kde, lots more on freenode, and #uakroncs on slashnet.

Fedora Ambassador: At the University of Akron in Akron, Ohio, USA

Dancing on top of an igloo last winter.

This week we had at least 10 people say they’ll be at our install fest next Tuesday “for sure”. Combined with what we had two weeks ago, I think our installation day is going to be rather busy.

As far as how exactly we’re doing our installs we’ll be having people either bring in their own computer, where we can then do the install and tweaking for them (including getting icky broadcom drivers to work, proprietary graphics, and setting up a connection to UA’s wireless). When they show up we’ll ask a few questions such as “Do you play games on windows?” or “Is there any software you use a lot [that wouldn't be available on fedora]“. Then we customize the system for them (dual boot, setting up wine, showing cedega, etc) and send them home with a copy of the install CD we built with Revisor for their system. The CDs get labeled nice Fedora/ACM logos with the disk printer the CS department bought us just last week.

If you’re a fedora user or a UA student, drop on by the 3rd floor of the student center. We won’t be too busy to say hello!