Slashdot Mirror

Actually, my current best DVD player is Mplayer and Linux running on my Toshiba Satellite DVD laptop.

I use Gentoo Linux with all the performance patches in the kernel (low-latency, pre-empt). Combine this with the fact that all of my libraries/apps/tools are built specifically for my hardware, and I have a blazing system. I use the latest XFree86 to support my laptop's video hw accel. Then, I use Mplayer from the CLI (tho, there are some fancy GUIs for those who prefer the stuff). Since the laptop has a TV out, I can plug it into my home entertainment system.

The end result is a DVD player that allows me to skip all ads/warnings/etc, and watch what I want when I want. Plus, since everything is so optimized for my hardware (it helps that everything on the laptop is 100% supported ;-) I actually get DVD playback as good as anything else I've tried (I have a PS2 and used to own a dedicated DVD player). I was even shocked to discover that with all this set up, DVD playing under Linux actually /can/ outperform Win32 on the same box (don't flame me, it's really true.. and I was as surprised as you are ;-)

Try Xine, or MPlayer. Xine has excellent DVD menu support, a fully functional GUI, and also plays other video files. You'll need libdvdcss, libdvdread, libdvdnav and xine-dvdnav as well to play encrypted DVDs with menu support (see here for more info).

Look up MPlayer or Xine.
AFAIK, they both play DVD's and come with/you can get CSS plugins' for them.
There are a bunch of DVD players for linux as well.

I guess this could be done using MPlayer and LAME.. Mplayer supports mms:// urls and about all codecs there is.. The proprietary extensions to rtsp:// (streaming realaudio/video) is also about to be supported.. It also supports writing audio to raw pcm or wav, which can be encoded to mp3 using LAME.

The problem with this reasoning is that VBR encoding (popular with the divx crowd) requires two passes over the video, once to find the hard to encode spots and twice to actually do the encoding. Copying the whole thing to the hard drive actually speeds up the I/O, since two reads to the hard drive is much faster and less taxing on the system than two reads from the DVD-ROM drive.

For SVCD (which is usually done with CBR), this problem does not exist, and indeed the tarball of the mplayer program comes with a shell script called mencvcd which decodes a DVD to raw uncompressed video and then reencodes it at once to [S]VCD using a named pipe to save your hard drive the 100GB of space per hour that uncompressed video would otherwise require.

I cannot view the videos, since I run Linux...

Dude! Get MPlayer or Xine. There are others, but those two seem to be pretty well done.

"What we need is an Open Source application to capture a .ra or .ram stream, convert it to .ogg or .mp3 and optionally save it to a file or just play it"


MPlayer, now fully GPL'd, has (beta) support for realmedia, and comes with an encoder for many formats.

Does anybody still have Real Player installed? And actually use it for a general player and not just for when certain cites require it for video clips?

Of course. RealPlayer is actually pretty good as an mp3 stream player. What else is there on Linux for streaming video anyway ? (besides the almighty mplayer).

-DZM

• gcc 2.96 is actually more standards compliant than any other version
  of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable yet).
  It may not be standards compliant as in what most others
  are shipping, but 2.96 is almost fully ISO C99 and ISO C++ 98
  compliant, unlike any previous version of gcc.
• gcc 2.96 has more complete support for C++. Older versions of gcc could
  handle only a very limited subset of C++.
  Earlier versions of g++ often had problems with templates and other
  valid C++ constructs.
• Most of gcc 2.96's perceived bugs are actually broken code
  that older gccs accepted because they were not standards compliant - or, using
  an alternative term to express the same thing, buggy.
  A C or C++ compiler that doesn't speak the standardized C language is
  a bug, not a feature.
  In the initial version of gcc 2.96, there were a couple of other bugs.
  All known ones have been fixed in the version from updates - and the version
  that is in the current beta version of Red Hat Linux. The bugs in the initial
  version don't make the whole compiler broken, though. There has never been
  a 100% bug free compiler, or any other 100% bug free non-trivial program.
  The current version can be taken from Red Hat Linux 7.2. It will work
  without changes on prior 7.x releases of Red Hat Linux.
  Since a lot of people claim 2.96 is buggy because of the accusations
  found in MPlayer documentation, I have
  included the facts that led them to incorrectly believe that 2.96 is buggy
  here.
• gcc 2.96 generates better, more optimized code.
• gcc 2.96 supports all architectures Red Hat is currently supporting,
  including ia64. No other compiler can do this. Having to maintain different
  compilers for every different architecture is a development (find a bug, then
  fix it 4 times), QA and support nightmare.
