Motion Blur

[djackson]

DVD-RB .2x - .34
CCE 2.67 (4 pass)
ECL 1.8b
Fraiser, Season 1 Disks 1&2 PAL Region4

I've been using the Big3 for some time but also experimenting with DVD-RB.

I seem to keep getting hit with motion blur when the scene is panning across the set. I've tried various versions up to 0.34 with simular results. "Frasier" being a very low motion intensive is driving me more mad. Have tried setting the 'Decomb' option but still no success.

To make matters worse my results are inconsistant between encodes, some high motion DVD's are fine (Tomb Raider 2) [apart from stopping 1hr into watching it, which may be a media prob "Princo"] and waiting on a full rebuild to retest is frustrating. I tried editing the .ecl file to only encode 1 segment to speed up testing, but the rebuild phase failed.

I've been following the never-ending thread but have not seen an answer.

I appreciate all the work that has gone into DVD-RB by jdobbs.

Any and all suggestions appreciated.

ADDED: This was supposed to go in the main thread, but clicked the wrong button. One of the joys of being new.

[bodhead]

At last someone with the same problem,i have tried red dwarf series 5 disc 1 PAL,about 6 times now,its gotta be an interlace problem,but but everybody is going on about this chapter stutter this keeps getting buried.
i tried THE OMEN pal,film ok,thats progressive,the extras r interlaced,used all default settings in dvdrb,NO Decombe.
no go all the extras r blurry,not like the original at all,does this in power dvd,and standalone.red dwarf does all the way through its interlaced.sounds like a FIELD PROBLEM but cant select any.seen this before with svcd2dvd but they fixed it somehow with an option keep interlaced.

anyway thanx for a cool program.

[djackson]

You could be right. I remember having simular probs when starting out with the Big3 and the CCE "TFF" feature as set by DoCCE4U. Playback in PowerDVD is OK, just the standalone. I've had probs with extras in the past too, with poor quality, have always assumed that was due to the lower starting bitrate of the extras, you can only compress things so far.

UPDATE: Bitrate Viewer shows the VOBs as interlaced, and the DVD-RB .avs files show interlaced=true

[babaz]

DVD-RB 0.34
CCE sp 2.67.00.23
Ecl 1.8 (latest)
source material: "home made" 704*576 PAL Fully Interlaced (recorde via an hardware standalone codec)

mee too having this nasty ghosting effect, using powerdvd or my xbox to replay it back

i've encoded some REAL interlaced PAL centents (it's a 704*576 - broadcast- stream with AC3 2chan audio ... as i said it's FULLY interlaced)

backed it up with DVD-RB leaving inerlace ON, gives an "horrible" warbling/ghosting effect along the entire movie (but being unmistakably visible during left/right panning)

i've not tried a fully hardware dvd player (xbox is just like a software driven pc...) thus not being able to reproduce the common situation

FYI try to display back your ghosting movie with Media Player Classic from Gabest (get the latest) using his internal MPEG decoder... no ghosting at all!!! (but this is not surprise to me... whereas powerdvd xp shows *superbly* true interlaced content, mpc seems always to deinterlace/blur it)

so to me this is maybe a BAD FLAGGING issue with DVD-RB
to me it's just like the frames are not correctly flagged as "interlaced" thus cheating the playback into powerdvd and other software-based playes...

just my thought ('coz it's a pain in the ass to re-encode a 3:15 movie.... damn!)
:p

UPDATE: it seems that this problem (ghosting) is visible when using direct hardware-aided decoding into powerdvd (and xbox, i suppose) - infact forcing hardware support OFF into powerdvd it plays back fine just like using MPC (as stated above)

so there's definitely something that tricks hardware in doing something it shouldn't do...

[babaz]

as i said, i was tryong to "tweak" the progressive/interlaced flags to see the results...

now i demuxed the .vob files
using re-stream i opened the .m2v video part, now it shows the stream has Top First Field enabled!
disabled it and rewrote the .m2v

it works!!!

playing back the newly written .m2v (without TFF enabled) plays back nicely and smootly into powerdvd (and my xbox too)

so definitely there's some glitch into DVD-RB (up to 0.34) dealing with real interlaced sources
;)

[Joergen]

so definitely there's some glitch into DVD-RB (up to 0.34) dealing with real interlaced sources

No there isnt. I've done FOUR episodic discs with full interlaced sources and they work fine on standalones and on software players.

But there MIGHT be a problem if the original is authored so that the field order is reversed and somehow DVD-RB doesnt detect it.

But a reversed field order doesnt appear as "ghosting" .. it appears as jumping or warping stutter when things are in motion. To me, ghosting sounds like blend deinterlace where two frames form one overlapping eachother.

[babaz]

so maybe is misused the "ghosting" word
actually, i experienced a very visible warbling/NOT-fluid motion expecially with camera pannings

anyhow, disabling TFF (as mentioned above) completely solved my issue
i endorsed responsibility to DVD-RB just because i took the original source (704*576, PAL Fully Interlanced) and feed that to DVD-Rb
the output was still interlaced (as i wanted to) but with a flag that prevented proper playback (at least onto powerdvd xp and my xbox...)

that's it ;)

[Joergen]

babaz: it's great you found a problem and the solution.. I hope jdobbs will get the chance to sort it out.

[djackson]

@babaz

How did you switch off the TFF option? I've checked both the DVD-RB and Big3 .ECL files and they both have top_first=0.

[babaz]

DVD-RB ends up withe the .vob files ready to be burned...
i demuxed the vob files and run restream on each .m2v video stream (when u load the video stream, program shows TFF checkbox enable... untick it!) then save
then remux (i do it via Ifoedit...don't ask)

admittedly this was a pain in the ass but for sure i was not going fro another 10 hours encode, for the sake of it

so i've just found a nice workaround, this is still no good solution for the average DVD-RB user (a newbie, i suppose :p)

but, hey... DVD-RB is updated ona daily basis... so who dares to complain? hats off to you jdobbs, and all betatesters :)

[bodhead]

cheers babaz for finding the solution,its been driving me mad.
lets just hope jdobbs reads this thread.

[jdobbs]

@babaz

I guess the part that confuses me is how the TFF could be set if it wasn't set in the original???

DVD-RB records the TFF flag as it scans the file and creates the .D2V.

Just for grins... I'd be interested in seeing the results if you went back and demuxed the original source to see if it was TFF...

[jdobbs]

I just had a thought (that's news in and of itself)... Does anyone have any sources that they KNOW absolutely are BFF? See if these come out consistently wrong... it could be that I am making a mistake by setting the .D2V the way I do -- MPEG2DEC3DG may bring the frame in correctly interlaced and adjusted for the BFF, and I then may be reversing it by reinserting the flag during rebuild!!!

[Joergen]

No such luck finding a source like that.

I've just watched through the Gladiator extra's disc R2 that has an assortment of interlaced, progressive (trailers) and still picture material (although those were copied as-is I believe the VTS_04_1.VOB being 46MB) and its all roses again. Really amazed at the quality again eventhough I caused it to undersize with the titlesetblanker thing.

Thank you jdobbs, I'm still a happy camper!

[jdobbs]

Originally posted by Joergen
No such luck finding a source like that.

I've just watched through the Gladiator extra's disc R2 that has an assortment of interlaced, progressive (trailers) and still picture material (although those were copied as-is I believe the VTS_04_1.VOB being 46MB) and its all roses again. Really amazed at the quality again eventhough I caused it to undersize with the titlesetblanker thing.

Thank you jdobbs, I'm still a happy camper! The titlesetblanker thing is interesting. I made the assumption in my code that I'm working from a pristine DVD copy... and that there would be no "junk" in the original directory. It just shows you what can happen when you make assumptions.

[Joergen]

Originally posted by jdobbs
The titlesetblanker thing is interesting. I made the assumption in my code that I'm working from a pristine DVD copy... and that there would be no "junk" in the original directory. It just shows you what can happen when you make assumptions.

Yep, though I think Titlesetblanker is about the only one that leaves junk files in the dir, although its a brilliant feature cause you can bring back the original files in a flash if something goes wrong, and I was used to DVDShrink ignoring the files aswell.

[djackson]

I'll check when I get home what the created VOB shows (TFF/BFF), also will set top_first=1 to check if any difference with an encode.

[jdobbs]

I just remembered I have a disc that has some strange switching between TFF and BFF -- it's the 2nd Disc of the Cosmos series. It's really weird and caused me fits. I have it running on my video computer right now. I'll see what happens to the BFF section.

[RB]

jdobbs, remember that one quirk of CCE is that it will always flag the encoded stream TFF, no matter what you set "Upper Field First" or "Offset Line" to. Setting these options to 1 just causes CCE to shift the video up by one line, this is the CCE way to convert from BFF to TFF.

So to make sure the field order is not changed by CCE, always disable "Upper Field First" or set "Offset Line" to zero, then disable TFF flag during muxing when necessary.

About "BFF on DVDs": I have only seen this with picture_structure == FIELD_PICTURE streams. I have one PAL DVD where when you create the D2V with DVD2AVI, the D2V has all zeroes (0 0 0 0...) But it's also all field pictures (not frame), meaning every field of an interlaced frame is stored as a separate picture in the stream. I have found that in this case the TFF flag cannot be trusted, i.e. although the D2V indicates BFF, it's really TFF. When you load this D2V into an AVS and check the field order, for instanceMpeg2Source("D:\field_maybe_bff.d2v")
AssumeBFF()
SeparateFields()you clearly see that it's not BFF because horizontal movement is stuttery/jerky.

I think maybe the TFF flag is not even used for field pictures because the fields are stored simply in "display order" and as such Mpeg2Dec3Dg will always assemble a frame by taking the first field in the stream as top field.

Just my 2 cents.

[djackson]

Have done further testing.

1. Orig source VOB is set to TFF in ReStream and Bitrate Viewer
2. Encoded source VOB (top_first=0 in .avs file) is set to TFF in ReStream and Bitrate Viewer, both after encode phase and after rebuild phase
3. Encoded source VOB (top_first=1) is set to TFF in ReStream and Bitrate Viewer, both after encode phase and after rebuild phase

On further watching the re-encoded DVD it seems to start out OK at each chapter break, start to blur/jitter with motion, come back in sync during the chapter and repeat the whole process again (blur/sync/blur/sync...). The time taken to go thru this sequense is also not constant.

CCE also alternates between Open/Closed GOP while encoding, I've never seen this with the Big3 method.

Not sure if this helps (or confuses things more)...

[jdobbs]

Originally posted by jdobbs
I just remembered I have a disc that has some strange switching between TFF and BFF -- it's the 2nd Disc of the Cosmos series. It's really weird and caused me fits. I have it running on my video computer right now. I'll see what happens to the BFF section. Well, this DVD came out perfectly. By the way -- :p DVD-RB is the only one-click encoder to do it correctly.

[jdobbs]

Originally posted by RB
jdobbs, remember that one quirk of CCE is that it will always flag the encoded stream TFF, no matter what you set "Upper Field First" or "Offset Line" to. Setting these options to 1 just causes CCE to shift the video up by one line, this is the CCE way to convert from BFF to TFF.

So to make sure the field order is not changed by CCE, always disable "Upper Field First" or set "Offset Line" to zero, then disable TFF flag during muxing when necessary.

About "BFF on DVDs": I have only seen this with picture_structure == FIELD_PICTURE streams. I have one PAL DVD where when you create the D2V with DVD2AVI, the D2V has all zeroes (0 0 0 0...) But it's also all field pictures (not frame), meaning every field of an interlaced frame is stored as a separate picture in the stream. I have found that in this case the TFF flag cannot be trusted, i.e. although the D2V indicates BFF, it's really TFF. When you load this D2V into an AVS and check the field order, for instanceMpeg2Source("D:\field_maybe_bff.d2v")
AssumeBFF()
SeparateFields()you clearly see that it's not BFF because horizontal movement is stuttery/jerky.

I think maybe the TFF flag is not even used for field pictures because the fields are stored simply in "display order" and as such Mpeg2Dec3Dg will always assemble a frame by taking the first field in the stream as top field.

Just my 2 cents. Yes, TFF would probably have no effect because each field is individually tagged with a value of BOTTOM_FIELD or TOP_FIELD in the picture_structure. But when CCE gets it delivered from MPEG2DEC3DG.DLL it is no longer in that form. It is assembled into a frame with the fields in their proper position. I would hope that then the TFF is significant -- not sure though, this is something worth a little research.

ADDED LATER FOR ACCURACY: Actually it is the combination of MPEG2DC3DG and AVISYNTH that presents it as a frame to CCE.

[digidragon]

This is my first attempt at using DVD-RB, and everything appeared to go well.

But the rebuilt DVD plays back with motion blur. I'd seen something similar to this before with an mpeg and it was because the field order was wrong. I altered that mpeg using ReStream and the blur disappeared.

However, I opened both the original and rebuilt VOBs in ReStream and the field order is the same. But the blurring still looks the same as in the mpeg with the incorrect field order.

I don't know if this is relevant, but according to ReStream the m2v files created by DVD-RB have a frame rate of 23.976 and the top field first flag set. But in the original VOBs
the frame rate is 29.970 and the top field first flag is off.

I didn't alter any settings at all, I just clicked the three buttons and let it do its stuff.

DVD-RB: 0.35
AviSynth: 2.5
CCE: 2.67 with EclCCE

[jdobbs]

Originally posted by digidragon
This is my first attempt at using DVD-RB, and everything appeared to go well.

But the rebuilt DVD plays back with motion blur. I'd seen something similar to this before with an mpeg and it was because the field order was wrong. I altered that mpeg using ReStream and the blur disappeared.

However, I opened both the original and rebuilt VOBs in ReStream and the field order is the same. But the blurring still looks the same as in the mpeg with the incorrect field order.

I don't know if this is relevant, but according to ReStream the m2v files created by DVD-RB have a frame rate of 23.976 and the top field first flag set. But in the original VOBs
the frame rate is 29.970 and the top field first flag is off.

I didn't alter any settings at all, I just clicked the three buttons and let it do its stuff.

DVD-RB: 0.35
AviSynth: 2.5
CCE: 2.67 with EclCCE That's done purposefully -- its a part of the way that DVD-RB keeps the original form of the video. It really wouldn't matter if you changed it. The stream is recoded back to its correct frame_rate and flag settings at REBUILD time.

I've gotten a few reports of this happening and I wish I could figure what causes it. Is there anything you can put your finger on that is unusual about the DVD you've done?

What I'd like to do is create a test version of DVD-RB for you. I have an idea what may be causing this and want to see if it helps. I'll make the changes and post it in this thread tomorrow.

ADDED: Do you still have the .D2V file from your encode? I'd like to see it. Could you post the first page or so of it?

[digidragon]

Thanks for the reply.

I'm not really sure what's considered unusual, but the first VOB (VTS_01_0.VOB) which contains the menu(s) has a progressive frametype flag and a TFF flag. But the rest of the VOBs (the movie) don't have those flags.

I don't remember deliberately deleting any files, but can't find any d2v files, only m2v files.

[jdobbs]

Thats okay. I think I know what's happening. The original source was BFF interlaced. I think (as I mentioned in an earlier post) that it is being "corrected" when it is served as a frame, and then is being "uncorrected" when I put it back. We'll see tomorrow -- I need to go to bed...

[digidragon]

In case it wasn't clear, the VOBs I mentioned in my above post were the VOBs from the original DVD, not the rebuilt VOBs.

[zeus163]

It sounds like I should wait until tomorrow to try Great Teacher Onizuka again. I ran the files through restream, but that didn't seem to work. It could be that I made a mistake. I just opened one of the .vob files in Restream (from the original ripped dvd) and it should it tagged as TFF. This is the same thing that the CCE ones showed, but there was definitely something weird going on when I watched it. Hmmm...

I'll try again tomorrow when I get home from work.

[Joergen]

Perhaps the decoder used to decode the mpeg2 flips the fields on its own. This might even cause a stutter at the start of a chapter when the field order is flipped around.

I hope jdobbs can look into this field order bug as a few of you seem to have it.

[jdobbs]

Alright... try the attached test version of DVD-RB. It makes corrections for BFF interlaced sources that are processed by CCE. Let me know if it works and I will incorporate it in the "real" version.

Thanks.

[Paced]

Originally posted by jdobbs
Alright... try the attached test version of DVD-RB. It makes corrections for BFF interlaced sources that are processed by CCE. Let me know if it works and I will incorporate it in the "real" version.

Thanks.

I just did the "Prepare" phase with this new build (on BFF material), and it set top_first=1 in CCE 2.50 (which is right). Then, I went back to 0.37, tried the same BFF material, and it set top_first=0 (wrong). So in conclusion, I think you've fixed it. But it's probably best to wait for other tests to come in.

[jdobbs]

There's more to it than just that. It needs to be encoded and rebuilt before we know if it works. I added "intelligence" so it won't get set back to BFF during REBUILD.

[Paced]

Oh OK, I wasn't aware DVD-RB was switching it back to BFF during the REBUILD stage.

That being said, I authored a 10 minute DV BFF clip, and after Preparing, Encoding, and Rebuilding, BitRate Viewer reports DVD-RB's output as: Field topfirst: Yes. Whereas, if I open the source .vob I used, it says Field topfirst: No.

[jdobbs]

Way cool. Thanks. I assume it plays alright?

[Paced]

Well, for fun, I extended my tests, and this time I authored a DVD with three chapters (chapter1=progressive, chapter2=TFF material, chapter3=BFF material). I put it through DVD-RB (Prepare), and it set the tags correctly for all three chapters. Then I continued Encoding + Rebuilding, burnt it on a DVD-RW, placed it in my cheapo XMS-1050 DVD player, and everything played fine (no stutters were present on the TFF and BFF material). But again, I would wait for other comments before getting your hopes up.

//Edit

I guess for this test to be more relevant, I should test it on DVD-RB 0.37 also, and see if I get the stutter during the BFF chapter.

[bodhead]

ok great news,i just tried a test with one of the extras from THE OMEN Pal,and its working GREAT no stutter,i am off to work now,i will encode the full disc will post my findings later,but this has got to be it, solved at last.

thanx jdobbs.

[Paced]

Yep, confirmed (for me anyway), 0.37 causes stutter during the BFF chapter when I perform the same test I did with 0.38.

[jdobbs]

Another one bites the dust.

[digidragon]

Thanks for the zip.

I didn't want to do the whole disc again for a test (4+ hours!!!) so I just ripped the menu and a few chapters from the original disc and will use that for the test.

I'm rebuilding it again using the old exe, just to make sure I get the same motion blur as I did when doing the whole disc. Then I'll do exactly the same using the new exe.

Will post back in a bit...

[digidragon]

The first test using the old exe produced the same motion blur as the full disc backup did.

But using the new exe there was no sign of any motion blur. It looks perfect.

Should I use this test version to do the whole disc, or wait for the next point release?

[Joergen]

If you can do the full disc it would be good for jdobbs.

[jdobbs]

Originally posted by digidragon
The first test using the old exe produced the same motion blur as the full disc backup did.

But using the new exe there was no sign of any motion blur. It looks perfect.

Should I use this test version to do the whole disc, or wait for the next point release? I think it's good. Wait for a short while and I'll post the official v0.38 that includes it.

[FMalibu]

Originally posted by RB
jdobbs, remember that one quirk of CCE is that it will always flag the encoded stream TFF, no matter what you set "Upper Field First" or "Offset Line" to. Setting these options to 1 just causes CCE to shift the video up by one line, this is the CCE way to convert from BFF to TFF.

So to make sure the field order is not changed by CCE, always disable "Upper Field First" or set "Offset Line" to zero, then disable TFF flag during muxing when necessary.



Erm, I just tried version 0.37a on a interlaced PAL DVD (Red Dwarf S2), and the resulting .ecl file didn't have any offset line value set. The offset line value used while encoding was just that of the default CCE profile. So I presume thatpeople who haven't set the offset line of their default profile 0 will experience a shift i.e. a field order inversion. Is there even a ECL value that sets the offset line? (RB?)

I gather jdobbs has made a new version with some fix that is supposed to work. I haven't checked that out yet, so maybe I'm wrong.

Originally posted by RB
About "BFF on DVDs": I have only seen this with picture_structure == FIELD_PICTURE streams. I have one PAL DVD where when you create the D2V with DVD2AVI, the D2V has all zeroes (0 0 0 0...) But it's also all field pictures (not frame), meaning every field of an interlaced frame is stored as a separate picture in the stream. I have found that in this case the TFF flag cannot be trusted, i.e. although the D2V indicates BFF, it's really TFF. When you load this D2V into an AVS and check the field order, for instanceMpeg2Source("D:\field_maybe_bff.d2v")
AssumeBFF()
SeparateFields()you clearly see that it's not BFF because horizontal movement is stuttery/jerky.

I think maybe the TFF flag is not even used for field pictures because the fields are stored simply in "display order" and as such Mpeg2Dec3Dg will always assemble a frame by taking the first field in the stream as top field.

Just my 2 cents.

The MPEG-2 specs (ISO 13818-2) state:

In a field picture top_field_first shall have the value ‘0’, and the only field output by the decoding process is the decoded field picture.

So you are right in your assumption that the TFF flag is not to be used at all for field pictures.

-- FMalibu

[djackson]

I knew sleep would become a hinderance one day. I missed the flurry of activity, should change my tag to "ripvanwinkle".

Just kicking off the whole process with 0.38 before going to work on Fraiser DVD's that started this tread. Will check the results and advise when I get home in 12hrs time.

Thanks for spending the time to track down this bug!

[jdobbs]

Erm, I just tried version 0.37a on a interlaced PAL DVD (Red Dwarf S2), and the resulting .ecl file didn't have any offset line value set. The offset line value used while encoding was just that of the default CCE profile. So I presume thatpeople who haven't set the offset line of their default profile 0 will experience a shift i.e. a field order inversion. Is there even a ECL value that sets the offset line? (RB?) top_first=1 (versions 2.66 and below) and offset_line=1 (newer versions) shouldn't necessarily have to be set for interlaced -- that is only when the interlaced input is BFF.

The TFF flag has no effect if the fields are sequentially and separately sent in the MPEG file (picture_structure=TOP_FIELD or BOTTOM_FIELD). But you can still have interlaced sources that come through as FRAMES. They have to have the TFF set properly.

EDIT: Corrected myself. I'd typed "top_field" when I meant "top_first"

[babaz]

surely a bit late, but i've managed to feed restream with the original (or as tehy say, unbutchered :D) source .m2v - as i expected the TFF flag *WAS* checked!

...right now i'm trying out on the same source new 0.38 version

i'm litteraly blown away by the pace jdobbs irons issues out
it ain't human!!! :D ;)

[FMalibu]

Originally posted by jdobbs
top_first=1 (versions 2.66 and below) and offset_line=1 (newer versions) shouldn't necessarily have to be set for interlaced -- that is only when the interlaced input is BFF.


So that means you're not including an offset_line=0 entry for interlaced content that is TFF? Because that was what I was trying to point out. If this is not included, CCE will use the value of the current template. And in the default template that comes with the program, this value is 1. So if people don't change their template, the offset line entry in CCE will ALWAYS be 1.

EDIT: Great, you fixed it in the new version! I guess I should have checked that out first and my post was a bit premature ;)


