Sony Vegas - YouTube makes the colors pink

[Bucic]

Description:
Videos saved using lossless codecs are fine out of Sony Vegas but "pinked" when uploaded to youtube.

What I'd like to achieve while producing videos for YouTube in SV:
(CamStudio -> Sony Vegas -> YouTube = perfect quality of a screencast)
Main goal - retain colors and practically perfect quality of screenscasts recorded by CamStudio.
Second - to be able to choose whatever lossless codec with sensible compression ratio (HuffYUV files are too big!).

What I tried already:
Videos recorded in CamStudio using either CamStudio or TechSmith lossless codecs are perfect after uploading to YouTube. The problem is that SV brakes colors/causes artifacts when rendering to these codecs.

I also tried x.264 lossless - it changes white to grey.



Inverted means inverted colors when played in Windows Media Player Classic Home Cinema. Colors are fine when played in VLC.

Source vids from CamStudio:
camstudio codec http://www.youtube.com/watch?v=YjwcO0OywBY
techsmith codec http://www.youtube.com/watch?v=9LMb3alxYng

All the vids below has been rendered in Sony vegas and are fine played in media player but got "pinked" when uploaded to YouTube:
camstudio_to_camstudio http://www.youtube.com/watch?v=Ajq3OKsSMiw
techsmith_to_camstudio http://www.youtube.com/watch?v=UWSXjEskGfo

Same as above (pinked by YouTube) but inverted colors when played in Windows Media Player Classic Home Cinema. Colors are fine when played in VLC:
camstudio_to_techsmith http://www.youtube.com/watch?v=SRRM3sPx-2E
techsmith_to_techsmith http://www.youtube.com/watch?v=ErnWUxyrmY8

Lossless h264 (from ffdshow) pinked by YouTube:
camstudio_to_h264lossless http://www.youtube.com/watch?v=lQXJ9GHfRww



I started using a brilliant little piece of software called CamStudio for recording screencasts/tutorials. Another great thing about it is that one can upload video recorded in CamStudio lossless codec (same for TechSmith codec if you have at least Camtasia demo installed) to YouTube resulting in insane quality! See http://www.youtube.com/watch?v=vCGuV440y-I#t=0m55s Then I stumbled into the problem...


EDIT:
I tried with SVMS 10 trial. This sucker can't even spit out a video without fractals (camstudio/techsmith lossless codec)!

[poisondeathray]

You should do some reading on how vegas works. It's a bit complicated, but you will get levels shifts depending on your input format, project settings, and export settings, hence your colorshifts and levels shifts. You also have to keep track of what colorspace you are in, each YUV<=>RGB conversion is lossy, and requires a matrix conversion specified (Rec. 601 vs. Rec.709 , PC vs. TV Levels). Also, the preview window in vegas is not accurate

http://www.glennchan.info/articles/vegas/colorspaces/colorspaces.html
http://www.glennchan.info/articles/technical/hd-versus-sd-color-space/hd-versus-sd-color-space.htm
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

Also, youtube uses Rec.709 , but you are probably rendering in Rec.601, hence another color shift. Not much you can do about it. If you search, there was a thread at videohelp discussing this

x264 lossless is YV12 (4:2:0) only, so if your input is RGB, it's not lossless. Your screen capture is RGB (4:4:4)

Main goal - retain colors and practically perfect quality of screenscasts recorded by CamStudio.

Not possible if you're using youtube

Second - to be able to choose whatever lossless codec with sensible compression ratio (HuffYUV files are too big!).

Not possible if you are staying in RGB. Lagarith RGB will offer slightly better compression than Huffyuv. If you subsample to YV12 (4:2:0) , you will get better compression as well, at the expense of subsampled chroma

[Bucic]

OK, I get it and I'll note the articles links for later reference.

I would appreciate if you'd advise me on what to do next or what is worth pursuing and possible:

1. Investigate why SV 10 messes up (heavy artifacts) Camstudio losseless codec and techsmith lossless codec encoding (both are accepted by YouTube and give perfect quality!).
2. Investigate why YouTube messes up (pink colors) videos rendered in SV 9 using Camstudio losseless codec and techsmith lossless codec.
3. Investigate why YouTube messed up (pink colors) video rendered in SV 9 using H.264 lossless (the best alternative lossless codec I've tried - good results!).
4. Choose another lossless codec
   a) with as close to RGB (4:4:4) color space as possible - does such codec exist?
   b) whichever will work - when we run out of options.

The perfect solution would be 1 and 2

[poisondeathray]