• The binary incompatibility issues are not as bad as some people and
  companies make you believe.
  First of all, they affect dynamically linked C++ code only.
  If you don't use C++, you aren't affected. If you use C++ and link statically,
  you aren't affected.
  If you don't mind depending on a current glibc, you might also want to
  link statically to c++ libraries while linking dynamically to glibc and other
  C libraries you're using:
  g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
  (Thanks to Pavel Roskin for pointing this
  out)
  Second, the same issues appear with every major release of gcc
  so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++
  is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary
  compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with
  gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0.
  Besides, it can easily be circumvented. Either link statically, or
  simply distribute libstdc++ with your program and install it if necessary.
  Since it has a different soname, it can coexist with other libstdc++ versions
  without causing any problems.
  Red Hat Linux 7 also happens to be the first Linux distributions using
  the current version of glibc, 2.2.x. This update is not binary compatible with
  older distributions either (unless you update glibc - there's nothing that
  prevents you from updating libstdc++ at the same time), so complaining about
  gcc's new C++ ABI breaking binary compatibility is pointless. If you want
  to distribute something binary-only, link it statically and it will run
  everywhere.
  Someone has to be the first to take a step like this. If nobody dared
  to make a change because nobody else is doing it, we'd all still be using
  gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...
• gcc 3.0, a so-called stable release (released quite
  some time after Red Hat released gcc 2.96-RH), fixes some problems, but
  introduces many others - for example, gcc 3.0.1 can't compile KDE 2.2
  correctly due to bugs in gcc 3.0.x's implementation in multiple inheritance
  in C++.
  With the recent release of gcc 3.1, there finally is a compiler that
  is better than 2.96 - but up until then (more than 18 months after the
  release of Red Hat Linux 7), gcc 2.96 was the best compiler available.

Check out the MPlayer development mailing list. It shows how a opensource project should be handled, with things like a strict patch submission policy to the lead developer's wrath (Arpi).

MPlayer can play some .rm files now:

http://www.mplayerhq.hu/

It doesn't stream, though.

I really don't know why anyone didn't mention this before, but MPlayer is now able to link to the Real libraries and play Real formats. Those are closed codecs; but Helix looks like it'll be closed as well - so where's the advantage to using a Real sponsored player, when MPlayer uses all the same closed-source libraries, and the base system is GPL'd? If you contribute to MPlayer (which also plays ASF) then Real can't snag your work like they can with Helix...

I really don't know why anyone didn't mention this before, but MPlayer is now able to link to the Real libraries and play Real formats. Those are closed codecs; but Helix looks like it'll be closed as well - so where's the advantage to using a Real sponsored player, when MPlayer uses all the same closed-source libraries, and the base system is GPL'd? If you contribute to MPlayer (which also plays ASF) then Real can't snag your work like they can with Helix...

MPlayer - MS Mediaplayer killer!

Alright... I know about this testing stuff and how long has woody been on but KDE 2.2 ? I mean come on, Redhat 7.3 was released before this one and it came with KDE 3.

KDE 3 is out now, but it wasn't when Woody went under freeze. The point of Debian's "stable" release is to be stable, not to be flashy; the idea is "tried and true", not "latest and greatest".

RedHat 7.3 shipped with KDE 3. It also shipped with an unofficial, experimental version of GCC that they called 2.96, which causes compilation issues with many major packages. Would you want this running as part of, say, a compile farm? I wouldn't put my trust in a release that can't even compile Apache correctly.

Not all of us use Linux for servers only, but those who do want a system that's solid. If you want more bleeding-edge software in exchange for a bit of risk that things might not work on occasion, you should try Debian's unstable branch. I've been running it on my own machine for the past several years and I find it to be quite nice. And you can always install "stable" and then upgrade individual packages using newer versions from "unstable".

Actually, quicktime seems to work quite well on linux via, for example, mplayer, with the sole exception that I've run into of SVQ3 (Sorenson, of course). SVQ1 is even working now, with optimized code (also appearing in FFMPEG) based on the reverse engineering done by the folks working on Xine. Oddly enough, the specifications page for QT6 mentiones SVQ2 and SVQ3, but implies that it DOESN'T support SVQ1...

