VirtualDub2 Colourspace

[wcndave2]

I had an AVI capture via Amarectv from VHS, which I ran through avisynth+ via avspmod.

The pixelformat section i left as default, and it came out as Matrix coefficients: BT.470 System B/G, which I believe is correct

My second tape came out as 709.

So i put the original tape's capture in and it also now shows as 709 in the UI.

Question is, from YUV422 source, to YUV420 output, does the pixel format's source/actual output, colour space="no change" actually do anything?
and does it actually convert if you pick something different to source, or does it just apply the tag?

And why does it think my source is now 709 and not 601?

If you need more information, happy to provide!

Thanks, Dave

[Sharc]

I had an AVI capture via Amarectv from VHS, which I ran through avisynth+ via avspmod.

The pixelformat section i left as default, and it came out as Matrix coefficients: BT.470 System B/G, which I believe is correct

Yes, very most likely correct.

My second tape came out as 709.

What does "came out as 709" exactly mean? Where did you get this value from (Tool?). What was 709, the Color Primaries and/or Transfer Characteristic and/or Matrix coefficients? Did you resize your video? Did you apply a conversion in your workflow (AviSynth script, Vdub)?

So i put the original tape's capture in and it also now shows as 709 in the UI.

Which "original" tape? Which UI? Can you post a MediaInfo report?

Question is, from YUV422 source, to YUV420 output, does the pixel format's source/actual output, colour space="no change" actually do anything?

It shouldn't.

and does it actually convert if you pick something different to source, or does it just apply the tag?

Pick from where? Depends what you are doing and at which stage of the processs/workflow.

And why does it think my source is now 709 and not 601?

If nothing is explicitely specified the colorspace is usually by default assumed as 601 for vertical resolutions <720 pixels, and as 709 for vertical resolutions >=720 pixels.
But flags can also be wrong or can be set wrongly by the user/tools. Some tools also allow to change the defaults.

Maybe post a MediaInfo report of your files and your Avisynth script.

[wcndave2]

Sorry, let me be more clear, I have about 100 files open now with different settings, plus a load of raw frames to compare chroma etc.. so I was a bit vague!

In my avs script, i open the AVI capture, and then -run some things on it- and then

src = src.Spline64Resize(1440, 1080)
src.ConvertToYV12()

When I opened this in vdub2, and selected compression, I chose x253 8 bit
Then under configure, set the output to YUV420
Then under pixel format, under the YCbCr properties, I set both to "No change"

The mp4 that was produced had this under mediainfo: Matrix coefficients : BT.470 System B/G
To me, this is what I was expecting, as the source should be 601


I then did the same exact thing with tape 2, and the value read: BT.709
I checked in the pixel format settings in vdub and it was still no change, however the compression settings said: YUYV-709 -> YUYV420-709

So I went back and loaded the avs script with the first tape again, and it was now also saying: YUYV-709 -> YUYV420-709
I have been unable to re-produce the events of the first render...

In any case, some experimentation seems to suggest that if (as you said) the file is > 720px it will come up as 709, however the file is actually 601.

If I set it to 601, it says it will convert. However if it tries to convert 601 pixels that it thinks are 709 to 601, it's going to do the wrong thing I would think....

So what settings should I use to save a 601 file which is 1080px out as a 601 (BT.470 System B/G) file?

Do you still need a mediainfo capture? and for which file?

[CaptureCraft]

Your original SD file should be 601, after converting to HD it should be 709.

[wcndave2]

Your original SD file should be 601, after converting to HD it should be 709.

Well, it seems to me (and I could well be wrong), that if a file has colour encoding data 601, and one just upscales the image, that the data is still in 601 space.

If one then just renders out with that new tag, it's reported as having a different colour space than what it actually has...

Does that make sense?

[Sharc]

Just guessing: Your captured format of the 2 tapes may not be exactly the same. Check with MediaInfo. Then set in Vdub the Video->Decode Format ... correctly.
I have to leave now. Someone else may chime in.

P.S. If your original source is SD 601, interlaced YUV 4:2:2, limited range (as it should be for a correctly captured VHS) you have 2 options for upscaling:
- Upscale without colorspace conversion and flag it as 601 in the hope the player respects the flag
- Upscale and convert it to 709 (and flag it as 709). This is the safer method as most players would by default assume 709 even when the flag is missing.

[CaptureCraft]

A proper upscale process should convert the colours too.

[Sharc]

A proper upscale process should convert the colours too.

Sure, just set the Vdub settings to "proper"
I do all this in Avisynth, so someone more familiar with Vdub may help.

P.S. and deinterlace before upscaling (or use an interlace-aware upscaler)

[wcndave2]

A proper upscale process should convert the colours too.

Sure, just set the Vdub settings to "proper"
I do all this in Avisynth, so someone more familiar with Vdub may help.

