Converting Fraps footage with x264, output file's colors become brighter?

[mzso]

Originally Posted by mzso

Now, I'm going try to figure out how to pass --input-range PC to ffmpeg.

But apparently I can't. Tried using "-x264opts " but it didn't work.
Didn't find anything else, besides -color_range in the ffmpeg help.

[mzso]

Originally Posted by jq963152

No, AFAIK both is lossless, but not 100% sure.

AFAIK the only difference is:

"Force lossless RGB capture (may be slower)" disabled = YCbCr 4:2:0

and:

"Force lossless RGB capture (may be slower)" enabled = RGB (which is 4:4:4)

So, yeah, YCbCr 4:2:0 is not really "lossless", because you loose chroma resolution (4:2:0 vs. 4:4:4). But you are very likely to loose that anyway when you are encoding with x264.

You can encode in YCbCr 4:4:4 and RGB with x264 to keep the chroma resolution, see:

http://forum.doom9.org/showthread.php?t=165415

But the resulting video probably (and unfortunately) will not play back on anything else than PC software.

Well I prefer actual lossless and no subsampling. Since I don't use anything else for playback than a computer the last is a non issue for me. Only if I knew how to get ffmpeg/libx264 to keep the range untouched...

[mzso]

Originally Posted by jq963152

Then you explicitly have to tell x264 to encode without subsampling.

x264 defaults to --output-csp i420 (4:2:0 chroma subsampling).

So, if you want to encode without subsampling then you need to use either --output-csp i444 or --output-csp rgb, otherwise it will encode with 4:2:0 chroma subsampling AFAIK.

See:

http://mewiki.project357.com/wiki/X2...ngs#output-csp

ffmpeg doesn't accept "-x264opts output-csp=rgb" or "-x264opts output-csp=i444" it seems. Not sure about the syntax, so far it seemed this syntax is right because it accepted "-x264opts fullrange=on", only it produced the same result.

I get: "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height"

[poisondeathray]

If you want to encode i444 with ffmpeg , use -pix_fmt yuv444p . I don't think libx264 in ffmpeg can use RGB24 or BGR24 (RGB fraps is detected by current ffmpeg builds as bgr24)

BUT the problems you're going to have is the RGB=>YUV conversion will use Rec601 (it will not be subsampled chroma, but colors will be off because of wrong matrix - should be 709)

ffmpeg does have a colormatrix filter, but the quality is noticably lower than doing it in avisynth
-vf colormatrix=bt601:bt709

(In avisynth you can use ConvertToYV24(matrix="Rec709")

Another option might be to do the colorspace conversions in vapoursynth pipe to ffmpeg

[osgZach]

Originally Posted by jq963152

With the "Force lossless RGB capture (may be slower)" checkbox enabled, HandBrake messes up the colors. But with that checkbox disabled (YV12), HandBrake is quite perfect at converting FRAPS YV12 to x264.

I really would like to know why HandBrake is so good at converting FRAPS YV12.

I still don't know how to convert FRAPS YV12 with AviSynth as good as HandBrake does.

Because when you convert from RGB to YV12 you lose color information. If you record in YV12, most tools won't need to convert because its already YV12. If you judge a YV12 video file produced by fraps, compared to a YV12 H264 you naturally would not see much of a difference, except in the case of the Color Matrix changing for w/e reason.

So, if Handbrake isn't changing the color levels (PC<->TV etc) then that is why it works so well for you.

Its why I loathe Youtube and other streaming services that do not support 4:2:2 or 4:4:4 Color sampling.

When I do game captures I compare the actual game on-screen (PNG/BMP screenshots, etc) to the video file produced during capturing. YV12 always looks horrible to me. Something somewhere, even with tweaking always ends up looking either washed out or oversaturated - i.e it probably takes more effort than I am willing to learn how to precisely convert colors from RGB - > YV12.

So I just gave up on capturing game footage.

[mzso]

Originally Posted by poisondeathray

If you want to encode i444 with ffmpeg , use -pix_fmt yuv444p . I don't think libx264 in ffmpeg can use RGB24 or BGR24 (RGB fraps is detected by current ffmpeg builds as bgr24)

BUT the problems you're going to have is the RGB=>YUV conversion will use Rec601 (it will not be subsampled chroma, but colors will be off because of wrong matrix - should be 709)

ffmpeg does have a colormatrix filter, but the quality is noticably lower than doing it in avisynth
-vf colormatrix=bt601:bt709

(In avisynth you can use ConvertToYV24(matrix="Rec709")

Another option might be to do the colorspace conversions in vapoursynth pipe to ffmpeg

Well, it still doesn't seem to be right... When I change to PC levels it's still light.

Here's the exact command line:

ffmpeg -i "infile1.avi|infile2.avi" -pixel_format rgb24 -acodec copy -scodec copy -vcodec libx264 -g 30 -pix_fmt yuv444p -vf colormatrix=bt601:bt709 -preset slower -crf 20 -x264opts fullrange=on "teszt.mkv"

Here's the output (interrupted after a few seconds): https://docs.google.com/file/d/0Byfd...it?usp=sharing

[osgZach]

Looks fine to me? Plenty of dark and shadowy in that.

Is your monitor calibrated?

[poisondeathray]

Can you post a few frames of the fraps source file (vdub, video => direct stream copy ) or I suppose you can cut it with ffmpeg -vcodec copy -an with -ss (start time) and -t (duration)

There are major, major quality issues with ffmpeg's colormatrix filter - it looks like doesn't work in full chroma resolution. Even when working with YV12 (4:2:0) material , quality is noticably lower than avisynth's colormatrix (I don't know why, it was ported from avisynth)

[osgZach]

To further that. Why not try running it through x264 instead of ffmpeg. I didn't want to say anything earlier, as I assumed it was just preference. But if there are quality issues with ffmpeg in this situation, then yeah try another encoder.

[mzso]

Originally Posted by poisondeathray

Can you post a few frames of the fraps source file (vdub, video => direct stream copy ) or I suppose you can cut it with ffmpeg -vcodec copy -an with -ss (start time) and -t (duration)

There are major, major quality issues with ffmpeg's colormatrix filter - it looks like doesn't work in full chroma resolution. Even when working with YV12 (4:2:0) material , quality is noticably lower than avisynth's colormatrix (I don't know why, it was ported from avisynth)

Here's 1 sec. https://docs.google.com/file/d/0Byfd...it?usp=sharing

It's still 33MB...

[mzso]

Originally Posted by osgZach

To further that. Why not try running it through x264 instead of ffmpeg. I didn't want to say anything earlier, as I assumed it was just preference. But if there are quality issues with ffmpeg in this situation, then yeah try another encoder.

Well, I'm unfamiliar with that one, but it can't convert full AV files, can it?

EDIT:
Well, it seems be working for the 1 sec sample with this CL:

x264 --preset slow --crf 20 --output-csp rgb --keyint 30 -o out.mkv in.mkv

[mzso]

New problem.
The image turns blue quite often.
"Brown" wooden door:

[mzso]

Had to downgrade to an older build of x264. It seems like the never ones can't decode fps1 properly just like the never builds of ffmpeg...

[mzso]

It seems like I get some blue stuff anyways. I give up.

[STaRGaZeR]

Originally Posted by mzso

Had to downgrade to an older build of x264. It seems like the never ones can't decode fps1 properly just like the never builds of ffmpeg...

What do you mean when you say they can't decode fps1 properly?

[mzso]

Originally Posted by STaRGaZeR

What do you mean when you say they can't decode fps1 properly?

Whole bunch of errors while decoding. Huge gaps in the encoded file. Didn't bother to investigate the errors, since I knew ffmpeg enough to just try older builds.

[STaRGaZeR]

Originally Posted by mzso

Whole bunch of errors while decoding. Huge gaps in the encoded file. Didn't bother to investigate the errors, since I knew ffmpeg enough to just try older builds.

If you mean that the decoded fraps stream is not constant frame rate, completely destroying motion when encoding it afterwards, then yes, I'm afraid you're screwed. Some time ago I had a discussion with the ffmpeg developer that changed this but he didn't listen when I said that by doing what he did he'd make the decoder useless for anything else than playing the original Fraps file in a player.

I even made a patch to correct it but he didn't accept it. LAV Filters included it until a big ffmpeg update some time ago, but nev hasn't included it since. I use it with my own builds thou. I can give you both the patch and a LAV Filters build, so you can compile an updated ffmpeg or LAV with a working (and multithreaded) fraps decoder.

[mzso]

Originally Posted by STaRGaZeR

If you mean that the decoded fraps stream is not constant frame rate, completely destroying motion when encoding it afterwards, then yes, I'm afraid you're screwed. Some time ago I had a discussion with the ffmpeg developer that changed this but he didn't listen when I said that by doing what he did he'd make the decoder useless for anything else than playing the original Fraps file in a player.

I even made a patch to correct it but he didn't accept it. LAV Filters included it until a big ffmpeg update some time ago, but nev hasn't included it since. I use it with my own builds thou. I can give you both the patch and a LAV Filters build, so you can compile an updated ffmpeg or LAV with a working (and multithreaded) fraps decoder.

Interesting, I didn't hear new removing a fix before. Anyway. I don't do patching and compiling, and ffmpeg failed at transcoding fullrange too.

Did you experience anything like the blueishness (the second one)?

[Snowknight26]

Originally Posted by mzso

Did you experience anything like the blueishness (the second one)?

http://trac.ffmpeg.org/ticket/75

Though I submitted that bug to ffmpeg over 2 years ago, it seems as if it was only just fixed recently.

[mzso]

Originally Posted by Snowknight26

http://trac.ffmpeg.org/ticket/75

Though I submitted that bug to ffmpeg over 2 years ago, it seems as if it was only just fixed recently.

That's "awesome". They fixed that meanwhile rendered the decoder useless, with the other thing. -_-

Edit:
Ouch, that's very recent. (17 hours ago) I was thinking of trying to find a build where both's fixed.