>From: Billy Biggs >Subject: Re: Studio-grade hardware support? >Date: Sat, 13 Apr 2002 19:14:49 -0500
I really appreciate the reply, BTW. > Hi Matt, > > To start, check out http://www.linuxmediaarts.com/ for a company >selling an SDI card that seems supported under linux, along with some >other 'high end' goodies. But the cost is prohibitively expensive to >end-users, since we're not the market. Yeah, I had run across them, but it's a bit outside of my budget. > Even if manufacturers provided this information, what linux developer >could a) afford the cards, or b) have equipment to use them? I know I'd I'd drop a grand on a used piece, like a digisuite card, if I had enough information to write a driver for it. I personally know the designer of all the Media100 hardware (I almost went to work there), so if I could score one of their cards, I should be able to get enough info to write a driver. > Well the V4L2 API (http://www.thedirks.org/v4l2/) is supposedly good > enough for what it wants to do: provide an API to consumer-level video >equipment. It has support for timecode, but I don't think anything >implements that (but you can read VBI data and correlate it with video >frames, and I wrote a timecode decoder for this API). The API has no >support for controlling genlocks, like if you wanted to genlock two Yeah, it worries me to see stuff that no one has tried to push into the studio. I know that a staff of over 100 hacked away on Avid's Media Composer, for about a decade, and there are just some issues you can't foresee until you stumble into them. But some of their effort is due to the code being un-modular and poor reuse. Then, consider what platform they developed it for (and what they ported it to). Also, you have the issue of "professional" software quality, to contend with, too. So, maybe it's not that hard. (I didn't work at Avid, but know several people who have.) > Audio sync is a bit funny, what hardware did you want to support? The >V4L2 API doesn't speak at all about audio, but I'm not sure what >hardware you'd be talking about here anyway. For field-correct output >sync is also a bit weird, but again nothing supports the TV output API, >so I think this is mostly untested. Well, I'm no expert, here, but it seems like you should at least know the latency of the audio and video capture cards. Then, you also want to be able to deal with drift, in case the two clocks aren't in synch. A co-worker who used to work in Media100's support department (I didn't work for them, either, BTW) once told me a story about the fact that they captured audio at the correct rate. The players of the time weren't written to account for the fact that video was 59.96 fps (or some such issue), and the video & audio would get badly out of synch, after a few minutes. They got continual tech support calls, until they finally decided to ship their own player that got it right. I guess, if V4L knows nothing about audio, that this must be solved by the existing apps, because it sounds like most users use a separate sound card that's not synched to the video, in any way. Do you know what they do to address this? Perhaps cross-fading, at every field boundary, to resynch with the latest samples from the sound card? If the two aren't genlocked, then you probably can't do anything much better, but I wonder if that could ever result in an audible 60 hz buzz. >recording. Most PVR efforts etc focus on recording every second field >at low resolution, like [EMAIL PROTECTED] That's a real shame. A high-quality PVR, with footage I can dump to DVD, is one of my long-term goals. > That doesn't mean we don't care about quality, but I don't see a big >push to get some of the more higher-end code done, even on our consumer >grade hardware. You might consider raising your standards, for hardware. The stuff is getting quite cheap (see my next post). > Since most developers aren't working on V4L professionally, I don't >see why we'd want to target the post/broadcast environments. Sure The more work it is, the more unlikely it'll happen. I hear things about big 3D houses using linux, and I wonder about video. But then, high-end 3D has been entrenched in UNIX for much of its history, whereas video was on proprietary systems, and first appeared on Macs, when it hit the desktop (Avid originally developed the Media Composer on an Apollo workstation. The story goes that Apple saw it at a convention, and their quicktime team showed up on Avid's doorstep, a week later). > > Note: I would be willing to contribute code & documentation to driver > > or API projects in line with the above goals. I have no (current) > > commercial interests in this, BTW. > > So you're a home user and you want to do what? Like you, I want a high-quality PVR, and I'm interested in video editing. There's some video restoration work I want to do (some of my friends are video collectors, and have irreplaceable content on VHS). I don't really need genlock or timecode, but I insist on quality. I also like hacking around with audio and video. I come from more of a compositing/effects/3D background (I suppose I can probably work on compositing & effects, since my non-compete agreement, from my previous job, has expired (and they're out of business, anyway)). I think I may like to do it full-time, again. I don't know how Linux might fit into that, but the more professional uses and applicability it has, the better. Linux has the potential to be rock-solid, and is very automation-friendly. I see no reason why it can't be the platform of choice, for large media outlets. Perhaps things are a bit closer in the audio world, where you actually have things like cutting-edge, surround-sound streaming demonstrations, at professional conferences, built on linux. Anyway, as I'm sure everyone knows, it already has lots of use for embedded video applications. Things should eventually reach a point where semiconductor vendors provide linux drivers with all their chips. Then, board vendors will have virtually no work, for their products to be supported under Linux. (hmm... I guess the MPAA will have to put a stop to that.) Well, thanks for taking these ideas seriously. Is there support for any uncompressed capture cards? Computers are getting fast enough (I hear intel already has a faster-than-realtime MPEG4 encoder) that it'd be nice to just capture uncompressed and do software encoding. IMO, hardware encoding is quickly becoming an anachronism. I don't have a whole lot of free time, but I am interested in contributing to making linux the video platform of choice. Are there any lists of ways to get involved in V4L development? I should note that I recently deployed XML DocBook, at my job (including some scripts to automatically generate parts of our reference manuals from comments extracted from source code), so I could help with coding as well as documentation infrastructure. If there aren't any uncompressed cards supported, I'd like to start there, since it's closest to my immediate needs. (I refuse to do anything that requires me to boot windows. Anything worth doing, including video capture, editing, processing, and output, shouldn't require it. :-) Matt _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Video4linux-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/video4linux-list
