Virtualdub output to mpg?

[zakman]

Can Virtualdub save to an mpeg file? I downloaded the mpeg plugin, but I think it only supports mpeg as input.

[jman98]

I think Virtual Dub Mod is what you really need to use.

[poisondeathray]

Neither vdub or vdubmod can export mpeg2 directly.

Try avidemux, or you can export a lossless format out of vdub (e.g. lagarith or huffyuv) then plug that into an MPEG encoder

[redwudz]

Or another option is to frameserve the VD output directly to a MPEG encoder. I've used it with TMPGEnc encoder and others should also work. There are guides for frameserving from VD at the bottom of the VD toolpage. Frameserving eliminates the in-between file and saves on hard drive space.

[zakman]

Thanks all,

I tried the Virtualdub frameserve guide here, and it all makes sense now. I now need to find a good encoder to make mpg files from avi. Any suggestions? I want DVD quality mpeg.

[jman98]

Sorry about the incorrect Virtual Dub Mod suggestion. I have never used it for what you propose, so it was just a best guess that it would work. However, I know that the free HCEnc program can provide excellent quality MPEG-2 output and it can accept frameserver input. I'd suggest using it. It's hard to believe an encoder as good as HCEnc is free, but it is.

[Midzuki]

It's hard to believe an encoder as good as HCEnc is free, but it is.

<OFF-TOPIC>
Speaking of decent free encoders, let's not forget Aften, nor LAME.
</OFF-TOPIC>


\\\\\\\\

[zakman]

jman98,

That's OK.
And thanks for the suggestion about HCEnc. I am just starting to learn about it and about frameserving. I found my output from HCEnc was washed out like somebody changed the brightness or contrast, so I looked into FreeEnc and could not get it to work (see my posted question here).

[manono]

Before you go through the trouble of learning how to frameserve out of VDub, be warned that it leads to inferior results and slower encoding. If you're serious about learning how to encode, you'd best learn AviSynth.

If it's just a one-shot deal and you don't care about quality, then go ahead because AviSynth has a bit of a learning curve.

I found my output from HCEnc was washed out like somebody changed the brightness or contrast,

How did you get the video into HCEnc, and what kind of a video was it?

[zakman]

My "big picture" task is to develop a better way of editing DVDs (I own them) which are 720 x 480 mpeg format. I have been using Womble for years and like it a lot. But womble's encoder isn't very good for when I add a title or a filter. So I just started learning about frameserverving. I discovered a guide on how to use HCEnc in conjunction with Womble. That has the advantage that I can use all the filters in Womble and the very nice GUI, along with HCEnc which is supposed to be a very good encoder. The problem I have is that the results from HCEnc seem to be washed out.

[manono]

If that guide is about Womble and HCEnc, then why this thread about VDub? Is it because you're trying to avoid that slightly washed-out look and blurriness as mentioned in that guide? You're experiencing the same thing? And you're getting it for the entire video, right, and not just the edited parts?

I don't quite understand why he says you need the ConvertToYV12 line in the script, since DVDs are already YV12 and HCEnc only accepts YV12. By frameserving out of Womble with that WBP file, is there an RGB color conversion going on? Like when frameserving out of VDub? If so, that could account for the results you're seeing. I don't use Womble, so I can't help with that, but I expect jagabo would have some tips about how to avoid the results you're getting. He'll probably come along soon.

You might remove the ConvertToYV12() line temporarily, add Info() to the bottom of the script, and then open your script in VDub(Mod) to see the colorspace of that script before the colorspace conversion, if there really is one. My guess is that you just have to get it back to the YV12 colorspace and the Rec.601 colorimetry properly. Just a guess.

[zakman]

First, I'd like to thank you so much for your time...

If that guide is about Womble and HCEnc, then why this thread about VDub? Is it because you're trying to avoid that slightly washed-out look and blurriness as mentioned in that guide?.

Yes, that's right. I was trying to find alternative solutions to my problem.

You're experiencing the same thing? And you're getting it for the entire video, right, and not just the edited parts?

When using Womble without HCEnc, I get pretty crummy output (blocking/striping, but no ccolor problems) whenever I use any of their filters or special effects. Womble is smart so that it doesn't re-encode the entire video, just the parts that use the filters (and other special features). When using HCEnc (frameserved), the results are much cleaner, but the colors are washed out (like someone changed the contrast or brightness).

I don't quite understand why he says you need the ConvertToYV12 line in the script, since DVDs are already YV12 and HCEnc only accepts YV12. By frameserving out of Womble with that WBP file, is there an RGB color conversion going on? Like when frameserving out of VDub? ?

I know nothing about colors. Never heard of YV12 until yesterday . But if I don't put the ConvertToYV12 into the script, HCEnc won't encode and says, "no YV12 color space, add ConvertToYV12() to script". Being the intelligent guy that I am ( ), I got the idea to put the ConvertToYV12() line back into the script.

