Ideal for fraps?

[Reino]

Fraps' decoders? Plural??

Originally Posted by aufkrawall

The other way, using the FRAPS Decoder for an YV12 source, sounds good, but there hasn't been any proof yet that this actually works.

Huh?! What are you talking about? Perhaps I don't understand correctly, but with Fraps' normal recording method, it creates Fraps-file in YV12 (yuvj420p to be precise) and with AVISource() in Avisynth, or by opening the FPS1(yuvj420p)-file directly with VirtualDub, Fraps' own decoder is used.

[aufkrawall]

Originally Posted by CoRoNe

Huh?! What are you talking about? Perhaps I don't understand correctly, but with Fraps' normal recording method, it creates Fraps-file in YV12 (yuvj420p to be precise) and with AVISource() in Avisynth, or by opening the FPS1(yuvj420p)-file directly with VirtualDub, Fraps' own decoder is used.

Sorry, I spread wrong information (in right assumption ).
Somehow the results of simply open the file in VD and open it in VD via AVS script differed in the past. But now it has worked.
I can't say what went wrong.

Will try feeding x264 with a proper script in which the official FRAPS decoder is used...

[Reino]

Originally Posted by aufkrawall

Will try feeding x264 with a proper script in which the official FRAPS decoder is used...

For your FPS1(bgra) videos that wouldn't be a problem, but I think we can all agree now, after the whole discussion in this thread, for FPS1(yuvj420p) the use of FFmpegSource is much more preferable than AVISource (Fraps' own decoder through VFW)!

[poisondeathray]

Originally Posted by CoRoNe

For your FPS1(bgra) videos that wouldn't be a problem, but I think we can all agree now, after the whole discussion in this thread, for FPS1(yuvj420p) the use of FFmpegSource is much more preferable than AVISource (Fraps' own decoder through VFW)!

Not necessarily. There are pros/cons

Is the colorspace conversion worse , or is banding from levels conversion worse?

ffms2 outputs full range Y'CbCr - if you scale to "legal" range you will get quantization (look at the histogram, and in shadows)

