Problem with Big 3 output

[LEGiON-1]

Backing up some PAL TV episode disks, I've run onto some problems. After completely finishing the process I test the video in PowerDVD and it seems fine, no problems. I burn it and stick it in my DVD player and its all screwy. The framerate is all jumpy in scenes with motion, or shakey or something, not really sure how to describe it. Its screwed at any rate.

The video is interlaced, top field first with "zigzag" scanning order according to Bitrate viewer, so in DoCCE4U I set the job options accordingly - unchecked progressive, checked top field first, unchecked Alternate scan. When this didn't work I went back and checked Alternate scan - some problem, but again it doesn't do it on the PC. The video is definitely interlaced, you can see the artifacts if you run it in media player or Vdub-MPEG2.

I encoded the same disk in DVD-Rebuilder and it came out fine, no problems there (it didn't like one of the disks in the series though, hence why I'm not using it now.) Obviously either DoCCE4U or another program down the line is messing my video up, whether it be a bug or a fault of my own due to bad settings.

Any idea how to fix this problem or what the cause is? And why is it fine on PC and not my DVD Player?

thanks

[Paced]

Sounds like it was encoded with the wrong field order to me (BitrateView isn't always accurate). Download a program called ReStream from here: http://shh.dvdboard.de - now open up the affected .mpv file(s) with the program, and see if "top field first" is ticked or not. If it's ticked, untick it, set a "Destination" and click "Write" (vice versa if it is unticked to begin with). Now try re-authoring the DVD, and testing it in your stand-alone (with the new .mpv files ReStream created).

[LEGiON-1]

Originally posted by Paced
Sounds like it was encoded with the wrong field order to me (BitrateView isn't always accurate). Download a program called ReStream from here: http://shh.dvdboard.de - now open up the affected .mpv file(s) with the program, and see if "top field first" is ticked or not. If it's ticked, untick it, set a "Destination" and click "Write" (vice versa if it is unticked to begin with). Now try re-authoring the DVD, and testing it in your stand-alone (with the new .mpv files ReStream created).

Thanks, I'm reencoding the video now with top field first unchecked. I looked in the ECL file that DVD-RB used to encode and it had top_first=0 and now the DoCCE4U ECL also has that setting. So if field order is the problem, this should fix it I hope.

I'll let you know how I go.

[LEGiON-1]

OK, changing field order fixed it. Not sure what the issue was though, the original video was top field first according to both bitrate viewer and restream, then if I encode in docce4u with top field first unticked it worked fine, cept according to those programs the output was top field first anyway:confused:

Oh well, it was working so I'm happy. thanks

[Paced]

Glad you worked it out :)

[influenza]

I have on simple advice: read the http://forum.doom9.org/showthread.php?s=&threadid=53770]CCE FAQ[/URL]. It will explain why you do not check topfield first in most cases

[n1ck0s]

Now I am confused... I always encode w/ tff checked (in BatchCCEWS) and everything seems ok onto my friends stand-alone...

[influenza]

Field order only matters on interlaced material. So if you encode progressive material with a wrong flag (tff/BFF) switched it won't matter.

Encoding interlaced material with wrong field order will certainly result in jumpy playback. Unless you deinterlace of course, since that will turn your material into progressive.

I think the CCE Faq is quite clear.

[n1ck0s]

No, I am reffering to interlace material too (PAL extras). Using the "AssumeTFF" trick I find that extras are mostly interlaced and tff so I leave tff checked inside BatchCCEWS and uncheck Progressive (I don't deinterlace by the way).

According to the FAQ you mentioned, when tff, the tff should be unchecked!!! I've tested my backups and they seem ok even though tff was left as it was...

[influenza]

Well that assume TFF thing works good indeed. (as does the field order detection of tmpgenc)

What I can imagine is the following:

You're using a version of batchccews that cannot control the offsetline option used in the latest cce versions. And the standard template of CCE is set to offsetline 0, which is equivalent to not checking TFF. So in that case you get in correctly by coincidence.

Check the filed order of your encoded file to be sure. If TFF is checked the file should say bottom field first, otherwise TFF (yes this sounds odd). Run dvd2avi on your encoded file and open this dvd2avi project in tmpgenc and let it detect the fieldorder.

Then if you really want to be sure encode the file manually and make sure offsetline is set to 1 (TFF). after that check the field order.

[Trahald]

Originally posted by influenza
Well that assume TFF thing works good indeed. (as does the field order detection of tmpgenc)

What I can imagine is the following:

You're using a version of batchccews that cannot control the offsetline option used in the latest cce versions. And the standard template of CCE is set to offsetline 0, which is equivalent to not checking TFF. So in that case you get in correctly by coincidence.

Check the filed order of your encoded file to be sure. If TFF is checked the file should say bottom field first, otherwise TFF (yes this sounds odd). Run dvd2avi on your encoded file and open this dvd2avi project in tmpgenc and let it detect the fieldorder.

Then if you really want to be sure encode the file manually and make sure offsetline is set to 1 (TFF). after that check the field order.

actually batchccews does honor the top field first setting with cce 2.67... but what happens is.. if you have top frame first on it sets offsetline to 0... which works fine.. and if you dont check top frame first it does set it to 1 (bff) .. so basically its the opposite of when you use batchccews with say 2.66.. so what im doing now with batchcce/cce2.67 is.. i have dif4u set to inverse the field order.. when batchccews sees bff in the filename it checks top frame first ... and my resulting output is fine.

[influenza]

so what im doing now with batchcce/cce2.67 is.. i have dif4u set to inverse the field order

Yes that's exactly what the function is for. Some miscommunication between eyes`only and bbwoof I believe.

[n1ck0s]

My setup is batchccews v0.9.1.3/cce v2.67.00.23 and I do have 'inverse field order' checked, so no worries then.

Thank you all for your replies.