examples of lossless RGB compression: lagarith, huffyuv, ut video codec. They all will be huge in filesize

I looked at some of your videos, I'm not seeing "pink". For example your camstudio to camstudio , the opera browser text looks red to me. Can you describe in more detail what you mean by "pink" ?
http://www.youtube.com/watch?v=Ajq3OKsSMiw

[Bucic]

Here's a comparison



Other example of pinked video in my collection (SV curse...) http://www.youtube.com/watch?v=E87r9YYkcew It's clearly visible on CamStudio and TotalCommander windows (TC background is just GREY on my desktop).

[poisondeathray]

ok, i see, the grey has a pink hue to it. Not sure why that's happening

[Bucic]

Soo, can you tell me what options are left from those 4 I listed above?

[poisondeathray]

not sure. I just did some quick tests and I don't get pink hue over grey shades when rendering without vegas

Did you check your upload before uploading to youtube, I suspect it already has the color shift

If you want complete control, I suggest using your own host and website, you can specify anything you want.

[Bucic]

According to the table above I got two different videos rendered in SV into CS codec fine and they both got "pinked" by YouTube. So yes, I made a complete record of what got broken and when. The thing is YouTube can provide excellent quality. The problem here is faulty SV. I bet some of the pinked videos would not get pinked if they had been encoded in VirtualDUB or even SUPER.

[poisondeathray]

Yes, it's probably the colorspace conversion or levels shift in vegas. I just did some quick tests (without vegas), and it works fine for me, no pink hue. Captured with huffyuv camstudio, encoded with h.264

http://www.youtube.com/watch?v=f7W-qGahkFA make sure you watch the hd version in full screen. It's crystal clear, no color shift

I compared the 3 versions, a) original huffyuv RGB b) h.264 YV12 version to be uploaded to youtube c) youtube re-encoded version (from browser cache). These are .png lossless screenshots of the same frame

The h.264 YV12 compressed upload was about 40x smaller than the huffyuv original RGB capture

You can notice the red print is less accurate with the YV12 versions (this is from the 4:4:4 vs. 4:2:0 chroma sampling), but there is no pink hue on the grey, or at least not as bad as your example

[Bucic]

The biggest difference is between huffyuv and h.264 YV12 (h.264 YV12 being worse). The difference between h.264 YV12 and youtube re-encoded is negligible IMO.

So if any SV editing is needed the best solution not involving any 3rd party apps would be to record in CamStudio using huffyuv, edit it in SV and render to h.264 YV12. Can you confirm that there is no other lossless codec instead of h.264 YV12 that would not cause the color deterioration as you showed on your screenshots?

This solution is the worst HDD-space-wise. I would have to compress it using 7-zip...


Some questions:
1. what h.264 YV12 you used? From x.26vfw?
2. I don't have huffyuv listed in my CamStudio. Is it named differently or do I have to install the codec?

[poisondeathray]

The biggest difference is between huffyuv and h.264 YV12 (h.264 YV12 being worse). The difference between h.264 YV12 and youtube re-encoded is negligible IMO.

Exactly. You should read up on chroma sampling. The colors and edges look more blocky from the subsampling
http://en.wikipedia.org/wiki/Chroma_subsampling

I didn't upload the RGB version, but I 100% assure you it will look like either YV12 versions (because youtube re-encodes everything to YV12 using h.264 anyway ! You gain virtually no benefit from uploading a RGB 4:4:4 video. You have to upload a video 40-50x larger for no quality benefit!

So if any SV editing is needed the best solution not involving any 3rd party apps would be to record in CamStudio using huffyuv, edit it in SV and render to h.264 YV12. Can you confirm that there is no other lossless codec instead of h.264 YV12 that would not cause the color deterioration as you showed on your screenshots?

This solution is the worst HDD-space-wise. I would have to compress it using 7-zip...

It doesn't matter if you upload RGB 4:4:4 or uncompressed , it will deteriorate as youtube converts to YV12 4:2:0 . Flash platform only supports YV12. To preserve the color information with no sampling you need RGB 4:4:4.

Your color shifts and "pink" are from something else, probably vegas settings, and input format. Read the links above for more info. You can minimize shifts if you use uncompressed in/out of vegas

1. what h.264 YV12 you used? From x.26vfw?

CLI , but it shouldn't matter. The color shifts and "pink" are probably from vegas, I suspect

2. I don't have huffyuv listed in my CamStudio. Is it named differently or do I have to install the codec?

