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 > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 16th September 2016, 16:12   #4261  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Motenai Yoda View Post
for research purpose, which is more compatible with tablet, tv and boxset, a main10 level 4.0 high tier or a main10 level 4.1 main tier?
Probably 4.1 Main Tier. But there's a lot of tablets and some TVs that aren't 10-bit compatible at all.

8-bit Main Level 4.0 is going to be the most compatible option.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 22nd September 2016, 17:49   #4262  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265-2.0+65-d20b78d6d138 (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[EDIT]
Updated to x265-2.0+65

Last edited by Barough; 23rd September 2016 at 13:24.
Barough is offline   Reply With Quote
Old 25th September 2016, 06:07   #4263  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Can someone explain RDO Prediction?

I recently upgraded my computer and therefore have some extra encoding power. I've been thinking about making one of the following changes.

RD 5
Rect
Rect & Amp

Now, I admit I don't fully understand the low level details of the options above - just the bits I can gather from the docs. What is RDO predictions? It is listed as the change to RD 5. It seems to have a very large impact on encoding speed.

Here are my current settings.

Code:
--profile main10 --output-depth 10 --ctu 64 --bframes 6 --bframe-bias 5 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 57 --subme 3 --no-rect --no-amp --limit-modes
 --max-merge 3 --no-early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 1 --aq-strength 1 --cutree --rd 4
 --tu-intra-depth 3 --tu-inter-depth 3 --psy-rd 1 --psy-rdoq 1 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing
On another note, how can I identify the differences/benefits of the three options above? As in - what should I look for? I generally use staxrip's video comparison tool but I don't know where to look for the differences.

Thanks in advance!
brumsky is offline   Reply With Quote
Old 25th September 2016, 11:58   #4264  |  Link
Jawed
Registered User
 
Join Date: Jan 2008
Location: London
Posts: 156
This is how I do it:

--preset medium --rd 5

versus

--preset medium

To compare encodes I use a script like:

Code:
a=FFVideoSource() # original before encoding
b=FFVideoSource() # encoded

c=subtract(a,b)
c=c.lumalevels(133,149)

interleave(a,b,c)

return last

function LumaLevels(clip source, int "black", int "white", float "sat")
{ 
black=default(black,16)  # PCLevels
white=default(white,235) # PCLevels
sat  =default(sat,1)     

Cont   = 255/float(white-black)
Bright = -int(float((black-16)*Cont+16.5))
Tweak(source,bright=Bright, cont=Cont, coring=false, sat=sat)
}
This helps me to identify where in the frame there are differences. I can then decide whether I care about those differences.

For my own encodes I'm currently using:

--crf 20 --preset medium --output-depth 10 --rd 6

--crf 24 --preset medium --output-depth 10 --bframes 2 --rd 6

--crf 28 --preset medium --output-depth 10 --bframes 2 --rd 6

I think medium with --rd 6 is better than slow and it's the same encode speed or a little faster than slow. Slow uses --rd 4. Medium uses --rd 3. So --rd 6 is a significant difference for the medium preset.

Yes, I know that --rd 6 is currently the same as 5 - when 6 arrives, I'm ready!

I decided to focus on --rd due to:

http://forum.doom9.org/showpost.php?...postcount=4237
Jawed is offline   Reply With Quote
Old 25th September 2016, 18:10   #4265  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by brumsky View Post
I recently upgraded my computer and therefore have some extra encoding power. I've been thinking about making one of the following changes.

RD 5
Rect
Rect & Amp

Now, I admit I don't fully understand the low level details of the options above - just the bits I can gather from the docs. What is RDO predictions? It is listed as the change to RD 5. It seems to have a very large impact on encoding speed.
RD = Rate Distortion Optimization level
At the core of x265 (and most video encoders) is an algorithm that figures out the best way to encode each block of video. This algorithm weighs the distortion of each candidate "mode" against the bits used (the rate). To do this rate distortion optimization as accurately as possible, the encoder has to accurately calculate the bits that each candidate mode would use. In other words, it has to fully encode the candidate mode, calculating the residual error after prediction (the difference between the inter or intra-predicted block and the source pixels), performing a discrete cosine transform on the residual error, quantizing the residual error, and entropy coding the predicted block plus the residual error. This method is used for RD level 5. For lower RD levels, x265 weighs the bits used by each candidate mode, but it doesn't go through all of the above steps (it will skip entropy coding, for example). Lower levels are roughly accurate when it comes to choosing the best mode, but not as accurate as the highest rd level. Note that there are a number of decisions in x265 that can be rd optimized. More decisions are rd optimized at higher rd level, to a higher degree of precision.

