x264 encoding RGB, doesn´t work as intended.

[zerowalker]

Okay, i have searched all around, and i can´t find much information regarding my problem.

It´s probably not a real "problem" and just a cause of me not knowing what to do.

Well to simply put it, i got a Avisynth script, it´s RGB at the end (tried RGB32 and 24, 24 is less wrong though).

I then encode it with Megui, but i set x264 command line to:

--input-csp rgb --output-csp rgb

And the RGB32 will look like, 6 small half windows of the movie, but it got green lines making it just look weird.

RGB24 will pretty much be the same, but without the green lines, just different colors on each window.

(all windows play back the move, they look the same, except colors etc)


Now i am pretty sure i have done this way back when RGB was introduced to x264, but somehow i can´t make it work.

I444 and the rest works as expected though.


And a bonus question:

Is it possible to encode Lossless with x264 10bit on normal sources (8bit).

I am pretty sure it´s not possible, as it´s converting to 10bit, but i may be wrong.

http://i41.tinypic.com/2emo311.png

Thanks!

[kabelbrand]

You are using an AviSynth source but isn't input-csp just for use with RAW video? Have you tried without it? output-csp is ok...

[zerowalker]

Didn´t work, it only made the 6 half windows to 1 big half window, with green lines (on both 24 and 32 rgb)

[kabelbrand]

Hmmm. Maybe a stupid question but does the source video look alright if you open the AviSynth script in VirtualDub or some player?

[zerowalker]

Yes it does. Can´t put the finger on what´s wrong;S

[osgZach]

I've been wondering about this myself. I've never been able to produce a "normal" watchable video file when trying to encode RGB game captures, to RGB H.264 streams. Although in my case I'm not getting half-images, I am getting full images, but they are all scaled down, and represented by 6 sets of smaller images which occupy the actual resolution space of the video. The large primary image in the set contains a black and white image, then below that are 4 smaller sections which look like the Black variety, and White variety, Infrared images.

I've get this result regardless of wheather I'm trying it via Avisynth (meGUI) or using the CLI encoder directly.
Must be getting a command wrong somewhere....?

I've uploaded an attachment JPG showing what it looks like.

[zerowalker]

I do get that as well.
There are 2 versions to get.

One is with RGB24, other RGB32. Both produces different results, and none are correct.

All seem to be many different windows that are smaller and messed up in colors.

I am pretty sure i did manage to produce an RGB correctly like 2 years ago, but either something has changed or i am doing something wrong.
And i have tried it so many times, it´s quite frustrating.

[poisondeathray]

RGB works ok here

Maybe something wrong with your x264 binary, or your decoder, or something else wrong with your setup ?

[osgZach]

No matter what I try it seems x264 always converts the output format to YUV 4:4:4 as well...

[poisondeathray]

No matter what I try it seems x264 always converts the output format to YUV 4:4:4 as well...

How are you making that determination ?

If it's something like mediainfo, it reports incorrectly ; Check with something like ffmpeg

[osgZach]

Yeah I was getting bogus info from Media Info (why don't they fix that?)

FFprobe confirmed RGB (bgr)

Interesting outcome as well.. I went and got an x264 binary from http://www.x264.nl/x264_main.php instead of using the one MeGUI ships with (why is theirs so much smaller anyway?) and I now get the proper output, the video is watchable..

And... this is what a proper RGB looks like, I guess :)
http://pics.oldskoolgames.com/forums/doom9/AceCombatRGB5.mkv

[zerowalker]

So the Megui one doesn´t work?
I should work, i think it´s only smaller cause it skips some internal libraries, but it shouldn´t effect RGB in any way.

LAV Filter is my decoder btw, and the video linked works properly as well.

[LoRd_MuldeR]

Yeah I was getting bogus info from Media Info (why don't they fix that?)

You could help them by submitting a patch or at least filing a detailed bug report. Complaining usually doesn't change anything ;)

(why is theirs so much smaller anyway?) and I now get the proper output, the video is watchable..

Different compiler versions/settings used in the build process and/or different versions of external libraries linked in and/or certain external libraries enabled/disabled.

[osgZach]

Zero, no idea why MeGUI's binaries won't work but its always been that way apparently. Give the one I linked a try and see what happens.

I was actually amazed at how high I could jack up CRF with RGB.

[osgZach]

You could help them by submitting a patch or at least filing a detailed bug report. Complaining usually doesn't change anything ;)



Different compiler versions/settings used in the build process and/or different versions of external libraries linked in and/or certain external libraries enabled/disabled.

I couldn't code my way out of a paper bag unfortunately, but this has apparently been such a long standing issue I am honestly surprised they haven't fixed it. Surely those more vocal than I, have complained to them already

[zerowalker]

osgZach, will do.

Wait does the CRF work differently between colorspaces?
As 20CRF which let´s say looks ugly with YV12, should still look ugly with RGB, except that the video should be quite bigger and colors more accurate, the Luma detail should be the same.

[osgZach]

I guess the short answer is "yes" ? For whatever reason, you can use higher CRF values. Look at the encode flags on the video I posted, I would never try to encode YV12 with a CRF that high I can tell you that :p

[zerowalker]

True, but can´t say the video looks that good either, would have to compare.
But CRF 30 should be extremely bad, especially on lower resolution, DVD would be unwatchable to put it harshly.

[LoRd_MuldeR]

this has apparently been such a long standing issue I am honestly surprised they haven't fixed it. Surely those more vocal than I, have complained to them already

If all users reason like that, nobody will ever submit a proper bugreport and this issue might remain unrecognized by the developer ;)

