From kde-multimedia Sun Jan 27 01:33:47 2002 From: Billy Biggs Date: Sun, 27 Jan 2002 01:33:47 +0000 To: kde-multimedia Subject: Re: Video Planning Meeting X-MARC-Message: https://marc.info/?l=kde-multimedia&m=101209480603342 I thought I could contribute some more numbers/information to this discussion. Martin Vogt (mvogt@rhrk.uni-kl.de): > 2. Format. > ---------- > There are different image formats/colorspaces. > Every video codec has its own understanding of the > best colorspace for it. > > -RGB[8..32] (png,gif, X11 Server Standard) > -YUV12 (mpeg) > -YUY2 (M$, divx) This list is by no means exhaustive, and to make matters worse, there are multiple standards for each even within a fourcc. For example, YV12 is the fourcc used for all Y'CbCr image maps at 4:2:0 sampling. However, MPEG1, MPEG2 and JPEG each have their own styles of sampling chrominance. This makes colourspace determination difficult. I think alot of us want to have a common library for handling conversions and resamplings between these formats. omega from the gstreamer project (see #gstreamer on OPN) has started a neat library, and also the avifile people have been looking into doing a library also. I'd recommend we work together to solve this part. > 3. Memory > --------- > Video Codecs operate the computer at the RAM bandwith limits. > > Result: For performance reasons we need to use shared mem, but its > not possible to use it always. > > Here are some numbers: > > For example a DVD video with as an RGB_32 image "produces": > > 712x512 DVD image * 4 RGB_32 == 364544 * 4 == 1458176 Bytes == 1 MB > per image > If you have 30 images (NTSC) this means 30 MB. But this is not the end. For kicks, here are some worst-case numbers. First off, we'll assume we can convert Y'CbCr -> R'G'B' in hardware (XVideo+overlay surfaces). DVD-Video uses Y'CbCr at 4:2:0: PAL: 720x576: 622080 bytes @ 25fps: 15552000 bytes/second. NTSC: 720x480: 518400 bytes @ 29.97fps: 15536448 bytes/second. For broadcast TV quality video we have higher chrominance sampling and therefore more colour resolution, and therefore more data. Broadcast TV sampling 720 pixels at 4:2:2: PAL: 720x576: 829440 bytes @ 25fps: 20736000 bytes/second. NTSC: 720x480: 691200 bytes @ 29.97fps: 20715264 bytes/second. To make matters worse, these frames are often interlaced. When playing back on a progressive display like a computer monitor or CRT projector, we must 'deinterlace', that is, convert each field in the image to full frame size. This doubles our framerate and data rate: Broadcast TV deinterlaced at 4:2:2 Y'CbCr: PAL: 720x576: 829440 bytes @ 50fps: 41472000 bytes/second. NTSC: 720x480: 691200 bytes @ 59.94fps: 41430528 bytes/second. That's alot of data. :( For deinterlacing interlaced DVD sources you can strip that down if you're willing to stay at 4:2:0, but if you're compositing subtitles or something, you may want to up the data rate to the 4:2:2 case. 4:2:2 Y'CbCr uses the YUY2 fourcc. 4:2:2 sampling is the standard for broadcast TV (but not new MPEG2 broadcasting which seems to stick with the 4:2:0 profile). > An mpeg video player produces YUV12 images, but the X11 Server has > only support for RGB16. Some graphics cards has the XVideo > extension, but I think the i810 can only handle YUY2, thus there > need to be conversion from YUV12->YUY2 for XVideo support. Pretty much every card that supports only 4:2:2 has a software converter in the XVideo driver that just doubles each chrominance scanline as it copies to video memory. Doing the conversion while you copy is cheaper, but because they don't do any sort of filtering you see some colour artifacts. :( Personally, I think of it like putting sample rate conversion into kernel soundcard drivers, something I for one am against. If we could only agree on a common user library for colourspace conversions ....... > "reverse" dithering can be usefull too. If you have an image in > RGB colorspace (png,gif) its usefull to dither it back to eg > YUY2/YUV12 because this allows resize/fullscreen with hardware > support. Don't be so quick to do stuff like this. The mapping isn't 1-1, some colours aren't representable in the other colour space and vice versa. Also, all of the 'fast mmxified conversions' for both directions out there have bad rounding problems. But hey. > VidMode Extension > ----------------- > - Here we remove the borders of the window resize the window > calculate an offset for the image position query the X server for > video resolutions and switch to this resoltion. You also want to be able to switch to a refresh rate which closely matches the output framerate. The VidMode extension in X4 is currently broken for adding modelines on the fly though, but I have a patch I'm going to clean up to fix this. We still need help in the vsync area though in deciding with the X folks on how best to do stuff like this for high-framerate video (like 59.94fps on a 59.94hz display). If anyone on this list would like to help out, talk to me (vektor) or omega on #livid/#gstreamer/etc... or email. My page on some refresh rate stuff: http://www.dumbterm.net/graphics/refresh/ -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ kde-multimedia mailing list kde-multimedia@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-multimedia