Color of footage going dull after applying ConvertToYV12()

[MiyaDV]

Right,

When I try to render with MeGui or Zarx264gui I have to add a ConvertToYV12() at end of script, and this is causing my footage to colors to be all faded...

Before ConvertToYV12()


After ConvertToYV12()


I'm wondering if theres anyway to encode to H264 without using ConvertToYV12 or is there anyway to fix this?
is this normal for video compression? like will it happen no matter what I encode with, I just noticed this now so I haven't tested much but yeah..

[JaddziaDax]

tweak(sat=1.2)

or whatever setting suits your fancy

[Mosc]

What program did you use to take those screenshots? Converting between color spaces introduces very small rounding errors, but should never cause this big of a difference. My guess is that your video renderer assumes a wrong luma range. Please don't use Tweak to compensate for what's most likely just a wrong setting in your player of choice.

I'm wondering if theres anyway to encode to H264 without using ConvertToYV12 [...]

H.264 doesn't support RGB and that's a good thing. It's highly inefficient for video compression.

[Zarxrax]

Those shots have not only had the colorspace changed, but the resolutions are also different. Please take a screenshot of your avisynth output with ONLY the colorspace line added, to ensure some other filter isnt doing this.

[Zero1]

It's not a saturation issue. As you can see, the dark areas such as the back of the head are lighter in the second image. This says to me that the luma values have changed. If it was just a saturation problem, it would have been mostly as dark as it was in the original since the dark part of the head contains mostly luma information and not much chroma.

The surrounding areas such as the top left red part of the sky would give you a better indication since they are a little more neutral, however that still isn't an exact science, since altering the luma often alters the overall image (brightness/contrast).

At what point were these images taken? Is the after converttoyv12, after it's been encoded? There are a couple of things to bear in mind. One it could be converttoyv12 that is compressing the range from 0-255 to 16-235, though I'm not sure why it would do that. It goes against common practice, but it's not technically breaking any specs to encode, say, a DVD at 0-255 (in fact I've seen a few) so I don't see why they would add that as an option. Also the fact that there is already a command to alter the levels makes it even less likely.

Some decoders alter the range on playback, and it can also depend on the colourspace your decoder outputs to (as well as it depends on how your graphics card handles different colourspaces). Having said that, it might even be the case that the source is actually 16-235 (as is often the case with DVD) but the encoder/decoder it is being processed with when you edited it/made a lossless is scaling the 16-235 to 0-255 on playback, and when you converttoyv12/encode to H.264, the lossless decoder no longer affects it. It might just be that your graphics card alters the range for certain colourspaces (which you sounds as though you have seeing as you need converttoyv12), but not for YV12.

So as you can see, it's a pig of a job encoding on a PC sometimes. My initial advice would be to post your script(s) so we can look to see if anything is up, then encode the H.264 and try it with different decoders or players (FFDshow/CoreAVC/VLC) to see if the problem still exists in the finished product. If so, you might also consider asking someone else to check it out for you.

But before I go, as a last resort I'll post this function:
Levels(0, 1, 255, 16, 235)
This should scale the lighter end result back to the same levels as the original, providing my theory about it being levels/decoders/whatever is right. However it is not a good idea to try to compensate for things like this because you are actually hurting the quality in the long run. Also the reason 16-235 exists is for TV. If you display 0-255 on a TV it can get oversaturated and lose definition so bear that in mind.

What you effectively may end up doing is:
0-255 > 16-235 > 0-255
Where the first 0-255 is possibly the range of the source (some CG animation tends to be that, even on DVD), it then appears to be changed to 16-235 by converttoyv12/encoding/decoding, which means you are then rescaling the 16-235 to 0-255 to compensate for that. It's like having a 1024x768 image to start with, something you aren't sure about causes it to rescale to 800x600, and to compensate for that you are rescaling it to 1024x768. Not the best method.

The other thing is that if it is a downloaded source, it is more likely to be 0-255 than 16-235 because encoders/rippers/whatever tend to adjust the source so that it looks good on computer monitors rather than TV.

[MiyaDV]

JaddziaDax-

I did try that, but yeah as others said I could notice the black being faded, but I thought that was normal cause of encoding

Mosc-

I used Windows Media Player, because it was the only way I could get the screenshots and when I put the files in it the video player upscaled them.. But I also played it on Media Player Classic, and Zoom player and they all had the same color issues

Zarxrax-
See above for res issue
The only Filter I had in it was ConvertToYV12() , but I realized I don't even need that now as lagerith has an option for YV12 output, so I tried rendering in Vegas to Lagerith YV12, and it doesn't do the color issue, but when I render in your gui it still does (or if I add a converttoyv12() and play in a player)

Zero1-
My source is from the DVDS, I ripped them, Change size/deen'd/deinterlaced only from scripts, then encoded to Lagerith YV12 from Vdubmod, then from there I started to edit.

I took one of the original clips I encoded lossless in Vdubmod, and applied the script command AVISource("....") only, and encoded it with the Zarxgui as an mp4, and the color issue happens, I also tried putting these scripts into vdubmod

Code: Select all

AVISource("....")

-

Code: Select all

AVISource("....")
Converttoyv12

and for some reason, nothing happens to the color.
but when I take those two scripts, and open them in a player the color issue happens... (maybe vdub isnt realtime on color? I dunno..)


--

Ok, the first two images I gave you guys were the original, and then an encoded MP4

I just found out how to take SS's in MPC so here:


Media Player Classic

Code: Select all

AVISource("C:\Documents and Settings\Owner\Desktop\P&Dbeta\PPIOED\PPIOED(sun7).avi")

Code: Select all

AVISource("C:\Documents and Settings\Owner\Desktop\P&Dbeta\PPIOED\PPIOED(sun7).avi")
ConvertToYV12()

Heres a new mp4 where I didnt need to add the converttoyv12 since I just found out you can change lageriths settings to YV12 (but it's still doing the same thing.
note: This is still in MPC

Mp4 with

Code: Select all

DirectShowSource("C:\Documents and Settings\Owner\Desktop\PD.mp4")

Original .avi from vegas


VDubMod

Code: Select all

AVISource("C:\Documents and Settings\Owner\Desktop\P&Dbeta\PPIOED\PPIOED(sunMEET).avi")

Code: Select all

AVISource("C:\Documents and Settings\Owner\Desktop\P&Dbeta\PPIOED\PPIOED(sunMEET).avi")
ConvertToYV12()

Do these have the same problem?

argh lol i always have these weird unfixable problems

My GFX card is 8800GT, could that be doing it...

[MiyaDV]

Opps, forgot to edit this out:

I also tried putting these scripts into vdubmod
and for some reason, nothing happens to the color.


it DOES happen in vdubmod, it was just harder to notice

[Zero1]

Good. As I thought, the last two images seem to have the same levels. This rules out converttoyv12 messing stuff up. Good troubleshooting there testing that

That means that the levels discrepancy is caused in the playback of the MP4 (since it's fine when it enters the encoder, and all it does is drop information, not alter colours). As I suspected, it seems to be a playback issue. The video is passed to the encoder fine, it is encoded fine, but it looks wrong on playback.

As I mentioned, decoders, colour spaces, graphics cards; they do all manner of weird things. Taking screenshots from MPC isn't the best idea because any changes made by the rendering mode or graphics card may show up in the screenshot.

Here's something to try.
Create an avs with the command to load the final MP4 via directshowsource, save that script then load it into Virtualdub. Seek forward a number of frames and take a screenshot. Go to the Video menu and click "copy source frame to clipboard". Then go into your graphics program and choose Edit > Paste then save the PNG.

Do the same as above but for the AVI. You may want to try loading the AVI with avisource and directshowsource just to see if there are any differences.

Then compare them and/or post them here.

It seems that VirtualDub's preview windows are unaffected by graphics card settings. Probably because it avoids certain rendering modes. This should give you a fairly accurate representation of what has actually been encoded. If you are happy with what you see in VirtualDub then you can carry on.

The thing I am trying to avoid is altering the appearance of the encode to compensate for a graphics card which perhaps has the brightness up too high or a decoder or rendering mode which isn't producing an accurate image. That's fine, but if you did compensate for it, it would appear wrong to everyone who was set up fine.

If you feel like playing around a bit, open MPC and press the "o" key. This will bring up some settings. Go to Playback > Output and make a note of the output in the Direct Show Video section. Have a play with overlay, VMR7 and VMR9 as these are the common modes, and see which is most accurate for you. You might also find that viewing videos in VLC avoid such problems as it uses it's own decoders.

On the topic of decoders, check your graphics card settings and see if it has any H.264 acceleration enabled. If it does, disable it and test again.

Do you happen to know what decoders you have installed?

[Mosc]

If you feel like playing around a bit, open MPC and press the "o" key. This will bring up some settings. Go to Playback > Output and make a note of the output in the Direct Show Video section. Have a play with overlay, VMR7 and VMR9 as these are the common modes, and see which is most accurate for you.

This is almost certainly the thing to try. You'll find that VMR7 and VMR9, both of which you should never use, will alter the luma range in a way that's undesirable for most material. I'm pretty sure Windows Media Player uses one of these two renderers, which explains why it has these issues. Use Overlay or, if you have processing power to spare, Haali's Video Renderer.

[MiyaDV]

Wooo~ Thanks alot Zero and everyone else!

As Mosc and Zero said, that was exactly the problem. I've always had this problem and always used MPC, and I thought it was just due to encoding but that wasn't the case.

I was using overlay/system default before while it had those problems, I tried switching to Halli's Video Renderer and it's perfect!

I also did that thing (snapshot virtual dub with all those different settings) they all looked the same.

and again, thanks alot guys!