If the release of QT6 means that MPEG4 will become the "default" codec for QuickTime movies as time goes on (as some posts, As well as several of the QuickTime pages at Apple, are hinting), the "quicktime barrier" to video on linux will all but disappear, since as far as I can tell just about every variant of MPEG4 works on Linux in some form or another. I suppose this depends on how the dispute between Apple and Sorenson goes...(anybody heard anything about that lately?) and how long it takes someone to work out how to interpret the type of what I assume are "pointer files" or something of the sort on the previously mentioned apple Quicktime Mpeg4 page (mplayer seems to have trouble decoding them...)

Of course, somewhere in here I should insert the obligatory comment about Ogg Theora and how I wish they'd hurry up and get the mailing lists working and get a working prototype that I can test, but as I can't think of what to say, I won't....

Yeah, i sumbitted this as a story, but it got rejected... anyways, MPlayer has Sorenson support now.

"To watch divx5 movies, it is not enough to download a codec like with WMP, but you have to recompile your media player, upgrade your ALSA, upgrade your kernel..."

Huh?!? All I did was compile MPlayer.
Are you using kernel 1.2 or something?

If it's MPEG-4 you want (and you should), mencoder, bundled with mplayer, should do nicely.

Xine (with decss plugin), Mplayer, Ogle, Videolan

You should really check out xine -- it's a great video player for Linux. It handles lots of avis, mpgs and movs. Just recently Sorenson support was added to it. I reckon that soon the qt support will be near perfect; Sorenson is the first step, all they need now are the sound codecs, which mPlayer has. So since mPlayer and xine are both OSS, it shouldn't be too hard to get the sound codecs into xine.

In any case, video playback in Linux is certainly quite good these days. I enjoy watching DivX encoded Cowboy Bebop episodes in Linux trouble-free, on a 266MHz laptop!

Mplayer is faster than Xine on sorenson videos.

Also, MPlayer in cvs currently has native SVQ1 support as well. Certainly, I was just able to play the trailer I downloaded off of one of the mirrors with it. Don't know how many other trailers and such are available in a format that the SVQ1 decoder can handle, but seeing this recent trailer in it gives me hope..>

(Anybody know the proper way to configure Konqueror to use MPlayer to play these things automatically?...)

(In the interest in giving fair credit to the Xine project - I do believe MPlayer's implementation is an optimization of the code made available by Xine, so they certainly deserve credit for figuring it out in the first place...)

Please note that it also was the last one; as of the G450 TV-out doesn't work anymore under Linux (and the Parhelia probably won't be much better). Check out the G400 prices on ebay. They're good business, probably because of this. [source: mplayerhq]

---"I have to give Ransom credit for his good answers. Especially in the area of whether Caldera will make billions off Linux without giving back to the community."

The community gives to anybody who accepts their license (usually the GPL). The GPL has no clause saying that they must tithe if they make money on GPL software. I could care less if a company makes money on Linux, however if they provide a good product, I'll support them.

---"Ransom makes it pretty clear that Caldera's development of Linux, even though done for profit,"

Why even mention that? Go on to thier "Contact Us"... Caldera International, Inc. Hmm, wonder what that Inc. stands for .... It's not like they're an INCorporated company, right?

---"is in itself something big that's being given to the community--it's the effect that takes place when a product has a lot of support from reputable companies more than which lines of code Caldera writes and puts wherever. Even in Caldera didn't write a single apostrophe of code but only packaged other people's hard and free work and sold it for profit, they'd still be opening a market window for the Linux community that wouldn't have existed otherwise."

Since they're a company, let thier business stragedies hold them up.

---"I believe that for Linux to really be successful, both in terms of code quality and widespread acceptance, a team of companies needs to get together with a specific purpose to fulfill: To develop a desktop version of Linux similar in functionality to Windows XP or Mac OS X."

Funny thing is Linux is sort of the P2P os. All the parts are everywhere, there are multiple 'fixes' to the same problem, and developers are around the world. Asking some standards body to make a "UnifiedLinux" is asking for trouble. Other than thier words, what are these people going to do to sway developers to do addon X to code Y? The "UnifiedLinux" players are probably going to be PR and programmers, but still how's that going to guarantee that thier patch is going to be included?

---"In other words, other than a few options here and there, it wouldn't really have the possibility of configuring every detail. The bare-bones system, which basically means a desktop with a few icons on it for basic functionality (and no applications) would basically be integrated into the kernel."

In a way, isn't that true to a certain extent already? Linux/Unix ideas is you reuse components like crazy. Because of that, I just cant see "bare bones" along with desktop with a few icons. You need a bit of stuff to build your way up to X and your windowmanager.

---"When the computer boots up, it boots directly into a nice graphical desktop, kind of like the way BeOS did, except Linux will actually stick around. Most of the configuration would be built in, heavily reducing the number of "system" files."

So you're saying that "advanced OS'es like Windows" dont have as much systems files? Ever look at /windows , /windows/system or the registery with regedit? Yeah. Windows has tons of configuration options, with most of those being hidden it clsid's and other crap. It's either configuration TEXT files or a kludge of a registery.

---"No desktop system needs to drown in its own configuration. I would say that a really good bare-bones desktop Linux OS shouldn't take more than 15 to 20 megs of space, and that includes all the beautiful graphics it would have."

15-20 megs wouldn't even be enough for the graphics libs for your "beautiful graphics". Considering that WinXP is 1 GB install, I think people would be OK with a graphic install around 300 MB. I actually mean having it work correctly (including all the pretties, decent fonts, AA, all the "new OS stuff").

---"To make this system useful, a number of applications made specifically for this version of Linux would be included, increasing the size to about 60 or 80 megs. This might include the standard "fun" stuff that consumers look for, like video editing, audio editing, image editing, and the more mundane crap, like word processing and whatnot. Obviously, major formats would need to be recognized."

Most of the closed formats have been dealt with. Office argment has been beaten (like that already dead horse). Even DiVX, MPEG 4, DVD's, and newer MS and Apple/Sorenson codecs are being released by 3'rd party develpers.

---"Only when something that's actually easy to use becomes available, Linux will skyrocket in popularity and Windows will go into the dumpster. Yeah, most of the code for this exists. Someone just needs to recognize why Linux tends to be so damn complicated, and rearrange these pieces into something that's really well designed and coherent."

People will take "Easiness" over stability if that means complication. That alone shows why that is true. And of curse, you're dealing with the mysticism of a computer...

---"As a disclaimer, just so someone doesn't say, "You stupid fsck! If you think Linux is too hard, go back to Windows and enjoy crashing all the time."

That's what a slashdotters and other moronic haxor types do. They hurt linux. Usually though, RTFM or STFU is the best answer to a linux question (in their minds). Beginners have no idea a manual exists for Linux (man).

---"Otherwise, learn how to use the damn thing!" I've been using Linux for years now, since an old Yggdrasil distro I picked up at some computer trade show, and a 8 CD set of crap they downloaded from a bunch of mirrors and stuck on some CDs. (Back in those days, those CDs were really handy, especially considering that most folks had a 14.4 connection. And that was considered fast ! Even 56k was far off! So that was a loooooooooooooooooooooooong time ago.)"

Neat little rant :-) I'm a user since '97. I just dabbeled in it. Now I run it as my main desktop of choice. Windows is my games desktop, as that seems to be its forte.

---"Anyway, I've since realized that Linux is too fragmented. There's way too much duplication of effort. The Linux file system "standard" is totally wrong, IMO, because everything's in the wrong place. (/home should be under /usr, for example.) And the configuration is a nightmare! There are literally hundreds of configuration files strewn all over the system!"

I dont agree with that... You live in a home, so /home it is. If you have problems with .conf's everywhere (like I did), just cp the files to /etc and sym-link to the original location. Now ALL your configs are in 1 place. Now you can back up your /etc dir (and sym links across your whole FS).

---"So I since moved on to FreeBSD. All ya'll Linux folks out there can learn a shitload of great stuff from the BSD folks. Just look at how much of the system configuration for a FreeBSD system is in a single file (rc.conf). In Linux, this would be scattered across 10,000 different files in a monster directory structure under /etc/rc or something like that, as far as I remember."

I absolutely love the run-level structure. You have 1 script for each runlevel, along with some scripts for large program init's. YOu have a rc.modules, which you can update for newer hardware. My opinion, I love the RC setups.

---"As you can easily tell, I haven't touched a Linux system in ages, and there's a reason. That's why I say this desktop thing needs to be made. Linux can kick Windows' ass in server stuff. Now it needs to start kicking Windows' ass in the desktop, because only when Microsoft loses that battle, they'll no longer be able to embrace and extend, a practice that fscks up all our code because we have to be compatible with their bugs,"

Who says so? I would fully support a addon in Samba that would allow extra features (embrace and extend) than what Windows normally has. Then make a client for WIndows that can take advantage of these extra features. However, the whole idea is to make Linux seamless with windows clients/servers.

---"flawed design decisions, and programming features probably designed by lawyers and marketeers rather than programmers. Ooooooooooh well. Oh yeah, I had all kinds of Negra Modelo last night. It was fun. (If Cerveceria Modelo made software, their operating system would kick everyone's ass!)"

