Losless codec choice

[Tafflad]

I am using a Lossless codec as an intermediate intra-fame codec on Virtual Dub processing
After some posts here, tried out GrassValley Lossless ... but found issues
https://forum.videohelp.com/threads/376896-DeShaker-use?p=2432620#post2432620

So it would make sense to use an alternative codec.

I had intended using Lagarith (as used it previously) ... but as files will be onwards used in Vegas .... was concerned to read in Vegas forums that there are known issues with color shifts on multi-generational use of Lagartith, and its very slow
Suggestions are to use MagicYUV

Is MagicYUV a good choice ? any issues or anomalies to be aware of .............. or should I look at something else ...

This is only intermediate use, files will not be kept - so size is irrelevant.

[pandy]

This one works also https://trac.ffmpeg.org/wiki/Encode/FFV1 - available trough ffdshow .

And if size is not important i would go for huffyuv as lagarith may have some issues and MagicYUV is not open source (in future may be not free).

[aedipuss]

vegas comes with sony yuv. use it if you can, as it's no re-code necessary for anything kept in that format when rendering.

[poisondeathray]

The previous discussions on multigenerational losses are because of vegas (and other programs, not just vegas) that do not handle YUV lossless codecs properly - they treat them as RGB so you get YUV => RGB conversion . But if you used deshaker and export in RGB, then vegas will handle RGB imports from lossless codecs properly (if you consider that RGB export your "source" now). If you export RGB from vegas, there will be no additional losses from compression or from colorspace conversions or anything else

Pandy raises good points about open source nature and availability in the future about certain codecs. Very important issues to discuss for archival and future workflow. But right now, magicyuv does work - in fact it's slightly faster and slightly more compressed than UT Video which was the "king" for decompression speed. But at least UT video has an open source derivatives in ffmpeg, you can compile it yourself, etc... 100 years in the future there will be no problems. magicyuv - uncertain.

FFV1 is very configurable (you can set it inter or intra frame, supports many colorspaces, bit depths, but it's not ideal for usage in vegas - the decoder is very slow even with I-frame configuration)

"Sony YUV" in vegas is v210, which is 10bit 422 . Filesizes are enormous and there will be quality loss because it's subsampled, and colorspace conversion.

[Tafflad]

OK .. it seems I can go ahead with MagicYUV ... its only intermediate so if it ever becomes 'pay for use' no issue for me.
Some test show it is much faster and files considerably smaller.

I have a question related to its use if someone can advise ....
I have files that are being set (by choice) to ColorYUV(levels="PC->TV") to get the range to [16:235]

In VD looked at MagicYUV settings and it gives option to use Rec601 SD or Rec709 HD

Can I leave it set to rec 709 without impacting my 'set levels', or do I need to set to Rec601 to maintain that.

[poisondeathray]

I have files that are being set (by choice) to ColorYUV(levels="PC->TV") to get the range to [16:235]

Describe why you are doing this, and at what point in the workflow. If your Y levels are 16-235 , UV levels 16-240 - BEFORE the RGB conversion - then you won't clip additional data from the RGB conversion. There is no reason for that step in that case. But if you "blindly" apply this conversion to a normal range YUV source, you will compress the range, and everything will look low contrast, flat

In VD looked at MagicYUV settings and it gives option to use Rec601 SD or Rec709 HD

Can I leave it set to rec 709 without impacting my 'set levels', or do I need to set to Rec601 to maintain that.

Leave everything set to auto. It will actually be RGB if you 're exporting from vdub and deshaker. Rec709/601 don't apply when everything is in RGB. It only applies to YUV<=>RGB conversions. It will hand off RGB to vegas , and vegas works in RGB internally as well. Ideally you would export an RGB format too, but most final distribution formats are YUV and 4:2:0 (YV12) . It those steps in between where RGB<=>YUV conversions occur that potentially bad things happen, like levels shifts, color shifts etc.. so you want to keep conversions to minimal

[Tafflad]

"Leave everything set to auto."

There is no Auto stetting ... only option to select Rec.601 or Rec.709.


My workflow ... fair number of DV files captures of PAL vhs tapes 720x576
Deinterlaced and resized:

ConvertToYV12(interlaced=true, matrix="PC.709")
LanczosResize(960,height)
AssumeBFF().QTGMC(Preset="slow", EZDenoise=2.0, NoisePreset="Slow" )
LanczosResize(width,720)
ColorYUV(levels="PC->TV")
# NOTE - this sets to correct levles for youtube
tweak(sat=1.2,coring=false)

saved as Lossless (first time)

then doing Deshaking in VD & some sharpening ... and setting colour space to YV12
Then saved as Lossless (second time)

It this Lossless second time output that I will then be taking into Vegas (along with a bundle of other similarly treated files) ... and ultimately create 720p H264/Mp4 files (using Sony AVC/MVC codec) for Youtube/Vimeo upload.

So just want to get the correct settings on MagicYUV .. and if I need to apply any changes in VD prior to this 2nd save happy to do so.

[poisondeathray]

1) The "ConvertToYV12(interlaced=true, matrix="PC.709")" is unnecessary coming from a PAL DV source. It's already YV12 unless your source filter is returning something different, which would not be ideal. Type info() right after the source filter with everything else commented out to check. Also the "matrix" doesn't apply unless you have a colorspace conversion from RGB

2) I would use QTGMC before upscaling the width (faster to do) . In fact I would consider not upscaling untill the very, very last step. Deshaker will be faster with lower resolution. Your intermediates will be smaller. Vegas will be faster etc...

3) Applying PC->TV blindly will make it more "safe" for the RGB conversion in vdub, but it might be unnecessary depending on your capture setup and potentially make things worse (you probably have to re-adjust levels later on). The more adjustments you make back and forth, the more you degrade the footage

4) There is additional loss from the colorspace to YV12 exporting from vdub/deshaker . The general rule at least for "best practices" is : Once in a certain colorspace, stay there as long as you can. If you're taking the steps/space/time to use lossless intermediates in the first place , you should go full out lossless all the way IMO, at least until the end. So you should be using RGB lossless intermediate (but the filesize will be larger). Another reason is vegas doesn't handle YUV lossless intermediates correctly - they get treated as "computer RGB" in vegas , not "studio RGB". Native camera files like DV, AVHD etc.. those types of YUV get treated as "studio RGB". This can result in levels shifts and color shifts from 709/601 mismatches. With mixed footage , some need studio to RGB filter or vice versa. But RGB input is mapped correctly 100% of the time. No fuss. What you see is what you get, at least up to the vegas stage on the timeline. The various export settings is another matter

You have to double check with some mini tests like colorbars if you're going to use YV12 input. Conversely RGB input (which is the same as the deshaker output) will cause no headaches on import

[Tafflad]

Good information for the future ....Thanks

The sequence of resizing & Deinterlacing I had followed from here:

http://www.bubblevision.com/underwater-video/Vegas-YouTube-Vimeo.htm#null
and the Avisynth steps is sect 3.3



Will look more into this in the future - though for now I am already at the point that all files have been through step 1 & 2 so deinterlacing and deshaking is complete.

Current files are in YUY2 at the end of Deshaker process.
A typical mediainfo for one of them is attached.
I could leave it in YUY2 and not do the change to YV12 .... was only doing that as end file will be in YVY12.

So based on where I am now ... want to save in MagicYUV .... any steps I should take, and do I set Rec.610 (sort of assumed this would be the case)


I also still have the intermediate file from Step1 output (after Deinterlacing) and prior to the DeShaking ........... so could go back a step to there if it improves things

[poisondeathray]

You're going to have to do some mini tests to check your workflow. Just take a sample clip and go end to end. If you get stuck I can help you out but there are too many little steps where something can go wrong.