You might remove the ConvertToYV12() line temporarily, add Info() to the bottom of the script, and then open your script in VDub(Mod) to see the colorspace of that script before the colorspace conversion, if there really is one. My guess is that you just have to get it back to the YV12 colorspace and the Rec.601 colorimetry properly. Just a guess.

I tried removing the ConvertToYV12() and put in the info() line, but HCEnc gives the same error message ("no YV12 color space, add ConvertToYV12() to script"). Is there another way to determine what color scheme is being used in the video?

Another idea: I see there is a setting in HCgui called "colorimetry". You mentioned this word (I never heard of it), so I went poking around in HCgui and see it under the "settings 2" tab. Would that help?

[poisondeathray]

OK I did some testing using a simple .avs script with ColorBars()

My hypothesis is that Womble does a poor quality RGB conversion internally. It also does some weird things, like resizing to 640x480 (from 720,480) and flipping the image that needs to be "undone" with FlipVertical() . I suspect all these manipulations add up to worse quality.

There are several colorspace conversions. At the borders between the color bars the quality deterioration is quite evident at the subsequent stages. (Please ignore the aspect ratio, I took the images out of AvsP. Also this takes the choice renderer out of the picture which might confuse the results)

1) This is what it should look like, ConvertToYV12() for HCenc output directly (actually encoding to .m2v, you get essentially the same result as the preview in AvsP, I verified this)


2) This is what it looks like, exported from Womble in the script, still RGB before the YV12 conversion


3) And the output converted to YV12 ready to be fed into HCenc


I don't think there is much you can do to compensate for this using HCenc encoder settings, because it is being fed that poor quality image. I suspect you'd have to do some avisynth filtering and colorspace magic BEFORE feeding it to HCenc (Paging jagabo...for the real explanation...). Better yet, it might be better to do it all in avisynth and avoid the Womble->HCenc frameserve method.

[manono]

I tried removing the ConvertToYV12() and put in the info() line, but HCEnc gives the same error message ("no YV12 color space, add ConvertToYV12() to script"). Is there another way to determine what color scheme is being used in the video?

I said to open it in VDub(Mod); that is, in either Virtual Dub or Virtual Dub Mod. It doesn't have to be YV12 for that and you'll get the colorspace. However, it looks like poisondeathray already did it for you and confirmed it's being converted to RGB and back again to YV12. And it looks as if the 2 improperly done colorspace conversions are responsible for both the blurring and the colors being off, as I suspected. Unfortunately, only one of them - the one in the script - can be fixed. I think you can improve the results, but not fix it entirely.

So, I agree with poisondeathray and it looks to me like you have 2 choices - either let Womble reencode the parts with the effects (probably a small per cent of the whole) and then reencode with HCEnc yourself, resulting in good quality for all but the effects parts, or let AviSynth do the effects for you. Depending on what you're doing (fades, adding text, dissolves, whatever), you might need know only a little or a lot of AviSynth. Maybe there's a third choice of using a different MPEG editor, maybe VideoReDo.

[jagabo]