The upscale is in avisynth,

src = src.Spline64Resize(1440, 1080)
src.ConvertToYV12()

are you saying that should convert the colour space too?

[Sharc]

yes, it is recommended to do it explicitly and flag it correctly to be on the safe side
also deinterlace before upscaling
and put the YV12 conversion at the end of the script

sorry I have to leave now. Maybe someone gives you the script

(Edit: And why do people always want to upscale and inherit problems? Leave as is an let the TV do the deinterlacing and upscaling. TV players usually do a pretty good job).

[wcndave2]

(Edit: And why do people always want to upscale and inherit problems? Leave as is an let the TV do the deinterlacing and upscaling. TV players usually do a pretty good job).

The thinking behind this was covered a bit in my other thread.

Any random device, that's upscaling "on the fly", is unlikely to do as good a job as avsynth which can take it's time and think about it.
Also the upscaling "process" can't be controlled, whereas in avsynth I can determine sharpening, noise removal etc.. and know exactly what the end product is going to look like.

It could well be that my reasoning is flawed of course!

[_Al_]

Upscaling makes files about 3x bigger, as oppose original lower resolution, also to mention. But that might not be an issue today.

[lollo]

Any random device, that's upscaling "on the fly", is unlikely to do as good a job as avsynth which can take it's time and think about it.
Also the upscaling "process" can't be controlled, whereas in avsynth I can determine sharpening, noise removal etc.. and know exactly what the end product is going to look like.

Upscale is not deinterlacing, and modern TVs do it quite well; for SD material generally there is no need to do it in AviSynth.

Sharpening, noise removal, etc.. are done on original capture prior to upscale (and not in that order), with few exceptions.

[wcndave2]

Any random device, that's upscaling "on the fly", is unlikely to do as good a job as avsynth which can take it's time and think about it.
Also the upscaling "process" can't be controlled, whereas in avsynth I can determine sharpening, noise removal etc.. and know exactly what the end product is going to look like.

Upscale is not deinterlacing, and modern TVs do it quite well; for SD material generally there is no need to do it in AviSynth.

Sharpening, noise removal, etc.. are done on original capture prior to upscale (and not in that order), with few exceptions.

I assume you mean the upscale.

Yes, most TVs do it fairly well, however you don't know what the end device might be.

In any case, even doing: src.ConvertToYV12(matrix="Rec601")

vdub still just sets the colourspace as 709, and if you set it back to 601 it thinks it needs to convert it - so I have given that up as a bad deal and sticking to keeping the video at 576 for now.

Cheers!

[lollo]

I assume you mean the upscale.

Did I not say that?

Yes, most TVs do it fairly well, however you don't know what the end device might be.

You do not know the native resolution of the unknown end device as well.

In any case, even doing: src.ConvertToYV12(matrix="Rec601")

vdub still just sets the colourspace as 709, and if you set it back to 601 it thinks it needs to convert it - so I have given that up as a bad deal and sticking to keeping the video at 576 for now.

Not sure what you mean here, mixing AviSynth commands and VirtualDub processing. ConvertToYV12 is the final AviSynth step prior to encoding to x264 (just for a larger compatibility), and in a proper flow there is no need to specify the color matrix inside it.

Cheers!

[wcndave2]

You do not know the native resolution of the unknown end device as well.

Sure, but everything will have to upscale 576. Most things will either be ready for 1080 or be able to upscale better when there's less information to interpolate... but doesn't matter, sticking to original res now anyway.

In any case, even doing: src.ConvertToYV12(matrix="Rec601")
vdub still just sets the colourspace as 709, and if you set it back to 601 it thinks it needs to convert it - so I have given that up as a bad deal and sticking to keeping the video at 576 for now.

Not sure what you mean here, mixing AviSynth commands and VirtualDub processing. ConvertToYV12 is the final AviSynth step prior to encoding to x264 (just for a larger compatibility), and in a proper flow there is no need to specify the color matrix inside it.
Cheers!

Right, but when you tell vdub to "do nothing", it assumes the data is rec709 and writes it out like that.

I did a load of tests on a single frame and then using a raw capture tested/compared the luma and chroma planes across different vdub settings and there was always some manipulation going on.

I guess I could use something other than vdub, however I want it to be fairly use friendly...

With the source not upscaled, vdub does no pixel conversion in this regard, so it's not an issue.

I went all the way up the hill, decided the view was not very good and came all the way back down again... such is life.

grazie e ciao!

[lollo]

You do not need a VirtualDub rendering. Its filters are lower quality than AviSynth (one/two exceptions). You can feed ffmpeg directly with the AviSynth script:

ffmpeg.exe -i <input_file.avs> -c:v libx264 -crf 17 -preset slow -aspect 4:3 -c:a aac -b:a 128k <output_file>.mp4

Prego, ciao!