Could someone tell me what this is? Is it partially interlaced etc?

[hello_hello]

It's 25fps, but seems to have a pattern of 12 interlaced frames followed by 13 progressive frames. However that's just how it looks to me which doesn't necessarily mean anything......

Could someone please tell me exactly what it is and how to best go about de-interlacing it?
The video appears to play normally using MPC-HC, but when I try stepping through it frame by frame, it looks as though every frame is repeated.

So far I've not been able to successfully use ffmsindex or dgavcindex without the result being "jerky" video at best, regardless of any methods of de-interlacing/IVTC I've tried. They don't seem to decode it properly either. It's kind of like the frames are being decoded in the wrong order. With directshow/ffdshow doing the decoding it at least seems to make more sense, and enabling ffdshow's de-interlacing filter gives me what appears to be normal 25fps progressive video.

Thanks.

[hello_hello]

Well I ran the whole thing through ffdshow and converted it to a lossless format for re-encoding, and it appears after de-interlacing the output was 25fps with every 24th frame repeated. Removing it to end up with 24fps shouldn't be too hard, but I still feel like I've used the wrong method to obtain the correct result.....

[hello_hello]

Plan "B" now, Hopefully it's a better way to do it.
Under the assumption the video has been converted from 24fps to 25fps by repeating 2 fields in every 50 using some sort of pulldown pattern and it's not actually interlaced, I'm doing this:

SeparateFields()
SelectEvery(2, 0)

There must be a way to remove the remaining duplicate fields in the process but for the moment I'm following it with this, then finally resizing back to 16:9 dimensions.

TDecimate(cycle=50, cycleR=2)

Hopefully that'll work, but if anyone know how to do it better....

[hello_hello]

Finally got it sussed. I think my method in the previous post worked fine, but probably wasn't the safest way to do it.

I converted the file to a lossless format with directshow/ffdshow again (no de-interlacing this time). That way I could use AVISynth filters which might request frames ahead, or out of order, without the whole thing turning into a mess.

From there I'm encoding the lossless file using the following in the script:

tfm(order=-1).tdecimate(cycleR=1, cycle=25)

That seems to be giving me nice and smooth 24fps progressive output.

I guess next time I come across something like that I'll know what to do. Thanks to everyone who offered help!

[sanlyn]

Well, that was quick. I think TFM/Tdecimate is likely the best way to remove pulldown.

[jagabo]

Yes, it's 24p film converted to 25i with 2:2:2:2:2:2:2:2:2:2:2:3 pulldown. tfm(order=-1).tdecimate(cycleR=1, cycle=25) is the right way to handle it.

[hello_hello]

Thanks guys. I hadn't come across something like that before and the decoding problems didn't help. Plus living in PAL land I'm not that practised with pulldown.

I should give you some of the credit for helping me work it out anyway jagabo. It was after a bit of Googling, reading the tdecimate help files and then reading an old post of yours in this forum that the penny finally dropped.

Actually one thing I still don't quite understand.... why when I open the file with MPC-HC and step through the video one frame at a time does every frame seem to be repeated?

[jagabo]

Actually one thing I still don't quite understand.... why when I open the file with MPC-HC and step through the video one frame at a time does every frame seem to be repeated?

I think it stems from the fact that originally the frame rate of interlaced videos was stated as 25i or 30i. Then some genius in marketing decided that calling it 50i or 60i sounded better. Of course, once one company started doing it all the other had to do the same, lest their products look inferior. Then some software engineers started doing the same. So you get programs that are confused about what the frame rate really means -- whether it's frame per second of fields per second.

[hello_hello]

Maybe that explains some of the ffmsindex "oddness". Indexing the video with it was fairly messy and stepping through the frames it looked like they were sometimes going back and forth rather than progressing in the correct order.

Oh well.... once again DirectShow/ffdshow saved the day..... even if I did have to convert it to a 220GB lossless file first. Opening a file that size with ffmsindex...... no problem once it was indexed, but the indexing certainly took a while.