DV CODEC for VHS Capture?

[enbidia]

Can I use DV CODEC for VHS Capture? In my understanding VHS video is top field first while DV CODEC is bottom field first so how can both fields joined together correctly and w/o becoming jittery during playback?

[edDV]

What hardware/software are you using to capture?

[enbidia]

Nvidia Geforce 5700, IUVCR and Canopus DV CODEC

[edDV]

Nvidia Geforce 5700, IUVCR and Canopus DV CODEC

Not with that hardware. DV is usually hardware encoded.
Bettter to capture uncompressed, edit/filter and thenencode to DVD MPeg2.

[enbidia]

Ucompressed format is too big and the video is 2 hrs. I don't think I have enough drive space for it. What hardware or CODEC do I need for VHS transfer?

[edDV]

Ucompressed format is too big and the video is 2 hrs. I don't think I have enough drive space for it. What hardware or CODEC do I need for VHS transfer?

Best solution is a MPeg2 or DV hardware capture device*. Software encoding requires a very fast computer, still falls short in quality and has many ways to drop video frames to seconds.

Current CPU's are getting fast enough to realtime software encode MPeg2 but still need hardware to handle HDTV.

* e.g Hauppauge PVR series or Canopus ADVC or similar.

[enbidia]

But even with hardware I still have to resolve this field order problem. I got this video jittering problems using the Canopus DV CODEC

[edDV]

But even with hardware I still have to resolve this field order problem. I got this video jittering problems using the Canopus DV CODEC

I haven't used IUVCR but most editing programs or encoders allow TFF or BFF project settings. I've never run into this problem.

Ucompressed format is too big and the video is 2 hrs. I don't think I have enough drive space for it.

Alternate codecs that are less CPU or HDD capacity intensive are MJPEG ( PicVideo ) or HuffYUV. Either will bring file sizes down to ~ 25-35GB/hr

[zoobie]

You've switched the fields and it's still jittery?
Check cap in gspot or mediainfo and see what the scoop
Post more info

[vhelp]

enbidia,

I think that you are confusing the two w/ regards to Field Order.

It doesn't really matter what field the VCR is shooting outward, but rather
what your capture device is inputing to your finished AVI file.

** if you are using an hardware MPEG capture card, check to see if there is
any provisions to changing the Field Order. There should be. You can check
with SHS website (for the url) and you might find info there, regarding the
Hauppauge PVR-250 capture unit.

** if you are using another hardware MPEG capture card, you should probably
check to see if they have any options to change the Field Order. for intance,
on my ADS DVD Xpress (hardware MPEG) unit, there is a feature to change the
Field Order.

** if you can't find any options to change in the above hardware MPEG units,
then chances are, there was no specific feature added into the software they
provide - at time of presentation. But, you can still change this through
the avenue of "hacking". But that get's complicated.

** if you are using an Analog Capture card, then what is required as knowledge,
is how your AVI and Codec is setup. Some codecs have a feature param that you
can change for UP/Down field order. MJPEG has this, for instance.
The Huffy codec has a semi param of this under its setup dialog, but its not
entirely the same thing. It's more or less a FieldSwap() feature.

** however, w/ regards to Analog Capture and Huffy or other YUV (YUY2.422)
type codec, or DV codec, used in capturing.. the deciding factor in Field Order
setup can be determined and setup inside the software MPEG Encoder appplication.
But you also have to know a few things - knowledge as well.

For instance, say you used a DV codec to capture with.. Then, its a known fact
that DV sets the image data as Bottom Field First. Thus, inside TMPGnec, you
would setup this encoder to encode your video as BFF.

If for instance, you used Huffy codec to capture with.. Then, its also a known
fact, that with this codec, your Field Order will be Top Field First, or TFF.
Thus, you would setup TMPGenc to encode your video as TFF.

Codec, In short:

** DV sources is BFF
.
** MJPEG is user selectable for TFF or BFF
** RGB/YUV/Huffy and some other codecs are TFF

Thus, weather your source medium is Cable, Satellite, VCR, Laserdisc or DVD,
your Field Order will have to be changed only according to your codec.

( MPEG is sometimes seen as a codec as well, and it is usually TFF unless
otherwise changed by the user. )

-vhelp 3925

[enbidia]

I'm not sure of about this VHS thing. I came only to this conclusion that VHS playback is TFF by experimenting with different CODEC settings. I am aware that some editing or transcoding software such as Canopus Procoder has options for choosing different field orders during playback/decoding than how it was originally encoded. Despite of that I still want to have it encoded correctly at the onset for i'm not sure if it would affect image quality in addition to jittering for not doing so. Please enlighten me more about this technical stuff. Thanks

[vhelp]

As I was trying to say earlier.. It doesn't matter on the units you are
capturing from, ie.. vcr; cable; antenna; laserdisc; dvd player, etc.

What matters is the knowedge you have about the Codec and the MPEG Encoder
and how they both interact/process the video.

Software MPEG Encoder's are usually featured with a param option to encode
to a given Field Order, (FO) ..But this FO is driven by the AVI source
setup, and is usually codec featured.

Now, knowing that you can change FO, you can encode your videos with FO set
to BFF or TFF. But, doing so, blindly, can result in video playback issues.
But this is usually stand-alone dvd player driven. Most dvd players will
hickup (jitter) the video during playing. I forget the techy explanation,
but you'll know when you see your video hickup or act funny.

( DVD, when used as a source to encode, (ie, dvd rips) does not suffer from
this when it is true progressive and kept that way, straight through your
MPEG encoder.. in this case, FO setup does not matter. )

Scenario A - a HUFFY codec experience:

Now, lets assume you want to capture from your VCR (a vhs tape) and you
decide to use the Huffy codec.. so, you capture from this vcr and now have
an AVI who's stamped with the Huffy format.

You proceed to frameserve this into TMPGenc, to encode an MPEG out of this
captured Huffy AVI file.

Because the Huffy format image is TFF, you would setup TMPGenc's FO to
TFF.. setting\advanced\field order: [Top field first (field A) ] and proceed
to encode your MPEG.

Note, if you had captured from another medium, say a Laserdisc; dvd player;
Cable; Antenna; etc., it would still require a TFF setup.


Scenario B - a DV codec experience:

Now, lets assume you want to capture from your VCR (a vhs tape) and you decide,
this time, to use a DV codec.. so, you capture from this vcr and now have an
AVI who's stamped with the DV format.

You proceed to frameserve this into TMPGenc, to encode an MPEG out of this
captured DV AVI file.

Because DV standards for image makup is BFF, you would setup TMPGenc's FO to
BFF.. setting\advanced\field order: [Bottom field first (field B) ] and proceed
to encode your MPEG.

Note, if you had captured from another medium, say a Laserdisc; dvd player;
Cable; Antenna; etc., it would still require a BFF setup.


So, in closing, again I say,

Codec, In short:

** DV sources is BFF
.
** MJPEG is user selectable for TFF or BFF
** RGB/YUV/Huffy and some other codecs are TFF

-vhelp 3927

[enbidia]

I got your illustration this time however I had done both scenarios above but with Canopus Procoder. For Scenerio B on Canopus Procoder with DV as source the video becomes jittery when transcoded to DVD and playback on TV however if I reverse the FO of the Source to TFF the transcoded video is OK. Switching FO of the Target eg. MPEG2 doesn't have any visible effects on the video

[vhelp]

hmm.. what is your capture card that you are using ?

-vhelp 3929

[enbidia]

GeForce 4200 Ti and the video capture chip is IDT QS3257Q.

[vhelp]

To be quite honest, I'm not familiar with that style capture card.
But, I fail to see why you have to setup FO for TFF.

But, if that is what works, than perhaps somehow you capture card is
forcing the image data in the oposite direction, and throwing off your
Field Order orientation. In the mean time, since acording to your
experience, TFF setup works.. so just stick to what works in this case

-vhelp 3930

[enbidia]

Bringing us back to square one. Does VHS output really has no field order? Let me illustrate. If for example a video source is TFF then each frame in the video will be rendered with upper fields first then lower fields and so on... Supposedly we use DV CODEC for capture of this video source. Since it is BFF then it would start its capture bottom field first. If thats the case wouldn't we end up blending bottom fields of the frame 1 with the upper field of frame 2 and so forth for each captured frame which could explain the jittery?

[zoobie]

I knew I read that vhs has no field order...
https://www.videohelp.com/forum/viewtopic.php?t=257631

[enbidia]

I also read in another forum which said that 'VHS uses "top field first" dominance' I played the converted video frame by frame and noticed the top fields and bottom fields misalign very much when using BFF setting on this home-made VHS tape. It has ghost-like after images when freeze.
http://episteme.arstechnica.com/groupee/forums/a/tpc/f/67909965/m/2740970585