RECT = allow x265 to evaluate and code rectangular blocks (CUs). Each CTU (usually a 64x64 pixel block, but this depends on your --ctu setting) is analyzed to find the optimal way to encode the pixels in the CTU, partitioning the CTU into smaller CUs. For example, a 64x64 pixel CTU might be encoded as four 32x32 CUs, or sixteen 16x16 pixel CUs. HEVC supports rectangular CUs. For example, a 32x32 pixel block could be encoded as two 16x32 CUs, or two 32x16 CUs. Rectangular CUs allow the partitioning to more ideally match the video content, but of course the more possibilities the encoder wants to evaluate, the longer it takes to evaluate all of the possibilities.

AMP = allow x265 to evaluate asymmetric partitions. Asymmetric partitions are rectangular CUs that have a ratio of 1:4, 3:4, 4:1 or 4:3. For example, a 32x32 pixel block can be encoded as a 8x32 pixel block plus a 24x32 pixel block. Again, these additional possibilities can allow for a more accurate fit, but more possibilities = more time needed to evaluate all possibilities.
  Reply With Quote
Old 25th September 2016, 20:26   #4266  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
AMP seems to have a much less of an impact on performance compared to RECT.
burfadel is offline   Reply With Quote
Old 26th September 2016, 19:41   #4267  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by burfadel View Post
AMP seems to have a much less of an impact on performance compared to RECT.
And --limit-refs and --limit-modes can make the perf cost of each or both a lot smaller while retaining most of the gains.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 26th September 2016, 20:19   #4268  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Quote:
Originally Posted by benwaggoner View Post
And --limit-refs and --limit-modes can make the perf cost of each or both a lot smaller while retaining most of the gains.
Yes, that too!
burfadel is offline   Reply With Quote
Old 26th September 2016, 23:20   #4269  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Jawed View Post
For my own encodes I'm currently using:

--crf 20 --preset medium --output-depth 10 --rd 6

--crf 24 --preset medium --output-depth 10 --bframes 2 --rd 6

--crf 28 --preset medium --output-depth 10 --bframes 2 --rd 6
Why only 2 b-frames?
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 27th September 2016, 00:36   #4270  |  Link
Jawed
Registered User
 
Join Date: Jan 2008
Location: London
Posts: 156
Quote:
Originally Posted by benwaggoner View Post
Why only 2 b-frames?
I found that motion in live action tended to become jittery (sort of as though it were half-rate: "anime" in feel).

http://forum.doom9.org/showpost.php?...postcount=4189

I actually found the same source suffered the same fate with x264 at crf 24 (using settings that are almost equivalent to preset very slow in speed). But in x264 I historically did not use crf as high as 24 - principally because blocking/banding with 8-bit encodes becomes unbearable.

So the same source in both x264 and x265 (both 10-bit) produced the same problem, which disappears with crf 20. In x264, setting --tune grain also solved the problem (doubled the bitrate for the water test sequence too...).

So when I started my x265 experiments I started to investigate crf, pushing far beyond 21 which was my limit with x264 8-bit. 10-bit, it transpires, makes x264 blocking/banding a non-issue, which was a good reason to see what I thought of higher crf values. Along the way I stumbled into this problem at crf 24.

(In fact I found the problem back in April and was so dismayed that I just forgot about my x265 experiments and did other things - not realising at the time that it was b-frames causing the problem.)

On the water sequence I reported 4 b-frames as a solution. But in other testing I found that rapidly turning faces (small in the frame) in low contrast (think "a steamy room") the problem recurred (horrible jumps, like anime). So 2 b-frames it is.

I decided not to evaluate CRFs between 20 and 24 to see how the problem arises. It just seems that at crf 24, b-frames (with x264 or x265 both on very slow preset) are too unreliable. I hadn't noticed in the past with x264 because I hadn't used such a high value for crf.

Last edited by Jawed; 27th September 2016 at 00:45. Reason: "turning" rather than "moving"
Jawed is offline   Reply With Quote
Old 27th September 2016, 01:07   #4271  |  Link
Dclose
Registered User
 
Join Date: Aug 2014
Posts: 50
Quote:
Originally Posted by Jawed View Post
I think medium with --rd 6 is better than slow and it's the same encode speed or a little faster than slow. Slow uses --rd 4. Medium uses --rd 3. So --rd 6 is a significant difference for the medium preset.
I'm testing that right now. --rd 5 is "better" than 4, but it's so slow. And on my current live action test sample, it looks like Medium + --rd 5 is more susceptible to reference frames than Slow + --rd 4.

