Why is my PAL interlaced messed up? [SOLVED]

[lordsmurf]

I don't understand this.

PAL VHS captured ATI AIW to Huffyuv AVI.
Not resized at all.
Encoded to both TFF and BFF. VLC stutters on both versions when the deinterlacers are used.

What happened?

[msgohan]

Convoluted fix for TFF sample. I'm sure there's a much shorter way.

MPEG2Source("PAL-TFF.d2v")
ConvertToYUY2(interlaced=true)

SwapFields().AssumeTFF()

# Fix vertical placement
SeparateFields()
E = SelectEven()
O = SelectOdd().Crop(0,1,-0,-0).AddBorders(0,0,0,1)
Interleave(E,O).Weave()

# Fix out-of-phase 25p. NOTE: This changes field order to BFF as well.
SeparateFields().Trim(1,0).Weave()

# Change back to TFF.
AddBorders(0,1,0,0).Crop(0,0,-0,-1).AssumeTFF()

#Bob() # check correct playback

http://avisynth.nl/index.php/SwapFields
http://www.avidemux.org/admWiki/doku...er_swap_fields

Less hacky alternative that supports 4:2:0 without conversion:

MPEG2Source("PAL-TFF.d2v")

# Fix bottom field temporal displacement.
SeparateFields()
E = SelectEven()
O = SelectOdd().Trim(2,0)
Interleave(E,O).Weave()

# Fix out-of-phase 25p. NOTE: This changes field order to BFF as well.
SeparateFields()
BlankClip(last,1)+last
Weave()

# To produce the same bobbed output as script above.
# I guess neither field order is really "correct" though...
# ... all that differs is noise placement since this is 25p.
AssumeTFF()

#Bob() # check correct playback

[lordsmurf]

I still don't understand how it happened.
Does the flaw exist on the source AVI? How can you tell? AVI is encoded progressive.
I'm only seeing this on recent PAL captures.

If I encode in TMPGEnc 2.5, instead of MainConcept/TotalCode, it seems to be fine. What gives?

I don't get confused often.

If TMPGEnc is doing it right, why is MainConcept doing it wrong? I have MC 1.x, MC 2.x and TC 3.x, and all act the same. I don't get it. I've been using MC for at least 7 years now, and have never seen this problem.

To make it more confusing, MC works fine on a slower/older system, but not on my new Skylake. Is this a codec decode issue? Perhaps it's time to try a Lagarith install again.

EDIT: Well, SOB. I found a flaw. Wasted most of the last 2 days on this.

The libavcodec/FFmpeg version of Huffyuv -- useful in 64-bit version of ffdshow, to allows 64-bit systems to use this 32-bit codec, to allow software like MainConcept TotalCode 3 to decade Huffyuv -- messes up PAL decodes. It screws up interlacing on PAL videos. It's only good on NTSC. I've never seen this behavior before. The normal 32-bit Huffyuv that only installs in 32-bit apps like VirtualDub is fine.

I saw this issue several months ago, on one video, and assumed it was something else. My fix was to simply deinterlace the source AVI, and encode it again. It was fine for that project, but not this one. I'm glad I found the flaw.

Now ... can the libavcodec version be fixed?

Or perhaps some of you have finally won, and made me install Lagarith.

[msgohan]

https://www.ffmpeg.org/bugreports.html

Why not skip Lagarith altogether and install the faster & more efficient Ut Video or MagicYUV?

[lordsmurf]

UT-Video now supports Mac. To me, that's really important. So it's now an option. Last I looked at codecs was 2012, and the only viable lossless format for Mac was still Huffyuv via Perian. I do need to see what works with versioning. For example, which OS X version is supported; for comparison, I know Perian is maxed out at Quicktime 7, no OS X limit that I can see.

Lagarith still does not work on Mac, has too much overhead for capturing, and would merely be an intermediary for encoding.

Not sure about MagicYUV. I don't want payware/licensing issues, nor will I connect certain systems to the internet for any reason.

You and sanlyn have mentioned the differences in the past. Huffyuv YUV was YUV, and some of the others were YV12. I forget which is which. Would you comment on this?

[sanlyn]

I always capture with huffyuv. The caps stay that way until I have to go YV12 for processing or to YV12 before feeding results to an encoder that will make it YV12 anyway. I guess I was too lazy to keep recompressing back to YUY2 during restorataion. Multiple colorspace changes are something I avoid when possible.

I've not noticed any particular speed issue with Lagarith. Maybe faster or slightly smaller files, I don't know, it doesn't seem to be enough to worry about. But capture with Lagarith was more overhead -- on my old AMD slowpoke motherboard that kinda turned me away from capping with Lagarith.

I don't use a Mac and the only big NLE I use is AfterEffects, so other software or OS's haven't been an issue.

I guess you could find complaints about every compressor out there. I just use what always works and is easier for sloths like myself.

[lordsmurf]

I'm thinking of locking Lagarith to YUY2 output, using for intermediary PAL processing.

@sanlyn: Any input on that?

UT-Video is still interesting. Thinking of switching to it for Mac post-restoration/post-capture editing master SD files. Perhaps as fallback to YUY2 Huffyuv when there are Quicktime limits that may prevent Perian use. Thankfully, I've not updated my Mac in a few years, as it works for everything I need.

[msgohan]

Quote:

Originally Posted by lordsmurf

UT-Video now supports Mac. To me, that's really important.

QuickTime for Windows support was just killed with the 16.1.1 update, so it's not clear to me what needs to be done if you want to migrate files between Mac and Windows. Maybe all that's required is installing 16.1.0.

Quote:

Originally Posted by lordsmurf

Not sure about MagicYUV. I don't want payware/licensing issues, nor will I connect certain systems to the internet for any reason.

It's donation-ware. The developer has said you can put $0 in the box if you feel that's what it's worth. The file you get from the download page matches what everyone else gets; no keys, locks, or dialers.

Quote:

You and sanlyn have mentioned the differences in the past. Huffyuv YUV was YUV, and some of the others were YV12. I forget which is which. Would you comment on this?

Lagarith, Ut Video, and MagicYUV all support YUY2, YV12, and RGB without any unnecessary conversions.

[lordsmurf]

Well, added more to my to-do list:
- report bug to ffmpeg
- test UT, Magic and Lag on Mac
- test Magic on Linux
- compare Magic speed on the Skylake

Thanks.

[msgohan]

Sorry for making your To-Do even longer.

MagicYUV should be much faster for decoding than anything else, and slightly faster than Ut Video for compression, but slightly less compressed when the content is videotape. I think MagicYUV can be smaller than Ut when the content is noiseless 1080p and beyond.