"Frame Type" and "Coding Type" not what I anticipated

[halsboss]

I'm sorry, but I don't know how to interpret "Frame Type" and "Coding Type" and wonder if you could clarify. I'm capturing Aus PAL HDTV (usually 1080i) with a view to -> PAL DVD for watching later (legal in Aus). It is notionally interlaced, but it turns out isn't always it seems.

To get to DVD, I need to resize it to 576i or 576p and I guess the resizing method will depend on whether it's interlaced or progressive. Where it's interlaced fast moving sports action I'd prefer to leave it like that because I gathered from somewhere in the forum that i retains some perception of more smoothly moving action. I chop out ads using VideoReDo, in the process turning the .TS into a .mpg and then I use DGIndex/Mpeg2Source to open the .mpg in avisynth for processing/resizing.

Having discovered that 1080i isn't necessarily interlaced, I used DGIndex to see if I could discover whether the source is interlaced or progressive and am now more confused than ever. Below is 3 samples where I suspect particular things from loading into Vdub and seeing if there are "horizontal lines" indicative of interlacing.

Given those results, have you any suggestions on how I can tell if a clip is interlaced or progressive ? Thanks.

1.Suspect-fully-interlaced.log which dgindex says is "Coding Type: P"
http://rapidshare.com/files/166434510/1.Suspect-fully-interlaced.mpg 5Mb
Stream Type: MPEG2 Program
Profile: main@high
Frame Size: 1920x1080
Display Size:
Aspect Ratio: 16:9 [3]
Frame Rate: 25.000000 fps
Video Type: PAL
Frame Type: Interlaced
Coding Type: P
Colorimetry: BT.709*
Frame Structure: Frame
Field Order: Top
Coded Number: 39
Playback Number: 39
Frame Repeats: 0
Field Repeats: 0
VOB ID:
Cell ID:
Bitrate:
Bitrate (Avg):
Bitrate (Max):
Audio Stream: 80: AC3 2/0 448
Timestamp: 0:00:01
Elapsed: 0:00:01
Remain: FINISH
FPS: 36.81
Info:
dgindex on the .TS says
Frame Type: Interlaced
Coding Type: P
Colorimetry: BT.709*
Frame Structure: Frame
Field Order: Top

2.Suspect-progressive.log which dgindex says is "Coding Type: P"
http://rapidshare.com/files/166434511/2.Suspect-progressive.mpg 4Mb
Stream Type: MPEG2 Program
Profile: main@high
Frame Size: 1920x1080
Display Size: 1920x1080
Aspect Ratio: 16:9 [3]
Frame Rate: 25.000000 fps
Video Type: PAL
Frame Type: Interlaced
Coding Type: P
Colorimetry: SMPTE 240M
Frame Structure: Frame
Field Order: Top
Coded Number: 9
Playback Number: 9
Frame Repeats: 0
Field Repeats: 0
VOB ID:
Cell ID:
Bitrate:
Bitrate (Avg):
Bitrate (Max):
Audio Stream: 80: AC3 2/0 384
Timestamp: 0:00:00
Elapsed: 0:00:00
Remain: FINISH
FPS: 37.59
Info:
dgindex on the .TS says
Frame Type: Interlaced
Coding Type: B
Colorimetry: SMPTE 240M
Frame Structure: Frame
Field Order: Top

3.Suspect-fully-interlaced.log which dgindex says is "Coding Type: B"
http://rapidshare.com/files/166434512/3.Suspect-fully-interlaced.mpg 4.2Mb
Stream Type: MPEG2 Program
Profile: main@high
Frame Size: 1440x1080
Display Size:
Aspect Ratio: 16:9 [3]
Frame Rate: 25.000000 fps
Video Type: PAL
Frame Type: Interlaced
Coding Type: B
Colorimetry: BT.709*
Frame Structure: Frame
Field Order: Top
Coded Number: 29
Playback Number: 29
Frame Repeats: 0
Field Repeats: 0
VOB ID:
Cell ID:
Bitrate:
Bitrate (Avg):
Bitrate (Max):
Audio Stream: 80: AC3 2/0 448
Timestamp: 0:00:00
Elapsed: 0:00:00
Remain: FINISH
FPS: 45.66
Info:
dgindex on the .TS says
Frame Type: Interlaced
Coding Type: B
Colorimetry: BT.709*
Frame Structure: Frame
Field Order: Top

[Guest]

I thought that link you cited in the other thread made it all clear. The flags in DGIndex tell you NOTHING about whether the *content* of your video is progressive or interlaced. They tell you only how the stream was encoded, which is a very different thing.

For example, you can have a progressive stream that is encoded as interlaced. It means that the two fields of each frame are from the same picture, or temporal moment to be more exact. But the encoder can encode a field at a time.

The converse can happen too. You can have interlaced video encoded as progressive. That means the two fields of each frame are different pictures, or sample different moments in time. But the encoder can encode it together as one frame.

I know you are looking for an automatic solution where some program will just print out "Interlaced content" or "Progressive content". There have been attempts at that, with varying degrees of success, but the only reliably accurate method is called Human Mind 1.0. That means you separate the fields and step through them to see what pattern of pictures you have, i.e., is there motion between the fields of the frames.

I have documented the method here:

http://neuron2.net/faq.html#analysis

It will be a useful exercise for you to apply that to your three samples and tell us your conclusion. After that I'll tell you what I think and we'll see if we agree.

One more thing, the coding type has nothing whatsoever to do with interlaced versus progressive content. P stands for a "Predicted" frame, B for "Bidirectional predicted" frame, and I for "Intra coded" frame.

Bottom line: DGIndex is telling you only about the MPEG encoding, and not about the actual content of the video. Here's an analogy. You buy apples and oranges with labels saying either "apple" or "orange". DGIndex can only look at the label and tell you it says "apple" or "orange". But if some idiot has labeled an apple as an orange, DGIndex is going to tell you only that the label says orange. He can only read labels (the encoding flags), not tell colors apart and all that. :)

[halsboss]

Ah, no, I'm a bit simple and that didn't sink in... and I was hoping DGIndex was a bit magical.

For example, you can have a progressive stream that is encoded as interlaced. It means that the two fields of each frame are from the same picture, or temporal moment to be more exact. But the encoder can encode a field at a time. So to reflect back and check my understanding, that means one single progressive frame is processed into a top field and a bottom field so it's in "interlaced fields format" but not "really interlaced" as such. I guess in Vdub you don't see any of the interlaced "lines" and can pick up on it as "progressive as interlaced". Sounds like it could be easy to combine the 50i fields (originating from a "p") into a 25p.

The converse can happen too. You can have interlaced video encoded as progressive. That means the two fields of each frame are different pictures, or sample different moments in time. But the encoder can encode it together as one frame. Yuk. That must be hard to tell visually from proper interlaced then, say in Vdub ? These ate OTA broacasts which are notionally 1080i, so I wonder what would be an indicator for "interlaced as progressive", visual or otherwise.

the only reliably accurate method is called Human Mind 1.0 HM 0.75 is struggling along here :)

That means you separate the fields and step through them to see what pattern of pictures you have, i.e., is there motion between the fields of the frames. I have documented the method here: http://neuron2.net/faq.html#analysis It will be a useful exercise for you to apply that to your three samples and tell us your conclusion. After that I'll tell you what I think and we'll see if we agree. Yes, this is a great learning opportunity and I thankyou for it.

One more thing, the coding type has nothing whatsoever to do with interlaced versus progressive content. P stands for a "Predicted" frame, B for "Bidirectinal predicted" frame, and I for "Intra coded" frame. Oh. I'd mistakenly thought in the log it meant Progressive or Interlaced or Both. Whoops.