Since you have "HD" footage now the standard is actually 709 for YUV<=>RGB . Vegas uses 709 as well for most intermediates. But vdub uses 601 for converting to and from RGB by default if you let vdub do the conversion. The colors will be slightly "off" when the wrong matrix is used. What actually did the conversion? So how it got converted from YV12 to RGB and back to YUY2 will affect what you have now. How vegas "reacts" to a YUY2 intermediate or YV12 intermediate is it usually converts to RGB, but sometimes with 709 , sometimes with 601. And then it also handles different export formats , differently. Some get different treatment in terms of levels because it's "expecting" prior a studio RGB conversion

What was the reason for converting canopus lossless to magic yuv ?

[aedipuss]

not sure which one you've used but the sony yuv i use in vegas is 4:2:2 lossless

[poisondeathray]

@aedipuss - UYVY is 8bit422 uncompressed. That is a "lossless" format in terms of compression, but coming from an RGB timeline it's actually lossy because you have subsampled color information (1/2 width 960x1080). There is also a 10bit422 variant v210, which is "less lossy" . You basically need a Raid0 or SSD to get realtime speeds

[LigH.de]

Just one more example: "Ut Codec Suite" is also very versatile and quite efficient for a lossless codec.

[Tafflad]

I don't mind what Lossless codec to use ... just mentioned MagicYUV as guys on Vegas forum advise it works well with Vegas.
I know the exact sequence I followed ..... I will try and map it through with a color bar clip.
Key goal is to get an output file from Vegas of H264/mp4 720p with color l levels in range [16:235]

