HiCon32 Demo: Discards frames unexpectedly

[opieant]

I've been experimenting with the HiCon32 demo and since it is related more to HDTV than anything on this forum, I felt it should be posted here. The program is available for download here. (http://www.hhi.fraunhofer.de/german/bs/HiCon/downloads.htm)

After performing many tests, it seems that this application discards frames from the source video without warning. This doesn't happen on all clips I've used however, just some. The source clips were in DV format (720x480 and 29.97FPS), the "Top Field First" option was unchecked (since the bottom is first), the "Source Is Interlaced" option was chosen, and the "Add Line On Top" option didn't matter. The output format also didn't seem to matter, however I tested using AVI format with Uncompressed RGB output, AVI format with DivX 5.1.0, AVI format with DivX 5.1.1, and the SLB format. The same frames were discarded in all cases.

Keeping in mind that the frame rate is doubled by the SDTV Deinterlacing filter, some of the results were:
10 Frames in, 20 Frames out (good)
100 Frames in, 167 Frames out (bad, 33 lost)
88 Frames in, 80 Frames out (very bad, 96 lost)

Tests were also done with some longer clips and the number of lost frames just increases. Even with the similar source clip "HHI - SDTV(30i) XviD.avi" from the HiCon32 web site, if it is processed in "Top Field First" mode, 50 frames go in and only 55 come out (so 45 lost). This makes me think that while my source material really is "bottom field first" that the program interprets certain transitions in the video as being incorrect relative to the general flow of motion and it is discarding those. This seems unlikely to be the problem with my clips however because the motion in the source video isn't jerking around in any manner that would confuse the program, and I'm always processing it in "bottom first" mode (after "top first" was tested and produced disgusting results of course).

Another theory is that it is discarding (without notice in the Report Log) some or all frames that appear to be identical to the previous frame. Based on the clip that had 88 frames in and only 80 out, this is far more likely to be what is happening. Looking at the interlaced 88-frame source, there are several frames that are nearly identical to the previous one, and since this is a clip of fast motion, they certainly seem to be duplicates and could be interpreted as such. On top of that, when the program extracts the two fields from each frame, the number of apparent duplicates doubles since each field will be used to construct a full frame in the output.

Based on all of this, I am wondering if anyone else has had similar experiences with this application, and if so, how could its tendency to discard frames be avoided? As another slightly less appealing option, does any program exist that could process the interlaced (as a source only) and deinterlaced (as a second source AND for output) material in a way that compares the frames between them and duplicates the most recent frame in the deinterlaced material until the interlaced source changes reaches a frame (or field) more similar to the next deinterlaced frame than the most recent deinterlcaed frame? I know this probably sounds like it could be terribly inaccurate, but since it could assume that the two sources are of the same thing, and because it could compare each of the fields in the interlaced source as separate frames (interpolated from 720x240 to 720x480), it seems like it could be quite feasible and accurate.

Thanks to anyone that took the time to read and consider what I've posted here, and hopefully someone will have a bit of advice to offer.

Greg F.

[pinkish]

Hey Greg,

I've just tried Hicon32 and it's happening for me, too. Small clips have, after convertion, the normal (double) number of frames. But if you input slightly longer clips, there's a lot of frames that are discarded. I don't know the cause for it and I'm terribly disappointed, because the deinterlacing for a small test clip produced excellent results.

If you can, please post some more on this subject - have you found any other program that would yield better results?

LATER EDIT: the program discards the same number of frames if you process the same clip, so i guess it's something algorithm-based, not some internal errors...

[opieant]

One post per year in this thread, heh. Excellent.

I came up with a somewhat messy workaround (described below) for the problems with HiCon32. It involved marking each frame of the video in the source material such that the places where frames were dropped can be detected later. Since they're dropped due to no motion changes being detected, it works to just repeat the last frame before the dropping started. The number of times to repeat the frame seemed to be limited to about 4 frames, although I don't remember the exact number.

When all was said and done, I found myself disappointed by the deinterlacing quality in the clips I tested with so I didn't bother to tidy up the workaround for public release. Unfortunately, I don't have time now to refine it, but it can certainly be done.

My method was to insert white bars on the side of the video (which was wasted space that would be cropped later anyways) and have the bar move from the top-left to the bottom left with eight possible locations. I think this was done by using a logo inserting function of AVIsynth along with some bitmaps generated for the appropriate resolution. Once the bar reached the bottom-left, it would return to the top left. By using AVIsynth to measure the luminance of each of the eight locations, I could determine where the white bar was in each frame. This data would be analyzed to determine where frames were dropped and how many times to repeat "filler" frames. An AVIsynth script file could then be produced that repeats the frames as necessary with 100% accuracy. After that, you can finally compress the video to your format of choice.

There's probably a much simpler method though, like changing a byte or two of the HiCon32 executable to correct the frame-dropping bug, but that's currently beyond my abilities.

Greg