Decomb v. "Force Film"

[bouis]

While I've also posted this to the "DVD2AVI" forum, I feel
it's just as relevant here.

Is there some function in any version of DVD2AVI which can produce a summary of which frames it found to be "FILM" and which "NTSC" beyond the "FILM 99%" in the "Statistics Window"?

I'm seeking a better way of removing the dreaded combed frames which occur in many non-100%-film movies around chapter points and in random places resulting from post-telecine editing. Here's what I've learned so far:

DVD2AVI "Force Film" output is perfect on areas which it reports as "FILM," but it often causes problems with random combed frames, which, to my knowledge, it always reports as "NTSC" (but doesn't output correctly). Occasionally, poorly telecined material is reported as long sequences of "NTSC" which looses frames and plays "jerky" (with or without combing).

Decomb "Telecide(post=false) + Decimate" generally works well, but often errs on scenes with little or no movement, resulting in combed mouths and flickering candles on areas which "Force Film" works perfectly on. On occasion, it completely chokes, resulting in a sequence of combed frames throughout the rest of the scene, completely wrecking output that DVD2AVI detects as 100% film. Telecide(post=true) just covers up these errors by blurring the bad output. I've found that using "guide" with telecide is useless; it still errs on the same "FILM" scenes and often creates worse output when it finds a lone combed frame.

"Force Film" + "Telecide" (no decimate) is my own improvised solution to randomly occurring interlaced frames. When it encounters combed frames, it replaces them with duplicates of a previous (non-combed) frame. The problem is that it has the other shortcomings of "Force Film" and that Telecide+Decimate can often handle these combed frames better (without any duplicates in the output.)

A detailed log of what decisions DVD2AVI makes would be a great help for choosing which of these methods to employ. I really don't know how DVD2AVI's FILM/NTSC detection works, but it's clearly better than decomb's; it's a shame that decomb can't make use of it to ignore sections of the film which DVD2AVI finds as "FILM."

Is there some other method that I've missed? Anyone have any suggestions? Any input is appreciated.

[Guest]

Originally posted by bouis
On occasion, [Telecide] completely chokes, resulting in a sequence of combed frames throughout the rest of the scene, completely wrecking output that DVD2AVI detects as 100% film.I don't believe that Telecide completely chokes on 100% real film scenes, and I challenge you to provide a clip that shows it. Maybe your sequence is really a 30fps section. After all, DVD2AVI's reporting is not always reliable.

Stop crossposting, there is no excuse for it and the rules explicitly tell you not to. I'll be nice and not strike you this time. :)

[bouis]

for most mercifully not smiting me -- I think.

Your challenge is accepted; a HUFFYUV sample will be at "http://www.datasync.com/~bouis/test.rar" in 90 minutes or so.

Thanks for your help.

Edit: the file size is 13,592,864 bytes.

[trbarry]

DVD2AVI "Force Film" output is perfect on areas which it reports as "FILM," but it often causes problems with random combed frames, which, to my knowledge, it always reports as "NTSC" (but doesn't output correctly). Occasionally, poorly telecined material is reported as long sequences of "NTSC" which looses frames and plays "jerky" (with or without combing).

If this part is true, and I'm not so sure, then it would seem sufficient to only spend the extra processing time on the exceptions, which you claim are already properly identified.

This could be done either by passing DVD2AVI's opinion to Avisynth or, more likely, just adding code to MPEG2DECx to do extra Decomb-like processing when it is not "FILM". I've considered doing this sort of thing for many months now but never quite figured out how or managed to spend the time to find out.

And yes, please don't cross post.

- Tom

[bouis]

I'm sorry.
My post begins and ends with questions (one for each forum), and I thought it necessary to provide a context in which they could be considered.

[bouis]

I can't offer you any technical assistance, but I'd be happy to help test either of those potential applications.

[Christo]

Try to run Decomb's FieldDeinterlace(full=false) after the "Force Film" process to catch occasional combed frames that might have slipped through.

[Guest]

Originally posted by bouis
Your challenge is accepted; a HUFFYUV sample will be at "http://www.datasync.com/~bouis/test.rar" in 90 minutes or so.
Edit: the file size is 13,592,864 bytes. Of course, I'm talking about the input clip, not the processed clip. But you know that -- I think.

[bouis]

Originally posted by neuron2
Of course, I'm talking about the input clip, not the processed clip. But you know that -- I think.
I do. The clip is now available for download:

http://www.datasync.com/~bouis/test.rar

[Guest]

Originally posted by bouis
Your challenge is accepted; a HUFFYUV sample will be at "http://www.datasync.com/~bouis/test.rar" in 90 minutes or so.
The archive appears to be corrupt. Did you try downloading and uncompressing it? I tried twice with the same result -- corrupt archive.

[bouis]

was available the moment I began the upload, although any attempts to download it would have given you an incomplete copy until the upload was completed. It has only been "all there" for a few minutes.

Try resuming your download now.

[Guest]

This script works perfectly on your clip:

Avisource("cleo.avi")
Telecide(post=false,guide=1)
Decimate()

So what is the problem? :confused:

[bouis]

it seems that my conclusions about "guide=1" may have been made prematurely. I'll have to investigate this one farther.

Thanks, and goodnight.

[bouis]

I'm using version 4.01 of decomb.dll.

Try it with:

Telecide(post=false)
Decimate(cycle=5)

Look at output frames 18, 19, and 22.

[Guest]

Maybe that was a reply to a post I deleted. :D

Yes, without guide=1 there can be misalignments. That is why I added the guidance functionality. :p

[Guest]

The problem with DVD2AVI is that it just uses the MPEG flags for its decisions, but these are not reliable, even if you have found one or two movies for which they are reliable. Please see this link (section called "Deinterlacing DVDs"):

http://www.dumbterm.net/graphics/dvd/

Also, the official MPEG committee says this:

INTERNATIONAL ORGANISATION FOR STANDARDISATION
ORGANISATION INTERNATIONALE DE NORMALISATION
ISO/IEC JTC1/SC29/WG11
CODING OF MOVING PICTURES AND AUDIO

ISO/IEC JTC1/SC29/WG11/N2820
July 1999, Vancouver

Source: Video group
Status: Approved
Title: Report on improving the visual quality of non-progressive content on progressive-scan devices

Discussions:

This output document contains the discussions and conclusions of the video group related to the issue of displaying non-progressive content on progressive-scan devices.

While 13818-2 does not define the display process, numerous flags exist that can help the display process, such as the Sequence Display Extension and the Picture Display Extension. The normative semantics of the progressive_frame flag completely describe the temporal relationship between the fields within a coded picture.1 As such, decoders that display content on progressive-scan devices often rely on this flag to pair fields for presentation. A common display practice is as follows: if progressive_frame = 1, the two fields are interleaved for presentation on the progressive-scan device; otherwise, some form of frame rate conversion is performed to convert the output field data to frame data for display.

Due to current editing and encoding practices, the progressive_frame flag does not always correctly convey the temporal relationship between the fields of the original progressive source content. Improper field pairing, dangling fields and the inability to automatically detect the temporal relationship between fields contribute to this problem. Since the progressive_frame flag can not be used reliably during the display process for these situations, visual quality is degraded on progressive-scan devices.

In addition to the progressive_frame flag issue, the practice of inserting repeated fields prior to encoding for simple frame rate conversion causes the source frame rate to be lost during the editing/encoding process (e.g., converting 24 frames/second progressive source to 29.97 interlaced encoded content). The presence of repeated fields is often characterized by the use of the repeat_first_field flag. Since it is desirable to display the content at the original source frame rate on multi-sync displays, the loss of this information results in degraded visual quality.
To avoid these undesirable situations, the video group makes the following recommendations to the editing and encoding communities:

1. The encoding process should make every effort to pair fields that are from the same time instant, that these field pairs should be encoded as frame pictures, and that the progressive_frame flag for these pictures should be set to '1',
2. If possible, the insertion of repeated fields should be avoided by the editing processes and instead be performed by the display process when needed, and
3. The editing process should avoid splicing between two fields that occur at the same time instant (i.e., avoid dangling fields).
Discussions were held regarding the use of additional flags at the picture level to aid the display of non-progressive content that contained field coded pictures or frame coded pictures with improper field pairing. However, the consensus of the group was that these flags would not adequately solve the general problem of improving the visual quality of non-progressive content on progressive-scan devices. There were also concerns raised that adding any new flags to the video stream would incur unnecessary risks. Nevertheless, since this goal is valued as desirable, the group solicits solutions to the general problem.
Future work will look for solutions that will convey information (e.g., progressive/interlaced, frame rate) about the source content through the editing and encoding processes, to assist the display process.

Recommendations:

The video group recommends:

1. To draft on informative annex to 13818-2 describing the proper editing practices, including the expected use of the progressive_frame flag, and issues related to the source frame rate,
2. To send liaison statements to the editing and encoding communities (SMPTE, EBU, DVB, broadcasters, etc.) regarding recommended practices to avoid dangling fields and improper field pairing due to editing,
3. To not proceed with the input contribution proposal, which did not address the problem defined above,
4. To review proposals that do address the problem defined above,
5. To form an ad-hoc group until the Melbourne meeting to draft the informative annex and foster new proposals,
6. To proceed with the SMPTE metadata dictionary as a separate work item outside of this ad-hoc group,
7. To make this output document publicly available to improve education on this problem.
1 Since Corrigendum 1 removed the restriction of frame_pred_frame_dct on the progressive_frame flag, progressive_frame in and of itself does not affect the decoding process.

[trbarry]

Can anyone summarize the way DVD2AVI calculates it's % film statistics. I'm pretty sure it only looks at the flags but have never analyzed the logic behind it.

And can anyone confirm or deny the statement about how, when DVD2AVI says it is film then it really is. I realize there is a lot of improperly flagged material out there like the examples posted above but some of that leaves other traces that show while still looking only at the flags.

For instance, as long as there was a regular 3:2 pattern of repeats and progressive frames I would be inclined to call it good until shown otherwise.

And we should consider that any logic done by DVD2AVI (only) on the flags would be nice performance wise. It would be possible to look ahead hundreds of frames with no noticable performance effects at the time the .d2v file was being built. So if the flags are anything more than worthless it would be nice to do more with them.

- Tom

[hakko504]

Originally posted by trbarry
Can anyone summarize the way DVD2AVI calculates it's % film statistics. I'm pretty sure it only looks at the flags but have never analyzed the logic behind it.

And can anyone confirm or deny the statement about how, when DVD2AVI says it is film then it really is.
- Tom When DVD2AVI says it is FILM then it is FILM. It's when DVD2AVI says NTSC that the problems begin. And, yes, it only looks at the flags in the stream to do this. But it also means that it only says FILM when it is going to add extra frames to make it NTSC. And that this telecining isn't done when you 'Force FILM'.

I've been looking at the possibility of creating two Decomb guidance files (telecide/decimate) from the .d2v data, but I haven't gotten very far yet. I think this is the way to go really, to give Decomb the correct parts to IVTC or deinterlace. It should be a lot faster that way also.

[Guest]

When the YV12 conversion is done I will explore this for Decomb. I fully concur with Tom's idea: to the extent that the flags are useful and available, they should be used.

[Guest]

Originally posted by hakko504
I've been looking at the possibility of creating two Decomb guidance files (telecide/decimate) from the .d2v data, but I haven't gotten very far yet.The .d2v is the log info that bouis is looking for, I suppose. Hakko, do you have documentation on the format/interpretation of the .d2v contents? Thank you.

[Nic]

@trbarry:
My dvd2avi does it as follows:

int rff = info->display_picture->nb_fields-2;
int tff = ((info->display_picture->flags & PIC_FLAG_TOP_FIELD_FIRST) == PIC_FLAG_TOP_FIELD_FIRST);
int trf = (tff << 1) + rff;

PlayBackFieldsNum += info->display_picture->nb_fields;
CodedNum++;

DetectVideoType(trf);


for every frame & then the detectvideotype function is:


void DetectVideoType(int trf)
{
if ((trf & 3) == ((Old_TRF+1) & 3))
FILM_Purity++;
else
NTSC_Purity++;

Old_TRF = trf;
}


Then the info outputted is created using:


void GetTypeText(char *szBuffer)
{
if (NTSC_Purity || FILM_Purity)
{
if (!FILM_Purity)
{
if (m_FrameRate==25.0)
sprintf(szBuffer, "PAL");
else
sprintf(szBuffer, "NTSC");
}
else if (!NTSC_Purity)
sprintf(szBuffer, "FILM");
else if (NTSC_Purity > Old_NTSC_Purity)
sprintf(szBuffer, "NTSC %2d %%", 100 - (FILM_Purity*100)/(FILM_Purity+NTSC_Purity));
else
sprintf(szBuffer, "FILM %2d %%", (FILM_Purity*100)/(FILM_Purity+NTSC_Purity));

Old_NTSC_Purity = NTSC_Purity;
}
}


All variables used are initialised to 0 to begin with.

-Nic

[hakko504]

Originally posted by neuron2
Hakko, do you have documentation on the format/interpretation of the .d2v contents? Thank you. Not really, my intentions were to use the source for Mpeg2dec.dll as a starting point for this work. Don't remember exactly where I found it, but in a section of the decoding there is a check for the repeated field flags. I know I found it by searching for 'Force Film'. Basically my idea was to remove the actual decoding parts and replace them with a filewriter that wrote the exact repetition pattern to a file that could be used by decomb to recreate the original pattern. Then in the NTSC parts, it should rely on whatever it can find by looking at the frames, maybe mark these as 'de-interlaceable'

[trbarry]

If I understand it correctly, MPEG2DEC loads these into a big table when it loads the file. For Avisynth it would probably be possible to have a call that returned the address of that table for a clip. No reason to parse the file twice or to be vulnerable to format changes.

BTW, I notice some of my d2v files have 5 or 6 as the flag numbers. Anyone offhand know what the extra 0b00000100 bit means? (maybe progressive?)

@Nic - Thanks. It doesn't seem to be looking much at any bit patterns. Maybe more could be done along those lines to notice cadence changes and stuff which would be immediately suspect in film material.

- Tom

[Nic]

@trbarry:
5 & 6?! very strange the real code from dvd2avi is:
(gethdr.c)
d2v_current.trf = (top_field_first<<1) + repeat_first_field;

and the output code is:
(getpic.c)
fprintf(D2VFile, " %d", d2v_current.trf);

5 & 6 should never happen...strange :confused:

-Nic

[scmccarthy]

Here's a question:

If DVD2AVI adds frames to the sections it calls FILM to make it compatible with the NTSC sections, does it decimate every 5th frame in the NTSC sections when in Force Film mode?

Because it would be nice to have a third option where DVD2AVI did not do either and we could let an IVTC filter deal with it separately.

Stephen

I did not notice there was already a 2nd page to this thread this morning until *after* I posted this message.

[hakko504]

Originally posted by scmccarthy
Here's a question:

If DVD2AVI adds frames to the sections it calls FILM to make it compatible with the NTSC sections, does it decimate every 5th frame in the NTSC sections when in Force Film mode?

Because it would be nice to have a third option where DVD2AVI did not do either and we could let an IVTC filter deal with it separately.

Stephen

Yes, and yes.
Actually it is even worse, it decimates every 5th field, so that if you have a correctly telecined 1t1b 1t2b 2t3b 3t3b 4t4b sequence, it will produce 1t1b 2t2b 3t3b 4t4b. But if you have NTSC 1t1b 2t2b 3t3b 4t4b 5t5b then you will get 1t1b 3t2b 4t3b 5t5b. Ouch! top first becomes bottom first. :(
And I think your other suggestion is rather similar to what trbarry suggested. The point is that DVD2AVI writes all available data to the .d2v file. It is up to Mpeg2dec to parse it correctly.

[scmccarthy]

Oops OK, that's right.

DVD2AVI just creates a d2v file that a mpeg2dec.dll can over-ride.

So the question should have been whether there is a version of mpec2dec.dll that delivers all frames as is and lets another filter handle the rest. But I was only thinking of the options that DVD2AVI offers and was not thinking of mpec2dec at all.

Sorry, I have not been keeping up on the mpeg2dec options available. I would have checked that first before I posted my question if I had thought of it.

Stephen

[trbarry]

5 & 6 should never happen...strange

I don't know how I made this but it was from the superbit CTHD disk. I think I was playing with an early version of VdubMpeg2. I just found it by scanning my drives for .d2v files when we started talking about it on this thread.

But if I can't reproduce it (still have vobs) then I guess I'll assume 5&6 don't need to exist.

It is indeed strange though. And since it is allowable to code some frames as progressive then it seems DVD2AVI should save that flag too. But maybe it has no use in the d2v file. Have to think about this one.

If anyone else has d2v files that have flag values of 5 & 6 in them it would be nice to hear where they came from, and what it means.

- Tom