VD Mod and filter issues...
 

I am using VirtualDubMOD with TMPGEnc and Mainconcept 1.4.2.

I have a AVI file captured to AVI 352x480 Half D1 with MJpeg 19 codec.

The file encodes fine with both encoders. The output has a view stairstep effects here and there. After looking at the original 8mm analog source, they are there too.

I added soem filters to VD and Frameserved to both encoders. The resulting file looks much better, but any movement of any kind has a ghosting or jerky effect. Very difficult to watch.

I bypassed Frameserving and created a AVI file from VD then encoded. Same thing. Does this on ANY filter I use.

Is there any way to make VD work??

LS

The problem is not relative to vdub but to the codec you used. MJPEG is one of the worst thing either :-(

How does that explain that a normal encode works with great results, but only when I feed it with VD it goes bad?

LS

Well,.....

Mjpeg 19 sounds like PicVideo mjpeg setted to quality=19, right?

In case of capture mjpeg is the first choice (if recording space is important).
HuffYUV is even better but results in a hell big encoding file.
picVideo at 19 is also very good and comes like HUFFYUV as a YUY2 codec, means at least half colorfrequency at the width BUT full colorfrequency at the height. YV12 only gots half/half, means for capturing the worst choice.

I dont know 8mm and its technique but your workout sounds like if you did some kind of wrong deinterlacing (ghosting)?

SO: Which filters did u use in Vdub ?

What ? I never seen any mjpeg video with a decent quality. It's true that I do'nt know wich quality setting was used (19 or something else as it was DLed videos.
But you have skills in capture I don't have, so just forget my words.

Well Phil if compression to the limits is the factor then mpeg1/2/4 rules, shure as they do got also P/B Frame architecture.

Mjpeg also DCT based is a stream which works "like" a mpeg one but only I Frame quality is used in the whole framecount.

So IF a correct! MB/s rate is choosen, mjpeg gots one of the best qualities in compression codecs and its mega compatible.

For shure you did see many mjpegs where a too low bitrate related to mjpeg was used.
A friend of mine made Commercial online video cut jobs for the WDR (biggest federal broadcast station in germany in cologne) using a Miro DC30+ and mjpeg Quality set to 6,5 MB/s. Thats why I also did buy that card at Ebay 8) .

Quality 19 at Picvideo is very good (well as we know everything depends on the source).
The biggest Problem on mpeg (no matter if 1 2 or 4) is the YV12 colorspace which only contains the quater of colorinformations then the lumainformations. There does also exist a 4:2:2 mpeg2 profile, but I never got that working at mpeg2 capture apps like the MCE capture engine for example.

I do not understand why so many peoples do use XVID/Divx for capturing!
a) mega CPU consumption therefore they do capture at 352x288(240) = even worse colors!!!! (colorfreq. will be a quater of 352x288(240)!!)
b) Worse colors as said, maybe not on the first view of the mpeg4 BUT later for shure at the encoded mpeg1/2 - NOT MENTION the color problem on interlaced capturing!
c) mjpeg is very fast - full resolution live capturing is possible even when using lower CPUs

As you shure know 95% of all these lines above Phil, I did wrote that here mainly for other readers ;-)

I'm with inc in this one. PicVideo MJPEG is very good and at Q19 you probably won't be able to tell the difference between it and a HuffYUV encoded clip.

As inc said, the problem probably relates to incorrect deinterlacing. VirtualDub doesn't have many good deinterlacers so you might be better off using AviSynth instead. If you wish to use VirtualDub, I recommend Donald Graft's Smart Deinterlacer ( http://neuron2.net ).

The other problem VirtualDub causes is that it does a colorspace conversion to RGB (and then to whatever colorspace the result will be in) when you use full processing mode. That's not a good thing to do :wink:

This is interlaced video with no deinterlacing at all. I tried the following filters:
SNR
DNR
2DCleaner
Smoother

I tried each one by itself. I even frameserved the AVI to the encoders with no filtering at all and it did the same thing. So it must be something with VD itself. I even skipped Frameserving and added fitlers and did a SAVE AS to a new uncompressed AVI then encoded that. Same results.

LS

Do you resize your video ?

If you have an interlaced source and do not deinterlace then you must use a resizer that can handle correctly interlaced streams. Think about that.

And denoiser should be interlaced-aware too, I don't know if there even are any that can be used on interlaced material.

Regarding the situation where you saved the clip as AVI without any filters..it could be the YUY2->RGB->whatever conversion which screws things up as VDub doesn't probably do a proper colorspace conversion with interlaced material.

The jerky motion could also happen because of an incorrect field order. Don't trust TMPGEnc on this one, most of the time it doesn't have a clue about the correct field order, you'll have to find it out for yourself.

In short, if you wish to resize and/or filter, deinterlace first. You'll be a lot safer that way.

My 2 cents here: PicVideo will never be as good as Huffy, because Huffy is a "lossless" CODEC, while PicVideo is a "Lossy" CODEC.
So there will always be artifacts on a PicVideo capture, unless a high value is used, and even then I have my doubts. There's a BIG difference between lossy (discarding frequencies), and lossless (all data intact).
I'd go Huffy over PicVideo anytime, at the expense of captured file size ;)
References: http://neuron2.net/www.math.berkeley...yuv.html#MJPEG

-kwag

Sorry Kwag, thats theory! ;-)

Shure it makes sense what you quoted, but as said I do have NO artefacts when using Picvideo at a sufficient datarate which still comes out in smaller files than HuffYUV.

