Best way to open an mkv with avisynth for deinterlcing

[ROBO731]

Right now I'm using ffmpegsource to open mkv files which I am deinterlacing, but in the userguide it states that the following is a known issue:

Interlaced H.264 is decoded in an odd way; each field gets its own full-height frame and the fieldrate is reported as the framerate, and furthermore one of the fields (odd or even) may "jump around". To get the correct behavior, you can try setting fpsnum and fpsden so that the framerate is halved (may or may not work). This issue is caused by libavcodec.

Is there a better way for me to import the video?

[jagabo]

The problems with interlaced h.264 varies with ffMpegSource(). I usually use ffMpegSource() but sometimes have to revert to DirectShowSource(). The latter has its problems too (not always frame accurate when seeking) and will depend on what DirectShow filters you have installed. In a worst case scenario I'll use DirectShowSource() and convert linearly to a lossless codec for non-linear access later.

[ROBO731]

I see, thanks for the input.

[poisondeathray]

Arguably the "best" way if you have an compatible Nvidia card is to use dgnvtools to index it. But it's not free (donationware)
http://neuron2.net/dgdecnv/dgdecnv.html



What was the original format before MKV? (Was it an interlaced h.264 transport stream?)

For some people, L-SmashSource is an improvement on FFVideosource in this situation

LWLibavVideoSource("video.mkv", repeat=true)



In addition to jagabo's technique, other people use ffmbc to encode to a lossless intermediate like ffv1 (ffmbc decodes interlaced AVC transport streams without problems)

[ROBO731]

Thanks I'll look into those options when I get the time. The file I'm working with was originally from a DVD and has been encoded once already, progressively, to h264.

[poisondeathray]

Thanks I'll look into those options when I get the time. The file I'm working with was originally from a DVD and has been encoded once already, progressively, to h264.

huh ?

If it's been encoded progressively then why are you deinterlacing ?

Or are you saying it wasn't processed properly ? (wasn't IVTCed or deinterlaced) ?

If it's been encoded progressive, FFMS2 won't have those issues mentioned in the guide

[poisondeathray]

or better yet , just start over with the DVD - no problems!

[ROBO731]

Sorry, to clarify, it has been encoded as if it were progressive. It has not yet been deinterlaced. Unfortunately I don't have access to the originals, but if this is the case then FFMS2 won't have any of these issues?

[poisondeathray]

Yes, FFMS2 won't have any of those issues. Those issues only occur with "interlaced" AVC (PAFF streams) . If it's a movie or theatrical release, deinterlacing is usually the wrong thing to do . If it's been resized as well, you're going to have big problems

[ROBO731]

Fortunately it hasn't been re-sized and it's animation, will that cause any issues?

[poisondeathray]

"Hasn't been resized" is a good thing -

But animation is very rarely interlaced ; it usually has pulldown for NTSC DVD release . If you post a sample someone will have a look at it and suggest some options . Again , deinterlacing is usually wrong thing to do

[jagabo]

Fortunately it hasn't been re-sized and it's animation, will that cause any issues?

If it is telecined film that was encoded progressive you can restore the luma channel but the progressive encoding of the interlaced chroma channels will have blurred the two chroma fields together (assuming YV12 video). When there's lots of motion you will get colors that don't line up with the luma.

[ROBO731]

I see, here's a sample.

[jagabo]

That's in sad shape. It looks like someone tried to inverse telecine to 23.976 fps but it didn't work properly, leaving some combed frames. Then they duplicated frames to restore the 29.97 fps frame rate. Sometimes the combed frames are duplicated. Since it is encoded progressive the interlaced chroma channels have blended together. Here's one field from a sequence of frames. The top and bottom images are from fields where the original frame was progressive, the middle field is from an interlaced frame encoded progressive:



You can see that the middle field has a blend of the colors of the two other fields.

They also packaged a ~640x480 square pixel 4:3 frame into a 720x480 square pixel frame. Bizarre.

I'd look for a better source.