TIVTC - Artifacts?
 

So, I have a bunch of music videos on DVD that I'm converting to MP4. The vast majority from this particular subscription service (Promo Only) are film sources telecined for DVD distribution.

I get good results with TIVTC using default settings on most videos. However with some, after using tfm() and tdecimate(), I get stripes of color every 4th frame in portions with faster motion, like the following:

http://www.digitalfaq.com/forum/atta...1&d=1491869324

Notice the orange-ish stripes in the upper left of the frame, and also the blue regions on T.I.'s face...

Workflow:
Rip DVD to "IFO" mode using DVDecrypter
Split VOB for specific music video using Mpg2Cut2
Create D2V file with DGIndex (Field Operation > "Honor Pulldown Flags")

Avisynth Script:
Like I said, the artifacts only appear every 4th frame.

Any ideas???

A few problems with your script, other than the current madness that compels people to endure a quality hit by resizing and resampling standard def source and then hollering about the results, LOL! (but I realize they're doing this for very limited playback devices or web mounting that can't handle DVD, MPEG, telecine, or other standard commercial formats):

Your code converts DVD source (which is aleady YV12) to YV12 ? ?
Of course, nothing happens on that line.

The statement "nnedi3_rpow2(rfactor=2, cshift="spline64resize", fwidth=960, fheight=720)" involves three resizing operations, one of them a 2x software upscale, followed by a software downscale back to nonstandard 960x720 and an alteration of the original image proportions, then a hardware resampling by your playback system to match the resolution of different display panels. Personally I would have left the original alone and been satisfied with only a one-time playback resampling. When playing on TV. did you turn off your TV's overscan feature? Otherwise you're losing part of the image by masking on all four edges on TV's with default overscan settings. Of course on a PC player it won't matter.

The image posted says you have more periodic color problems than you realize -- I see a lot of discoloration and blotching in that image. The trouble is here:

The periodically telecined fields in your original source are interlaced. The original source is some form of YV12, likely 4:2:0. With interlaced frames in YV12 you must crop vertically in multiples of 4 pixels, not multiples of 2, or you screw up the colors. Look at the table in the bottom half of this page: http://avisynth.nl/index.php/Crop.

You could clean up the script by first eliminating the LoadPlugin statements, which you don't need because the dll's you're loading are in the default folder and will load automatically (unless you have some system problems that require those lines). Then, if you must, you should crop after IVTC, not before:

If it's allowed, you might get slightly better results by resizing only once, and in only one dimension, such as Spline36Resize(856,480) for NTSC. That's not as big as your nonstandard 720p, but high definition is based on high source resolution, not on frame size.

If you still have the color problem you have a faulty source. But no one can tell from a still image alone, they can only guess.

Yup, that's the case here. These files are specifically for playback in DJ software to whatever display happens to be at the venue where I'm working. I would never do this in a preservation situation--say, VHS transfers of home videos or rare material :congrats:

Oops... hold habit from YUY2 VHS captures. It didn't even occur to me that DVD was YV12. As far as loading scripts, I don't think I realized that putting them in the default folder eliminated the need for loading statements. I learn something new every day!

