output .m2v has a different field order compared to original .vob

[jarthel]

I viewed the original .vob files in dgindex 1.4.5 and it says the field order is "top".

I then viewed the two of the output .m2v files and the field order is now "bottom".

should I be concern? thank you.

[jdobbs]

No. The field precedence should be based upon the new encoding, not the original. I wonder, though, whether you have that backwards. It's a lot more probable that the original might be BFF and the new one TFF.

[jarthel]

i previewed the original vob and output .m2v in dgindex and original is top and output m2v is bottom.

But thank you for the reply. :)

[wmansir]

The original MPEG flags will be copied over the .m2v duing the Rebuild stage, so even if the .m2v files are wrong, they will be correct in the final ouput.

[Jeffster]

The original MPEG flags will be copied over the .m2v duing the Rebuild stage, so even if the .m2v files are wrong, they will be correct in the final ouput.
I don't think that's entirely correct... DVD-RB may copy the original progressive/interlaced flags, or something like that, but I don't think it takes into account the field order.

Strangely enough I posted about a similar thing (http://forum.doom9.org/showthread.php?t=101123) a few days ago. The original DVD was BFF, but it was encoded TFF and the rebuild vobs were also TFF.

[jdobbs]

@jeffster

Are you checking the M2V files or the VOB files? The M2V files don't have flags corrected yet -- that happens during rebuild.

It's been a long time since I wrote that code, I may need to go back and review it (the mind is the second thing to go, you know).

[Carpo]

whats the first ? :p

( i know its comming but i just had too) :)

[Jeffster]

Are you checking the M2V files or the VOB files? The M2V files don't have flags corrected yet -- that happens during rebuild.
Both - I noticed after the encode phase the M2V files were TFF, but assumed that would be corrected during the rebuild. After the rebuild phase I checked the new VOB files and found they were still TFF and the flag hadn't been changed back to BFF during the rebuild.

I think this is probably an uncommon scenario though, at least it's the first time I've ever seen a commercial DVD where the video was BFF (and hopefully the only time). :)

[jdobbs]

If you take a look at the .FLG files, you'll see the flags that DVD-RB found in each of the original frames (one byte per frame). It's like this for the lower three bits:

Bit 0 = RFF
Bit 1 = TFF
Bit 2 = PROGRESSIVE_FLAG

[Jeffster]

What program do I use to view/decypher the FLG files?

I can upload one if you want to look at it.

[jdobbs]

Deleted this response....

[Jeffster]

Deleted this response....
??

Well the FLG files for the main movie all have a bunch of 02's in them.
Both DGIndex and BitrateViewer say the vobs are BFF though.

The FLG file for the trailer also has a bunch of 02's in it... but it is TFF.

There are a couple of single frame files which are progressive and their FLG files have a 06 in them.

[jdobbs]

If any other software says it is not TFF and they are scanning the same source as DVD-RB, I believe they are wrong. DVD Rebuilder writes that file with the values directly pulled from the video stream. Are you sure that the VOBs you are looking at are the same that were used during PREPARE?

[jdobbs]

By the way... what are you using to view the contents of the FLG file?

[Jeffster]

Are you sure that the VOBs you are looking at are the same that were used during PREPARE?
Yep I'm sure I'm looking at the source files. I'd previously deleted the other vobs and these are the only set on my HD. I re-ran PREPARE on them earlier to have a look at the FLG files for you.
(By the way, I just checked the source files with a third program and it also reports them as BFF)

By the way... what are you using to view the contents of the FLG file?
The hex editor in VirtualDubMod.

[jdobbs]

Is this an NTSC source? If so I'll go get it and look at it.

Try this: Open the VOB files using VOBEDIT. Go to each frame and look at the flags. They are listed following the picture_coding_extention start code. Look at several of them. They will be in the video packs that have [I], [P], or [B] listed in the LBA column.

Also check the picture_structure and see what it says. If the structure is TOP_FIELD or BOTTOM_FIELD rather than FRAME it will becomes a whole different ball game because the fields are separated in the stream and my discussion above may not apply.

[jdobbs]

By the way, are you having a problem with the playback of DVD-RB or are we just having an academic discussion? The former is a concern, the later is cool.

[Guest]

If you look randomly and see a 2, it doesn't necessarily mean the clip is TFF!