The TFF flag has no effect if the fields are sequentially and separately sent in the MPEG file (picture_structure=TOP_FIELD or BOTTOM_FIELD). But you can still have interlaced sources that come through as FRAMES. They have to have the TFF set properly.


Yes. That's what I said. I was backing up RB's assumption with information from the specs.

-- FMalibu

[jdobbs]

Cool. :cool:

[RB]

jdobbs, are you now setting top_first/offset_line=1 in the ECL for BFF interlaced content? If so OK, it works just fine, but for the last bit of perfection you could have set that to 0 always, remember that it was BFF and during remuxing, set TFF flag to 0. This way the one-line shift could be avoided in CCE. Anyway, probably not worth the trouble :)

[jdobbs]

Originally posted by RB
jdobbs, are you now setting top_first/offset_line=1 in the ECL for BFF interlaced content? If so OK, it works just fine, but for the last bit of perfection you could have set that to 0 always, remember that it was BFF and during remuxing, set TFF flag to 0. This way the one-line shift could be avoided in CCE. Anyway, probably not worth the trouble :) I thought so too. That's exactly what I was doing originally and it was causing the reported problems. I think CCE has issues with BFF material that doesn't have the top_first/offset_line option set. I can't imagine why, though -- especially since it is coming through to CCE as a FRAME anyway. My guess would have to be that AVISYNTH is passing the BFF info through somehow???? Don't know for sure.