Thoughts on encoding interlaced content

[djloewen]

I will shortly be taking on the task of encoding all of my DVDs into video files (I have decided on H.264 + Matroska), and as with many of you, I am trying to decide what to do with interlaced content. Please share your thoughts with me on this:

In making decisions, my primary guide is the idea of preserving the original format of the film/video

-for hard pulldown/telecined content, IVTC is the way to go for me.

-for pure interlaced NTSC content, the video was originally meant to be played back at 59.94 fields per second. I have seen two methods of "faking" this in progressive playback that I like. The first is to do a blend deinterlace at 29.97 frames/second, the second is to bob the fields into frames and play back at 59.94.

These methods are good, but they're not perfect. In past discussions such as this (and there have been many, I know) some people have claimed that the best thing to do is just leave it interlaced. To me this is a great solution IF (and only if) it can actually be played back non-progressively (i.e. have the TV set, computer monitor or handheld device actually draw just the odd lines, then the even ones, etc). Otherwise you're either relying on decoder deinterlacing or you're just watching a jaggy mess. Personally, I do not like the idea of relying on the decoder to do any such thing.

So, is it at all possible to flag a video for interlaced playback? I have the impression that many screens can't even do this. HDTV sets obviously can (right? they're not just deinterlacing TV or something?), but is there any way to tell them to do this for video files?

Assuming that's not possible: An idea occured to me, regarding the best way to "fake" this sort of playback on progressive monitors. I'm sure someone out there has tried this, but I've never seen it mentioned in posts before. What if you encoded the video at 59.94fps, encoding the whole frame each time but only changing one field per frame?

So if the original video was:
1t 2t 3t 4t 5t
1b 2b 3b 4b 5b

bobbing to 59.94 would be:
1t 1b 2t 2b 3t 3b 4t 4b 5t 5b
1t 1b 2t 2b 3t 3b 4t 4b 5t 5b

but what I am suggesting is:
1t 1t 2t 2t 3t 3t 4t 4t 5t 5t
-- 1b 1b 2b 2b 3b 3b 4b 4b 5b

Is this worth trying, or does it still end up looking like an interlaced mess?

[Sagekilla]

You either encode as progressive or encode as interlaced: That's the only "flagging" the goes on really (ignoring 24PsF or hard coded telecine). Also, what you suggest just won't work. You're going to end up with a really screwed up output. I'll post an example in a few mins of what it'll look like.

Just stick with either:
1) Encode as 60i
2) Use a high quality deinterlacer to smart-bob it to 60p (TGMC, MCBob, MVBob, etc)

[Jay Bee]

right? they're not just deinterlacing TV or something?)

That's exactly what they are. Only tube-type displays can deal with an interlaced signal, all HDTVs have their own deinterlacing electronics while computer LCDs usually need to have the signal deinterlaced by the GPU as they lack deinterlacing capability.

[Sagekilla]

Depending on your hardware and how you set it up, your system might do a couple of different things, in order of quality:

1) 30i (worst)
2) Dumb bob to 30p
3) Dumb bob to 60p
4) Smart bob to 30p
5) Smart bob to 60p (best)

If you have hardware acceleration on your GPU, you'll likely get 4 or 5. Unless you have a GPU, the output will probably be a soft dumb bob.

Like Jay Bee said, if you have a CRT TV they can handle interlaced signals perfectly fine. If it's any other kind (LCD, Plasma, DLP, etc), then it has to use it's own built in deinterlacer which could be very good or absolute crap.

[djloewen]

Thank you for your responses - I hadn't realized that non-CRT displays were always progressive. So, even if my idea worked, each frame would end up getting deinterlaced by most hardware anyway... hrm.

Sagekilla, when you say "encode as 60i" what exactly do you mean? If I just encode the original source without deinterlacing then isn't it 30i, since it's 30 interlaced frames?

I would like to implement my idea with AVIsynth, just to see what it looks like. I'm not very handy with AVIsynth, maybe someone could help me? Here's what I think might be easiest:

-load the video clip in two streams, one with just the top fields, and one with just the bottom.
-duplicate every field/frame in each stream, and add a single field/frame of black to the beginning of the second stream. So the first stream would be:
1t 1t 2t 2t 3t 3t 4t 4t 5t 5t
the second would be:
bk 1b 1b 2b 2b 3b 3b 4b 4b 5b 5b
-interleave the streams together, to create a single stream:
1t bk 1t 1b 2t 1b 2t 2b 3t 2b 3t 3b etc
-weave the fields back into frames, and you should end up with what I want.

So, what might the codespeak for all that be?
Thanks in advance!

[Sagekilla]

Sorry, I meant encode as 30i. I was probably on drugs or something when I wrote 60i. Also, as I said before, what you think "might work" would look very screwed up. What you're essentially doing is temporally shifting all bottom fields by one, which gives a VERY bad looking image.

Explanation: Each field is taken from a distinct time. For four fields, t0, b0, t1, b1 you have four times each was taken at:
t0 = 1/30s
b0 = 2/30s
t1 = 3/30s
b1 = 4/30s

I know what you're thinking but since each is temporally distinct you can't just shift a field back or forward and expect it to come out right.

Can't figure out the exacts of it (for good reason, there's no reason to do what you suggest) but it looks like this:


source = last
length = 1000 # The number of frames your video has, NOT fields! If you know the exact number fields, use half that for this value.

