Interlacing issue
 

Hi there,

I acquired this AVC@720p through the NRK (Norwegian TV) archive website without re-encoding, but there's a strange interlacing issue I can't figure out. Here is a still frame from a finger hitting a piano key
Attachment 16010

and here are the fields side by side
Attachment 16011

As you can see she lines in the separate fields are still garbled. Does someone here see how the lines can be put in order? I attached a short sample...

Thanks!
Karel

The video is 25 fps progressive. I would guess that the source material is interlaced and 30 fps (60 interlaced fields). I viewed the video field by field, and the even/odd field pairs are almost identical. That is consistent with the scan of the source material being progressive and not interlaced. Also noticed every so often a frame is duplicated. Probably because the source material was not 25 frames per second. It could have been shot on film at 24 fps progressive, then telecined to 30 fps interlaced for broadcast. Or it could have been shot on video at 30 fps. My guess it was not originally 25 fps though, because of this occasional duplication of frames. Naturally, the progressive scan of an interlaced video source is going to show the jagged edges.

Seems the scan is the casualty of incorrect frame rate and progressive scan of interlaced material. I don't suppose there's anything that can be done.

I understand the anger one can have when seeing analog video scanned improperly. I would think even a casual observer who knew nothing about interlaced vs progressive would notice how something is not right with the video. Hard to understand how this can get through any kind of quality control or approval process before being released. Although, I do see major studios putting stuff online (such as youtube) who cannot get the aspect ratio or frame rate correct. When it's a video of something you really care about, it can really break your heart when it is handled improperly by people that don't understand the most basic of things about analog video transfer and don't appear to care. I know I feel like screaming, "Give me the tape, and I'll do it myself!" :mad4:

As a jazz fan, I wish I could have helped. Sorry that I cannot.

Sorry, ignore parts of my prior post. I was playing around with the file after converting from the mp4 to an HUFFYUV AVI file, and I had used the incorrect frame rate. Forgot it was 25 fps. Once I fixed that, I don't see the occasional duplicate frame. I would change my guess, and say the original video probably was 25 fps, based on where you say the source material is from.

So I think any issues you see in the video would be if this video were scanned progressive instead of interlaced. When I look at each field, I still see jagged artifacts, which I would suppose were not in the original film or telecined video, as the case may be. So if the fields are like this, there's really nothing that can be done to fix that. One other possibility could also be that this video was scanned interlaced, but when they converted the video to progressive for the H264 codec, something was done wrong.

I did some playing around in Avisynth with swapping even/odd field order, but was not able to make the video look any better. But, when the fields show that many jagged edges, I didn't expect changing field order to make a difference.

I've can't recall seeing that effect with high-motion 25FPS progressive. It would just be blurred.

Agreed. I was still modifying my post after you quoted me, as my thoughts were still not totally thought through. :)

When the fields themselves have jagged looking artifacts, such as on the veins in the arm of one frame, it tells you something scanned the video at a different rate than the original video. The original video would not have such an artifact, it would simply be a blurry object. When you break down a frame into the separate fields you see a picture half the size of the frame and it should be free of jagged artifacts. You should only see jagged artifacts when looking at 2 interlaced fields put together. Assuming, of course, it was scanned as interlaced. Interlaced scans each of those fields independently, where as progressive scans 2 fields at once, so jagged artifacts can be introduced. When you break down a frame that was scanned progressively into 2 fields and it still shows jagged edges, then the scan has not faithfully captured the original video.

The one thing that makes me believe there's a solution, is that the separate fields actually look beter, even if they're still not right. In fact if you look at the fields, they kind of look interlaced like a frame would be!

So from the first field, lines 1-5-9-13 etc. appear to be from the same instant in time, while from the other field lines 4-8-12-16 etc. seem to be from that same instant... (I'm doing this by eye, I'm not accustomed with other ways to check individuals lines yet...)
Together that would give the following line order: Field A = 2-3-6-7-10-11 etc. // Field B = 1-4-5-8-9-12-13 etc.

To accomplish this from the original frame, lines 1&2 should be swapped, lines 3&4 remain intact, 5&6 swapped, 7&8 intact... So a field swap for every other line. In theory possible, but is there a way to try it out?

