Lansing raises an interesting point, which is...

[huhn]

Your player does IVTC if #2 looks the same as #1. If it would jus deinterlace #2 you would see a jerky playback of the moving white bar. If you would watch #2 progressive you would see 2 combed frames out of 5.

the main point is that #1 the 23p sample should be watch at 23p and will be smooth while watching this at 60 hz will result in a very bad 3:2 judder while #2 is only smooth if watch at 23p with realtime IVTC else you will see 3:2 judder again.

in theory #3 could be IVTC too and played at 23p but that is hardly supported and the file is not flagged interlanced so smooth playback is hard to achieve.

[wonkey_monkey]

I made one that's 25fps at the beginning and then switches to 29.97fps for the final 60% or so. I used the same 23.976fps source for both so the first part plays slightly too fast and the second part quite a bit too fast.

I don't get it. I don't see the speed changing. DGIndex reports a "field order transition" but I don't see any interlaced frames. I'm still not convinced we're talking about the same things.

It does seem to play back at different speeds in VLC vs VirtulDub, though...

[manono]

You can't tell that the women waving their arms at the end are doing it faster than at the beginning? You can't notice the change in the D2V from 0 1 2 2 3 0 1 2 2 3 (or 0 0 1 2 3 0 0 1 2 3, the signs of 3:2:3:2:2 pulldown) to 2 2 2 2 2 (the sign of 2:2 pulldown)?

The field order transition means nothing here, except as a sign of where the speed change takes place. That's right, no interlaced frames. I believe DGIndex cuts on GOP boundaries and I used it to cut out the M2Vs before then running them through DGPulldown to reset the framerates. There wouldn't be any interlaced frames. I believe the illegal transition might be where it goes from a 0 to a 2 which isn't supposed to happen. But I'm not entirely sure of that.

[hello_hello]

the main point is that #1 the 23p sample should be watch at 23p and will be smooth while watching this at 60 hz will result in a very bad 3:2 judder while #2 is only smooth if watch at 23p with realtime IVTC else you will see 3:2 judder again.

in theory #3 could be IVTC too and played at 23p but that is hardly supported and the file is not flagged interlanced so smooth playback is hard to achieve.

This is possibly not the same thing I referred to earlier, as I think it's supposed to be a motion blur test, but it's the closest I've found. http://www.testufo.com/#test=framerates&count=2&background=none&pps=960
The top UFO should wonder across the screen smoothly at 60fps (60Hz) while the second 30fps UFO looks blurred. For me I'd not necessarily say it was blurred, but rather there's multiple images overlapping each other. Maybe that's the same thing.
There's no UFO in the test running at 23.976fps, but if the 30fps UFO looks as bad as it does viewed on my displays, I'm not sure slowing it down to 23.976fps could make it look much worse, or if it did add "judder" to the equation, if it'd be easy to tell.

If you're seeing anything similar to what I do see, it might illustrate why I say progressive 3:2 pull-down is not something I can easily see, and I think it's because there's already enough horrible going on to hide it.

#3 is a different story though because the extra refreshes aren't being spread out over four frames and repeating a frame instead is quite obvious.

Do any TVs really refresh at 24Hz? I can connect to my Plasma at 24Hz but the screen can't be refreshing that way or there'd be flicker for days. If not, then probably only higher frame rates or interpolated frames will produce truly smooth motion.

[huhn]

This is possibly not the same thing I referred to earlier, as I think it's supposed to be a motion blur test, but it's the closest I've found. http://www.testufo.com/#test=framerates&count=2&background=none&pps=960
The top UFO should wonder across the screen smoothly at 60fps (60Hz) while the second 30fps UFO looks blurred. For me I'd not necessarily say it was blurred, but rather there's multiple images overlapping each other. Maybe that's the same thing.
There's no UFO in the test running at 23.976fps, but if the 30fps UFO looks as bad as it does viewed on my displays, I'm not sure slowing it down to 23.976fps could make it look much worse, or if it did add "judder" to the equation, if it'd be easy to tell.

this test is there to test the motion blur added by a display device. on a lightboost hacked asus VS248QE you can see the squad white pixel razor sharp in motion like a CRT would display it.

all these UFOs are 2:2, 4:4 or something like that so they are kind of smooth unlike 2:2:2:4 or 3:2.

