MeGUI Doing Weird Things to Frame Rate

[SameSelf]

I am a little confused. What is the source of your video? It sounds like it is mostly 4:2:2 1080i25? But what codec? I didn't realize you were dealing with interlaced footage. Color shifts can be a problem for a number of reasons. Rec.709 vs Rec.610. PC levels vs TV levels. Avoiding all these issues along with chroma subsampling issues is a challenge and why I stated earlier that you need to test your workflow with color bars and scopes to be absolutely certain. So follow these steps:

1. Download or generate some color bars that match your source footage. I generated ProRes HQ color bars for this very purpose to test my workflows.
2. Import the color bars into PP
3. Create a timeline of the color bars
4. Look at them on the scopes and make sure everything looks ok and that the colors are where they are supposed to be
5. Export/render the color bars timeline
6. Import the rendered color bars and compare them to the original color bars on the scopes, hopefully everything is exactly the same

Again, look at the Lossless Workflows link in my signature. There is extensive discussion on all these issues in PP. There are also color bars to download. It is a long thread, I know, but a ton of information is in there.

[koberulz]

Mostly, yes, I work with 1080i 25fps 4:2:2 footage. I have that process nailed: Premiere, YUY2 Frameserve, AVS with the ColorMatrix and ConvertToYV12 lines, MeGUI, x264, Blu-Ray. Done it dozens of times.

Now I've got a 1080i 25fps 4:2:0 file. Colors are fine. What's not fine is the interlacing, as shown by the two screenshots on the previous page. It causes a weird ghosting/shimmering type effect around the edges of some areas of color when there's movement, but only when viewed on a TV (it looks fine in PowerDVD). When I was first learning the process mentioned in the above paragraph, I didn't realise I needed to include 'interlaced=true' in the ConvertToYV12 line (this was before I added the ColorMatrix line). So it did the color conversion as if it were progressive footage, and caused the same ghosting/shimmering issue I'm now experiencing.

I tried a YV12 Lagarith AVI export from Premiere, but that had exactly the same issue as the YUY2 frameserve.

MediaInfo for my source:

Video
ID                               : 1601 (0x641)
Menu ID                          : 1380 (0x564)
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L4.0
Format settings, CABAC           : Yes
Format settings, ReFrames        : 4 frames
Codec ID                         : 27
Duration                         : 3h 59mn
Bit rate                         : 4 938 Kbps
Width                            : 1 920 pixels
Height                           : 1 080 pixels
Display aspect ratio             : 16:9
Frame rate                       : 25.000 fps
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : MBAFF
Bits/(Pixel*Frame)               : 0.095
Stream size                      : 8.28 GiB (89%)

[koberulz]

Bump.

[jagabo]

The image labeled original.ts is showing interlaced YV12 video converted to RGB as if it was progressive YV12. Ie, the difference between:

ConvertToRGB() # interlaced=false is the default

and

ConvertToRGB(interlaced=true)

The same will happen when converting to YUY2 or YV24() without specifying interlaced=true.

[koberulz]

Where would that be happening? I'm importing the .ts into Premiere, then frameserving as YUY2 or outputting as a YV12 AVI. That's literally all that's going on, there's no conversion of color format except in the AVS that uses the AVI/framserve, but that's a conversion to YV12 with interlace flagged as true (but the issue is obviously happening before that).

[jagabo]

Where would that be happening? I'm importing the .ts into Premiere, then frameserving as YUY2

Could be happening there.

or outputting as a YV12 AVI.

How are you viewing that YV12 AVI? For example, VirtualDub will incorrectly convert to RGB for display.

[koberulz]

For that screenshot? I just brought it back into Premiere. Wouldn't be that, though - if I use the AVI to create a .264 file with MeGUI, the problem occurs when viewing the resulting Blu-Ray disc on a TV.


EDIT: I should also point out I've done this problem-free dozens of times, but with 4:2:2 sources.

[jagabo]

For that screenshot? I just brought it back into Premiere. Wouldn't be that, though - if I use the AVI to create a .264 file with MeGUI, the problem occurs when viewing the resulting Blu-Ray disc on a TV.

I don't know anything about Premiere and I don't know your exact workflow. All I can tell you is what the problem is: interlaced YV12 chroma is being handled as if it's progressive. This is a very common problem with interlaced YV12.

Note that basic AVI doesn't really support interlaced video. You can put interlaced video in it but there's no way for the video stream to indicate the video is interlaced in the AVI header or stream header (only in the ODML extensions, which few programs use). So you typically have to override what an editor thinks about your AVI file.

EDIT: I should also point out I've done this problem-free dozens of times, but with 4:2:2 sources.

4:2:2 doesn't have this problem. Only 4:2:0. With YUV 4:2:0 pairs of scan lines share the same chroma samples. With progressive YV12 consecutive scan lines share the same chroma. With interlaced YV12 every other scan line (consecutive scan lines of the same field) share the same chroma.

[SameSelf]

My suggestion is upload a small sample and maybe someone like poisondeathray will hopefully weigh in. As jagabo has stated, and which you will find discussed in my lossless thread, trusting a video image displayed on a computer monitor is a bad idea and for interlaced footage it is even worse:

1. Computer monitors have ALWAYS been native progressive. So the image needs to be de-interlaced on the fly to properly display on your monitor. As jagabo has mentioned, the software or your GPU could be doing this any number of ways. I haven't worked with interlaced footage in quite some time. And when I do come across the rare interlaced video, I just de-interlace it with QTGMC as a matter of course to avoid these issues. All modern TVs these days are native progressive, so interlacing is going the way of silent films thankfully. I don't know how PP de-interlaces footage for display. But that is going to be a problem unless you only display each field or leave it combed. But I believe PP ordinarily blends the fields somehow.

2. for 4:2:0 footage the chroma channels need to be uprezzed to 4:4:4 for display on a computer monitor because computer monitors are 4:4:4. I believe PP uses Lanczos. I think vdub uses bicubic if you don't do it yourself in an Avisynth script.

3. Lastly, the YUV signal needs to be converted to RGB unless you have a broadcast monitor that can handle YUV signals. This is where you can quickly get into issues with Rec.601 vs Rec.701 and PC vs TV levels depending on the conversion matrix used when left to the software package. It is my experience that legacy programs like vdub and many of the filters in Avisynth run home to Rec.601 unless you explicitly tell them Rec.701. But with the rise of 10/12-bit and Rec.2020 none this will matter anymore because the legacy programs will either need massive updating or will be useless.

So, hopefully you see that displaying a video image on a computer monitor is messy at best. This doesn't even get into calibration and LUTs. But, the thing is, you can do everything I mention above in Avisynth yourself: Deinterlace, uprez, and convert to RGB.

[koberulz]

I don't know how PP de-interlaces footage for display. But that is going to be a problem unless you only display each field or leave it combed. But I believe PP ordinarily blends the fields somehow.

The available options are 'display first field', 'display second field', and 'display both fields' (which leaves it combed). DBF was used to generate those screenshots. I'm not worried about display on a computer here; I'm only doing the digging because it looked bad on my TV. Which I'm assuming renders points two and three irrelevant.

Note that basic AVI doesn't really support interlaced video. You can put interlaced video in it but there's no way for the video stream to indicate the video is interlaced in the AVI header or stream header (only in the ODML extensions, which few programs use). So you typically have to override what an editor thinks about your AVI file.

It's manually flagged as TFF in Premiere, and the AVS script uses 'interlaced=true' whenever doing color conversions.

It's 1080i 25fps and destined for Blu-Ray, so deinterlacing means either reinterlacing later or decreasing the frame rate. Neither seems ideal.

Seems like Premiere is doing a conversion somewhere, but I'm not sure where that could be. I bring in the .ts flagged as TFF and it looks fine, output as a YV12 AVI and it breaks. I don't see why it would convert to some other color format in between.


EDIT: Hang on...

The image labeled original.ts is showing interlaced YV12 video converted to RGB as if it was progressive YV12.

I skim-read this and, because the AVI is the problem, didn't see that this referred to the original. So...the YV12 AVI is fixing a problem Premiere caused on importing the TS, and then it's getting broken again later? What?

The .264, which plays back badly on TV, looks identical to the YV12 AVI, not the TS file.

[jagabo]

So...the YV12 AVI is fixing a problem Premiere caused on importing the TS, and then it's getting broken again later? What?

No. I think the Lagarith AVI has further screwed up the chroma and blended the chroma of the two fields together. But it's hard to tell from a single image. You should post a sample of the AVI.

As far as I can tell there's nothing wrong with the original TS file -- it's just normal interlaced YV12 video. But somewhere between the TS file and the posted RGB image the chroma was screwed up.

[koberulz]

As far as I can tell there's nothing wrong with the original TS file -- it's just normal interlaced YV12 video. But somewhere between the TS file and the posted RGB image the chroma was screwed up.

I'm confused. You're saying the screenshot showed the TS file having been converted as progressive, now you're saying there's nothing wrong with it?

[jagabo]

As far as I can tell there's nothing wrong with the original TS file -- it's just normal interlaced YV12 video. But somewhere between the TS file and the posted RGB image the chroma was screwed up.

