RGB or YUV? Going from SDI to MPEG-2

[sharper]

Hi!

I am going to capture a lot of material from an uncompressed SDI source with a Video Toaster capture card. It's basically VHS material, previously transferred to DigiBeta, which will be authored on DVD so the quality of the signal is crucial.

I'm planning on restoring the video using slight denoising and chroma shift in Virtual Dub, but the switch between YUV and RGB concerns me: What difference will it make on the final MPEG-2 stream? Isn't MPEG-2 YUV, so it will go from YUV to RGB and then back again during transcoding?

Like: Is it possible to open a yuv spaced avi in vdub, filter it, and save as an yuv avi file that e.g Adobe Encore can transcode?

Grateful for all wildly hypothetic answers =)

/axel

[Wilbert]

What difference will it make on the final MPEG-2 stream?

It will be a bit slower if you run filters.

Isn't MPEG-2 YUV

Yes, it's YV12.

Like: Is it possible to open a yuv spaced avi in vdub, filter it, and save as an yuv avi file that e.g Adobe Encore can transcode?

Not without an internal conversion to RGB. VDub's filters require RGB.

If you want to stay in YUV space you need to use AviSynth.

[Josef Kneht]

What difference will it make on the final MPEG-2 stream? Isn't MPEG-2 YUV, so it will go from YUV to RGB and then back again during transcoding?

In reality, depending on a lavel and profile, MPEG2 video stream can be either YUV 4:2:2 (YUY2) or YUV 4:2:0 (YV12) or even YUV 4:4:4.

The most widespread case is MPEG2 YUV 4:2:0.
Neverless almost all the software MPEG2 encoders support various formats as an input (RGB32,RGB24,YV12,YUY2, etc.). This means an encoder performs a necessary conversion by itself .

[guns1inger]

But do you trust the encoder to convert without reducing the quality ?

If you can stick with YUV using avisynth, you should do so.

[Josef Kneht]

But do you trust the encoder to convert without reducing the quality ?

If you can stick with YUV using avisynth, you should do so.

A conversion RGB to YUV can be losless only to YUV4:4:4 format.
As I already mentioned a most widespread case is MPEG2 4:2:0.

This means that an encoder will process a RGB to YUV conversion in any event.

In YV12 format for each four pixels there are four luminance values (Y) and one chrominance value(U and V).

[Wilbert]

In reality, depending on a lavel and profile, MPEG2 video stream can be either YUV 4:2:2 (YUY2) or YUV 4:2:0 (YV12) or even YUV 4:4:4.

True. But he's encoding to dvd. So, YV12 it shall be

Btw, there are mpeg encoders like QuEnc and HC (see doom9) which require YV12 input (encoders like TMPGEnc, CCE, MainConcept require RGB or YUY2).

[sharper]

Okay, I'll try feeding the .AVS file directly into Adobe Encore and dodge vdub (for once )

Thanks a lot for the answers!

[edDV]

VHS to DigiBeta. That is like transporting your dog in a first class seat. It's still a dog when it gets there.

[BJ_M]

and sdi from d-beta is still a compressed format btw ..

but vhs to d-beta is a waste of time and resources ...

[edDV]

and sdi from d-beta is still a compressed format btw ..

but vhs to d-beta is a waste of time and resources ...

It would be compressed 2:1 to d-beta tape and then uncompressed to SDI 4:2:2 (SMPTE 259M) on playback.

[vhelp]

Evening everyone.

>> In YV12 format for each four pixels there are four luminance values
>> (Y) and one chrominance value(U and V).

But that is for NTSC DV 411 layout, where each component U/V are processed
per group of 4 luma pixels, (each U and V share those 4 luma pixels)

Ok. I realize now.. you were probably refering to PAL's DV 420 format.

(the YV12 fourCC belongs to the 420 sampling group, and I think that
you used it in the wrong form here - I think)

.
.

>> If you can stick with YUV using avisynth, you should do so.

I agree.. if you want to keep the lossless 'ness, stay in YUV space,
until your MPEG encoder processes it to its last YUV stage. But be
sure that you know your MPEG encoder, and how it handles color spaces
and codecs too

Regarding RGB ...

What you have to watch out for is wheather or not your MPEG encoder
does a conversion behind the seems. Case in point follows..

In the case of frameserving a YUV source to TMPGenc, the YUV source
will be converted to RGB inside TMPGenc through whatever the codec
depending on the signature fourCC, (not to mention also, that a given
codec(s) installed on one's pc may share the same fourCC signature as
another codec elsewhere on that given system, for the YUV->RGB) and
TMPG's final RGB->YUV420 color space.

For instance, below is a short list of some of the common yuv codecs.
Some share the same method of decoding as the others do:

** msyuv.dll    - 422 - uyvy   -   yvyu  yuy2 
** ir41_32.ax   - 422 - uyvy   -    -      -     -  iv41*
** msh263.drv   - 422 -   -    -    -    yuy2
.
** iyvu9_32.dll - 420 -   -    -    -      -   yvu9
** msh263.drv   - 420 -   -  i420   -      -   yvu9
** atiyuv12.dll - 420 -   -    -    -      -     -    -   yv12
** iyuv_32.dll  - 420 -   -    -    -      -     -    -     -  iyuv*

* iv41 [same as uyvy]
* iyuv [same as i420]

(notice how several codecs share the same fourCC signatures..
i.e., yuy2; uyvy; yvu9; etc)

Depending on your systems "highest priority" level setting for each codec
installed or registered to each fourCC signature, you may be stuck with a
given codec responsible for the decoding (and possible issues that *might*
be present)

(There have been reports / findings that certain codecs do not perform to
satisfaction. And because of this, it was suggested that removal of such
codec(s) would/should solve the matter, though in certain situations, such
attempts may not prove successful)

The above sounds pretty subjective, but you can test this out for yourself
with the sw tool, vcswap.exe ..and draw your own conclusions.

Cheers,
-vhelp 3669

[sharper]

vhelp: Some truly interesting facts there, I think I'm with you and have this one question left: Is the encoding in Adobe Encore satisfactory when going from YUY2 to YUV420? Any other encoder to recommend? Result will be high bitrate to preserve as much as possible, perhaps even over 7mbit.

[sharper]

and sdi from d-beta is still a compressed format btw ..

but vhs to d-beta is a waste of time and resources ...

Granted, but I had some terrible results using the Como DV bridge. The mjpeg-type compression couldn't handle the noisy vhs signal so i figured a higher bandwidth tape would leave me more data to clean in the pc.

But.... stop me if you think I'm recording 600gb of uncompressed video in vein here...

[edDV]

..

But.... stop me if you think I'm recording 600gb of uncompressed video in vein here...

mild overkill?

[Wilbert]

@vhelp,

yvu9 is nine bit, ie 4.1.0. Thus chroma is shared between 4x4 pixels.

http://www.fourcc.org/fccyuv.htm#Planar%20YUV%20Formats

IV41 is Intel Indeo 4.1, which is just yvu9 (thus 4.1.0).

http://www.nadine.be:3455/d/136

[vhelp]

wilbert.., thank you for that headsup. Though I'm sure I would have
figured it out either way, since I am working inside this process
(is on my next schedule) elsewhere in another topic.. an on-going
project I am involved with, which includes building tools for these
yuv images.

I wasn't planning on adding this format to my tool, but I was planning
on just demonstrating the ability to produce such images in this format
(as well as others) .. (but I was hoping for after I find a 411 viewer
to test my tools compliance with, so that I can post those, which are
long over due anyway - unfornately, this is one area [411] sampling
that AVIsynth is failing me on - I was counting on it) oh well.

Thanks again,

(sorry for the slight OT, guys)

-vhelp 3671

[Wilbert]

4:1:1 is supported in AviSynth v2.60. The first alpha will be released before Xmas (at least i hope; if needed i can send you a pre-alpha build / most filters including ImageSource/ImageWriter are working for 4:1:1 and for other new planar formats like 4:2:2 and 4:4:4). 4:1:0 is not supported.