3,4 frames it is more detailed than Slow + 4, but there's more blocking/artifacts. I changed the frames to 4,4 and that helped, though Slow + 4 is still more consistent even at 3,4 frames. (but Medium + rd5 still has more detail).

And now I increased frames to 5,7. I didn't notice that helping Slow + rd4, but it sure looks to have helped the artifacts/blocking of Medium + rd5. Slow + rd4 is still better in that regard, though.

This is with using most of the common(?) settings for more detail. Maybe those detail settings are too much for Medium and rd5 and 23-24 CRF.

Are there differences between presets that can't be changed? Right now, I think I'm basically changing Sub-Pixel Precision to be able to run --rd 5 at a decent speed. Medium, rd 5, Sub-Pixel Precision 2 vs. Slow, rd 4, Sub-Pixel Precision 3.
Dclose is offline   Reply With Quote
Old 27th September 2016, 01:32   #4272  |  Link
Jawed
Registered User
 
Join Date: Jan 2008
Location: London
Posts: 156
Check the presets page:

http://x265.readthedocs.io/en/latest/presets.html
Jawed is offline   Reply With Quote
Old 27th September 2016, 14:37   #4273  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Another milestone has been passed. Triple feature this time: v2.1+2 stable

x265 2.1+2-c0d91c2b4048 (GCC 5.3.0)
x265 2.1+2-c0d91c2b4048 (GCC 6.1.0)
x265 2.1+2-c0d91c2b4048 (GCC 6.2.0)

I guess I can skip GCC 6.1.0 soon?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 27th September 2016, 19:47   #4274  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
My Little Test

Thanks for the reply and info Jawed. I did watch that video when it was released. Based on your suggestion, I decided to take a 30 second clip with high motion and a significant amount of rain then encode it using different settings.

The main goal of this was to determine the extra encoding time required for a variety of settings. This is by no means an exhaustive analysis of all the settings - just a select few.

Please note that I am comparing the additional settings against my base config - see below.

Code:
 --profile main10 --output-depth 10 --crf 22 --ctu 32 --bframes 6 --bframe-bias 5 --rc-lookahead 40 --scenecut 40 --ref 5 --limit-refs 3 --me 3 --merange 26 --subme 3 --no-rect --no-amp
 --limit-modes --max-merge 4 --no-early-skip --b-intra --no-sao --signhide --weightp --weightb --aq-mode 1 --aq-strength 1
 --cutree --rd 4  --tu-intra-depth 3 --tu-inter-depth 1 --psy-rd 1 --psy-rdoq 1 --rdoq-level 2 --qcomp 0.65 --no-strong-intra-smoothing --qg-size 16
Using the settings above I began making the following changes then running the encode, and documenting the results.

Here is the link to my dropbox folder, it contains all the videos, images, and excel doc I used.

I will only post a few select images, if you wish to see them all please download from dropbox.

https://www.dropbox.com/sh/mv9jhnoez...7v60IVlZa?dl=0

First off I'd like to say that I selected this clip for two reasons.
  1. It was the best clip I had at the time.
  2. I wanted a clip that would be difficult to encode, lots of motion and rain. The idea being to try and kick x265 in the pants.

Before I post the images I'd like to mention I couldn't tell the difference between any of the encodes when watching the video. The only way I could see a difference was to go frame by frame.

I'd suggest playing the encodes at random to see if you can see a difference.

Source:


My settings: 4.8 FPS - 2:25 encoding time


My settings plus RD 6: 3.135 FPS, 3:42 encoding time


Slow: 2.513 FPS, 4:37 encoding time


Very Slow: 0.919 FPS, 12:37 encoding time


Placebo: 0.250 FPS, 46:24 encoding time



If you look closely at the highlighted areas below you can see the areas I was specifically comparing.



Using my default settings you will see that the areas are less crisp and generally fussy. Especially the hair I highlighted. It has noticeable more distortion then any of the other encodes. The only way I was able to get rid of the distortion was by enabling RD6 - yes 5 & 6 are the same right now. With the exception of preset slow, which is RD 4.

I was actually quiet puzzled by this, I tried adding rect & amp or tu-inter-depth 3 & rect to remove the distortion. Neither of them worked, the images and videos are in dropbox for those encodes. I'm guessing at this point that since the slow preset uses SAO and strong-intra-smoothing, those are responsible for the reduced distortion observed.

It shouldn't be a surprise that the higher the settings used the better the quality. The question is, is the extra encoding time worth the extra quality?

I'd suggest downloading the excel doc now to view all of the results.

