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."
What the hell is that supposed to be? Is it supposed to be like th magic eye things? Never could get those...
I love this philosophy. Cut the crap, focus
on what's important, and you end up with the
right facilities to build higher-layer stuff
on top of later.
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
Clueless, completely clueless .... oh well.
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 :) ).
That sure was slashdotted quickly, does anybody have a mirror? Somebody should write a program to refresh /. a lot and mirror pages in the new articles right when they are posted, before the /. effect hits, lol.
Appears they are slashdotted to hell and back.
(sigh)
Check my Go-related blog for beginners: DGD
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.
I wish they had some more details on how they did things and some downloadable software that shows
off their architecture.
I put together a simple VCR using existing Linux tools. See it at : http://cheema.com/vcr. Warning, my uplink is very slow.
I use NVrec/ffmpeg for recording and grab the TV guide data from tvguide.com.
I had hoped to release the software under GPL but now that I am working on a very related product at work, it may not be kosher with my employer.
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.
For me, one major thing holding me back from using Linux as my home theater PC is the lack of a Linux port of dScaler. My own programming experience isn't enough for me to wade through the Linux video APIs to get the job done. Not to mention the fact that Linux APIs for video change every year or so (frame buffering, Xvideo, v4l, v4l2, etc).
When someone doesn't make software that compiles correctly, it's usually because they don't make very portable software to begin with.
What I'd like to see is less dependency on little tiny libraries that change all the time and throw the entire system out of whack.
In the old days they used to make a program that interfaced with X and OSS directly and threw it in a statically linked Motif GUI. I'm not advocating this, but it seems we've been thrown to the other extreme these days.
I am a C++ developer. I shy away from, for example, wrapper libraries like gtkmm because simply not having gtkmm installed can be enough to turn people off from using my software, and I don't want to do risk that.
Can I or anyone else really be so arrogant to assume that people will find my software important enough to go through dependency hell just to use it?
8-)
I read the lessons learned at SGI on video and it's very interesting. A lot of it appears to apply to other APIs than video. For example networking. It would be interesting to see a simplified network API with TCP/IP in user space not the kernel.
MPI-GAMMA is a step in this direction (but lacks device independence).
http://130.251.61.4/project/gamma/
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
...but faster!
I am having similar troubles, however mine is with Windows 2000 and Windows XP.
.NET architecture. There is no configuration options anywhere in Windows 2000 and Windows XP. I tried to recompile it to include it but I found out that I have to pay several hundred thousand dollars and sign a non-disclosure agreement to see the code. There was a beta version of IPV6 for Windows NT4, but it wasn't compatible with Windows XP and is not Active Directory aware.
My employer (a very large corporation) is trying to roll out Active Directory and IPV6 to get ready for the next generation
Unfortunately we have decided to move to a stable Solaris/Unix server network instead as we need support NOW for this 6 year old protocol.
I really enjoyed the FreeBSD installer talking about a kernel configurator even before /stand/sysinstall started. I don't know what all this stuff means, I am just a "home user".
When it asked about slicing up my hard disk (a0ivd02a1), I just turned off my computer, got a copy of slackware from my friend, and PARTITIONED my hard disk like a normal computer user should.
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!
Joe Barr is a fucking drooling moron, unable to even get mplayer to work he decided to trash it.
Doubtless a Taco Snotting Champion.
You're supposed to be working on my retirement package, not posting long articles about Linux video (we know it'll never work anyway). Get back to work or I'll sick the short whiny dwarf on you!
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.
Forgive me if I am wrong, but the upcoming OpenML libraries are going to change a lot of whats going on here. If the industry supports OpenML like is does OpenGL then software programmers like us :) will be able to focus on OUR CODE and not have to worry about low-level media calls and having to use several different cryprtic media libraries just for multiple platform support!
The Jahshaka project is moving to OpenML, so you can be sure that you will see OpenML video cards hitting the market real soon...
http://www.jahshaka.com for more info
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.
- Disclaimer: This is a nostalgic trip ;-)
... This meant that the graphics signal was perfectly in sync with other equipment in the facility and so could be "mixed" with other signals in the facility.
The problem is that the Linux kernel is currently missing a retrace interrupt counter...
The Amiga had a vertical refresh interrupt - actually you could even synchronize to an arbitrary (x,y) coordinate on the screen via the "copper" co-processor.
Some of the SGI graphics boards actually had an input jack called "genlock" into which you plugged a video signal
A "genlock" could be bought for the Amiga as an accessory for very little money (~100$ or so).
The Amiga was very well adapted to television display. So much that the CPU clock frequency was some multiple of the horizontal scan frequency of either PAL or NTSC! This made for incredibly smooth graphics on a standard television, and so with an Amiga you actually had a very cheap system for generating title screens etc. for your homevideo. And this was more than 10 years ago! Actually i believe that some of the cable companies here in Denmark are still using an Amiga for generating their "info channels".
Really. Installing this from source really is quite easy. Just do
./configure [options]
make
make install
And on my matrox card I get hardware scaling and other good stuff.
-------------------------------------------------
UNIX isn't dead, it just sme
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.