If you install huffyuv, it should show up on camstudio compression list. I used camtasia studio, but it's basically the same . It shouldn't make a difference if you use camrec or other lossless format. The difference is in how vegas handles it. Read the links provided above and/or in your other thread. Vegas is very peculiar about how it handles video formats.

[Bucic]

Exactly. You should read up on chroma sampling. The colors and edges look more blocky from the subsampling
http://en.wikipedia.org/wiki/Chroma_subsampling

Will do.

(...)(because youtube re-encodes everything to YV12 using h.264 anyway ! You gain virtually no benefit from uploading a RGB 4:4:4 video. You have to upload a video 40-50x larger for no quality benefit!

Now that is a very important info! And it brings me to few additional questions (knowing that YT will encode to YV12 using h.264):
1. Is it possible to upload to YT a video in such format so that YT will do no encoding operations on it? This would give an instant out-of-SV preview of the final YouTube results.
2. If so wouldn't it be better quality-wise than uploading a video in lossless format?

You can minimize shifts if you use uncompressed in/out of vegas

Another useful piece of info.

CLI , but it shouldn't matter.

OK, let me make sure I have all the codecs I need installed...
HuffYUV - checked
h.264 YV12 - I think it's achievable through x.264 but I don't know the proper settings to make sure it's actually h.264 YV12. Can you sketch needed changes on the shot below?

Vegas is very peculiar about how it handles video formats.

One could frame this topic and show SV devs what users have to juggle with to get around crippled SV cooperation with codecs installed in the system.


I couldn't thank you enough!!! I was right that investing some time to ask #at the right place# will pay back If you still have some energy left I would appreciate if you tested a CS recording using CS codec, then load it into SV and render it again using CS codec and upload to YouTube. I wonder if you would get pinked vid too. Maybe you would come up with some new solution for SV screwing CS codec encoding which would be awesome!

P.S. Is it just me or is this forum s-s-s-llowww?

P.S. 2. YťŚ} <- I had these characters in my x264 command line (command line was enabled!). Very disturbing...

[poisondeathray]

1. Is it possible to upload to YT a video in such format so that YT will do no encoding operations on it? This would give an instant out-of-SV preview of the final YouTube results.

No. Hence the recommendation to use your own site. You have more control over bitrate, quality etc.... In the past there were 100 page threads full of hacks, but YT closed all the holes.

2. If so wouldn't it be better quality-wise than uploading a video in lossless format?

Negligible, you still incur the colorspace losses . If your YV12 upload is suffcient bitrate, it won't make much of a difference than if you uploaded a 4:4:4 uncompressed or losslessly compressed upload. Just ~50x smaller. Youtube will still re-encode about 2-2.5Mb/s for the 720p version.

h.264 YV12 - I think it's achievable through x.264 but I don't know the proper settings to make sure it's actually h.264 YV12. Can you sketch needed changes on the shot below?

I don't think YT accepts x264 lossless (at least it didn't a few months ago when I last checked)

x264 encoder only outputs YV12

I couldn't thank you enough!!! I was right that investing some time to ask #at the right place# will pay back If you still have some energy left I would appreciate if you tested a CS recording using CS codec, then load it into SV and render it again using CS codec and upload to YouTube. I wonder if you would get pinked vid too. Maybe you would come up with some new solution for SV screwing CS codec encoding which would be awesome!

I don't really use YT much , and I don't use your version of vegas. I think if you use uncompressed for everything, then encode using x264 in a different application, it should work out. If I get a chance, I'll do some tests later

[Bucic]

Questions after your last post:

1. Does it still make sense to upload h.264 YV12 lossless to YT instead of e.g. 6 Mbps Sony AVC?
2. What do I have to install to get access to h.264 YV12 lossless through SV?
3. If h.264 YV12 lossless video goes pink when uploaded to YouTube does it mean that we've ran out of options for getting a h.264 YV12 lossless vid out of SV and then to YouTube?
4. Where in SV do I check what color space is particular piece of video and same for the whole project?

[poisondeathray]

Vegas uses RGB internally, depending on the settings, it maybe studio RGB or computer RGB. Read the links about vegas for more information. If you have a DV or HDV project you can stay in YV12, because it smart renders those formats. But as soon as you use color correction , filters, it's decompressed to RGB any way

I think h.264 lossless isn't compatible with YT

Other YV12 lossless intermediates - FFV1, lagarith (in YV12 mode), huffyuv (in YV12 mode), UT video codec, MLC lossless, a dozen more.....

I don't think it's worth uploading a lossless YV12 to YT, it's many times bigger (30-40x), but negligible increase in quality. A decent bitrate h.264 encode is good enough

The problem you're facing is the various colorspace conversions . Each colorspace conversion is lossy (Even using lossless compression), and each can convert using a different matrix, PC vs. TV levels, Rec. 601 vs. Rec 709 coefficients. Read the articles for more information, and do some experimenting. What is mentioned in this thread may change tomorrow; as YT always changes their practices

[Bucic]

You said

b) h.264 YV12 version to be uploaded to youtube

and I probably took it wrong as a lossless format, sorry.

I am going through the articles about SV color spaces but slowly. I'm more stubborn than a bits-bytes savvy.




Let me wrap around what we've already established re proposed workflows (starting from the last process, [color space] [operation])


[YV12] [YouTube converts to YV12 color mode, h.264, mp4, ~2.5 Mbps]

[? ?] [rendering in Sony Vegas: Sony AVC mp4 (h.264) ~6 Mbps]

[?RGB?] [editing in Sony Vegas]

[YV12] [CamStudio recording: HuffYUV in YV12 mode]


OR (if user accepts use of 3rd party software for rendering (encoding))


[YV12] [YouTube converts to YV12 color mode, h.264, mp4, ~2.5 Mbps]

[? ?] [rendering (encoding) in 3rd party app.: h.264 YV12] - what's the advantage over Sony AVC in SV?

[?RGB?] [editing in Sony Vegas]

[YV12] [CamStudio recording: HuffYUV in YV12 mode]



Have we avoided color space conversion during both procedures?

I will edit my post if you tell me what color space is where I placed question marks...

[poisondeathray]

The problem here is vegas. It can treat RGB or YV12 formats differently. You input something, but get something else out. Even if you input an RGB format. There maybe a levels and/or colormatrix conversion. It's not just vegas, other NLE's do the similar things and have similar quirks. In the past, I have used uncompressed in/out and then encoded with x264 without level shifts, not sure if this still works. I can't recall if this works in 8-bit or 32-bit mode (vegas acts differently when you toggle the modes, and whether you use 1.0 vs. 2.2 gamma - there is a chart that explains this on one of those articles)

If you have cuts only editing, I would use vdub in direct stream copy mode (this avoids any colorspace conversion). If you are familiar with avisynth, you can also do editing without any colorspace conversions. This way you have complete control, and the only thing you can't control is whatever youtube is doing.

The advantage of using x264 is that it offers much better quality/compression (when used properly with decent settings) compared to other implementations of h.264. You might only need 5Mb/s using x264, but might need 7-8Mb/s for equivalent "quality" if you used Sony AVC for example.

EDIT: ok I did a quick test, and the Huffyuv RGB capture => Vegas 8-bit mode => Export uncompressed AVI works fine. You can take this RGB uncompressed AVI and encode with x264. Although I recommend eventually learning the command line options for the most control, You don't have to use the command line, there are easy to use GUI's like ripbot264 , xvid4psp, handbrake, megui etc...

Rendering directly to your final format (e.g. sony avc) from vegas (instead of using uncompressed) resulted in some levels shifts.

I should mention this was vegas pro 9, so I'm not sure if your version will act the same way. You should experiment a bit to see for yourself

[Bucic]

The main reason for me to mess with Sony Vegas when doing simple CamStudio tutorials was to insert fake frames to choose a custom YouTube thumbnail. Other edits may become helpful soon. Either way it's almost pathological situation where users of advanced video editing suite are doing God knows what to eliminate it from workflow of producing a video for YouTube! Even more - it looks like it's virtually impossible to avoid color space conversion even when only SV and YouTube are involved in the process!

Advantage of using x264 instead of AVC:
When only uploading to YouTube is taken into account this advantage is negligible, i.e. AVC is simpler to work with from SV, as filesize is not our concern (the limit is 2GB and 10 minutes long).

Have you looked at my proposed workflows? I'm going through the articles you provided again and again and I think I proposed wrong workflows in terms of avoiding color spaces conversions. I have no idea what's that with 8-bit and 32-bit/(video levels) versus 32-bit/(full range) projects, I won't pretend I do. The articles don't explain it clearly enough for me.

The way I currently see it SV will work in RGB (studio or computer RGB) and I fed it with YV12 vid from CamStudio. That's one color space conversion. AVC, according to the articles, belongs to "Codecs that decode to and expect Studio R'G'B' levels" so if I get it right a video rendered using AVC will also be in RGB color space. Then we have YouTube which is YV12 color only so it's the second color space conversion!

The problem is that there is no way I will figure this out myself. Either you will propose a workflow with minimum number of color space conversions or I will have to give up

[poisondeathray]

I just edited my post above with a workflow that works. If it's too clunky for you, feel free to experiment and find a better one . Initially I thought you might have to convert the capture to uncompressed , then import, but the RGB huffyuv direct seems to work, as long as you export uncompressed AVI out.

When you do more complex stuff, and color corrections, the 32-bit mode is useful, because it offers a higher level of precision. That's 32bits per channel (32 red, 32 green, 32 blue, 32 alpha), as opposed to 8 bits per channel. This helps to minimize banding when you do things like curves or levels adjustments. But 32-bit mode causes vegas to act differently with different input/export formats. That's what that chart in one of those Glenn Chan articles is talking about

[Bucic]

Thanks for the 8-bit vs 32-bit explanation but how do I switch between 8-bit and 32-bit modes in SV? I don't see it in Project properties window nor in the help file. I'm going to test if switching between them can accidentally solve my initial problem with pinked videos!

I was about to ask you if I will ever have to use 32-bit mode which, as you said, complicates things. I looked it up and I can say for sure that I will never ever have to use it for tutorials and probably for other contents I will not have to use it either. Here is why:
http://www.dvinfo.net/forum/attachments/what-happens-vegas/4387d1189777065-32-bit-8-bi...son-8-bit-.png
http://www.dvinfo.net/forum/attachments/what-happens-vegas/4388d1189777065-32-bit-8-bi...a-1-linear.png
I just don't like the 32-bit one even though it's a picture of a real thing

You are right. It's about time to start testing. I will start using the basic Huffyuv RGB capture -> Vegas 8-bit mode workflow and compare PNG captures of each configuration. What's the ultimately true preview I can use to get PNG captures for comparison? I don't trust WMP HC (it showed techsmith encoded vids in inverted colors) and 'your' articles say that the SV preview will show bad colors when the project is in studio RGB mode. I still don't know how to check if I'm working in computer or studio RGB mode and if I have any control over it.

And one more thing - I don't see a possibility to switch between RGB and YV12 in HuffYUV v2.2.0 codec. How do I switch between these two modes?

[poisondeathray]

It should be 8bit by default , it's in the project properties . File=>Properties=>Pixel Format. Not sure if the studio version has this capability

I use avisynth + avsp to take screenshots.

In my experience, the small vegas preview will be inaccurate either way, unless you use an external calibrated broadcast monitor. Use your scopes, wave form monitor, and histogram.

Huffyuv will use whatever it's being fed; if it's RGB, it'll produce RGB. If it's YUY2, it'll produce YUY2; unless you have under RGB Conversion Method: Convert To YUY2. By default it will say predict gradient (best). I'm using v2.1.1

[Bucic]

It should be 8bit by default , it's in the project properties . File=>Properties=>Pixel Format. Not sure if the studio version has this capability

IN SV MS 9 I use the File menu is called a Project menu and I don't have any Pixel Format settings there.

I use avisynth + avsp to take screenshots.

In my experience, the small vegas preview will be inaccurate either way, unless you use an external calibrated broadcast monitor. Use your scopes, wave form monitor, and histogram.

I meant taking screenshots from already renderend vid, outside SV and I don't think I'm up to using scuh tools as histogram

Huffyuv will use whatever it's being fed; if it's RGB, it'll produce RGB. If it's YUY2, it'll produce YUY2; unless you have under RGB Conversion Method: Convert To YUY2. By default it will say predict gradient (best). I'm using v2.1.1

TBH I don't get it, sorry. I want my CamStudio recording to be in HuffYUV RGB - what do I change from the default settings of HuffYUV to make it happen? What do I change to get my CamStudio recording in HuffYUV YV12?

I would post a screenshot but I've just broken my HyffYUV installation when I wanted to downgrade from 2.2.0 to 2.1.1. Now neither of them is listed in CamStudio.

[poisondeathray]

avisynth and avsp are external to vegas. You might have difficulty learning how to use avisynth at first, but it's easily the most powerful, versatile tool for video. If you ever get involved in video, it's definitely worth your while to learn at least the basics at some point.

Inside vegas, you have monitoring tools such as scopes, waveform monitor, RGB parade, vectorscope etc... Not sure if your version has these. I just mentioned these, because they are important for doing proper color correction. The preview in vegas and just "eyeballing" it is unreliable. You often don't get what you see - those articles partially explain why. Basically it uses full range 0-255 for the preview, but depending on what format and settings your are using, it's usually "video levels" internally or 16-235 RGB, so there is a disconnect.

Leavy Huffyuv at default settings and it will be RGB. This is what I tested and worked. If you use something else it might work, it might not. Go ahead and experiment, this is how you learn.

Try re-booting or using a registry cleaner like ccleaner. You can also try vcswap to manage your vfw and acm codecs (these are different than your system installed directshow codecs)

[Bucic]

avisynth and avsp are external to vegas. You might have difficulty learning how to use avisynth at first, but it's easily the most powerful, versatile tool for video. If you ever get involved in video, it's definitely worth your while to learn at least the basics at some point.

Inside vegas, you have monitoring tools such as scopes, waveform monitor, RGB parade, vectorscope etc... Not sure if your version has these. I just mentioned these, because they are important for doing proper color correction. The preview in vegas and just "eyeballing" it is unreliable. You often don't get what you see - those articles partially explain why. Basically it uses full range 0-255 for the preview, but depending on what format and settings your are using, it's usually "video levels" internally or 16-235 RGB, so there is a disconnect.

I will rely on screenshots for now according to "what I don't see is irrelevant" rule.

Leavy Huffyuv at default settings and it will be RGB. This is what I tested and worked. If you use something else it might work, it might not. Go ahead and experiment, this is how you learn.

OK, got it. So what do I do if I need HuffYUV YV12 in one of my tests?

Try re-booting or using a registry cleaner like ccleaner. You can also try vcswap to manage your vfw and acm codecs (these are different than your system installed directshow codecs)

Already done and the codec is listed in VirtualDUB Compression Window. Fresh CamStudio didn't help either. A worst case scenario :/

[poisondeathray]

I will rely on screenshots for now according to "what I don't see is irrelevant" rule.

But how you take the screenshots is equally important, otherwise the results are irrelevant. The screenshots are converted to RGB for display, so there is a YV12=>RGB conversion. You can specify a different matrix for this conversion and it will look completely different. For example, I used Rec.601 for taking the screenshots for the youtube and uploaded h.264 video. The RGB video was already RGB, so no conversion was necessary

OK, got it. So what do I do if I need HuffYUV YV12 in one of my tests?

Not sure if huffyuv has a YV12 mode. You could use FFV1, or lagarith, or UT Video Codec.

If you are doing screen captures, I recommend that you should be doing them in RGB. Otherwise you are at the mercy of some other software's colorspace conversion and you might not like how the conversion was done. Also, you've already thrown away lots of color information. It's better to process video at the highest quality, you'll get better results if you need to do manipulations later. At least you can specify how to do the conversion if you capture in RGB (e.g. you might use PC.601 or Rec601 , or you might use Rec709 or PC.709). You limit your options if you allow the software to choose some default setting. For example if you import a YV12 video into Vegas, it will specify it's own conversion, and you might not like how it does it.

Already done and the codec is listed in VirtualDUB Compression Window. Fresh CamStudio didn't help either. A worst case scenario :/

Try installing the v2.2.0 version and see if it re-appears

[Bucic]

Oh, OK. Things are appear to not be as simple as I thought. Again. I'm talking about taking screenshots.

YV12 - noted, thanks.

HuffYUV installation:
Now I'm screwed. I did the installation from scratch: add remove programs, restart, then manual removal of leftovers, then CCleaner and now I don't see the HuffYUV codec even in VirtualDUB :/ VCsnap shows correct entry. 2.2.0 does not catch either.

[poisondeathray]

32-bit OS ? are you using 32-bit version of huffyuv ?

VCSwap shows huffyuv entry? did you try enabling it? (right click and check out the options)

[Bucic]

64-bit OS. I didn't know there is 64-bit version of huffyuv. This sucker http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv-2.1.1.zip made all the mess. Before I had 2.2.0 from http://www.free-codecs.com/HuffYUV_download.htm. The codec is listed only in VCSwap (active).

Edit:
It's OK now, it reappeared now... when I was reading forum posts. Maybe I was checking too fast after changes before...

Anyway, thanks again for your help. I have to go. I will report back in some time later. I was tempted to switch to 2.1.1 because 2.2.0 gave me blank black recording in CamStudio and the file was crashing media players. I hope it won't happen again.

[poisondeathray]

you can install 32-bit in x64 OS

see this post
https://forum.videohelp.com/threads/302087-AC3-ACM-Will-Not-Install-with-Vista-64?p=184...=1#post1849154