Ideal for fraps?

[Zerofool]

Could this command perhaps be replaced by --range tv --input-range pc, because x264 returns an error.
It IS replaced (http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=e047b3c475cd42b6647397a244e239ebfca53bf6).

[TheFluff]

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 (http://ffmpeg.zeranoe.com/builds/) 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) (http://x264.fushizen.eu/):
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"http://www.ld-host.de/uploads/thumbnails/423b1922871377542d33edfd5e3aaa2f.png (http://www.ld-host.de/show/423b1922871377542d33edfd5e3aaa2f.png) http://www.ld-host.de/uploads/thumbnails/f490614d2aed92412b5ba4dbe1ea8501.png (http://www.ld-host.de/show/f490614d2aed92412b5ba4dbe1ea8501.png)
**********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 (http://ffmpeg-users.933282.n4.nabble.com/BT-709-colorspace-conversion-td3084346.html). 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 :confused:.

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...

[TheFluff]

@ 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 (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-api.html) has the correct explanation:
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".

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 :confused:.

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]

The number 2 thus means "unspecified"."Matches the values used by ColorMatrix() as input." on the Avisynth mediawiki (http://avisynth.org/mediawiki/FFmpegSource) is quite confusing then.

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]

"Matches the values used by ColorMatrix() as input." on the Avisynth mediawiki (http://avisynth.org/mediawiki/FFmpegSource) is quite confusing then.
That's what I said, the documentation is wrong. I've fixed it in SVN (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html), 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.

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.

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]

Are you sure it really does that?

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=e047b3c475cd42b6647397a244e239ebfca53bf6

[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.53Although 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()

[Reino]

libswscale has nothing to do with Avisynth and I'm really wondering, in that thread you linked to, what aufkrawall means by "Original".
Upon using this forum's search function for something else, I accidentally stumbled upon "Making FRAPS video from FFMS2 match AviSource? (http://forum.doom9.org/showthread.php?t=157941)".

This topic is about FPS1(yuvj420p) only, not FPS1(bgra).
I can now understand the output of AVISource (the original Fraps decoder through VFW) is actually wrong. The source is YUV with PC-levels and while the Fraps decoder performs a PC to TV levels conversion, which in any case has to take place in the end, the colourspace conversion to RGB32 is completely unnecessary.
FFVideoSource's output is YUV and if you want to feed it to x264, which also requires YUV, letting loose ConvertToRGB(matrix="PC.709") on FFVideoSource would involve an unnecessary colourspace conversion; YUV->RGB->YUV.
I think we can all agree now, for FPS1(yuvj420p), that Fraps's own decoder is faulty and it's better for FFMS to handle it. The next question is of course, what then? Let Avisynth handle the color conversions:
FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
...
ColorYUV(levels="PC->TV")
ColorMatrix()
...or...
SmoothLevels(preset="pc2tv")
ColorMatrix()
...or...
ColorMatrix(clamp=0, inputFR=true)Which one is preferable, I don't know. That's still something I'm trying to find out.

...or let ffmpeg handle the color conversions:
--------------------------------------------------------------
The FFMBC branch has a colormatrix filter.
...
Maybe it can be merged into x264 / ffmpeg ?At the moment it's merged into ffmpeg, not x264 (yet).
--------------------------------------------------------------
ffmpeg.exe -i "D:\FPS1(yuvj420p)_sample.avi" -pix_fmt yuv420p -vf colormatrix=bt709:bt601
-an -vcodec libx264 -qp 28 "D:\FPS1(yuvj420p)_sample.mkv"
So it's essential to know how "Original" is decoded. Also..."With Avisynth it always fails"...how? With what script?

[aufkrawall]

libswscale has nothing to do with Avisynth and I'm really wondering, in that thread you linked to, what aufkrawall means by "Original".

How the YV12 Fraps record looks like with original Fraps decoder (converted to RGB).

[Reino]

How the YV12 Fraps record looks like with original Fraps decoder (converted to RGB).Exactly as I feared.

[aufkrawall]

Wouldn't it be better to take a lossless (BMP/PNG/etc.) direct screenshot of a game and to consider that being "original" for comparison purposes?
I compared a lossless screenshot with the video and it was correct how Fraps decoder treats the video.
Would be surprising if it wasn't that way, wouldn't it? ;)

[aufkrawall]

I can't say where exactly the problem lies.
When using the Fraps decoder while playing a video, everything is fine. When using it in conversion chain, somehow something goes wrong.

Edit: Just with Fraps YV12 video, of course. RGB is fine.

[Reino]

Unhelpful and unrelated, at least... I'm talking about version 5 only.

Ok...

Fraps has 2 recording modes:
-YUV mode, FPS1(yuvj420p)
-RGB mode, FPS1(bgr24) ("Force lossless RGB capture (may be slower)" enabled)

My system is really old (about time I bought a new pc :rolleyes:) and doesn't support the RGB mode very well, but I've read Fraps's own decoder (AVISource() in Avisynth) correctly decodes FPS1(bgr24).
For YUV mode I quote Fraps's author:...so I sent an email to FRAPS' author about 6 months ago. He just now finally got back to me with this:Dear Cory,

Thanks for your message and I apologize for the very long delay in getting back to you.
In YUV mode Fraps will use 709 coefficients and generate the full range 0-255 (i.e. it's not clamped between 16-235).

Regards,
Rod Maher

It seems one of FRAPS or libav or me is doing something wrong.So FPS1(yuvj420p), in addition to being full range (quote ffmpeg (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/pixfmt.h): "planar YUV 4:2:0, 12bpp, full scale (JPEG)"), also uses the Rec.709 luma coefficients (http://www.glennchan.info/articles/technical/rec709rec601/rec709rec601.html). FFMS2 (https://code.google.com/p/ffmpegsource/) in Avisynth also confirms that. We need yuv420p (tv range) using Rec.601 however, or in other words: we need a PC.709-->Rec601 conversion. Fraps's own decoder already does this, BUT also performs a colorspace-conversion to RGB32 for reasons I don't know. That's why Fraps's own decoder's output is controversial.

For the PC.709-->Rec601 conversion you could use ffmpeg:
ffmpeg.exe -i "D:\FPS1(yuvj420p)_sample.avi" -pix_fmt yuv420p -vf colormatrix=bt709:bt601 -qp 0 -an "D:\FPS1(yuvj420p)_sample.mkv"
...or you could let Avisynth plugins do the job:
FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
...
ColorMatrix (http://bengal.missouri.edu/~kes25c/)(clamp=0, inputFR=true)
...or...
ColorYUV(levels="PC->TV")
ColorMatrix()
...or...
SmoothLevels (http://forum.doom9.org/showthread.php?t=154971)(preset="pc2tv")
ColorMatrix()


Now which one to choose? I've uploaded some levels- and luma-histogram screenshots for comparison:

Levels

AVISource_________________FFMS2+ConvertToRGB(PC.709)__FFMS2+ColorMatrix(clamp0,inputFR)
http://www.ld-host.de/uploads/thumbnails/d1035ba590a0a38dcb72c90f84ed10ba.png (http://www.ld-host.de/uploads/images/d1035ba590a0a38dcb72c90f84ed10ba.png)__http://www.ld-host.de/uploads/thumbnails/b0bd72426f4f99dbdf78c99f04e4b9d3.png (http://www.ld-host.de/uploads/images/b0bd72426f4f99dbdf78c99f04e4b9d3.png)______http://www.ld-host.de/uploads/thumbnails/ddd63631d64da695c65daf9fc5c1d49a.png (http://www.ld-host.de/uploads/images/ddd63631d64da695c65daf9fc5c1d49a.png)
FFMS2+ColorYUV(lev.PC-TV)____ffmpeg_avi+pix_fmt________FFMS2+SmoothLevels
+ColorMatrix()_________________+clrmtrx+qp0______________(pc2tv)+ColorMatrix()
http://www.ld-host.de/uploads/thumbnails/1f005fc81ac7cd43d496287b13a0f154.png (http://www.ld-host.de/uploads/images/1f005fc81ac7cd43d496287b13a0f154.png)__http://www.ld-host.de/uploads/thumbnails/65675b083be8260c95bde9600cc46fac.png (http://www.ld-host.de/uploads/images/65675b083be8260c95bde9600cc46fac.png)__http://www.ld-host.de/uploads/thumbnails/5a3042db87c346b87df5ab4952589b8e.png (http://www.ld-host.de/uploads/images/5a3042db87c346b87df5ab4952589b8e.png)

Luma

AVISource_________________FFMS2+ConvertToRGB(PC.709)__FFMS2+ColorMatrix(clamp0,inputFR)
http://www.ld-host.de/uploads/thumbnails/904373e245e1f5d4b9e59910e71039bf.png (http://www.ld-host.de/uploads/images/904373e245e1f5d4b9e59910e71039bf.png)__http://www.ld-host.de/uploads/thumbnails/226272ba171242a5c009a4c1ea5aa159.png (http://www.ld-host.de/uploads/images/226272ba171242a5c009a4c1ea5aa159.png)______http://www.ld-host.de/uploads/thumbnails/0e4d77c2698855c982bc009778c835f3.png (http://www.ld-host.de/uploads/images/0e4d77c2698855c982bc009778c835f3.png)
FFMS2+ColorYUV(lev.PC-TV)____ffmpeg_avi+pix_fmt________FFMS2+SmoothLevels
+ColorMatrix()_________________+clrmtrx+qp0______________(pc2tv)+ColorMatrix()
http://www.ld-host.de/uploads/thumbnails/bd153ec1a178bac54c9dd81569ac0f6e.png (http://www.ld-host.de/uploads/images/bd153ec1a178bac54c9dd81569ac0f6e.png)__http://www.ld-host.de/uploads/thumbnails/0b2e6735e7a4e89151fd9e89989fcd78.png (http://www.ld-host.de/uploads/images/0b2e6735e7a4e89151fd9e89989fcd78.png)__http://www.ld-host.de/uploads/thumbnails/47ef080ca5d3790ed7ad4f2fe314244b.png (http://www.ld-host.de/uploads/images/47ef080ca5d3790ed7ad4f2fe314244b.png)

With the levels screenshots you can see right away that FFMS2+ColorMatrix(clamp0,inputFR) resembles AVISource a lot and that FFMS2+ColorYUV(lev.PC-TV)+ColorMatrix() is almost identical to ffmpeg's method.

With the luma screenshots the first noticeable thing is AVISource and its extreme colorbanding (or is it something else? I'm no expert) on the mudflaps. Also very noticeable is the amount of detail (I don't know how that technique is called) with FFMS2+SmoothLevels(pc2tv)+ColorMatrix() (especially noticeable in the clouds). No wonder a higher bitrate is required.
Here FFMS2+ColorYUV(lev.PC-TV)+ColorMatrix() and ffmpeg's method are again almost identical. When you then compare one of these 2 to FFMS2+ColorMatrix(clamp0,inputFR), I personally have to give the edge to the latter. The color transition halfway the rear-screen and the 'middle-grey' cloudy part (halfway the Sparco-banner and the top of the image) is a bit smoother.

Of course this is the analysis of 1 single frame, so perhaps FFMS2+ColorMatrix(clamp0,inputFR) could generate very different results on other material, I don't know. Nevertheless, for FPS1(yuvj420p) I think I'll stick to FFMS2 + ColorMatrix(clamp=0, inputFR=true) in Avisynth for the moment.

I've also seen the libswscale thread, but you do realize, jq963152, that FFMS2's SWScale filter only does colorspace conversions, which is exactly what you don't want!

[Reino]

http://www.ld-host.de/uploads/thumbnails/9f5c01b2cf170cc3bf914e79ee0f93c2.png (http://www.ld-host.de/uploads/images/9f5c01b2cf170cc3bf914e79ee0f93c2.png)

Why?

[Bloax]

And here I'm promptly going to wonder why all this is so necessary, if you need a histogram and everything to see the differences.

I'm also going to wonder if you guys really like to store uncompressed RGB footage, because anything that's even remotely lossy would obviously be too different from the uncompressed RGB source.
Of course what you're kind of doing here would help in case your workspace has a lot of generation loss (or whatever the term is), but that's an entirely different issue, which should primarily be fixed at the source.

[Reino]

jq963152, no I don't. I consider Fraps's encoder the 'original'. It's the decoder that's messed up.
And fyi, I recorded that video at "Half-size". It's the 1st frame extracted with AvsPmod.

Bloax, up untill now we've only been talking about FPS1(yuvj420p).

[Reino]

I'm partly colorblind, so I do need those histograms, because I really can't spot any differences otherwise. I can only see a very slight difference in sharpness around the ferns, so you shouldn't exaggerate. For all we know Handbrake runs a sharpening-filter by default.
My old computer can't handle recording at "Full-size".
But anyway, unless Handbrake's author ever finds this thread, I think it's best you ask on the Handbrake forum (https://forum.handbrake.fr/). I'm satisfied with my analysis, so I'll let this rest now.

I do hope though x264 will get the colormatrix videofilter some day, just like ffmpeg.

[Reino]

Since when is framerate an issue if all you want to do is capturing a single frame for comparison purposes :rolleyes:;)?I recorded this video 20 months ago for other purposes (https://www.youtube.com/watch?v=wLyl-vxFgVk).

[TheSkiller]

My old computer can't handle recording at "Full-size".Why don't you simply reduce the game's render resolution for the time of the recording then? Much better than sticking to a high resolution and using Fraps' "half size" option. :)


Personally, I gave up with with Fraps' non-RGB mode due to the hassle with it. I want 100% lossless captures anyway, so RGB is the way to go since YV12 is of course 4:2:0 color subsampled and therefore not lossless.

[TheSkiller]

I know – but that should be a hard disk drive issue as the data that needs to be saved is much more in RGB mode. :)

That means if the game you're trying to record is on the same physical HDD that you're recording to, you're creating yourself a bottleneck – especially in lossless RGB.

CPU wise I'm quite sure there should be no noteable difference between Fraps' non-RGB and lossless RGB mode. In theory at least, RGB mode should actually consume less CPU cycles because there's no RGB-YV12 conversion needed.

Just trying to give you some tips. ;) I see these very same problems with so many Fraps-captured videos on YouTube.

If you can, record not to the same hard disk drive where the game is installed. Set the game to an appropriate render resolution for the time of the recording.

[TheSkiller]

Well, it's about capturing at 1080p60 :cool::D;).Well...and that's the problem. ;) :D

But let me give you a hint: YouTube doesn't allow framerates higher than 30 for videos with 1080 lines (if you upload such video anyway, YouTube will simply drop every other frame to stay below or at 30 fps). That means, you could just record with 30 fps in the first place.

If you need a higher framerate than 30 on YouTube you need to stick with (Edit: according to my own tests) 480p or lower (720p does not go above 30 fps currently either).


And at least according to some other users tests, even a RAM drive appears to somewhat struggle with 1080p60 and "Force lossless RGB capture (may be slower)" option enabled :(;).No wonder, people are expecting too much.
The data rate of lossless RGB 1920x1080 with a framerate of 60 is 356 MB/s (that's Megabytes, not Mbit).
Albeit Fraps applies some lossless on-the-fly compression (think of it like ZIPing), it's still an insane amount of data.

[aufkrawall]

No wonder, people are expecting too much.
The data rate of lossless RGB 1920x1080 with a framerate of 60 is 356 MB/s (that's Megabytes, not Mbit).
Albeit Fraps applies some lossless on-the-fly compression (think of it like ZIPing), it's still an insane amount of data.
My Samsung 830 256GB with SATA3 can handle it, but unfortunately it gets filled up rather quick, as you may imagine. :D

@CoRoNe: Could you please post the exact script with range/matrix conversion via ColorMatrix?

[Reino]

You mean this one?
FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
ColorMatrix(clamp=0, inputFR=true)That's all?...you might ask. In case anyone's confused, it isn't necessary to fully specify everything:
ColorMatrix(source=0, dest=2, clamp=0, inputFR=true, outputFR=false)
Leaving them out has the same result in our case, because these are the default values for those settings anyway. But, for users with a multi-core/threaded cpu, the threads setting could be useful.

P.s.
- 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 necessary?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 :)
For...
FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
ColorYUV(levels="PC->TV")
ColorMatrix()...I can fully understand poisondeathray's post. clamp=0 (no clipping), or clamp=3 (pre and post clipping) doesn't make a difference, because ColorYUV already did the scaling. BUT, how come clamp=3 with inputFR=true suddenly does make a difference?! From the readme I would think clamp sort of does the same thing as inputFR=true, outputFR=false. What exactly is this setting for? And how to explain the sudden difference with inputFR=true?

[sneaker_ger]

1. Make sure you haven written "ColorMatrix" instead of "ColorMartix"
2. Make sure you actually have the plug-in installed/loaded: http://bengal.missouri.edu/~kes25c/ColorMatrixv25.zip

[sneaker_ger]

Ooh :eek:, so it doesn't come with MeGUI by default and needs to be installed separately :eek:?

Now that you mention it, I think it actually does. Should be in the tools\avisynth_plugin folder.

I don't know if it is official, but this should be close:
http://web.missouri.edu/~kes25c/

[Reino]

The colours are correct when using HandBrake.Are they?!
I wanted to see for myself the magic Handbrake does, so I installed it today and converted a 15sec FPS1(yuvj420p)-file (which is PC.709 by default) to a lossless MKV[H.264]-file.
Nowhere in Handbrake I could find range- and luma coefficient conversion related settings, so I was really interested in the outcome.
I fired up AvsPmod again and compared the 1st frame again. It turns out the 1st frame of Handbrake's MKV[H.264]-file is identical to:
FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
ColorMatrix(dest=0, clamp=0, inputFR=true)
Or Rec709 (limited/tv-range with Rec.709 luma coefficients) in other words. So Handbrake only does the range conversion.

[egr]

I did some testing with Fraps 3.4.7.13808, and uh...*cough*

Colin McRae Rally 04 and 2005 (both forced RGB, or bgra):
http://www.ld-host.de/uploads/thumbnails/b98549ff3383087ab24717c2f2d6e6fa.png (http://www.ld-host.de/show/b98549ff3383087ab24717c2f2d6e6fa.png) http://www.ld-host.de/uploads/thumbnails/b8bf75280fac211f313f61b74cda0510.png (http://www.ld-host.de/show/b8bf75280fac211f313f61b74cda0510.png)

Tactical Ops AOT (bgra, yuvj420p(!) and yuvj420p (Fraps 2.9.9.8086)):
http://www.ld-host.de/uploads/thumbnails/3599e73c10dbc6b4e8499151a51d21c5.png (http://www.ld-host.de/show/3599e73c10dbc6b4e8499151a51d21c5.png) http://www.ld-host.de/uploads/thumbnails/613cf657a92bbf9e8209f3c6054a7e5f.png (http://www.ld-host.de/show/613cf657a92bbf9e8209f3c6054a7e5f.png) http://www.ld-host.de/uploads/thumbnails/50db3858d0c32d5518c4ef35a1a3f880.png (http://www.ld-host.de/show/50db3858d0c32d5518c4ef35a1a3f880.png)

Vertically interlaced video streams, omg lol! xD
I've done some quick Google searching, and although I found some websites about people complaining about blue-ish vertical lines, I haven't found someone with the exact same issue. Unless anyone here has encountered something similar, I'm going to blame my ancient computer. Freaking weird!

As you can see I don't have experience with opening "normal" FPS1(bgra) videos in Avisynth yet, sorry. But you're probably recording only in bgra, aren't you? Because otherwise, for yuvj420p, you would've also had the same results with FFVideoSource + ConvertToRGB(matrix="PC.709") compared to AVISource.

So, is it RGB24 or BGRA for when you have the "Force lossless RGB capture (may be slower)" checkbox checked? If it matters, I run version 3.5.99 Build 15622.... I know if that isn't checked then the colour space is just YUVJ420P, both which has(or inside) REC.709 that defines it....?

Just trying to figure out what colour space profile to use with Axiom using FFV1 codec...since there are so many there none of which have flavour text explaining them......and the frontend itself hasn't yet been able to just *auto-detect* the correct colour space and just apply the correct configuration for it.....

I just realized you got dead links...hah...

[StainlessS]

CoRoNe Not on-line since 26 Dec 2018.

[egr]

CoRoNe Not on-line since 26 Dec 2018.

oh....well I hope he's not dead...........:scared: