Announcement

Collapse
No announcement yet.

Flying Dutchman patch, YUV2 & drivers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Flying Dutchman patch, YUV2 & drivers

    Hello,
    Please, can somebody send me the Flying dutchman patch for the YUV2 correction ?
    Also, when Matrox will release some new drivers for the Marvel G400-TV with a full support of the YUV2 ?

  • #2
    They're in the mail.

    Word is future drivers will have YUY2 enabled by default.

    Dr. Mordrid

    Comment


    • #3
      Thank you Doc for the patch.

      By the way I'm quite young in the video world and I like to know if somebody has some documentation concerning the differents formats YUV, YUY, .... and I like to know also what is the difference between YUV2 and YUY2?
      Thanks in advance

      Comment


      • #4
        YUV is a video encoding method. It has many variants of which YUY2 is one. These are written in four character codes, or fourCC's. The various fourCC's are listed here;

        http://www.webartz.com/fourcc/fccyuv.htm

        Y = the luma component of the signal

        U = the chroma red component (aka: Cr)

        V = the chroma blue component (aka: Cb)

        In the U.S. the "official" format is called YCrCb, but most folks still use YUV. PAL still designates their standard as YUV.

        There are three commonly used "resolutions" of YUV. The following are based on a 720 wide frame;

        4:4:4 (Studio)= each horizontal pixel has its own Y, Cr and Cb value.

        B&W rez: 720
        Color rez: 720

        4:2:2 (Broadcast)= each pixel has its own Y value, but the color value is shared between 2 horizontal pixels.

        B&W rez: 720
        Color rez: 360

        4:1:1 (NTSC DV)= each pixel has its own Y value, but the color value is shared amongst 4 horizontal pixels.

        B&W rez: 720
        Color rez: 160

        PAL DV has a designation of 4:2:0

        DV's very reduced color rez is why there are problems encoding it to MPEG or when using it for composited or bluescreen effects. These 4 pixel color packages tend to organize into very visible block artafacts in shadows and in large color patches. It also exhibits "quliting", or stair-step artifacts, along diagonal lines.

        TMPGEnc has a mode that helps DV considerably by up-sampling the video to 4:4:4 before encoding it to MPEG. This helps MPEG encoding considerably, but it's still not perfect and DV so encoded can still show artifacting.

        The RT-2000 also helps DV editors a lot. When it reads in DV's 4:1:1 video it up-samples and converts it to 4:4:4:4 RGBA. What's that?

        In a 720 wide frame;

        R: 720 red values
        G: 720 green values
        B: 720 blue vlaues
        A: 720 wide alpha channel

        As a result all internal modifications of the video in an RT-2000 are done at full resolution in all channels.

        Because of this up-sampling and the addition of the alpha channel the RT-2000's output encodes to MPEG much better and the compositing issues are largely eliminated.

        This feature is the RT-2000's big advantage over other DV or realtime solutions.

        Dr. Mordrid


        [This message has been edited by Dr Mordrid (edited 27 February 2001).]

        Comment


        • #5
          Dr. Mordid,

          thank for your comprehensive and clarifying answer.

          I was just about to ask you Gurus why my DV-footage always comes out better when captured as MJPEG (through the G400 TV's BOB) and compressed to Mpeg or Mpeg4, than when "captured" (copied) as native DV through Firewire and compressed. I suppose MJPEG has better color resolution compared to the DV!?

          Comment


          • #6
            It's not necessarily MJPeg itself, it's the analog signal that comes out of the S-Video & Composite analog ports.

            These ports put out 4:2:2 vs. 4:1:1 for the IEEE-1394's DV footage. This does not change the color content of the video itself, but it does provide a larger "palette" when captured as MJPeg and edited.

            Of course the MJPeg data rate has to be high enough as well (>3 mb/s, preferrably 5 mb/s using PICVideo MJPeg at a quality setting of 20). This helps MPEG encoding, compositing and titles.

            Something similar can be done when encoding DV to MPEG by using TMPGEnc. It has an option in the Options/Global Settings tab for internally convolving 4:1:1 footage into 4:4:4 before encoding it to MPEG. Helps a lot....

            Dr. Mordrid


            [This message has been edited by Dr Mordrid (edited 28 February 2001).]

            Comment


            • #7
              Can someone please e-mail me the YUV2 patch?

              Desktop Video World still seems to be out, and I have not found another site that posts this patch.

              Thanks for your efforts.

              ------------------
              Harald
              Harald

              Comment


              • #8
                Thanks Chris and Doc for the file

                ------------------
                Harald
                Harald

                Comment


                • #9
                  I read on one of the Matrox announcement forums that they were/are hoping to get the next Marvel G400 drivers out by the end of May 2001. I, for one, am praying that they meet (if not exceed) expectations.

                  Comment

                  Working...
                  X