Slashdot Mirror
Notes On The Future of Video on Linux
Dina's Dream points out two interesting articles currently running on LinuxPower, and linked from Gnotices (GNOME news site) as well. "The first article is a really good
summary of the current state of affairs of video under Linux and the direction we should take. Questions are bounced back between a few very knowledgeable people, including
GStreamer developers, SGI people and Alan Cox. The second article is
a set of lessons learned by Chris Pirazzi while working at SGI. Chris was involved in a lot of Video API programming at Silicon Graphics, and raises a few very good points based on his experience. All people even remotely working on video drivers or software should read these points and take them to heart."
My pvr production is running slick as can be, now that I have ditched all the capture card madness (WinTV, Buz, etc). All I need now is a $30 firewire card and my trusty Canopus ADVC-100 and I capture full frame 720x480 video in better than DVD quality. If you are considering doing a lot of capture/encoding of anything, I highly recommend this setup. dvgrab running under linux seems to be very stable and the captured video is virtually identical to the source.
DivX is waste of energy and programmer time. Its so patent trapped that one yawn from the movie industry to the patent holders and it'll be gone except in very limited form
Something like VP3.2 holds more promise (and hey I got the lib to actually -compile- on a non windows/mac box two days ago)
Now combine VP3.2 video with Ogg audio and you have a credible media format. Add xhtml navigation and you have something really cool
From: http://heroinewarrior.com/bcast2000.php3
After a long period of deliberation on the matter, Broadcast 2000 has been removed from public access due to excessive liability.
We've already seen several organizations win lawsuits against GPL/ warranty free software writers because of damage that software caused to the organization. Several involved the RIAA vs mp3/p2p software writers. Several involved the MPAA vs media player authors. You might say that warranty exemption has become quite meaningless in today's economy.
Fucking dmca....
Video on linux has always been one of my favorite things.
The biggest advance in v4l was essentially the XFree86 4.x release since it encorporated an Xvideo extension allowing for really nice video play back in Linux.
There are a couple cards that are extremely well supported. I personally use an ATI AIW and the MPEG playback in incredible. In fact, I prefer MPEGs in Linux verses Windows simply because I think Linux does a better job at using the RGB conversion stuff at the hardware level than Windows does.
Of course, the biggest foe to video in Linux has been the fact that many of the best accelerations (iDCT) are simply not supported because card makers fear releases 'techinical secrets.'
Another problem is the split in video display APIs. Prior to the Xv extension being released, the Linux kernel had a video4linux API. The second version of that API is incredible as it has so many features that would allow for truely pluggable components.
Unfortunately, all X stuff is implemented in user space so cards that have integrated display and video stuff end up supporting everything in user space and then providing a loopback mechanism to work with the kernel API. It's a little messy but hopefully everything will get worked out as things progress.
Otherwise, hats off to all the hard work of the gatos project, the v4l2 project, and linuxvideo. If you haven't tried all the really cool stuff available for video on linux, you really should.
int func(int a);
func((b += 3, b));
Paul: You mention that it makes little sense to sync audio to video and then state that this is what most applications do.
On the contrary, syncing video output to the audio is much easier, since audio resampling is a big pain. It's much easier to just watch the soundcard buffer and decide approximately when to show the frame as you imply. You only run into big difficulties when you want to sync audio to the video (or more accurately, sync video blits and audio output to the vertical refresh rate of your output device).
There are times when this is a very important. You imply that video framerates are between 20-30fps, which is quite small. For playback of video sources we need to handle framerates of 50fps and 59.94fps. At such a high framerate, the monitor refresh must track the video input in order to achieve smooth video. See the link to Dave Marsh's faq on judder I mention in the article.
In these cases, you need to set the monitor to the correct refresh rate and then watch the error between the refresh and the sound card clock, and resample the audio when necessary: playing with the refresh rate on the fly would cause a monitor resync and disturb playback!
If video cards let applications drive the refresh of the monitor (software genlock), we could run it based on the audio clock and get the advantages you describe. However given the current state of the hardware it's better to do these small resamplings. That said, actually doing this in linux is still infeasible without some updates to the APIs and drivers, which we are working on.
-Billy Biggs