You lost me there... I thought overscan was strictly a CRT display issue? Flat panels are fixed-pixel displays, so overscan shouldn't apply? Unless you're talking about the settings where a 4:3 image can be zoomed/stretched to look like 16:9? (I would never do that if it's under my control). Regardless, these videos will either be played on my projector as part of my mobile DJ setup or on whatever display system a wedding or restaurant venue happens to have. I never know what I'll be plugging into. Having a picture with a slightly stretched image is the lesser of two evils vs. leaving the black overscan areas intact in this scenario -- or at least that's the judgment call I made.

Good to know. My logic was "remove pixels first, less work for tfm to perform," I guess. (I originally applied this logic when using the more computationally-intensive QTGMC on some true interlaced sources.) I'll also ensure vertical cropping is divisible by 4 (I thought most functions threw an error if that was the case?)

I guess I'm not sure where the 856 is coming from? My source is 720x480 (non-square pixels)... on that note, what happens to pixel aspect ratio on a spline resize?

Thanks for your help and advice, Sanlyn.

Yes, I figured there were special playback considerations.

The YV12 line doesn't huirt becauase the source is already YV12. The statement just doesn't do anything. No harm done, just saves some typing.

Today's TV's are almost always set for about a 10% overscan, defeatable via the TV's menu. Some cheaper sets have no adjustment available -- you either take what they give you, whether it's overscan or not. Most plasma TV's had no overscan enabled, but a few expensive ones were adjustable. My SONY Bravura 37" LCD has three overscan settings: "full pixel" (no overscan), "Normal" (about 10% overscan), and "-1" (about 15%). Adjusting overscan does nothing to the original image ratio, it just zooms in or out slightly but proportionately. A 16:9 image with no overscan displays as 16:9 -- with overscan applied, it's still 16:9 but is zoomed in by about 10%.

The mod-4 rule for vertically cropping YV12 applies to interlaced frames. Telecined frames are interlaced structures. But after IVTC the frames are progressive, so mod-2 can then be used. Unfortunately you likely won't get an error mesage unbless you try to use odd numbers or attempt to use a function that expects mod-4 or bigger. Many Avisynth filters will throw an error if the frame dimensions can't be cut down to mod-8 block sixes.

The resize method itself has no effect on the image proportions. What affects the proportions (original image aspect ratio) are the height and width you set. The math gets a little goofy. I'm not certain what the original display aspect ratio was (DAR). As DVD it has to be either 16:9 or 4:3, but your code suggests you have have thick side borders and perhaps some bottom border head switching noise? It's not certain from the image posted, but the posted image is 1.3343:1, or several pixels wider than 4:3. But that image is moot with a height of 667, and odd-numbered dimensions aren't allowed for most YUV colorspaces.

The DAR appears to be 16:9. If the height is to be 480, then 1.77777778 x 480 would be a width of 853.3 pixels -- not allowed because of the odd number, but not horizontally divisible by 2, 4, 8, or 16. If you look at the standard sizes for all of SD and HD video, the dimensions are all mod-16 (except for 1920x1080, where 1080 is only mod-8, not mod-16). So for practical use it's best to stick with mod-8 at least. This means that to get a mod-8 width for a 480-pixel height, the width is rounded to 856.

However, the clincher is that the crop is a compromise (I asked myself why the top is cropped?). The result at 856x480 square-pixel is actually about right, but only if you crop that extra 6 pixels off the top. Since we have no view of the original video frames, I'd have to say that the final image size is correct for 16:9 but with a little of the original top missing.

The video had black borders all the way around, including a 6-pixel tall black region at the top and bottom. No head switching noise though, I don't think this source saw analog tape anywhere along the way to DVD. Promo Only gets their files directly from record labels (although in 2003 I don't know what format the labels would have been providing... probably MPEG-2, unfortunately, which means this underwent 2 lossy encodes in order for PO to add their stupid text overlay prior to DVD authoring). It's intended to be a 4:3 aspect ratio video. I think the 720x480 is due to overscan padding and DVD's not having a square pixel aspect ratio? PAR always confused me a little bit...

The screenshot I posted is a sloppy crop of hitting "print screen" on my keyboard, so no info to be gleaned from its dimensions.

When I get home tonight I'll try your suggestions (cropping AFTER deinterlacing) and I'll skip creating fake 4:3 720p by upscaling. However, what's the best way to achieve a standard, square pixel 640x480 image from the 692x468 image that I'll end up with after cropping the original 720x480? Should I just spline64resize(640,480)? Would I be significantly better off quality-wise by living with the 6 black pixels top and bottom and limiting the resize to act horizontally 692 --> 640?

With only 6 pixels at top and bottom each, this original video might be 1.6:1 movie film instead of 16:9, common in many circles. Certainly the original image wouldn't be "regulation" 1.85:1 movie or you'd have more pixels letterboxed top and bottom. I'd crop the side borders and make it 640x480 with the 6 pixels retained top and bottom. Trying to get the original 1.6:1 to fill the screen won't be possible, as it's neither 4:3 nor 16:9 image content. A capture of an entire frame with all borders would tell us more.

Great news -- cropping AFTER TIVTC 100% fixed the color artifacts.

Also, thanks for your input on the other stuff!