Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th February 2012, 17:43   #21  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,704
For converting FRAPS YV12 video, the simplest solution is to use Handbrake (nightly):
http://www.forum-3dcenter.org/vbulle...1&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.
aufkrawall is offline   Reply With Quote
Old 8th February 2012, 18:25   #22  |  Link
CoRoNe
Registered User
 
CoRoNe's Avatar
 
Join Date: Nov 2005
Posts: 648
@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:
Quote:
Originally Posted by http://x264.fushizen.eu/
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.
__________________
My hobby website

Last edited by CoRoNe; 8th February 2012 at 18:37.
CoRoNe is offline   Reply With Quote
Old 8th February 2012, 19:27   #23  |  Link
smok3
brontosaurusrex
 
smok3's Avatar
 
Join Date: Oct 2001
Posts: 2,391
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
Code:
[scale @ 0x7fb230416660] w:1280 h:1024 fmt:yuvj420p -> w:1280 h:1024 fmt:yuv420p flags:0x4
__________________
certain other member
smok3 is offline   Reply With Quote
Old 8th February 2012, 20:01   #24  |  Link
richardpl
Registered User
 
Join Date: Jan 2012
Posts: 72
Your ffmpeg must be very recent to experience this.

Read this for more info: http://article.gmane.org/gmane.comp....07/match=fraps

Last edited by richardpl; 8th February 2012 at 20:06. Reason: clarification
richardpl is offline   Reply With Quote
Old 8th February 2012, 20:02   #25  |  Link
smok3
brontosaurusrex
 
smok3's Avatar
 
Join Date: Oct 2001
Posts: 2,391
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
__________________
certain other member

Last edited by smok3; 8th February 2012 at 20:33.
smok3 is offline   Reply With Quote
Old 8th February 2012, 20:11   #26  |  Link
richardpl
Registered User
 
Join Date: Jan 2012
Posts: 72
Sorry but that revision points that you are using Libav.
And Libav fraps decoder does not support multi-threading.
richardpl is offline   Reply With Quote
Old 8th February 2012, 20:21   #27  |  Link
smok3
brontosaurusrex
 
smok3's Avatar
 
Join Date: Oct 2001
Posts: 2,391
Quote:
Originally Posted by richardpl View Post
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
__________________
certain other member

Last edited by smok3; 8th February 2012 at 20:45.
smok3 is offline   Reply With Quote
Old 8th February 2012, 20:29   #28  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,704
Quote:
Originally Posted by CoRoNe View Post
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.
aufkrawall is offline   Reply With Quote
Old 8th February 2012, 20:46   #29  |  Link
CoRoNe
Registered User
 
CoRoNe's Avatar
 
Join Date: Nov 2005
Posts: 648
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.
__________________
My hobby website
CoRoNe is offline   Reply With Quote
Old 8th February 2012, 21:27   #30  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,704
Quote:
Originally Posted by CoRoNe View Post
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?

Quote:
Originally Posted by CoRoNe View Post
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 ).
aufkrawall is offline   Reply With Quote
Old 9th February 2012, 00:47   #31  |  Link
CoRoNe
Registered User
 
CoRoNe's Avatar
 
Join Date: Nov 2005
Posts: 648
I did some testing with Fraps 3.4.7.13808, and uh...*cough*

Colin McRae Rally 04 and 2005 (both forced RGB, or bgra):


Tactical Ops AOT (bgra, yuvj420p(!) and yuvj420p (Fraps 2.9.9.8086)):


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!

Quote:
Originally Posted by aufkrawall View Post
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.
__________________
My hobby website
CoRoNe is offline   Reply With Quote
Old 9th February 2012, 01:15   #32  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,704
Quote:
Originally Posted by CoRoNe View Post
Vertically interlaced video streams, omg lol! xD
Really very weird, something must be fundamentally wrong.
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.

Quote:
Originally Posted by CoRoNe View Post
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.
aufkrawall is offline   Reply With Quote
Old 9th February 2012, 01:21   #33  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,056
Quote:
Originally Posted by richardpl View Post
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.

Quote:
Originally Posted by CoRoNe View Post
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.

Quote:
Originally Posted by aufkrawall View Post
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.

Last edited by TheFluff; 9th February 2012 at 01:30.
TheFluff is offline   Reply With Quote
Old 9th February 2012, 02:07   #34  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Quote:
Originally Posted by aufkrawall View Post
Is there anything I can do about it?
Here's my script:
Code:
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:

Code:
FFVideoSource("trine.avi")
ColorMatrix(mode="Rec.709->Rec.709", inputFR=true)
Quote:
Originally Posted by TheFluff View Post
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:

Code:
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.
__________________
Lanczos4, Spline36, what!? Don't know how to pick a resizer? Take a look at my kernel visualizations.
Want a high-quality, gamma-aware resizer? Check out my ResampleHQ filter.
PhrostByte is offline   Reply With Quote
Old 9th February 2012, 11:17   #35  |  Link
Rumbah
Registered User
 
Join Date: Mar 2003
Posts: 455
Code:
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.
__________________
x264 full help - x264 --fullhelp r2345
Cuttermaran HCEnc provider - Support for HCEnc in Cuttermaran
DualDVDRB - Dual core support for DVD-RB free
Rumbah is offline   Reply With Quote
Old 9th February 2012, 13:27   #36  |  Link
CoRoNe
Registered User
 
CoRoNe's Avatar
 
Join Date: Nov 2005
Posts: 648
Quote:
Originally Posted by TheFluff View Post
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.
__________________
My hobby website
CoRoNe is offline   Reply With Quote
Old 9th February 2012, 16:52   #37  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,056
Quote:
Originally Posted by CoRoNe View Post
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 if you want hard numbers.

Quote:
Originally Posted by CoRoNe View Post
@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.
TheFluff is offline   Reply With Quote
Old 9th February 2012, 17:02   #38  |  Link
CoRoNe
Registered User
 
CoRoNe's Avatar
 
Join Date: Nov 2005
Posts: 648
Upon using this forum's search function for something else, I accidentally stumbled upon "Making FRAPS video from FFMS2 match AviSource?".

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.
Code:
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)
__________________
My hobby website
CoRoNe is offline   Reply With Quote
Old 9th February 2012, 18:00   #39  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,704
Quote:
Originally Posted by TheFluff View Post
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.
aufkrawall is offline   Reply With Quote
Old 10th February 2012, 20:20   #40  |  Link
PhrostByte
Grand Fruitioner
 
PhrostByte's Avatar
 
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
Quote:
Originally Posted by TheFluff View Post
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.


Quote:
Originally Posted by aufkrawall View Post
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
__________________
Lanczos4, Spline36, what!? Don't know how to pick a resizer? Take a look at my kernel visualizations.
Want a high-quality, gamma-aware resizer? Check out my ResampleHQ filter.

Last edited by PhrostByte; 10th February 2012 at 20:22.
PhrostByte is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 17:13.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.