(or if you use smoothlevels instead of levels, it will smoothen out, but then at the expense of more dithering noise - that's why the bitrate required is higher)

[Reino]

You're right, I should've said: FFmpegSource for quality, AVISource for speed.

I noticed it too, the higher required bitrate with SmoothLevels, but I can perfectly live without it, especially because it's very slow.

Although MediaWiki says "this is the same as ColorYUV(levels="PC->TV")", I noticed when I compared level histograms for
Levels(0, 1, 255, 16, 235, coring=false)
ColorMatrix(mode="rec.709->rec.601", clamp=0)
and
ColorYUV(levels="PC->TV")
ColorMatrix(mode="rec.709->rec.601", clamp=0)
I noticed there's still a slight difference. Because I'm not all that into this technical colour stuff, which one would you prefer?

Since you're the one who suggested to use SmoothLevels and ColorMatrix in a thread I linked to on the previous page, would you mind answering the couple of questions (at the end of the post) I have about these filters?

[poisondeathray]

- chroma=100 is already the default value according to SmoothAdjust's readme, so you can leave it out safely. But then the output in the end is a tiny bit different. Strange?

At the time it smoothlevels chroma settings was 0-100, now it's scaled to 0-200. You will have to try it out and see for yourself , some things have changed. If I have some time later I will revisit it

- When I remove clamp=0, the output stays the same, while the default value is 3 according to ColorMatrix's readme. What does this setting actually do and is it really

for colormatrix? If you have a full range video, clamp will clamp to Y'16-235 and CbCr16-240 , but if you've already scaled to "legal" levels before that, of course it will do nothing

- I don't think I even have to ask, but if quality is more important, SmoothLevels is recommended I guess? (png screenshots are quite a bit larger compared to ColorYUV at least)

quality is subjective . There are pros/cons to either

[Gavino]

Originally Posted by CoRoNe

Although MediaWiki says "this is the same as ColorYUV(levels="PC->TV")", I noticed when I compared level histograms for
Levels(0, 1, 255, 16, 235, coring=false)
ColorMatrix(mode="rec.709->rec.601", clamp=0)
and
ColorYUV(levels="PC->TV")
ColorMatrix(mode="rec.709->rec.601", clamp=0)
I noticed there's still a slight difference.

There are slight differences in chroma between the two.
Levels() on a YUV clip scales chroma by the same ratio as luma, so the call above does not map chroma [0, 255] exactly to [16, 240], but ColorYUV(levels="PC->TV") does.

[Reino]

Thanks you two!

Originally Posted by poisondeathray

If you have a full range video, clamp will clamp to Y'16-235 and CbCr16-240 , but if you've already scaled to "legal" levels before that, of course it will do nothing

Funny, there still appears to be an extremely small difference (luma Y=0 1pixel in height ) when I compare level histograms for:
ColorYUV(levels="PC->TV")
ColorMatrix("rec.709->rec.601", clamp=0)
vs.
ColorYUV(levels="PC->TV")
ColorMatrix("rec.709->rec.601")

P.s. I noticed something weird in AvsP:
When I tried to compare 'clamp=0' vs. no clamp-entry with SmoothLevels() on 2 different tabs, refreshing the preview of either tab constantly shows a slightly different levels histogram. Removing one of the tabs with the SmoothLevels() entry, and the levels histogram becomes static again upon refreshing.
To reproduce, just open 2 tabs, copy-paste the exact same script with SmoothLevels() there and F5 the preview.
Just thought I'd mention.

[Reino]

For anyone interested, I did some speed tests with AVSMeter:

AVSMeter v1.17 by Groucho2004
AviSynth 2.60, build:May 25 2011 [19:58:41]

Number of frames:             375
Length (h:m:s.ms):       00:00:15.000
Frame width:                  640
Frame height:                 480
Framerate:                     25.000 (25/1)
Progressive:                  Yes
Colorspace:                  RGB32* / YV12**


AVISource (Fraps's own decoder)			- fps (avg): 79.24 *

FFMpegSource2
ConvertToRGB("PC.709")				- fps (avg): 55.02 *

FFMpegSource2
Levels(0,  1, 255, 16, 235, coring=false)
ColorMatrix("rec.709->rec.601", clamp=0)	- fps (avg): 90.08 **

FFMpegSource2
ColorYUV(levels="PC->TV")
ColorMatrix("rec.709->rec.601", clamp=0)	- fps (avg): 97.10 **

FFMpegSource2
SmoothLevels(preset="pc2tv", chroma=100)
ColorMatrix("rec.709->rec.601", clamp=0)	- fps (avg):  4.96 **

Performed on an ancient AMD Athlon XP3200+ (WinXP SP3)

[Reino]

Although it's great to know now that with Avisynth the colour-issue can be fixed, I'd like to get back at my original post; trying to do the same thing directly with x264.exe or ffmpeg.exe, without the help of Avisynth. I've done quite some testing with ffmpeg and x264 and these are my findings.

For ffmpeg I used the following command-line:

ffmpeg.exe -i "<path>\FPS1(yuvj420p)_sample.avi" -pix_fmt yuv420p -color_primaries 5 -color_trc 5
-colorspace 5 -an -vcodec libx264 -qp 28 -x264opts force-cfr "<path>\FPS1(yuvj420p)_sample(ffmpeg).mkv"

and for x264(JEEB):

x264.exe -q 28 --range tv --colorprim bt470bg --transfer bt470bg --colormatrix bt470bg --input-range pc
--force-cfr --acodec none -o "<path>\FPS1(yuvj420p)_sample(x264_ffms).mkv" "<path>\FPS1(yuvj420p)_sample.avi"

_________ffmpeg____________________x264

- First of all; despite the new FFmpegSource 2.17 being incorporated in the rev2164 JEEB build of x264.exe I used, I'm still being shown ffms [info]: color matrix: undef. Seems detecting color-matrices in Fraps files is for FFMS a bit more difficult than for other formats.
- Both encoders here produce the same file. For the range conversion -pix_fmt yuv420p and --range tv --input-range pc seem to do the same thing. Strange it's not possible to enter --output-csp yuv420p for x264. (--input-csp yuvj420p --output-csp i420 doesn't work. Neither does --vf resize:csp=i420)
P.s. I've read several times on the internet, including PhrostByte's post, about this so-called command --fullrange on/off command. Could this command perhaps be replaced by --range tv --input-range pc, because x264 returns an error.
- Both encoders here produce the same file, except that only the file produced by x264 actually has the "Color primaries", "Transfer characteristics" and "Matrix coefficients" entries in it. Back in dec 2010 these parameters didn't even appear to be working for ffmpeg. But in the end it doesn't matter, because neither MPC-HC, nor FFmpegSource (in Avisynth) seem to respect these entries.
Apart from these colorimetric settings, I haven't found any commands that do the luma conversion directly, in either ffmpeg or x264.

So to summarize: PC->TV no problem with ffmpeg and x264, but for BT.709->BT.601 you really need Avisynth (at the moment).

[Zerofool]

Originally Posted by CoRoNe

Could this command perhaps be replaced by --range tv --input-range pc, because x264 returns an error.

It IS replaced.

[TheFluff]

Originally Posted by CoRoNe

Although it's great to know now that with Avisynth the colour-issue can be fixed, I'd like to get back at my original post; trying to do the same thing directly with x264.exe or ffmpeg.exe, without the help of Avisynth. I've done quite some testing with ffmpeg and x264 and these are my findings.

For ffmpeg I used the following command-line:

ffmpeg.exe -i "<path>\FPS1(yuvj420p)_sample.avi" -pix_fmt yuv420p -color_primaries 5 -color_trc 5
-colorspace 5 -an -vcodec libx264 -qp 28 -x264opts force-cfr "<path>\FPS1(yuvj420p)_sample(ffmpeg).mkv"

and for x264(JEEB):

x264.exe -q 28 --range tv --colorprim bt470bg --transfer bt470bg --colormatrix bt470bg --input-range pc
--force-cfr --acodec none -o "<path>\FPS1(yuvj420p)_sample(x264_ffms).mkv" "<path>\FPS1(yuvj420p)_sample.avi"

**********ffmpeg************************x264

- First of all; despite the new FFmpegSource 2.17 being incorporated in the rev2164 JEEB build of x264.exe I used, I'm still being shown ffms [info]: color matrix: undef. Seems detecting color-matrices in Fraps files is for FFMS a bit more difficult than for other formats.
- Both encoders here produce the same file. For the range conversion -pix_fmt yuv420p and --range tv --input-range pc seem to do the same thing. Strange it's not possible to enter --output-csp yuv420p for x264. (--input-csp yuvj420p --output-csp i420 doesn't work. Neither does --vf resize:csp=i420)
P.s. I've read several times on the internet, including PhrostByte's post, about this so-called command --fullrange on/off command. Could this command perhaps be replaced by --range tv --input-range pc, because x264 returns an error.
- Both encoders here produce the same file, except that only the file produced by x264 actually has the "Color primaries", "Transfer characteristics" and "Matrix coefficients" entries in it. Back in dec 2010 these parameters didn't even appear to be working for ffmpeg. But in the end it doesn't matter, because neither MPC-HC, nor FFmpegSource (in Avisynth) seem to respect these entries.
Apart from these colorimetric settings, I haven't found any commands that do the luma conversion directly, in either ffmpeg or x264.

