[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Video Planning Meeting
From:       Billy Biggs <vektor () dumbterm ! net>
Date:       2002-01-27 1:33:47
[Download RAW message or body]

  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
[prev in list] [next in list] [prev in thread] [next in thread]