Oh well. Fun rant :-)

Yup, you're totally screwed. :-P

Firstly I wouldn't think this would come from a hotmail user :-)

I've been following the dxr3 (em8300) developers closely for quite some time and from what they say it's been hell developing drivers for the card (no specs at all). Even worse getting real-time divx decoding and a/v sync.

But it works now and I wouldn't trade my dxr3 for a "native" mpeg4 decoder card in the world. Decoding divx and reencoding it to mpeg2 takes about 10% cpu on my xp 1700 so it's no biggy and the quality is excelent.

What happens when divx 6 or another great codec comes out? I'll just upgrade mplayer and you'll be screwed :)

Supported by mpolayer and libavcodec.

Since mplayer got Real support the only really missing link was the sorensen quicktime codecs. Now that Xine has done sorensen and it's gpl 'ed it should just be a matter of time before mplayer has support for it too. Isn't Free Software wonderful?

...and plays great in MPlayer.

MPlayer www.mplayerhq.hu can play pretty much anything if you run on x86 and the version about to be released even plays real media.

I use asfrecorder or asfr+ try this mirror for recording streaming programmes like from www.byutv.org

I believe mplayer will record from tv cards

But... you might want to join openmovie which aims to make a complete media system based on some of the above components

When you have questions like these never underestimate searching freshmeat.net

I don't get what you mean, but mencoder (part of mplayer) can use the official DivX 5 to encode, among the other options (ffmpeg/libavcodec, XViD etc).

On a sidenote, this week they added support for RealVideo/RealAudio G2/v8 to mplayer cvs, using two of the .so/.dll-files from RP8.. Really cool! =)