Once I understand how to discern them apart, and given it's Aus OTA 1080i broadcasts and they dont don't support 1080p (that I know of) and DGIndex does report "Frame Type:Interlaced"
(1) interlaced which really is interlaced in 1080i format
(2) "progressive as interlaced" in 1080i format
(3) "interlaced as progressive" in 1080i format
then I'll need to match up methods to convert each type into PAL DVD 25i or 25p. I have a method for (1) and will check on something for (2) and (3) later.

[Guest]

I wonder what would be an indicator for "interlaced as progressive", visual or otherwise. This question tells me you haven't fully absorbed what I told you. What you call "interlaced as progressive" is more accurately "interlaced content encoded progressively". You can tell how it's encoded by looking at what DGIndex says. It reads the labels, remember? :)

And you tell that it is interlaced *content* by applying the method in the FAQ question. There is no quick visual check in VirtualDub. I'm sorry. You have to separate the fields and step through. Just seeing "combing" when viewing full frames in VirtualDub could be interlaced content, field-blended content, field-shifted progressive content, pulled-down content, etc. Even the sharpest observers, like scharfis_brain, can't always tell reliably from looking at frames.

Don't get hung up on how things are encoded. What is important for the processing is whether the *content* is interlaced, progressive, field-shifted, blended, hybrid, pulled-down, etc. You can reliably tell that ONLY by going through the process I described. Forget about all the flags and "interlaced as progressive", etc., blah blah. The question to answer is "What is the nature of my video content?"

"Notionally" doesn't mean anything. Stop using that word.

[halsboss]

Well, I went to http://neuron2.net/faq.html#analysis and had a read and tried it out with those 3 clips to ascertain which one of these they fall into
(1) interlaced which really is interlaced in 1080i format
(2) "progressive as interlaced" in 1080i format
(3) "interlaced as progressive" in 1080i format

1.Suspect-fully-interlaced.log
http://rapidshare.com/files/166434510/1.Suspect-fully-interlaced.mpg 5Mb
seems to be "type (1)" interlaced TFF on the basis of the combination of
(a) the raw file opened in vdub (mpeg2 plugin) showed classic horizontal interlacing lines during movement
(b) using the AssumeTFF.SeparateFields it appeared to look like ... a b c d e f ..
(c) using the AssumeBFF.SeparateFields it appeared to jitter back and forward movement (dunno what frame sequence)

2.Suspect-progressive.log
http://rapidshare.com/files/166434511/2.Suspect-progressive.mpg 4Mb
seems to be probably "type (2)" progressive although the format is interlaced TFF on the basis of the combination of
(a) the raw file opened in vdub (mpeg2 plugin) showed no classic horizontal interlacing lines during movement
(b) using the AssumeTFF.SeparateFields it looked close to ... a a b b c c ... albeit with miniscule differences between some consecutive frames
(c) using the AssumeBFF.SeparateFields there was no jitter back and forward movement

3.Suspect-fully-interlaced.log
http://rapidshare.com/files/166434512/3.Suspect-fully-interlaced.mpg 4.2Mb
seems to be "type (1)" interlaced TFF on the basis of the combination of
(a) the raw file opened in vdub (mpeg2 plugin) showed classic horizontal interlacing lines during movement
(b) using the AssumeTFF.SeparateFields it appeared to look like ... a b c d e f ..
(c) using the AssumeBFF.SeparateFields it appeared to jitter back and forward movement (dunno what frame sequence)

As you say, (b) the way to do it. Do you have the same conclusions ?

edit1: I'm not sure what "field blending" looks like, I'll go google it.
edit2: http://en.wikipedia.org/wiki/Deinterlacing describes blending but I'm still not sure what it looks like in my context

[Guest]

The first two are progressive content. There will be a little jumping up and down between fields due to the field separation. The last one (the football one) is TFF interlaced content.

"progressive as interlaced" Please stop using this terminology! It's needlessly confusing. It doesn't matter how it's encoded. It only matters what the content is.

So you went wrong on the first one. That's because it is field-shifted. And that's why you shouldn't open it and look at frames in VirtualDub. Don't you listen to anything I say? :)

Field shifted means this, where [ ] denotes the two fields of a frame:

[z a] [a b] [b c] [c d] ...

It is really progressive (pairs of matching fields) but the fields are not matched in frames. Run it through Telecide() or TFM() to match up the fields. Then you won't see the combing in VirtualDub.

Also, about that (3) "interlaced as progressive" in 1080i format...Is there a sample about the place I can have a look at too? Don't worry about it! It doesn't matter how it's encoded. Just say, it's interlaced content, OK?

I'm not sure what "field blending" looks like, I'll go google it. It means when you look at a field, not a frame, you see two pictures blended together.

[halsboss]

Ah, thankyou. Used Vdub with the separate-fields .avs script per the instructions at http://neuron2.net/faq.html#analysis Now serve the script into VirtualDub and step through the fields in a high motion section and also looked at the whole frame out of curiosity ;) ... now I know better than to rely on the whole-frame observation.

So you went wrong on the first one. That's because it is field-shifted. And that's why you shouldn't open it and look at frames in VirtualDub. Don't you listen to anything I say? :)
Field shifted means this, where [ ] denotes the two fields of a frame:
[z a] [a b] [c d] ...
It is really progressive (pairs of matching fields) but the fields are not matched in frames. Run it through Telecide() or TFM() to match up the fields. Then you won't see the combing in VirtualDub.
... "field blending" ... It means when you look at a field, not a frame, you see two pictures blended together.

Thanks again, now what I know what to look for with Field Shifting - Life just got a lot more complex. I hadn't anticipated coming across field-shifted progressive in a supposed OTA 1080i source. ( For other readers, Google also yielded http://neuron2.net/LVG/classifyhighres.html , look under "Check For Field Shifting of PAL/SECAM Video" to see how to check for this, it's great :) ).

To close the door on This question tells me you haven't fully absorbed what I told you. What you call "interlaced as progressive" is more accurately "interlaced content encoded progressively". You can tell how it's encoded by looking at what DGIndex says. It reads the labels, remember?

Sorry. Label for how it's encoded - that would be "Frame Type" as the manual says Frame Type - Displays Interlaced or Progressive depending on the value of the MPEG2 progressive_frame flag. Please be aware that this merely describes how the [B]frame was encoded; it says nothing about whether the content of the frame is progressive or interlaced. It is common for progressive video to be encoded as interlaced, and vice versa.
http://rapidshare.com/files/166478246/dg.jpg

I glean from that, in the context of OTA 1080i broadcasting, there's 2 steps to this
(i) encoding the video in the 1st place, resulting in a movie thats progressive or interlaced, etc, which is where I was at
(ii) encoding that movie content into the OTA "broadcast stream" frames which could be interlaced or progressive frame types
and that's where "interlaced content encoded progressively" and "progressive stream that is encoded as interlaced" comes into it at step (ii). If it isn't say so and I'll just let it go at that.

I could hope that in the case of Aus PAL OTA broadcast PAL 1080i - it would always be of frame type Interlaced since our TV's don't support PAL 1080p and wouldn't they choke at frame type Progressive ?

[halsboss]

PS from http://neuron2.net/LVG/vdplugins.html is there a link to the telecide filter (or its replacement) ?

EDIT found it at http://neuron2.net/mine.html

EDIT2: followed this wrt telcine & PAL under "Check For Field Shifting of PAL/SECAM Video" and source #1 http://neuron2.net/LVG/classifyhighres.html however the interlacing artifacts (horizontal lines) seemed to remain present. Oh well Human Mind 0.75 strikes again.

[Guest]

I glean from that, in the context of OTA 1080i broadcasting, there's 2 steps to this
(i) encoding the video in the 1st place, resulting in a movie thats progressive or interlaced, etc, which is where I was at
(ii) encoding that movie content into the OTA "broadcast stream" frames which could be interlaced or progressive frame types
and that's where "interlaced content encoded progressively" and "progressive stream that is encoded as interlaced" comes into it at step (ii). If it isn't say so and I'll just let it go at that. No, it's not like that. The content is always what it is. Then you encode the content as MPEG2 video. That is where the progressive/interlaced labels get applied. Now you mux the encoded MPEG2 video into the OTA transport stream. Nothing relevant happens when muxing.

I could hope that in the case of Aus PAL OTA broadcast PAL 1080i - it would always be of frame type Interlaced since our TV's don't support PAL 1080p and wouldn't they choke at frame type Progressive ? Now you are confusing the nature of the interface to the TV with the nature of the video. You can play progressive video over an interlaced connection. That's a whole different story. All it means is that you place the two progressive fields onto the interface to the TV with a time difference between them (the field time: 1/50th of a second for PAL) instead of at the same time (as you would do for a progressive interface). In simple terms, you pretend it is interlaced for transfer to the TV.

followed this wrt telcine & PAL under "Check For Field Shifting of PAL/SECAM Video" and source #1 http://neuron2.net/LVG/classifyhighres.html however the interlacing artifacts (horizontal lines) seemed to remain present. Oh well Human Mind 0.75 strikes again. It worked for me (no combing). Are you sure you were looking at the output pane? Try View/Swap input and output panes.

Better to stick with my method, IMHO.

[halsboss]

you encode the content as MPEG2 video. That is where the progressive/interlaced labels get applied. Now you mux the encoded MPEG2 video into the OTA transport stream. Nothing relevant happens when muxing. Oh, good. Thankyou for being patient. I'll get it and how to apply DGIndex/Avisynth without assumptions, soon.

I could hope that in the case of Aus PAL OTA broadcast PAL 1080i - it would always be of frame type Interlaced since our TV's don't support PAL 1080p and wouldn't they choke at frame type Progressive ? Now you are confusing the nature of the interface to the TV with the nature of the video. You can play progressive video over an interlaced connection. That's a whole different story. All it means is that you place the two progressive fields onto the interface to the TV with a time difference between them (the field time: 1/50th of a second for PAL) instead of at the same time (as you would do for a progressive interface). In simple terms, you pretend it is interlaced for transfer to the TV. OK. I had not considered analogue. I'd thought OTA --> digital HDTV receiver (inbuilt in the digital TV) --> TV display. Since digital TV specs here only say they are capable of up to 1080i then I was guessing they'd spit if receiving 1080p (not p dress up inside an interlaced frame like you showed before, or in my sample #1 which is I gather field swapped progressive inside interlaced frames with the field sequence [z a] [a b] [b c] ...) - and hence I wondered if I could assume OTA 1080i would always be an interlaced frame being received by the tuner here.

It worked for me (no combing). Are you sure you were looking at the output pane? Try View/Swap input and output panes.

Better to stick with my method, IMHO.
Had a bit of trouble with the panes (1080 too big for my screen and then ticking the right ones. HM upgraded to version 0.8, panes swapped, and now yes thankyou I see the same as you do. Your method #1 involved separatefields and looking for fields [za] [ab] [bc] etc ? If that url http://neuron2.net/LVG/classifyhighres.html is an older one of yours :) then it as a 2nd method with Vdub/telecide was easier for me to spot and useful as in confirming. Did I miss something in method #1 ?

Lots of these things seem to involve separatefields and frame-by-frame viewing to check on stuff... is it a dumb suggestion to ask if that functionality (separatefields with TFF/BFF setting and frame-forward, and optionally a checking telecide with a frame-forward) maybe could be built into DGindex ? If it's in there then I missed it and apologies in advance.

[Guest]

then it as a 2nd method with Vdub/telecide was easier for me to spot and useful as in confirming. Did I miss something in method #1 ? That #2 method is useful only for the field shift case. My method will allow you to identify all the signatures that correspond to the different types of video. If you ever reach HM 1.0 you'll find it to be the simple and straightforward process that it is.

Lots of these things seem to involve separatefields and frame-by-frame viewing to check on stuff... is it a dumb suggestion to ask if that functionality (separatefields with TFF/BFF setting and frame-forward, and optionally a checking telecide with a frame-forward) maybe could be built into DGindex ? If it's in there then I missed it and apologies in advance. I don't really see the point of it and I'm against kitchen-sinking in general.

[halsboss]

I don't really see the point of it and I'm against kitchen-sinking in general. OK, thanks for considering it and responding.

Thanks I think I have it now. Re OTA 1080i here's a summary for posterity for the uninitiated ...

Broadcast frames can contain many types of content (both interlaced and progressive variations thereof per the thread above and the quote below) unrelated to what the flags say.

The content is still within the context of the frame which in my cases were flagged as 1080i. There are ways to visually discern which type of content it is, but not detected (reliably) automatically by a tool. Collected below below are some ways to recognize what type of content it may me. Having recognized it, you can then use great tools like DGIndex to feed the content into your AviSynth script to process it correctly (refer other forums).

If you don't recognize the content and process it correctly then you'll end up looking like a silly dill, as did I per this lengthy thread :- http://forum.doom9.org/showthread.php?p=1215754#post1215754 (don't bother clicking it).

From http://neuron2.net/faq.html#analysis :-

How do I figure out the nature of my source video?

It's important to know whether your video is progressive, interlaced, telecined, field-blended, etc., when making decisions about how to process it. Here's a reliable method for analyzing your video:

The first step is to create an Avisynth script that sources your video and separates the fields. If you have MPEG video, you can use DGIndex to make a project with "Honor pulldown flags". Then make a script to step through the fields:

MPEG2Source("file.d2v")
AssumeTFF() # or AssumeBFF(). See the next FAQ.
SeparateFields()

If you have a different video source type, just use an appropriate source filter, such as AVISource().

Now serve the script into VirtualDub and step through the fields in a high motion section. We will label a new picture with a new letter below. If you see a repeating field sequence like this:
... a a b b c c ...

then it is progressive video. If you see this:
... a b c d e f ...

then it is pure interlaced video. If you see this:
... a a a b b c c c d d ...

Then it is 3:2 pulled-down progressive video.

Make sure that you always apply this test in a scene with continuous movement, e.g., an object moving steadily across the screen. There is no more reliable way. It also allows you to spot field blending very easily. If you see any blended pictures, then you have field blending.

How do I figure out the field order of my video?

It is essential to set the field order properly for correct rendering of interlaced material. If you are using Decomb, the field order is obtained from Avisynth and can be set using the AssumeTFF() or AssumeBFF() functions in your script before invoking Telecide(). Set AssumeTFF() for top field first; use AssumeBFF() for bottom field first. Because setting it correctly is so important, you are strongly encouraged not to make assumptions about the field order of a clip, but rather to verify the field order using the following procedure, which is a variant of the procedure described in the FAQ preceding this one.

To determine the field order, make an Avisynth script that serves the raw clip and separates the fields. If it were an AVI, then just AVISource() would be used. For our example, we'll use AVISource(). Add a script line to separate the fields using top field first, as follows:

AVISource("your_clip.avi")
AssumeTFF()
SeparateFields()

Now serve the script into VirtualDub and find an area with motion. Single step forward through the motion. Note whether the motion progresses always forward as it should, or whether it jumps back and forth as it proceeds. For example, if the field order is wrong, an object moving steadily from left to right would move right, then jump back left a little, then move right again, etc. If the field order is correct, it moves steadily to the right.

If the motion is correct with AssumeTFF().SeparateFields(), then your field order is top field first and you must use AssumeTFF(). If the motion is incorrect, then your field order is bottom field first and you must use AssumeBFF(). If you want to double check things, you can use AssumeBFF() to check correct operation for bottom field first.

Additionally, if the clip is progressive, motion will be correct for both AssumeTFF() and AssumeBFF(), i.e., field order does not matter.


Field Shifting detectable using the Separatefields thing above (where you want to eventually ignore frame z)
That's because it is field-shifted. And that's why you shouldn't open it and look at frames in VirtualDub.

Field shifted means this, where [ ] denotes the two fields of a frame:
[z a] [a b] [b c] [c d] ...

It is really progressive (pairs of matching fields) but the fields are not matched in frames. Run it through Telecide() or TFM() to match up the fields. Then you won't see the combing in VirtualDub. Telecide() is a part of the DeComb package at http://neuron2.net/mine.html If you are still unsure you can use this from http://neuron2.net/LVG/classifyhighres.html under "Check For Field Shifting of PAL/SECAM Video" to double-check

Note: This section should only be applicable to those whose video is PAL or SECAM (25 fps). Since I personally do not live in a country where PAL/SECAM video is used, this section is based upon what I've read. If something that I've written is incorrect, please contact me. (You can read more about PAL/SECAM and NTSC video at my article entitled NTSC Vs. PAL/SECAM.)

PAL/SECAM telecining, unlike NTSC telecining, generally does not produce duplicated fields that lead to interlacing artifacts. However, sometimes one field of the video is delayed (shifted), which does produce interlacing artifacts. From what I understand, this commonly occurs for movies, which are converted from 24 fps to run at 25 fps.

1) Scroll through your video and locate a part with lots of continuous motion. Portions where the camera quickly pans across a scene are a good choice.

2) Click on Video -> Filters -> Add, and double-click the filter labeled "telecide". (This filter can be obtained from my VirtualDub Plug-ins page.) The default options are fine, so hit OK twice to return to the main VirtualDub window.

