Let’s go over cameras again. Many expressed dismay in yesterday’s API Review that Flash Player 9 will be using the Video4Linux version 1 (V4L1) API. Many inquired, “What drives this decision?” Mostly because the code was already in there from the previous codebase and required very little effort to make work with the current Player internals.
That said, let’s look forward to a purely hypothetical future where the Player supports version 2 of the same API (henceforth V4L2). We’ve covered this territory before in Penguin Eyes. That thread emitted some mixed signals. Here is what I took away:
- there are 2 APIs: V4L1 and V4L2
- V4L1 is on its way out, scheduled for demolition this month, in fact
- V4L2 is the way, the truth, and the light (until V4L3 is finished)
- lots and lots of camera drivers provide V4L1 facilities
- comparably few camera drivers provide V4L2 facilities
I thought I picked up somewhere in that thread that there is some compatibility for V4L1 in V4L2. Wow, that would be nice. I tested this quickly by trying the V4L2 capture.c example with my spca5xx-driven, no-name camera. To no avail.
/dev/video0 is no V4L2 device
But I suppose that’s neither here nor there. I guess my question is: If (not promising anything here) I wanted to try my hand at adding V4L2 support to the Player, and given the limited camera support for the API, what specific camera model can I easily purchase that will provide the support? Note: Please don’t tell me, “Just use any camera with a foocam610 chipset.” That doesn’t help me. In the Penguin Eyes thread, I saw a recommendation for a Logitech Quickcam 5000. Any others? Thanks, that would help me out.
As for delegating camera input duties to GStreamer as so many have clamored for… no, just… no.
What follows is a list of the APIs that the current Linux Flash Player 9 development version is using. I debated whether it was appropriate to publish this information. Then I remembered that anyone who knows what they’re doing should be able to figure this stuff out by themselves anyway once the final Player is released.
- General graphics: X11
- GUI elements (dialog boxes): GTK
- Audio I/O: ALSA
- Camera input: Video4Linux, API version 1
- Threads: POSIX threads
- non-HTTP Networking: BSD sockets
- SSL: OpenSSL
- IME: you know what? I don’t think we’ve settled on this one yet…
There are undoubtedly others that I’m missing… dlsym() and friends for dynamically loading shared library functions to avoid static linking of LGPL libraries.
Now that I think about it, how come there are so many layered methods for doing basic A/V operations but one for doing network communication (BSD sockets)? I have searched for higher level general libraries on top of the sockets. I know that some criticize raw ALSA programming as being comparable to ASM for audio operations. BSD sockets strike me as the ASM of network programming.
I would now like to open this thread for readers to voice their concerns over API choices.
Welcome, again, Digg readers. Flash Player 9 for Linux Details Posted by Adobe Insider– sounds so scandalous. I just wanted to point out that the really interesting part of this post are the comments in the thread written by another Adobe insider, Tinic Uro, explaining why rendering graphics in Flash is not as easy as it sounds. Search for them.
Before today, I was not really aware of what Digg is. I’m still not entirely sure what it is, but I now know what it’s not: A credible news source. As a countermeasure to recent events, the titles of my blog posts will now be groups of random words that I pull from those spam emails which try to confuse Bayesian filters. I can’t wait to see the Digg posts about Adobe hammering bedraggled earlobes.
Following up on yesterday’s issues, remember that Flash does things that are not strictly multimedia related. All the multimedia stuff — the A/V output, the A/V input — we have that pretty well nailed down, though it does pop back up every so often. The problem that had me stopped was unrelated to audio or video. I’m not going to re-hash the details because it’s extremely tedious and because I have already spent the last 2 days explaining it to anyone who would listen.
I came up with a solution. So I am back in today to implement it, since I basically lost all of yesterday to my main dev box. Yeah, I finally fixed that too, and without having to jump distros.
A word about distribution loyalty: Everyone has their favorite distro, and that’s fine. I believe that all distributions have their place. I’ve been through lots of distributions, including Slackware, Red Hat, Debian, Mandrake, even Linux From Scratch. I’ve settled on Gentoo as it suits my needs and my habits best. And there’s no way I want to take the time to learn the idiosyncrasies of another distro in the middle of this project. That said, we do expect the Linux Flash Player to work reliably on a wide diversity of (x86-based) Linux distributions and plan to test it with that in mind. Further, different team members are using different distros. At the very least we have Gentoo, Fedora Core, and Ubuntu in the mix and even that limited diversity has helped us shake out some bugs.
Things are not going so swell right now, at least for my development tasks. My favored Linux distribution — which I previously claimed rarely fails me — failed me. I may need to shop around for another distribution soon (perhaps along the lines of Mac OS X or Windows).
Though we have been diligently working towards getting all of the Linux features in line with the Windows and Mac counterparts, we have been hitting some capability walls. I.e., there are some standard facilities and APIs that Windows and Mac operating systems provide to applications that Linux simply doesn’t. To be sure, it’s not that Linux can’t do XYZ, it’s that there are so many ways to do XYZ. And forget about making these different methods interoperate where conducive. To answer anticipated objections, we don’t have the prerogative to pick and choose which Flash features go into the Linux version; it’s basically all or nothing. To address further objections, “Adobe isn’t open sourcing the Player at this time.”
Though many of the Flash 8 and 9 features are in place now, the Linux Flash Player currently crashes. A lot. I have yet to make it through one full minute of a video when I try to partake of the erudite entertainment at YouTube. On the plus side, the pre-crash A/V sync is outstanding.
Undaunted, the ragtag Linux Flash team presses forth…
Tinic has some stuff to say about Linux Flash Player development as it pertains to other CPU architectures, including x86_64, PowerPC, and ARM.
Thanks to those who advised me recently that there is no reason that the Linux kernel should not support my network hardware. You were right, just as long as I have a recent kernel. The problem was that I was trying to use a slightly out of date Gentoo Linux distribution (that would be upgraded after installation). Hey, I’m not used to using cutting edge network hardware– my 3com 3c905 NICs still serve me well. Normally, I do my homework before purchasing hardware on which I plan to run the penguin-based OS, but The Company provided this box to our group.
Anyway, the Flash-on-Linux development posse now has a beefy new Gentoo-based server that will aid us in a number of ways (think distcc for the non-negligible source tree). And I was worried I would have to learn how to operate a more, shall we say, Enterprise-focused Linux distribution for this task. For posterity and education I have documented my findings at the Gentoo Wiki.
I like Gentoo, I really do, except when it doesn’t work as advertised. Scratch that. Gentoo is still my current favorite distribution and nearly always works as advertised.
Some quick notes about the infrastructure around here:
- The blog system lives on an internal server and the static pages are periodically mirrored to the public-facing server. At least, that’s how it was explained to me. Blogging was a bit frustrating before I figured that out.
- The comments are moderated. So far, I have not had occasion to delete a single comment, save for some duplicates. I would actually be happy to remove that configuration and let the readers chat amongst themselves. However, due to previously described mirroring system, the comments would not show up for 5-10 minutes after posting. This would invariably lead to a lot of double posting and general irritation.
- Yeah, the Movable Type/MySQL comment system sometimes seems to go down or respond with errors. I have seen it happen occasionally when I post a comment. This may be the first blog where this problem is a real issue. It seems Penguin.SWF is the only blog hosted at blogs.adobe.com that receives an appreciable number of comments. I’m not sure why that is.
While we’re on the subject, why not check out some of the other Adobe blogs? I don’t think any of them talk about Linux much, but you may find interesting tidbits about other Adobe technology,