Boken deinterlacing

[c.lambin]

This is a very old bug still not corrected.

Tested on VLC 0.86c on Windows and MacOS X

Description :
When deinterlacing videos in 50i (PAL) or 54.94i (NTSC) standards, the only way to get a smooth video motion is to select one of those deinterlacing methods : Bob or Linear.
Doing this doubles the framerate. So the deinterlacing filter needs to know, from an original frame, which field comes first : the upper field (odd lines) or the lower field (even lines). As far as I understoond the only difference between Bob and Linear is that Bob only doubles each other lines, while Linear do a linear interpolation to recreate missing lines.

Bug :
By checking the source code, it's easy to see that the order of the fields being interpreted is fixed. That means that those filters always decode fields in the same order and are not at all connected to the decoder in any way to know what is the current field order.
The problem is, in many cases they decode fields in the wrong order.
The professional video standards define fields order this way :
NTSC : Always lower field first
PAL : Always upper field first, except for DV and DVD.

I did my tests with PAL sources only, because that's where the problem lies. Broadcasted PAL should always be in upper field first, but in practice it's now often lower field first, espescially on IPTV. If you're in France with a Freebox, just watch the Nolife TV channel : it broadcasts in lower field first. The Bob & linear filters then inteprets the video in the wrong field order and the resulting video stutters a lot (an effect called temporal field inversion). The fact is the field order information is in the MPEG2 stream and should be taken into account by the deinterlacing filter.

My tests showed the following :
- PAL DVDs always show OK (lower field first)
- PAL DV sources are always broken (lower field first)
- MPEG2 PAL sources (PS/TS), including compressed for DVD before authoring, are broken, except when upper field first

It seems that the deinterlacing filters expects the fields to be always in the same order and that the ok/broken results are because of the MPEG2 decoders to be able to switch the field order or not, depending of the source, to suit the deinterlacing filters. IMO something should be added to forward the field order from the decoder to the deinterlacing filters.

Unfortunately even if I'm able to open the source code and search for some evidences, I do not have the skills to do the fix. So I hope my report would help some of the VLC developpers.

[fenrir]

I have commited a fix.
It should work in the next nightly build.
Thanks for your report.