Gerd Knorr (kraxel@xxxxxxxxxxx): > > The bttv chip writes to memory fields at 59.94hz afaict, however > > xawtv cannot be convinced to display at this rate. > > Please don't confuse *frame* rate and *field* rate. The frame rate is > 30 fps only. But, you do understand that when watching TV, you don't see both fields at the same time. Each field is scaled up independently to the size of a frame. Ancient TVs don't interpolate and just rely on the phosphors. Modern TVs actually perform a digital interpolation of the missing scanlines. Regardless, while the input frame rate is 29.97fps, the displayed frame rate is always 59.94 fps. > > Using XVideo to control the overlay window, all I see is one of the > > fields. This seems confirmed in the code: > > > > height = pPPriv->enc[pPPriv->cenc].height/2; /* no interlace */ > > Exactly. I have a pending patch for v4l.c which makes this switchable > at runtime (both fields interlaced vs. one field scaled up). But both of these options are unacceptable. In each case you give up too much quality. A third option, scale both fields but to the same location, will have more flicker than optimal but will provide smooth motion with no CPU cost. > > and you don't overwrite the top field directly with the second one. > > Yes. Simply overwriting the top with the bottom field would give you > some anonnying flicker because the two fields don't line up exactly. > Older bttv versions (<= 0.7.20 or something like that ...) used to > work this way. Ok thank you, this explains why with older bttv versions I did get the full display framerate. > > I don't understand how you avoid sheering (I guess you don't?). > > By using one field only ... Well that doesn't explain it either. Since you're not double-buffering, the bttv could be DMA'ing a field right on top of the existing one. > > And I don't think the fix is obvious either. If we say screw > > sheering (or if there's some other reason why that is not an issue), > > you'd still need some interrupt from the video card to handle the > > field parity correctly, since you need to start the bottom field a > > scanline below where you start the top one. > > No, the bt848 has no problems to deal with different memory locations > for even/odd fields. Sure, but if you're scaling from a stream of 720x240 fields, you'd need to have every second field start a half-scanline below the first one, which you can't do with memory location tricks. Instead, you must talk to the video card each time to tell it to change the scale destination for each field. > > If I'm not using XVideo for scaling, just xawtv accessing > > video4linux directly, then I still don't get true 59.94hz: instead > > I see interlaced frames! > > What else do you expect? This is exactly how TV works. Without > Xvideo no upscaling using the graphics card is possible, so I can't > play tricks to avoid the interlace artefacts. No this isn't how a TV works. When watching my TV, I see the entire screen redrawn at a rate of 59.94hz. I've written an app to deinterlace to full-frame 59.94hz output. I'll post a version tonight. Motion is much smoother, and quality is similar to my TV. Sports broadcasts and smooth text crawls are now smooth, and antialiased text still looks reasonable. However this does eat alot more CPU than xawtv. -- Billy Biggs vektor@xxxxxxxxxxxx
