TMpgEnc Field order judgement

[Peter van der Burgh]

I’m a bit confused about the ‘field-order’ issue.
My final question is: does TMpgEnc always make a correct judgement of the field order?

The most important parts of my config.:
* Canon stereo Hi-8 analogue camcorder (with S-video out).
* Asus V7700 DeLuxe with TV-in (S-Video) video card.
* SoudBlaster Live audio card.
* Asus CUV4X motherboard with PIII 733MHz
* Windows98 SE
* All (Asus/SoundBlaster) drivers as well as Windows are fully up to date.

I capture with VirtualDub using HuffYUV:
* Source is S-video; PAL – BGHI (25fps)
* Video format is 704 x 576; UYVY
* HuffYUV is set to Predict left

‘Overlay’ is disabled and ‘Hide on capture’ and ‘Multisegment capture’ are enabled.
I capture, using the normal capture mode (F6), about 0.5 hour at the time on a empty (partition of a) hard disk of 50GB without any problems: CPU usage is below 90% (most of the time 80%), not more than 1 field/2500 fields are dropped.
The result is a multiple of AVI files: Capture1.xx.avi and from the next capture session: Capture2.xx.avi.

I do understand that one frame contains two (interlaced) fields, the odd and even lines of a TV screen, displayed at a rate of 50 (PAL) halve pictures (fields) per second, or 25 frames per second.

With TMpgEnc, the multiple segments (files) need to be processed individually.

This is where my problem starts: Capture1.00.avi is judged to be a ‘Top field first’ interlaced video, but Capture1.01.avi a ‘Bottom field first’ video. In other words, not all Capture1.xx.avi are judged to have the same field order.
Also Capure2.00.avi seems to be ‘Bottom field first’, thus not the same as Capture 1.00.avi.

I would think that VirtualDub is starting to capture at a new frame, but the above suggests that it starts at a new field (Capture1.00 has not the same field order as Capture2.00).
I would also think that VirtualDub is switching to a new segment (file) at the end of a complete frame, but the above suggest that it is switching after a complete field (Capure1.xx files don’t all have the same field order).

I must admit, I didn’t yet burn a CD with these ‘large’ files, but during testing I’ve converted a file with all three possible settings (Top, Bottom field first and non-interlaced) and at that time the field order that TMpgEnc suggested (Bottom field first) was clearly the correct one.

Can someone confirm that:
* When I start a capture session, using the same hard and software with the same settings, the first field can vary (capture starts at the beginning of a field, not a frame).
* Segments (files) of a single capture session can have different field orders (switching is done between fields, not frames).

And actually the most important question:
* Does TMpgEnc always make a correct judgement of the field order?
* How does it do this, especially when the first part (it does not seem to analyse the whole video) of a video has hardly any moving objects?

I hope someone can increase my confidence.

I must admit that, after hours of fooling around with various settings, I’m impressed with the quality that can be achieved using the above programs in combination with my hardware.
Also the VCDHelp.com website and the links where a great help understanding video capture and compression.

And finally I found some sensible work for my computer!!! At least one and a half hour per minute video for conversion to MPeg (I’m using a bit noise reduction and the highest motion prediction during 2 pass VBR – Quality first)

Thanks for all that is coming,
Peter van der Burgh

[BJ_M]

And actually the most important question:
* Does TMpgEnc always make a correct judgement of the field order?
* How does it do this, especially when the first part (it does not seem to analyse the whole video) of a video has hardly any moving objects?

no - i have seen it goof up on guessing which...

To verify that you selected the correct field order, view the movie in the Clip window and step through the movie frame by frame. If the movie stutters, the field order may be set incorrectly.

if you are applying filter before encoding they can reverse field order .. this is a problem in many apps ..

if in doubt covert to progressive ..

IF all your clips are using the same settings and filters -- all clips should be of the same field order.

the speed you mnetioned seems VERY slow even at the settings you are using ... i think interpolation is happening.

[LanceSteel]

Yah, Tmpeg can mess it up (its done it to me a couple of times.) I usually follow this guide to figure out what field order it is:

http://www.lukesvideo.com/classifyhighres.html

Look down at the "Determine the Field Dominance" section.

[Peter van der Burgh]

Both Lance and BJ thanks for the response.
If nothing else, the confidence in my own knowledge/judgement has increased.
Knowing now that I have to re-compress most probably 50% of my files, I’ll first create another test CD with small parts of both field orders containing high motion to confirm that the outcome of previous tests (Bottom field first) is indeed the correct one for my hard/software combination.

BJ, you are saying

if in doubt covert to progressive ..

But this has to do with the field order of the source. If that one is reversed, the end result will not be optimal, no matter to what standard I convert.
I can imagine that, when converting to progressive, it does not matter (so much) which field order is used. The quality of the end result will be somewhere between right and wrong field order with interlaced output. Or am I wrong?

and

the speed you mentioned seems VERY slow

Do you really think so? This is the total time of a 2 pass VBR including noise reduction (10-1-10 high quality) and the highest motion prediction setting on a PIII 733MHz.
You are most probably right about the interpolation. I capture 704x576 (the only format I can capture in using 576 lines (PAL), the next highest is 640x480), and this has to be converted to the SVCD-PAL standard of 480x576. Since 480 is just not half of 704, there is some interpolation going on. Unfortunately I can’t capture at 720x576 (or 480x576).

Lance, thanks for the link.
I’ve seen the page before, but found it very difficult to see the field order differences on my monitor. I admit, I did not have the instructions next to me and did not spend more than a couple of minutes on it.
You reply is a good reminder and knowing what I know now I will have another go at it.

Greetings,
Peter van der Burgh

[Peter van der Burgh]

I've played with AviSynth and as a result created a new post : http://forum.vcdhelp.com/viewtopic.php?t=106944
You will see that I'm completely lost.

I did also some testing on the conversion speed:
If I convert using 2 pass VBR and no filters it will take 16 minutes/10seconds.
This is in line with the speed test in http://www.vcdhelp.com/comparison.htm (8:12 minutes using a single pass methode, computer spec and conversion settings almost identical - I used 2520kbit/s VBR - and AVI length also 10 seconds).
If I convert the same file using the Highest prediction methode and noice reduction it will take 1:20 hrs. to convert 10 seconds of AVI.
I don't know how much of the extra time is related to the highest setting and how much to the noice reduction.

Peter