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.

[RB]

Hmm, very interesting. This has always worked for me and a lot of other people (encode BFF with upper field first disabled, then use Restream to clear TFF flag). Anyway, I really don't want to ride a dead horse, it's solved so let's move on :)

[jdobbs]

Originally posted by RB
Hmm, very interesting. This has always worked for me and a lot of other people (encode BFF with upper field first disabled, then use Restream to clear TFF flag). Anyway, I really don't want to ride a dead horse, it's solved so let's move on :) In retrospect, what I wish I had tried first for this fix would be to always set TFF on in the .D2V file (all '2's) rather than do the conversion to TFF. I'm with you. I'd much rather have a pristine duplication as closely matched to the original as possible. In fact I may post a test version to try that. What do you think?


ADDED: I guess, though, in that situation I'd have the lines transposed in the frame sent to CCE and the compression would suffer...

[jdobbs]

BTW. I don't mind beating a dead horse if it is at least an interesting subject. I just don't want to use the word "stutter" in a sentence anymore.

[djackson]

Have just tested 0.38 on Frasier (Season 1, Disc 1&2, PAL R4). I'm now getting a combing effect with motion.

If there is any info I can supply, or any test I can run, I'm more than willing to try.

I appreciate the efforts so far to stomp on this one.

[jdobbs]

Originally posted by djackson
Have just tested 0.38 on Frasier (Season 1, Disc 1&2, PAL R4). I'm now getting a combing effect with motion.

If there is any info I can supply, or any test I can run, I'm more than willing to try.

I appreciate the efforts so far to stomp on this one. That's normal when you play interlaced back on a PC. Have you tried burning it and watching it on a television? If your end-plan is to watch it on a PC you can use the DECOMB function under Options/AVS Options/Advanced (Expert) Options.

[djackson]

Playback was done on a standalone. Playback on my PC has always been OK. I think I'm just jinxed.:confused:

[jdobbs]

You know. I can to make another version that does what I mentioned above just as a test -- are you up for it?

[djackson]

What did P.T Barnum say? "There's a sucker born every minute!" So I must be him... I'm game:D

[RB]

Originally posted by jdobbs
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.
Hmm, maybe those reporting problems actually had DVDs with field picture streams, meaning the D2V would be all 0-Flags (BFF) and you misinterpreted this to actually mean BFF so cleared TFF flag during muxing? We discussed the field pictures issue a few posts up on this page, confirmed by FMalibu.

About AVISynth - not sure Mpeg2Dec3Dg passes any BFF/TFF info to AVISynth. OTOH, it should, otherwise SeparateFields/Weave could never be used reliably.

[jdobbs]

Originally posted by RB
Hmm, maybe those reporting problems actually had DVDs with field picture streams, meaning the D2V would be all 0-Flags (BFF) and you misinterpreted this to actually mean BFF so cleared TFF flag during muxing? We discussed the field pictures issue a few posts up on this page, confirmed by FMalibu.

About AVISynth - not sure Mpeg2Dec3Dg passes any BFF/TFF info to AVISynth. OTOH, it should, otherwise SeparateFields/Weave could never be used reliably. I'm pretty sure that isn't the case, because I've found a bug (I'm now working) that makes at least some of those streams fail completely. It is the cause of one of the "Runtime Error '9'" errors in PREPARE. Considering how few complaints I've gotten I think it's safe to say that those are pretty rare.

I think I had a basic misunderstanding as to how those streams work... I got an example in which the TOP_FIELD was tagged as an I frame, and the BOTTOM_FIELD for the same frame was a P frame. I didn't know that was how it worked... I need to go back to the spec and do some homework on those.

[jdobbs]

@djackson and anyone else who wants to try this on a BFF source

Here is a test version of 0.38. Here's what it does:

1. It flags all frames as TFF in the .D2V files so they are served as such to AVISYNTH

2. The top_field/offset_line is set to 0 to it is processed as TFF

3. The flags are reset to their original state (TFF=0) in the REBUILD.

If this works without making an ugly image it would be the best way to handle these.

Thx. jdobbs

[djackson]

Just starting the process off.

This is from the info panel of Bitrate Viewer for the source of Frasier S1, D1, PAL R4 (VTS_01_2.VOB)
Num. of picture read: 26
Stream type: MPEG-2 MP@ML VBR
Resolution: 720*576
Aspect ratio: 4:3 Generic
Framerate: 25.00
Nom. bitrate: 9800000 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 10
Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced
Scene change detection: NOT FOUND
Variable GOP pattern: NOT FOUND
Notes:

[jdobbs]

????? :confused:

That says it's top field first.

[zeus163]

I didn't try the new test version, but did try 0.38 last night on Great Teacher Onizuka. When I woke up the encode was finished, so I rebuilt it, and then burnt the folders (I was even able to include the jacket file!).

