Matt G. (matt_g_@xxxxxxxxxxx): > > Even if manufacturers provided this information, what linux > > developer could a) afford the cards, or b) have equipment to [...] > > 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. That would be cool, I guess, but I would be scared you would be the only user. > > 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. Ok so this is just for recording. Well, in my recorder, I keep track of timestamps on every audio frame and video frame. Then after recording is done, I construct a list of the differences between the two streams, and estimate the slope of the difference line, and use that to tell how 'off' the two cards are. I'd like to try and fix that to work on like 15min sections independently to get the accuracy better, but the problem is a bit annoying, since for example I'm relying on the kernel to wake me up quickly on the audio/video interrupts, and so there is some possibility for annoying error there too. All of the recording apps seem to have some support for watching for clock drift between A/V, but I don't know how far along these projects are. I like my approach, of course, but I haven't really had time to finish yet. I'm not sure how things work with capture cards that have audio recording on-board. > > recording. Most PVR efforts etc focus on recording every second > > field at low resolution, like 253x240@xxxxxxxxx > > That's a real shame. A high-quality PVR, with footage I can dump to > DVD, is one of my long-term goals. Well me too, so that's at least two of us. You should help with my app. > [...] I don't know how Linux might fit into that, but the more > professional uses and applicability it has, the better. You seem to want to generate "professional quality" uses more than writing code that linux users might use. I think that's fine if you're the only one writing the code, but I doubt you'll find many users or developers to help you. :) But that's just IMHO... > 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. Most recording software does any compression in software, the cards provide uncompressed frames (I speak here about any BT878-based cards). The exception is the code in mjpeg.sf.net which works with a few MJPEG capture boards. > 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 can speak for nobody but myself, so I'll of course recommend you help me with my apps (www.sf.net/projects/reetpvr/ in particular). I'll also point at projects I like, you should check out gstreamer.sf.net, matterial.sf.net, nvrec, ... -- Billy Biggs vektor@xxxxxxxxxxxx
