Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: Scaling interlaced material vertically is supported by at least overlay video on i9xx chips. Hmm. Can't check at the moment (will do later) but I think I had problems with _unscaled_ overlay (i.e. the VGA output set to 720x576x50i, pixel clock 13.5 MHz). It looked like the chip was performing some filtering. I was obviously unable to xwd-check the resulting RGB image but it was certainly lower res. right, when playing non-live data VGA output timing needs not to be synced to an external signal. But for live-TV it's crucial if you don't want to lose fields/frames. I wonder what is the difference between the on-air frame rate and your card's (fixed) one? 100 ppm would need one second of additional (initial) buffering for ca. 3 hours of playback. I think the players initially buffer more than 1 second, don't they? -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Wed, Jun 24, 2009 at 03:23:44PM +0200, Krzysztof Halasa wrote: I wonder what is the difference between the on-air frame rate and your card's (fixed) one? 100 ppm would need one second of additional (initial) buffering for ca. 3 hours of playback. I think the players initially buffer more than 1 second, don't they? the problem is not the absolute accuracy of your graphics card. the problem is: there are always differences between the on-air frame rate and the card's fixed one if both are not synchronized. Even if it were possible to adjust your graphics card exactly to 50Hz it would help nothing. Because the on-air frame rate always floats around a litte. Besides that the graphics card of course never is running at exactly 50Hz. May be somewhere in the range of 49.90 and 50.10 if your are very optimistic. In practice (after heavily experimenting with that) this leads to field/frame losses/duplicates at least every 45 seconds. The only solution to avoid this judder is to synchronize the graphics card to the base clock of your software player. This is what the vga-sync-fields patch does. Any buffering won't help. Because the problem arises between the software player's base clock and the graphics card. And not between the TV station and the software player. Theoretically you could synchronize the software players clock to the (fixed) graphics card clock for replay of recordings. Even that is not a common practice under linux because the software player has no clue about the graphics card frame rate. For live-TV this is not possible anyway. Your assumption of 1 second buffer per 3 hours of playback is way too optimistic. - Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: I wonder what is the difference between the on-air frame rate and your card's (fixed) one? 100 ppm would need one second of additional ^^^ (initial) buffering for ca. 3 hours of playback. I think the players initially buffer more than 1 second, don't they? the problem is not the absolute accuracy of your graphics card. the problem is: there are always differences between the on-air frame rate and the card's fixed one if both are not synchronized. I already wrote about the difference and not about a card only, right? The broadcast is the most accurate and stable (at least here), almost always at 50 Hz +- maybe 10 ppm, maybe less than that. Even if it were possible to adjust your graphics card exactly to 50Hz it would help nothing. Because the on-air frame rate always floats around a litte. Of course. That's why I wrote about a buffering. Besides that the graphics card of course never is running at exactly 50Hz. May be somewhere in the range of 49.90 and 50.10 if your are very optimistic. No. In fact, I have just verified with a freq meter, it's orders of magnitude better. Aren't you using a miscalculated modeline (not 13.5 MHz pixel clock or invalid total number of pixels or lines or something like that)? 0.2% difference is excessive. The only solution to avoid this judder is to synchronize the graphics card to the base clock of your software player. This is what the vga-sync-fields patch does. Any buffering won't help. Because the problem arises between the software player's base clock and the graphics card. And not between the TV station and the software player. That would be true if you use some player-internal time base. But players can, and do, synchronize to the graphics card. IOW the card becomes the time base, and everything (sound) is adjusted to it. Of course this doesn't make much sense if your card is 0.2% faster than the broadcast, as for a 3-hrs playback you'd need to buffer over 20 seconds (= waiting 20+ s when changing channels). But if the difference is reasonable (100 ppm is quite a lot, WRT a pair of DPLLs controlled by quartz oscillators) buffering probably makes sense. Theoretically you could synchronize the software players clock to the (fixed) graphics card clock for replay of recordings. Even that is not a common practice under linux because the software player has no clue about the graphics card frame rate. Depends on the output driver. I think all sync drivers for mplayer and xine do it, don't they? (E.g. matrox driver) For live-TV this is not possible anyway. It's perfectly possibly if your card's frame rate is much better than those +- 0.2%. With 0.2%, well - that's impossible. Your assumption of 1 second buffer per 3 hours of playback is way too optimistic. Fine, let's assume we have a system with a big frame rate difference (the DPLL has a discrete set of frequencies it can produce, though it can do 13.5 MHz). I'm not saying you stuff your VCO code. I'm just not interested in it, at least at this point, and I'm going to implement (actually, have mostly done it) field sync only, based on the IRQs generated by the card, instead of Xserver peeking the registers all the time etc. This is simple, fast, and reliable. Actually, the best one can do (though it doesn't mean your VCO code can't make it even better). Now the question is the interface between players and Xserver, not the internals of the driver, which BTW I'm using for almost two years without issues. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Wed, Jun 24, 2009 at 07:33:47PM +0200, Krzysztof Halasa wrote: I already wrote about the difference and not about a card only, right? The broadcast is the most accurate and stable (at least here), almost always at 50 Hz +- maybe 10 ppm, maybe less than that. finally it does not matter how stable the broadcast itself is. Rather how this stability is realized by the decoder. Of course. That's why I wrote about a buffering. Buffering if at all only would help if your graphics card is slower than the broadcast. If it's faster you get noticeable disturbances if your buffer gets exhausted. No. In fact, I have just verified with a freq meter, it's orders of magnitude better. Aren't you using a miscalculated modeline (not 13.5 even that is way too much if you want directly route interlaced fields from decoder to graphics card double buffer. Without dynamically syncing decoder and graphics card you have no chance to stay within a time window of about +-20ms for double buffer updates. MHz pixel clock or invalid total number of pixels or lines or something like that)? 0.2% difference is excessive. I'm not speaking of my own setup. My algorithm dynamically adjusts with accuracy of +-0.001Hz. I'm speaking of common solutions for video playback using the XV extension. That would be true if you use some player-internal time base. But players can, and do, synchronize to the graphics card. IOW the card becomes the time base, and everything (sound) is adjusted to it. are these solutions also available for live TV? Depends on the output driver. I think all sync drivers for mplayer and xine do it, don't they? (E.g. matrox driver) can't tell. I don't know these proprietary solutions for matrox cards. Now the question is the interface between players and Xserver, not the internals of the driver, which BTW I'm using for almost two years without issues. no problem. With my solution I setup a tiny D945GSEJT based linux SAT receiver consuming only about 14W with high quality SCART/HDMI output. I don't know any another solution providing these features under linux. - Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: finally it does not matter how stable the broadcast itself is. Rather how this stability is realized by the decoder. No. What is important is maximum shift in time between the broadcast and playback. It has to stay within buffering capability. It's that simple. If your playback time base (video card, or sound card, or metronom etc.) is slower than the broadcast, you don't have to buffer in advance. You will need more buffers as the show goes on but this is hardly a problem. If your playback is faster than broadcast, you need some initial buffers which will be drained as the playback progresses, because you supply video data a bit slower than you consume it. True: if you playback is noticeable faster (0.2% is) then you can't effectively compensate for this because you'd need really big initial buffers. OTOH you can artificially make it slower (tried and it worked well with a live DV cameras) and forget about those problems, especially if you only need to display it. This is BTW also possible with multiple video streams. Buffering if at all only would help if your graphics card is slower than the broadcast. If it's faster you get noticeable disturbances if your buffer gets exhausted. Not if. When. This is why you need to calculate how much buffering do you need. Unless you aim for a continuous playback for a really long time (such as many hours) - this would be problematic (if not slowing down the card, of course). I'm not speaking of my own setup. My algorithm dynamically adjusts with accuracy of +-0.001Hz. I'm speaking of common solutions for video playback using the XV extension. The above has nothing to do with Xvideo or no Xvideo. It's simple: frame rate = pixel clock / total h count / total v count. It was like that for ages. Pixel clock for digital SD video is 13.5 MHz and i915 can generate it. You divide by 864 pixels and 625 lines and you get 50 Hz. +- 0.001 Hz is 20 ppm, I wound't be surprised if a fixed clock generator stays within this limit, in comparison to the broadcast. Anyway you don't need 20 ppm, I guess 100 ppm is enough, and you can be slower as much as your TV likes. Of course your solution may be better for some corner cases. This doesn't matter at this point as I'm not trying to implement variable pixel clock but, rather, a synchronized playback using textured overlays This is simply orthogonal to the VCO thing, you can use both. That would be true if you use some player-internal time base. But players can, and do, synchronize to the graphics card. IOW the card becomes the time base, and everything (sound) is adjusted to it. are these solutions also available for live TV? Yes, in the official packages for a long time. can't tell. I don't know these proprietary solutions for matrox cards. They don't seem to be very proprietary. Open-source drivers written by their users I guess. Note it may be unable to drive the Parhelia cards, I don't know. Also, there are drivers for other hw/sw doing the same. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Paul Menzel paulepan...@users.sourceforge.net writes: I am no expert and do not know if it has anything to do with your “problem”, but have you heard of the FRC patches [1] yet? I put Thomas, the author of the patches, to receivers of this message. Thanks for the pointer. It's seems those patches are a bit different functionality, what I'm going to implement is the BFF/TFF(/progressive) interface at XVideo and DRM level. Unless I'm mistaken the patches don't touch the field order and sync, at least on the intel and/or i915 driver. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 03:54:03PM +0200, Krzysztof Halasa wrote: DRM level. Unless I'm mistaken the patches don't touch the field order and sync, at least on the intel and/or i915 driver. with a slight modification the patches can output BFF or TFF. But I'm living in PAL land so I use TFF only ATM. going to implement is the BFF/TFF(/progressive) interface at XVideo and what do you mean with progressive here? Do you mean 2 interlaced fields in weaved format? The vga-sync-fields patches effectively use these 2 weaved fields of softdecoder output and forward these directly to VGA/DVI output. To keep synchronicity between stream and video timing the output line frequency is continuously trimmed in very small steps. This works very well even for live-TV where you must adopt exactly the stream clock delivered by the TV station. Trimming the graphics card video timing ensures that the weaved fields always appear at the right time in the double buffer of graphics card. Video output is interlaced. It's the task of the display to take care of deinterlacing (if needed). This relieves the PC from CPU intensive deinterlacing. So the patches work very well with Asus EEE 701 or Intel D945GSEJT. DRM level. Unless I'm mistaken the patches don't touch the field order and sync, at least on the intel and/or i915 driver. moving the sync point by 20ms yields in reversed field order output Cheers Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: with a slight modification the patches can output BFF or TFF. But I'm living in PAL land so I use TFF only ATM. I'm here as well but I routinely use PAL MPEG2 (DVD) with BFF encoding (originating as DV which is always BFF, I could of course shift the audio and reverse fields but it creates some minor additional problems). going to implement is the BFF/TFF(/progressive) interface at XVideo and what do you mean with progressive here? Do you mean 2 interlaced fields in weaved format? Progressive video playback on interlaced display. This means the driver is free to sync to either field (for example, to the previously selected one). The vga-sync-fields patches effectively use these 2 weaved fields of softdecoder output and forward these directly to VGA/DVI output. To keep synchronicity between stream and video timing the output line frequency is continuously trimmed in very small steps. This works very well even for live-TV where you must adopt exactly the stream clock delivered by the TV station. Right. This is well beyond my needs. DRM level. Unless I'm mistaken the patches don't touch the field order and sync, at least on the intel and/or i915 driver. moving the sync point by 20ms yields in reversed field order output Ah... But there is a simple interrupt-based way. And it doesn't depend on the timings, the card signals end of each field. You may want to see intelfb for details, I was using fb because the X playback was unusable. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Mon, Jun 22, 2009 at 09:56:20PM +0200, Krzysztof Halasa wrote: My assumption (please correct if wrong): - it requires interlaced display mode (i830+: practically completed). sorry, but opposite to i810 and i9xx the i830 is not capable of doing any interlaced video output. - the video windows must not be scaled vertically. this restriction applies for i810 but is no longer true for i9xx graphics - sync events for TFF and BFF are signaled by interrupts. For progressive video (with interlaced display mode, of course) we can not necessarily by driver interrupts. In [1] (intel portion of vga-sync-fields patch) I simply peek some registers (DOVSTA and PIPEA_DSL) directly within the Xserver to determine the actual line + field position of CRT controller at any time. In [2] (radeon portion of the patch) I do the same with radeon graphics. A small DRM-driver patch there is only needed to dynamically alter video output timing. You are right: for i810 some field related overlay regs must be reprogrammed during vertical retrace interrupts. This is no longer true for i9xx architecture. 2 weaved fields are processed there with no driver (interrupt) intervention. - Thomas [1] http://www.easy-vdr.de/git?p=frc.git/.git;a=blob;f=patches/xv-intel.patch;h=b54655a6d6473f55b49fac759f4afc77c101d69f;hb=20810204a85917449096a5fbba65d996c0a1ac2c [2] http://www.easy-vdr.de/git?p=frc.git/.git;a=blob;f=patches/xv-radeon.patch;h=8c6ee3f199f70364c91057c634dfbf864c3db656;hb=20810204a85917449096a5fbba65d996c0a1ac2c ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: RFC: Xv field order
Krzysztof Halasa k...@pm.waw.pl writes: I'm at a point with all needed hardware info to implement interlaced mode (mainly for perfect Xvideo playback) in intel driver. Now there is another question: how should an Xv client interface with it? Do we have any interlaced field-aware Xv interface? What video encoder are you planning to use for the TV out? I am using a Chrontel 7022 on a SDVO/ADD2 card driven by a 945G chipset to output on a composite coax cable. When sending it 720x480 frames (I work in NTSC) I keep getting scaling artifacts (that are not caused by XV texturing this time:). If I could get rid of that scaling artifact, I think that I could send it the 720x480 frames consisting of the two weaved fields and get a decent interlaced video quality (although timing from frame to frame might still be an issue) Hugo Jacques This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: sorry, but opposite to i810 and i9xx the i830 is not capable of doing any interlaced video output. Aaa, right, that may be so. I meant the traditional i830 driver (as opposed to i810), now it's named intel and the DRM is i915. In fact I'm not really interested in pre-915 chips. - the video windows must not be scaled vertically. this restriction applies for i810 but is no longer true for i9xx graphics Come on, playback of interlaced video only makes sense with vertically unscaled display. Otherwise you have to deinterlace first and this is hardly usable (except for maybe 1:2 scaling when you can just strip every other line to get progressive video). It doesn't depend on the chip. Well, obviously there is another possibility, you can double the frame rate - I guess not something we can do here (TV sets do that internally). not necessarily by driver interrupts. In [1] (intel portion of vga-sync-fields patch) I simply peek some registers (DOVSTA and PIPEA_DSL) directly within the Xserver to determine the actual line + field position of CRT controller at any time. Yes, I realize you can do it this way. But the chip can do it in hardware. IRQ driven, faster and completely reliable. The code already does it for progressive display + textured video. I've been using interrupt-driver frame sync (with selectable TFF/BFF - though without textured video) for almost 2 years and it's simple, fast and reliable - even with the CPU doing all the work. I wonder... Can your current code support textured video? Multiple video windows? Don't you have reliability problems, caused by the 20 ms sleep taking longer than requested (due to lack of RT scheduling)? You are right: for i810 some field related overlay regs must be reprogrammed during vertical retrace interrupts. I didn't say that. Actually I don't know about i810. This is no longer true for i9xx architecture. 2 weaved fields are processed there with no driver (interrupt) intervention. Consider two video windows, one is BFF and the other one TFF. You have to sync after each field. Of course, each window will get sync events only every complete frame, but they will be a field apart. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 08:08:38PM +0200, Krzysztof Halasa wrote: Come on, playback of interlaced video only makes sense with vertically unscaled display. Otherwise you have to deinterlace first and this is hardly usable (except for maybe 1:2 scaling when you can just strip every the newer type intel chips do that transparently in hardware. I have not found documentation about how they exactly handle this (by scaling each field independently or by deinterlacing?). But for watching 16:9 material on an 4:3 TV it's a very useful feature. Picture quality is still very good. It doesn't depend on the chip. yes it does. i815 chips and radeon pre-avivo chips can't scale interlaced material vertically. But i9xx chips can do. I wonder... Can your current code support textured video? Multiple video windows? Don't you have reliability problems, caused by the 20 ms sleep taking longer than requested (due to lack of RT scheduling)? no, my patch collection is for conventional TV - one screen only. My major concern was not to encounter any field loss. That's why I synchronize field timing dynamically to the stream clock. The stream clock is calculated within xine-lib (in my case). I built extensive debug tools showing any reliability problems. If you aren't running number crunching processes on the machine whilst watchin TV there are no problems at all. On 2.6.26 or newer kernels I need not alter scheduling policies. - Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 08:08:38PM +0200, Krzysztof Halasa wrote: Thomas Hilber x...@toh.cx writes: sorry, but opposite to i810 and i9xx the i830 is not capable of doing any interlaced video output. Aaa, right, that may be so. I meant the traditional i830 driver (as opposed to i810), now it's named intel and the DRM is i915. In fact I'm not really interested in pre-915 chips. - the video windows must not be scaled vertically. this restriction applies for i810 but is no longer true for i9xx graphics Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: RFC: Xv field order
-Original Message- From: Krzysztof Halasa [mailto:k...@pm.waw.pl] Sent: Tuesday, June 23, 2009 14:59 To: Jacques, Hugo Cc: xorg@lists.freedesktop.org Subject: Re: RFC: Xv field order Jacques, Hugo hugo.jacq...@verint.com writes: What video encoder are you planning to use for the TV out? At this time I'm using internal RGB VGA. But I'll also personally need an SDVO DVI-D (on-board Chrontel chip). I am using a Chrontel 7022 on a SDVO/ADD2 card driven by a 945G chipset to output on a composite coax cable. When sending it 720x480 frames (I work in NTSC) I keep getting scaling artifacts (that are not caused by XV texturing this time:). If I could get rid of that scaling artifact, I think that I could send it the 720x480 frames consisting of the two weaved fields and get a decent interlaced video quality (although timing from frame to frame might still be an issue) I guess it's Chrontel chip scaling it. Unfortunately the docs don't seem to be public, are they? I don't think they are. I might be wrong. Hugo This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Ville Syrjälä syrj...@sci.fi writes: Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. Well, correct. Is something (hardware, drivers) capable of doing that? It would mostly make sense with small reduction (like 576-480), right? -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Thomas Hilber x...@toh.cx writes: the newer type intel chips do that transparently in hardware. I have not found documentation about how they exactly handle this (by scaling each field independently or by deinterlacing?). Ah, I didn't know this. Is it supported by the textured video? Overlay only? But for watching 16:9 material on an 4:3 TV it's a very useful feature. Picture quality is still very good. Or at least the best we can do. Sure. My TV monitor has different modes (16/9, 14/9, 4/3 and so on) so I haven't though about it, but it's clearly interesting for displaying many video windows simultaneously (thumbnails). no, my patch collection is for conventional TV - one screen only. My major concern was not to encounter any field loss. That's why I synchronize field timing dynamically to the stream clock. Sure, I OTOH work with non-live data. -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 10:10:18PM +0200, Krzysztof Halasa wrote: Ville Syrjälä syrj...@sci.fi writes: Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. Well, correct. Is something (hardware, drivers) capable of doing that? Any hardware with a decent texture unit (or scaler which writes the results to the framebuffer) should be enough. Also some hardware has video overlays which can do it too (OMAP3 is one example). I don't know if any Xorg driver can do it, but DirectFB's matrox driver supports field based scaling. It uses the texture unit. It would mostly make sense with small reduction (like 576-480), right? The scaling ratio should be irrelevant. The fields are basically independent pictures so you can scale them how much you like. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Ville Syrjälä wrote: On Tue, Jun 23, 2009 at 08:08:38PM +0200, Krzysztof Halasa wrote: Thomas Hilber x...@toh.cx writes: Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. Even with scaling, it's not a great idea. Interlacing is a psychovisual hack, designed to make use of your eye's motion-compensation and spatiotemporal interpolation systems. It only works if the scan lines not present in each frame are black, because your persistence of vision will fill in the black lines with the correctly motion-compensated contents of the previous frame. If you scale each field to fill the frame, you will perceive significant flicker and blurring of fine detail. The only way to reproduce the interlace effect correctly is to leave half the lines black in each frame. If you are scaling, this is basically impossible, unless you are scaling up by a factor of at least 2. A good deinterlacer is a much more general solution. --Ben signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 04:48:25PM -0400, Benjamin M. Schwartz wrote: Ville Syrjälä wrote: On Tue, Jun 23, 2009 at 08:08:38PM +0200, Krzysztof Halasa wrote: Thomas Hilber x...@toh.cx writes: Come on, playback of interlaced video only makes sense with vertically unscaled display. Not true if you can scale the fields independently. Even with scaling, it's not a great idea. Interlacing is a psychovisual hack, designed to make use of your eye's motion-compensation and spatiotemporal interpolation systems. It only works if the scan lines not present in each frame are black, because your persistence of vision will fill in the black lines with the correctly motion-compensated contents of the previous frame. Sounds like you're thinking of bob deinterlacing which this is not. The output will still be interlaced with black scanlines and all. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Ville Syrjälä wrote: Not true if you can scale the fields independently ... Sounds like you're thinking of bob deinterlacing which this is not. The output will still be interlaced with black scanlines and all. True, but even if you're scaling output to a truly interlaced display, scaling a single field will not give you correct spatial behavior. You can think of this is as a frequency-domain aliasing problem in the vertical direction, if you like. The best solution would still be to use a fancy motion-search deinterlacer, and then throw away half the output lines. --Ben signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
On Tue, Jun 23, 2009 at 10:19:25PM +0200, Krzysztof Halasa wrote: Thomas Hilber x...@toh.cx writes: Ah, I didn't know this. Is it supported by the textured video? Overlay only? I haven't tried textured video since a while because this had bad tearing effects at the time when I started my vga-sync-fields project. This may have changed meanwhile. Scaling interlaced material vertically is supported by at least overlay video on i9xx chips. Maybe somebody can roughly tell how this scaling feature has been realized for intel i9xx series hardware? Would be very interesting. I haven't found any documentation about that yet. no, my patch collection is for conventional TV - one screen only. My major concern was not to encounter any field loss. That's why I synchronize field timing dynamically to the stream clock. Sure, I OTOH work with non-live data. right, when playing non-live data VGA output timing needs not to be synced to an external signal. But for live-TV it's crucial if you don't want to lose fields/frames. The more I'm wondering there still does not exist any other solution to that problem except my vga-sync-fields patch. Even vdpau does still NOT sync video timing to an external clock source (e.g. PTS dictated by a TV station). Which means that even vdpau loses/doubles fields/frames when watching live-TV. - Thomas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RFC: Xv field order
Hi, I'm at a point with all needed hardware info to implement interlaced mode (mainly for perfect Xvideo playback) in intel driver. Now there is another question: how should an Xv client interface with it? Do we have any interlaced field-aware Xv interface? My assumption (please correct if wrong): - it requires interlaced display mode (i830+: practically completed). - the video windows must not be scaled vertically. - there could be progressive, top-field-first or bottom-field-first order. PAL uses (generally) TFF, NTSC - BFF. Video may be in any order and it may change in the middle. - using textured Xv we can have many video windows on one screen. Each can have different field order (progressive, TFF or BFF). This also depends on vertical window position and on panning position. HW support is not a problem. - sync events for TFF and BFF are signaled by interrupts. For progressive video (with interlaced display mode, of course) we can pick any of these two. Now: how is a client going to tell the Xserver that it wants progressive, TFF or BFF video window? Possibilities: - attribute: XV_TOP_FIELD_FIRST, writable by the client. 0 = BFF, 1 = TFF. A client could change the value upon a change in the video material. Could we have 3 values (TFF, BFF, -1 = progressive)? Perhaps a better name/scheme? - different XV ports for TFF and BFF. A client would have to change ports when the video order changes. - adding field order to Xv specs? Should it have anything to do with XvMC? -- Krzysztof Halasa ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RFC: Xv field order
Dear Krzysztof, Am Montag, den 22.06.2009, 21:56 +0200 schrieb Krzysztof Halasa: […] I'm at a point with all needed hardware info to implement interlaced mode (mainly for perfect Xvideo playback) in intel driver. Now there is another question: how should an Xv client interface with it? Do we have any interlaced field-aware Xv interface? I am no expert and do not know if it has anything to do with your “problem”, but have you heard of the FRC patches [1] yet? I put Thomas, the author of the patches, to receivers of this message. […] Bests, Paul [1] http://frc.easy-vdr.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
