Ideal for fraps?

[Boogerlad]

Hey, I'm working on trying to convert fraps footage to x264+aac in mp4 container using just the command line, x264.exe, avisynth, propriety nero aac encoder and yamb to mux video and audio stream. First off, are these the right tools for the job? Are there better alternatives?

However, with avisynth, I noticed there's many ways to input the video. There's avisource and directshowsource. Which one do I use?
I think you also need ConvertToYV12() at the end of the script because x264 likes that and fraps is rgb32 right? Is there much quality loss?

**Forgive me if this is in the wrong section. Mods move if needed.**

[Boogerlad]

anyone use avisynth and fraps?

[Robert Martens]

I've had excellent results with a similar setup for some Audiosurf videos I've recorded (for example: http://www.youtube.com/watch?v=Q7or1c6UdxA), and though that's only been to stitch split file captures together, I've got no reason to think more complex processing would present a problem.

AVISource works quite well for me, the Fraps codec is Video for Windows if I'm not mistaken. If you have some need to access the files through DirectShow, there's always ffdshow.

I honestly don't know what difference there would be between using ConvertToYV12() in AviSynth and letting x264 handle the conversion. In either case the quality drop is barely perceptible. Comparing my original Audiosurf recordings and an x264 lossless YV12 version side by side I can see a slight drop in sharpness (I cannot emphasize the word "slight" enough), but then again the game is running with no antialiasing, and I'm comparing individual frames, so the difference is that much more noticeable. I wouldn't worry about it, especially when the images are in motion.

As far as compression, I've been mostly using Staxrip (http://forum.doom9.org/showthread.php?t=102652) for my videos, though lately I've been practicing doing it by hand (command line x264, BeHappy for audio, mkvtoolnix or Yamb to mux everything). Perfectly suitable tools, I'd say. Your workflow sounds fine to me.

[Blue_MiSfit]

AVISource is the way to go here. The FRAPS codec has a perfectly good VFW decoder, and it works fine. I've used it plenty of times :)

I'd do the YV12 conversion in AviSynth, like this:

ConvertToYV12(matrix="PC.709")

This will use the Rec709 standard, but also use the full PC range (0-255). If you don't want full range, then change the matrix to "Rec709" and you will get standard "TV" levels (16-235).

There certainly is a quality loss when you go to 4:2:0 chroma subsampling from RGB. The difference is mathematically huge (hence why it's used in the first place!!!), but perceptibly not too bad. Our eyes are fairly terrible at receiving color :)

I'd use the AviSynth plugin SoundOut to get audio out of your AVI and into a WAV. I'd then use eac3to to encode this WAV to AAC. eac3to uses Nero's AAC encoder, which performs very well.

[Boogerlad]

thanks for the help guys. Also, if there are multiple files since fraps saves in non opendml avi files, will appending them cause a loss in audio-video sync?

[Blue_MiSfit]

It shouldn't, especially since FRAPS writes PCM audio, which is inherently CBR.

Derek

[PhrostByte]

FRAPS has two encoding modes: RGB and full range YV12. But it only decodes to RGB. If you're encoding as YV12, you should use FFVideoSource to prevent another colorspace conversion.

And yes, you can append multiple FRAPS videos without any problems. I do it all the time :)

[Boogerlad]

Would I use to + or ++ operator to join files? I'm thinking aligned splice?
http://avisynth.org/mediawiki/Splice

[Boogerlad]

wait, so if you check "force lossless rgb capture (may be slower)" than it records in rgb32, else in yv12? If so, is avisynth even necassary unless you want to do other processing? Could you just feed x264.exe the raw fraps footage?

[PhrostByte]

Yes, you can give x264 (if compiled with ffms2) raw FRAPS footage without avisynth in between. keep in mind that the YV12 will be full range, though.

[Boogerlad]

I added the info() to the end of the avisynth script to both the "force lossless rgb capture (may be slower)" checked and not checked videos. Both appear to be rgb32? I know it's probably because of the vfw decoder, but how did you guys figure out it was yv12?

[PhrostByte]

I added the info() to the end of the avisynth script to both the "force lossless rgb capture (may be slower)" checked and not checked videos. Both appear to be rgb32? I know it's probably because of the vfw decoder, but how did you guys figure out it was yv12?

The official FRAPS codec always decodes to RGB, even when the file is actually the YV12 format. If you use FFVideoSource it will decode directly as full-range YV12.

I know it is YV12 because I've talked to the developer.

[Boogerlad]

here's the script for the video with the "force lossless rgb capture (may be slower)" checked along with a screenie of info
FFVideoSource("C:\Users\Alex\Desktop\encoding\rgb.avi")
info()
http://i735.photobucket.com/albums/ww352/boogerlad/rgb.png

here's the script for the video with the "force lossless rgb capture (may be slower)" unchecked along with a screenie of info
FFVideoSource("C:\Users\Alex\Desktop\encoding\yv12.avi")
info()
http://i735.photobucket.com/albums/ww352/boogerlad/yv12.png
both say rgb24? Doesn't ffvideosource use ffmpeg to decode instead of the installed codecs?

[Boolsheet]

both say rgb24? Doesn't ffvideosource use ffmpeg to decode instead of the installed codecs?

Fraps uses YV12 at higher resolutions like HD.

[Reino]

Although my question isn't Avisynth + Fraps related in the first place, I don't think a new thread would've been necessary.

Lately, especially in the LAV Filters and FFDShow Development threads, there's been quite some discussion going on about proper Fraps support. For testing sake, I've tried to compress a Fraps video directly with the x264 video codec, without the intervention of Avisynth (which I would normally use). Obviously without additional settings the colours get screwed up, but in addition to that, instead of expecting x264's normal output colourspace, yuv420p, x264 puts out the yuvj420p colourspace, which Fraps appears (http://frapsforum.com/threads/fix-dark-fraps-videos.758/) to record in (http://peter.corrosivetruths.org/2011/09/03/fraps-videos-are-too-dark/).

To get proper colours, I know of 2 ways to accomplish that:
- Letting Fraps itself decode the avi-file with AVISource() in Avisynth (Fraps through VFW).
- Letting FFmpegSource (http://avisynth.org/mediawiki/FFmpegSource) decode the avi-file with FFVideoSource() and ConvertToRGB(matrix="PC.709") in Avisynth. Examining the picture closely shows you this is the equivalent of the FFDShow Video Decoder with forced RGB32 output, "High quality YV12 to RGB32 conversion", "ITU-R BT.709" and "Full Range (0-255)".

This of course brings Avisynth in the picture and I'm trying to do without it. I tried to find x264-settings equivalent to ConvertToRGB(matrix="PC.709"), which I thought would be well represented. I've tried several variations with --input-csp, --output-csp, --input-range, as well as --colormatrix (which in the end I realized doesn't affect the video-stream directly), but I just couldn't get the desired result.

Does anyone know if x264 has the necessary settings to do this job, or is Avisynth at the moment the only way to succeed?
Again, for me this is for testing sake. I can always use Avisynth, but I'm just curious if the colour-conversion could be done without.


P.s. I'm using the Avisynth GUI AvsP and it shows me the sample video I used here has 375 frames in total. However, when I then Import() the avs-file (with only AVISource() in it) in a new file, it suddenly has 376 frames.
The same with x264: Having the avi-file as input directly, with either --demuxer ffms or --demuxer avs(!), results in 375 frames being encoded. Having the avs-file as input, results in 376 frames being encoded. Can someone explain this?

P.s.2. Although a bit off-topic, I noticed that, even though the original Fraps avi has a constant frame-rate, x264 (with the default ffms demuxer) tells me the input video-stream is vfr. --force-cfr can fix that of course, but is that normal?

[PhrostByte]

If you have x264 with ffms2 built in, you can just use the fraps .avi directly and specify "--colormatrix bt709 --fullrange on". With this, all supporting players should show correct colors. Of course, not all players support it ;)

As far as I know there is no way to convert colorspaces with only x264. When using Avisynth, you should use ColorMatrix rather than ConvertToRGB as it'll be faster and should retain better quality.

[aufkrawall]

When using Avisynth, you should use ColorMatrix rather than ConvertToRGB as it'll be faster and should retain better quality.
Maybe this plug-in fixes the issue I'm describing here:
http://forum.doom9.org/showthread.php?t=164042

But it seems to work only with YV12, not YV24. With YV24 it looks this way:
http://www.ld-host.de/uploads/thumbnails/407ff14c3d1a83758f318816166bcfbf.png (http://www.ld-host.de/show/407ff14c3d1a83758f318816166bcfbf.png)

Is there anything I can do about it?
Here's my script:
LoadCPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\ffms2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\colormatrix.dll")
FFVideoSource("trine.avi", colorspace="RGB32")
ConvertToYV24(matrix="Rec601")
ColorMatrix(mode="Rec.601->Rec.709")

[Bloax]

I actually think JEEB's (?) builds would be the simplest way.
You can get them here. (http://x264.fushizen.eu/)

Because on the only file I did encode with it, it actually encoded the audio to AAC.
And the container can easily be switched.

[TheFluff]

FRAPS seems to use its own custom color matrix for converting RGB to YV12 and back again. ConvertToRGB32(matrix="PC.709") does, AFAIK, not match the original colors exactly.

x264 does not, as far as I know, provide an option for setting the SWScale colormatrix flags that would force a conversion using Rec.709 coefficients and fullrange output.

Furthermore, the conversion from RGB (your video card's output buffer) to YV12 (FRAPS) and back to RGB (Avisynth) is not lossless.

P.s.2. Although a bit off-topic, I noticed that, even though the original Fraps avi has a constant frame-rate, x264 (with the default ffms demuxer) tells me the input video-stream is vfr. --force-cfr can fix that of course, but is that normal?

FFMS2 input is always considered VFR. CFR is strictly a special case of VFR where all frames have the same duration. FFMS2 doesn't really bother doing anything with this special case, so all input is always considered VFR. If you know and can certify that the input is 100% CFR, you can use --force-cfr.

[richardpl]

Actually latest FRAPS decoder from FFmpeg is VFR and from Libav is CFR.

[aufkrawall]

For converting FRAPS YV12 video, the simplest solution is to use Handbrake (nightly):
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=9157271&postcount=14
It may not be perfect up to 100%, but very close to it.
With FRAPS YV12 you already have a huge quality loss, so it doesn't matter IMHO.

[Reino]

@aufkrawall: You're right. These 2 pngs differ 1504 bytes in filesize. If filesizes would be the same, the video streams would be identical imo.

@TheFluff and richardpl: Thanks for the information. But TheFluff, screenshots from, on the one hand Avisynth output (with ConvertToRGB32(matrix="PC.709")), and on the other hand FFDShow output (with settings mentioned in my initial post), are identical in filesize. So FFDShow isn't matching the exact colours either.

@Bloax:
Color matrix detection with ffms/lavf.x264.exe:
ffms [info]: color matrix: undef
Although it seemed promising, it's not really helpful atm.

With --video-filter resize:csp=rgb at least full-range is applied.

[smok3]

ffmpeg fraps.avi to x264.mp4 is always getting me 100 fps with no Indikation that the input is considered VFR, clues?

color seems correct
[scale @ 0x7fb230416660] w:1280 h:1024 fmt:yuvj420p -> w:1280 h:1024 fmt:yuv420p flags:0x4

[richardpl]

Your ffmpeg must be very recent to experience this.

Read this for more info: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/140807/match=fraps

[smok3]

ffmpeg version N-37510-g8c48652 with Duclair libvpx & x264 0.120.2146 bcd41db

example log:
ffmpeg -i /Volumes/raid0/battlefield_heroes_fraps/BFHeroes_2011-08-07_00-33-21-87.avi -pix_fmt yuv420p -an -vcodec libx264 -preset medium -crf 21 -threads 0 -r 25 /Volumes/raid0/battlefield_heroes_fraps/BFHeroes_2011-08-07_00-33-21-87.xCRF21fraps.1328728071.video.mp4
ffmpeg version N-37510-g8c48652 Copyright (c) 2000-2012 the FFmpeg developers
built on Feb 2 2012 22:02:52 with clang 3.0 (tags/Apple/clang-211.12)
configuration: --prefix=/Volumes/tempdisk/sw --enable-gpl --enable-libx264 --enable-libvpx --cc=clang --enable-runtime-cpudetect
libavutil 51. 37.100 / 51. 37.100
libavcodec 54. 0.102 / 54. 0.102
libavformat 54. 0.100 / 54. 0.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 61.100 / 2. 61.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 6.100 / 0. 6.100
libpostproc 52. 0.100 / 52. 0.100
Input #0, avi, from '/Volumes/raid0/battlefield_heroes_fraps/BFHeroes_2011-08-07_00-33-21-87.avi':
Duration: 00:00:29.99, start: 0.000000, bitrate: 523430 kb/s
Stream #0:0: Video: fraps (FPS1 / 0x31535046), yuvj420p, 1280x1024, 100 fps, 100 tbr, 100 tbn, 100 tbc
Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s
[buffer @ 0x1037158a0] w:1280 h:1024 pixfmt:yuvj420p tb:1/1000000 sar:0/1 sws_param:
[buffersink @ 0x103716440] auto-inserting filter 'auto-inserted scale 0' between the filter 'src' and the filter 'out'
[scale @ 0x103716840] w:1280 h:1024 fmt:yuvj420p -> w:1280 h:1024 fmt:yuv420p flags:0x4
[libx264 @ 0x7f888882b800] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
[libx264 @ 0x7f888882b800] profile High, level 3.2
[libx264 @ 0x7f888882b800] 264 - core 120 r2146 bcd41db - H.264/MPEG-4 AVC codec - Copyleft 2003-2011 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=12 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=21.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to '/Volumes/raid0/battlefield_heroes_fraps/BFHeroes_2011-08-07_00-33-21-87.xCRF21fraps.1328728071.video.mp4':
Metadata:
encoder : Lavf54.0.100
Stream #0:0: Video: h264 (![0][0][0] / 0x0021), yuv420p, 1280x1024, q=-1--1, 25 tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (fraps -> libx264)
Press [q] to stop, [?] for help
frame= 22 fps= 0 q=0.0 size= 0kB time=00:00:00.00 bitrate= 0.0kbits/s dup=0 drop=31
cut some lines here
frame= 751 fps= 18 q=-1.0 Lsize= 37120kB time=00:00:29.96 bitrate=10149.8kbits/s dup=0 drop=1386


and this is what youtube thinks about it
http://www.youtube.com/watch?v=BWS1Ij_1pnY

[richardpl]

Sorry but that revision points that you are using Libav.
And Libav fraps decoder does not support multi-threading.

[smok3]

Sorry but that revision points that you are using Libav.
And Libav fraps decoder does not support multi-threading.

where did you get multi-threading, aren't we talking about CFR vs VFR?

a question: how to get nicely blured motion when going from 100fps to 25fps with ffmpeg only? (possibly with added dedup before that)

tryed:
tinterlace 0 > yadif 0 > rescale = fail
yadif 0 > yadif 0 = fail

[aufkrawall]

With --video-filter resize:csp=rgb at least full-range is applied.
If I got you right you want to maintain full range.
May I ask why you want to do so? :)

The visual difference to TV range is indistinguishable and only few player/decoder configurations will be able to play it right.

I think full range doesn't make sense in this case since the quality has already suffered a lot from reducing to YV12, I don't think there is any need to maintain such theoretical properties.

By converting to TV range you can also save a little of space.

[Reino]

I'm using Fraps 2.9.9.8086 atm, which as you may know, is not the most recent version. I'm using a sample from a Fraps video I made almost a year ago. For this sample I really need to apply full-range and BT.709 conversion with ConvertToRGB(matrix="PC.709") to (almost) match AVISource (Fraps through VFW). Perhaps your sample is newer and maybe the latest version of Fraps uses yet another colourspace.

[aufkrawall]

I'm using Fraps 2.9.9.8086 atm, which as you may know, is not the most recent version.

Was it the latest fully free version? How many years is it old? :D


I'm using a sample from a Fraps video I made almost a year ago. For this sample I really need to apply full-range and BT.709 conversion with ConvertToRGB(matrix="PC.709") to (almost) match AVISource (Fraps through VFW). Perhaps your sample is newer and maybe the latest version of Fraps uses yet another colourspace.
My situation is really odd. Using the FRAPS Decoder via AVISource gives me a very wrong result.
Do I have to consider anything else?

My experience is also that it may seem ok with some colors, but with some others maybe not.
I will continue testing.

As a test game I can really recommend Trine 2, it has lots of different colors (and is a nice game apart from graphics too :) ).

[Reino]

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!

My situation is really odd. Using the FRAPS Decoder via AVISource gives me a very wrong result.
Do I have to consider anything else?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.

[aufkrawall]

Vertically interlaced video streams, omg lol! xD

Really very weird, something must be fundamentally wrong. :D
I've never experienced such issues, neither with FRAPS RGB, nor with YV12.

You could try out the newest MSI Afterburner beta (it is free).
It can record raw video (much more ressources consuming than FRAPS RGB), maybe it works for you if it's smooth enough.


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.
Yes, for serious recording (not testing) I always use RGB, CPU and HDDs can handle it.

[TheFluff]

Actually latest FRAPS decoder from FFmpeg is VFR and from Libav is CFR.

The mailing list thread you linked has absolutely nothing to do with any of the things I mentioned other than vaguely being related to frame timestamps.

The reason FFMS2 treats everything as VFR is that it's the only format-agnostic way to treat playback speed. Frames have timestamps and durations. Sometimes, by pure coincidence, all frame durations in a video are the same, and then the video could be treated as CFR if you really wanted to. That's a special case, though, and we don't like special cases. Also, assuming CFR is fundamentally unsafe even with containers like AVI, so the only sensible solution is to always treat everything as VFR.

But TheFluff, screenshots from, on the one hand Avisynth output (with ConvertToRGB32(matrix="PC.709")), and on the other hand FFDShow output (with settings mentioned in my initial post), are identical in filesize. So FFDShow isn't matching the exact colours either.

FFDShow uses FFmpeg for decoding, and the standard Rec. 709 coefficients for converting YV12 to RGB, so of course it behaves just like Avisynth does. I don't see how this is remarkable in any way whatsoever. Furthermore, comparing compressed filesizes is a really, really bad way to determine if two images are alike or not.

My situation is really odd. Using the FRAPS Decoder via AVISource gives me a very wrong result.
Do I have to consider anything else?

You've either enabled FFdshow's VFW decoder, or you're doing something else wrong. The official decoder's output is correct by definition since it is the only existing specification of the format.

If you want to get exactly correct RGB video out of a FRAPS file encoded in YV12 using a decoder that actually outputs YV12 (such as FFmpeg) rather than one that outputs RGB (such as the official FRAPS VFW decoder), you'll need to reverse engineer the color coefficients used when converting YV12 to RGB, since it's obviously not using any of the standard ones (i.e. Rec 601 or Rec 709). That should be simple enough; just make a few test images that covers the entire RGB color space and compare the YV12 output from FFmpeg with the RGB output from the official FRAPS VFW decoder and create a lookup table (with 16.7 million entries, heh). Or just use linear regression to derive the original formula.

[PhrostByte]

Is there anything I can do about it?
Here's my script:
LoadCPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\ffms2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\colormatrix.dll")
FFVideoSource("trine.avi", colorspace="RGB32")
ConvertToYV24(matrix="Rec601")
ColorMatrix(mode="Rec.601->Rec.709")

I thought you were encoding with x264? YV12 is what you want, not YV24. If you to change from full-range 709 to normal range 709, which will be a lot more compatible with players:

FFVideoSource("trine.avi")
ColorMatrix(mode="Rec.709->Rec.709", inputFR=true)

FRAPS seems to use its own custom color matrix for converting RGB to YV12 and back again. ConvertToRGB32(matrix="PC.709") does, AFAIK, not match the original colors exactly.

I've noticed the same, 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.

[Rumbah]

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
I'm very astonished by that as I couldn't reproduce correct colors other than with the original decoder two years ago. I guess I have to try it again but I would be surprised if anything changed.

[Reino]

Furthermore, comparing compressed filesizes is a really, really bad way to determine if two images are alike or not.Unless you have a better way to quickly determine if 2 decoder outputs are identical, I'd say, if you take a screenshot of 1 frame of both decoders output and the compression potential (to png) is the same, both decoder outputs would have to be the same as well.
This way I found out that, while FPS1(rgb32), HFYU(rgb32) and LAGS(rgb32) are identical in output, FFV1(rgb32) is definitely not! But that's another story.
The same can be said for audio imo. If one questions whether a lossless audio encoder really is lossless, encoding the output of WavPack, Monkey's Audio and TAK Audio, to FLAC has to result in 3 flac-files identical in filesize.

@PhrostByte: in the LAV Filters thread aufkrawall explains his trine.avi is infact FPS1(bgra). TheFluff explains, the official decoder's output is correct by definition. For FPS1(bgra) AVISource and FFVideoSource produce the same output, so colorspace="RGB32" and all the following conversions are really unnecessary if you ask me.

[TheFluff]

Unless you have a better way to quickly determine if 2 decoder outputs are identical, I'd say, if you take a screenshot of 1 frame of both decoders output and the compression potential (to png) is the same, both decoder outputs would have to be the same as well.

That's not even remotely close to being accurate.

Avisynth has the subtract() filter if you want to look at the differences; use ImageMagick's compare tool (http://www.imagemagick.org/script/compare.php) if you want hard numbers.

@PhrostByte: in the LAV Filters thread aufkrawall explains his trine.avi is infact FPS1(bgra). TheFluff explains, the official decoder's output is correct by definition. For FPS1(bgra) AVISource and FFVideoSource produce the same output, so colorspace="RGB32" and all the following conversions are really unnecessary if you ask me.

FRAPS is lossless, so of course the outputs are the same. The entire problem is that FRAPS seems to do the RGB->YUV conversion in a way that isn't compatible with the way everything else does YUV->RGB. The obvious workaround for this is, as has already been mentioned, to just not use FRAPS in YV12 mode. Just cap RGB and you're home free.

[Reino]

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 involves an unnecessary colourspace conversion; YUV->RGB->YUV.

I've tried ColorMatrix, which already was suggested in other threads, but I just couldn't create a similar image to AVISource. Now I know ColorYUV(levels="PC->TV") or SmoothLevels(preset="pc2tv", chroma=100) has to go with that.
FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
ColorYUV(levels="PC->TV")
ColorMatrix(mode="rec.709->rec.601", clamp=0)

or

FFVideoSource("D:\FPS1(yuvj420p)_sample.avi")
SmoothLevels(preset="pc2tv", chroma=100)
ColorMatrix(mode="rec.709->rec.601", clamp=0)And this doesn't involve any colourspace conversions.

Now I do have a few question though:
- 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?
- 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?
- 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)

[aufkrawall]

FRAPS is lossless, so of course the outputs are the same. The entire problem is that FRAPS seems to do the RGB->YUV conversion in a way that isn't compatible with the way everything else does YUV->RGB. The obvious workaround for this is, as has already been mentioned, to just not use FRAPS in YV12 mode. Just cap RGB and you're home free.
It seems this is the only solution to get mathematically matching colors.
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.
I couldn't get it to work (ffdshow wasn't installed, neither any other codecs).
If somebody gets it to work, I'd be glad for a guide. :)

[PhrostByte]

FRAPS is lossless, so of course the outputs are the same. The entire problem is that FRAPS seems to do the RGB->YUV conversion in a way that isn't compatible with the way everything else does YUV->RGB. The obvious workaround for this is, as has already been mentioned, to just not use FRAPS in YV12 mode. Just cap RGB and you're home free.

One point of interest is that FRAPS' own decoders are also different -- its YV12 is significantly darker than RGB. So the only way to get accurate coder is to use RGB, in which case FFMS works fine.

FRAPS' decoder outputs nearly identical to FFMS().ConvertToRGB("Rec709"), so I'd guess its decoder is fine and it's the encoder that is borked.


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.

Because it doesn't work :)

[Reino]

Fraps' decoders? Plural??

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]

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]

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]

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 (http://avisynth.org/mediawiki/Levels) 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) (http://forum.doom9.org/showthread.php?p=1557070#post1557070) 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]

Although MediaWiki (http://avisynth.org/mediawiki/Levels) 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!

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 :p) 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 (http://forum.doom9.org/showthread.php?t=162155):

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

[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: