Why is my PAL interlaced messed up? [SOLVED]
2 Attachment(s)
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? :question: |
Convoluted fix for TFF sample. I'm sure there's a much shorter way.
Code:
MPEG2Source("PAL-TFF.d2v") http://www.avidemux.org/admWiki/doku...er_swap_fields Less hacky alternative that supports 4:2:0 without conversion: Code:
MPEG2Source("PAL-TFF.d2v") |
5 Attachment(s)
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. :huh1: 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. :wall1: 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. :laugh: |
https://www.ffmpeg.org/bugreports.html
Why not skip Lagarith altogether and install the faster & more efficient Ut Video or MagicYUV? :) |
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? |
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. |
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. |
Quote:
Quote:
Quote:
|
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. :cool: |
Sorry for making your To-Do even longer. :omg:
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. |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.