Shaky DVD movie when camera pans sideways

[Vulcan]

I make DVD out of DV. Whether I use CCE or TMPGEnc the movie is shaky on sideways camera pans (not up down pans). The result is the same wheter I use a 1CCD camera or a semipro 3CCD camera.

It does not seem to be a field order problem (not a combing effect just shaky as if the camera have problem catching up). The problem does not occur if the camera is still and the objects move (e.g. when shooting from a car) but it occurs when the camera moves sideways and irrespective if whether objects are non-moving or moving. The shakiness is not noticable when playing back the DV tape directly so my guess is that it has to do with the encoding or the conversion.

Is the shakiness something that I'll have to live with when encoding from DV to DVD? I use 2 - 4 passes VBR, average 7,500 and max 9,000 and I guess that the higher bitrates are allocated to the complex sideway pan parts. Since I have the same problem whether I use CCE or TMPGEnc I don't think it is encoder related. I have also tried different field order but the shakiness is still there (even more so on the movie as such when the field order is wrong) so I don't think it is a field order problem. I live in PAL country, the video is 25 fps and interlaced and I have not gotten the framerate wrong.

Anyone have any ideas? Could it be due to the camera been set to autofocus (maybe a stupid question but I have run out of ideas) or is just that simple that DV as such is much higher quality than the resulting mpeg even when recorded at DVD rates?

[Arky]

Please post:

your computer hardware specifications

which firewire capture card you are using

which software you are using to capture with (e.g. Premiere)

the specs of your graphics card


Arky ;o)

[Vulcan]

Here we go:

The computer is a Toshiba 8100 (laptop), PIII, 650 Mhz, standard hd of 10GB, a dedicated capture disk (through firewire) IBM Deskstar, 7,200 rpm, 60 GB. The graphics gard is build in 8MB SN3.

I use ASD firewirecard for notebooks, P6 and/or Scenalyzer, MainConcept 2.04, TMPGenc and/or CCE.

I know that the computer is week/low end as regards video but I'm able to capture without dropping any frames (but the encoding process is slow). A new computer, Fujitsu-Siemens, PIV, 2GHz, 64MB nVidia GeForce 3, have been ordered and will be delivered the first week in March and if my problem is computerrelated this will hopefully take care of the problem.

[Arky]

I used to have this problem when captruing firwire DV footage, EVEN THOUGH no frames were reported dropped. I may be wrong, but I believe that you are suffering from a BUS bandwidth problem here. By asking your laptop to capture AND, simultaneously EXPORTING (to your firewire harddrive), you are placing an extraordinary amount of strain on your system's resources.

To begin with, utilise the Premiere 6 capture option which permits switching of of the video preview during capture, since this eats CPU resources and may well be contributing to your problem.

Additionally, I would suggest that you try capturing to your internal hardrive, and transferring to the external firewire HDD thereafter. I must stress that this advice is the result of personal experience, and still stands, despite the fact that no dropped frames have been reported. Just try it and let me know how you get on. Incidentally, I originally purchased an Orangelink PCMCIA firewire card, which employed an NEC firewire bridge chip, which was NOT sufficient for correct operation, particularly on export. I was foreced to purchase a new card, with a Texas Instruments chipset, instead, and this works beautifully. Guess what? It's an ADS Pyro!

So, to sum up, I know the PCMCIA card is up to the job, cos I have one myself - I believe your problem is a BUS bandwidth (which includes CPU "data-marshalling" abilities) issue.

Please follow my above suggestions and let me know how you get on.


Arky ;o)

[Vulcan]

Arky,

Thanks for the reply and I hope you are right. According to the Task Manager the CPU usage is very close to 100% on capture as well as exporting. As I said I'll get a new "high-end" computer beginning of March and I guess that will result in the bandwith problem go away. I'll follow your suggestions on my new machine and report back (but this is not likely to be until beginning or mid March).

I have also been told that the problem might be due to the encoder is less forgiving than the eye (treats the shakiness as motion and tries to adjust the output) and that shakes that are hardly noticable when playing back the DV tapes really stands out after encoding. I guess that a bandwith problem resulting in captured footage be "poor" would really make the problem even bigger.

[Nogami]

Try reversing the field order just to see what happens. Field order doesn't create a combing effect, it just looks jittery on side-to-side motion.

[Arky]

Also ensure that BOTH your PCMCIA slots are CardBUS compatible. On many machines, only one of the two Type-2 slots is up to the CardBUS spec. Also ensure that the BIOS is setup to enable the CardBUS transfer rate on the PCMCIA slots in question - this is often overlooked by users. I put my Toshiba BIOS on auto-select, cos I use a variety of different cards, and it works perfectly during capture. I also find that the standard firewire drivers in Win2k work just as well as the Texas Instruments one on the ADS installation disk, which I use only when I can be bothered to plugin my CDrom drive and find the ADS disk!


Arky ;o)

[easy2Bcheesy]

It's sounds very much like Nogami has it here with the field order.

[Vulcan]

I'll try the field order thing once again but I would be very surprised if this is the problem. It is DV material and I have the settings set to lower field first (I have been told that this is the correct setting) in P6 and for exporting.

The clip has been encoded with both TMPGEnc (2.5.1) and CCE. TMPGEnc recognizes the field settings as lower field first and encodes this way. The CCE check box is unchecked. However, no matter the setting in CCE, CCE seem to always (according to BV)encode upper field first (don't know if this is a codec (MainConcept 2.04)or encoder problem. To correct this I change (after the encode) field setting in CCE with a program named changer (changes the fieldorder without re-encoding). The CCE clip have been played back on my stand-alone with as well as without the fieldorder change applied by Changer. Without running the clip through Changer the CCE clip looks worse, i.e. I believe that lower field first is the correct setting. Don't know if the clip changes order within the clip and don't know how this can be checked.