How to properly deinterlace? :(

[Fadeout]

I'm trying to use either StaxRip or MediaCoder since I need NVENC.

The problem is trying to re-encode a 1080i 50fps to 1080p 25fps so that my TV player can read it (30fps limit).

The first attempt I made was very good. I was simply using StaxRip with FFVideoSource and SelectEven(). But of course the result is a 1080p 25fps video that is flagged as progressive but that actually shows an interlaced image. The problem is that playing this file in MadVR and forcing deinterlacing produces a so good result that I was NEVER able to match when deinterlacing BEFORE encoding the video (even at 50fps).

So, no setting I tried was able to match that. Yadif produces ugly results. No other deinterlacer produces something different from what I see in yadif, and especially the movement isn't smooth.

How the hell is even possible that my 1080p 25fps (that needs to force deinterlacing to be properly seen) retains the smooth movement of the source, but properly deinterlaced videos, even at 50fps, lose that smoothness?

I think I need some kind of magic to know how to actually do this conversion properly... Can anyone help?

[LoRd_MuldeR]

The first attempt I made was very good. I was simply using StaxRip with FFVideoSource and SelectEven(). But of course the result is a 1080p 25fps video that is flagged as progressive but that actually shows an interlaced image.

Sure. Your original "interlaced" (or "field-based") input contains 50 fields per second, stored as 25 "interlaced" frames per second.

Each "interlaced" frame contains two fields. One consisting of the odd lines, and one consisting of the even lines.

Consequently, selecting every second frame (and skipping the others), which is what SelectEven() does, still gives you "interlaced" frames!

Actually you'll keep two fields, then skip the next two fields, then keep the next two fields, then skip the next two fields, and so on.

SelectEven() does not select the even lines of the frame, but it selects the frames with even index (frame #0, frame #2, frame #4, and so on).

If you want to separate the even and odd lines of a frame, you have to use SeparateFields(). But that gives you half height frames...


So, no setting I tried was able to match that. Yadif produces ugly results. No other deinterlacer produces something different from what I see in yadif, and especially the movement isn't smooth.

How the hell is even possible that my 1080p 25fps (that needs to force deinterlacing to be properly seen) retains the smooth movement of the source, but properly deinterlaced videos, even at 50fps, lose that smoothness?

I think I need some kind of magic to know how to actually do this conversion properly... Can anyone help?

I think Yadif is quite good, considering that it runs very fast. But QTGMC will give you much better results, at significantly slower processing speed!

If you use QTGMC, be sure to not apply SelectEven() or SelectOdd() before QTGMC.

You may apply one of those afterwards, on the resulting progressive frames, in order to reduce the resulting 50 fps video to 25 fps.

[Fadeout]

SelectEven() does not select the even lines of the frame, but it selects the frames with even index (frame #0, frame #2, frame #4, and so on).

If you want to separate the even and odd lines of a frame, you have to use SeparateFields(). But that gives you half height frames...

I want simply to reproduce what MadVR is doing. The best thing could be if I could make DirectSource also use DXVA deinterlacing. And then encode my file from there.

The big problem here is that the file encoded with SelectEven(), so down to 25fps "interlaced" (so I guess 12.5), still looks way better than deinterlacing with Yadif while encoding a 1080p progressive at 50fps. I don't know why.

If I play the same video in VLC, with Yadif on. Then open the same video on MadVR with its own deinterlacing, the result is MUCH better in this second case, and the motion is smooth. The source file in VLC + Yadif is not smooth.

VLC + Yadif is not smooth as MadVR or even WMP. And what I see in VLC is EXACTLY what I get with my encoded videos.

This is not a problem of the quality of the interlacing, it's just that MadVR and WMP are doing something different.

[Fadeout]

Wait a second, maybe I got something.

In LAV Video options, if I enable Yadif at 25/30 fps I get the same result of VLC = not smooth.

If instead I set Yadif 50/60 video then I get the smooth result I see in WMP too.

So, is there a way to do that stuff in Avisynth before encoding the file?

[TheSkiller]

The source file in VLC + Yadif is not smooth.Yes, you have to select "'Yadif (2x)" in VLC for the motion to be smooth.

[LoRd_MuldeR]

Yadif() can do "single rate" deinterlacing, i.e. convert 25 "interlaced" frames per second (50 fields per second) into 25 progressive frames per second.

And it can do "double rate" deinterlacing, i.e. convert 25 "interlaced" frames per second (50 fields per second) into 50 progressive frames per second.

Performing the "double rate" deinterlacing and applying SelectEven() afterwards is going to give pretty much the same result as "single rate" deinterlacing.

QTGMC always does "double rate" deinterlacing, but you can apply SelectEven() or SelectOdd() on its output, if you like 25 fps result...

[johnmeyer]

Why deinterlace? Your TV is designed to play interlaced footage, and will do a great job. If you are going to re-size, then you definitely must deinterlace, but that isn't the case here. Some filters (although not all) can be made to work just fine by following the advice given in this ancient doom9.org guide:

7.2.11 Processing interlaced video (http://www.doom9.org/index.html?/capture/postprocessing_avisynth.html)

Scroll 90% of the way down the page until you get to section 7.2.11.

The results are of following this guide will still be interlaced video, but without any problems from the filter trying to work on both fields at once, which being from different moments in time sometimes (but not always) causes problems.


It would be interesting to add up all the posts in this forum about video that got screwed up by people deinterlacing incorrectly, often when they didn't need to do it. The result of such an exercise would be a two-digit integer percentage, for sure.

[Fadeout]

Yes, you have to select "'Yadif (2x)" in VLC for the motion to be smooth.

I tried that, I get all the image trembling. Not sure if maybe it's not the CPU (old E8400 3Ghz) but MadVR and WMP are super smooth.

I simply want to use a similar input to encode the damn video.

[Fadeout]

Why deinterlace? Your TV is designed to play interlaced footage, and will do a great job.

I use WD Live TV player. It can only go up to 1080p 30fps. So it won't play the damned 1080i 50fps.

The whole problem is I'm capturing with Avermedia Game Capture HD II, only that it can't play ITS OWN files, because it shows very ugly interlacing on some colors, like red. YET I cannot load the file in a different player, because the player doesn't support higher fps.

So I'm stuck trying to reconvert the file in a format my TV player can digest, and that means 25fps. But the file I produced with SelectEven() won't play properly because the output video is marked as "progressive". It plays fine with a PC player where you MANUALLY force deinterlacing, but I can't do that with the TV player.

NOR I was able to find a program that makes me override the metadata so that the file would be treated as interlaced.

It's a cluster of complications.

I even stalled for a long time because I was using StaxRip 64x and it didn't come with Yadif, then I tried to load the plugin manually but wouldn't, and finally figured out I needed a x64 version. That I finally found, but that didn't produce even remotely a comparable result to the standard DXVA deinterlacing I see in WMP.

[johnmeyer]

I tried that, I get all the image trembling. Not sure if maybe it's not the CPU (old E8400 3Ghz) but MadVR and WMP are super smooth.

I simply want to use a similar input to encode the damn video.Your posts confuse me. You say that your original is "1080i 50 fps." Well, to me that sounds like standard PAL which is 25 fps, but is often called "50i" because it is 50 interlaced fields per second. If so, then you need to follow closely the posts already made in response to your initial query.

However, if you really do have video that is 50 interlaced frames per second, that is quite a rarity. I'm not sure I've ever come across such a thing. If that's what you really have (which I am betting you do not), then all you need to do is do a SelectEven() or SelectOdd() and you are done: just throw away half of the frames.

However, if that's not the case, then I think you need to re-read LoRd_MuldeR's two excellent posts.

[Fadeout]

Your posts confuse me. You say that your original is "1080i 50 fps." Well, to me that sounds like standard PAL which is 25 fps, but is often called "50i" because it is 50 interlaced fields per second. If so, then you need to follow closely the posts already made in response to your initial query.


This is the source:

Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 53s 0ms
Bit rate : 11.9 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 50.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.115

By the way, I'm not sure how "rare" it can be since it's what's broadcasted all over Europe: https://en.wikipedia.org/wiki/Sky%2B_HD

[Fadeout]

However, if you really do have video that is 50 interlaced frames per second, that is quite a rarity. I'm not sure I've ever come across such a thing. If that's what you really have (which I am betting you do not), then all you need to do is do a SelectEven() or SelectOdd() and you are done: just throw away half of the frames.

In fact I get a PERFECT result.

Problem is the output is flagged as "progressive", so the TV player doesn't know it has to activate the interlacing.

There is NO PROGRAM on the internet that makes me override the "Scan type" field and turn it back to "Interlaced". Or I would have fixed this SERVERAL hours ago.

[Fadeout]

So, logic.

Source is 1080i 50fps. But being interlaced it's only 25 actual frames built by two fields.

That means that if I put together two fields and encode the resulting 1 frame, I get 25fps progressive of what should look equal to 50fps interlaced. But NOPE, this is not the case. 25fps progressive are way less smooth moving than the source.

I even tried then to go from 1080i to 1080p 50fps. But nope, no sensible change to the 25fps encode.

Then, for some magical reason, my encoded-as-is 1080i with SelectEven() but no deinterlacing applied becomes 1080p at 25 fps. But if you force interlacing in the player, then you STILL retain the smoothness of the original.

Why cannot I obtain similar results when deinterlacing is done before the encoding, and so use an output that is really progressive I can use?

[johnmeyer]

Scan type : Interlaced
Scan order : Top Field First

...

Problem is the output is flagged as "progressive", so the TV player doesn't know it has to activate the interlacing.

There is NO PROGRAM on the internet that makes me override the "Scan type" field and turn it back to "Interlaced". Or I would have fixed this SERVERAL hours ago.In your previous post you copy/pasted from some program that DID correctly identify the video as interlaced (that is what I copied at the beginning of the above quote). So, if that program correctly identifies your video as standard PAL interlaced video, then if some other program (your "player") fails to read those flags, then that is the fault of the player.

This leads me back to the same recommendation: get a better player.

[johnmeyer]

Once again, we are posting at the same time.

That means that if I put together two fields and encode the resulting 1 frame, I get 25fps progressive of what should look equal to 50fps interlaced. But NOPE, this is not the case. 25fps progressive are way less smooth moving than the source.

No, no, no. The even fields represent a different moment in time than the odd fields. Therefore, you cannot combine them together and play them both at the same moment in time. The resulting video will look really bad.

LoRd_MuldeR answered all these questions about interlacing in his two excellent "tutorial" posts earlier in this thread. They are worth reading a second time.

[johnmeyer]

You posted as I was posting.

The key phrase I was missing is "TV player." So you are not watching this on a standard TV, but instead are watching on your computer or other device, and are using a software "player" that doesn't understand how to play 50i material.

This means your software player is crummy.

So, my solution for your problem would be to get a better video player. VLC used to be a great player, but around release 2 they totally broke it. You might try an older release if that is what you are using.

Other people can probably suggest better alternatives for players which do a good job of handling interlaced video.

The advantage of solving your problem this way is that you won't constantly have to fiddle with every video you want to watch.

[vivan]

In your previous post you copy/pasted from some program that DID correctly identify the video as interlaced (that is what I copied at the beginning of the above quote). So, if that program correctly identifies your video as standard PAL interlaced video, then if some other program (your "player") fails to read those flags, then that is the fault of the player.He tries to encode it using hw encoder because his cpu is slow, but that encoder doesn't allow (or he can't find such switch) to select interlaced encoding mode. Sure with proper encoder aka x264 it's easy, --tff.

[Fadeout]

No, no, no. The even fields represent a different moment in time than the odd fields. Therefore, you cannot combine them together and play them both at the same moment in time. The resulting video will look really bad.

Yet, you should be able to encode the 50i/25fps into 50fps progressive. That shouldn't be "lossy".

[vivan]

Yet, you should be able to encode the 50i/25fps into 50fps progressive. That shouldn't be "lossy".Yes you should and it should be really easy.
Post video sample please.

[Fadeout]

He tries to encode it using hw encoder because his cpu is slow, but that encoder doesn't allow (or he can't find such switch) to select interlaced encoding mode. Sure with proper encoder aka x264 it's easy, --tff.

It doesn't work either, since you still need to deinterlace before encoding, so you once again pass through Yadif. And doing so removes the smoothness.

There isn't any way to input an interlaced format, encode it as it is, and then tell the output file to set itself as interlaced.

You can only take the interlaced input, deinterlace, re-encode it interlaced. Which is TERRIBLE.

But what's even more absurd is that my fakely progressive 25fps file not only moves smoother, but somehow has a much better video quality despite the file size is much lower.

It doesn't make any sense.

[Fadeout]

Yes you should and it should be really easy.
Post video sample please.

If I set Yadif in x2 mode, with the 50fps interlaced input I get a 100 fps progressive output from the encoder.

That I cannot even verify it works because my PC can't handle 1080p at 100fps.

If I take that file and process it through SelectEven() (so it goes back down to 50fps progressive), the result is a loss of smoothness that is exactly the same as when I apply the normal Yadif.

[vivan]

If I set Yadif in x2 mode, with the 50fps interlaced input I get a 100 fps progressive output from the encoder.

That I cannot even verify it works because my PC can't handle 1080p at 100fps.

If I take that file and process it through SelectEven() (so it goes back down to 50fps progressive), the result is a loss of smoothness that is exactly the same as when I apply the normal Yadif.Well, if every field is unique (means every frame in resulting 100 fps progressive video has movement), then it's real 100 fps.

That's a lot and that's why it's weird (50i that has actually 50 interlaced frames per second) and very uncommon.

[johnmeyer]

Yet, you should be able to encode the 50i/25fps into 50fps progressive. That shouldn't be "lossy".I don't think that is correct. The standard interlaced PAL video you have has 50 fields each second, but each field has only half the spatial information (i.e., only half the vertical lines). You cannot "simply" create progressive video from this footage. That just isn't how it works.

I have linked to the original doom9 post on this subject, from a decade ago, and also referred you to the earlier posts in this thread.

I can do no more.

[Fadeout]

Well, if every field is unique (means every frame in resulting 100 fps progressive video has movement), then it's real 100 fps.

That's a lot and that's why it's weird (50i that has actually 50 interlaced frames per second) and very uncommon.

Considering that a straight encoding without deinterlacing along with SelectEven() (for 25fps) and then forced deinterlacing during playback retains the smoothness, then it's obvious something is wrong somewhere else.

1080p 25fps then forcing deinterlacing via player = still smooth.

1080p 50fps with deinterlacing done by Yadif before encoding = not smooth.

[Fadeout]

I don't think that is correct. The standard interlaced PAL video you have has 50 fields each second, but each field has only half the spatial information (i.e., only half the vertical lines). You cannot "simply" create progressive video from this footage. That just isn't how it works.

I don't think my *monitor* is interlaced. So how the hell both MadVR and WMP can display these videos?

They must do the deinterlacing differently, because I don't think the PC player is playing the interlaced video on a interlaced display.

The problem here is that DXVA shows a smooth video. I cannot preserve any of that during encoding.

Am I wrong thinking a PC player is displaying an already deinterlaced frame?

[johnmeyer]

Well, if every field is unique (means every frame in resulting 100 fps progressive video has movement), then it's real 100 fps.

That's a lot and that's why it's weird (50i that has actually 50 interlaced frames per second) and very uncommon.I thought the same thing from his earlier posts, but he later clarified that this is actually nothing more than standard PAL interlaced video. Here is what he said:

By the way, I'm not sure how "rare" it can be since it's what's broadcasted all over Europe: https://en.wikipedia.org/wiki/Sky%2B_HD

He is just having the same problem many of us had when first tried to understand that interlacing involves two separate problems: each field represents a different place in space AND a different moment in time. Any attempt to combine them together or to do filter operations on both at the same time creates huge problems because the two fields cannot be treated as one unit.

[johnmeyer]

I don't think my *monitor* is interlaced. So how the hell both MadVR and WMP can display these videos?

They must do the deinterlacing differently, because I don't think the PC player is playing the interlaced video on a interlaced display.

The problem here is that DXVA shows a smooth video. I cannot preserve any of that during encoding.

Am I wrong thinking a PC player is displaying an already deinterlaced frame?As I've tried to say in earlier posts, both your TV set AND good software media players handle deinterlacing automatically, and generally do a very good job.

[johnmeyer]

We're going in circles: post some video so we can see what is going on.

[vivan]

I thought the same thing from his earlier posts, but he later clarified that this is actually nothing more than standard PAL interlaced video. Here is what he said:

He is just having the same problem many of us had when first tried to understand that interlacing involves two separate problems: each field represents a different place in space AND a different moment in time. Any attempt to combine them together or to do filter operations on both at the same time creates huge problems because the two fields cannot be treated as one unit.But he is saying that after proper deinterlacing he has 100 fps video.

I dunno, maybe his decoder (or encoder that produces those videos) is broken and outputs dublicated frames?

So, I repeat it, Fadeout - post sample video.

[Fadeout]

I'll try later to upload some samples somewhere. In any case I'm just using StaxRip and NVENC.

I did NOT say that I get a 100fps video after proper deinterlacing. I said that if I enable Yadif in double mode I get a 100fps video.

Even MediaCoder overrides FPS through a command: fps=50,convertfps=true

But then it doesn't have a Yadif 2x option.

I think I'm using the software everyone else is using too (with the difference I need NVENC, so I can't use, for example, Megui).

[Fadeout]

Hoping I'm not doing anything illegal.

This is the source I tried to convert, see if you can do better than me:
https://mega.nz/#!mxYH0IrZ!y19B3sJTz7gwCK1rQpTfTxzI-otiOhZ_JWVQLZEghxQ

Later I'll try to post also my ugly conversions.

[creaothceann]

This doesn't work?

DSS2("00.mp4")
DuplicateFrame(0)
SelectEven
QTGMC(FPSDivisor=2)

[Fadeout]

StaxRip says QTGMC is not a valid application, probably because it's 32bit only.

[Sparktank]

This is the source I tried to convert, see if you can do better than me:
https://mega.nz/#!mxYH0IrZ!y19B3sJTz7gwCK1rQpTfTxzI-otiOhZ_JWVQLZEghxQ

Since you're using NVenc, do you have DGdecNV ?

Using its deinterlace creates 25fps with no interlacing artefacts.
Sinlge-rate and double-rate (bobbing).
deinterlace: 0/1/2 (default: 0)

Nvidia PureVideo Deinterlacer
0: no deinterlacing
1: single rate deinterlacing
2: double rate deinterlacing (bobbing)

Note that double rate deinterlacing requires Windows XP SP3!

Also note that setting deinterlace to 1 or 2 forces the field operation to be "Ignore Pulldown", regardless of the project setting.

The file has no header file.
I had to remux with FFMPEG to Matroska container and demux with eac3to (which added FPS to header), but still the elementary stream of .h264 didn't contain enough to use the free, old version of DGdec.

It works in DGdecNV.
DGSource("E:\test\a150822-1510 - 1 - h264, 1080i.dgi", debug=true, deinterlace=1)

Linked images, click and follow to expand to original sizes.
Zero rate: Frame #535
http://i.imgur.com/upCtaAtl.png (http://imgur.com/upCtaAt)

Single rate: Frame #535
http://i.imgur.com/nKUieWPl.png (http://imgur.com/nKUieWP)

Double rate: (now) Frame #1071
http://i.imgur.com/0GSXGPel.png (http://imgur.com/0GSXGPe)

Using just the MP4, DGdecNV calls the frame structure progressive.
Doing the long chain, it calls the frame structure Fields (TFF).
Either way, when you invoke "deinterlace=1" in DGSource(), it will play back in 25fps.

[johnmeyer]

The video you provided is progressive. Yes, I know that it shows as interlaced TFF, but if you use separatefields() and look at it field-by-field, there is no temporal difference between fields.

Put another way: since the video is progressive, why do you need to do anything to it? Trying to deinterlace progressive video is a pointless exercise.

[vivan]

Video is weird, it's progressive, but with bottom field shifted by 1 frame.
SeparateFields()
Interleave (SelectOdd().Trim(1,0), SelectEven()).Weave()Fixes the part with flying triangles.
TFM() fixes it all.
Of course it looks better than deinterlacing (http://114.imagebam.com/download/V5hsyvlGBESWUDEnyUzxPw/43089/430886512/1.png).

Put another way: since the video is progressive, why do you need to do anything to it? Trying to deinterlace progressive video is a pointless exercise.Because it has interlacing artifacts? It should be not deinterlaced, but still have to be fixed.

[Fadeout]

Put another way: since the video is progressive, why do you need to do anything to it? Trying to deinterlace progressive video is a pointless exercise.

Well, this is what I see without deinterlacing:

http://i.imgur.com/1tVbJm9.jpg

So I don't know what makes you say it's progressive. Maybe you mean the image is interlaced in two fields, but there's no actual movement shift between them.

But if you are right, then why the smooth motion is lost? Maybe because this specific clip is from "film" footage, and so it's 25 fps multiplied to 50, whereas the other video I tested with the smooth movement was proper "video"? That's my guess.

[Groucho2004]

Well, this is what I see without deinterlacing:
If you want to exclude any potential processing by media players you should use VirtualDub to analyse your video.

[Fadeout]

Which program does this screen shot come from?

Both VLC and MPC-HC with deinterlacing off.

Does anyone know what MadVR does when forcing to deinterlace a video that is encoded as 1080p 25fps progressive? Because that retains the smooth movement even if fps were supposedly cut down.

If to go at 25fps it needs to grab two fields then it means it's effectively 12.5 fps, and that should be a fairly noticeable loss...

Or maybe it builds a frame by taking A and B field, then the next frame by using B and C, then C and D. That would somewhat preserve the same behavior of the source 1080i 50fps and justify why I see similar results.

[Groucho2004]

Both VLC and MPC-HC with deinterlacing off.

Does anyone know what MadVR does when forcing to deinterlace a video that is encoded as 1080p 25fps progressive? Because that retains the smooth movement even if fps were supposedly cut down.

If to go at 25fps it needs to grab two fields then it means it's effectively 12.5 fps, and that should be a fairly well noticeable loss...
I changed my reply, make a script to load the mp4 and try with VirtualDub.

[kuchikirukia]

assumeTFF()
#deinterlace

Don't deinterlace to 100fps. It ain't.

[Fadeout]

Since you're using NVenc, do you have DGdecNV ?

I wouldn't know how to set up StaxRip to load it to try.

[Fadeout]

assumeTFF()

This:
DSS2("%source_file%")
assumeTFF()

Produces a 50fps progressive video with interlaced artifacts (since no deinterlacing happened). I don't think that command does anything.

[kuchikirukia]

^^ I added the "deinterlace" bit right after since I figured you wouldn't get it.
The deinterlacer is assuming BFF when it's TFF. Put AssumeTFF before the deinterlacing.

[vivan]

Does anyone know what MadVR does when forcing to deinterlace a video that is encoded as 1080p 25fps progressive? Because that retains the smooth movement even if fps were supposedly cut down.It deinterlaces it.

If to go at 25fps it needs to grab two fields then it means it's effectively 12.5 fps, and that should be a fairly noticeable loss...How did even you came to this conslusion? Deinterlacing 25 fps video can result in either 25 ("film") or 50 ("video") fps.
Even though MI says that your sample is 50 fps - it's 25, and this is number of frames madVR gets.

Your sample has 25 fps, but tagged as 50. Some decoders try to output 50 frames per second (by dublicating every frame), some - 25.
And, as I said, it has field shifted.
One frame holds top field for this frame and bottom for next one, next one holds top field for this frame and bottom for next one and so on. Like third resulting frame there (https://en.wikipedia.org/wiki/Telecine#2:3_pulldown), but every frame is like this.

Anyway, this is what I'm getting after TFM https://dl.dropboxusercontent.com/u/16254258/d9/temp/1.mp4?dl=1

If you have another sample that has video content with 50 unique frames - post it...

[Sparktank]

I wouldn't know how to set up StaxRip to load it to try.

It also requires a $15 fee for the license.

Here's the DGI index for the remuxed/demuxed elementary stream:
http://pastebin.com/kbQTr5CP

APPENDIX A: DGI File Structure [AVC]
n:FRM w x y z: A frame of type w (refer to slice types in the AVC specification) with POC x and pic_structure y and matrix coefficients z is present in the source file. FRM entries appear in display order. If pic_structure is -1, then there are no SEI's specifying the picture structure. The number n preceding FRM is the frame number (without honoring pulldown, if any).

all in the posted log are:
pic_structure= -1

SIZ 1920 x 1088
FPS 25000 / 1000
CODED 933
PLAYBACK 933
0.00% FILM
ORDER 0

ORDER n: Specifies the field order of the project: 0 = progressive, 1 = TFF, 2 = BFF.

If anyone can read DGDNV more fluently (tbh, I mostly check the DGI on MPEG2 as most 1080i blurays I have are MPEG2).

[Fadeout]

Since you're using NVenc, do you have DGdecNV ?

OMG PROGRESS!!

I loaded the file into DGIndexNV to create the .dgi.

Then loaded the .dgi with DGSource into StaxRip:
Load_Stdcall_Plugin("D:\Program Files\staxrip\Apps\DGDecodeNV.dll")
DGSource("150820-1023.dgi", deinterlace=2)

The result is a 50fps progressive that ACTUALLY retains the smooth movement of the interlaced video. I never managed this before.

Problem is there seem no way to actually do something like that at 25fps, with SelectEven() I get visually the same result of Yadif.

On the plus side it's WAY faster (encodes at 100fps when before it was around 30). So at least I got something out of all this.

Is there some way to auto create and auto load the .dgi files in the StaxRip scripting editor? Or I have to do this manually every time?

[kuchikirukia]

Your sample has 25 fps, but tagged as 50. Some decoders try to output 50 frames per second (by dublicating every frame), some - 25.

^^ there's that, too.
Your "selecteven" was probably just repairing the frame doubling your source filter was doing. Set it to output 25fps.

[videoh]

You don't need deinterlace=2.

I agree with vivan that it is just field-shifted progressive mistagged as 50fps at container level.

Chop off the first field and encode it at 25fps progressive.

dgsource(...,deinterlace=0)
assumetff()
trim(1,0)
weave()

or use TFM() as vivan suggested, but the first way is faster if there are no further shifts in the stream.

[johnmeyer]

OK, I have it figured out. I wasn't at my main editing computer earlier today, so I couldn't do a complete analysis.

1. Your video is progressive in the sense that there is no temporal difference between fields.

However ...

2. Fields from adjacent frames in the original video are combined together into new frames. Unfortunately, the fields in each frame are not matched: each frame has an odd field from one moment in time, and an even field from the next moment in time. As a result, you see what you think are interlaced herringbones when you play the video. You will see these even when you freeze-frame the video.

I came up with a quick and dirty solution that works perfectly for this video. Now that the problem is understood, perhaps others can come up with more elegant solutions. All I did was separate each frame of the video into fields. I then dropped the first field and then re-combined the video. This put the even and odd fields from the same moment in time back together into the same frame.

Here is the code I used:

assumeTFF()
separatefields()
a=selecteven().trim(1,0)
#a=selecteven() #Use this line instead of the one above to get the original video
b=selectodd()
interleave(a,b)
weave()

Once again, this entire thread shows why people should resist deinterlacing video. The OP didn't cause the problem, but whoever touched this video before he got it did some sort of deinterlacing, and got it wrong.