Brian J. Murrell (v4l@xxxxxxxxxxxxxxx): > > Most linux developers care about: > > - Recording TV as a progressive stream at low resolution > > I think I know what progressive means in terms of video, but I think > what I am missing is how can I get a progressive capture from an > analog device that is receiving interlaced fields? Maybe I can't and > a progressive capture is only meant to work from digital devices. I mean that you record at like 352x240 so that you don't get interlaced frames, or you record to MPEG1 which is a progressive format (you can't record interlaced frames without colour bleeding between them) and so it's been deinterlaced. My point was that I don't think any of the recorders out there are tuned to recording interlaced streams to an interlaced format (like MPEG2 in interlaced mode). For example, notice how the chroma from the bttv driver at bigger-than-single-field resolution in 4:2:0 mode is in the wrong format for MPEG2's interlaced mode. In order to record TV for compression to interlaced MPEG2, I need to grab frames in 4:2:2 mode and downsample the chroma myself. My test recorder app is the first I've seen to do this, which tells me that either a) nobody else knows (but I did post on this list about this problem), or b) nobody else cares about recording interlaced streams from V4L sources (yet). > > - Watching TV in a window at frame-rate not field-rate > > Not terribly interested in watching in a window myself. I want to > watch on my TV plugged into my G400. Well the drivers aren't good enough to allow you to watch interlaced video on the G400 TV output. > > Some Linux developers care about these 'high quality' things: > > - timecode [1] > > What is this? Timecode is a standard for noting the time of each frame. You can use it to sync streams and stuff. You can find timecode in the VBI of some video streams. It can also be helpful for inverse telecine. > > - 59.94/50hz TV watching [2] > > So you play each field, one after the other scaled x2 to fill a normal > frame's height? I tried tvtime but it was very juddery for me. The > processor usage for it is: > > 2797 root 20 0 66352 20M 7464 R 74.8 5.3 1:15 X > 3419 root 11 0 8252 8252 8000 S 13.4 2.1 0:01 tvtime > > Does it use Xv for scaling? My monitor's refresh is set to 75Hz. > Could that be why it's so juddery? Yes, I use Xv for scaling. But I'm sending 720x480 @ 59.94fps @ 16bpp (that's 4:2:2, so the same colour quality as a TV natively). That's alot of data, much more than twice the bandwidth of a DVD. It will be juddery if your monitor is at 75hz since the framerates are so close, it will also be juddery because it's alot of data and the path for those memcpys isn't so optimized. Very few of the Xv drivers use DMA to transfer frames into video memory, and there's little demand since I seem to be the only app to be sending this much data. The judder problem is something else that needs to be fixed. For playback of 59.94fps video without judder I need to basically software-genlock the monitor to either 59.94hz or 119.88hz and then make sure each frame I send is displayed for exactly the right amount of time. I have it working here but I had to hack a bunch of stuff, and I haven't had time to get it working 'well'. Things are moving forward, but slowly since I don't have much time myself. It would be nice if more people were interested in stuff like this, but I find it hard to convince people that these problems need to be solved. > > - full-height/rate recording from consumer cards such as bt878 [3] > > I record at 640x480 with mp1e. Strangely enough I never see interlace > artifacts but I think I should. Well I thought mp1e only records MPEG1. Maybe it's deinterlacing. Also 640x480 I wouldn't consider full resolution, it would be nice to get at least 720x480, and maybe even 720x486. > > - inversing telecine [4] > > Don't need it (I don't think). My interest is recording from NTSC > sources (like cable, or satellite, etc.) Sure you need it. You want it if you're recording anything from film source to convert it from 59.94fps to 23.976fps. It makes watching films much smoother and MUCH better quality, and you get better colour and better compression! It's not much use if you're recording 'Friends', but lots of use if you're recording documentaries shot on film, or old movies on TV, or watching a VHS/laserdisc of a movie. > > - field correct TV output [6] > > Do you mean actually interlacing out to the TV the way it comes across > the air/cable? I have always thought the best way to get the same > quality picture (smoothness-wise) you get from cable/air is to exactly > record what you are getting and play it back as it was played > originally, to interlaced devices. None of this field combining etc. You need to record it as an interlaced stream and remember the field dominance (are your recorded frames top-field-first or bottom-field-first). Then, when you output to your G400, you need to make sure it plays the fields back in the right order. The point is you need a better API than just running mplayer on the second CRT which happens to point at your G400. The V4L2 API might be good enough, but nothing supports it yet. Also, AFAIK when mplayer (or whatever) talks to your CRT2, it's sending RGB. Ideally you'd want to talk directly to the TV encoder and feed it the raw Y'CbCr data etc.. All of this means better drivers than the current set. I keep meaning to do it, but I've been busy with school. But now that I'm almost done, I'm considering buying a more modern video card and getting it to work instead... -- Billy Biggs vektor@xxxxxxxxxxxx
