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