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."
Yeah, there are lots of DivX players for linux. I've seen them everywhere. But how come none of them seem to work with Mandrake? I tried everything. The #1 problem with linux is no longer hardware support, since Mandrake supports all the hardware in my computer, even my printer, automatically.
The #1 problem is ease of software installation and configuration. Sure rpms are great, until you get some that depend on something else. Which depends on somethign else, which dependson the rpm you were trying to install in the first place. Not to mention when you try to install something from source, and it wont compile. I don't have the time or the patience to figure out what is wrong with someone else's code.
I know how to code yes. But when I donwload a DivX player and it fails to make, make install. I have no clue how to fix it. That's why I'm downloading a DivX player, and not writing my own. So far Tribes 2 server, and Netscape/Mozilla are the only linux programs that I've seen (there are probably more) that have windows style installations. This means it can be done. Do it more often. Like all the time. Then maybe I wont have to reboot my computer to watch movies.
The GeekNights podcast is going strong. Listen!
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.
Well, if SSSCA passes, there won't be any video on linux.
There is one group working on a complete multimedia network architecture. More information can be found unter www.networkmultimedia.org.
Quote from the web-page:
"The goal of this project is to design and implement a network-integrated multimedia infrastructure for Linux as well as other operating systems. Since many low-level parts of such a system already exist (like en-/decoders, de-/compression, multimedia networking APIs, CORBA, and others), our primary goal is the development of an architecture, which integrates these usually isolated modules. This unified architecture will offer a simple and easy to use interface for applications to integrate multimedia functionality. Therefore, it can be used as enabling technology for traditional multimedia applications, but also for ubiquitous computing and mobile computing.The result of our work will be made available as OpenSource."
- Jarman
I read the article on video for linux, and what the author basically describes is SDL. I think that he means it to be a layer under what SDL is, so it wouldn't be portable, but the functionality is basically SDL.
This Wiki Feeds You TV and Anime - vidwiki.org
Personally, I've never had problems with RedHat installs (YMMV), the only time I ever have problems with *nix system is when I don't know where the files are that allow you to configure the system. Since every distribution of linux, BSD and Solaris all seem to be a little different in their config.
Are they still around? Is anyone continuing their work? And what of VirtualDub? Is there a Linux port out? Anyone know? It sucks to have to boot into Windows just to use premiere... (Yeah, yeah VMWare, but shhh :) ).
the slashdot headline is more accurate than the article's actual title. the author's approach comes almost entirely from a consideration of video. if he was starting from a primary interest in audio, he would have talked about many different issues, and mentioned different kinds of solutions. gstreamer is a cool system, but it needs to be stressed over and over that gstreamer is an architecture for building applications. it does not offer any mechanisms for inter-application communication or synchronization. since most people want to do a lot more than write a particular plugin for gstreamer, gstreamer doesn't help us when the challenge is not providing an architecture for a single program, but one for multiple applications on the same (or even networked) system(s). when you want to run a cool video processor along with a really nice FX rack for audio, gstreamer can't help you unless the author of each component had decided to implement his stuff as a gstreamer plugin. since this cramps the GUI style rather considerably, its unlikely that many people will choose to do this. finally, i would note that although it has become customary to sync audio to video, this actually makes very little sense when the temporal resolution of audio (22000-96000 frames/sec) is vastly greater than video (20-30 frames/sec). its really just an artifact of the way technological development has happened, of who has the most power in the entertainment "content" business, and of the fact that we generally consider visual data more significant than acoustic data. we'd be in much better shape is the conventional approach was to sync a video stream to audio, since we could easily and uniformly take advantage of the much better clock resolution that audio devices provide.
Funny.
I also reboot my computer to watch movies, but in the opposite direction.
On my computer, the only things I do is to play games (mainly quake3 and total annihilation) and watch movies and music.
I usally run windows, but when I want to watch a movie, I just can't face the crappy windows media player. (Yes, I tried others. bsplayer, microdvd, etc. no one satisfied me.)
Then I boot linux to watch it on MPlayer, by far the best player i have seen.
By the way, MPlayer is only avaiable as source code, but I never had any problem compiling it.
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));
Namely: graphics drivers should be moved into the kernel, which should provide a very low level graphics API
There are many people opposed to this as bloat in the kernel. But come on, there are so many things in the kernel that should be called bloat if gfx is bloat (like sound for instance).
And of course this is related to video. I think these low level drivers would include support for TV/out, processing signals from TV cards, standardizing APIs.. etc.
This has to be the only article I have read in a long time that stresses the importance of doing things the right way, instead of the wrong way or, heaven forbid, the "Max Power" way.
There are many core issues with video on any Unix that need to be hammered out now to ensure that things will go well both now and in the future.
As the author mentions several times, adapting refresh rates to video frame rates and working with the monitor's vertical sync as well as audio sync etc, are all very important things that need to be implimented before Video for (insert favorite unix here) will become anything more than a glorified hack.
The first logical step is to impliment what is needed to do things right, and to impliment them in the right(proper) way. the X-protocol should be fully implimented in Xfree, and the kernel should be extended to enable applications to be written which can make full use of the hardware, with minimal kludge-work.
Then the focus moves to making the "killer-app" type media production tools and players. The power of Open Source is the ability to build on the work of others. However, stealing someone's hack to adapt refresh rates, and jamming it into your own code is not an optimal solution. Focus on doing things right the first time, anything less (especially when dealing with core issues) is just asking for untold headaches and frustration in x years, when we are kicking ourselves for not doing the right thing the first time
Comments should be like skirts. Short enough to keep your attention, but long enough to cover the subject
Or you could just get apt-get and let it sort out the dependencies in your rpms for you automatically. The Freshrpms apt archive (for Red Hat 7.2) has packages for
And all you need to install them is type apt-get installl (whatever) to fetch the rpms, whatever dependencies they need to install, and install the packages.
The problem lies herein:
(e) Notwithstanding Sections 2.1 (a), (b), and (c) above, no license
is granted to You, under any intellectual property rights including patent
rights, to modify the code in such a way as to create or accept data that is
incompatible with data produced or accepted by the Original Code. By way of
example but not limitation, a Modification that adds support for other
compression data such as MPEG-1 or MPEG-2 would be permissible, but only if the
resulting Larger Work continues to support playback of VP3.2 data.
Modifications that provide only playback or encode support are also permissible.
However, a Modification that adds support for encoding or playback of any non-
VP3.2 compatible files or bitstreams without complementary support for VP3.2
encoding or playback would not be permissible, and no license is granted for
such Modification(s).
Basically, this is denying users the right to modify the source code to produce binaries that produce a stream incompatible with the original software. It may sound good to some, but I urge developers to think twice before releasing modifications or compiled versions of the VP3 codec because, even if unintended, a compiler bug or error in your modifications to the software could mean that the stream your modified VP3 codec produces is unintentionally incompatible with the VP3 specification, opening you to legal procedure from On2 Technologies, the proprietors of the codec.
The VP3 codec licensing terms are not only not Open Source, they are a threat to developers, contribuors and distributers of VP3 both in source code and compiled form. Please contact On2 Technologies and try to convince them to update their license to remove this dangerous clause, and spread the word to your friends!
Some of the motivation for the design elements that Chris objects to is the desire to exploit very sophisticated hardware. Ideally you develop to one API and the application exploits very different hardware on heterogeneous systems. Mainstream PC cards are only just starting to get sophisticated about video so it doesn't on the face of things need some of this, but if you don't abstract then you are stuck with applications that either can never exploit better hardware or need to be ported by hand to use it.
As long as Linus keeps multimedia and extraneous "features" out of the kernel. As in Operating Systems Design and Implementation by Tanebaum, the author of Minix, I tend to think that compartmentalization is safer from a system security and integrity POV, but hardware threads are nice. The only things that should reside in kernel-space are drivers and system functionality. I can't even see justifying IP stacks in the kernel since that could run on top of the ethernet or whatever is underneath because a layered approach can install/remove/restart parts of the system w/o killing the whole thing. Btw, MINIX starts in less than 1 sec from a HD on a 486. And pretty darn stable too, except for the lack of preemptable kernel processes. I suggest running it on Bochs.
Multimedia codecs should remain where they should be, in libraries.
The biggest trick the devil pulled was letting lawyers become politicians so they can write the laws.
Actually i believe that some of the cable companies here in Denmark are still using an Amiga for generating their "info channels"
The college I work for has their own cable TV network set up for the dorm residents. One of the channels that they get is an endlessly looping "info" channel with campus events and the like on it.
We _just_ retired the Amiga 1200 that's been doing this for years. And it was only because the poor thing had started to overheat and crash - the job it did was still more than adequate.
--saint
Make all the tools pipable (that's the *nix way) That way I can implement the parts based on my hardware, time and disk space constraints.
Don't tell me it can't be done - There are amny pieces already out there. They just need to be put together.
BTW, I have a system that can capture TV, DVD, and VCD, play most formats, and record to VCD now. It took multiple tools to do the job, and some are not even the most 'up-to-date' ones that _should_ work. I will soon try recording to digital tape (aka a DAT drive) and see how that works as well.
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
Looks like video on Linux is only going to be the domain of professionals, motion picture houses with renderfarms and electronics manufacturers with the wherewithall to embed it into appliances. The age of the bedroom hacker hacking his PC to use Linux for video editing is almost over.