[Xpert]Re: XVideo and vsync
On Fri, 21 Sep 2001 23:28:50 +0200, Peter Surda wrote: I vaguely remember that for mga you can use /dev/mga_vid. I think there is a generic interface somewhere in X but don't know where. The /dev/mga_vid is a specific device that belongs to a kernel driver which you can use to directly access any matrox card. That driver is *not* in the official kernel tree but you can get it somewhere from the net. Yet as far as I know it is quite outdated. There is a project which is called TELETUX and hosted at sourceforge (teletux.sf.net) that provides all necessary functionality (including vsync). The only problem is that if you use it you by-pass XFree entirely and every window that's in the area of the overlay won't show up because it is overwritten in the video ram. So it is not very useful for what I wanted to do. :-( What card do you have? Matrax G400 MAX (and quite happy with the DH stuff *grin*) gpg --send-key [EMAIL PROTECTED] --keyserver certserver.pgp.com or better yet, define a keyserver in ~/.gnupg/options, then gpg will download automagically any keys if necessary, works well under mutt too. Thanks for the hint but I have a key server specified. (wwwkeys.nl.pgp.net) And mutt is set up properly. *grin* Back to the original topic again. :) As Mark Vojkovich kindly pointed out, X does not provide any way to check the vsync pulse. :( Just a few dri drivers implement that functionality for OpenGL usage - but really, only a few. What brings me to my question: if it is indeed possible for the dri people to implement that feature why can't we put it in the XVideo protocol too? As I understand it, direct access to the video card is necessary as well as its interrupt. The dri drivers run in kernel space and do have access to those kind of informations. Now maybe, just maybe, couldn't we implement some sort of feedback from the dri drivers to the XVideo protocol which is only used if dri is present and that information available? I am not an expert on this but I think this would indeed be possible, wouldn't it? I consider video output sync with the vsync pulse as quite important, especially if you wanna watch high-quality video material on your home computer. :( Just my two cents naturally. :-) -- So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: XVideo and vsync
On Sun, 23 Sep 2001 16:10:50 +0200, Peter Surda wrote: As he also pointed out that hardware automatically does this. That depends on the hardware - matrox cards unfortunately don't do this automatically. And I guess if it did, some people would complain about it because they want the best possible frame rate. :( At least ATI seems to do it when using monitor (but it fsckes up when I use tvout). Anyway, I tried getting it working on my ATI with tvout, and I found a register in the docs that signals retrace status, however it still doesn't mix. Maybe I am wrong but I don't think your TV out does need to synch with your TV - and I don't know if this is possible at all. As far as I understand it those tearing artifacts are caused by different frequencies (your video material is 29.xx fps but your monitor for example runs at 68 Hz) and the different formats (your monitor is usually a progressive display while your TV is a interlaced display - I hope I am not making a fool out of myself and those things I just said were right!). So your TV out should now deliver the frames in the right frequency (50Hz for example) and in the right format (interlaced). That should be it. So IMHO your are looking at the wrong thing to find the cause for your problem... I suggest you do what I did: Thanks for that! :) Yet I think this could cause a bit of trouble. If your system is under heavy load, you could easily miss the right time. So the function that is responsible for drawing the image waits even longer. On the other hand it's a step in the right direction (a quick workaround). :-) Now what confuses me is that I thought it isn't possible to get the retrace information in user space - just in kernel space. I guess this is only true if you want to make use of the hardware interrupt that is being issued (and naturally that would be the best solution IMHO). But I still think there should be an official way (through the kernel space drm drivers for example) to get that information and handle it in the right functions (for example XvPutImage) by implementing an optional double buffering that is only used if a) retrace information is available and b) if the programmer explicitly asked for the feature. If you are interested on high-quality video watching on mga, you can join the avifile mailing list or perhaps even directly ask Zdenek Kabelac or A'rpi. Thanks for the hint. I have tried avifile some time ago and was pretty pleased with it. But now XINE has become my player of choice where I'm also trying to contribute a bit. :) Last but not least. Could you please cc your answers to my mail address because I am not subscribed to the Xpert list - just using the archives. :-( -- So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: XVideo and vsync
On Sun, Sep 23, 2001 at 04:52:24PM +0200, Matthias Dahl wrote: As he also pointed out that hardware automatically does this. That depends on the hardware - matrox cards unfortunately don't do this automatically. And I guess if it did, some people would complain about it because they want the best possible frame rate. :( Well, you can't get higher frame rate than your monitor can go can you? Unless your brain is plugged directly to the videoram :-) Maybe I am wrong but I don't think your TV out does need to synch with your TV - and I don't know if this is possible at all. Actually I don't know that much about TV either. But TV is similar to monitor in that both are CRT-based. So the signal is generated the same way and indeed you should need to sync drawing. As far as I understand it those tearing artifacts are caused by different frequencies (your video material is 29.xx fps but your monitor for example runs at 68 Hz) I don't think so. and the different formats (your monitor is usually a progressive display while your TV is a interlaced display My current theory is indeed that this is something with interlacing. I believe that my routine simply waits for A retrace, and not a FIRST retrace of the two, hence the 2 pictures sometimes overlap. - I hope I am not making a fool out of myself and those things I just said were right!). I believe you are partially right. So your TV out should now deliver the frames in the right frequency (50Hz for example) and in the right format (interlaced). That should be it. So IMHO your are looking at the wrong thing to find the cause for your problem... I still think that the problem is caused by retraces not being synced to data transfer. It doesn't matter that the frequency is lower or it is interlaced, you can't expect the picture to look ok if you transfer data to videoram while the ray is drawing. Yet I think this could cause a bit of trouble. If your system is under heavy load, you could easily miss the right time. Well, that's why we have patches for preemptive kernel and low latency. Unforutnately the preemptive patch causes crashes and segfaults pretty often, so I'm sticking to lowlat. For more than 75Hz I don't think you'll notice a difference whether a picture is displayed on 2 or 3 frames. Otherwise the latency would have to be bigger than about 1000/75/2 = 6ms and I don't think that happens even if load is high, unless you are too low on memory and in that case disturbances are expected to occur anyway. So the function that is responsible for drawing the image waits even longer. It doesn't matter, it still looks better than 2 pictures mixed together. On the other hand it's a step in the right direction (a quick workaround). :-) Sure. Now what confuses me is that I thought it isn't possible to get the retrace information in user space - just in kernel space. I guess this is only true if you want to make use of the hardware interrupt that is being issued (and naturally that would be the best solution IMHO). I think you're right on this. But I still think there should be an official way (through the kernel space drm drivers for example) to get that information and handle it in the right functions (for example XvPutImage) by implementing an optional double buffering that is only used if a) retrace information is available and b) if the programmer explicitly asked for the feature. Hmm mga has some buffering stuff like this in hardware I've heard. Thanks for the hint. I have tried avifile some time ago and was pretty pleased with it. But now XINE has become my player of choice where I'm also trying to contribute a bit. :) I find xine cubersome to use, in fact I was unable to actually get it working :-) Of course everyone will claim their player is the best g. Last but not least. Could you please cc your answers to my mail address because I am not subscribed to the Xpert list - just using the archives. :-( k So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ Bye, Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- Secret hacker rule #11: hackers read manuals. PGP signature
[Xpert]Re: XVideo and vsync
On Sun, 23 Sep 2001 14:59:14 -0400, didier wrote: No MGA can do that without polling, If you only want to wait the next vsync. Interesting. Without waiting for a hardware IRQ or anything like that? I just mailed a patch at [EMAIL PROTECTED] If you don't mind and if it's not too much trouble, maybe you could send me the patch also? I'd be very interested in it! If you want a particular vsync then I'm not sure Xv is the right API, at least on an unix like OS. What do you mean with a particular vsync? You mean a special position at the screen? -- So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: XVideo and vsync
On Sun, Sep 23, 2001 at 05:38:52PM +0200, Peter Surda wrote: Well, you can't get higher frame rate than your monitor can go can you? Unless your brain is plugged directly to the videoram :-) Um, pluging myself directly to the video ram... hey... good idea. :-))) So the signal is generated the same way and indeed you should need to sync drawing. But you shouldn't forget that one is progressive and other one is interlaced. And I guess the TV does all the synching itself - it's its job and not that of your graphic card - IMHO. I don't think so. Well... I guess you would run into trouble of you are trying to display your video material at 67 Hz on your 50 Hz TV... so frequency is indeed an important factor. ;-) I believe that my routine simply waits for A retrace Does your ATI card provide two independend register of retrace? (one for that of your monitor and one for your TV out) I believe you are partially right. So I am a partial fool... ok... that's ok. :-)) For more than 75Hz I don't think you'll notice a difference whether a picture is displayed on 2 or 3 frames. Ok, admitted. :) Hmm mga has some buffering stuff like this in hardware I've heard. I'm not sure about this - but I guess so. I find xine cubersome to use, in fact I was unable to actually get it working :-) Of course everyone will claim their player is the best g. You are absolutely right. :) Yet you should give a recent XINE version a chance to proof itself... maybe you will be surprised. :-) -- So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: XVideo and vsync
On Sun, Sep 23, 2001 at 07:26:47PM +0200, Matthias Dahl wrote: So the signal is generated the same way and indeed you should need to sync drawing. But you shouldn't forget that one is progressive and other one is interlaced. yes there are 2 of them. And I guess the TV does all the synching itself - it's its job and not that of your graphic card - IMHO. No, the card tells the monitor or tv stuff like start drawing NOW retrace there draw again retrace back TV or monitor are pretty stupid, the card must tell them everything. Well... I guess you would run into trouble of you are trying to display your video material at 67 Hz on your 50 Hz TV... so frequency is indeed an important factor. ;-) Yeah sure then some are missed, but still this has nothing to do with the topic: retrace sync must be done anyway. I believe that my routine simply waits for A retrace Does your ATI card provide two independend register of retrace? (one for that of your monitor and one for your TV out) No, but you can apparently choose which one will be taken into account. I hope the last sentence didn't reveal any confidential information about ATI g But I was able to find a register that tells you if it's odd or even frame and I adapted the Xv function to take it into account. However I'm unable to see whether it helped. If someone on the list knows a video that is freely available and good for determining whether syncing to retrace works, I'd be very pleased if he/she sent me the URL. I find xine cubersome to use, in fact I was unable to actually get it working :-) Of course everyone will claim their player is the best g. You are absolutely right. :) Yet you should give a recent XINE version a chance to proof itself... maybe you will be surprised. :-) Well I didn't mean that it doesn't compile, on the contrary, it compiled without hitch, I was just unable to do anything useful (like playing videos) with it :-) So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([ Bye, Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- /* vsprintf.c -- Lars Wirzenius Linus Torvalds. */ /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */ PGP signature
Re: [Xpert]Re: XVideo and vsync
On Sun, 23 Sep 2001, Matthias Dahl wrote: Now what confuses me is that I thought it isn't possible to get the retrace information in user space - just in kernel space. I guess this is only true if you want to make use of the hardware interrupt that is being issued (and naturally that would be the best solution IMHO). You can do it from user space by polling, which isn't a solution because you can easily eat up all your CPU. Most hardware double buffer their registers and the updates only go into effect at the retrace. At least Intel, NVIDIA and ATI do that. You only have to stall when you get ahead. For frame rates lower than the refresh rate you'll never get stuck polling. But I still think there should be an official way (through the kernel space drm drivers for example) to get that information and handle it in the right functions (for example XvPutImage) by implementing an optional double buffering that is only used if a) retrace information is available and b) if the programmer explicitly asked for the feature. NVIDIA's drivers (both nv and nvidia) sync to the retrace by default for Xv(Shm)PutImage. It can be turned off with the XV_DOUBLE_BUFFER port attribute. I chose not to stall when clients send data quicker than the retrace but stop worrying about syncing instead. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