Take this over to Videohelp.com. There are some coding wizards there; if they can't fix it, nobody can.

In Avisynth, you can slice and dice a video down to the pixel if you wish.

Separate and Select commands could be used. Refer to http://avisynth.nl/index.php/SeparateRows and http://avisynth.nl/index.php/Select

As it says in the documentation, SeparateRows(2) is the same as SeparateFields, which gives you a set of even and odd fields. But if you used SeparateRows(720) for a 1280 x 720 video, it should slice it down to the individual row level. From there, you can use Select functions to access whatever pairings you want. Then you use Interleave and Weave to reassemble fields/frames. Refer to http://avisynth.nl/index.php/Weave and http://avisynth.nl/index.php/Interleave. WeaveRows(720) would reassemble into a frame of 720 rows. Or if you want to operate on fields, I suppose you could start with SeparateFields or SeparateRows(2). From there you could try SeparateRows(360) on each field. If you want to first separate even and odd fields of the frame, you could SelectEven and SelectOdd, then call SeparateRows(360) on each of those.

It does look a bit like what you get if you scale an interlaced clip while treating it as progressive. Guess it's happened at the source since the videos on the web archive site are all 25p (and not 50p for originally 50i content a :mad:)

Could be... those are 70ties Norwegian videotape recordings, so probably captured as PAL and then upscaled to 720(p) for web distribution

Yeah most stuff on there has been scaled correctly and deinterlaced to 25p but I guess some clips could have slipped through the cracks for whatever reason.

I've tried my idea of what the correct line order should be with Avisynth, combining the functions SeparateRows, Interleave & Weave, but it didn't work out. The pattern seems to be more complex... It's a bit of a brainbreaker. I should need some overlay telling me each line number of the videoframe so I could figure out the pattern more easily (if there is one)

It has been upscaled using a progressive algorithm, while still interlaced (in fields) - this resamples the original scanlines

You can use inverse kernel to downscale, such as debilinear, debicubic etc...

Yes thank you very much!
Can you explain why you're applying the downscaling on the pillarboxed video, instead of on the 4:3 image? And also, what's the reason you have to downscale to 572 lines instead of 576? I would assume they applied the upscaling on a 720x576i file and added the black sidebars later...

If I want to keep the video interlaced, can I just do like this?
Or are there advantages to deinterlacing the video and denoising it?
(I'm having some trouble getting a temporal denoiser working in AviSynth+ x64...)

In order to keep as much of the quality of the original heavily AVC-compressed video intact, I exported in VirtualDub x264 on slow preset with CRF=18 and --tff flag. I'm not familiar yet with those AviSynth downscaling algorithms, so I don't know which one is optimal. It also apparently fixed the aspect ratio, since (I now see) the original video was horizontally stretched. The result is much more enjoyable to watch, although sometimes the compression artefacts are a bit more noticeable. There are also moments where the downscaling algorithm is having a hard time, but that's maybe where the temporal denoising would come in?

No real reason, it's equally valid to crop and apply inverse resize

The 572 with inverse resizing kernel is the only critical step. If you use the wrong number, you will get "wavy" results . It takes trial and error to get the "right" number. Try out some number like 576 and preview several successive fields (or preview with a double rate deinterlace like bob to check a few frames) - you will instantly know it's the wrong number. You can use a helper function to animate the values and preview in avspmod or vdub2 - ask if you want more info on that

yes

Depending on what your target was, that 572 might not be valid - e.g, DVD-video . Also 572i might cause problems on some devices

Mainly because of the chroma issues (chroma was also scaled progressively, while still in fields - so you get a color flicker - mctd on the high setting also denoises the chroma temporally so it evens out the color flicker somewhat) . There are residual combing and artifact issues in the source and after inverse resizing - You can never "undo" an upscale perfectly, and there are lossy compression artifacts to begin with, so denosing can help, but it's a tradeoff .

If your display device/chain has a bad deinterlacer, you can make an argument for perhaps better software deinterlacing

Try out some variations and choose what works best for your situation

If you have specific avisynth+ questions, you need to post the error message