On Sun, Apr 14, 2002 at 03:04:15AM -0500, Billy Biggs wrote: > > Well sure but my dxr2 hardware decoder can play to a TV at 59.94 from > a DVD and it works well. In movietime I intend to get software DVD > playback to 59.94 working also. If you go pick up a dxr3 it can > probably do it too. So why dick around with software and G400's and Radeons if a dxr[2|2] does the job well? Or am I mis-understanding just how well the dxrs do/don't work? MPEG2 only I guess. > Well of course. There are lots of deinterlacing filters you can apply > to make the output suck less. I kinda liked the ffmpeg filter, vertical > with kernel [-1 4 2 4 -1], although I know there are probably better > ones that are just as cheap. Still, I think it would be just as > expensive to not do any deinterlacing and record interlaced frames to > MPEG2. Interesting idea. I don't think there are any realtime mpeg2 encoders yet though. > It would be neat to turn mp1e into an MPEG2 recorder, I think. :-) > Then you could play back to a dxr3 card and maybe get smooth 59.94 > playback for free. ~drool~ :-) > Blah, or we can just get that hauppauge pvr thing working and it will > probably do the right thing too. Wouldn't that be nice. It is too bad to hear that the work that was being done on it got back-burnered. > I mean a frame that contains two fields. OK. The idea being that the video card extracts the fields from the frames and displays them, one after the other @59.94. I get ya. > Uh, well you'd still have to say 'here is a top field', and 'here is a > bottom field'. Regardless you can't use the API we have right now, > which is 'draw RGB to an fbcon device and it will appear on your TV'. Right. > Well still if you're sending buffers too fast you'll need to be > blocked Right, but if you are blocked, hopefully you have done everything you need to do until you can get a frame into the video card. > and if you're sending them too slow you'll get underruns. So we > need some sort of API that exports that. I guess it would be nice to know (asynch. again) when you can push another frame to the card, but like I said above, hopefully when you block, you are all done until you can get rid of the frame anyway. I supoose there is always frames to be decoded though, amortizing CPU across a bunch of frames, so maybe you are never really done. MPlayer uses this buffering mode of the G400. Maybe something can be learned there. > Yeah but then I'd need to tell it to subpixelly move the destination > accordingly. I had some discussions with Matt Sottek and Mark Vojkovich > on the Xpert list about this and we sort of came up with an API to do > this with XVideo, but neither Matt nor I have had time to implement it > on the X side, and nobody else seems interested in doing it. Nobody's got an itch yet. > I mean sure, there are some people who want to get this done, just not > enough with free time to get it done too quickly. :) Or skills I am sure too. > I think the real problem is that the API MPlayer is using to talk to > the G400 TV out is just broken. Is it still using an fbcon context? I would guess. I mean nothing has changed with it (that I know of) in a while so if that's what they were doing, that is what they are still doing. > You should be able to use the G400 TV out as if it were an overlay > device, give it a 720x480 Y'CbCr frame I will have to do some reading about this video stuff. I am not really sure what Y'CbCr means although I think it has to do with the luma/chroma etc. of the picture. > and have it output that to the TV > encoder directly. We need to get rid of these hacks and do it properly. :-) > I think like this: > VCR: Record to like 40GB/hour, take 3 days postprocessing, get out a > high quality DVD. For a television program, like Friends (to use your previous example)? > PVR: Record directly to storage format, let me pause during programs > and stuff, Pausing during programs is just a by-product of watching as you record. You know, it's more a "way of thinking thing" to me. I am still trying to teach my girlfriend to get out of the "what time is it on" mode of thinking; to just forget when anything is scheduled and to learn to just sit down and watch what you want from the list of available programs (well when the GUI is done anyway :-). If she happens to do that at 8:02pm on Thursday evening, one of her choices will be Survivor, but that should just be a coincidence. > time-shifting, etc. No postprocessing of video > (already gone to a lossy format). OK, I think I see. VCR to you is high quality processing for archival. To me PVR is Super-VCR, and what you call VCR, I would probably call Video Edit/Archive. > Awesome. :) See ya there! :-) > I currently do 3:2 pulldown inversion in realtime on DVD content, so > that works well. You can do a better job offline (see the phase > detection code I have in reetpvr), but it's easy enough to do in > realtime that it's worth it. dscaler does it. I suppose I thought the idea of having to know when to do it and when not was more cumbersome that the doing it. Maybe it's not as difficult as I am thinking it is. > The code isn't so bad, but I don't like some of their algorithms. :) > There have been some ports though, some of their filters were modified > and put in xine for example. Cool. > Yeah well they pretty much all can, it's just a matter of putting them > in the right mode and knowing what they expect. Right, but by access I guess I also meant documentation on how to do it. ATI, for example, won't tell anyone how to enable TV-Out on Radeons. Gatos seem to have figured it out as they have some amount of TV-Out support for some Radeons. > I'm pretty much convinced that with sufficient hacking you could do a > V4L2 TV-Output API for all the consumer cards with TV output that would > be good enough for what we've been discussing. That would be so cool. I would love to see broadcast quality playback of TV on Linux. b. -- Brian J. Murrell
Attachment:
pgpC1ugw7qam8.pgp
Description: PGP signature