Let's see, I've got my video capture card working on v4l, I've got video capture to mjpeg (good balance of 'quality of original encoding' and 'file size taken up by original encoding') working through xawtv's(no, not a troll, that really is xawtv's URL) 'Streamer' utility, I've got framerate and format conversions of other file types working through mplayer's Mencoder, and I've got The MJPEG tools for generation of VCD and SVCD video from the original sources (the yuvdenoise filter is handy when transferring old VHS's to VCD), and when I want to get more complex with my conversions, I've got transcode (the '.ppml' format for subtitle rendering seems to support quite a lot of effects...) and now I've got Cinelerra (which I can never seem to spell properly the first time) for messing with the video itself, once I figure out how to use the program (which now runs on my Slackware box after seeing a previous poster's tip about finding the libgcc* libraries and such in OpenOffice - Thanks!).

Now if only I could get xawtv to recognize that I have libquicktime.so on my machine so that I could save my video to .mov's (so that I can get more than 2GB at a time) I'd be set...

Well, that and support for .ogg [XVid/VP3]/Vorbis video file encoding (MPlayer already supports playback at least, or so I'm told, and it sounds like support for this in ffmpeg may be coming Real Soon Now from what I've seen on the mailing list...)

So, there's quite a lot of work that seems to be going on with Linux multimedia (not even counting proprietary packages and audio-only tools) if you look long enough...

Sorry for replying to myself, but that URL is supposed to be www.mplayerhq.hu, not .com.. :P

And what about fastforwarding through the previews and commercials on videos and DVDs? Are they going to try and put anti-fast-forwarding technology in them?

They already have anti-fast-forwarding technology encoded in DVDs these days. When played on my JVC DVD player, on some movies I can't fast forward past the previews and commercials.

Thats why I went out and bought a video card with TV-out support under Linux, and now play my DVDs with MPlayer like this:

Which, so far, has always started at the movie studio's logo just before the movie starts.

You know, I wonder if this really matters. I've recently discovered mencoder (part of mplayer) and it's libavcodec. It's absolutely amazing. I can compress ~5G mpeg to about 1.5G without really any loss in quality. Does QT add anything except compatibility with a popular format? If you're encoding on your own, try mencoder

By no means are you an idiot. DVD playing under Linux isn't quite there yet. I recently ranted about this elsewhere. Do a search for "linux DVD playing" on google, and you end up with the so-called "Linux DVD Playing Howto" which tells you to use livid/oms. Oms is dead. The "Linux DVD Playing Howto" is completely misleading, but you won't realize this until you've invested at least three or four hours getting the latest oms CVS and then figuring which decss plugin to use (as there are at least three but only one actually works). If you manage to finally get something that can read DVDs and output to your monitor, you'll find that oms doesn't do sound sync, so you still won't be able to watch movies.

So your next step is to complain on a forum like slashdot (this is what I did). You will then get replies telling you something to the order of "you are a fucking idiot, oms is dead, you should use xine/mplayer, it works better than in windows for me." So then you try xine or mplayer. But first, you must update your kernel, then update to XFree86 4.2, then update your SDL and maybe even update your gcc and binutils as mplayer won't even compile (well, actually it fails at the assembly step) with older versions of binutils. If you choose xine, you then have to figure out which decss plugin to use as there are quite a few to choose from, and only one or two that work (I understood dvdnav was the one to use, but an anonymous comrade just pointed out a different one in this thread). If you choose mplayer, you're in for a treat: here are the installation instructions. It took me about an hour and a half to go through those instructions before I was finally able to run mplayer's configure script. And if you think you can download some pre-built binary, you're wrong: all the mplayer asm optimizations are determed by your CPU type, which is determined by the configure script, not through run-time detection. Fortunately, mplayer does not require a separate decss plugin, so you don't have to go hunting through mailing lists and online forums to figure out which decss plugin works and which decss plugins are crap.

So, once you've compiled mplayer or xine and you've sufficiently frobbed your /proc to turn on DMA on your CD drive and get your MTRRs set up, you can actually run these programs and see if you get DVD output. Unfortunately, this is the point where you find out that the XFree86 4.2 ATI Rage 3D driver claims to support the XV extension, but, in fact, does not work correctly, causing xine and mplayer to fail on startup. So, now you have to use some "output plugin" that does not require the XV extension. The only output plugin capable enough to play DVDs would be the SDL output plugin, so you try to use that (you did remeber to enable SDL support at ./configure, didn't you?).

My suggestion: forget it. Your time is expensive and you have better things to do. There is a very vocal minority of Linux users who claim that DVD playing under Linux works beautifully: I can't argue with them. Linux DVD playback works well for them, but not for the rest of us. Look at it this way: you can spend one or two days figuring out if DVD playback will even work with your hardware, or you could go to a temp agency and get some crap job for a weekend, make $150 and buy a dedicated DVD player to hook up to your TV. Now, cut out the crap temp job which was only meant to demonstrate the value of your time, go buy the damned player, and be absolutely 100% certain that you'll be watching DVDs by the end of the weekend.

Sure you can.

> So has anybody converted these to MPEG or something?

Just use MPlayer, it will play just about anoy video file out there...

If you are looking for cheap, maintainable, stable software to replace your current Windows environment, then look into this :

Slackware Linux.
KDE.
OpenOffice (maybe StarOffice or Hancom Office or KOffice).
Mozilla (or maybe Netscape 6 or Opera).
The GIMP.
XMMS.
MPlayer.
GNUCash (or maybe Kapital).
Evolution.
NEdit.

Or if you need anything else, check out Freshmeat.

• MPlayer's GUI is skinable as well (as a matter of fact, it seems to be more extendable... this one being particularily hilarious.)
• MPlayer actually supports many more formats than Xine (at least, the version of Xine in Debian testing compared to the latest source-compiled MPlayer.. Xine could have a newer version that supports what mplayer supports). As a matter of fact, I'm yet to encounter a format (other than the obvious Quicktime) that mplayer doesn't support.

Some gripes people have had, for instance (a) wasn't GPL and (b) binaries need to be compiled on a specific machine for optimization--both are moot points now! They are now fully GPL

Not according to this

mplayer has support for DVB and the Hollywood DXR3, according to their website.

gcc 2.96 is actually more standards compliant than any other version
of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable yet).
It may not be "standards compliant" as in "what most others
are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98
compliant, unlike any previous version of gcc.

gcc 2.96 has more complete support for C++. Older versions of gcc could
handle only a very limited subset of C++.

Earlier versions of g++ often had problems with templates and other
valid C++ constructs.

Most of gcc 2.96's perceived "bugs" are actually broken code
that older gccs accepted because they were not standards compliant - or, using
an alternative term to express the same thing, buggy.
A C or C++ compiler that doesn't speak the standardized C language is
a bug, not a feature.
In the initial version of gcc 2.96, there were a couple of other bugs.
All known ones have been fixed in the version from updates - and the version
that is in the current beta version of Red Hat Linux. The bugs in the initial
version don't make the whole compiler broken, though. There has never been
a 100% bug free compiler, or any other 100% bug free non-trivial program.
The current version can be taken from Red Hat Linux 7.2. It will work
without changes on prior 7.x releases of Red Hat Linux.
Since a lot of people claim 2.96 is buggy because of the accusations
found in MPlayer documentation, I have
included the facts that led them to incorrectly believe that 2.96 is buggy
here.

gcc 2.96 generates better, more optimized code.

gcc 2.96 supports all architectures Red Hat is currently supporting,
including ia64. No other compiler can do this. Having to maintain different
compilers for every different architecture is a development (find a bug, then
fix it 4 times), QA and support nightmare.

The binary incompatibility issues are not as bad as some people and
companies make you believe.
First of all, they affect dynamically linked C++ code only.
If you don't use C++, you aren't affected. If you use C++ and link statically,
you aren't affected.
If you don't mind depending on a current glibc, you might also want to
link statically to c++ libraries while linking dynamically to glibc and other
C libraries you're using:
g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
(Thanks to Pavel Roskin for pointing this
out)
Second, the same issues appear with every major release of gcc
so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++
is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not binary
compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with
gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0.

Besides, it can easily be circumvented. Either link statically, or
simply distribute libstdc++ with your program and install it if necessary.
Since it has a different soname, it can coexist with other libstdc++ versions
without causing any problems.
Red Hat Linux 7 also happens to be the first Linux distributions using
the current version of glibc, 2.2.x. This update is not binary compatible with
older distributions either (unless you update glibc - there's nothing that
prevents you from updating libstdc++ at the same time), so complaining about
gcc's new C++ ABI breaking binary compatibility is pointless. If you want
to distribute something binary-only, link it statically and it will run
everywhere.
Someone has to be the first to take a step like this. If nobody dared
to make a change because nobody else is doing it, we'd all still be using
gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point...

gcc 3.0, the current so-called "stable" release (released quite
some time after Red Hat released gcc 2.96-RH), fixes some problems, but
introduces many others - for example, gcc 3.0.1 can't compile KDE 2.2
correctly due to bugs in gcc 3.0.x's implementation in multiple inheritance
in C++.
Until another set of 3.0.x updates is released, I still claim 2.96 is
the best compiler yet.

"Green Goblin's Last Stand" works just fine with MPlayer, provided you download the .asf file from its actual URL first.

well, two basic parts: hardware and software
first of the hardware is pretty independant of the os, just pick the highest quality capture card you can afford that is supported in linux, add a reasonable camera, sound card, and a nice modern machine of any kind. I use a bttv card, which works well for me, but of course it depends on your exact needs, and the camera that you hook up to it. As to software:
SDL, mostly used for game programming, but has some of the capabilites needed for capturing, sound recording, etc.
v4l the basic component of all video type stuff under linux-you can see the list of crap it supports there, but it doesn't really have facilities for actually capturing to something like mpeg.
avifile everything you want in a capture API, will let you output to all kinds of formats.
mplayer I have heard that they support capturing now, but haven't used them for that, but is what you will be using for playing back the files you capture.

My recommendation would be to use the VCR project, and one of these for audio. VCR uses avifile to record the video in your chosen format, and will record the audio also, but if you want seperate files for audio and video, it is simplest just to use the mic in with another program.

Let me know if you have problems--it's remarakably similar to what is already done to record television programming, with higher quality requirements, so you should be able to take advantage of all the PVR projects out there.
Or you can let me do it-send me the requirements, 1500$, and I'll send the box back a week later
;-}

First of all, this is not an official Red Hat statement. Anything said here is purely my own opinion and not necessarily Red Hat's. I happen to work for Red Hat, but this does not mean I have to agree with (or do agree with) everything Red Hat does.

For instance, I wholeheartedly disagree about Red Hat's choice of default desktops (GNOME is ok and should definitely be included, but KDE 2.x has a lot more interesting features (e.g. the Konqueror web browser/file manager) and is more friendly to total newbies, therefore IMO it should be the default).

The choice of compilers is an entirely different thing though:

• gcc 2.96 is actually more standards compliant than any other version of gcc released at the time Red Hat made this decision (3.0 is even more compliant, but not as stable yet). It may not be "standards compliant" as in "what most others are shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98 compliant, unlike any previous version of gcc.
• gcc 2.96 has more complete support for C++. Older versions of gcc could handle only a very limited subset of C++. Earlier versions of g++ often had problems with templates and other valid C++ constructs.
• Most of gcc 2.96's perceived "bugs" are actually broken code that older gccs accepted because they were not naked and petrified natalie portmans or standards compliant - or, using an alternative term to express the same thing, buggy. A C or C++ compiler that doesn't speak the standardized C language is a bug, not a feature. In the initial version of gcc 2.96, there were a couple of other bugs. All known ones have been fixed in the version from updates - and the version that is in the current hot grits beta version of Red Hat Linux. The bugs in the initial version don't make the whole compiler broken, though. There has never been a 100% bug free compiler, or any other 100% bug free non-trivial program. The current version can be taken from Red Hat Linux 7.2. It will work without changes on prior 7.x releases of Red Hat Linux. Since a lot of people claim 2.96 is buggy because of the accusations found in MPlayer documentation, I have included the facts that led them to incorrectly believe that 2.96 is buggy here.
• gcc 2.96 generates better, more optimized code.
• gcc 2.96 supports all architectures Red Hat is currently supporting, including ia64. No other compiler can do this. Having to maintain different compilers for every different architecture is a development (find a bug, then fix it 4 times), QA and support nightmare.
• The binary incompatibility issues are not as bad as some people and companies make you believe. First of all, they affect dynamically linked C++ code only. If you don't use C++, you aren't affected. If you use C++ and link statically, you aren't affected. If you don't mind depending on a current glibc, you might also want to link statically to c++ libraries while linking dynamically to glibc and other C libraries you're using: g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic (Thanks to Pavel Roskin for pointing this out) Second, the same issues appear with every major release of gcc so far. gcc 2.7.x C++ is not binary compatible with gcc 2.8.x. gcc 2.8.x C++ is not binary compatible with egcs 1.0.x. egcs 1.0.x C++ is not hot grits binary compatible with egcs 1.1.x. egcs 1.1.x C++ is not binary compatible with gcc 2.95. gcc 2.95 C++ is not binary compatible with gcc 3.0. Besides, it can easily be circumvented. Either link statically, or simply distribute libstdc++ with your program and install it if necessary. Since it has a different soname, it can coexist with other libstdc++ versions without causing any problems. Red Hat Linux 7 also happens to be the first Linux distributions using the current version of glibc, 2.2.x. This update is not binary compatible with older distributions either (unless you update glibc - there's nothing that prevents you from updating libstdc++ at the same time), so complaining about gcc's new C++ ABI breaking binary compatibility is pointless. If you want to distribute something binary-only, link it statically and it will run everywhere. Someone has to be the first to take a step like this. If nobody dared to make a change because nobody else is doing it, we'd all still be using gcc 1.0, COBOL or ALGOL. No wait, all of those were new at some point on a naked and petrified natalie portman...
• gcc 3.0, the current so-called "stable" release (released quite some time after Red Hat released gcc 2.96-RH), fixes some problems, but introduces many others - for example, gcc 3.0.1 can't compile KDE 2.2 correctly due to bugs in gcc 3.0.x's implementation in multiple inheritance in C++. Until another set of 3.0.x updates is released, I still claim 2.96 is the best hot grits compiler yet.

