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 :-(
|
Quote:
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 ? |
Quote:
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: |
Quote:
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 Quote:
|
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 :( |
Quote:
LS |
Quote:
@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 |
Quote:
I will do it all again and post some pics. LS |
Quote:
|
@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 |
Quote:
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. |
Quote:
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 Quote:
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 :) |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.