I asked a Q on youtube support on what colorspace is optimum for them (hopefully one they won't chnage) .. they advise there is no preferred color space but had advice here to set to YV12, hence my 'intent' to change to this ........... but I'll wait to get this right - I'll be back.

[LigH.de]

YUV 4:2:0 (known with the FourCC "YV12") is the most usual chroma subsampling in common and compatible video formats like Main profiles of MPEG1 .. MPEG4 and WMV. Some profiles also support YUV 4:2:2, but such profiles are not as common and compatible as those based on YUV 4:2:0 chroma subsampling.

Chrominance matrix ITU-R BT.601 (Rec601) is common for SD resolutions (up to 704|720 × 480|576); HD resolutions (720p and up) instead prefer the ITU-R BT.709 (Rec709) matrix for conversions between RGB and YUV. But as usual, expect mistakes in any component involved in conversions...

AviSynth knows to avoid unnecessary conversions between YUV and RGB. Many commercial video editing applications don't care in this regard.

[pippas]

AviSynth knows to avoid unnecessary conversions between YUV and RGB. Many commercial video editing applications don't care in this regard.

I think it would be fair to say that for many people who like to use Vdub and/or Avisynth for their video work there is really not a lot of point in using a commercial editor as well. Especiailly , as you say, as they can introduce all sorts of unknowns into the workflow.

I use Avisynth and Vdub exclusively these days. There's nothing that pairing can't do for anything I need - cuts - crops - fades - overlays - zooms - dissolves - titles -multicam - conversions......and so on

With the machine I'm using now I haven't even bothered with an installation of a commercial editor....

[LigH.de]

An important advantage of recent VirtualDub versions is that basic handling of YUV was introduced, so it is able to do conversions from YUV based video to RGB for display only, without harming the conversion. And even some of the basic VirtualDub filters now work in YUV space (it is not always necessary to forcefully convert to RGB anymore, like in earlier versions, only if you want to apply old VDub filters designed for RGB only – but better try to filter in AviSynth and only display and convert in VDub, if possible).

[SameSelf]

I think it would be fair to say that for many people who like to use Vdub and/or Avisynth for their video work there is really not a lot of point in using a commercial editor as well. Especiailly , as you say, as they can introduce all sorts of unknowns into the workflow.

I use Avisynth and Vdub exclusively these days. There's nothing that pairing can't do for anything I need - cuts - crops - fades - overlays - zooms - dissolves - titles -multicam - conversions......and so on

With the machine I'm using now I haven't even bothered with an installation of a commercial editor....

I have never considered using vdub as an NLE. So a few questions at the risk of hijacking this thread:

1. How is vdub at keyframing? I use that extensively. For example, I put together a lot of custom Ken Burns footage that I keyframe myself versus slapping some auto effect on it.
2. Since most people are idiots and shoot with their phones in portrait vs landscape, I often emulate the background blur versus black bars that news programs use for similar footage. Can vdub do that easily? It is a cinch in PP.
3. How is vdub in handling 10-bit workflows? I shoot almost all my footage in ProRes HQ 422 which is 10-bit and I try hard to stay 10-bit until the final encode. I find Avisynth is somewhat painful because of the limited/clumsy 10-bit support. However, I don't worry too much because I only use Avisynth for frameserving to an encoder like x264, and I need to dither down to 8 bit for delivery anyway. Plus I am thinking hard about upgrading to a 10-bit monitor now that I have a Quadro. Does vdub support that?
4. How is vdub at grading and secondary color correction? Most of my experience is using Synthetic Aperture in AE, but recently I have started using BMD Resolve, which is free and knock your socks off powerful. I am forced to shoot in flat cinema modes because I shoot live events and have no control over lighting.
5. Finally, the multicam capability is surprising, that is probably the biggest reason I use commercial NLEs. I would like to see a demo of that in vdub.

Thanks.

[pippas]

I should perhaps have highlighted the phrase in my post that mentions that the pairing does everything I need to do personally...... and that clearly wouldn't cover some of the advanced features you've described.

The fact that Resolve is now a freebie is surely the real game changer for the kind of thing you're looking to do, without the need to buy expensive software?

As an amateur, I've only played around the edges of most of the things you're asking, so it would need a more expert head than mine to offer decent advice on how suitable Vdub and AviSynth are for some of these more advanced tasks.

For 'Ken Burns' type of footage I use an old version of Canopus Imaginate, and export from that as Grass Valley HQX (so with an Alpha channel). That can also be useful for animating simple graphics. I made this (very simple) 'logo' thing using that and Avisynth:

https://www.youtube.com/watch?v=5d7LUP9PUG4


For my simple experiments into animation I've been trying out CSS3 and HTML as I mentioned in this thread:

https://forum.videohelp.com/threads/375981-Creating-animated-titles-with-HTML5-and-CSS3

All done with free HTML editors, and the video with Vdub

Regarding Multicam, I wanted to try out a simple music video, and made several versions of a short keyboard piece which I put together using Avisynth into a sort of multicam sequence. I couldn't think of another way of doing it, without shelling out a shed load of cash for suitable real multicam software!
See here: https://www.youtube.com/watch?v=6N48kkdR-bs ( probably not your kind of music.. sorry about that!)

So I think I've probably over-simplified when suggesting Avisynth and Vdub can do everything....I'm sure some of the more advanced editing features might prove to be really difficult to do... although I suspect most are possible .. at least in theory!

As I say, it can do most of what I need personally... but then I'm not pretending to be an advanced operator in any way!


As you mentioned, this is a bit of thread hi-jack, so apologies to the OP for that .... back to lossless codecs...

[Tafflad]

> so apologies to the OP for that

No problem ... all helps my understanding .. I'll admit I may be at odds with the crowd .... I like using Vegas, I find it intuitive cuts fades transitions, effects are immediate with simple adjustments.

I do fully accept VD/Avisynth have their benefits and a lot of powerful features and I do use them for particular tasks.

It is pretty hard going though .. so glad you guys are happy to help.

[SameSelf]

@pippas, very nice logo animation. I have been contemplating something similar to tag my productions with. Hopefully soon. As for the music video, well done as well. Multicam work can either be frustratingly difficult or smooth as silk. It is all a function of the NLE used and how often you have to do it. During football season I need to crank out video fairly quickly on a weekly basis, so I need a tool that is powerful. Resolve's multicam capabilities are excellent.

https://www.youtube.com/watch?v=4T0hz5Upk7o

I strongly suggest you give it a try. My main complaint about Resolve is that it doesn't support many codecs while Avisynth/vdub and PP can handle just about anything you throw at them. But, when I am doing a multicam edit and I need to give all the cams a consistent look, it beats the socks off PP. I am getting ready to start a new project where I hope to work exclusively in Resolve. I will have a much better feel for its capabilities after that. I am hoping it is good enough to ditch Adobe since they left me stranded by switching to a subscription model versus a perpetual license model.

[SameSelf]

"Leave everything set to auto."

There is no Auto stetting ... only option to select Rec.601 or Rec.709.


My workflow ... fair number of DV files captures of PAL vhs tapes 720x576
Deinterlaced and resized:

ConvertToYV12(interlaced=true, matrix="PC.709")
LanczosResize(960,height)
AssumeBFF().QTGMC(Preset="slow", EZDenoise=2.0, NoisePreset="Slow" )
LanczosResize(width,720)
ColorYUV(levels="PC->TV")
# NOTE - this sets to correct levles for youtube
tweak(sat=1.2,coring=false)

saved as Lossless (first time)

then doing Deshaking in VD & some sharpening ... and setting colour space to YV12
Then saved as Lossless (second time)

It this Lossless second time output that I will then be taking into Vegas (along with a bundle of other similarly treated files) ... and ultimately create 720p H264/Mp4 files (using Sony AVC/MVC codec) for Youtube/Vimeo upload.

So just want to get the correct settings on MagicYUV .. and if I need to apply any changes in VD prior to this 2nd save happy to do so.

I have been thinking a little about your workflow and pdr's comments. I agree with what he said. If were you, I would only deinterlace with QTGMC (that is my preferred deinterlacer as well) and bring that into Vegas to build your timelines. Then once everything is completed in Vegas, use Debugmode Frameserver to export your video out of Vegas to an Avisynth script that resizes and does whatever else you want before sending it off to x264 for encoding. For example, you might change your mind about how to resize, so why commit this soon?

Finding the optimal workflow is always the hardest part it seems.

[Tafflad]

For the future I will certainly consider changing approach, not familiar with Debugmode Frameserver to get output of Vegas ... will have to look into that.
At this moment in time I have processed the original DV captures through the QTGMC & resizing, and through DeShaking. So they are at that point now, a lot of Hours of effort already to get there.

[SameSelf]

This website has a VERY good walk through for Vegas users (though the same techniques work just as well under Adobe).

http://www.bubblevision.com/underwater-video/Vegas-YouTube-Vimeo.htm

[Tafflad]

This website has a VERY good walk through for Vegas users (though the same techniques work just as well under Adobe).

http://www.bubblevision.com/underwater-video/Vegas-YouTube-Vimeo.htm

Yep- good write up, that is the link I posted in post #9 ... and it is there I got the Deinterlace script that I posted in post #7

The difference for me is that I am not starting in Vegas ... I am starting with VHS footage captured to a DV file.

I just checked along each step of what I have been doing:
Original capture format, DV, 720 x 576, PAL 4:2:0 interlaced
Step 1 – VD - deinterlace, Grass Valley Lossless, 960x720 YUY2
Step 2 – VD - deshake, Grass Valley Lossless, 960 x 720, YUY2
Step 3 - VD - not yet done (will sharpen & colour adjust) ???
Step 4 – load several files into Vegas – on completion - Render out as 720 Progressive - Tested and the end result is in 4.2.0 (using SonyAVC/MVC template)


So I'm back to my question ... for step 3 above after I have completed VD tasks .. what format compression do I save in, I had intended using Grass Valley Lossles, but as mentioned been advised against it.
I could use MagicYUV ........... if so do I set it to Rec601 SD or Rec709 HD ... I know the comment was leave everything set to auto ... but there is no 'auto' setting for color matrix. assuming it should be Rec601 but wanted to check.
Here is pic of the settings:


[Attachment 35764 - Click to enlarge]

[poisondeathray]

You're supposed to use 709 for HD. But the setting is irrelevant coming from canpous YUY2 - there is no matrix used because your output is going to be YUY2 and your input is YUY2. It only applies for YUV<=>RGB conversions. Mouse over the option and the tool tip pretty much says the same thing. Unlike UTVideo, Magic YUV does not have a separate fourcc distinguishing 601 or 709 . But even in the case of UT Video, most of the time it's ignored anyways - the host application just does whatever the hell it wants to do (sometimes they use 601, sometimes 709, sometimes something else). So again, the recommendation is to do a quick test for colors because vegas doesn't treat lossless YUV codecs as YUV

Also, when upscaling to HD, you're supposed to use colormatrix 601=>709 in YUV because 709 is standard for HD. That' s missing from your script

[Tafflad]

Hoping to do the color test over the weekend .. thanks for explanation on matrix being irrelevant.

[poisondeathray]

If you've run the script as-is , the conversion from YUV to RGB in vdub/deshaker would have used the wrong Rec601, despite it being HD. If it wasn't upscaled, it would be correct. You're supposed to use the colormatrix filter in YUV to "switch" to 709 when upscaling to HD (becacuse 99.9% of recieving applications will use 709 when converting back to RGB, so everything looks "normal"), or you could have used ConvertToRGB with 709 matrix before importing into vdub

To "fix" what you have, you could either convert to RGB with 601 matrix before importing (then the RGB colors will be correct , and there will be no issues importing into vegas), or redo a few steps, or try to fix it on the other end by frameserving. It's something you'd have to fiddle with a bit

Basically I would double check to see what you have right now. To see if the colors are correct. Check the canopus intermediate with either ConvertToRGB24(matrix="rec709") vs ConvertToRGB(matrix="rec601") . The difference isn't large between them -things like skin colors will alter, red will look orangish instead

Another reason people use the debugmode workflow is the bundled AVC encoders in vegas aren't very good

[Tafflad]

My original capture files were DV PAL captures 720x576 in YV12
I run the step one DeInterlace script as:

AVIsource("E:\colours.avi")
ConvertToYV12(interlaced=true, matrix="PC.709")
LanczosResize(960,height)
AssumeBFF().QTGMC(Preset="slow", EZDenoise=2.0, NoisePreset="Slow" )
LanczosResize(width,720)
ColorYUV(levels="PC->TV")
# NOTE - this sets to correct levles for youtube
#Increase the saturation
tweak(sat=1.2,coring=false)

I then saved it as GV Lossless ... which gave me a YUY2 - Step1 output
Loaded back into VD and carried out DeShaking .. saved as GV Lossless again YUY2 - Step2 output
In practise that is the point I am at now - files are in step2 format

Next step is to be reload into VD some sharpen & maybe colour adjust ........ and it seems would now save in MagicYUV.

If I leave its 'as is' it will save in RGB32 <edit:been advised best to leave it in RGB32 as Vegas works in RGB>


I did follow the steps through as suggested with just colour bars .... and I can't 'see' any difference, but maybe I am not comparing correctly.
As example I attach the sample files for each step

#1 Colour_bars from the lead in on the original DV capture
#2 Step 1 output
#3 Step 2 output
#4 Step 3_MagicRGB32 step 3 output saved in Magic YUV - as is
#5 Step 3_MagicYUY2 step 3 ouput saved in Magic YUV forced to YUY2


Q1. I need to carry out Step 3 .. is there something I could add at that point before saving as MagicYUV ...? ref previous comments on maybe need to add a ConvertToRGB(matrix="???") step.


Q2. Or if you think it would give me better results I can go back to Step1 or even to the original captures - in which case what changes should I make to the DeInterlace script .... I still need to end up with 960 x 720

[aedipuss]

sorry i'm lost. why are you using a lossless intermediate with DV? vegas treats DV losslessly internally and only re-encodes changed frames. what is your intended final output?