input = source.AssumeTFF().SeparateFields()
input = input.Trim(0,1).DeleteFrame(1) ++ input.DeleteFrame(2*length-1)

weave(input)


Here's a slow pan of an image that was converted to have fake interlacing:
http://img222.imageshack.us/img222/7498/fakeinterlacenh8.jpg

And after your idea:
http://img222.imageshack.us/img222/1804/yourmethodtg8.jpg

Fake interlace 2:
http://img80.imageshack.us/img80/3333/fakeinterlace2nc3.jpg

Your method:
http://img145.imageshack.us/img145/4533/yourmethod2qc6.jpg


I don't know why anyone would need them (other than to horribly mangle a source) but here's the scripts:

function InterlaceClip(clip clip) {
fields = clip.SeparateFields().SelectEvery(4,0,3)
frames = fields.Weave()
return(frames)
}

function shiftFields(clip clip, int frames) {
input = clip.AssumeTFF().SeparateFields()
input = input.Trim(0,1).DeleteFrame(1) ++ input.DeleteFrame(2*frames-1)
return Weave(input)
}

[djloewen]

Hrm, I don't think I've explained myself properly.
Regarding your explanation about each field being taken from a distinct time, I assume you meant:
t0 = 1/60s
b0 = 2/60s
t1 = 3/60s
b1 = 4/60s

That is exactly what I am trying to recapture. The idea is to leave the top fields where they are temporally, but shift the bottom fields 1/60 (NOT 1/30) so that they assume their proper temporal location.

I have managed to piece together a script which is almost exactly what I want. It's clumsy, but...

stream1 = mpeg2source("x").SeparateFields.SelectEven
stream2 = mpeg2source("x").SeparateFields.SelectOdd
dupstr1 = Interleave(stream1, stream1).DeleteFrame(0)
dupstr2 = Interleave(stream2, stream2)
stream = Interleave(dupstr1, dupstr2).Weave

It's hard to tell by just looking, but each time you step through a frame, only a single field of the picture is actually changing.

The minor problem is that, rather than deleting the first frame from the "top" stream, I would rather be adding a black frame to the "bottom" stream. When I try BlankClip it gives me grief about audio streams being present in only one of the clips. Otherwise, this is exactly what I want.

The major problem is that I can't get this script to encode. I'm trying it with DivX through Gordian Knot (which is what I'm currently familiar with), and it's telling me that the "source image format is not acceptable".

So just to clarify, I realize that any given frame of this 60i output would look just as interlaced as the 30i. What I am trying to do is recreate the experience of watching 60 fields per second in a brave new world that only speaks in whole frames. This is based on the assumption that the "60 fields" thing always looked okay on TVs when I was growing up, and in the end, that was the way it was meant to be played back.

[Sagekilla]

1/30s vs 1/60s, those are minor technical details. The main brunt of what I'm saying is there though: You can't turn interlaced 30i or 60i into some "progressive-like" format by shifting the fields forward or backward in time. Like I said, each field exists in a distinct moment in time. The bottom field of frame 1 is taken from a different time from the top field of frame 2, that's inherently how interlacing works. No two fields are taken at the same time, so you can't push a field back or forward in time and expect it to spatially match up if they were taken from two distinct times with different motion present in each.

You're much better off trying to use one of the good deinterlacers out there like MCBob, MVBob, TGMC, LeakKernelDeint, TomsMoComp, etc than trying to do this.


Revision:

Stream = MPEG2Source("x").AssumeTFF()
Even = Blackness(width=Stream.Width(),height=Stream.Height()).SeparateFields().Trim(0,1).DeleteFrame(0) ++ Stream.SelectEvery(2,0).DeleteFrame(0)
Odd = Stream.SelectEvery(2,1)
Output = Interleave(Even,Odd).Weave()
return(Output)


I don't know why you're trying to do this, but 30i can't be turned into true 30p using this method. The only way to get 30p is to reinterpolate the lines using a dumb bob or do smart deinterlacing to create the original data.

[djloewen]

Hm, your code still isn't working for me. There are also some conceptual problems with it:
-it never splits the frames into fields
-it never duplicates the fields
-it adds black to the wrong stream

I have managed to get the black frame thing working by using my clip as a template for BlankClip. This code is exactly what I want:

#Opens the source and splits it into fields
Stream = MPEG2Source("x").AssumeTFF.SeparateFields()

#Splits the stream into TF-only and BF-only streams
Top = Stream.SelectEven
Bottom = Stream.SelectOdd

#Duplicates every field in each respective stream
D_Top = Interleave(Top,Top)
D_Bottom = Interleave(Bottom,Bottom)

#Adds a single black field to the beginning of the lower stream
Black = BlankClip(D_Bottom,length=1,color=$000000)
D_Bottom_Shift = Black ++ D_Bottom

#recombines the resulting top and bottom field streams
Output = Interleave(D_Top,D_Bottom_Shift).Weave()
return Output

No two fields are taken at the same time, so you can't push a field back or forward in time and expect it to spatially match up

That is correct, but I am not trying to match up two simultaneous fields. Here's what I want:

1/60s: the first field gets displayed. BF is still black
2/60s: the second field gets displayed. TF doesn't change
3/60s: the third field gets displayed, replacing the TF that was displayed at 1/60. the BF doesn't change
4/60: the fourth field gets displayed, replacing the BF that was displayed at 2/60. the TF doesn't change

...etc. Isn't that exactly what CRT televisions used to do?

Anyway the problem is, my new code still isn't working. I can view it in VDubMod (although it can't play back at full frame rate, which makes it useless for testing), but when I try encoding it with DivX through Gordian Knot, I get a VDubMod error saying the "source image format is not acceptable". What on earth is wrong with it??

[Jay Bee]

If I understand you right you are trying to create a deinterlacer that simulates the physics of a CRT. Nice idea but it won't look good. The physical effect you are missing is that by the time the new field arrives on the screen, the old field will have faded quite a bit on the CRT. Your method mixes together two fields that don't temporally belong together. To simulate one field fading away you would need much higher update rates for the LCD display, so that you could go through several steps of fading in 1/60 of a second. This is one reason why deinterlacers don't try to simulate CRT physics.

There are many deinterlacers out there that will give you excellent results though, f. ex. mvbob or ATI's Vector Adaptive deinterlacing (don't know what Nvidia's equivalent is called).

[Jay Bee]

Anyway the problem is, my new code still isn't working. I can view it in VDubMod (although it can't play back at full frame rate, which makes it useless for testing), but when I try encoding it with DivX through Gordian Knot, I get a VDubMod error saying the "source image format is not acceptable". What on earth is wrong with it??

If it already runs in Vdubmod why not try encoding from there instead of Gordian Knot? And try a different codec, it sounds like Divx doesn't like your input.

[pcordes]

1/60s: the first field gets displayed. BF is still black
2/60s: the second field gets displayed. TF doesn't change
3/60s: the third field gets displayed, replacing the TF that was displayed at 1/60. the BF doesn't change
4/60: the fourth field gets displayed, replacing the BF that was displayed at 2/60. the TF doesn't change

...etc. Isn't that exactly what CRT televisions used to do?


No. Like JB said, LCDs are different.

CRTs scan an electron beam across a phosphor-coated picture tube. Try taking a picture of one with a fast shutter speed on your camera, for example, and you'll just see a couple lines of image lit up. The human visual system sees a whole image because of the persistence-of-vision effect. If you don't know about this, go read up on it, there's a lot of neat stuff about how what we think we see is different from the images focused onto our retinas at any given instant. (e.g. saccades, among other things.)

Anyway, a CRT draws an image one pixel at a time, scanning left to right for each line, and down the screen one line after another. In interlaced video modes (like NTSC 60i and PAL 50i TV), it draws every other line, alternating which set. So it really does show you both half-resolution fields at different times. Your visual system isn't fast enough to really notice that every other line of each picture is blank. If the image is bright, and you're paying attention, you should be able to notice interlacing artifacts, though. Mostly it's just that NTSC looks horrible (in other ways, too) if you've learned to notice it. So if you like your TV, avoid learning to notice it! Not really an option if you're looking for potential problems in the output of a deinterlacer you're trying out, though.

An LCD, OTOH, always has all its pixels lit simultaneously by the backlight. So if you show two fields from different times in one picture, they'll both be lit at the same time, and your visual system _will_ notice that it looks all jaggy. The only option I can think of for simulating an interlaced display would be to show fields with black pixels in the gaps, not stale fields. Although I imagine that would be noticeable, and look bad.

BTW, if your computer doesn't sync video with the refresh rate of the screen, you get tearing of progressive video, but it's an even worse mess with interlaced video.


How to encode interlaced content depends on how much bitrate you have to throw at it, and what video processing options will be available on decode. It might sometimes be better to encode the interlaced content, and deinterlace it on playback. Then you can use a deinterlacer that outputs 60p from 60i input, without having to encode twice as many pixels (although the pixels will be more redundant, and interlaced encoding is less efficient...)

So it may depend on whether your content looks ok deinterlaced 60i -> 30p, or if you need 60p. Or if you have mixed telecined-film and interlaced-video content, there's no optimal choice for the whole video. mplayer has some good docs about handling mixed content:
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-telecine.html
But for mixed content, HandBrake can do something mplayer can't: It can output a variable-framerate mkv, with the telecined sections detelecined to 24p, and the really interlaced bits deinterlaced to 30p. (I don't know if you can get it do deint to 60p.)

You can build HandBrake with libx264 compiled from git, since they don't keep the version included with it perfectly up to date.

Anyway, for mixed video and film, I've had great results with HandBrake. I don't remember how well it detects hard telecined DVDs, or if it just looks at the MPEG flags to detect soft telecine, so be sure to check that out...

[roozhou]

Hm, your code still isn't working for me. There are also some conceptual problems with it:
-it never splits the frames into fields
-it never duplicates the fields
-it adds black to the wrong stream

I have managed to get the black frame thing working by using my clip as a template for BlankClip. This code is exactly what I want:

#Opens the source and splits it into fields
Stream = MPEG2Source("x").AssumeTFF.SeparateFields()

#Splits the stream into TF-only and BF-only streams
Top = Stream.SelectEven
Bottom = Stream.SelectOdd

#Duplicates every field in each respective stream
D_Top = Interleave(Top,Top)
D_Bottom = Interleave(Bottom,Bottom)

#Adds a single black field to the beginning of the lower stream
Black = BlankClip(D_Bottom,length=1,color=$000000)
D_Bottom_Shift = Black ++ D_Bottom

#recombines the resulting top and bottom field streams
Output = Interleave(D_Top,D_Bottom_Shift).Weave()
return Output



That is correct, but I am not trying to match up two simultaneous fields. Here's what I want:

1/60s: the first field gets displayed. BF is still black
2/60s: the second field gets displayed. TF doesn't change
3/60s: the third field gets displayed, replacing the TF that was displayed at 1/60. the BF doesn't change
4/60: the fourth field gets displayed, replacing the BF that was displayed at 2/60. the TF doesn't change

...etc. Isn't that exactly what CRT televisions used to do?

Anyway the problem is, my new code still isn't working. I can view it in VDubMod (although it can't play back at full frame rate, which makes it useless for testing), but when I try encoding it with DivX through Gordian Knot, I get a VDubMod error saying the "source image format is not acceptable". What on earth is wrong with it??

You need a ConvertToYv12().

[Comatose]

So wait, progressive TVs always deinterlace, regardless of whether the material is telecined or really interlaced?
Or do they attempt to IVTC and then deinterlace on combing like TFM?

[roozhou]

So wait, progressive TVs always deinterlace, regardless of whether the material is telecined or really interlaced?
Or do they attempt to IVTC and then deinterlace on combing like TFM?

IMO no hardware does ivtc like TFM. How could a LCD decide whether the video is telecined or pure interlaced? And how could a LCD look ahead 5+ frames like TFM does?

[Sagekilla]

Depending on the source, telecined material is either native 23.976 fps with soft pulldown (flags rearrange the stream to 30 fps) which gets removed anyway by nearly every source, or hard pulldown which still gets removed in most hardware or software players.

So I can't imagine a case where telecined material wouldn't have the pulldown removed.

[pcordes]

So I can't imagine a case where telecined material wouldn't have the pulldown removed.

Here's a case: DVD player outputs NTSC video signal, which by definition is 60i. The LCD it's connected to can't see any flags or anything, just an analog video signal, and it's not going to add latency to give itself a window to see the telecine pattern. That would bork the a/v sync. So it deinterlaces.

If you say, "well you're using NTSC, there's your problem right there", you'd be right. :rolleyes:

But even in a situation where a player outputs interlaced video digitally (e.g. 1080i60), the LCD probably just deinterlaces.

I think you have to kill interlacing at the source, i.e. in the player before it outputs any interlaced video signals. Interesting to hear that some HW players might ivtc hard-telecined video. That's impressive. On Linux, none of the common players I'm aware of can ivtc on playback. e.g. mplayer's design prevents changing frame timestamps. You have to use mencoder to make another video, and play that. I think I have tried running a video through mencoder on the fly, though. So much video software on GNU/Linux has crufty one-frame-in one-frame-out designs and crap like that... grrr...

[roozhou]

Here's a case: DVD player outputs NTSC video signal, which by definition is 60i. The LCD it's connected to can't see any flags or anything, just an analog video signal, and it's not going to add latency to give itself a window to see the telecine pattern. That would bork the a/v sync. So it deinterlaces.

If you say, "well you're using NTSC, there's your problem right there", you'd be right. :rolleyes:

But even in a situation where a player outputs interlaced video digitally (e.g. 1080i60), the LCD probably just deinterlaces.

I think you have to kill interlacing at the source, i.e. in the player before it outputs any interlaced video signals. Interesting to hear that some HW players might ivtc hard-telecined video. That's impressive. On Linux, none of the common players I'm aware of can ivtc on playback. e.g. mplayer's design prevents changing frame timestamps. You have to use mencoder to make another video, and play that. I think I have tried running a video through mencoder on the fly, though. So much video software on GNU/Linux has crufty one-frame-in one-frame-out designs and crap like that... grrr...

Actually MPlayer's ivtc filters delay 1~2 frame and remove pts from all frames. But for containers with frame duration information, e.g. avi, dvd and wmv, ivtc works fine.

[nm]

On Linux, none of the common players I'm aware of can ivtc on playback. e.g. mplayer's design prevents changing frame timestamps. You have to use mencoder to make another video, and play that. I think I have tried running a video through mencoder on the fly, though. So much video software on GNU/Linux has crufty one-frame-in one-frame-out designs and crap like that... grrr...
Sorry for the off-topic response, but Xine's tvtime post-processing plugin has basic IVTC capabilities. Something like this should work for normal 3:2 hard (and soft) -telecined sources:
xine --post tvtime:method=Greedy2Frame,enable=1,pulldown=vektor,framerate_mode=full,judder_correction=1,use_progressive_frame_flag=1

[djloewen]

Thank you all for your informative responses! I'm definitely curious about Handbrake's ability to encode variable framerate. One concern however: I want to make sure that the videos I encode will be playable on as many devices as possible. Now as you may all know, DivX will be shortly releasing their H.264 codec into the mainstream market, and while I'm not sure if I will use it or x264 for the encoding, I intend either way to stay inside DivX's specs so that my vids stand a better chance of playing on all sorts of players in the future. In framerate terms I think this will mean sticking with whatever is in ATSC specs (23.976, 24, 25, 29.97, 30, 50, 59.94, 60), and I suspect it means that variable framerate is out.

Regarding deinterlacing generally, I'm still a little torn as to whether to do it or not. Personally I have not had great success with deinterlacing in AVIsynth - the results look fine, but not amazing or anything. I see in the ever-growing post about neuron2's DGAVCindexNV that the deinterlacer in Nvidia cards seems to be superb - and since modern TVs have to deinterlace television anyway, I'd imagine that they'd be pretty good at it too (and they'd just get better with time). However, I'm still not thrilled about being dependent on the hardware like that. Decisions, decisions...

Anyway thanks again for all your help.

[Sagekilla]

Honestly, the fact of the matter is you have to deinterlace at some point: Whether it's before encoding or after encoding. Nearly all TVs, except CRTs, require a progressive image so you'll have deinterlacing (which may be good, bad, or horrible) done at display end or before you encode it (generally high quality). As a special case of display side deinterlacing, if you have a graphics card they will provide very good deinterlacing if it's output through the built in decoder.

So there's your two choices:
Deinterlace before you encode (higher coding efficiency --> better quality/lower file size, nearly always good (but slow) quality)
Deinterlace after you encode (lower coding efficiency --> lower quality/bigger file size, hit or miss deinterlace on displays except for video card output)

In the case of deinterlacing before you encode, you can keep the full 60 fields reconstructed into 60 frames, and get full vertical resolution and temporal resolution if it's done right. 60 fps vs 30 fps will cause a bitrate hit, but interlacing on x264 isn't so great (but still better than other encoders) so the difference may be minor.

My recommendation? Try both methods and see which one you like best.

[Jay Bee]

...Deinterlace after you encode (lower coding efficiency --> lower quality/bigger file size...

...60 fps vs 30 fps will cause a bitrate hit...

Contradiction?

[Comatose]

Here's a case: DVD player outputs NTSC video signal, which by definition is 60i. The LCD it's connected to can't see any flags or anything, just an analog video signal, and it's not going to add latency to give itself a window to see the telecine pattern. That would bork the a/v sync. So it deinterlaces.
Why not? It can just delay the entire thing (including the audio) by 5-10 frames.
People are already used to TVs, DVD players and STBs like that having a short delay when changing channels or sources, so I don't see the problem.

IMO no hardware does ivtc like TFM. How could a LCD decide whether the video is telecined or pure interlaced? And how could a LCD look ahead 5+ frames like TFM does?
That answers the "5 frame" part.

As for telling whether it's telecined or interlaced -
It would attempt IVTC. If it fails, it would switch to deinterlacing. Optimally, it should keep attempting to IVTC in the background in order to tell when the type of material changes.
IVTCing truly interlaced material would lead to everything remaining interlaced, while IVTCing telecined material with interlaced material overlayed (such as subtitles, credits, notices, etc) would lead to most of the image being free of combing.

So, to summarize:
Attempt field matching. If leftover combing present:
- if the majority of the frame is combed, smart bob. (examples: truly interlaced, scrolling credits on top of progressive)
- if the majority of the frame is progressive, deinterlace only the areas detected as combed. (examples: notices, subtitles, telecine disasters)

If no leftover combing or option two (above) was used, run dupe metrics on the first 500 frames (no decimation yet).
- If dupes are detected, decimate to 24 fps using a preset pattern or one that was constructed using the previous 500 frames.
- If not, keep at 60p.
~ The metrics should always keep running so that they can adapt to VFR.

But that might not be very practical at all, and just bobbing everything is a good compromise, I guess.

[Sagekilla]

@Jay Bee: No, there's multiple things going on. In general this happens:

Single rate:
30i --> 30p: Increase in coding efficiency
60i --> 60p: Increase in coding efficiency

But for double rate:
30i --> 60p: Increase in coding efficiency from going interlace --> progressive, loss in efficiency since you have twice the frames to deal with (more bits per second required).

[pcordes]

Why not? It can just delay the entire thing (including the audio) by 5-10 frames.

Not if audio doesn't go through the TV. AFAIK home theatre setups based around a receiver usually send the audio from the receiver to the amp/speakers directly.

Otherwise. what you describe would work. It's just that the TV can't presume that it's not in a latency-sensitive environment. Even if it is seeing the audio, maybe the user is playing a game, where latency is definitely important. Players can make assumptions about latency (or just read ahead on the media).

Maybe some TVs will ivtc, they just couldn't react to changes in the pulldown pattern right away. They'd be looking for patterns in frames they'd already displayed.


I'm definitely curious about Handbrake's ability to encode variable framerate. One concern however: I want to make sure that the videos I encode will be playable on as many devices as possible. ... don't trust VFR...

DVDs that switch between hard and soft telecine are variable frame rate if you decode the soft TC progressively. So most TVs probably expect input vid signals that can switch between 24000/1001 frames per second and 60000/1001 fields per second as output from progressive DVD players. (I hope that's right; I just use a computer so I don't have much hands-on experience with anything beyond NTSC.) So while it is VFR, it's only switching between standard rates.

As for players, yeah, that's an interesting question. Handbrake outputs mkv, which can have a frame rate for the whole video, but it also has timestamps on each frame. With mplayer, if you play Handbrakes VFR IVTC output, it starts up showing e.g. 23.976fps as the frame rate for the video, but it shows each picture when the mkv says it should, so if you single step while watching the timestamps in the status line, you'll see it takes 24 frames to go a second on film sections, and 30 frames to advance a second in the video non-ivtced sections. It basically just works with software players and mkv. If you want to put the video into other containers, e.g. for hardware that supports mp4 or BD5 (mpeg TS?), you'll have to find out how well those formats support it. Probably trying it on your computer and making sure it still works with a software player would be a good start.

[Jay Bee]

@Jay Bee: No, there's multiple things going on. In general this happens:

Single rate:
30i --> 30p: Increase in coding efficiency
60i --> 60p: Increase in coding efficiency

But for double rate:
30i --> 60p: Increase in coding efficiency from going interlace --> progressive, loss in efficiency since you have twice the frames to deal with (more bits per second required).
Yes, that's the way I understand it too. But I don't see how 30i --> 30p can be seen as a viable solution for true interlaced content. You can't just cut the temporal resolution in half and act as if nothing happened.

It has been argued in the past that deinterlacing 30i to 60p and then resizing to get the amount of data back down will in fact look better than an interlaced encode but I'm not entirely convinced.

[Sagekilla]

That wasn't my point, I was saying if you're going from interlaced to progressive it'll be more efficient to encode. I wasn't talking about the single rate case of 30i to 30p, but the better method of 30i --> 60p.

[pcordes]

What's 30i? I thought Np meant N frames per second, while Ni meant N fields per second (a field being either the odd or even lines from a frame). BTW, for compactness I sometimes write 720p24 for example, to describe 720p @ 24fps.

So 30i would mean 30 fields per second, or 15 frames per second when stored in the normal way, with odd and even fields merged into interlaced frames. I didn't think that was a very common format to encounter, since NTSC is 480i60 (or 480p30), and PAL is 576i50 (or 576p25). 30i content would only display properly if deinterlaced, or shown on a CRT scanning at half normal speed. (I don't think CRTs would be willing to scan the odd lines twice, then the even lines twice, or something.) Does HD content sometimes run at 1080i30 or something? I think I've seen 15p video samples, but I assumed they were just reduced-frame-rate, not single-rate deinterlaced.

Maybe we're using different terminology: By my definition (which I thought was the usual one) 60i -> 60p is double rate. You're turning each field into a full frame, doubling the amount of pixel data (and doubling the size of an uncompressed copy). 30i->60p would be quad rate, and I've never heard of anything but odd/even interlace...

So maybe I should ask: if 30i means 30 interlaced _frames_ per second, what do you mean by 60i? 120 fields per second? Does that exist anywhere?

Other thoughts on interlaced content:
Some content isn't _really_ interlaced, but it's field-shifted. Each frame shows combing because it's made of the bottom field from the last from, and the top field from the current frame. This is stuff that mplayer -vf phase can fix.

The nastiest stuff to deal with, as someone pointed out, is material that was originally progressive film, but has been telecined onto video and then had special effects or titles added to the video. So you have native 60i (or sometimes 30p) content in the same frame as telecined 24p content. ivtc ruins the 30p special effects (although depending what they are it might not look too bad), and single-rate deinterlacing (60i->30p) leaves juddering in the originally-progressive stuff. Early Star Trek TNG (e.g. season 1) had this, because they did the SFX in video. I guess 60p deinterlaced would be ok. Where it gets really bad is when this is converted to PAL. e.g. I got my hands on a copy of the ST:TNG season 1 PAL dvds, and it was the worst thing I've ever tried deal with. mplayer -vf phase helped some, after I added some code to remember some history and provide some hysteresis for mode switching... Which reminds me, I should submit a patch... But I saw some people with massive avisynth scripts that was said to be really slow, but effective... I don't use Windows at all, so I just gave up on it. :/

I own TNG season 5 NTSC dvds, and I gave HandBrake's VFR ivtc a try on that. It switches to 30p deinterlaced on the special-effects sections, and tends to look pretty good.

Hmm, I guess this is way off topic and has probably already been discussed in another forum.

[Sagekilla]

30i = 30 interlaced frames per second = 60 fields per second (2 fields to one frame)

So, 30i != 15 frames per second

[Jay Bee]

That wasn't my point, I was saying if you're going from interlaced to progressive it'll be more efficient to encode. I wasn't talking about the single rate case of 30i to 30p, but the better method of 30i --> 60p.

Hmm, what do you mean by efficient?

[LoRd_MuldeR]

Hmm, what do you mean by efficient?

It's more efficient to encode 30 progressive frames per second than to encode 30 interlaced frames (that is: 60 fields) per second.
And "more efficient" means: You'll need less bits to retain the same level of quality. Hence deinterlacing from 30i to 30p should be done before encoding!

However if you got 30i material and you bob it up to 60p, then it will be less efficient to encode, because the number of frames has actually doubled.
So in the case you got a 30i source and you need to keep the full temporal resolution, bobbing before encoding might not be the best solution compression-wise.
In that case (and only in that case) interlaced encoding is preferable...

[Jay Bee]

So if you want to keep the full resolution of the source, both spacial and temporal, then encoding as interlaced is the most efficient. Right?

[LoRd_MuldeR]

So if you want to keep the full resolution of the source, both spacial and temporal, then encoding as interlaced is the most efficient. Right?

I think so. The only other way to keep the full spacial and temporal resolution would be bobbing before encoding (which doubles the number of frames and hence takes more bits for the same quality). And yes, I know that interlaced video is bad and evil. But it exists and we need to deal with it. Deinterlacing/bobbing before encoding is not always the best solution, but most of the time it is...

[pcordes]

30i = 30 interlaced frames per second = 60 fields per second (2 fields to one frame)

So, 30i != 15 frames per second

huh, I googled a bit and both conventions seem to be in use. Although the 30i = 30 interlaced frames convention seems to be more common when talking about HD, and I've only seen people say 60i = 60 fields per second for e.g. NTSC.

I can't say I like that convention; I like the idea that 60i = images from 60 discrete times per second, but interlaced so it's only half rez, just like 60p means 60 pictures per second (but at rez). IMHO, the important thing is that the screen redraws 60 times a second. Storing fields together as frames doesn't change the fact that it's 60 pictures per second. Two interlaced fields do make up a full frame, so these halved numbers are frames per second, but they're from different times, so it leads to confusion when you think about that as 30 frames per second. As we all agree, you need to smart-bob to 60p to not destroy information. (depending on the content, though, 30i->30p can look just fine. That's what I usually do on the rare occasions I want to encode something interlaced.)

So is talking about frame (not field) rates the norm (on doom9, and/or elsewhere)? I don't want to confuse everyone by using nonstandard terminology.

I found one page that looks like it's using field rates for HD:
https://eww.pavc.panasonic.co.jp/pro-av/sales_o/p2comp/HPX2000_Avid_XPProHD_1394AVC.html
That doesn't mean they're right, but it does support my case for talking about field rates. :devil:

[Jay Bee]

Deinterlacing/bobbing before encoding is not always the best solution, but most of the time it is...

So you're saying that most of the time you either don't want to keep the full resolution of you don't want the best efficiency?

Why would that be?

[LoRd_MuldeR]

So you're saying that most of the time you either don't want to keep the full resolution of you don't want the best efficiency?

Why would that be?

Because for many sources deinterlacing from 30i to 30p is acceptable -or- because you can accept the additional bitrate for bobbing 30i to 60p before encoding.

Another advantage of bobbing 30i to 60p before encoding is: You can use an ultra-slow high-quality bobber, which you can't use at playback time...

[Jay Bee]

Because for many sources deinterlacing from 30i to 30p is acceptable -or- because you can accept the additional bitrate for bobbing 30i to 60p before encoding.

I see. The second point is valid but I can't agree with the first. Going from 60 Hz to 30 Hz completely transforms the look and feel of a video IMO. There's even a Wikipedia article about it: http://en.wikipedia.org/wiki/High_motion

[LoRd_MuldeR]

I see. The second point is valid but I can't agree with the first. Going from 60 Hz to 30 Hz completely transforms the look and feel of a video IMO. There's even a Wikipedia article about it: http://en.wikipedia.org/wiki/High_motion

I capture a lot of video from TV. Most of that is PAL, 25fps interlaced. And I deinterlaced most of my captures from 25i to 25p.

Of course it doesn't look as "smooth" as bobbed 50p, but for me it's acceptable most of the time. And it's definitely the best way compression-wise.

If you can't accept going from 30i to 30p for yourself, choose one of the two alternatives we have already discussed...

[foxyshadis]

Not if audio doesn't go through the TV. AFAIK home theatre setups based around a receiver usually send the audio from the receiver to the amp/speakers directly.

Otherwise. what you describe would work. It's just that the TV can't presume that it's not in a latency-sensitive environment. Even if it is seeing the audio, maybe the user is playing a game, where latency is definitely important. Players can make assumptions about latency (or just read ahead on the media).

Maybe some TVs will ivtc, they just couldn't react to changes in the pulldown pattern right away. They'd be looking for patterns in frames they'd already displayed.

They do. High end panasonics, sonys, and a few other brands have very powerful deinterlacing built-in. People just plain aren't sensitive enough to small delays for it to matter. 2-3 fields delay is enough for good field-matching, if a match isn't found it just deinterlaces until it finds good matches again - and the deinterlacing itself looks good enough that it's very difficult to notice even frame-by-frame.

Cheap TVs like mine, on the other hand, just look lousy with their dumb bobbing through a composite connection. :p

[pcordes]

They do. High end panasonics, sonys, and a few other brands have very powerful deinterlacing built-in. People just plain aren't sensitive enough to small delays for it to matter. 2-3 fields delay is enough for good field-matching, if a match isn't found it just deinterlaces until it finds good matches again - and the deinterlacing itself looks good enough that it's very difficult to notice even frame-by-frame.

Yeah, that makes sense. The only thing I doubt they can do is long lookahead to avoid mistakes when the telecine pattern changes. They probably do look-behind instead.

I saw an add for a 120Hz HDTV the other day. I looked up some more info, and apparently some of them have "anti-judder" processing. I think they're talking about the TV interpolating new frames to display. Sounds fishy to me, but it could certainly make motion look smoother.

http://reviews.cnet.com/4520-6449_7-6792632-1.html
http://www.avsforum.com/avs-vb/showthread.php?t=736064
http://futureshopforums.com/futureshop/board/message?board.id=hometheatre&thread.id=50

They don't actually take 120p video signals, though. And I don't think the prospect of displaying a video on one of them would have much effect on what I decided to do for deinterlacing. For sports, I might go with 30i->60p, but for a lot of stuff 30p doesn't really lose anything. It totally depends on the source whether it's worth doubling the rate.

Cheap TVs like mine, on the other hand, just look lousy with their dumb bobbing through a composite connection. :p

One more reason why I just use a computer + monitor. Although it's good in theory, but xf86-video-intel still doesn't do vsync, so I get tearing in vids except when I boot up my old machine with an NVidia card... :/

[LoRd_MuldeR]

One more reason why I just use a computer + monitor.

Yup. I definitely won't buy a TV Screen + DVD Player + DVB Reciever (+ BR Player + Streaming Client), when the PC can do it all in one device and with full control.

(In fact I got an old 60cm CRT TV screen and a standalone DVD Player here, but I didn't use it for ~1 year - the time my 22" LCD PC screen arrived ^^)

[mikeytown2]

huh, I googled a bit and both conventions seem to be in use. Although the 30i = 30 interlaced frames convention seems to be more common when talking about HD, and I've only seen people say 60i = 60 fields per second for e.g. NTSC.

So is talking about frame (not field) rates the norm (on doom9, and/or elsewhere)? I don't want to confuse everyone by using nonstandard terminology.

The standard according to the EBU (European Broadcasting Union): 25i is a frame rate of 25 with a field rate of 50.
http://www.ebu.ch/CMSimages/en/tec_doc_t3299_tcm6-23327.pdf
http://en.wikipedia.org/wiki/1080i

But then this wikipedia article has 60i
http://en.wikipedia.org/wiki/480i
with no references.


IMHO
30i means 30 frames or 60 fields.
30p means 30 frames or 30 fields.
60p means 60 frames or 60 fields.
60i should mean 60 frames or 120 fields.

But then there's this article on wikipedia
http://en.wikipedia.org/wiki/Frame_rate
which got its info from microsoft
http://www.microsoft.com/whdc/archive/TempRate.mspx


In short, I think the EBU, is right and MS is wrong.

[LoRd_MuldeR]

IMHO
30i means 30 frames or 60 fields.
30p means 30 frames or 30 fields.
60p means 60 frames or 60 fields.
60i should mean 60 frames or 120 fields.


The "p" in "30p" indicates "progressive", so there are no fields in 30p. In "30i" there are 30 "interlaced frames" per second, hence 60 fields per second.

[Jay Bee]

Personally I use the number after the i to indicate the sampling rate. For example a sports broadcast is 576i50 while a hollywood movie on a Pal DVD is 576i25.

I don't see how any other naming conventions would carry any useful information.

[LoRd_MuldeR]

I don't see how any other naming conventions would carry any useful information.

As long as we discuss about framerates and interlaced-vs-progressive only, it's perfectly valid to say "30p" or "30i"

(because the resolution doesn't matter or because the resolution is clear from the previous discussion)

[G_M_C]

Well reading about on this board i found a post made bij DS about the interlacing subject ....

My impression:
[... snip ...]

Things Mainconcept has that x264 doesn't:
P-frame weighted prediction (I think?)
PAFF
Adaptive MBAFF (coming soon to an x264 near you)



Mind the red color above ....

[onesloth]

Vista's EVR's deinterlacer looks better to me than my 8800GT's hardware deinterlacer AND all MeGUI's options for pre-encode deinterlacing. EVR is used by Windows Media Player and can be used with Media Player Classic Home Cinema. I use x264's encode interlaced option so I can use the EVR deinterlacer.

So, is it at all possible to flag a video for interlaced playback?
I'm not sure, but it sounds like you might be saying your interlaced encodes are not being deinterlaced by your playback software. If you are using MPC Home Cinema with the ffdshow decoder, you can force ffdshow to flag interlaced to the renderer in the ffdshow config -> output panel.

[STaRGaZeR]

Vista's EVR's deinterlacer

:confused:

[Atak_Snajpera]

Vista's EVR's deinterlacer
:confused::confused:

[Esurnir]

If I'm correct at least with coreavc connected to evr, the graphic card do the deinterlacing (correct me if I'm wrong)

[LoRd_MuldeR]

If I'm correct at least with coreavc connected to evr, the graphic card do the deinterlacing (correct me if I'm wrong)

CoreAVC has four deinterlace options available:
* None/Weave
* Single Field
* Bob
* Hardware

Only the the very last option will use "hardware" deinterlacing. With the second and third options CoreAVC will deinterlace itself (in software).
And even if "Hardware" is selected this means only one thing: The output video stream will be flagged as "interlaced".
In that case it totally depends on the subsequent filter (usually a Renderer), the graphics hardware and the drivers whether deinterlacing will be applied or not.
Also the deinterlacing method used in "Hardware" mode is specified by the graphics drivers...

[onesloth]

:confused:
:confused::confused:
http://en.wikipedia.org/wiki/Media_Foundation#Enhanced_Video_Renderer

If you are using MPC Home Cinema and ffdshow, you will get your graphics card's hardware deinterlacing if you have 'VMR9 (windowed)' (probably also 'System Default') selected under view -> options -> playback -> output. You will get EVR's deinterlacing if you select 'EVR' from the same list.

[Atak_Snajpera]

If you are using MPC Home Cinema and ffdshow, you will get your graphics card's hardware deinterlacing if you have 'VMR9 (windowed)' (probably also 'System Default') selected under view -> options -> playback -> output. You will get EVR's deinterlacing if you select 'EVR' from the same list.
This works only if you force NV12 mode in ffdshow + Enabled >Set interlace flag< . It's called HARDWARE deinterlacing not EVR's deinterlacing.

[onesloth]

It's called HARDWARE deinterlacing not EVR's deinterlacing.
You're right. The EVR mixer uses DXVA video processing for deinterlacing. My point is that, to me, the EVR playback deinterlacing looks much better than the common encode-time deinterlacing options and what I get with VMR9.