3) Press the 'play output' button and watch the video in the output pane. (The play output button [>o] is the third button at the bottom of the VirtualDub window.) If the interlacing artifacts (horizontal lines) are no longer present in the video in the output pane, then your video suffers from field shifting. You can press the stop button, scroll to other parts in your video, and press the play output again to verify that your video really does suffer from this problem. If the interlacing artifacts are still present in your video, then your video probably wasn't field shifted.

You should now know which of these categories your video falls into:
A) Field shifted. No further analysis is needed, scroll down to the section called "Conclusion".
B) Not field shifted. Continue on to the next section.


"field blending" using the separatefields() script above
It means when you look at a field, not a frame, you see two pictures blended together. and from http://neuron2.net/faq.html#analysis with the separatefields thing
It also allows you to spot field blending very easily. If you see any blended pictures, then you have field blending.


In my case of OTA PAL HDTV 1080i sources, the frame types are likely to all be type Interlaced (at least they have been so far, regardless of the nature of the content). Per http://forum.doom9.org/showthread.php?p=1216577#post1216577 1080i50 cannot contain 50 progressive images per second. It can contain 25 progressive images per second. There's always 720p50 for that. And I'm sure we'll see 1080p50 camcorders (not HDV of course) sooner or later.

I don't think we'll see 1080p50 from broadcasters (for a long time, if ever).