For example, the clip could start this way:

0 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 ...

If you look at the 2's you might think it is TFF, but actually, it is BFF. The repeat flag (1) is responsible for that. DGIndex looks at the polarity of the first picture to determine field order.

[jdobbs]

If the original video included that sequence, so would DVD-RB's finished product. The flags of the original would be reinstated during the REBUILD process.

Looking at my code it appears the only exception I could imagine to that rule might be if there was an orphaned field in the original and the picture_structure was not FRAME -- and thats only because of the way DVD-RB scans. That's the reason I asked him to look at the picture_structure.

For example, the clip could start this way:

0 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 ...Are you talking about values in the D2V file here, or in the FLG file?

[Guest]

In the D2V file. Bit 0 = RFF, bit 1 = TFF.

[Jeffster]

Is this an NTSC source? If so I'll go get it and look at it.

Try this: Open the VOB files using VOBEDIT. Go to each frame and look at the flags. They are listed following the picture_coding_extention start code. Look at several of them. They will be in the video packs that have [I], [P], or [B] listed in the LBA column.

Also check the picture_structure and see what it says. If the structure is TOP_FIELD or BOTTOM_FIELD rather than FRAME it will becomes a whole different ball game because the fields are separated in the stream and my discussion above may not apply.
It's a PAL disc. (R2)

Okay, the picture_structure appears to alternate between TOP FIELD and BOTTOM FIELD for each consecutive frame. The other flags remain constant.

Here is a snippet from the first frame in the VOB...
intra_DC_precision: 2
picture_structure: 1
picture_structure: Top Field
Top_Field_First: 0
alternate_Scan : 1
Repeat_First_Field:0
Progressive_frame:0
the next frame is the same except picture structure is 2 and Bottom Field.

By the way, are you having a problem with the playback of DVD-RB or are we just having an academic discussion? The former is a concern, the later is cool.
The rebuilt DVD played ok on my PC, but I didn't burn it to disc and try it on a standalone, perhaps it would have been ok there too, I can't say as I deleted the vobs from the first attempt.

I guess it's more an academic discussion since I'm not overly concerned about backing up this particular disc and thought it was an isolated case. I only entered this discussion because this thread sounded similar to what I experienced and posted about a few days ago, and thought you'd want to get to the bottom of it.

[Guest]

Okay, the picture_structure appears to alternate between TOP FIELD and BOTTOM FIELD for each consecutive frame. Those aren't frames; they are pictures, field pictures, to be exact.

the next frame is the same except picture structure is 2 and Bottom Field. You mean 'the next picture'. You have field pictures with top field first.

[Jeffster]

Well I hope the info from VOBEDIT proves helpful, even if my terminology was less than accurate.

I guess I'll have to be careful in referring to [I], [P], or [B] as frames from now on. :)

[Jeffster]

@jdobbs
I think I can put an end to this discussion although I don't totally understand it :)

I chose a segment from the DVD with high motion and encoded it first with the same settings as DVD-RB, including the top field flag ON, and a second time with the top field flag OFF. Then I authored a simple DVD with those segments and played it on my standalone.
The result was one played smoothly and the other was jittery.
The one that played smoothly was the first, with top field ON.

So DVD-RB must be doing things correctly.

Although to the casual observer, like myself, the rebuilt vobs have different characteristics to the original, it's obvious things are not always as they seem on the surface.

From what's been said above I'm guessing it has something to do with the source vobs having a Field based picture structure? Feel free to expand on this if you want, or correct me if my conclusion is wrong.

I'm sorry for dragging out this thread unnecessarily as it turns out. :(

[jdobbs]

I see.

As I said earlier, the important thing isn't whether the fields are TFF or BFF -- but that they are played back in the correct order. This is because each of the two fields of a true interlaced source represent different points in time -- so if played out of order you would be play one from a point in time, then go back 1/50th of second in time, followed by a jump of 1/25th of a second jump forward in time... on still scenes it isn't noticable, but on action scenes it can really give you a terrible headache.

The disc you are examining isn't very typical because it has the fields separated in the file. Most sources are frame based. In the frame scenario you will get a single picture containing both fields. DVD Rebuilder handles the two structures in different ways -- and that's why I wanted to make sure how it was structured.

Thanks.