Sony YUV codec

[Ron German]

I`m trying to figure out what should be the best codec choice within Vegas (9, 10) to render a timeline to a file that is going to be transcoded to a HDCAM tape.

Regarding this subject, I wonder why (what kind of projects) should I render to Sony YUV and Sony 10bits YUV codecs - I didn`t find the answer in Vegas 10 manual.

Thanks

[Dustin Moore]

I did some research awhile back with Vegas 9.0 comparing the Sony YUV
codec(s) and other lossless YUV codecs like HuffyUV and Lagarith and studying
the final output files with a YUV native waveform monitor.

I believe that when you use the Sony YUV codec you are guaranteed that
Vegas will be converting RGB to YUV using it's internal RGB->YUV conversion
routine. One of the advantages of this is that if you have YUV input files like
DV or MPEG2, the rounding errors that occur due to
YUV->RGB->edit->RGB->YUV
are minimized since the conversion algorithms are "matched" in some sense.
The final video is slightly superior from the standpoint of a pixel peeper that
analyzes histogram distributions and rounding errors.

I also found that Sony YUV 10 bit was slightly smoother and nicer than the
regular 8 bit version but if you don't have 10 bit output it isn't worth the trouble.

If you use other YUV codecs like HuffyUV or Lagarith, Vegas always feeds
RGB to those codecs and it is up to those codecs to internal convert
RGB->YUV. Since this algorithm is not matched to the YUV->RGB conversion
algorithm, a slight amount of rounding error is introduced to the final output.

In Vegas 9.0, the cineform codec (I think) was in the same boat as HuffyUV so
a slight amount of rounding error was introduced. In Vegas 10.0 I see that Sony
has completely customized the cineform writing functionality so I bet that it is using
the optimal conversion strategy.

To answer your question, if you can write SonyYUV to hdcam without doing a
color conversion then SonyYUV is what you want.

If you are feeding the hdcam deck with a blackmagic card you might need to convert
the SonyYUV to the blackmagic lossless codec with a lossless transcode. I think
the blackmagic utility can do this or virtualdub can.

[Ron German]

Thank you very much Dustin.
It`s the first time I will (probably) do a HDCAM copy so I don`t kow if I can write SonyYUV to hdcam without doing a color conversion, becouse I haven`t argued the finishing house about it - I know they are used to convert with Aple`s PRORES.
So I wonder if Sony YUV would be compatible with other editing systems beside Vegas to do the convertion.
The codec I have my project rendered / masterized at this moment is (Quicktime) MJPEGA and I gess there would be a better codec to make the master to convert to HDCAM, what seems to be Sony YUV.
Thank you again

[Dustin Moore]

An avi file rendered with the SonyYUV 8bit codec is basically just raw uncompressed
YUV pixels. Rather than uncompressed RGB it is uncompressed UYVY. It is slightly
smaller than uncompressed RGB but it is still uncompressed so you need hard disk space.

It is a much cleaner codec that MJPEG but your mileage may vary. The minor quality
increase from avoiding a compression generation might not be noticeable.

[Ron German]

Thank you Dustin.
Regards

[Mike Kujbida]

Ron, since the post house is FCP, you might want to consider the free Avid DNxHD codec.
Both of you you will have to have it installed on your system.
Avid - Avid QuickTime Codecs 2.3.4 Specifications

[Ron German]

Thank you Mike.
After I instal the free Avid DNxHD codec in my system, how will I find it in Vegas 10D to do the render? Will I find it in "Save as Type: Quick time 7 (*.mov)?

[Mike Kujbida]

That's correct Ron.
After doing that, click the Custom button, in the Video tab, choose "Avid DNxHD codec" in the Video format dropdown box, click Configure and then choose from the dizzying range of options.
I don't use the codec myself but I know some folks on here do as well as users in the Sony Vegas forum.
Hopefully someone can advise you on the right choices to make.

[Gene Gajewski]

Originally Posted by Dustin Moore

I did some research awhile back with Vegas 9.0 comparing the Sony YUV
codec(s) and other lossless YUV codecs like HuffyUV and Lagarith and studying
the final output files with a YUV native waveform monitor..

Seeing as Lagarith supports RGB (as well as RGBa), Vegas is claimed to use RGB internally, and colorspace conversions are claimed to be a 'bad thing'...

Why would anybody bother to even consider using Lagarith's YUV colorspace?

RGB works fine, and RGBa is the way to go if you're doing any CGI compositing.

[Phil Lee]

Hi

It's very confusing all this, my current work flow is:

• H264 HD footage (from Panasonic camera) on the time line
• Output using Lagarith RGB - thoughts here are internally Sony Vegas will decompress to RGB to use internally, so outputting RGB has avoided Sony Vegas converting that RGB back to something else
• Using AVISynth convert the RGB to YV12 to feed into the X264 encoder to get the final output to H264 for Blu-ray

The slight snag with the above method, and I'm not sure exactly why, but output to Lagarith from Sony Vegas has a different colour range with washed out blacks and dull highlights, so in the AVISynth script during the conversion to YV12 I tell it to use the PC.709 colour matrix which corrects this. Outputting YV12 direct from Sony Vegas is the same, washed out so I would still need a conversion in the AVISynth script.

So now comments here about the Sony YUV codec got me thinking maybe that would be a better option. When I use the Sony YUV codec, there is no colour space issues, i.e. blacks are blacks, why is that? The snag though with the Sony YUV codec is I can't get this read with AVISynth correctly, it can be opened using 'Rawsource' but I don't know the correct parameters to pass for it to work correctly. Also wouldn't this still mean a conversion from YUV to YV12 is needed for X264. Maybe this is better than the RGB conversion to YV12?

Having a play around I've since discovered I can output directly to YV12 (or RGB) to the Lagarith codec without colour space issues so blacks are black, by selecting under Project properties the Pixel format 32-bit floating point (full range). What is this changing and should I do this? Would this be a better option, use full range, output as YV12 to Lagarith so this would mean Sony Vegas is doing the colour space conversion and sending YV12 to Lagarith, or is Vegas still sending RGB and it is just the codec doing the conversion?

I think my main concern is with the colour space issues (0-255, 16-235) and if converting between them is potentially losing colour information, and is using the 32-bit floating point full range option a good idea when outputting from Sony Vegas, it certainly seems to correct the issue with regard to the shifting black levels.

Regards

Phil

[Phil Lee]

Hi

Did some tests:

Sony Vegas to Lagarith YV12 then to X264 shows a very slight shift in colours compared to the original.
Sony Vegas to Lagarith RGB then via AVISynth to YV12 to X264, absolutely no shift in colours, identical to the original.

It seems to make no difference if I render for 32bit 'video range' or 'full range', except for video range I need to ask AVISynth to convert to YV12 using the PC.709 matrix which puts the levels back correctly, the final results are identical with nothing seemingly getting lost with the stretch then compression of the colour space.

Think I will stick with this workflow of Lagarith RGB out unless anyone has any other insight.

Regards

Phil

[Dustin Moore]

Originally Posted by Gene Gajewski

Seeing as Lagarith supports RGB (as well as RGBa), Vegas is claimed to use RGB internally, and colorspace conversions are claimed to be a 'bad thing'...

Why would anybody bother to even consider using Lagarith's YUV colorspace?

Well, all modern distribution codecs used on the web, DVD and Blueray are YUV. At some point you
will have to convert to YUV and when you do, you may want to most accurate conversion
possible if you are trying to squeak every last ounce of color rendition quality out of your
system.

IF Vegas could render YUV straight into Lagarith, then Lagarith would be a great lossless YUV
codec that you could then feed into a high end MPEG-2 encoder like Cineform or whatever.

Originally Posted by Gene Gajewski

RGB works fine, and RGBa is the way to go if you're doing any CGI compositing.

RGB works but just because it works doesn't mean it works great. If you have CGI that started
as RGB then you may as well output in RGB from Vegas. If you have source material that
started as YUV though, you might want to output it in YUV if your next step is encoding.

If you are not going straight to a distribution codec and you are going to futz with it in After
Effects (which works RGB internally) then you may as well rendering everything out as RGB.
You might want to render it out as 10 bit RGB to preserve a bit more range so that later on
when you RGB->YUV you get a nicer/smoother result.

At any rate, we're splitting hairs here. Using that "bad" RGB->YUV conversion is usually
un-noticable unless you do a couple of generations or if you have a really good eye or if
you look at the final result on a waveform monitor.

[Dustin Moore]

Originally Posted by Phil Lee

Hi

Did some tests:

Sony Vegas to Lagarith YV12 then to X264 shows a very slight shift in colours compared to the original.

Yes, Vegas is feeding RGB to Lagarith. Lagarith internally converts RGB to YV12 using an ok but
sub-optimal conversion.

Originally Posted by Phil Lee

Sony Vegas to Lagarith RGB then via AVISynth to YV12 to X264, absolutely no shift in colours, identical to the original.

Avisynth has a higher quality conversion than the Lagarith workflow. I would feel ok using this
workflow on a project that I wanted to get good quality out of. If you are comfortable with this
workflow, I would recommend doing it. It results in little rounding error and it is much better
than the first workflow.

If you want almost no rounding error you need to use the SonyYUV output and get a bigger
hard drive to deal with all the uncompressed pixels.

Originally Posted by Phil Lee

The snag though with the Sony YUV codec is I can't get this read with AVISynth correctly, it can be opened using 'Rawsource' but I don't know the correct parameters to pass for it to work correctly.

Yes, Avisynth can not open UYVY which is what SonyYUV is. It can open YVUY (otherwise
known as YUY2) so what you need to do is re-order the bytes. I usually use Virtualdub to do
a fast-recompress between the SonyYUV file and Lagarith running in YUY2 mode explicitly. In
this recompresion, the bytes are re-ordered by virtualdub and passed to Lagarith in YUY2 format
and Lagarith compresses the file with no colorspace conversion.

When you open the Lagarith file in Avisynth, it will pull YUY2/YVUY from the lagarith file and
then you can do your YV12.

Originally Posted by Phil Lee

Also wouldn't this still mean a conversion from YUV to YV12 is needed for X264.

The conversion from YUY2 to YV12 is basically just downsampling the chroma resolution. It is not a
conversion from one way representing a color numerically into another that can have rounding
errors due to finite precision. That is not to say it is trivial. You do need to tell Avisynth to make
the YV12 interlaced or progressive since that changes how the YV12 is calculated.

Originally Posted by Phil Lee

Maybe this is better than the RGB conversion to YV12?

If you use a waveform monitor, it is very slightly, infinitesimally better in my opinion. It might
not be worth the effort though.

[Gene Gajewski]

Well, I can definitely agree on splitting hairs as most of this thread...

But, I disagree on the need to preserve a YUV colorspace, in light of the fact that Vegas composites internally using RGB.

The major problem with codecs isn't so much theri color space, but what happens with levels - whether or not they support 16-235 or 0-255 input and how they handle output also. I.e. Sony YUV doesn't give a hoot about levels, but Cineform does.

[Phil Lee]

Hi

Originally Posted by Dustin Moore

Yes, Vegas is feeding RGB to Lagarith. Lagarith internally converts RGB to YV12 using an ok but
sub-optimal conversion.



Avisynth has a higher quality conversion than the Lagarith workflow. I would feel ok using this
workflow on a project that I wanted to get good quality out of. If you are comfortable with this
workflow, I would recommend doing it. It results in little rounding error and it is much better
than the first workflow.

If you want almost no rounding error you need to use the SonyYUV output and get a bigger
hard drive to deal with all the uncompressed pixels.



Yes, Avisynth can not open UYVY which is what SonyYUV is. It can open YVUY (otherwise
known as YUY2) so what you need to do is re-order the bytes. I usually use Virtualdub to do
a fast-recompress between the SonyYUV file and Lagarith running in YUY2 mode explicitly. In
this recompresion, the bytes are re-ordered by virtualdub and passed to Lagarith in YUY2 format
and Lagarith compresses the file with no colorspace conversion.

When you open the Lagarith file in Avisynth, it will pull YUY2/YVUY from the lagarith file and
then you can do your YV12.



The conversion from YUY2 to YV12 is basically just downsampling the chroma resolution. It is not a
conversion from one way representing a color numerically into another that can have rounding
errors due to finite precision. That is not to say it is trivial. You do need to tell Avisynth to make
the YV12 interlaced or progressive since that changes how the YV12 is calculated.



If you use a waveform monitor, it is very slightly, infinitesimally better in my opinion. It might
not be worth the effort though.

Thanks for your reply, very helpful. I think I will stick with output to Lagarith RGB then as this has less steps associated with it, and by the sounds of it, any tiny improvement with the Sony YUV is probably not something I'll notice.

Regards

Phil