P.S. The Canon HV20 does 1080p25-wrapped-in-1080i50. It's a very common format.

All errors are mine, any intelligence in the above is neuron2's. Pending corrections, Human Mind will then be at version 0.9.

[Capsbackup]

Very good info! Thanks. Now following thru with this, I have a similar capture of an OTA broadcast that is NTSC. DGIndex reports a similar code as your example 1 above except NTSC, 29.97fps. After running AVISynth script thru VDub with AssumeTFF(),SeparateFields(), my video shows the pattern ... a a a b b c c c d d ... which would appear to be 3:2 pulled-down progressive video. However, this video still appears to be interlaced when stepping thru with VDub. After changing the script to AssumeBFF(), there is definite forward/backward movement, thus interlaced. So my question is if I want to reencode this video, which is 13.5GB, to a BD-5 size for playback on my Sony Blu-Ray BDP-350, what would my AVISynth script be? I would not want to reencode useless frames, but do not want the audio out of sync either. Any help or suggestions will be much appreciated.

[Guest]

Very good info! Thanks. Now following thru with this, I have a similar capture of an OTA broadcast that is NTSC. DGIndex reports a similar code as your example 1 above except NTSC, 29.97fps. After running AVISynth script thru VDub with AssumeTFF(),SeparateFields(), my video shows the pattern ... a a a b b c c c d d ... which would appear to be 3:2 pulled-down progressive video. Yes, correct. Now the crucial question is whether it is soft pulldown or hard pulldown. Open the VOB in DGIndex and set Honor Pulldown Flags. Do a preview. Do you see the count in the Field Rpts box of the info dialog going up? If so, soft pulldown flags are present. If not, it's hard pulldown. Before we proceed, tell me the result of that test and the Film/Video percent reported at the bottom of the D2V file.