the ghosting is an other problem. and even with the ghosting proper image displaying like 2:2 is way more smooth than 3:2 and easily visible to the human eye.
If you're seeing anything similar to what I do see, it might illustrate why I say progressive 3:2 pull-down is not something I can easily see, and I think it's because there's already enough horrible going on to hide it.
it is trivial for me to see 3:2 judder vs real 23 hz.

try madVR SM on a PC display @60 HZ with a 23p source. it will make playback as smooth as it would be at 23 hz. don't even think to compare this to SVP.

#3 is a different story though because the extra refreshes aren't being spread out over four frames and repeating a frame instead is quite obvious.
2:2:2:4 is really really ugly no question. 3:2 is better than this but still terrible.
Do any TVs really refresh at 24Hz? I can connect to my Plasma at 24Hz but the screen can't be refreshing that way or there'd be flicker for days. If not, then probably only higher frame rates or interpolated frames will produce truly smooth motion.

yes but it depends on the brand. sony has absolutely no problem with that "all" w series or better can do that.

they do it at 120 HZ and because of sample hold the 5 images with the same content never ever change so it is the same as 23p/24p.

i try to make a proper VFR encode later with true 23p at 23p and true 29p at 29p using a source that needs this treatment.

[Sharc]

Here 2 sample NTSC DVD (http://www.mediafire.com/download/ewwpzivw1q8fsy3/NTSC_DVDJuddertest.zip), each containing 4 clips: 3:2 soft pulldown, 3:2 hard telecine, 2:2:2:4 hard telecine, true interlaced

DVD1 has all 4 clips included in the same .vob (is this compliant at all?)
DVD3 has the 4 clips in 4 separate titles (separate *vobs)

You can check how your actual playback device plays it, and how it handles the format switching in DVD1.

[Katie Boundary]

https://scontent-ord1-1.xx.fbcdn.net/v/t1.0-9/13466425_1702864323311356_5994855343166660613_n.jpg?oh=28d5c2cd1c7755a62a8c174640179139&oe=57C75721

BTW,

She's using NTSC in the same sense as does DGIndex

Yes! We're finally speaking the same language!

anything not progressive 23.976fps with 3:2 pulldown is NTSC.

Well, there's also PAL. Why doesn't DGIndex have a PAL option in addition to Ignore Pulldown, Honor Pulldown, and Forced Film?

It would be nice if it were one or the other but, sadly, it isn't.

I actually prefer the mixed material to the pure hard NTSC stuff like Babylon 5. Interlaced frames drive MPEG crazy and produce macroblocking artifacts. This is especially noticeable on Mainframe's titles.

Her example 3) includes a common mistake by the great Criterion Collection. They have this nasty habit of dropping to video for a few frames at chapter points.

Example #3 was Darkwing Duck... I think you meant to refer to one of my other examples...

She wants to learn how to make VFR videos so that solution won't work for her. I do think, though, she'll wind up bobbing her sources initially, before then converting them to VFR.

Well, bobbing is the only way to clean up orphaned fields without just decimating them out of existence, so yes, bobbing is and always has been part of the plan. I'm not sure what you mean by "converting" to VFR, though. Isn't there some way of automatically separating the soft telecine from the hard NTSC, bobbing the hard NTSC without touching the film content, and then stitching them back together into a 60/24 VFR file?

When you can't see a difference between 2) or 3) against 1), then your player does IVTC

Player? You mean VLC?

or you don't care about the combed frames or jerky playback.

I'd have to see it to care about it.

[manono]

Well, there's also PAL. Why doesn't DGIndex have a PAL option in addition to Ignore Pulldown, Honor Pulldown, and Forced Film?

