Slashdot Mirror
Linux Media Arts Advances Video in Linux
GigsVT writes "Linux Media Arts has introduced a line of video capture and hardware MPEG encoding cards with full Linux support. The sd601 is a full featured hardware video solution including hardware dissolve, key, wipe, and split screen.
At pricetags around $3000 US, they aren't cheap, but this could break Linux into the video editing market. This isn't vaporware, they are selling these right now."
An Amiga with a Video Toaster 2.0 and a time base corrector can be had for around $1200, and with any of the seven mainstream Linux desktop video packages, it can be slaved as a second system, so you control it from a cheap, fast PC running Linux, with the Amiga doing the majority of the hard work.
Video Toaster users are the few sane remaining Amiga fanatics. Most television shows and minor Hollywood production companies still use Video Toaster for the few things you still can't do in Adobe Premier and After Effects.
I already own video capture cards that run under Linux, but what about other imaging products? I was doing some work at a dental office the other day, and they were using specialized video capture equipment for their X-ray machines (running on Windows 98 PCs... blech!). Based on the Windows driver name (bt848.sys), I'm sure it uses a standard video capture chipset used in many TV tuner cards, but these cards *definitely* didn't have Linux drivers.
I thought they already did? Some Linux Journal article about Broadcast 2000 and aA list of supported video capture cards for Linux
Sure the hardware isn't quite Linux supported yet, but at least there are some lower-end cards out there that are supported. So it looks like for the home user the hardware and software is somewhat there. And what about for high-end? Well supposedly Linux is already being used for editing movies (including LOTR). I'm not sure how they get their video onto the computers though, but there must be some way to do it I guess.
So I guess this hardware is special because it is specifically targetted at Linux, but as far as breaking Linux into the video editing market...I think that already happened a little bit so far. And it's not going to get any better with a $3000 USD card.
Broadcast 2000, "the software the competition fears", is the revolutionary Open Source Linux software package created by Heroine Warrior (and now being carried on in development and service by LMA)...
So why can't I find the source or binaries on their website?
--LP, who just wanted to check what parts were truly free
There does appear to be a Sourceforge-related project. The discussions forums have some pointers to non-US (not DMCA affected?) mirrors of the code.
--LP
Wasn't shrek made on linux running Maya? Linux already is in the movie business! (It's called...research)
I'd like to shout out to my Windows XP box: as of now it has an uptime of 2 days 6 hrs 39 min and 55 seconds. A new record for Windows!! Yay!
Apart from running on Linux, how is this $3000 solution better?
The card is a professional solution for the professional broadcast market, for what it does $3000 is actually pretty resonable.
This product takes SDI (Serial Digial Interface) for video input which is the standard to broadcast video, it runs at 270Mbs and is not found on anything but professional (or at best "prosumer") gear.
This is not the first pro card that does SDI under Linux either, IIRC Optibase have a Mediapump card that does SDI under *nix.
Australian? Join EFA
A wipe is a way of 'cutting' between two shots. The existing shot is wiped away and replaced by the new shot. It's used a lot in Star Wars. A star wipe is a wipe in a star shape. Usually starting in the middle of the existing shot. Inside the star is the new shot. The star expands outwards until the new shot replaces the existing shot. Quite common in late 70's-early 80's music videos.
Blog
http://www.metzlerbros.org/bttv.html
With the right insmod args you can get pretty much any bt8x8 based card working under linux.
NewTek is still producing the Video Toaster, and it's very much in use. I work for Fox, and we've purchased over eighty units this year alone. There's nothing like it for the price, and even high end motion paintboxes lack some of its more basic features.
Do you really think there would be so many desktop video packages with Video Toaster slave support if it were that dated? Hell, half of Maya's rendering target options have to do with extra key modes and depth buffer information for Video Toaster use.
And yes, the 68030 blows Athlons and Xeons out of the water when it comes to SIMD bandwidth, because it can deal with different cache modulos. The straight set-associative cache of the Intel and Athlon architectures kills them when it comes to dealing with full-frame video effect processing, and half the vector opcodes aren't even there, except in the newer, upcoming AMD Hammer architecture.
Linux Media Labs is another group that is providing video hardware that runs under Linux. I have seen motion JPEG work very successfully in a research environment (Internet2) and I know that the test machines are being deployed. You can find out more about the test machines that I am talking about via
Google.
This is a far cry from BTTV cards. I should have said "high end video market, on the x86 platform". That would have been more accurate.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
You really don't know anything about video, do you?? this is PRO equipment, not something which gives you a compress video (a.k.a MPEG, MPEG-2, etc)...
Hetz (Heunique)
Yeah, I've tried FFMpeg too.
Do you think this even compares to a $3k hardware encoder? A real-time software encoder is cutting corners everywhere: integer math (probably in the form of MMX), fixed "one size fits all" lookup tables, and little if any motion detection. You know, it's easy to make a real-time MPEG encoder if you only use I frames, but then you basically have motion-JPEG. The real compression payoff in MPEG comes from motion detection with P (predicted) and B (bi-directional predicted) frames. Simply put, the real-time software encoders will produce crap output. That may be acceptable for your PVR-knockoff (I know, I've been using VCR with DiVX under Linux for abouta year now), but it isn't for DVD production. And that's what this card is for.
I'm not sure how many video professionals would actuall trade their current desktop video production environment for a linux-based one, but this kind of hardware may be very useful for unattended video work - you know, the box that is sitting there in the rack and encoding, decoding, switching, inserting, etc.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
IIRC DBeta is DCT based but not MPEG2. ATSC transmission is MPEG2, as is BetacamSX and IMX.
Calum
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
As I seem to recall, the majority of final formats in the digital realm are in MPEG-2, as that is what the current mastering/delivery solution is.
Yes... but you hit the nail on the head when you said "final format." Although some outlets choose to encode manually before broadcasting, most outlets encode right before the signal go to the transmitter as part of an unattended real-time process. For all intents and purposes, the transmitter or uplink or distribution-system-you-like takes uncompressed SDI or HD-SDI as its input.
Digital Betacam and DVD both use MPEG-2
Bzzt. Digital Betacam (HDCAM too, for that matter) uses a proprietary DCT-based compression algorithm that usually results in around 2:1 compression for SD, 10:1 for HD. D-5 is purely uncompressed, and a lot of post houses use D-5 instead of D-Beta. In the HD world, the D-6 is purely uncompressed. It's a monster VTR, though.
With HDTV coming up in the future, how are editors/equipment suppose to deal with uncompressed data streams of frames larger than current NTSC/PAL frame sizes? Even with fast enough computers, achieving those disk writing speeds to capture the video realtime to a system uncompressed would literally flood almost any physical storage bus solution.
Oh, you'd be surprised. First of all, we've been doing HD nonlinear for over three years now, using Fire on an Onyx2. It's getting to the point where you can do some HD work on a PC or Mac, although no editor who's ever worked on a Fire will ever go back to the desktop. You get spoiled by all the real-time stuff.
Handling the basic data I/O isn't hard. Say you work in 8-bit YUV, 4:2:2. You can pack an entire pixel into two bytes (eight bits for luminance, and four bits each for the two color samples). That's 4,147,200 bytes per frame at 1920x1080 (make it simple; don't count the vertical interval). At thirty frames per second, that's about 120 MB per second. Two fibre channel loops (or one 2 Gb loop) with about eight disks can accomplish that. HDTV at 1080 lines isn't delivered as frames, of course, but as fields. This has no relevance on the storage of data on the disk, because the math works out the same either way.
RGB is more complex, though. Discreet uses RGB internally because all the SGI media libraries deal with it best. So you need three bytes for each pixel, making your data rate one-third more. That's a bit over 180 MB/s, which is still easily doable with commodity hardware.
(The software is tricker. I leave constructing a filesystem that is capable of real-time random-access playback and recording of multi-resolution data to be an exercise for the reader. It's much, much harder than you think. You can get around it, though, by buffering like crazy and using lots of disks.)
But, of course, if you're editing you have to be able to play back two streams of video at the same time. (Think real-time dissolve.) Double that. For RGB, that's about 360 MB/s of raw disk bandwidth required. Even with overhead, that's still within what one 64-bit, 66 MHz PCI bus can do.
Of course, once you get that data onto your disks, you still have to be able to read it and pump it to the video card in real time. If you wanna do anything to it on the way-- like apply a color correction, for instance-- you have to pass it through the CPU. It's easier to do that sort of thing on an SGI than on a PC, because the graphics hardware on an SGI can do lots of stuff in real time without having to bog down the CPUs.
Long story short, you can do HD on a PC or a Mac. If you've never done any high-end work, it's pretty amazing. On the other hand, if you have worked on a Fire or such, HDTV on the desktop sucks.
...and while we currently use SGI O2s for our live insertion systems (I work for Sportvision, the people whoe brought you the virtual yellow 1st down line in football, etc), we're moving to a intel platform.
Sgi is dying- They tried to make systems and their product revision cycles were just too slow for hardware consting tens of thousands of dollars... (not to mention that SGIs stuff is just dog slow for the $$) So... we're moving to the PC, hopefully Linux.
For our stuff, we've found that the DVS card (out of Germany) works best- It does 66 Mhz, 64 bit PCI, simultaneous in and out, has up to a second of delay onboard (user selectable), and it has colorspace conversion on board. We've paired this board with an intel i860 chipset since it is one of only two boards (the other is AMD supplied) that does 4bit/66Mhz PCI and 4X AGP.
The colorspace conversion is really the killer feature for us on teh DVS card (well, that and the fast PCI)- It saves us from having to do it on the CPU (which takes up a lot of processor at 270 or 540 Mbit/second!!).
Our biggest wish right now is for someone to make good GL drivers for linux (glReadPixels has to be fast so that we can rendered video and blit it out of the AGP card at framerate) Currently the only one we've found to work well is NVidia's proprietary drivers..)
We havn't tried the LMA card as my attempt to reach anyone over there was met with 4 consecutive seemingly intentional hangups.
I'd love to use the LMA card, but at $3000 it just doesn't have all the features the the DVS card does for the price- ($600 more in quantity, and DVS hasn't ever hung up on us..).
This is really bad news for SGI. I'd heard that DreamWorks was disatisfied with SGI, but they must be totally disillusioned to abandon SGI's famous massively parallel systems in favor of a Linux cluster! Makes you wonder who will buy the Itanium supercomputers SGI is betting its future on.