However, this video still appears to be interlaced when stepping thru with VDub. After changing the script to AssumeBFF(), there is definite forward/backward movement, thus interlaced. We just established that it is 3:2 pulled down progressive video! Field order must be known for 3:2 pulldown, however (as you will see shortly), so use this test to determine it, but don't conclude that the video is therefore interlaced. So far we know that you have TFF 3:2 pulled down progressive video.

So my question is if I want to reencode this video, which is 13.5GB, to a BD-5 size for playback on my Sony Blu-Ray BDP-350, what would my AVISynth script be? I would not want to reencode useless frames, but do not want the audio out of sync either. Any help or suggestions will be much appreciated. This thread can only deal with DGIndex, so if you are wanting to remove the pulldown, then it depends on whether it is hard or soft pulldown and whether the 3:2 is a consistent pattern throughout. So, answer the questions above and we'll go from there. Note that removing pulldown does not affect the AV sync.

[Capsbackup]

Thanks for the quick reply neuron2. My movie (.TS file) reports Field rpts and Frame rpts say 0 and do not change with Honor Pulldown Flags selected. Video type says NTSC with no percent being reported.

[Guest]

OK, you have hard pulldown.

First save your project in DGIndex with Honor Pulldown Flags (NOT Force Film). Then make an Avisynth script like this:

MPEG2Source("yourfile.d2v")
Telecide()
Decimate()

You can play that in VirtualDub to see that the pulldown is removed. Then you can open that in the encoder app of your choice.

To include the audio, refer to the Quick Start guide that comes with DGMPGDec.

MPEG2Source() sets the field order for Telecide() but in the very rare case where it gets sets wrong for some obscure reason, your test above could be useful.

If it had been soft pulldown, you could have omitted the Telecide()/Decimate() and just saved your project with Force Film.

[Capsbackup]

Thanks again. I'll give it a try. Your program and advice is much appreciated!!

[halsboss]

Good info again. I've seen web pages suggesting I won't see this in PAL land, however I did wonder how it was done.

[halsboss]

There is a clip which has me stumped since I don't recognize the field pattern. Have looked again at the "how to tell" pages. This is the clip (21Mb) http://youshallnotpass.com:8383/tbclip.ts. Using separatefields() it appears to be TFF (gets jerky if BFF) and have the pattern
a b b c c c d d e e e f f g g g
which isn't the same as any pattern mentioned above (a a a b b c c c d d)

At about frame 110 (without separatefields) there is evidence of horizontal lines similar to interlacing (frame 220 with separatefields, but that does not show these lines).
Open the VOB in DGIndex and set Honor Pulldown Flags. Do a preview. Do you see the count in the Field Rpts box of the info dialog going up? No, it stays at zero.
the Film/Video percent reported at the bottom of the D2V filePreview says NTSC, .d2v says "100.00% VIDEO" at the end.

So, it sort of looks like 3:2 hard pulldown apart from the 1st field is an odd one out ? Is it also field-shifted in some way or did I miss something...

edit er, is it the same pattern after all except missing the 1st frame (2 fields) of the "a"'s ? Where should I ask about how to correct something like that where the pattern could start anywhere within that sequence ?

[Guest]

Adaptive IVTC filters such as Telecide()/Decimate() and TIVTC() automatically adapt to the phase of the telecine pattern.