BTW: MediaInfo supports a zillion of container, audio and video formats, each of which has dozens of properties. So it's not that surprising that bugs, which effect a specific property of a specific video format, can get overlooked. Also it's not like storing RGB data is the most common use of H.264.

[vivan]

Wait, how mediainfo is wrong? RGB in H.264 stored as 4:4:4 YUV with "GBR" matrix (Y = G, Cb = B, Cr = R).

[LoRd_MuldeR]

You are right, MediaInfo actually does show the correct info:
Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3.0
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Writing library : x264 core 140 r2377 1ca7bb9
Matrix coefficients : RGB

It may not be intuitive, but technically it is correct. So much about that :rolleyes:

[raffriff42]

Does x264 do anything different when compressing the U and V channels vs. the Y channel (psy masking, lowlights vs. highlights etc?) What about in RGB mode - are all channels treated like Y channels, or...?

[LoRd_MuldeR]

Does x264 do anything different when compressing the U and V channels vs. the Y channel (psy masking, lowlights vs. highlights etc?) What about in RGB mode - are all channels treated like Y channels, or...?

It's probably treated just like YUV 4:4:4:


commit ffc41542d73811dffbe5814a23edda65db0e6aea [revision 2018]
Author: xvidfan <xvidfan@freenet.de>
Date: Wed Jun 22 18:46:14 2011 -0700

RGB encoding support
Much less efficient than YUV444, but easy to support using the YUV444 framework.

Couldn't find any commits that mention RGB-specific optimizations...

[raffriff42]

That's logical: if you really need RGB (as opposed to YUV444) you should be using --qp 0 anyway. I mean, seriously.

[zerowalker]

Should it be reported to MeGUI that their x264 builds are wrong as it can´t support RGB?
And if so, does anyone know what´s wrong, cause internal libraries shouldn´t be the cause, though again it may be a decoding issue instead of an encoding issue.
Meaning that when x264 reads the RGB data, it fails and isn´t shown correctly.

Not the decoding of the x264, but the decoding Before it´s encoded.

[LoRd_MuldeR]

x264 uses libswscale for color-space handling. Maybe the "MeGUI" build was compiled without that one?

[zerowalker]

Perhaps, that would explain it, as it really does seem to by some handling,conversion going wrong, as RGB24 and RGB32 is different, and i don´t think they really should be different in the Video,
Both look the same, though i am not that familiar with this, but isn´t it only the Alpha that differs, which shouldn´t matter in a Video anyway?

[the_weirdo]

Actually, x264 builds of MeGUI were built with libswscale support. And if both input and output are RGB, I think the color-space conversion via libswscale won't be used. You can check MeGUI logs to see if there's a color-space conversion by x264 or not.

[osgZach]

Not intuitive and often confusing to the layman at any rate

[zerowalker]

Okay i can´t get RGB working with the builds here either : http://www.x264.nl/x264_main.php

It´s messed up as always

[osgZach]

Let me guess.. You are still trying to do it through MeGUI?

There is something in MeGUI which is screwing up the image, because I tried with those binaries as well and they still came out messed up.

Something to do with avspmod maybe ?


BUT those binaries work fine if you use the CLI directly ;)

If you absolutely need to use Avisynth to run filters before hand, I suggest saving out to a lossless (in RGB no less!) and then running that AVI through x264 via CLI.
I'd advise to use Lagarith though, x264 didn't want to read my UTCodec renders.

[zerowalker]

Hmm you are a master in disguise;)

Weird, i thought MeGUI didn´t do anything except, check the script and status,logs etc.
Really needs to get fixed, has anyone done a bug report on it?

EDIT:

btw, if you convert it to YCgCo in Avisynth, what settings do you use in x264?
As it´s supposed to be a very capable colorspace, though it seems a bit complicated to use when it comes to colormatrix.

[osgZach]

Actually, x264 builds of MeGUI were built with libswscale support. And if both input and output are RGB, I think the color-space conversion via libswscale won't be used. You can check MeGUI logs to see if there's a color-space conversion by x264 or not.


So I have no idea what MeGUI thinks its doing.


edit: well that was weird, the quotes done puked.

[vivan]

btw, if you convert it to YCgCo in Avisynth, what settings do you use in x264?
As it´s supposed to be a very capable colorspace, though it seems a bit complicated to use when it comes to colormatrix.complex? :)
--colormatrix YCgCo

[zerowalker]

I tried that, but when decoded it has the wrong colors, though then again it looks wrong in Avisynth aswell after converting, green is pink and stuff like that.

[vivan]

Have you used madVR for rendering? It's the only renderer that supports YCgCo colorspace.

[osgZach]

At any rate, I've filed a bug report so we'll see what comes of it or if its something we are doing wrong.

If you can at least confirm for me using the CLI directly with those binaries works that will be good to know

[osgZach]

The solution to get MeGUI working with RGB for now, seems to be disabling 64-bit encoding. I just tested it and it worked