It doesn't need one as PAL sources are all handled with 'Honor Pulldown Flags'. If you had a separate PAL category it would do exactly the same thing. In the Field Operation section of the DGIndexManual (you might read it sometime as it's very good) it says:
Honor Pulldown Flags - The pulldown flags (if any) are obeyed and the fields are repeated. This means that the frame-served video will appear exactly as it is intended to appear on the final display device. Therefore, if you have a 3:2 pulled-down clip, you'll get the standard repeating pattern of 3 progressive frames followed by 2 interlaced frames. If you have PAL or MPEG1, you'll just get the encoded pictures with no repeated fields (because PAL and MPEG1 have no RFF flags to honor). The frame rate will always be the same as the display frame rate of the source.
Example #3 was Darkwing Duck... I think you meant to refer to one of my other examples...
Oh yeah, you're right. I apologize. For some reason I read it as 90-98% FILM and not 90-98% hard NTSC. Then it's a category you either haven't run across or didn't include - the ones almost all FILM but with little sections of NTSC here and there. Not just in the black frames at beginning or end or during fades, but during the 'meat' of the video.
Isn't there some way of automatically separating the soft telecine from the hard NTSC, bobbing the hard NTSC without touching the film content, and then stitching them back together into a 60/24 VFR file?
Not if you're going to reencode for MKV anyway, or whatever VFR container you go with. And not if you're not willing to separate them out manually and reencode just the parts that aren't FILM. However, I was specifically thinking of an earlier comment of yours that the TIVTC method of creating VFR videos didn't have the option of bobbing true interlaced material. And you were correct - material that by rights should be progressive 59.94fps when all done, won't be if using that method. Bobbing the whole thing initially and then creating VFR from that allows the 59.94 parts to remain that way. The anime guys have done most of the work in this and they typically start with what are called 'raws' - 119.88fps television captures - and can create VFR encodes from that if they want to. If you begin by bobbing using a good bobber - one such as QTGMC - together with a lossless AVI codec you might be very pleased with how it turns out as a source for then creating your VFR encode.

[Sharc]

Player? You mean VLC?

I'd have to see it to care about it.

