Avisynth/Vegas interface, other (new to avisynth) processing issues

[poisondeathray]

What are we looking at at this point for getting the .264 ready for BD? And can HCEnc play nice with .264?


Yes, you need to use BD compatible settings when using x264. Reference links were posted

No HCEnc is MPEG2 encoder. DVD-video only uses MPEG2 (AVC is not compatible). You need to do a few other things like resize, colormatrix (601 for SD colors) to prepare it for DVD-video .


Here's kind of an oddball question, in the spirit of not reaccomplishing work. Can I do both, finish up with where I'm at now (author and burn), while still rendering at 10bit?


Yes, but only as a video playable on a computer. DVD-video and BD are 8bit only . UHD BD , however is 10bit compatible but uses HEVC.


Is there a way to somehow bring it down to 8 bit after the 10bit render out of Vegas for the purpose of running it into (or during) the MeGUi (for example, as that is what I'm using presently) process and out with .264? What I'm thinking here is not having to re-render out of Vegas, if in the future I do tackle adapting the script for a 10bit input? Now even though the Vegas rendering will be much quicker compared to the script running, (remember the.3xx fps rates I was seeing, lol) it would save me doing a different Vegas render later. (I will of course save the .veg file with the cuts/corrections info, so I won't have to redo those later)


Yes, you can truncate it down to 8bit. This happens if you just open the v210 "normally". But the proper way is to use higher depth workflow and properly dither it down to 8bit.

If your output formats and processing filters in avisynth are 8bit , I wouldn't bother with 10bit or stacked workflow. Especially on your type of material. You might reconsider when 10bit becomes more mainstream




I'm thinking not, not without even more information loss than just doing a 8 bit render would impose, but I thought I'd ask.

And just for the sake of seeing what I'm up against if/when I attack chapter 2, putting 10bit into the script, which of these are going to need changes? I believe I'm using, from the script notes:

autolevels
Deflicker
Depan
DepanEstimate
fft3dfilter
masktools2
mvtools2
RemoveDirtSSE2
removegrain
warpsharp

I believe you said earlier that some of these have no 10bit counterparts.


Yes, some of them have stack16 equivalents, some of them don't . You have to do some legwork or find some equivalent or replacement compatible stack 16 filters. It's not going to be trivial task - someone ambitious enough or having a lot of free time might do it for you.

[Bruce/Fl]

If your output formats and processing filters in avisynth are 8bit , I wouldn't bother with 10bit or stacked workflow. Especially on your type of material. You might reconsider when 10bit becomes more mainstream

Yeah, looks lie 10 bit will be quite a tasking.

With that in mind, I was looking at my options in the video for windows template, trying to pick out a codec that would give me the most robust input for the script. I have the standard ones from Vegas, plus some Blackmagic ones, Cineform (but thats 10 bit), and some UTVideo ones.

One in the UTVideo collection looked good, it is called "UTVideo YUV422 BT.709 VCM", I ran a mediainfo on it and it does come thru as 4:2:2. It doesn't specify the bit depth, but I believe it is 8.

Good choice to feed into the script? Or is there another choice that ideal practices would point to? (And I can download more codecs, of course)

Also, I ran a test of one of the 264 files I made using MeGUI, and put it thru multiAVCHD and selected the BD output. Here is the mediainfo on the resulting file, does it look like it missed something that a different encoder would have done better? (The progressive came through)

General
ID : 1 (0x1)
Complete name : C:\multiAVCHD\AVCHD\BDMV\STREAM\00000.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 5.84 MiB
Duration : 9s 409ms
Overall bit rate mode : Variable
Overall bit rate : 5 199 Kbps
Maximum Overall bit rate : 35.5 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : 27
Duration : 9s 476ms
Bit rate mode : Variable
Bit rate : 4 986 Kbps
Maximum bit rate : 40.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.080
Stream size : 5.63 MiB (97%)
Writing library : x264 core 148 r2638 7599210
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=fake / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=1 / keyint=30 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=40000 / vbv_bufsize=30000 / crf_max=0.0 / nal_hrd=vbr / filler=0 / ip_ratio=1.40 / aq=1:1.00
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

I also rendered a clip using the UTV422, it came through authoring as 4:2:0, however.

[poisondeathray]

UT 422 will be 422 . Your script is converting it to 4:2:0. 4:2:2 isn't supported by DVD or BD . This was already mentioned but eitherway, you should use RGB coming out of vegas for the 8bit version (either dmfs, UT RGB, lagarith RGB etc...). Best practices is still to use the higher bitdepth workflow. You can look at other workflows like vapoursynth or even other tools if you can't find similar filters. But will not make a big difference in your case - I wouldn't worry about it. It makes a larger difference on higher quality source material, or even things like CG

That mediainfo of that indicates it uses --fake-interlace, but only some authoring tools will author it properly. Not sure if multiavchd does. You have to test some discs on some players, or ask around (maybe someone did these tests already with mulitavchd) . MBAFF route is safer, because more authoring applications and players will handle it properly

[Bruce/Fl]

UT 422 will be 422 . Your script is converting it to 4:2:0. 4:2:2 isn't supported by DVD or BD . This was already mentioned but eitherway, you should use RGB coming out of vegas for the 8bit version (either dmfs, UT RGB, lagarith RGB etc...). Best practices is still to use the higher bitdepth workflow. You can look at other workflows like vapoursynth or even other tools if you can't find similar filters. But will not make a big difference in your case - I wouldn't worry about it. It makes a larger difference on higher quality source material, or even things like CG

Yes, and I apologize. I went back through the whole thread and reread it. All together with this thread and the section of the MeGUI bug thread that I was a part of, my mind has been all over the place.

A couple questions in this regard.

Is there a benefit, quality wise, to using say, the UTVideo RGB codec or using the one built into the DBFS?

Also, and just for my own understanding, I'm guessing that it is better to keep the output of Vegas as RGB, and do the conversion to YV12 or YUY2 in the script, rather than changing it as you render out to YUV for input into the script, or am I making way too much of the connection between YUV and YUY2 and YV12, which is probably the case.

That mediainfo of that indicates it uses --fake-interlace, but only some authoring tools will author it properly. Not sure if multiavchd does. You have to test some discs on some players, or ask around (maybe someone did these tests already with mulitavchd) . MBAFF route is safer, because more authoring applications and players will handle it properly

I'll burn a disc soon using that process and see what happens, and I'll report back.

[Bruce/Fl]

I'm getting ready to start doing some scene separating and corrections in Vegas tonight, and want to make sure I have all the "Project properties" options set optimally for my situation.

This is what I selected. Please let me know if I have one set wrong.

I will bold the ones I overrode the default selection.

On the "Video Tab"

For Template I went with what it defaulted to, "HD 1080-60i (1920x1080, 29.970 fps)"

Field Order - "none (progressive scan)"

Pixel aspect ratio - "1.0000 (Square)"

Output rotation - "0 degrees (original)"

Frame rate - "14.985 (Half NTSC)"

Stereoscopic 3D mode - "Off"

Pixel Format - "32-bit floating point (video levels)"

Full resolution rendering quality - "Best"

Motion Blur Type - "Gaussian"

Deinterlace method - "Blend fields"

Adjust source media to better match project or render settings - I left it checked.

Start all new projects with these settings - I left that unchecked.

I didn't adjust anything in the other tabs.

I will also add my video fx to the project before I start separating scenes, that way the options will be there in each separate scene, and I won't have to add them 264 times.

Is there anything else that should be on my radar that I have missed?

[johnmeyer]

Your last question is about Vegas, not AVISynth. There are quite a few Vegas users here, but not everyone knows the program. Since I am a Vegas user, and I do a lot of film transfers (as you already know), I thought I should answer the last question.

First, the Vegas project settings are extremely important because you are using the Satish Frameserver. Normally project properties simply conform the video to whatever you set in Project Properties for the purpose of getting a "WYSIWYG" preview. However, the Vegas Project Properties settings do not affect your render (with the exception of the deinterlace settings).

However ...

Things are different when frameserving. In this case, project settings control what is actually sent to your AVISynth script. Therefore, you have to get it right. The easy way to get it right is to use the "match media settings" button in the Vegas Project Properties dialog. It sets all the properties so they exactly match your source video. By doing this you avoid any needless changes to your video. The only time you should have to change anything from what this "match" button sets is if your source media incorrectly sets the interlaced flag even though your video is progressive (the DV AVI codec does this).

Finally, I've been reading all the advice about higher bit color settings. I don't disagree with a word of it, but as "poison" said earlier, you really don't need to worry about it given the relatively low quality of your source material. I'd go a step further and say that by trying to get all your plugins to work at a higher bit depth, you are needlessly creating more work for yourself, without any real gain. If you can actually get the entire workflow to work at higher bit depths, then by all means go ahead. As always, I strongly suggest that you do 5-10 seconds using one method, and compare it with what you get using another method.

Expanding on that point: doing your own before/after tests is a far, far better way to get a great result than simply trying to follow advice from other people who are not doing the same thing as you are.

This advice goes double for your choice to use Vegas' 32-bit setting. As you may or may not know, 32-bit in Vegas has all sorts of subtle problems, with both color shift and levels. You can search GlennChan's excellent posts in the Vegas forum for wonderful advice. He also has some old, but still relevant tutorials on his web site, such as this one:

Color Spaces / Levels in Vegas 9 and 10 (http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm)

My advice: stick with 8-bit color from Vegas. I also serve out of Vegas using YUV, since you will have to make that change somewhere along the line. You can read some of Nick Hope's posts on this subject both here and in the Vegas forum. There is an epic 200+ post thread about his quest for a great rendering workflow for posting video on YouTube, and a dozen of us did all sorts of tests with different settings. You will definitely be able to see differences in how red is rendered, depending on what settings you chose. Other colors are affected, of course, but red was particularly obvious.

[Bruce/Fl]

Finally, I've been reading all the advice about higher bit color settings. I don't disagree with a word of it, but as "poison" said earlier, you really don't need to worry about it given the relatively low quality of your source material. I'd go a step further and say that by trying to get all your plugins to work at a higher bit depth, you are needlessly creating more work for yourself, without any real gain. If you can actually get the entire workflow to work at higher bit depths, then by all means go ahead. As always, I strongly suggest that you do 5-10 seconds using one method, and compare it with what you get using another method.

Yes, I didn't do a very good job of being clear that I saw the amount of work ahead in trying to go with more 10bit, but up at the top of post 52 I conceded that pursuing it was probably too much work at this time, and I was going to press on in 8 bit once the color work was done in Vegas.

First, the Vegas project settings are extremely important because you are using the Satish Frameserver. Normally project properties simply conform the video to whatever you set in Project Properties for the purpose of getting a "WYSIWYG" preview. However, the Vegas Project Properties settings do not affect your render (with the exception of the deinterlace settings).

However ...

Things are different when frameserving. In this case, project settings control what is actually sent to your AVISynth script. Therefore, you have to get it right. The easy way to get it right is to use the "match media settings" button in the Vegas Project Properties dialog. It sets all the properties so they exactly match your source video. By doing this you avoid any needless changes to your video. The only time you should have to change anything from what this "match" button sets is if your source media incorrectly sets the interlaced flag even though your video is progressive (the DV AVI codec does this).

I went with the match media settings, but I felt that some needed to be adjusted. Although it didn't autoselect the DV AVI codec (you masy have mentioned that just as an example) it did default to interlaced, which I felt was incorrect for my material. Also, I felt that the advice I got earlier in selecting half NTSC (14.985) was sound, as it reduced the chance of me possibly getting an edit point wrong, (if I sent a clip with a single frame left on one scene due to being a frame off on my cut, and it's doubled counterpart at the beginning of the next scene, wouldn't that possibly drop a frame or create some other issue when it hit "selecteven" in the script?) and it also halved the size of the video being sent to the script.

The thirty two bit floating selection I'll mention below.

The "Full resolution" setting just made sense as I looked at my options. "Best" should be best, right, that was my thinking, heh.

Expanding on that point: doing your own before/after tests is a far, far better way to get a great result than simply trying to follow advice from other people who are not doing the same thing as you are.

This advice goes double for your choice to use Vegas' 32-bit setting. As you may or may not know, 32-bit in Vegas has all sorts of subtle problems, with both color shift and levels. You can search GlennChan's excellent posts in the Vegas forum for wonderful advice.

Yes, and I mostly follow that train of thought, (seeing the results with my own eyes) even though all my questions here might look otherwise. I can't remember what the situation was years ago, (I don't think it was in the Vegas or video world, but it might have been) but there was a process I was doing where I finally thought something was different compared to results others were getting. So I asked a question, I was asked my settings, and it turns out in a sub menu there was a selection I had/hadn't selected and once I did, voila!

I was just hoping that if I was making a similar user error in this case, someone would point it out. I'd hate to be hours and hours of work, days or weeks later finding out that I missed selecting some button/changing a setting that would have really helped my efforts. So I posted what I was doing in the hope that someone who had the experience themselves before could give sound advice in correcting a mis-selection I had/hadn't made.

As far as the 32 bit float, I had no idea about the "subtle problems". I admittadly know nothing about it. I went with it because of this from earlier in this thread:

32bit is more accurate for intermediate calculations and manipulations - there is less rounding error. You introduce less banding with your color manipulations, compositing and layer blend modes are more accurate.

I focused on that, but in re-reading it, there was also this:

The main "negative" to using 32bit processing is speed.. It's much slower. For many types of projects, 8bit manipulations are perfectly fine. So it's going to depend on your project specifics and expectations.

So, I will give that thread, and others like it, a read. I'm sure there is lots of good info in there that will further educate me. Thank you for the link.

My advice: stick with 8-bit color from Vegas. I also serve out of Vegas using YUV, since you will have to make that change somewhere along the line. You can read some of Nick Hope's posts on this subject both here and in the Vegas forum. There is an epic 200+ post thread about his quest for a great rendering workflow for posting video on YouTube, and a dozen of us did all sorts of tests with different settings. You will definitely be able to see differences in how red is rendered, depending on what settings you chose. Other colors are affected, of course, but red was particularly obvious.

Yes, I tossed in the towel on 10 bit for the time being. And for all I know, say in the future it becomes feasible/easier to accomplish all the way through the workflow, I might not be able to see any difference at all. But yes, I am going with 8bit once I'm done with corrections in Vegas.

I am confused with what format to serve out of Vegas with, yours and PDR's advice appear to me to be at odds, you saying YUV and PDR with RGB. Maybe I'm not grasping one or both of your points, but if you'd like to discuss it here, i'd be a very interested spectator. I learn alot from the discussions here. (well, up to a point, some of the more code related stuff here is in the stratosphere to me)

Thank you for your thoughts John. And also, do you agree or disagree with my project properties selections I made, other than the 32 bit one?

[johnmeyer]

And also, do you agree or disagree with my project properties selections I made, other than the 32 bit one?From your description above, it makes it sound as though you changed the fps to 14.985 from whatever the "match properties" operation gave you ("I felt that the advice I got earlier in selecting half NTSC (14.985) was sound, as it reduced the chance of me possibly getting an edit point wrong..."). If so, that is a really big mistake. You absolutely MUST match the source frame rate, and then do NOT change it. If you change it so it no longer exactly matches the source frame rate, then Vegas will add or delete frames, as needed, in order to get the original video to have 14.985 frames per second. If Vegas' resample is set to "smart" or "forced," Vegas will create these additional frames by blending adjacent frames. If resample is disabled, Vegas will create the extra frames by duplicating fields (i.e., standard pulldown). Either of these operations will completely screw up the AVISynth scripts because they expect frame accurate input without any pulldown.

[Bruce/Fl]

From your description above, it makes it sound as though you changed the fps to 14.985 from whatever the "match properties" operation gave you ("I felt that the advice I got earlier in selecting half NTSC (14.985) was sound, as it reduced the chance of me possibly getting an edit point wrong..."). If so, that is a really big mistake. You absolutely MUST match the source frame rate, and then do NOT change it. If you change it so it no longer exactly matches the source frame rate, then Vegas will add or delete frames, as needed, in order to get the original video to have 14.985 frames per second. If Vegas' resample is set to "smart" or "forced," Vegas will create these additional frames by blending adjacent frames. If resample is disabled, Vegas will create the extra frames by duplicating fields (i.e., standard pulldown). Either of these operations will completely screw up the AVISynth scripts because they expect frame accurate input without any pulldown.

Maybe i'm not understanding, but it seems to be working fine. Vegas doesn't do anything when I set it that way except eliminate my duplicate frames. (My source is 15fps, with duplicate frames added to each and every frame to get it to 30fps. I have gone through more than 100 frames of the original file and it was true to that pattern, 2 copies of the same frame, everytime, no other pattern emerged.) I don't believe any frame blending or other such unnatural manipulations are being made.

I'm assuming that Vegas achieves the same reduction in frames to get it to 14.985 that the "selecteven" command does in an avisynth script. It takes away the duplicates. Now, for some reason Vegas may decide to do it some other way, but I would wonder why, especially in a case where the pattern is so simple, a,a,b,b,c,c,d,d,e,e,f,f,.....

I believe avisynth is getting frame accutate input, just single frames, not duplicates.

That being said, I'm not locked into that process, and can easily switch back to leaving it as is, and having avisynth do the frame removals, but if Vegas is doing what I would think is natural, having Vegas do it made sense, for the reasons I mentioned.

[poisondeathray]

You're understanding correctly. He probably missed the point that you had duplicates or 2:2 pulldown to start with. But it's critical (and I emphasized it earlier) that you check the framerate interpretation in vegas (ie. what vegas "thinks" the frame rate is) . Because the interpretation of the file was 29.97 by vegas and the QT frame header (not 30000/1001) 14.985 will give you perfect 1:1 unique frames within vegas. You're essentially removing the 2:2 pulldown. That's also why you needed the AssumeFPS(15000,1001) at the beginning , and ChangeFPS(30000,1001) at the end to make it legal for BD and DVD . 29.97 and 14.985 are only approximations. Strict authoring software will reject a 29.97 stream because it's an approximation

As for RGB or YUV. Vegas works in RGB. Another reason most people choose to frameserve out RGB, because sometimes vegas gets the matrix wrong for the RGB=>YUV conversion. It' s not a big deal eitherway (you can "fix" it in your script), but you have more control in avisynth in terms of algorithm choice and matrices for YUV<=>RGB conversions in avisynth or vapoursynth. That's the most common reason users report shifted reds, the 709/601 mistmatch. ( and it's likely a 709/601 mismatch on youtube for the shifted reds) and for levels changes: it's the way vegas handles studio vs. computer RGB treatment in vegas of different file exports and imports. These are vegas (not avisynth) issues discussed quite frequently, especially over at videohelp. There is almost a thread a week on vegas handling of levels. The RGB/YUV export is not a big decision point and nothing to stress over, because you can "fix" the levels and a wrong matrix treatment in avisynth.