De-Interlacing - the only REAL answer

[alex_the_g]

I have looked high and low for discussion on this, which I thought would be common but is non-existant, so I hope someone out there may have travelled this path before.

The only real solution to de-interlacing genuine interlaced sources, whether captured through G400 or ripped from DVDs whose original source was video (not film), is to split the fields and double the frame rate (whether you interpolate up the number of lines double to maintain single-frame quality and aspect ratio or not).

BUT although that can give you a beautifully smooth hi-res playback on your monitor (providing your hardware has the oomph) if, like most of us, you want to watch films on the TV via the overlay there seems to be another problem. So far as I can work out, the overlay just won't buy it.

Whereas an interlaced 25fps (30fps if you're NTSC) 576 line (480 if you're NTSC) clip plays back beautifully smoothly on the TV-out, the identical video stream as a progressive 50 fps (60fps ditto)288 line (240 ditto) does not - indeed the stuttering is worse than the version decimated back to 25fps.

This is infuriating and seems totally unecessary! The original version IS being played de facto on the TV at 288 lines 50fps, so why can't I play field-only-height double-frame-rate configured AVIs just the same?

I hope someone has an answer, and a solution. If the hardware designers overlooked this requirement though, any ideas how it might be 'fooled' into working? For instance, a mini-app that takes a progressive half-height double-rate avi and re-interlaces each two fields 'on the fly' before passing to the overlay.

P.S.
Note to the MPEG: how difficult would it have been to include interlacing as part of the MPEG-4 spec, hmmm, hmmm?

[dZeus]

you can make interlaced mpeg4 encodes with for example the XviD codec.

doubling the framerate is not a good solution, as it produces highly increased cpu load on the system when played back, and it's not compatible with tv out like you mentioned yourself.

[alex_the_g]

Does XviD actually have an option to code as interlaced? That is to say, splitting each frame into 2 fields before applying the motion compression algorithms etc., and reinterlacing at playback time to retain the framerate-doubling effect for TV-out? Or is it, as in the DivX 5.02 CoDec I've been using, just a deinterlacing filter applied before coding - of which there are better in VDub/AVISynth etc - and none of which retain the frame-doubling effect of an interlaced video output to TV.

[alex_the_g]

Intrigued by your first comment re Xvid I have spent an entire day doing more searching, and my oh my what a can of worms I have found!!! Doom9s board is currently under an iron fist that the MPAA itself would be proud of (kind of ironic really), preventing any discussion of a NEW MPeg-4 CoDec (as of July) from a company named Sigma and called "RealMagic RMP4". I was interested in it because it claims to be the first Low-Bandwidth CoDec (<2 mBits, as opposed to MPeg-2) which implements the Interlaced part of the MPeg-4 specification (my apologies to the MPEG, for thinking it wasn't in the spec!).

The reason for all this controversy and censorship from the very gods of anti-censorship themselves? There is a SUSPICION that this out-of-the-blue commercial (though free for personal use) CoDec may be ... ahem ... "closer" to XviD than it should!

So far as XviD itself goes, what is implemented and what works seems to vary according to the day's build and who built it. Latest post (August 15th) from one XviD developer suggests Interlacing should be operating in recent builds, but that there is a problem causing encodes with interlacing enabled to be non-Mpeg-4 compliant until the bug is fixed!

http://forum.doom9.org/showthread.php?threadid=31465

In any case, the interlacing option implemented in XviD looks quite inflexible compared to that in the Sigma CoDec - which includes controls for such things as field swapping.

Does it not seem bizarre to anyone else that despite being in the specification, all implementations of an Mpeg-4 Codec either omit interlacing altogether or have it as an afterthought years after initial development. When the vast majority of material for encoding is .... interlaced!

[Flying dutchman]

Splitting interlaced material into fields can work perfectly as long as you get the following things right:


- the field that was recorded first should also be played back first, or you'll get terrible vibration on the screen! Do not assume that this is autoomatically done correctly if you use a frame splitter filter; these normally put the upper frame first which is absolutely wrong in the case of a Marvel!

- The field that was "upper" should remain "upper"; that's a tricky one because the odd and even frames must be scaled differently.

[alex_the_g]

Thanks for that aside Flying Dutchman. Unfortunately, that still doesn't make any difference to the fact that - as dZeus says, and contrary to what 100fps says on his VERY thorough interlacing website - field splitting and storing as 50 or 60 fps is a totally crap idea, BECAUSE THE OVERLAY WILL NOT PLAY IT TO TV! If you can get your TV-out to display smooth 60fps (or 50) please do let us know. I am only interested in the TV-out quality, I couldn't care less what's going on on the monitor!

So far as I can see now, there is ONLY ONE way to maintain the full quality of interlaced video and that is to only use it with CoDecs that genuinely store the Interlaced format: currently MPEG-2 or the RMP4 MPEG-4 CoDec, and perhaps a future implementation of the XviD MPEG-4 CoDec.

I'm still gobsmacked by the lack of solutions. Anyone who wants to view their video in the 'normal' way (and the way for which the content is optimised) via TV must face this problem. I assume they are either sticking to smooth-moving-but-crap with awful compression by trying to MPEG-4 interlaced content, or jerky-but-quality with good compression after a so-called-deinterlace.

All the acres of space devoted to quality and the most imperceptible differences achieved by different settings/CoDecs; but this issue, the non-solving of which means that all MPEG-4 files are inevitably VERY SIGNIFICANTLY more crap than the original, is neither solved nor discussed but passed over in favour of the unacceptably low-quality solution of trying to deinterlace!

One can't help wondering whether, on the part of the corporates, the burying of MPEG-4s interlacing capability was deliberate. Compared to all their clumsy and failed attempts to protect DVD content with security systems, this problem is a far greater obstacle! Just think of the total man-hours that have been wasted simply trying to overcome the fact that when coding from MPEG-2 to MPEG-4 there isn't a flag or a little box to check saying "Content Interlaced - treat fields as frames."

[Flying dutchman]

I did render some interlaced DV video to 50 Hz and it plays perfectly smoothly on my little son's PC that has an old ATI Xpert 2000 graphics adapter with TV-out. At $30 that card was the best buy I ever made on Ebay.

But that card only displays what's on the desktop, converting the 640x480 or 800x600 to 576 lines PAL resolution. You can't really compare that to the Marvel's DVDMAX capabilities. My own Marvel is only a G200 without DVDmax, unfortunately.


One question: If you render a file interlaced (top field first) in whatever codec you have, will a Marvel G400 play it back correctly at all? AFAIK, it only handles bottom-field-first correctly.

[dZeus]

I think alex meant playback to TV of of a 50 fps interlaced stream, rather than 25 fps interlaced.

Anyway, the reason why mpeg4 codecs lack interlaced compression is probably due to the nature of origin: MS developed their codec for online streaming (no interlace needed here), DivX networks continued on the success of the MS codec being used for ripping DVDs to MPEG4 format. Most DVDs can be stored in progressive MPEG4 streams , because most DVD material is of progressive nature.

As soon as MPEG4 will be used for stuff like DV, or HDTV-DVDs, certain corporations will most definately release interlaced-capable MPEG4 codecs. In fact, I can't see why you don't want to use XviD's interlaced implementation? The bug is only small and only prevents ISO MPEG4 compatibility. The developers said they were working on a fix + patch for files which were created with the 'incompatible' codec. That suggests that only the header is incompatible?

[alex_the_g]

Just to make sure everyone thinks I am schitzophrenic, I am going to contradict myself again here!

dZeus, are you absolutely sure that the MarvelG400 DVDMax/Overlay/TV-out (whatever to call it) won't properly handle a 50 fps/288 line (PAL mode) or 60 fps/240 line (NTSC mode) - noninterlaced, obviously, since we just deinterlaced it by field splitting and framerate doubling to get here (!) - video stream without dropping frames? As my previous posts tell, I rejected this last time I tried it but after Flying Dutchman's experience I tried again - and this time it does seem to work (thanks for your persistence FD )!

Thing is, last time I had an ideal clip for testing this - large text moving along the bottom of the screen: beautifully smooth-moving on TV but combed on monitor as MJPEG capture; non-smooth-moving (ie what you expect at 25 fps) on TV and uncombed on monitor after whatever kind of deinterlacing; positively stuttering on TV and uncombed on monitor at 50 fps by field splitting. My current clip isn't so good for the comparison, but I've re-watched and compared till my eyes are square and I'd swear that it is playing at 50 fps on TV this time in the final example - just as FD says.

I find that VDubs special import option to split fields and double frame rate works in its default mode (non-swapped) for me (selecting the swap fields option definitely yields the reversed-fields stutter). But I'm not sure that last time I added the field bob filter option to move even and odd fields up and down a quarter line, to compensate for the second field being shifted up half a line after splitting (or possibly got THOSE the wrong way round, since odd-down even-up seems counter-intuitive but works).

My reasons for a slight reluctance to go to Xvid and use the de-interlace (apart from the small bug, which as you say probably isn't significant) are 1) Having read some CoDec comparisons which either concluded that DivX5 was positively better, or had pros and cons where I liked its pros (eg. perhaps less sharp but not suffering macro-blocks as badly as XviD), those reasons haven't changed, 2) nor has the fact that XviD is still an alpha test, 3) I haven't read a single test or review that made any claim for XviD's interlaced capabilities, but have read doubts about it (one post claiming it made no difference whether it was selected or not), so 4) I don't know what the 'interlace' option of the XviD or RMP4 CoDecs REALLY do, but what I REQUIRE them to do is precisely what I can force to happen by using the process we are discussing - IF it works at playback.