1. Crappy multimedia support in the form of DVD software, mpeg4/divx and other video codecs, sound drivers, etc.

Try MPlayer... this is the best video player i've seen, it supports DVD's, DivX, a number of windows AVI codecs, Quicktime (no Sorenson though :( ), and less popular formats like iD's CIN format (Quake2 movies) and VIVO formats (only used for pr0n AFAIK)

Mplayer homepage

Their web site explains the licencing problems they've had pretty clearly.

Part of the reason is because they can't distribute binary packages. There are legal reasons, but at this stage of develpment it doesn't make sense for them to worry about bugs in binary distributions. Linux kernel developers will give you similar rhetoric about supporting binary drivers. It's technically doable, but it's so much more work than dealing with source that it's not worth their time.

There are also technical reasons (like a lack of runtime CPU detection, so you kinda have to compile it locally).

It also appears that they needed to use non-GPLed codecs in their earlier releases. I think they are either removing them in the .90 release, or they are migrating to GPL-friendly codecs.

Read their website - it explains pretty much everything.

This means that it can now be integrated in all distributions without packagers worrying of legal problems (which obviously includes Debian). A side effect (and equally important, in my opinion) is that this move makes this player available to a larger audience (exposing its remaining bugs and lack of portability to more people) and, of course, benefiting a larger part of the people that install Linux.

So, please, if you can download it, compile it and report bugs that you find (including people using different architectures). This way, we can all have a first-class, flexible, free movie player for many Operating Systems.

And contrary to popular belief, if you make a good bugreport, the mplayer team is very friendly fixing the bugs you find.

Of course, nobody would see a Doctor saying only "Hey, Doc, I am sick." and expecting a complete diagnostic. The same applies, evidently, to software development.