Taking the encoding time into account, my opinion is that adding RD 6 gives the best quality increase per extra encoding time. That single option was able to remove a significant amount of the distortion I mentioned above with the smallest increase in encoding time. If you're looking at the doc the column Magnitude difference, for the life of me I couldn't think of a better term, shows the multiple/factor of encoding time increase. Meaning if you take your FPS and divide it by the corresponding value, it should give you a reasonable idea of your fps rate.

Yes I know it will vary, the point is it will at least give you a good ballpark range.

I've decided to have a bit of a rolling scale. Meaning if a particular video is less important to me I'll use by default settings. As the importance of the content increases so will my settings.

On a scale of 1 - 10:
1-4 - my default settings
5-7 - Add RD6
8-10 - add RD 6 rect & amp

Adding at least rect gives the benefit of tu-inter-depth 2 for at least the blocks that use rect or amp, per the docs.

With all of that said, I don't think I'll ever use Placebo or Very Slow presets. Placebo is up to 19x slower than my settings and Very Slow is over 5X slower. While they did produce better encodes, obviously, the increased quality wasn't enough to justify the encode times...

Now if you've actually looked at the excel doc you'll notice I ran the encodes on two different systems. One with AVX2 and one without.

Please Note: I only ran the tests once, so YMMV.

System A:
Dual E5-2670 v1 8c/16t 2.6GHz @ 2.9Ghz No AVX2
This is a Sandy Bridge chip and thus does not down clock when running AVX instructions. This means it can run at the 2.9GHZ all core turbo setting.

System B:
Single E5-2683 v4 16c/32t 2.0GHz @ 1.9Ghz With AVX2.
This is a Broadwell chip and does down clock when running AVX2 instructions.

Despite the 1GHZ difference in clock speed when encoding, the Broadwell chip is up to 25% faster depending upon the settings. If you are running CTU 64 it is up to 25% faster. With CTU 32 it is approximately equal.

At first glance this may not appear that impressive but keep in mind we are comparing two 115 watt chips versus a single 120 watt chip. At the vary least they are equal in speed for approximately half the power usage and heat generated - up 25% faster with CTU 64!!

EDIT:

I forgot to mention that to-intra-depth has little to no impact on performance. My default settings now include --tu-intra-depth 4.

Last edited by brumsky; 27th September 2016 at 20:33.
brumsky is offline   Reply With Quote
Old 27th September 2016, 20:24   #4275  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by x265_Project View Post
RD = Rate Distortion Optimization level
At the core of x265 (and most video encoders) is an algorithm that figures out the best way to encode each block of video. This algorithm weighs the distortion of each candidate "mode" against the bits used (the rate). To do this rate distortion optimization as accurately as possible, the encoder has to accurately calculate the bits that each candidate mode would use. In other words, it has to fully encode the candidate mode, calculating the residual error after prediction (the difference between the inter or intra-predicted block and the source pixels), performing a discrete cosine transform on the residual error, quantizing the residual error, and entropy coding the predicted block plus the residual error. This method is used for RD level 5. For lower RD levels, x265 weighs the bits used by each candidate mode, but it doesn't go through all of the above steps (it will skip entropy coding, for example). Lower levels are roughly accurate when it comes to choosing the best mode, but not as accurate as the highest rd level. Note that there are a number of decisions in x265 that can be rd optimized. More decisions are rd optimized at higher rd level, to a higher degree of precision.

RECT = allow x265 to evaluate and code rectangular blocks (CUs). Each CTU (usually a 64x64 pixel block, but this depends on your --ctu setting) is analyzed to find the optimal way to encode the pixels in the CTU, partitioning the CTU into smaller CUs. For example, a 64x64 pixel CTU might be encoded as four 32x32 CUs, or sixteen 16x16 pixel CUs. HEVC supports rectangular CUs. For example, a 32x32 pixel block could be encoded as two 16x32 CUs, or two 32x16 CUs. Rectangular CUs allow the partitioning to more ideally match the video content, but of course the more possibilities the encoder wants to evaluate, the longer it takes to evaluate all of the possibilities.

AMP = allow x265 to evaluate asymmetric partitions. Asymmetric partitions are rectangular CUs that have a ratio of 1:4, 3:4, 4:1 or 4:3. For example, a 32x32 pixel block can be encoded as a 8x32 pixel block plus a 24x32 pixel block. Again, these additional possibilities can allow for a more accurate fit, but more possibilities = more time needed to evaluate all possibilities.
Thank you for the detailed answer!

