Re: [Xpert]XVideo extension docs
Attached is a modified rootv.c file - this should do the trick. I tested it on my ATI AIW radeon and it works OK. The window sizes and everything are all hard coded, but you can change this stuff to suit your needs and see how it works. The encoding is also hard coded to the number that the ATI driver uses for NTSC composite - you can figure out which number this is for your brooktree board by using xvinfo. Yup, checked that and chanded it accordingly. I tested it with all Xv ports which i assumed to correspond to the video devices i have (which seems to be a wrong assumption because of the results i got). Anyway - if i start the program it displays some image but it is half offscreen and half set to the side, as a completly misconfigured overlay and looks pretty close to the overlay (guessed upon the coloring as xv images have a slightly darker gamma than overly here). The video is display for some seconds and then it locks up for some seconds and the process repeats. After launching the app the X server is no longer responsive and often can not be restarted cleanly at all. In short - it does not work. (BTW - i think you mixed up the order of some of the parameters of the XvPutVideo() call in that modified rootv.c). Any more ideas? Eventually i can test it with a system with an Nvidia card to see if it works anything different... Not sure I completely understand you here, but any program can use the XvPutVideo() call. There are various reasons why the author of xawtv chose Just to go for sure - i guess the XvPutVideo call is not just an X-server integrated version of the overlay+clipping functionality like xawtv does? I mean - it really uses graphics hardware for colorspace+stretching? XvShmPutImage instead - in my experience, this call is usually used to display frames one at a time in quick succession (such as in an MPEG-2 decoder). Exactly, and in the case of xawtv (and my kvdr) i use it to display consecutive grabbed frames which works but with the mentioned limitations. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
I tested it with all Xv ports which i assumed to correspond to the video devices i have (which seems to be a wrong assumption because of the results i got). You'll note that the software picks the first port that it finds which matches both the XvInputMask and XvVideoMask (ie - it supports putVideo - can be verified using XvInfo). So, if you have multiple cards that support this, you'll always get the first one unless you modify it. Anyway - if i start the program it displays some image but it is half offscreen and half set to the side, as a completly misconfigured overlay and looks pretty close to the overlay (guessed upon the coloring as xv images have a slightly darker gamma than overly here). The video is display for some seconds and then it locks up for some seconds and the process repeats. After launching the app the X server is no longer responsive and often can not be restarted cleanly at all. In short - it does not work. (BTW - i think you mixed up the order of some of the parameters of the XvPutVideo() call in that modified rootv.c). I didn't actually write this It looks OK to me - from the man page: XvPutVideo(dpy, port, d, gc, vx, vy, vw, vh, dx, dy, dw, dh) Display *dpy; XvPortID port; Drawable d; GC gc; int vx, vy, dx, dy; unsigned int vw, vh; unsigned int dw, dh; You could try making the last 8 numbers 0,0,640,480,0,0,640,480 ... It was set for 240 because of some deinterlacing junk for the ATI card I was working with at the time - this could cause you issues. Any more ideas? Eventually i can test it with a system with an Nvidia card to see if it works anything different... Not sure I completely understand you here, but any program can use the XvPutVideo() call. There are various reasons why the author of xawtv chose Just to go for sure - i guess the XvPutVideo call is not just an X-server integrated version of the overlay+clipping functionality like xawtv does? I mean - it really uses graphics hardware for colorspace+stretching? As far as I understand, yes - this actually uses the graphics hardware to do colorspace conversions and overlays... (the hardware gurus can correct me here if I'm wrong). Try changing those numbers and see how it works What is the exact hardware you're using again (framegrabber card and VGA card) Perhaps if you post the output of xvinfo I could have a look to see if I can help solve your problem Mark ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
On Wednesday, 24. July 2002 03:05, [EMAIL PROTECTED] wrote: Thanks! That sounds really like i'am doing something wrong using repeated calls of XvPutStill() every 40ms (PAL). So it would work to just call XvPutVideo() once. I thought i made it right, as xawtv and mplayer both do use Still. I tried just to use Video() but it did'nt display anything at all. Do you have sample code working as described? There is actually a simple program that does this included with xawtv. Download the xawtc src and look for a file called rootv.c in the src directory - that should do the trick. This will work with a brooktree (v4l) device provided the v4l module is loaded in the X server. If you type xvinfo and get a device called video4linux, you should be set. Ok, i tryed it (once again): $ ./rootv 4 adaptors available. name: video4linux name: video4linux name: video4linux name: 3dfx Video Overlay it prints and then stays quite. No video visible. Tested with the first 3 ports ( 1 and 2 are dvb cards, 3 is bttv) What wonders me, is that this program is there but xawtv uses XvShmPutStill() in it's Xv displaying loop anyway. Are you the only one able to use the PutVideo() call? Which version of the bttv driver do i need at least? (Still using 2.4.0 kernel) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
Attached is a modified rootv.c file - this should do the trick. I tested it on my ATI AIW radeon and it works OK. The window sizes and everything are all hard coded, but you can change this stuff to suit your needs and see how it works. The encoding is also hard coded to the number that the ATI driver uses for NTSC composite - you can figure out which number this is for your brooktree board by using xvinfo. You can compile this by typing: gcc rootv.c -L/usr/X11R6/lib -lX11 -lXv -lXext What wonders me, is that this program is there but xawtv uses XvShmPutStill() in it's Xv displaying loop anyway. Are you the only one able to use the PutVideo() call? Not sure I completely understand you here, but any program can use the XvPutVideo() call. There are various reasons why the author of xawtv chose XvShmPutImage instead - in my experience, this call is usually used to display frames one at a time in quick succession (such as in an MPEG-2 decoder). Which version of the bttv driver do i need at least? (Still using 2.4.0 kernel) 2.4.0 should be OK - I'm using the RedHat 7.3 stock kernel (2.4.18-3), but anything in the 2.4 tree should be ok. Hope that helps! Mark - Original Message - it prints and then stays quite. No video visible. Tested with the first 3 ports ( 1 and 2 are dvb cards, 3 is bttv) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert rootv.c Description: Binary data
Re: [Xpert]XVideo extension docs
I'm coming (butting?) into the middle of this so my comments may not be germane (in which case I won't be offended if you tell me to buzz off). No, many thanks for your in depth explanation. I'm not quite sure what YUV2 is but ordinary MPEG2 YUV (more properly, Y, Cb, Cr) is such that U and V are subsampled x2 horizontally w.r.t. Y and that is how you get 16 bits. I'am far from xpert at this area - so maybe i'am wrong at this ml anyway mayself ;-) Bit chopping does not, technically speaking, result in loss of resolution. Instead you get various contouring and other artifacts due to the Exactly that is what i see! But what to do now? Is there a way to support more ximage input formats? But, this is going OT now - as it was about Xvideo docs. Still got no detailed explanation why i should use the XvPutVideo() function call at all, which i thought would solve btw, the problem of the high CPU-load (at least reported to me with V3K + NVIDIA + Matrox cards). ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
Michel Lanners ([EMAIL PROTECTED]): On 23 Jul, this message from Guido Fiala echoed through cyberspace: moving YUV across the bus, but it should use no CPU. Yes, so i thought. But that would mean, that the XServer loads it's data directly from the v4l device itself (mmap-io or direct write into AGP-memory?) The latter should work if the ximage is a contigous array in AGP memory only. No, it's the video input hardware that pushes the data with DMA to an off-screen VRAM memory area, and the graphic chip then copies and color-converts on the fly to the visible window. Wouldn't it be great if they were actually in sync so they wouldn't tear, or so that we could handled interlaced streams better. The v4l-module architecture needs to be reworked. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
:: These are all driver-specific properties and not something that would
:: be in a general API description. For the most part these just shadow
:: the V4L attributes.
::
:: Right - but AFAIK there is no such thing as setting the grabbing frequency in
:: v4l drivers.
::
:: Video is not in RGB. Video is always in YUV. I don't think it's
:: possible for an RGB format to have better quality if the video source
:: is in YUV.
::
:: Right - but if you have a dvb card at hands you can see that the overlay
:: quality in RGB565 mode is much better than YUV2 although both formats are
:: 16bits and although the input is MPEG2, especially yellow and brown colors
:: have little resolution.
::
:: That means, eventually Xvideo is not was i need - i'll will try GL instead,
:: because Xv uses to much CPU (X-server, sys) anyway...
I'm coming (butting?) into the middle of this so my comments
may not be germane (in which case I won't be offended if you tell
me to buzz off).
I'm not quite sure what YUV2 is but ordinary MPEG2 YUV (more properly,
Y, Cb, Cr) is such that U and V are subsampled x2 horizontally w.r.t. Y and that
is how you get 16 bits.
In fact looking horizontally at MPEG2 (studio profile) you see {Y Cb Y
Cr Y Cb Y Cr ...}. Where Y, Cb, and Cr, are each 8-bits. Hence each
grouping ((Y Cx): (x\in {b,r}) is 16bits. The more usual MPEG2 (main profile)
also subsamples the U and V vertically x2.
As a result the chrominance signal can support only
half (or less) the resolution of the luminance signal.
For RGB-565 you are chopping bits from each subpixel, a non-linear
operation not (easily) amenable to linear systems type analysis.
Bit chopping does not, technically speaking, result in loss of resolution.
Instead you get various contouring and other artifacts due to the
limited bit-depth. Note however that there is an R, G, and B sub-pixel
at every location in the sampling lattice so the chrominance signal
can support just as high frequencies as the luminance.
Caveat to the Cognoscenti: Those who know this subject will detect
that I've fudged a tiny bit in my explanation. But what I've said gets
across is layman's terms why you would see low chroma
resolution in the YUV case.
dean S. Messing
Center for Displayed Appearance
Information Systems Technologies Dept.
Sharp Laboratories of America
E-Mail: [EMAIL PROTECTED]
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
API docs are in the server tree at xc/doc/hardcopy/Xv. There are DEC's original docs there and the version 2.2 addendum. Thanks too. However - that does'nt seem to be more than just the man-pages. I'am missing documentation about the XV_FREQ atom - what is the purpose and unit of the freq interger? (It seems anything works the same with and without setting that at all) Also - i don't see why i should use the Put/GetVideo calls at all, they don't seem to do anything useful for me. Another thing - where are the number of available _input_ formats (color spaces) specified? I mean - why are just those available listed by xvinfo and not e.g. RGB565 or RGB24 which would give much better output quality than YUV2 from v4l devices!? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
On Thu, 18 Jul 2002, Guido Fiala wrote: API docs are in the server tree at xc/doc/hardcopy/Xv. There are DEC's original docs there and the version 2.2 addendum. Thanks too. However - that does'nt seem to be more than just the man-pages. I'am missing documentation about the XV_FREQ atom - what is the purpose and unit of the freq interger? These are all driver-specific properties and not something that would be in a general API description. For the most part these just shadow the V4L attributes. (It seems anything works the same with and without setting that at all) Also - i don't see why i should use the Put/GetVideo calls at all, they don't seem to do anything useful for me. Another thing - where are the number of available _input_ formats (color spaces) specified? I mean - why are just those available listed by xvinfo and not e.g. RGB565 or RGB24 which would give much better output quality than YUV2 from v4l devices!? Are you speaking of XvImage formats or something else? XvImage formats are formats the hardware supports. There are no software fallbacks in any Xv drivers that I've seen, so if the hardware doesn't do it, it doesn't get advertised. Video is not in RGB. Video is always in YUV. I don't think it's possible for an RGB format to have better quality if the video source is in YUV. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XVideo extension docs
Hello! I'm tring to find documentation on capabilities and use of XVideo extension. Mabey someone knows where to find some manuals or so? Jacek Bator [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
On Tue, 16 Jul 2002, Jacek Bator wrote: Hello! I'm tring to find documentation on capabilities and use of XVideo extension. Mabey someone knows where to find some manuals or so? API docs are in the server tree at xc/doc/hardcopy/Xv. There are DEC's original docs there and the version 2.2 addendum. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
On Tue, 16 Jul 2002, Jacek Bator wrote: I'm tring to find documentation on capabilities and use of XVideo extension. Mabey someone knows where to find some manuals or so? xc/doc/hardcopy/Xv in the tarball. xc/doc/specs/XvMC in the tarball. xc/doc/man/Xv in the tarball. -Peter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
