DV 2 MPEG2 - bad interlace conversion?

[adboehm]

I am trying to convert my captured DV to DVD compliant MPEG2 files with TMPGenc, with no loss in the rates of fields per second.

MY specs: P4 2.6, 512mb ddrram, 40 gig free, Geforce4 Ti4800se, firewire. Camera - JVC GR-DVL300.

The source files are PAL DV 720x576 interlaced, and were captured with Adobe Premiere v6. The footage is of fast cars racing around a corner, and panning as they go past. I want the footage to be as smooth as possible, ie 50 visible fields per sec. The aimed format of course is tv.

Now, the footage was quite bumpy, so to deshake it I have used virtualdub with Gunnar Thalin's Deshaker v1.6, and exported with Huffyuv v2.1.1 and uncompressed audio. I converted this back to DV using Premiere to conserve space for the time being. If I export these back to the camera, there is no apparent loss in quality, and it is smooth as (still interlaced perfectly).

To convert these to DVD, I tried both TMPGenc b12a and 2.5. I used the PAL DVD spec with VBR (MPEG-2 720x576 25fps VBR 7000kbps, Linear PCM 48000Hz 1536kbps). Video source is interlaced, so I made sure the Encode mode was interlace.

To preview these MPEG2 files for comparison to the original DV, I tried two ways.

I tried comparing these using PowerDVD v4 (with hardware decoding enabled). While the DV is really smooth, the MPEG2 seemed to stutter at 25 frames per second. I realised it was because PowerDVD was deinterlacing via the bob method. I changed the setting to 'Force weave', and the scan lines were then visible, but it still seemed not quite the same smoothness.

To check that it was not PowerDVD, I tried saving the MPEG2 file back to DV (with Premiere), and exported the video back to the camera. It appears on the camera and via camera to tv that TMPGenc has lost half it's fields (ie every second field), and made every second field the same as the first field. Pausing the video on the camera confirms this - no sign of interlaced movement (still image, no apparent switch between different frames).


Perhaps should I try some other MPEG2 encoder?

[adboehm]

I have now tried CBR-4000, -6000, -7000, VBR-6000 (max 8000 min 2000), and a few other combinations, as well as trying odd or even field first (technically even should work) but there appears to be no difference between either. There should be an obvious difference when the cars move across the screen, but either way motion looks like 25 progressive fps instead of 25 interlaced fps.

I filmed with a 1/500 shutter speed, so differences between fields is quite noticable when something 'goes wrong'.

It seems that the only way to get the result of both fields the same as DV is by compressing with MPEG-1 720x576 @ 50fps progressive (using deinterlace both-2fps).

Does anyone else have this problem?

[Richard_G]

If you are going to be playing it back on a TV, why don't you just save it in the format that a TV wants to display, 720 x 576, 25 fps, interlaced? It will save you all this grief and you'll end up with something that should look as good as the original.

[BJ_M]

the second conversion back to Dv from huffy really killed quality as it would have been compressed with ms dv codec at that point -- better to install main concept dv codec , which works with v-dub and render directly to that if you want to save space ...

also -- did you select bottom field first in tmpgenc ? - which is standard for DV ..

[adboehm]

Richard_G - That is what I am doing. The problem is that the 720x576i@25 encoded files look progressive, instead of the motion looking smooth.

BJ_M - Bottom field first = even field first. Just different terminology. I tried both top and bottom field first, even though bottom should be for DV, but the result looks the same - only half the fields are being shown, ie looks like 25fps progressive. As for the codec, I shall try main concept. Thanks so far

[adboehm]

I have looked further into this, and I was about to say that it seems to be nothing to do with the DV codec, as the re-encoded DV file from the deshaked huffyuv looks perfect motion-wise (which is my number 1 priority).

But then looking at a thread over at the tmpgenc forums http://bbs.pegasys-inc.com/bbscgi/search/docs/en/tmpgenc/box53/tmpgenc_post_20655.html, it may seem that tmpgenc might be using a bad dv codec to read the dv file, or else totally misunderstands the dv field operations. That could explain why when I try either top field or bottom field first, the result looks the same (theoretically bottom should be the original encoding). Either that or else tmpgenc misunderstands the fields of dv 2 mpeg2. Soon I'll try AVISynth and CCE as on the Doom9 guide to see if there's any difference there

[guns1inger]

I am using tmpgenc plus and have the same issue. No matter what settings, PAL DV always comes out looking very poor. I also use Vegas 4 for editing, and have found the Mainconcept Mpeg2 encoder included with Vegas to produce very good results with DV source footage. There is a standalone version of the encoder but it is not freeware.

[adboehm]

The Doom9 guide I refered to can be found at http://forum.doom9.org/showthread.php?s=002f66319c878a5b512097ffccb38882&threadid=60392. Currently having problems with AVIsynth, but shall be fixed sometime soon.

[RoopeT]

TMPGEnc encodes interlaced material as frame-based 25 fps interlaced. With Canopus Procoder you can encode your footage as field based interlaced. There's quite a big difference with MiniDV material when using this setting.

[adboehm]

I finally burned by tmpgenc encoded mpgs to dvd - and the motion is fine. Previews via playing in PowerDVD and Intervideo DVD were unreliable. TMPGenc is fine for motion. The conversion from MPG2 2 DV was unreliable as well. Turned out to be no issue at all.

[BJ_M]

TMPGEnc encodes interlaced material as frame-based 25 fps interlaced. With Canopus Procoder you can encode your footage as field based interlaced. There's quite a big difference with MiniDV material when using this setting.

you CAN use field based in procoder -- but doing so will make your mpeg2 files non dvd compliant and non readable in some players .