So to summarize: PC->TV no problem with ffmpeg and x264, but for BT.709->BT.601 you really need Avisynth (at the moment).

Fraps does not have a metadata flag to indicate the colormatrix used; hence FFmpeg reports it as undefined and thus FFMS2 reports the same. When reading H.264, those metadata flags you mention do exist and FFMS2 does pass them on to the client application. Whether the client application actually does something useful with them completely depends on said client application. In Avisynth you can examine what FFMS2 thinks about the source color matrix by saying

subtitle(string(FFCOLOR_SPACE))

after calling FFVideoSource.

In both of your example cases you explicitly flag the output with metadata indicating it as bt470bg, but the input is known to be bt709. In neither case do you instruct swscale to actually do any color matrix conversions (AFAIK you have to do this by hand, neither application will do it automatically; JEEB's patched x264 might, but only if the source colorimetry is definitely known (i.e. not undef)). To my knowledge, neither ffmpeg nor x264 expose any settings that will let you manually override the input/output colorimetry, so your conclusion is essentially correct.

FFMS2 will respect colorimetry metadata and tell swscale about it as appropriate, but that only affects processing if you tell it to output a non-default colorspace or resolution, since it'll try to avoid rescaling the image if possible. In the Fraps case the input is YV12, which can be output directly to both Avisynth and x264, so no rescaling will take place (x264 will not use FFMS2 for rescaling anyway though; it uses swscale directly).

[Reino]

@ Zerofool: Ah, ok thanks! Didn't know the repository was on the videolan website. Google didn't return any useful results at least.

@ TheFluff: Since Fraps has no colormatrix metadata as you mentioned, I take it the value returned by FFCOLOR_SPACE (value 2, which if I'm correct corresponds with ColorMatrix()'s source=2 (Rec.601) parameter) is just as unreliable as ffms in x264, because the Fraps file is BT.709 afterall.
But interesting nonetheless, because while reading the FFmpegSource wiki I was already wondering how to utilize these variables. Thanks.

I'm still pretty new to this. The input is indeed BT.709, but I've read bt470bg corresponds with BT.601 (which is the desired output of course), or isn't it? So that why I used these 3 color parameters. These aren't part of swscale? As I've mentioned already, I haven't found any other parameters/commands to do luma conversions, so when you say "In neither case do you instruct swscale to actually do any color matrix conversions", I'm beginning to wonder if I've overlooked something .

[edit]1 more Avisynth question:
To match colors as closely as possible, which one would be preferred?

ColorYUV(levels="PC->TV")
ColorMatrix(dest=2, clamp=0)

or

ColorMatrix(dest=2, clamp=0, inputFR=true)

Levels histogram of the latter more resembles the one from Fraps' VFW decoder...[/edit]

[TheFluff]

Originally Posted by CoRoNe

@ TheFluff: Since Fraps has no colormatrix metadata as you mentioned, I take it the value returned by FFCOLOR_SPACE (value 2, which if I'm correct corresponds with ColorMatrix()'s source=2 (Rec.601) parameter) is just as unreliable as ffms in x264, because the Fraps file is BT.709 afterall.

No, the documentation is wrong. The numerical values returned are the same as in the MPEG specs, and thus the same as the ones used in FFmpeg. The API documentation has the correct explanation:

Originally Posted by FFMS2 API documentation

enum FFMS_ColorSpaces {
    FFMS_CS_RGB         = 0,
    FFMS_CS_BT709       = 1,
    FFMS_CS_UNSPECIFIED = 2,
    FFMS_CS_FCC         = 4,
    FFMS_CS_BT470BG     = 5,
    FFMS_CS_SMPTE170M   = 6,
    FFMS_CS_SMPTE240M   = 7,
};

Identifies the color coefficients used for a YUV stream. The numerical constants are the same as in the MPEG-2 specification.
Some of these are specified or aliased in a number of places. Most importantly:
"BT709" (ITU-T Rec. 709) is equivalent to ITU-R BT1361, IEC 61966-2-4 xvYCC709 and SMPTE RP177 Annex B;
"BT470BG" (ITU-R BT. 470, also known as ITU-T Rec. 601) is equivalent to ITU-R BT601-6 625, ITU-R BT1358 625, ITU-R BT1700 625 PAL & SECAM and IEC 61966-2-4 xvYCC601;
"SMPTE170M" (SMPTE standard 170 M) is functionally the same as BT470BG, and is furthermore equivalent to ITU-R BT601-6 525, ITU-R BT1358 525, and ITU-R BT1700 NTSC.

The number 2 thus means "unspecified".

Originally Posted by CoRoNe

I'm still pretty new to this. The input is indeed BT.709, but I've read bt470bg corresponds with BT.601 (which is the desired output of course), or isn't it? So that why I used these 3 color parameters. These aren't part of swscale? As I've mentioned already, I haven't found any other parameters/commands to do luma conversions, so when you say "In neither case do you instruct swscale to actually do any color matrix conversions", I'm beginning to wonder if I've overlooked something .

bt470bg is equivalent to BT.601, yes. But the parameters you use are for setting metadata flags only; they do not trigger a color conversion or make x264 use swscale to change the image in any way. The input will be passed through unchanged, but the output file will have metadata flags telling decoders that the file uses bt470bg, while in fact it's using BT.709 like the input did.

[Reino]

Originally Posted by TheFluff

The number 2 thus means "unspecified".

"Matches the values used by ColorMatrix() as input." on the Avisynth mediawiki is quite confusing then.

Originally Posted by TheFluff

bt470bg is ... input did.

I know these only add metadata, but it seems atm these parameters are the only ones available that have anything to do with luma conversion. Are you saying; swscale is capable to do a direct BT.709->BT.601 conversion, but x264 hasn't correctly incorporated it yet and thus can't provide proper parameters for it?
P.s. Funny then. Although categorized as a "Video Usability Info"-parameter, --range should in fact be an "Input/Output"-parameter, because it directly influences the video instead of only adding metadata.

[TheFluff]

Originally Posted by CoRoNe

"Matches the values used by ColorMatrix() as input." on the Avisynth mediawiki is quite confusing then.

That's what I said, the documentation is wrong. I've fixed it in SVN, but I don't maintain the Avisynth mediawiki page and I don't know who does. IMO it's bad to have the documentation duplicated there since it's easy to miss updates of the source documentation. I think that page should just link to the official documentation instead.

Originally Posted by CoRoNe

I know these only add metadata, but it seems atm these parameters are the only ones available that have anything to do with luma conversion. Are you saying; swscale is capable to do a direct BT.709->BT.601 conversion, but x264 hasn't correctly incorporated it yet and thus can't provide proper parameters for it?

Correct. I think x264 actually does use the relevant parameters internally in some cases (especially in JEEB's patched builds), but it hasn't exposed any command line parameters for manually overriding them.

Originally Posted by CoRoNe

P.s. Funny then. Although categorized as a "Video Usability Info"-parameter, --range should in fact be an "Input/Output"-parameter, because it directly influences the video instead of only adding metadata.

Are you sure it really does that?

[poisondeathray]

The FFMBC branch has a colormatrix filter . I think it's actually from avisynth, as vf_colormatrix.c in the libavfilter folder suggests

http://code.google.com/p/ffmbc/

Convert HD YUV BT709 to SD BT601 and vice versa

But I tested it in earlier builds, and it wasn't working properly. Not sure if it was a n00b compilation error on my part or if it's working now

I think the ffmbc syntax was
-vf colormatrix=bt709:bt601
-vf colormatrix=bt601:bt709

Maybe it can be merged into x264 / ffmpeg ?

[sneaker_ger]

Originally Posted by TheFluff

Are you sure it really does that?

http://git.videolan.org/gitweb.cgi?p...e239ebfca53bf6

[Reino]

Yes, and since the input is already correctly being detected as full-range, I've noticed --input-range pc isn't needed. Instructing x264 with --range tv is enough.

I'm sorry to bother you again with Avisynth, but to match colors as closely as possible, apart from SmoothLevels, which one would you prefer?

ColorYUV(levels="PC->TV")
ColorMatrix(dest=2, clamp=0)
or
ColorMatrix(dest=2, clamp=0, inputFR=true)

Speed-wise it doesn't matter at all, but the levels histogram of the latter more resembles the one from Fraps' VFW decoder. o_O

[Reino]

Feeding x264 an Avisynth-script.
I'm still not sure which one of these two I would choose:

FFMpegSource2
ColorYUV(levels="PC->TV")
ColorMatrix()				- fps (avg): 94.74

FFMpegSource2
ColorMatrix(clamp=0, inputFR=true)	- fps (avg): 88.53

Although I can't see any differences, histograms are rather different.

FFMpegSource2								FFMpegSource2
ColorYUV(levels="PC->TV")		    histogram almost		Levels(0,  1, 255, 16, 235, coring=false)
ColorMatrix()				--> identical to:		ColorMatrix()

FFMpegSource2								FFMpegSource2
ColorYUV(levels="PC->TV")						SmoothLevels(preset="pc2tv", chroma=100)
ColorMatrix(clamp=0, inputFR=true)	--> histogram resembles:	ColorMatrix()