OK, if you have a hell of diskspace, do it in HuffYUV, but PicVideo at Q=19 is Totally ok. My way is to compare quality at a 400% zoomed preview of the encoding or capture and PicVideo at 19 is "enough".
And as EVERYTHING depends on the source, sometimes HUFFYUV wont give you its gain cause of not perfect incoming broadcasted signals.
Ok, "not good quality inputs should be kept as max perfect as tjey are so we wont even loose in that intermediate step quality"
.... but we are talking about "captures" out of a TV signal and there mjpeg is enough.

And Mjpeg is more sensible to noise??
See it like that a minimal noise wont be encoded as the DCT quantizes them "off" (only at a 400% preview you will recognise that!!) BUT the needed Details are kept for mpeg encoding and NO blocks or artefacts do appear ;-)

Thats only my experience and I never had probs :(

No resizign done. I capture at 352x480. I've tried 702 and 720x480 then resizing and saw no benifit in quality.

LS

it isnt that, that would make capturing in huffyuv in yuy2 mode useless.

@lschafroth, are those filters you are using capable of recognisizng interlaced material? you don't deinterlace right? but then again, it even happens with no filters at all.

could you post two images before and after without any filtering in uncompressed RGB to make the effect visible for us?

ghosting usually is an after effect of deinterlacing BTW

The SNR filter I beleive had an option for Interlaced. I ran that checked and unchecked with no difference.

I will do it all again and post some pics.

LS

If I remember correctly, RGB data is actually created from YUY2 data in most (all?) chips so there's no advantage in capturing in any RGB colorspace. It's only a disadvantage and also requires more CPU cycles and HD space.

@lschafroth,

Your problem could be related to field order.
Follow this procedure here, to determine the correct order: http://www.inmatrix.com/articles/ivtc1.shtml
Read the section titled: Selecting the correct field order:

-kwag

Hi Inc,

If there's a source that make MJPEG limitations evident, that's old style cartoons. :(

OK, when you're encoding the capture to mpeg the mosquitoes will show anyway, but then you can at least try to minimize it with filters, etc.

I haven't had time to try that. When I select Top Field order and encode the video is very jerky. when I select Bottom First and encode it is normal.

When I encode bottom first via VirtualDubMOD, it is ghosty adn jerky again.

LS

PS Anyone know how to get AVISynth to work with TMPGEnc? I get video in VDMod via AVIsynth but no video in TMPGEnc via ACISynth.

@lschafroth

Install ReadAVS, that lets read TmpgEnc DIRECTLY the avs scripts.

http://www.avisynth.org/warpenterpri...es/readavs.zip

@ GFR

Everything depends on the Q level (like 19 in picvideo) or if counted in MB/s then in a high MB/s rate like 6000MB/s. For shure you cant go into the encode using a same Bitrate value as if you would go into using mpeg2 (shure u know that, just mentioned for other readers).

Im at work right now, but at home I got a very good example of a mjpeg capture of a Donald Duck Christmas tale .... so its a cartoon and it came out very nice. And I got luck as they did broadcasted it as progressive :)

I installed that and TMPGEnc reads teh AVS file but the video is awlays blank.

LS

TMPGEnc needs RGB input no?

perhaps adding "converttorgb" at the end of your script would help?

In (2 years old) release 12a yes. We are in 2.521 now ;-)

I have AVISynth working now. I had to switch from YV12 to YUY2 color with my capture and the Convolution3D filter.

I capture my 8mm analog home movies to DVD Half D1 with the PicVideo YUY2 format with a quality setting of 19.

I then encode it with TMPGEnc 2 pass VBR. 1000min, 2200avg, 3500max. Motion est High. The file comes out looking good but has some jaggy's.

This is where I run into problems. When I use VirtualDubMod or AVIsynth to smooth it out, the final encoded file has ghosting or jerkyness on fast moving scenes. Unviewable.

I even tried frameserving it with no filters at all and it still does it.

I guess my issue at hand is how do I filter the video without ruining it? I now have all the other issues resolved but filtering.

Thanks!

LS

PS: I tried KDVD but the standard TMPGEnc 2 Pass VBR consistantly created smaller files, so that is what I am using.

You have to do a file size prediction with any of KVCD or OKDVD template ! The CQ taht is set in the templates can't be used "blindly" whatever the source is. And when you will find the correct CQ that will give you files the same size than with 2pass, you will see how much the quality is better !

I found that when I start capturing before I hit play the field order was messed up. Can't exlain why it looked bad the first time I encoded Top first, but all filters work great.

I changed the PicVideo setting to 18, turned off the 2 lines if 240 option and the jaggies are all gone and quality is superb.

Thanks!

LS

PS I'm using the standard Half D1 KDVD template from this site and it produces teh same file sizes as 2 pass VBR and looks good. 2VBR is a touch smaller.

Well thats MEGA risky!!!

Because IF you capture from NTSC you will defenitely get an telecined/interlaced signal where if using not fieldbased ... a blended output will be the result = shadows in movements.
A big rule is to capture filedbased (2 lines if more than 240!).
You have to find the problem of whats guilty for the jerkyness. Framebased capturing will not be the result finally ;-)

PS: In PAL its the same as you NEVER know how the input will be (interlaced/phase shifted/norm converted from 29.97 to 25.00)

Also DON'T use PicVideo at 18! Cause the quality drops exponentially if going lower than 19.