VLC for example, or better perhaps MPC-HC. Watch in full screen and switch any deinterlacers or IVTC off, then you will see the difference in the moving block (#2 with 2 combed frames out of 5, #3 with ugly judder). If you see no difference, well, you are right, why care.
You can also download this (http://www.mediafire.com/download/yciih16fz7v2amj/NTSC_DVDJuddertest.zip) and watch DVD_3 with a HW or SW DVD player. 3:2 soft or hard pulldown should look the same (no combed frames) but with the typical slight 3:2 judder. For 2:2:2:4 (repeating frame 4) the judder will be really ugly - but again, if you don't notice, why care.

[hello_hello]

Here 2 sample NTSC DVD (http://www.mediafire.com/download/yciih16fz7v2amj/NTSC_DVDJuddertest.zip), each containing 3 clips: 3:2 soft pulldown, 3:2 hard telecine, 2:2:2:4 hard telecine

DVD1 has all 3 clips included in the same .vob (is this compliant at all?)

I don't know about compliant, but when I tried stepping through the frames one at a time it was bouncing backwards and forwards as though MPC-HC was trying to play all three at the same time.

DVD3 has the 3 clips in 3 separate titles (separate *vobs)

I still wasn't sure I was seeing any difference between the first two, but it was easy to pick #3.

As an experiment I opened your earlier 23.976fps sample via Avisynth and added AssumeFPS(30,1).
I may have to take back what I said earlier because there is a difference in smoothness at 30p/60Hz, although at 30fps the motion still "jitters" across the screen, so while there is a difference, maybe I have to pay attention to see it or my brain just sticks them in the same category.

In the past I've compared 23.976/60Hz with 25/50Hz which is probably a fairer comparison, and I suspect 25/50Hz will look more "jittery" than 30/60Hz and maybe that's why I've found it doesn't stand out as being hugely different to 23.976/60 in respect to smoothness.
I can't try your sample at 25/50Hz at the moment as this PC is currently only connected to the TV via VGA, but I'll connect it via HDMI later and try again, then report back as to whether I've proved myself wrong again.

[Katie Boundary]

It doesn't need one as PAL sources are all handled with 'Honor Pulldown Flags'. If you had a separate PAL category it would do exactly the same thing. In the Field Operation section of the DGIndexManual (you might read it sometime as it's very good) it says:

Oh. For some reason, I thought that applying HPF or IPF to a PAL source would speed it up to 29.97 (which is exactly what happens when you apply IPF to a film source).

Oh yeah, you're right. I apologize. For some reason I read it as 90-98% FILM and not 90-98% hard NTSC. Then it's a category you either haven't run across or didn't include - the ones almost all FILM but with little sections of NTSC here and there. Not just in the black frames at beginning or end or during fades, but during the 'meat' of the video.

You mean example #1?

Oh, that reminds me. I'm glad that you pointed me toward the "secrets of home theater" page. In addition to finally learning exactly what "progressive scan" meant, my eyes sharpened a bit at the mention of the redone special effects in the two-disc director's edition DVD of Star Trek: the Motion Picture. As it turns out, there's actually a reason why the opening credits were done as NTSC: although the credits themselves remained at 24p, the stars behind them were suddenly moving at 30p, and of course, they were composited together at 60i... and there were indeed little bits of NTSC throughout the rest of the movie too. So, when I went to make VCD-compliant MPEG-1 encodes of the first ten Star Trek movies (because OF COURSE I went and did that...), TMP ended up being 29.97 while the other movies were done as 23.976

Not if you're going to reencode for MKV anyway, or whatever VFR container you go with.

Probably MP4, for its industry-standardness.

And not if you're not willing to separate them out manually and reencode just the parts that aren't FILM.

Well that sucks. Maybe it's time for a new software toy that can detect the framerate changes in a VOB or d2v file and allow different filters to be applied to these different sections, or at least spit out the information in a form that another software toy (like an MP4 muxer) can make use of.

However, I was specifically thinking of an earlier comment of yours that the TIVTC method of creating VFR videos didn't have the option of bobbing true interlaced material. And you were correct - material that by rights should be progressive 59.94fps when all done, won't be if using that method. Bobbing the whole thing initially and then creating VFR from that allows the 59.94 parts to remain that way. The anime guys have done most of the work in this and they typically start with what are called 'raws' - 119.88fps television captures - and can create VFR encodes from that if they want to. If you begin by bobbing using a good bobber - one such as QTGMC - together with a lossless AVI codec you might be very pleased with how it turns out as a source for then creating your VFR encode.

Regardless of the bobbing filter that is used, this does require telecining the film parts, then bobbing them, and then trying to put humpty-dumpty back together without the benefit of proper IVTC.

Of all the options that can be done using software available today, the one that seems most similar to what I'm attempting would be "to encode multiple cfr avi files (some with 23.976 fps film and some with 29.97 fps video) and join them directly into one vfr mp4 file with mp4box and the -cat option (http://avisynth.nl/index.php/VFR#encoding_to_vfr_.28mp4.29)", but that would require going through a d2v file with "ignore pulldown flags" and guessing at where the framerate transitions are.

[Sharc]

I don't know about compliant, but when I tried stepping through the frames one at a time it was bouncing backwards and forwards as though MPC-HC was trying to play all three at the same time.
Please redownload NTSC_DVDJuddertest.zip (http://www.mediafire.com/download/ewwpzivw1q8fsy3/NTSC_DVDJuddertest.zip) and try again. Bouncing issue solved?

[Sharc]

I still wasn't sure I was seeing any difference between the first two, but it was easy to pick #3.
DVD3: That's ok. You shouldn't see a difference between clip2 (hard telecined) and clip1 (soft telecine i.e. pulldown happens at playback time), because a DVD player should handle both soft and hard telecined film footage the same, means playback as progressive frames at 59.94fps with the familiar 3:2 judder.

P.S.
After all, my main point was to show that there is a significant difference between 2:2:2:4 (or repeat frame 4 out of 5) and the usual 3:2 telecine (hard or soft) for film footage on NTSC DVD, as somewhere farther up in this thread the opinion was expressed that it looks the same, or quite the same.

[Sharc]

I don't know about compliant, but when I tried stepping through the frames one at a time it was bouncing backwards and forwards as though MPC-HC was trying to play all three at the same time.
Please re-download NTSC_DVDJuddertest.zip (http://www.mediafire.com/download/ewwpzivw1q8fsy3/NTSC_DVDJuddertest.zip). I double-checked the video stream of the *.vob in DVD1. It seems that all mpeg-2 flags (Picture_Structure, Progressive_Frame, Repeat_First_Field, Top_Field_First) are set correctly and change correctly at the transition from one clip to the next. So I think the stream is DVD compliant.
Did you try to play on TV?

[manono]

You mean example #1?

No, since you defined 1) specifically for fades. If you want to broaden the definition to include any little bits of NTSC in an otherwise FILM video (logos at the beginning, chapter changes, any random NTSC, seemingly for no reason at all, black frames at beginning, end, or middle, etc.) then, yes.
Oh, that reminds me. I'm glad that you pointed me toward the "secrets of home theater" page.

It wasn't to enlighten you about hows and whys for Star Treks, but anything to get you to read it. There's a wealth of solid information there, and not just on that particular page but in the other related ones as well. Unfortunately, the 'Shootout' DVD tests have all been removed and they tested virtually every DVD player under the sun.
Maybe it's time for a new software toy that can detect the framerate changes in a VOB or d2v file and allow different filters to be applied to these different sections
The HCenc MPEG-2 encoder has the ability to keep progressive as progressive and interlaced as interlaced, but that's about as far as it goes. I believe DVD-Rebuilder can do the same.

Regardless of the bobbing filter that is used, this does require telecining the film parts...
Which you'll get just by making the D2V using 'Honor Pulldown Flags' - a hard telecined 29.97fps video (assuming it's a mix of hard and soft telecine to begin with).

...but that would require going through a d2v file with "ignore pulldown flags" and guessing at where the framerate transitions are.

I think much easier would be to play the video with the player deinterlacer turned off and note when the interlaced parts begin and end. I don't think you want to mess around with 'Ignore Pulldown Flags'.

[Sharc]

Here few more NTSC_DVD examples with various cadences (VFR) (http://www.mediafire.com/download/dbzawmu0ba3s8fb/NTSC_DVD_formats.zip).
Are there HW Players/Smart TVs which play all files smoothly (i.e. without judder), means without manual intervention or extra scripts?
The few I have tested perform well with the "common" formats (like #1: true interlaced, #3: 3-2 telecined, #5: 3-2 pulldown, #6: interframe, #7: 2-2-3-2-3 on PAL player), but judder more or less with #2 (worst), #4, #6, #7 (on NTSC player) although they can all be IVTCed if the DVD player/TV would be "smart enough" to IVTC automatically and adapt the monitor refresh rate (to multiples of 24Hz and 25Hz).

I think the clips are all NTSC DVD compliant, the flags seem to be correct and MuxMan which is usually pretty picky did not complain ....
The question may no longer be very relevant in the Blu-Ray age, but one still finds all kind of mixed formats and hacks for the extra material on Blu-Ray discs.

[hello_hello]

I had a play with your new samples (I hadn't relaised you'd replaced the first lot until now) but I still have a hard time telling apart what I call "jitter", which I think is due to the sample and hold effect (ie 25fps at 50Hz) that prevents objects from moving smoothly across the screen (where there's a lot of contrast between the moving object and the background) and 3:2 pulldown which to my brain just makes the "jitter" effect a little worse, but not noticeably worse. Repeating whole frames stands out though. I wonder if the test might be better conducted using a moving object with less contrast compared to the background?

One issue was MPC-HC didn't seem to be de-interlacing the interlaced sample (or not de-interlacing it properly) if there was already an instance of the player opening another sample. The 59.940i sample would bob up and down. An issue I couldn't repeat with any other interlaced video. In MPC-HC's settings for LAV, I had Cuvid enabled, but neither of the de-interlacing options checked. Disabling Cuvid didn't fix it, but enabling either of the de-interlacing options did.

"Enable adaptive hardware de-interlacing (Cuvid/Qs)" fixed the problem when checked, but that led me to wonder who's de-interlacing when it's not checked.
"Software deinterlacing (Yadif)" also fixed the problem, which still left me wondering who'd be de-interlacing when Cuvid isn't being used for decoding and neither options are checked.

That led me to comparing de-interlacing, which was interesting, or maybe not.... I'm not sure. I rarely watch interlaced video. 99.99% of what I watch is progressive, or progressive after having been de-interlaced or IVTC'd when I've re-encoded it, so I don't think about "what happens on playback" much.

Neither de-interlacing option enabled in the LAV decoder configuration (sharpest picture):
https://s31.postimg.org/vtjyb8ku3/No_deinterlacing_enabled_in_LAV.png

Hardware de-interlacing enabled (blurred, and number "6" on top right not de-interlaced as well):
https://s32.postimg.org/xir7dxmtx/LAV_Hardware_De_interlacing.png

Yadif De-interlacing enabled (similar to hardware de-interlacing with a "shimmer" around the top left text that can't be seen in the screenshot):
https://s31.postimg.org/ef63ygtpn/Yadif.png

Another oddity I noticed was when first opening any of the samples the text appears to be interlaced, or it's being de-interlaced when it shouldn't be, but only for a frame or two before normality returns. I couldn't work out why.

https://s32.postimg.org/kawn2w8np/progressive_1.jpg
https://s31.postimg.org/n7ptulqjf/progressive_2.jpg

After all that I've run out of time to look at the samples for the purpose for which they were actually intended at the moment. Hopefully I'll be able to have another look tonight.

[Katie Boundary]

No, since you defined 1) specifically for fades. If you want to broaden the definition to include any little bits of NTSC in an otherwise FILM video (logos at the beginning, chapter changes, any random NTSC, seemingly for no reason at all, black frames at beginning, end, or middle, etc.) then, yes.

I was using fades as an example of the NTSC bits that get sprinkled around.

It wasn't to enlighten you about hows and whys for Star Treks, but anything to get you to read it. There's a wealth of solid information there,

Yeah well aside from Star Trek and an explanation of Progressive Scan that actually made sense, it was the same stuff I read 10+ years ago in READFAG.

The HCenc MPEG-2 encoder has the ability to keep progressive as progressive and interlaced as interlaced, but that's about as far as it goes. I believe DVD-Rebuilder can do the same.

Noted.


Which you'll get just by making the D2V using 'Honor Pulldown Flags' - a hard telecined 29.97fps video (assuming it's a mix of hard and soft telecine to begin with).

Speaking of "stuff I read 10+ years ago in READFAG"...:p

I think much easier would be to play the video with the player deinterlacer turned off and note when the interlaced parts begin and end.

uhhh... no. Trying to find a specific frame in a normal media player's seek bar? That would just give me flashbacks of Adobe Premiere 6.0 failing to decode DivX AVIs with frame-accuracy

[wonkey_monkey]

uhhh... no. Trying to find a specific frame in a normal media player's seek bar?

Who said anything about using a "normal" media player?

I should think it's rather obvious than manono's talking about using VirtualDub or something of that ilk.

[Sharc]

.....Neither de-interlacing option enabled in the LAV decoder configuration (sharpest picture):

Clip #1 (interlaced): When any deinterlacing, bobbing or field separation is really disabled and you step through the clip on frame basis, you should see combing (mice teeth) of the moving white bar.... but apparently (from your screenshots) you got no combes at all so I suspect that you had still some deinterlacing activated, or we are fooled by the screenshot (?)

[hello_hello]

Clip #1 (interlaced): When any deinterlacing, bobbing or field separation is really disabled and you step through the clip on frame basis, you should see combing (mice teeth) of the moving white bar.... but apparently (from your screenshots) you got no combes at all so I suspect that you had still some deinterlacing activated, or we are fooled by the screenshot (?)

I don't think the screenshot is foolin'.
When I step through the frames one at a time in MPC-HC, each number on the right displays twice (looking a tad different due to the de-interlacing) but as though I'm stepping through a 54.940fps video.

I have LAV decoding the video, and ffdshow processing that, so I can stop the video from being de-interlaced by unchecking ffdshow's "set interlaced flag in output media type" option, which I assume prevents ffdshow from telling whoever's doing the deinterlacing it needs to be done. With that option unchecked, the video displays like this and when I step through the frames one at a time, the numbers on the right only display for a single frame:

https://s32.postimg.org/475qxxwv9/interlaced.png

I assume the video card must be de-interlacing, but if it is I'm not sure why it appears to do a better job than the de-interlacing with either of the LAV de-interlacing options checked.

Anyway, I still haven't managed to try the samples for the purpose they were intended. Hopefully later today....

[Sharc]

^^^
Now the picture looks ok, and you are watching non-deinterlaced frames. You see the mice teeth. They are short because the motion between fields is low (simulating a slow camera pan).
The number on the top right always indicates the (progressive) frame number, not the field number. When you would separate the fields the number would repeat.

You may want to re-download the latest version (http://www.mediafire.com/download/dbzawmu0ba3s8fb/NTSC_DVD_formats.zip). The picture is sharper. Otherwise nothing has been changed. For analyzing it is best to watch it at 100% original resolution, otherwise the upscaling will introduce its own artefacts, e.g. smearing the combes etc.

[hello_hello]

My computer seriously dislikes your samples, although the problem of the 59.940i sample not being de-interlaced when there's another instance of MPC-HC open has gone away with the new samples. Now apparently, MPC-HC doesn't like resizing mpeg2 video. With or without hardware decoding enabled. FFS.....

Here's a video of DVDish resolution encoded with the x264 encoder running full screen (ie upscaled to 1080p). All is well.

https://s31.postimg.org/n32p9gqkb/madvr1.gif

Your sample at the original resolution. All is well.

https://s32.postimg.org/swtp84j4l/madvr2.gif

The same sample resized to fullscreen. Dropped and delayed frames for days (it happens with the progressive and hard telecined samples).

https://s31.postimg.org/4rr5w6lu3/madvr3.gif

I've no idea why I can't resize mpeg2 without issue (it's not just your samples, I've checked some others). I guess it shows how little of it I watch to not have noticed that's a problem. I've no idea why the MadVR stats show DXVA for mpeg2 given I'm using MPC-HC and it doesn't support DXVA on XP. Or maybe that's the cause of the problem. If I switch to an old renderer such as the "Overlay Mixing Renderer" the dropped frames problem appears to go away. Computers....

So after going through all that I'll take another break to let my eyes rest and come back to it again.
Now I've worked out resizing mpeg2 video is an issue I've checked the interlaced sample without resizing and it glides smoothly across the screen as it should when de-interlaced to 59.940fps. No "jitter" or "judder" to be seen. All the other samples are less smooth when it comes to motion, but I'll have a break and check them all again properly.

[Sharc]

No rush!

Hmmm... strange with all the dropped frames when upscaling etc. I have not seen this here.
Perhaps there are sometimes just too many conflicting or competing settings and filters in SW players. Try with VirtualDubMod.

I still hope that I did not miss something when I prepared the clips......

[hello_hello]

I might just give up and go mad. There's something odd happening. It's probably XP related, or something to do with my video card. I don't think it's your samples as I seem to be able to duplicate the dropped frames problem with other mpeg2 video (sometimes, at least). I've tried disabling IVTC in the video card's settings, but that doesn't seem to make any difference.

I can (usually) play any of the samples without dropping frames if they're running at their native resolution. Running fullscreen is a different story.

But why should I have dropped frames for days when running this fullscreen:

https://s32.postimg.org/e1y9qd7xx/madvr4.gif

While this one doesn't have that problem?:

https://s32.postimg.org/qalafgarp/madvr5.gif

Could it be to do with one being encoded as interlaced and the other as progressive, although I'm not sure why de-interlacing should effect resizing, unless the video card is doing both ands can't keep up?
Why does MadVR show DXVA for the first one and not for the second one?
Why is my computer torturing me like this?? :(

[Sharc]

.....Could it be to do with one being encoded as interlaced and the other as progressive, although ....
Possibly yes. The purpose of the clip is also to check how players handle the transition between formats (glitches, stutter, temporary combing ...
Maybe you try with DVD_7 which has the 7 clips isolated in individual .vob's
Sorry, I didn't want to stress you unduly ;)

[hello_hello]

I stopped thinking about it and went to bed, so naturally the penny dropped just as I was about to go to sleep and I had to get up again....

I think it's simply a matter of how many frames per second need to be rendered when de-interlacing is enabled. When it's not enabled it's in the range of 24 - 30fps. When de-interlacing is enabled it's twice that (double frame rate de-interlacing). Which probably also applies to hard telecined NTSC if it's encoded as interlaced.

To test that theory I enabled software de-interlacing and set it to "single frame rate" and the problem went away, so I think the issue was having to resize twice as many frames per second and the video card not keeping up, and not the de-interlacing as such.
Or the de-interlacing could be contributing, because I've got quite a bit of progressive video at 50fps and haven't noticed an issue with dropped frames, but then again most of it was resized to 640x480 for encoding, so the lower resolution might allow the video card to keep up with decoding and resizing without dropping frames.

This PC is also connected to the TV via VGA at the moment, although I don't know whether that should make displaying frames harder for the video card.

After all that, I think it comes down to a combination of interlaced video and slow hardware, combined with the user being a bit stupid and not realising sooner, so tomorrow I'll look at the samples again, trying to forget any of that happened and without resizing them.

[Katie Boundary]

Could VCD-compliant MPEG-1 streams of different frame rates be strung together into a single title on a VCD? I'd never actually do it, I'm just curious...