The resulting DVD played just like the original, in fact, I bet I could fool people with how good this looks.

Thanks jdobbs what a super package.

[jdobbs]

Originally posted by zeus163
I didn't try the new test version, but did try 0.38 last night on Great Teacher Onizuka. When I woke up the encode was finished, so I rebuilt it, and then burnt the folders (I was even able to include the jacket file!).

The resulting DVD played just like the original, in fact, I bet I could fool people with how good this looks.

Thanks jdobbs what a super package. Ahhh... shucks..:)

[Rombaldi]

@jdobbs

Just wandered in this morning, so the 'test' 38 hasn't been tried, but using the regular 38 on one of my 'problem children' (Land of the Giants, vol.1 from Columbia House) I still have the 'field flicker' problem.

will try the 'test' 38 ASAP, but I still have all the RB files from this attempt, would you care to see the contents of any and what else can I provide. (I haven't tried 38 on one of my homemades yes, wanted to start with this one..)

[jdobbs]

Originally posted by Rombaldi
@jdobbs

Just wandered in this morning, so the 'test' 38 hasn't been tried, but using the regular 38 on one of my 'problem children' (Land of the Giants, vol.1 from Columbia House) I still have the 'field flicker' problem.

will try the 'test' 38 ASAP, but I still have all the RB files from this attempt, would you care to see the contents of any and what else can I provide. (I haven't tried 38 on one of my homemades yes, wanted to start with this one..) You're telling me that the changes in 0.38 had no affect whatsoever on your output?

[djackson]

@jdobbs

Have rerun Fraiser S1-D1 thru the 0.38 BFF2 version just posted above. Perfection! For a while I was beginning to think this would become the never ending thread.

Thanks! Where can I donate to the cause?

[Rombaldi]

Originally posted by jdobbs
You're telling me that the changes in 0.38 had no affect whatsoever on your output?

On the Land of the Giants, none that I can see. I haven't tested my Panasonic recorded discs (yet), those are next. LOTG is processing now (just a 2 pass on CCE) with the BFF2 version, so I should have a report on that in the next couple of hours. I did save the RB created files from the first run with 38, so I will have something for comparision...

whatever the results, I'll do a Panasonic disc next..

[jdobbs]

Originally posted by djackson
@jdobbs

Have rerun Fraiser S1-D1 thru the 0.38 BFF2 version just posted above. Perfection! For a while I was beginning to think this would become the never ending thread.

Thanks! Where can I donate to the cause? Just push the button located in the "About" box.

[jdobbs]

Originally posted by djackson
@jdobbs

Have rerun Fraiser S1-D1 thru the 0.38 BFF2 version just posted above. Perfection! For a while I was beginning to think this would become the never ending thread.

Thanks! Where can I donate to the cause? I just want to make sure I have it straight. You had problems with the output of "Frasier" on the published version of 0.38 -- but the special test version BFF-TEST2 that I loaded this morning?

I want to be sure, because if everything worked okay I'm going to use that new code in V0.39...

@RB -- have you tried this test version yet on some BFF material, I want to be especially sure that it will run alright before I post it? Oh, by the way -- I fixed the Runtime Error 9 you experienced. As I mentioned I had some issues in my field-based processing. Thanks for the file.

[RB]

Problem is, I don't have any DVD with BFF interlaced material... I'll try to make one up from some home made video.

[jdobbs]

@RB

That's ok. Don't go to the trouble -- I thought you already had something.

I'm really getting confused on this one.

1. The first fix I implemented (using the top_field=1 etc.) seemed to fix everything.

2. Then djackson said he was still getting blurring from it... so I made up the BFF2 version as a test to see if it could fix the BFF problem he was having.

3. But then I noticed that his post from Bitrate viewer showed Frasier to be TFF. So the new version I loaded shouldn't have had an effect (it only should affect BFF)

4. Now djackson reports that the problem was fixed with BFF2...

:confused:

I'm trying to decide whether to post v0.39 with the new code or the old code. I was just looking for someone to confirm that the new code doesn't screw up BFF streams because I don't have any.

[Rombaldi]

Originally posted by jdobbs
I was just looking for someone to confirm that the new code doesn't screw up BFF streams because I don't have any.

I'll offer again, PM me with where to send it and I'll send you a Panasonic recording that (appears) to be BFF (still in the test queue, waiting for LOTG to finish) so you have have it in your hands and dissect to pieces...

[jdobbs]

@Rombaldi

Thanks. But I just used my DV camera and QuEnc to make myself a BFF titleset (I examined it with VOBEDIT and it is definitely BFF). The output looks the same either way to me.

[Rombaldi]

@jdobbs

NP, I'm still about 45 minutes away from seeing how LOTG comes out. If that works, then I'll feed it a Panasonic recording and see what
happens....

don't wait up on .39 on me tho... I'll hammer it as I can and find the cockroaches as they turn up.

[jdobbs]

Thanks. I put the new code in 0.39 -- but I have the old ready in case it needs to be reinserted.

[djackson]

Originally posted by jdobbs
I just want to make sure I have it straight. You had problems with the output of "Frasier" on the published version of 0.38 -- but the special test version BFF-TEST2 that I loaded this morning?

I want to be sure, because if everything worked okay I'm going to use that new code in V0.39...

Yes... The published 0.38 had the combing/blur, but the special BFF2 version was OK on the Frasier discs. This is even though Bitrate viewer says the source stream is TFF.

The thing is I didn't have this prob with "Pirates of the Carribean" with an earlier version of DVD-RB. I'll run this disc tonight (at work now) with the special version to see what happens. Maybe thre may be a need have both sets of code in a later release, and have a setting in advanced options.

[Rombaldi]

Originally posted by jdobbs
Thanks. I put the new code in 0.39 -- but I have the old ready in case it needs to be reinserted.

@jdobbs

well, no joy in Mudville, the LOTG still has the field flicker. I have maintained all the generated files from 38 and 39BFF2, so what
can I post for you to persue???

[Rombaldi]

@jdobbs

well, I'm losing what little mind I have....

I WIPED everything off my system,
cleaned the registry,
reinstalled DVDRB, the DLL's, everything
installed QENC (just to be different) and re-ran the LOTG
thru using QENC as the encoder..

NO FIELD FLICKER!

However, now the audio is about 2 seconds out of sync and the picture stalled every few seconds...

ARGGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHH!!!!!

I'm going to re-run this with CCE 2.50, check back in about 4 hours (note to self, get a faster CPU)

[redfive19]

@jdobbs

I am still a bit new to the field order stuff. Does this mean we wont have to deinterlace with decomb? Does Decomb make the material look crappier?

-redfive

[babaz]

it's all about keeping the interlaced...
by not deinterlacing it, we consider to mainly play back this content onto TV screens, and (as most do) i tend to prefer the more smoothness an interlaced source can allow...

of course, if you want to, you can "decomb" it to progressive
there should be no issue at all, then

my 2 cents

[redfive19]

right but before jdobbs added the decomb feature, i would get jaggy ghosting lines everytime i encoded TFF. I did the same DVD with DoItFast4U and DIF4U had a call to decomb in the AVS files. when I finished the DVD with the Big3, I did not have these lines. BTW, those lines were only visible on my tv.

-redfive

[jdobbs]

You still have the option to use decomb with DVD-RB -- it hasn't been removed. Different strokes for different folks.

[Rombaldi]

@jdobbs

I am OFFICIALLY losing my mind now...

as the previous report said, when using

RB 0.39 & QEnc 0.45

starting from an 'clean wipe' (uninstall AVISynth, RB, CCE, QEnc, ReJig) and a registry clean/compact.

reinstall AVISynth, DLL's, RB and QEnc

running LOTG thru produced NO FIELD FLICKER but the audio was out of sync from the get go and the disc FROZE every few seconds like it was trying to catch up...

CHANGING NOTHING ELSE except installing CCE 2.50 and ECLCCE 1.8a
and configuring same, switching to CCE Encode, 2 pass.

Burned the disc

With fear I press play.

Audio in proper sync - check.
No 'freezing' of the picture - check.
NO FLIPPING FIELD FLICKER, NONE - check!

in other words.. PERFECT.

Rule 1 of beta testing, clean the environment every so often.

I'll run thru a Panasonic recorded disc later tonight on 0.39, and
report back..

I can't explain it any other way than a 'contaminated environment'.

[Paced]

Originally posted by Rombaldi
@jdobbs

I am OFFICIALLY losing my mind now...

as the previous report said, when using

RB 0.39 & QEnc 0.45

starting from an 'clean wipe' (uninstall AVISynth, RB, CCE, QEnc, ReJig) and a registry clean/compact.

reinstall AVISynth, DLL's, RB and QEnc

running LOTG thru produced NO FIELD FLICKER but the audio was out of sync from the get go and the disc FROZE every few seconds like it was trying to catch up...

CHANGING NOTHING ELSE except installing CCE 2.50 and ECLCCE 1.8a
and configuring same, switching to CCE Encode, 2 pass.

Burned the disc

With fear I press play.

Audio in proper sync - check.
No 'freezing' of the picture - check.
NO FLIPPING FIELD FLICKER, NONE - check!

in other words.. PERFECT.

Rule 1 of beta testing, clean the environment every so often.

I'll run thru a Panasonic recorded disc later tonight on 0.39, and
report back..

I can't explain it any other way than a 'contaminated environment'.

Woah, first lab-one, and now you :) It's good to hear that these problems may not be DVD-RB's fault after all :cool: