meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)

[youmeus]

Yes, just checked - it doesn't. But you should never need uncompressed video - use a lossless compression codec in VirtualDub. I use Huffyuv all the time - it's fine in MeguIVit.

Oh alright then
I would use Avisynth to process my Fraps files with for instance Huffyuv but colors are much too dark when decoded, also after running them through the One-Click encoder. The Fraps are lossless YUV (701) and apparently decoding these to show the proper colorspace in Mac OS X isn't working. I noticed that the default "custom" Avisynth script in the One-Click encoder of MeguiVit beta4 adds ConvertToYV12() right after crop in the script. I have tried leaving this both in and out of the script but it makes no difference - the out is always much darker than intended. The data is there in the video files however as running these Fraps files through VirtualDub to uncompressed RGB made them render properly in MPC afterwards. These also render properly in QuickTime in Mac OS X, however I can't them in that format there since they go right back to being dark when I convert these into h.264 in Mac OS X.
Do you have any suggestions on what I might do to get these lossless YUV (701) AVI files through MeguiVit properly?
I've attached a download link containing small sample of the clip here:
https://rapidshare.com/files/2939755241/fraps-test.avi

 

[Vitreous]

In VirtualDub always check "Video>>Fast Recompress" to avoid an unnecessary colorspace conversion (unless you're using VirtualDub filters, but no reason for that here). That might cause your problems. Try outputting to huffyuv in VirtualDub (install FFmpeg and huffyuv should be available as part of the ffdshow codec). Then feed that to MeguIVit.

It also sounds like the problem that earlier Mac OS X (<10.6) had with gamma. It used to assume a monitor with a gamma of 1.8. Everything else assumes 2.2. Sometimes that difference affected video or image processing and made things dark. Dunno about fixing that or if it still causes problems with newer OS X...

 

[Rollyco]

When in-game, the video displays colors using PC scale RGB (0-255), but your encoding is probably clipping them to 16-235 (TV scale.)

Also, you might be experiencing a bad colorspace conversion. For example, using Rec.601 coefficients (implicitly) when the source demands something else. That usually manifests itself as a red push OR a green push. But this is difficult to see if you also have a PC-to-TV scale mismatch.

Check the Avisynth wiki for information on the "matrix" parameter of the ConverttoYV12() for more information. You can fix most color range and coefficient mistakes with that. You can also try the ColorMatrix filter.

You may also want to read up on FRAPS recording modes and coefficients. I've read rumors that some modes use strange non-standard coefficients...

 

[Vitreous]

There may be a simple solution. It's better to avoid all colorspace and color primary (matrix) conversions in avisynth where possible, and instead flag the correct values in the encode. I only just noticed you said you could feed the fraps directly through MeGUI, so try this:
- Feed your fraps file into MeGUI, but remove (or decline) the addition of ConvertToYV12 if you can (you seemed to suggest that it works without).
- Before you start the encode, go to the "Encoder Config" tab and press "config" for the video profile
- Go to the Misc tab and check the "Full Range" box (note: this has changed in the most recent MeGUI & x264, reply if you need the newer method, not relevant for MeguIV(it) though ).
- Encode...

Some codecs/players might still ignore the "fullrange" flag, but I believe that situation is getting better.

--

If that fails, or for a safer slightly lossy method:
- Make sure full range is unchecked
- Add this to the end of your avisynth script:
ColorYUV(levels="PC->TV")

 

[youmeus]

Thank you for all your replies guys!

Try outputting to huffyuv in VirtualDub (install FFmpeg and huffyuv should be available as part of the ffdshow codec). Then feed that to MeguIVit.

This worked just fine. After running that file through MeguiVit's One-Click encoder I get an MP4 looking like it should when rendered in VLC and MPC.

When in-game, the video displays colors using PC scale RGB (0-255), but your encoding is probably clipping them to 16-235 (TV scale.)

Thanks for that input Rollyco. I followed Vit's suggestion on putting "ColorYUV(levels="PC->TV")" in at the end of the script in the One-Click encoder, then fed the Fraps AVI to it and this also output an MP4 that renders like it should. Setting full range in the V.U.I settings of x264 didn't seem to make a difference.

However, when I put either of the MP4 outputs above into i.e. Adobe Premiere or iMovie they pop right back to being displayed way too dark. Same thing when exported from either of these programs. Do you guys recon its because they change the colorspace when rendering the files?

 

[Vitreous]

However, when I put either of the MP4 outputs above into i.e. Adobe Premiere or iMovie they pop right back to being displayed way too dark.

That's just messed up. Only way I can see that happening is if Premiere or iMovie are doing something strange with the levels. Post a short MP4 that you created with the ColorYUV(levels="PC->TV") statement, but before you put it in Premiere. I can check that if it's OK at that stage, in which case Premiere/iMovie are at fault.

 

[youmeus]

Post a short MP4 that you created with the ColorYUV(levels="PC->TV") statement

When opened in QuickTime 7 Pro it turns out right. However, I just tested this file with my commercial encoder too for Mac OS X, its called Pavtube and is based on FFMPEG I believe. When I do a h.264 encode with that, using libx264 writing application, the output comes out dark too. If I put the QuickTime encode into iMovie or Premiere though, turns up dark again.
Anyway thanks for your help again mates.
Here is the link to the MKV:
https://rapidshare.com/files/1652672744/test_ColorYUV_levels_PC-TV_.mkv

 

[Vitreous]

I can't see anything wrong with that mkv. Looks very close to any other rip out of MeguIV now. If I re-encode it I get no problem.

Attached image shows the luma range (uppermost of the graphs at the top-right): the entire width of the graph including the brown regions is the 0-255 range. Your video is nicely in the black area, which is the usual 16-235 range that most players assume.

The info (from madVR) at the left shows that it's being decoded without anything strange: YV12 colorspace - normal; BT709 matrix & primaries - standard for HD; limited range is the correct guess (16-235). It all looks good.

The BT709 might be wrong - I hear that FRAPS is weird on that, but at worst it will create a slight color shift, not a brightness change. You'd probably not notice. And the exact 30.0fps is not typical but not a problem; 29.970 is what you'd get from a DVD for example - but that shouldn't affect brightness.

No idea. Maybe this is your player doing something wrong with the output of Premiere etc. Try a different player? Or maybe this is that old Mac gamma problem. Are there any gamma settings in the problem apps?

 

[youmeus]

Alright thanks mate I'll play around with Premiere abit too try to solve this.

 

[youmeus]

Or maybe this is that old Mac gamma problem. Are there any gamma settings in the problem apps?

Sorry for not following up on this before now. There are no gamma settings that I am aware of in iMovie. I am sure there are in Premiere, however I am not very well versed with that app yet.
I told you that when I run either of the files, whether it is the x264 MP4 or the raw Fraps file, through my commercial encoder, the output becomes darker than what I put in. However, when increasing the brightness in the commercial encoder before I encode the MP4 or Fraps AVI, I seem to be able to remedy this darkness problem all together. This would suggest it is a gamma issue wouldn't it? However, whatever I run through iMovie comes out after editing and exporting looking completely washed out and a little darker too. Premiere can export my files however so that they look good, not washed out like iMovie, but dark too. But to summarize: putting the files through my commercial encoder (Pavtube based on FFMPEG) while increasing brightness seems to allow to make a file that looks right and with no detail lost in the areas that were brightened.

 

[shikun]

can someone please reupload? multiupload link shows a blank page uzzled:

 

[IdolFun]

can someone please reupload?

http://www.akiba-online.com/forum/showpost.php?p=1906485&postcount=883

 

[no__One]

When I got those crash as you, it's always about memory pb. (too much Threads). I think you are right, you are investigating in the good direction.
An Expert (Mr. Vitreous) could prove or disprove your hypothesis.

Ps: Coud you give your rig spec ? Without it, it's difficult to tell something.

 

[Vitreous]

When I got those crash as you, it's alawys about memory pb.

Actually I gave CMoar a power-user tip that I haven't mentioned in this thread:

- Get the Large Address Aware tool in the zip at the end of this post
- Run the tool and browse for this executable:
Your-meguIVit-Location\Sandbox\meguIV\1.0.1.1\Virtual\MODIFIED\@SYSDRIVE@\meguIV\MeGUI\tools\mencoder\mencoder.exe

- Check the "Large Address Aware" box and press Save (only need to do this once unless you extract the MeguIVit sandbox again)
- Now in the Custom Processing tab shown in Cmoar's picture above you can uncheck Auto by "Cache Memory" and enter a larger number, maybe 1200 or 1400.
- Higher values allows more threads and/or more extreme settings. Too high and it will crash (probably not more than 1600, but it's hard to say)

BTW CMoar, reduce your OS font-size back to normal to make the dialog more readable.

 

[no__One]

Hi Mr. CmoarIdols,
You do not ask me anything and if you think my remarks inappropriate, simply ignored them.
Since meguIVit0.21, it is impossible for me to encode with (post-processing error by lack of sleep...) pre-rendering activated.
Every time, I get a crash at one time or another.
Since this problem, I unchecked the box (post-processing error by lack of sleep...) 'pre-rendering' and no more crash.
For the rest, My Custom Processing params are very close to yours.
I hope this information will be of any help.

 

[Vitreous]

no__One: there is no "post-processing" box. What box are you talking about? Do you mean the "Add pre-rendering job" check box maybe? Switching that off might be worth a try CMoar, but it's a completely different memory situation then, so you may need to tweak threads.

CMoar: A single tip - don't use Placebo. It's more of a joke than a usable setting, it just switches everything on regardless of whether that's a good idea or not. I dearly wish I had never added that setting, it gives me endless people complaining here and over at d9. **It's not even the most accurate setting when using source match!!!** The most accurate setting is Preset:VerySlow + SourceMatch:2 + Boost + NoiseProcessing: about 0.5 (for clean content like idol vids). The x264 developers have the same opinion about their Placebo: don't use it, use Very Slow.

 

[no__One]

Absolutely, I meant "pre-rendering" ...
I need, once again, sleep:notagain:
I return to my cave to get some rest.:tea:

 

[SamKook]

A single tip - don't use Placebo. It's more of a joke than a usable setting, it just switches everything on regardless of whether that's a good idea or not. I dearly wish I had never added that setting, it gives me endless people complaining here and over at d9. **It's not even the most accurate setting when using source match!!!** The most accurate setting is Preset:VerySlow + SourceMatch:2 + Boost + NoiseProcessing: about 0.5 (for clean content like idol vids). The x264 developers have the same opinion about their Placebo: don't use it, use Very Slow.

Really? When I checked the settings one by one, it seemed like a good idea to use it(both for qtgmc and x264) and it does produce a smaller file than very slow. I only change the TR2 setting.
But since I mostly encode JAV instead of idols, I don't usually use source match since the source isn't usually good enough in my opinion.

 

[Vitreous]

Completely different story without source match. Placebo QTGMC makes much more sense without source match although it is over-smooth (but your change to TR2 corrects for that - still smoother than source match though). Without source match will also give a more temporally stable image which x264 can take advantage of.

Source match is designed to capture the highest detail - it increases vertical detail considerably if your source is good. Many junior idol videos have that detail (JI content is increasingly higher quality). But source match works best without the extreme temporal work of Placebo. So in summary, if you've got the detail then Very Slow + SourceMatch + etc. is as far as I would recommend, if not then Placebo without Source Match as long as you set TR2=1 or 2. Actually it's much, much more complex than that, especially if you are using QTGMC manually, but that's a reasonable generalization...

Effectively SourceMatch and standard QTGMC are two different directions for deinterlacing. With SourceMatch says "I want the source exactly, maybe a little sharpening but nothing more", without SourceMatch says "I want a smooth and sharp image (which might be quite different to the source)". I'm attempting to make these concepts more clearly separated in QTGMC 4.0 (which might, maybe, perhaps, be released before the next millennium).

 

[SamKook]

Good to know, thanks.