Filters Version: 0.2
Before we start, lets clear up the field a bit.
You DO NOT need any of the two filters (telecide and decimate) if you are working with "pure interlaced data" as opposed to "artificially interlaced data". In plain terms: You don't need these two filters AND YOU SHOULD NOT USE THEM if your source data are coming from:
For the above, you can use one of the other filters, like "-J dilyuvmmx", "-I 1" or "-I 3" (or even smartdeinter). Just remember to read the instructions.
Now that we've thrown away 90% of the readers, its time to describe what is this artificial interlacing we (might) meet in an NTSC DVD and why it requires special care.
As one might guess, American engineers had to interpolate. They also had to cope with the fact that TV isn't actually showing 29.97 frames per sec, but 2 x 29.97 fields per second. What are fields, you ask? Well, check this ASCII art:
scanline 0 --------------------------------- Field 0, 1st line scanline 1 +++++++++++++++++++++++++++++++++ Field 1, 1st line scanline 2 --------------------------------- Field 0, 2nd line scanline 3 +++++++++++++++++++++++++++++++++ Field 1, 2nd line scanline 4 --------------------------------- Field 0, 3rd line etc...
As you can see, each frame is composed from two fields. Each of the fields has 240 lines, thus we finally get 480 scanlines. So, to display film content, which is 24 frames per second, this is what American engineers came up with:
For example, the two first frames are split as follows:
![[Home]](/png/transcode.png)
Frame 1 Frame 2
======= =======
Top Field of Frame 1 (T1) Top Field of Frame 2 (T2)
Bottom Field of Frame 1 (B1) Bottom Field of Frame 2 (B2)
Now, if we had a 24fps Television set, we could see any film easily, if we sent it the following sequence:
T1 B1 T2 B2 T3 B3 T4 B4 T5 B5 T6 B6 ...
====== ====== ====== ====== ====== ======
Frame1 Frame2 Frame3 Frame4 Frame5 Frame6
Unfortunately, we have a stupid 29.97 standard, so this is what we send:
T1 B1 T2 B2 T2 B3 T3 B4 T4 B4 ...
===== ===== ===== ===== =====
N N A A N
As you can see, we have used fields from 4 film frames, but we have
sent them in a way that produces 5 NTSC 'frames': 3 Normal (N) ones,
and two Artificial (A) ones. The displaying is also slowed down,
from 30 'frames' per sec to 29.97 fps.
You see it? These Artificial frames are horribly interlaced! And this interlacing has nothing to do with the normal interlacing found in PAL and NTSC cameras... This is a different monster.
Note that if you use one of transcode's deinterlacing filters with such a sequence, you'll probably get something like this:
T1 B1 T2 B2 T3 B3 T4 B4 T4 B4 ...
===== ===== ===== ===== =====
... that is, two completely identical frames (IF the deinterlacing
algorithm is good enough). And yes, when you encode your sequence
to MPEG4 or whatever, you waste bandwidth for these extra frames.
Not to mention, that a skilled eye will notice that the film is not
natural - any motion will appear jerky, because of the duplicate
frames.
Did I mention that this pattern shifts and jumps throughout the video? In other words, this scheme is not constant; Video editing is performed on fields, and if the DVD authoring studio deletes a series of fields in the middle of the film, the eventual field order is impossible to predict...
The algorithms used in these filters are the basic ones used in the 'Decomb' package (made by Donald A. Graft and available - unfortunately - only under Windows). Thanks for opening up the source, Donald!
First pass:
transcode -M 0 -f 23.976 -i dolby-city.vob -x vob -y xvid,null -w 740 -J ivtc,decimate -V -o /dev/null -R 1 -B 6,13,16
Second pass:
transcode -M 0 -f 23.976 -b 64 -i dolby-city.vob -x vob -y xvid,ogg -w 740 -J ivtc,decimate -V -o test.avi -R 2 -m test.ogg -B 6,13,16
Adding video and audio together in an Ogg stream (you'll need ogmtools):
ogmmerge -o dolby-city.ogm test.avi test.ogg
Some explaining:
-w 740 Target video bitrate is 740000 bits per second
-B 6,13,16 Resize from NTSC 720x480 to 512x384 (4:3 aspect)
-M 0 -f 23.976 it means that the demux must not drop frames on
its own; the filters will do that, producing a
23.976 frames per sec result.
-J ivtc,decimate Always use them in this order, and with no other
filter before them - especially no deinterlacing
and no resizing one!
Additionally, when the telecine pattern shifts (as a result of, maybe, field editing by the DVD authors) a couple of interlaced frames will pass through. These should be deinterlaced on their own. You shouldn't use global deinterlacing after ivtc - it would blur out the otherwise perfect progressive frames that get reconstructed from 'ivtc'. However, transcode's '32detect' filter comes to the rescue: It first checks whether the frame is interlaced, and only then it forces a frame deinterlacing. So, this is what I recommend for your sessions:
transcode -M 0 -f 23.976 -J ivtc,32detect=force_mode=3,decimate ...
To put it simply, 'ivtc' will try to fix the paranoia of telecine. When the pattern shifts (or the algorithm fails) a couple of interlaced frames will slip-by, which are detected and deinterlaced by '32detect'. Finally, the 29.97 frames produced for every second of input are fed into 'decimate', which removes the extra frame.
Hope all this hasn't caused you a headache. If your NTSC DVD contains a film, chances are these filters will help (actually, they are the only 'correct' solution available under Linux).
Since they work perfectly for my NTSC DVDs, I probably won't mess them up anymore. Feel free to change them as you will, as they are available under the GPL.
Thanassis Tsiodras ttsiod@oreilly.softlab.ntua.gr
To e-mail, remove the well known publishing house from my address. The joy of spam, you see...
Modification for Version 0.4.1 by Frederic Briere <fbriere at fbriere.net> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Tue, 6 Jan 2004 11:35:37 -0500 Subject: Tentative patch for ivtc
Hiya! Here's something I whipped out in trying to improve ivtc a bit. My motivation was that de-interlaced frames never look as good as "real" ones, and if you're working with material that was telecined the "other" way (repeating the top frame instead of the bottom frame, or vice versa, I forget), then you end up with only two good frames out of four, instead of three.
The easiest solution is to patch filter_decimate.c to reject the second frame instead of the first, and that's what I've been doing for a few months. However, it seemed that the smartest way would be to adjust filter_ivtc.c itself, which I finally got around to doing.
The field parameter specifies whether you want to work on the top field (by default) or the bottom field. Basically, when you enable verboseness, if you see lots of "using 0" and "using 1", then you stand to benefit from working on the opposite field instead. (If ivtc is using 1s and 2s, you've got it right.)
I also added a bit of "magic", to give ivtc a little nudge towards the current field instead of the previous/next one. When looking at the verbose output, you'll see that ivtc often favors the "wrong" field, ie. if you work on the top field, and have the following frames:
Frame: A B C D E Top field: 1 2 3 3 4 Bottom field: 1 1 2 3 4
Then there is a good chance that frame D will end up with C's top field, for reasons that are beyond me.
The values I chose are completely arbitrary, but they seemed to yield good results for me. Maybe they should be configurable, or maybe there's a much better way to do this. In any case, I made it an option, so it's not in the way if you'd rather not use it.