I'm confused. You're saying the screenshot showed the TS file having been converted as progressive, now you're saying there's nothing wrong with it?

To upload an image you had to convert the interlaced YV12 video in the TS file to RGB. Somewhere in that conversion the chroma was screwed up.

[koberulz]

I just imported the TS file into Premiere, flagged it as TFF, dropped it into a sequence, and took a screenshot of the preview while displaying both fields. So Premiere is causing the problem?

[jagabo]

I just imported the TS file into Premiere, flagged it as TFF, dropped it into a sequence, and took a screenshot of the preview while displaying both fields. So Premiere is causing the problem?

It looks that way. But it doesn't matter what the screenshot looks like. What matters is what's in the output video. I haven't seen the AVI so I don't know if it's right or wrong.

[jagabo]

By the way, Lagarith doesn't explicitly support interlaced YV12. That doesn't matter as long is it is given YV12 as input and producing YV12 as output. But if you let Lagarith convert interlaced YV12 to YUY2 or RGB it will do so incorrectly. I highly recommend you enable Lagarith's "Prevent Upsampling When Decoding" option to prevent this.

You should also make sure that Lagarith doesn't convert incoming interlaced RGB or YUY2 to YV12. It will screw that up too.

[koberulz]

I just imported the TS file into Premiere, flagged it as TFF, dropped it into a sequence, and took a screenshot of the preview while displaying both fields. So Premiere is causing the problem?

It looks that way. But it doesn't matter what the screenshot looks like. What matters is what's in the output video. I haven't seen the AVI so I don't know if it's right or wrong.

You're saying the screenshot of the TS looks wrong, so surely the AVI is irrelevant? The resulting Blu-Ray disc looks awful when played on a TV, so there's clearly an issue finding its way that far down the line...would be a pretty big coincidence if the TS file just happened to display that way in Premiere but the issue was elsewhere.

I'll give it a whirl with the 'prevent upsampling' box checked, see if that makes a difference. Otherwise, how do I convert the .ts file to something more useful?

[jagabo]

Since you're not willing to provide samples there's no point in continuing this discussion.

[koberulz]

I'd deleted the original AVI because it took up way too much hard drive space. The one created with the 'prevent upsampling' box checked results in the same problematic .264. Re-creating the AVI and then uploading it takes hours, and hard drive space, so I didn't want to go through all that if there was an easier way, particularly since it didn't seem likely to produce a different result (which has turned out to be the case). I'm figuring the solution is converting the TS file to RGB before opening it in Premiere, which would be a better use of that same time and drive space, I just don't know how to do that given it's a TS file and not an AVI.

I mean, it definitely looks like a color space conversion has happened and assumed it's progressive footage. I've had that happen before because I didn't know to flag it in an AVS, I know what it looks like on a TV.

In any event, here's a sample from the 'prevent upsampling' AVI. When viewed on a TV, the issue is clearly visible around the guy's collar.

Checking that box also prevents any Lagarith AVI from displaying in any Adobe program. I had to go uncheck it before I could use a YUY2 Lagarith VHS capture in After Effects. Not sure if that fits into this somehow.

EDIT: Okay, so I found out about DGAVCDecode.

If I convert to RGB, it doesn't matter which of the five possible matrices I choose, the colors change horribly when viewed in VirtualDub.

If I convert to YUY2, the colors stay consistent but the combs change.

Not sure how much I should read into the altered combs though, given it's VirtualDub, or which of those is the better option in general.

[jagabo]

Checking that box also prevents any Lagarith AVI from displaying in any Adobe program. I had to go uncheck it before I could use a YUY2 Lagarith VHS capture in After Effects. Not sure if that fits into this somehow.

It's definitely part of the problem. The AVI you uploaded contains interlaced YV12 video compressed with Lagarith. But, as I told you before, Lagarith doesn't really support interlaced YV12. It treats interlaced YV12 it as progressive YV12. That't not a problem when Lagarith is given YV12 to compress and it produces YV12 on output. But if Lagarith is allowed to upsample the chroma (to YUY2, RGB, etc.) it will do so incorrectly -- producing artifacts like those in your earlier image.

When a program opens an AVI file it gives the VFW library a list of supported colorspaces. For example, it may say "open this video file and give me YUY2 or RGB video". If the codec can't provide those it will fail to open the video. The fact that Adobe's software fails to open the YV12 Lagarith videos when the "Prevent Upsampling..." option is enabled indicates they can't handle YV12 as input from an AVI. When "Prevent Upsampling" is disabled, Lagarith converts the video for Adobe but does so incorrectly. So basically, Lagarith is unsuitable for your uses. Try UT Video Codec instead. It has an "assume interlaced" option and will upscale the chroma correctly.

But even when Lagarith is putting out interlaced YV12 from your AVI the chroma channels are screwed up -- they're blended together. This isn't the same issue as above. From experimentation I've determined that Lagarth can produce perfect lossless video with interlaced YV12 input and YV12 output. So something is going wrong even before Lagarith gets the video. You need to determine whether the problem is in the TS file or your processing.

[koberulz]

When "Prevent Upsampling" is disabled, Lagarith converts the video for Adobe but does so incorrectly. So basically, Lagarith is unsuitable for your uses.

The only reason I'm opening the Lagarith in Premiere at all is to compare it to the TS because I was having an issue. I open the TS in Premiere, use that to create the Lagarith, then use the Lagarith in MeGUI to create the .264.

So Premiere reading the AVI incorrectly couldn't possibly have been the issue.

[koberulz]

I converted to YUY2 using DGAVCDecode:

loadplugin ("DGAVCDecode.dll")
AVCSource("source.dga")
ConvertToYUY2(interlaced=true)

It looks the same in VirtualDub with or without the conversion, color-wise. But in Premiere, the resulting AVI is completely the wrong color. Guess I'll have to try converting to RGB, which changes the color in VirtualDub, and see how that goes.

Also possibly relevant, DGAVCDecode listed the TS as MBAFF. Not sure if that might be related to the interlacing issues?

[jagabo]

I converted to YUY2 using DGAVCDecode:

loadplugin ("DGAVCDecode.dll")
AVCSource("source.dga")
ConvertToYUY2(interlaced=true)

It looks the same in VirtualDub with or without the conversion,
color-wise.

What's "the same" as what? You mean with and without ConvertToYUY2(interlaced=true) VirtualDub shows exactly the same image? That shouldn't be the case because VirtualDub doesn't handle interlaced YV12 properly. Without the conversion you should see problems like your first image in post #28.

But in Premiere, the resulting AVI is completely the wrong color. Guess I'll have to try converting to RGB, which changes the color in VirtualDub, and see how that goes.

VirtualDub usually uses a rec.601 matrix to convert the video to RGB for display. HD video is generally rec.709, though some capture devices use rec.601. Displaying rec.709 video as rec.601 will deliver brighter greens and darker reds.

https://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p...=1#post2045830

Your sample images in post #28 are showing this difference. If the HD TS video is rec.709 ConvertToRGB(interlaced=true, matrix="rec709") should give you properly interlaced frames with the correct colors. But don't use Lagarith in YV12 mode on that. It will screw up the chroma when it converts RGB to YV12.

Also possibly relevant, DGAVCDecode listed the TS as MBAFF. Not sure if that might be related to the interlacing issues?

MBAFF is a matter of how the codec encodes the frames internally (parts of the picture without comb artifacts are encoded progressive to deliver better quality, parts with comb artifacts are encoded interlaced). The output of the codec is simply interlaced frames.

You'll have to upload a sample of the TS file to see if that is messed up.

[koberulz]

What's "the same" as what? You mean with and without ConvertToYUY2(interlaced=true) VirtualDub shows exactly the same image?

In terms of colors, yes. The combs change though.

Your sample images in post #28 are showing this difference.

Which is odd, given it's the same footage in the same program. I've always just added a color matrix conversion to the MeGUI AVS, which sorts it out at the other end and it all comes out looking fine. But that's with it looking accurate in Premiere in the first place, which this now doesn't.

But don't use Lagarith in YV12 mode on that. It will screw up the chroma when it converts RGB to YV12.

It's not going back into YV12 until the x264 process. If I frameserve this to create the AVS, I assume I do so as RGB? The sequence will end up containing both RGB and YUV video.

[koberulz]

The RGB-converted version works perfectly.

[koberulz]

Well, the video does.

Watching it in VLC it's perfectly in-sync, but when I import it into Premiere it starts out in sync and then the audio gets further and further out of sync as it goes.

[koberulz]

Bump?

[poisondeathray]

Did you load elementary stream ? PP doesn't always handle ES properly. Try in a container

Check the framecount. If they are the same, the problem is lack of container or possibly a frame rate interpretation issue (e.g. ~23.976 vs. 24000/1001) either for the file or sequence

[koberulz]

The video is in the AVI coming out of VirtualDub, although the audio is still in the TS. Not sure how to container it though?

It's all 25fps, so I can't see it being an interpretation thing. It's a nice round number.

[poisondeathray]

What kind of AVI ? What video compression ? If video is in AVI container, and audio in TS, then how did you get VLC to play it ?