MeGui - Avisynth Colorspace Question

[Bully9]

I've been using MeGui for a long time with a kind bit of help from this forum. And I've had moderate success despite not having a profound understanding of many of the finer points. Now all of a sudden as i hit 'queue' i get an 'incorrect colorspace' warning: "The colorspace of your clip is not in YV12... Do you want me to add ConvertToYV12() to the end of your script?"

If i click on 'no' I get: "Your AviSynth clip has the following problem: You didn't want me to append ConvertToYV12(). You'll have to fix the colorspace problem yourself. Continue anyway?"

I've always been blissfully ignorant of the question of 'colorspace' and never had any cause to believe this was an important gap in my knowledge, but clearly this now seems to be a 'problem'.

Could someone please post a very brief idiots' guide as to what this 'problem' is exactly and whether i should add the extra instruction to the avs script? And why has this suddenly surfaced after all these years?

Thanks.

[jagabo]

YV12 is a YUV colorspace with a luma channel (Y, a greyscale image) that's the frame size of your video and two chroma channels (U and V, the colors, added/subtracted from the luma) at half the resolution both horizontally and vertically. So if you have a 1920x1080 video the luma channel is 1920x1080 and the two chroma channels are 960x540). The general idea being that the human eye has less color resolution than greyscale resolution.

http://fourcc.org/yuv.php#YV12

The encoder you are using apparently requires YV12 as input and the output of your AVS script is something else.

[Cornucopia]

Not all AVISynth filters work with/use all colorspaces, so what colorspace you end up with is determined by what space you started out with (source file format), plus which input decoder/filter you used, plus which additional transformation filters you used in your script.

And, as jagabo already mentioned, it wouldn't show up as a problem unless the encoding/playing app works in only a particular colorspace (such as YV12, probably the most common with lossy encoders).

The fix is simple: just say "YES" when it asks to append the line for you!
(as long as your resolution is mod2)

Scott

[hello_hello]

Could someone please post a very brief idiots' guide as to what this 'problem' is exactly and whether i should add the extra instruction to the avs script? And why has this suddenly surfaced after all these years?Thanks.

Probably because up until now, all the video you've encoded has been YV12, and MeGUI and the tools it uses can all process YV12 video, so it's always been YV12 in/out. And now after all these years, you're encoding a video that isn't YV12. The x264 encoder can cope with a few different input formats but MeGUI assumes you're ultimately going to want a YV12 encode so I think it plays it safe and offers to convert it for you regardless.

It might pay to check the colors of the encoded video are the same as the original. Depending on the conversion taking place if they're converted with the wrong formula the colors can look slightly different (high def or standard def formula) and you can't even trust MeGUI's preview for that one..... just check the encoded video.

YV12 is the standard colorspace used for most video (mpeg, DVD, Bluray etc). There's no colour issues to worry about when it's YV12 in and YV12 out (unless you're downscaling HD to SD but that's another story). What's different about the latest source? Did it come from somewhere unusual? A type of video you don't normally work with etc?

[Bully9]

Thanks for the replies.

hello_hello - that's the strange thing. The source video is a file downloaded from my humax HDR satellite TV recorder - something i've done many times before. The script is very simple:

DirectShowSource("G:\Video.ts", fps=25.00, convertfps=true)
LanczosResize(1280,720)

I'm using typical x264 codec settings that i've used before.

I know the fix couldn't be easier, and i presume it offers no quality loss, but i was curious as to why one was required and what would result if i encoded without the added instruction.

I have recently changed my OS to Win7 64bit, but that shouldn't have a bearing surely?

[jagabo]

I have recently changed my OS to Win7 64bit, but that shouldn't have a bearing surely?

That definitely does matter. What DirectShowSource() returns depends on what source filters and codecs are installed on a system. Maybe the DirectShow decoder is set to output RGB or YUY2.

[hello_hello]

Someone else may know something about the recorder, but maybe it's the decoding and not the original video. Maybe whatever codec is decoding is also converting to another format in the process (edit: it looks like jagabo beat me to that one). I don't know what decoder you're using (something that came from Microsoft with Windows?) but for me it's easy enough to see the format when decoding via DirectShow because ffdshow and it tells you. Plus you can control the output format.



Or before adding ConvertToYV12() to the end of the script, add Info() and you should learn which colorspace you're working with that way.



If you're not using a DirectShow decoder you can configure yourself, maybe don't use Directshow. It's not necessarily the most reliable method anyway.

Use MeGUI's File/Open menu to open the video. MeGUI should offer to index it. Add the indexing job to the queue and run it. With ffmsindex or L-Smash doing the indexing and then the decoding (depending which you choose) there should be no conversion. If it's mpeg2 video in the TS file MeGUI will default to DGIndex for indexing and that'd be the best option.

That's all my guesses used up for the moment. If you want to read a bit more about colorspaces, there's some info here. It's just some information on the colorspaces Avisynth will play with and how to convert between them. You don't really need to understand it completely. It's just a bit more info for you.

[Bully9]

Right, thanks, i think i'm starting to understand. Info() tells me that the decoder colorspace is YUY2 and one difference from my old MeGUI is that there is only the ffshow audio decoder icon in my system tray (and two haali splitters). Before, i'm pretty sure there was a ffshow video decoder icon as well. Which presumably means that i need to configure the ffdshow video decoder? However the H.264/AVC format is set to libavcodec (which i basically thought meant 'enabled'. So why doesn't avisynth load the ffdshow video decoder?

[jagabo]

"enabled" doesn't necessarily mean it will be used. It depends on which decoder has the highest priority in DirectShow. You can use a filter manager to check/fix that. Also, with 64 bit Windows you need 64 bit ffdshow if you are using 64 bit AviSynth; 32 bit ffdshow if you are using 32 bit AviSynth. And, be sure you are setting ffdshow's DirectShow settings (Video Decoder Configuration), not the VFW settings (VFW Configuration).

[Bully9]

I'm pretty sure i'm using 32 bit ffdshow and avisynth - they are both in Program Files (X86). I've got the right video settings (Video decoder configuration). Could you possibly expand a bit on your first comment about priority in directshow and using a filter manager? Thanks.

[hello_hello]

Didn't Microsoft get all "we want you to use our codecs" with Win7 and make life a little harder for Windows users yet again?

I'm still on XP so I have no first hand experience, but give the Win7DSFilterTweaker a spin. I think that's the sort of thing jagbo was referring to.

[Bully9]

Thanks - i tried it and changed mirosoft to ffdshow every where i could and failing that to merit. I then set Video decoder configuration direct show control merit to very high, but it's made no difference. DirectShowSource still decodes to YUY2.

Edit - although the Info() instruction shows YUY2, i don't get the 'problem' mesage any more.

[jagabo]

Enable ffdshow's tray icon. Then when it's in use you'll see the icon in the Tray and you can configure it from there. You can also force ffdshow to output particular color spaces in the Output section.

[Bully9]

Enable ffdshow's tray icon. Then when it's in use you'll see the icon in the Tray and you can configure it from there. You can also force ffdshow to output particular color spaces in the Output section.

Not sure what you mean. The icon appears in the tray when in use, it's just not been appearing, just the audio icon. YV12 is among the ticked colorspaces in output. I'm in the middle of an encode using the dgavcindex - i'll try a directshowsource and see if the video icon appears after the tweek when this encode is finished.

[hello_hello]

Did you check the "don't bother me with this s#*t again" option last time it asked if you wantred the colorspace conversion added to the script?

There's a button in MeGUI's option for resetting dialogues. If that doesn't work try shutting own MeGUI, opening the settings.xml file in MeGUI's installation folder with notepad, and do a search for YV12. You should find the following line in there pretty easily and you could change it, save the change and restart MeGUI.

<AskAboutYV12>true</AskAboutYV12>

For the ffdshow problem, did you also disable Windows Media Foundation for the file type in question if that's applicable? The way I understand it is if you don't, it doesn't matter how you set DirectShow merits because Media Foundation is used instead.
If you're a MPC-HC user you could also disable h264 (or another video type) in the list of transform filters and restart the player and open a video to see if MPC-HC will then use ffdshow for decoding. It might be another way of testing things.

[Bully9]

Well, i was getting a bit tired the other night and i think Win7DSFilterTweaker actually worked a treat. I've been experimenting just to confirm and it seems that simply changing the H264 option under 'preferred decoders' does what is required. The ffdshow video icon now loads in the system tray as MeGui loads the avs file and info() shows YV12. No 'problem' message when i hit 'queue'.

I shall probably mostly use an indexing option anyway, but it is good to have the direct show as an alternative/backup and to know that the source file will be decoded properly - without microsoft's 'assistance'.

Many thanks for all the help.