Is RDO predictions the Entropy coding you mentioned?
brumsky is offline   Reply With Quote
Old 27th September 2016, 20:54   #4276  |  Link
trip_let
Registered User
 
Join Date: Sep 2012
Posts: 47
Quote:
Originally Posted by brumsky View Post
Is RDO predictions the Entropy coding you mentioned?
I'm not x265_Project and not that familiar with video encoding, but unless entropy coding means something different in this context, usually that just refers to general lossless encoding of information bits by essentially making a more efficient representation using codewords, representing more common patterns with fewer bits and less common patterns with more bits. So this process is not about predictions. Some information used in aiding rate distortion optimization with rd 5 is entropy coded.

Rate distortion optimization is about figuring out which lossy representation is acceptably close to the original. At a high level there are more calculations with higher rd levels to increase accuracy of predictions of what might be the best candidate of choices/modes to use by the encoder.



By the way, does anybody know an easy way to compare what's different between versions? I'm not much of a coder and don't really know platforms like bitbucket etc. I know you can look at the commits but that's a bit low level. Kind of looking for the equivalent of a changelog between stable builds. Maybe you can compare documentation versions? But on readthedocs they have latest, stable, 1.7, 1.6 on down, but no 2.0. Can some other snapshot be accessed? Or perhaps any feature labeled "experimental" might be new?
trip_let is offline   Reply With Quote
Old 27th September 2016, 21:41   #4277  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by brumsky View Post
Thank you for the detailed answer!

Is RDO predictions the Entropy coding you mentioned?
The general sequence of video encoding (simple version)...

Prediction -> Calculate Residual Error after Prediction -> Discrete Cosine Transform the Residual Error -> Quantize the Transformed Residual Error -> Entropy Code the Prediction and the Transformed, Quantized Residual Error

Entropy coding is lossless compression (think of it like zip file compression). HEVC uses CABAC entropy coding. This is the last step for encoding each block.

When you're doing rate-distortion optimization (RDO), and you want to weigh the relative bit rate of multiple encoding candidates for a block of video, you have to do all of the above steps if you want the actual number of bits. This is very time consuming, of course, because you are doing a full transform, quant and entropy coding on every candidate, and you'll throw out all but the best candidate. So for faster settings, we just look at the # of bits for each candidate without doing the entropy coding. It's roughly accurate, but not as accurate.
  Reply With Quote
Old 28th September 2016, 09:35   #4278  |  Link
RainyDog
Registered User
 
Join Date: May 2009
Posts: 184
Quote:
Originally Posted by brumsky View Post
I forgot to mention that to-intra-depth has little to no impact on performance. My default settings now include --tu-intra-depth 4.
Yeah I've noticed this too brumsky. I used to run --tu-inter-depth 2 and --tu-intra-depth 2 but realised that there was no difference in speed by upping intra to 3.

In fact, I wonder if intra actually does anything at certain resolutions as --tu-inter-depth 2 / --tu-intra-depth 3 versus --tu-inter-depth 2 / --tu-intra-depth 1 resulted in practically identical bitrates and file sizes if I recall when I tested them.
RainyDog is offline   Reply With Quote
Old 28th September 2016, 21:47   #4279  |  Link
Jawed
Registered User
 
Join Date: Jan 2008
Location: London
Posts: 156
So brumsky, since your encode parameters are so slow, perhaps you can use --rd 6 to replace other of your parameters that are "slow".

Perhaps you can get back to approximately the same quality as your default parameters (without --rd 6) and maybe gain performance

The parameters (including --rd 6) you provided are very impressive on that clip - I'd say close to, if not as good as, crf 18 slow (and about 1/4 the bitrate).

That's really going some. But the nature of the clip could be biasing such an assessment. In my experience useful conclusions come from many test clips (and single frames are ignored)...

I wonder if the x265 project will, at some point, completely overhaul their presets. It would appear that they've been chosen too early in the development cycle.

One of the things that concerns me with the presets is that higher quality presets often lead to increased bitrate. This is the opposite of what's seen with x264. To me that indicates the presets are pretty immature.
Jawed is offline   Reply With Quote
Old 29th September 2016, 04:48   #4280  |  Link
x265_Project
Guest
 
Posts: n/a
Quote:
Originally Posted by Jawed View Post
I wonder if the x265 project will, at some point, completely overhaul their presets.
We take a look at this every so often. We've updated our presets several times already, and we'll certainly do it again as we make improvements to different algorithms, or develop new algorithms. We don't want to do it too often, as we think people like to develop a favorite recipe, and when we change presets it changes things for everyone using x265 (except those who specify every option manually).
  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 23:32.


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