It's been quite a while since I played around with Womble but I do remember it having levels and colorspace issues. The grayscale levels look ok in poisondeathray's images. The color shift looks a bit like rec709 vs rec601 error, but not exactly. For example, if you use ConvertToYV12(matrix="rec709") on the RGB output of Womble (#2 above) you get something closer to the original. I would just avoid using Womble.

By the way, you can ouput MPG with VirtualDub with YMPEG. I've never used it so I can't say how well it works.

A few words or warning about colorspace conversions:

When converting RGB colorbars to YV12 keep in mind that the alignment of the bars makes a difference in the result.

Original RGB (note I've shifted the color bars one pixel to the left every 64 scan lines):


After ConvertToYV12().ConvertToRGB() (note the different amount of blurring depending on the horizontal position):


Repeated RGB/YV12 conversion lead to more blurring in AviSynth but the colors remain accurate (each primary within 1 or 2 units). Some converters don't do as well and you get more drift in colors with each conversion.

AviSynth's ColorBars() RGB output should be converted to YV12 with the PC.601 or PC.709 matrix: ConvertToYV12(matrix="PC.601"). That gives the correct levels -- compare to ColorBars(pixel_type="YV12"). Note the pluge bars in the lower right.

[zakman]

I thought I should show you a before and after picture. The left is the original and the right is after using the HCEnc/frameserver.
[/img]

[zakman]

Do you think this is a dead end and I should look into another way to solve my problem? Possibly use another program to do the special editing? If so, I'll post a new question since it isn't related to this topic.

[poisondeathray]

What kind of editing?

You can do everything in avisynth, but it's not as easy or GUI friendly as Womble. There are several plugins you can use for transitions (e.g. TransAll), and you can use overlay() or layer() or even textsub() to make overlayed words. The benefit is none of these extra colorspace conversions and weird resizing business, so the quality will be higher.

Another approach is to use Wax (open source editor), which has pretty much all the (80's style LOL) cheesy effects that Womble has and many more, with 100s of extra presets you can download. It doesn't accept MPEG2 input natively, but accepts .avs input, so you can get around that easily. It doesn't output MPEG2 directly (you have access to all VFW encoders, e.g. xvid, divx, ffdshow), so you can either frameserve out, or use a lossless intermediate (e.g. lagarith).

Of course there are the staple NLE's: Vegas, Premiere Pro

[jagabo]

I thought I should show you a before and after picture. The left is the original and the right is after using the HCEnc/frameserver.

I didn't doubt you were seeing a difference. I was just pointing out that resizing isn't causing the levels change. I've lost track of what you are doing -- could you outline the entire process?

One quick thing to try since you are using ConvertToYV12() when feeding HC Enc: use ConvertToYV12(matrix="PC.601") instead. That will avoid the usual luma compression and may pull your levels back closer to the source.

<edit>

Ah, I see you are using a script from the aforementioned guide (I fixed some obvious typos):

LoadvfapiPlugin(“C:\Program Files\Womble Multimedia\MPEG Video Wizard DVD\WbpVFAPI.vfp”, “womble”)
womble(“C:\Documents and Settings\Tim\Desktop\Video Project\Trip to Safeway\Trip to Safeway.wbp”)
flipvertical()
Lancszosresize(704,480)
converttoyv12()

Add Info() just before the ConvertToYV12() to see what colorspace you're working in (I suspect it's RGB).

LoadvfapiPlugin(“C:\Program Files\Womble Multimedia\MPEG Video Wizard DVD\WbpVFAPI.vfp”, “womble”)
womble(“C:\Documents and Settings\Tim\Desktop\Video Project\Trip to Safeway\Trip to Safeway.wbp”)
flipvertical()
Lancszosresize(704,480)
Info()
converttoyv12()

Open the script in VirtualDub or a media player and see what colorspace is reported. Example:



But knowing that womble is putting out RGB probably isn't going to help us fix the problem. I think Womble is just screwing up the colors and levels.

[zakman]

Thanks to both of you for your patience.

I opened the script in virtualdub and it says "RGB24"! I think this means you were right.

I tried using "ConvertToYV12(matrix="PC.601") " (last line in script) and that made a big difference. Thanks for the suggestion. I would say it brought it about 80% of the way there, and that ain't bad. I'd still like to learn a better method, but now I at least have something which is quick and reasonable.

I'd like to learn more about using overlay(), layer(), and textsub(). The reason I stayed away from these is that in womble I can get real-time feedback. The types of things I want to be able to do is to zoom in, overlay some polygon or text on top of the video, blur a small area of the video, etc. I am not really interested in Womble's "cheesy" effects, except maybe fade or blend. Any suggestions for what I want to do that involves less than $100 are welcome (I'll probably start with seeing how much I can do with avisynth and I might look at Wax too).

[jagabo]

I tried using "ConvertToYV12(matrix="PC.601") " (last line in script) and that made a big difference. Thanks for the suggestion. I would say it brought it about 80% of the way there, and that ain't bad. I'd still like to learn a better method, but now I at least have something which is quick and reasonable.

Try following ConvertToYV12(matrix="PC.601") with: ColorYUV(off_y=-2, gain_y=-18). I think that will come close to restoring your levels.

<edit>

After examining your before/after image more closely I've come up with this:

I split the before/after image into two separate images, before.png and after.png. Looking only at before.png it's clear that the black level is too high for rec.601 RGB on the computer. Converting it to YUY2 with a PC.601 matrix gives much better YUV black levels.

Treating the after image the same way leaves the black level way to high. This problem was apparently caused by Womble. Adding ColorYUV( off_y=-18) corrected this and leaves the rest of the image at comparable levels (with the exception of the blown out white peaks).

Here are the images, the script, and the VideoScope() graph:



v1=ImageSource("before.png").ConvertToYUY2(matrix= "PC.601")
v2=ImageSource("after.png").ConvertToYUY2(matrix=" PC.601").ColorYUV(v2, off_y=-18, gain_y=0)
StackHorizontal(v1, v2)
VideoScope()



Note that the final VideoScope() image was saved from VirtualDub which uses a rec.601 matrix to convert to RGB for display. This performs the normal rec.601 contrast stretch which puts YUV luma black (16) at RGB 0, and YUV luma white (235) at RGB 255. Hence the greater apparent contrast.

[zakman]

jagabo,

I feel like an idiot because I only understand about half of what you are saying. Where did you learn all this stuff? Anyway, are you suggesting I add ColorYUV(off_y=-2, gain_y=-18) or ColorYUV(off_y=-18, gain_y=0) ? I will try both, but I think you are suggesting the second one.

<edit>

I just tried both, and found that the first one (off_y=-2, gain_y=-18) matched the original brightness/contrast the best. Let me know if you would like me to post the pictures.

Note: When I posted the picture before, I used womble to export the frame to a jpg file, then used paintshop pro to clip the two pictures and mush them together into a single jpg. Hope that was ok.

[jagabo]

Keep in mind I'm judging this only by the sample image(s) you posted, and I don't know exactly how you prepared them. But from what I saw you should use:

ConvertToYUY2(matrix="PC.601")
ColorYUV(v2, off_y=-18)

Oh, sorry, I forget to remove the "gain=0" earlier. (Gain=0 says not change the gain; leaving it out achieves the same thing.) "Off_y=-18" subtracts 18 from the luma of every pixel making the after image match the source. And the final result looks about right.

I recommend you use VideoScope() to check the result. You can get it from here:
http://avisynth.org/warpenterprises/

VideoScope() adds a luma graph to the bottom of the video. The graph plots the brightness of the image as heights on the graph. At the bottom of the graph is luma 0 (darkest) and at the top of the graph is luma 255 (brightest). (How the graph is drawn: take one scanline of pixels from the image. Directly below each pixel plot a dot whose height on that graph to represent the brightness of that pixel. Repeat for every scanline of the image.) YUV video should have the darkest areas at luma 16 and the brightest areas at luma 235. It's OK if small very parts of the image are outside that region, especially at the top. But on a properly calibrated TV, pixels at and below 16 will all be drawn the same shade of black. At the top end pixels above 235 may be a little brighter than the pixels at 235.

VideoScope() also adds a graph at the right of the frame. It's the same as the graph at the bottom but works column by column rather than row by row. It also has some other stuff worth checking out when you have the time.

[zakman]

ConvertToYUY2(matrix="PC.601")
ColorYUV(v2, off_y=-18)

What does the "v2" do? I am assuming it says, "use v2 as the clip I am working on", so it is both an input and output to the function (??). I looked up the syntax of ColorYUV here and it seems to indicate the first argument is "clip", and it isn't in parentheses so that means it isn't optional (??), but it is missing in some of your examples. So, I am confused about some basics of using avisynth.

ColorYUV(clip [, float gain_y] [, float off_y] [, float gamma_y] [, float cont_y] [, float gain_u] [, float off_u] [, float gamma_u] [, float cont_u] [, float gain_v] [, float off_v] [, float gamma_v] [, float cont_v] [, string levels] [, string opt] [, boolean showyuv] [, boolean analyze] [, boolean autowhite] [, boolean autogain])

[jagabo]

Sorry, I cut and pasted from the earlier script that opened both images and forgot to remove the extra arguments. In your case you are using the default video so you don't need to specify which video to use:

ConvertToYUY2(matrix="PC.601")
ColorYUV(off_y=-18)

And the line in the earlier script should have read:

v2=ImageSource("after.png").ConvertToYUY2(matrix="PC.601").ColorYUV(off_y=-18)

(I originally had the ColorYUV() filter on a separate line so I had to specify which video to operate on.)

Here is a test MPG file you can use to check for level shifts and clipping:

levels.mpg

Using DgIndex and AviSynth to open the video in VirtualDub:

MPEG2Source("levels.d2v") 
ConvertToYUY2() #convert from YV12 to YUY2 because VideoScope() requires YUY2
VideoScope("bottom")
ConvertToRGB(matrix="PC.601")

The last line, ConvertToRGB(matrix="PC.601"), converts to RGB with the PC.601 matrix to prevent luma stretch. If you use an image editor that shows the RGB values you'll see that they match the numbers on each bar. If you let VirtualDub do the conversion, or just use ConvertToRGB() the usual rec.601 contrast stretch would be performed. The 0, 4, 12, and 16 bars would all become RGB=0, the 235,239, 251, and 255 bars would all become RGB=255. And the range from 16 to 235 would be stretched from 0 to 255.

In case you don't understand the contrast stretch:

In video (YUV) black is defined as Y=16 and full white at Y=235. Levels below 16 and above 235 are there to allow for overshoot (ringing from sharpening, etc). On computers (RGB) black is defined as 0 and white as 255. So most programs stretch the luma range of 16-235 to RGB 0-255 when converting YUV to RGB. In AviSynth the matrix used to do this is called "rec601". This is the default if you don't specify which matrix to use. If you don't want that contrast expansion you have to specify "PC.601").

[J. Baker]

Can Virtualdub save to an mpeg file? I downloaded the mpeg plugin, but I think it only supports mpeg as input.

Yes... http://www.ympeg.com/index.htm