[edDV]

VHS is analog NTSC (or PAL). Fields sequentially alternate between odd lines (top field) and even lines (bottom field). TFF vs BFF is an issue only when the video is digitized. The digital NTSC convention seems to be BFF reference where digital PAL traditionally uses TFF (except DV format which is always BFF).

The problem shows up when the digital video is presented to an interlaced monitor. If the fields are constructed in the reverse order, vertical jumping occurs during motion.

Best way to deal with this is to make a test clip (containing vertical motion) and encode it both ways TFF and BFF. Then play the files to an analog TV and see which one doesn't jump during motion.

[enbidia]

Could you explain why VHS capture seems to favor TFF in my case or is there other technical reasons? My standard is NTSC.

[edDV]

Could you explain why VHS capture seems to favor TFF in my case or is there other technical reasons? My standard is NTSC.

That should be a capture card issue. Analog NTSC (and "VHS") has no field order, it just alternates odd and even fields as determined by the sync source. When NTSC is digitized, the capture device needs to ID a field sequence.

[enbidia]

thanks, I'm going to do some more testing with different CODECS and capture cards and will give more feedbacks later.

[enbidia]

Tested MainConcept DVCPro CODEC and it still favors TFF despite the CODEC being BFF. Jittery is noticeable even on progressive PC monitor when BFF decoded and converted to MPEG2. Can anyone explain to me why???

[vhelp]

>> Can anyone explain to me why???

Not entirely.

I'm starting to think that the cause in on account of your VCR -- tracking.

You might be able to perform a test w/ your vcr..

** Start your vcr, and press play.
** Turn on DISPLAY, (where you can see the tape counter)

Now, observe the tape play. If you see your "tape counter" jitter or
wobble up/down every so often or randomly or whatever, then you *might* have a
tracking problem, hence your image's being missread (BFF vs. TFF) or something.

I have an older VCR (1987'ish) and it's tracking fairly bad. Sometimes I have
to adjust the tracking-knob (on this older generation unit, it's a tiny nipple-
like screw, that has to be turned LF/RT) and on this 1987 unit, sometimes I
have to turn it all the way right. In other words, this unit is in bad shape..
but it still works for my needs.

-vhelp 3933

[edDV]

Your capture device is the cause. The Mainconcept DVCPro codec has a field reverse switch. If BFF jumps use TFF.

Why are you using the DVCPro codec for VHS? Save your money. Don't you realize VHS only has 500-700 KHz analog bandwidth in the chroma? Regular DV has more than enough bandwidth at 1.75MHz (3.375Ms/s).

[enbidia]

I don't think its tracking problems because the quality of the recording is good and don't have horizontal streaks. I just uploaded a screenshot to show how both images look. For the left side the source is set to TFF while the right side the source is set to BFF and both are converted to DVD compatible MPEG. I don't think DVCPro CODEC field reverse switch has any effects on the capture. TFF setting is still needed to encode properly. Personally, I think VHS visual quality is not that bad despite the specs. Despite the low bandwidth for the chroma however its still much better than VCD. IMO I think it has to do with how the low resolution of the chroma is being arrange or distributed on the screen either stochastic or dithered. Its precisely the same way also for inkjet printers despite that its only 720 DPI however the image quality is more photorealistic and smoother than a 2,400 dpi offset print. Another thing I think is VHS is being MJPEG type which do not have temporal compression between frames and has therefore higher bandwidth in between frames compare to MPEG. If you can provide me a space I can upload the whole 60+ MB comparison. You have to set interlace to field shift to clearly see the jittering on progressive monitor.

[enbidia]

Please click the image above to zoom it to 100%

[edDV]

It looks like the left picture (TFF) is the correct setting for that capture device and encoder. There is no vertical motion going on, only normal horizontal field tear. The right picture shows evidence of vertical displacement.

My only point on VHS was the use of the DVCPro codec (4:1:1 or 4:2:2 for DVCPro50) vs normal DV. If you already paid for it, no problem but I doubt there is any benefit to using DVCPro over DV for a VHS source.

[enbidia]

Haven't bought it yet. What is the the color sampling of normal DV?
Its hard to compare apple to oranges. I don't think the color resolution of VHS is measured the way it do with digital video. But if DVCPro is only 4:1:1 (180 chroma samples per line) wouldn't some parts of the image become loss during capture?