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 > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 17th February 2004, 04:28   #1  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
RealVideo 10 'Elysian'

I think this new RealVideo 10 encoder version includes the most two requested features from this forum, so I am looking forward to some feedback.

Download

EDIT: The latest RealVideo 10 'Elysian' is now included with Helix Producer 10 and the most recent GUIs as well. It is not necessary to download a separate DLL. There is also a new and much improved HFE, compared to the one included with the original Elysian release.

So, download it here: RealVideo 10 'Elysian' Preview. I am tired of making minor adjustments. I know it works. Time for some feedback. I have tested this only with Helix Producer 10 Preview cmd line version. However, it should also work in older Producer versions.
2/19: no change, except compiled w. Intel Compiler for 5-7.5% faster encoding.
2/20: moved to file sharing section on helixcommunity.org.
2/24: added new options to reduce large frames, increase small frames, increase keyframes
03/01: bugfix keyframe interval + new complexity level 30% faster than High, almost same quality

New encoder features

Curve Compression 2-pass rate control

Motivated mostly by doom9's codec comparison and how well XviD maintains constant quality, I decided it was time to implement a new rate control in Realvideo, with no streaming inheritance left-over at all.

This new rate control uses the same "curve compression" principle as XviD, and can achieve constant quality throughout the encode, and very accurate target filesize/bitrate.

Also new is the codec's ability to drop down to zero B frames during high action. Previously it would go down to one. Additionally, the 1st pass now runs at complexity 50, and always without the inloop filter, making the 1st pass faster than ever.

Please note for typical average PSNR comparisons with short clips for medium to low bitrates, there may be a slight loss, even though minimum PSNR is much improved. This is because the high action scenes, even though visually improved, are too expensive in terms of bits/PSNR. Please experiment with the advanced options to reduce high bitrate frames, this will improve average PSNR. However, for pure comparisons of avg PSNR, the previous rate control is probably better. Visually, I like the new rate control. Video is approaching audio in the sense that pure PSNR based comparisons are not matching the human sense preferences.

Full length encodes, like those used in the codec comparison on doom9 can hardly be recognized with this new rate control, during the high action scenes. No screen shots are needed. You can see for yourselves. It also works great for any length clip. The previous 2-pass VBR improvement was just a small step in the right direction. This is the real thing, finally constant quality 2-pass VBR with RealVideo!

Inloop filter

Implemented by my colleague Neelesh, and included in this preview is the ability on the encode side set the quant threshold at which the inloop filter is completely disabled. For high bitrates, this corresponds to another significant quality improvement, with better detail preservation. See the comments in the options below for details. Please be aware that completely disabling the inloop filter for low to medium bitrates is not a good idea, significant visual and PSNR degradation will be the result, so set the threshold wisely. We are specifically interested in feedback on which values you prefer.

New decoder features

High Frequency Emphasis

HFE is included with RealPlayer 10 Gold, currently available from http://www.real.com but not enabled by default. Use reg keys below to enable

Please try out this new feature in the included decoder, developed by Neelesh.

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV10HFE]
"strength"=dword:00000001

Useful values: 0 [off], 1, 2, 3
Recommended: 1

Video codecs employing methods like inloop filter and B-frame interpolation have a tendency to attenuate certain spectral information in the video. For example an inloop filter can smoothen out certain frequencies and B-frame interpolation mode can hurt the high frequencies present in video.

HFE (High Frequency Emphasis) post filter corrects and further enhances the spectral information lost or attenuated in video. Look for subtle improvements in textures/noise in the spatial domain and their temporal continuity.

Visualizations

Another feature by Neelesh:

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV10HFE]
"visualizations"=dword:00000000

Useful values: 0 [off], 1, 2, 3
1: shows one dot to indicate HFE is enabled
2: shows a number of dots to indicate quantizer
3: showtime
Note that HFE needs to be enabled for this to work (strength >= 1). This is because OSD can only be done with a postfilter, i.e. the processed data is not used for future prediction. HFE is a postfilter as opposed to the inloop filter, which makes this possible.

You were asking about tweaking the inloop thresholds using OSD. Remember, an inloop filter than only be changed in the encoder, because encoder and decoder need to match. However, it's indirectly possible, since the OSD will show you the quants of a clip.

HFE on the other hand is a postfilter, and can be adjusted on playback as much as you like.

Etc

GUIs supporting the new features are on the way. Thanks to Sirber, D-C, and zedude for providing valuable feedback.

For those who want to try new options in a GUI now, you can use reg keys, since all the options have corresponding reg keys. There is a sample reg file included in the zip.

Going forward, this new rate control will most likely be hooked up the the previously un-used 'vbrUnconstrainedBitrate' parameter in Producer 10 Gold. The inloop option will be hooked up to 'sharp' with the parameters found to work best.

Why 'Elysian'? Because of Champs Elysées in Paris, the final stage of the Tour de France. Maybe I will add more to this explanation later.

List of encoder options

Here are all the new options, these are included in a sample .rpad. Of course, to use a commented out option, it needs to be commented back in. All these options go in the <codecProperties type="bag"> of the audience:

<!-- New RC options -->

<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
<!-- Enables new curve compression based rate control -->
<!-- This disables all other RC modes, MSL and maxBitrate ignored -->
<!-- Still, include maxBitrate and MSL; needed for stream properties -->

<!-- The new RC's goal is constant quality throughout the encode. -->
<!-- It works very well at high bitrates, and is much more accurate than -->
<!-- the old rate control.

<!-- Note that his constant quality is not the best solution for -->
<!-- highest overall or average PSNR. For my sample test clip, -->
<!-- I got a reduction of 0.3 dB average PSNR, but 6.5 dB better -->
<!-- minimum PSNR, corresponding to a huge visual improvement -->
<!-- Other news about this RC, is that it allows 1st pass to be run -->
<!-- at the lowest possible complexity (50), with inloop filter off -->
<!-- This makes the 1st pass run even faster than before -->

<!-- Since the analysis file is the same format as XviD uses it -->
<!-- can be read, plotted, and analyzed with some of the same tools. -->
<!-- External scaler tools can be used as well -->
<!-- New is that with this new RC the 2nd pass can be re-run at -->
<!-- different target bitrates than the 1st pass. -->

<!-- WARNING: This rate control works only in 2-pass mode. -->
<!-- If you enable rcEnableCurveCompression, and run -->
<!-- a 1-pass encode, the encoder will run the 1st pass of -->
<!-- a 2-pass encode, and you will end up with a very large -->
<!-- output file. If you like, you can then run the 2nd -->
<!-- pass separately, using the rcPassNumber option below. -->


<!-- <rcSourceFrameRate type="uint">23976</rcSourceFrameRate> -->
<!-- If source != 30fps, this is temporarily needed, due to a bug -->
<!-- in Producer which sends the wrong framerate to the codec, which -->
<!-- needs the framerate to calculate target file size, from bitrate -->
<!-- Note that this param is an integer: fps * 1000 -->

<!-- <rcAnalysisFileName type="string">realvideo.pass</rcAnalysisFileName> -->
<!-- First pass analysis file, ASCII text, same format as XviD -->
<!-- This is possible, since all it contains are: frame types, -->
<!-- quants, MBs, frame sizes, (scalable and un-scalable part) -->
<!-- Can be read by XviD stats analysis tools, like this one : -->
<!-- http://atlas2.tgv.net/~media-video/f...pic.php?t=3594 -->
<!-- http://forum.doom9.org/showthread.php?s=&threadid=67639 -->
<!-- An external scaler would add a last column (desired frame size) -->
<!-- The binary .stats format is not supported -->

<!-- <rcLogFileName type="string">realvideo.log</rcLogFileName> -->
<!-- Rate control log file from 2nd pass -->
<!-- Useful only if problems occur, and for the curious -->

<!-- Advanced options -->
<!-- <rcTargetVideoSize type="uint">585728</rcTargetVideoSize> -->
<!-- Target filesize is kilobytes for /VIDEO ONLY/, over-rides target bitrate -->
<!-- If this option is used, rcSourceFrameRate is not needed -->

<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>
<!-- Boost keyframes by rcKeyFrameBoost % -->

<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>
<!-- Reduce larger than average frames by rcHighBitrateReduce % -->
<!-- Usually good for average PSNR, and/or low/medium bitrate -->
<!-- streams, where the largest frames cost too many bits -->
<!-- compared to the PSNR achieved -->

<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>
<!-- Boost smaller than average frames by rcLowBitrateBoost % -->

<!-- <rcPassNumber type="uint">2</rcPassNumber> -->
<!-- Specify pass # to run, requires cmd line -dt or jobfile -->
<!-- enableTwoPass to 'false'. 2nd pass can be re-run with any -->
<!-- target bitrate changes, other parameters should be the same -->
<!-- When pass #1 is run by itself, Producer will appear to be -->
<!-- encoding normally, and also output a large RMVB, but it will -->
<!-- also output .pass file correctly. -->

<!-- <rcPFrameRefQuant type="uint">6</rcPFrameRefQuant> -->
<!-- <rcBFrameRefQuant type="uint">10</rcBFrameRefQuant> -->

<!-- Quantizers to use for the 1st pass reference encoding -->
<!-- Range [0-30] Leave alone unless you know what you are doing -->
<!-- Quants do not correspond to MPEG-4 quants and do not scale -->
<!-- the same way either. -->

<!-- End of new RC options -->

<maxConsecutiveBFrames type="uint">3</maxConsecutiveBFrames>
<!-- Maximum consecutive number of B frames -->
<!-- Leave B frame adaptivity ON, but sets the max number of B frames -->
<!-- Only 3, 1, and 0 are allowed, due to current impl. restriction -->

<!-- Inloop filter options -->
<inloopCutOffQuant type="uint">11</inloopCutOffQuant>
<!-- Inloop filter is turned off below this quant. -->
<!-- Set to 0 to always use inloop (this is the default, but -->
<!-- in reality, the default level is around 8 -->
<!-- Set to 31, to completely disable inloop postfilter -->
<!-- When quant is below the threshold, the encoder will -->
<!-- skip the inloop filter, and put a bit in the bitstream -->
<!-- so the decoder will do the same. Use with caution for -->
<!-- low to medium bitrates. No inloop will lower PSNR as well -->
<!-- These quants do not correspond to MPEG-4 quants! -->

<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
<!-- Make bitstream 100% compatible with earlier*) decoders -->
<!-- What this means is that /key/frames will always be inloop -->
<!-- filtered with the default quant threshold. This is a -->
<!-- bug in old decoders, they always inloop filter keyframes. -->
<!-- When set to false, the threshold applies to all frame types. -->
<!-- When an old decoder tries to decode such a bitstream -->
<!-- there will be a very minor decoder mismatch, in most cases -->
<!-- not visible. *: RV8/9/10 decoders prior to RealPlayer 10 Gold -->

<inloopCutOffBUseRefQuant type="bool">true</inloopCutOffBUseRefQuant>
<!-- If true, the threshold to enable the inloop filter -->
<!-- for B frames, will use the reference frame's quant -->
<!-- If false, the B frame's quant is used. -->
<!-- Looking for feedback what works best here -->

__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.

Last edited by karl_lillevold; 17th May 2004 at 18:00.
karl_lillevold is offline   Reply With Quote
Old 17th February 2004, 04:44   #2  |  Link
RadicalEd
Registered User
 
Join Date: Dec 2001
Posts: 987
Sweeeeeeeeeeeeet
Merry Christmas to you too, Karl.
RadicalEd is offline   Reply With Quote
Old 17th February 2004, 09:48   #3  |  Link
damrod
Registered User
 
damrod's Avatar
 
Join Date: Jun 2003
Location: Elyseum
Posts: 640
i will add this new version and the new options to realbatch soon...
__________________
Projects :
(dev stopped) DamBatch, MBatch
(generate mkv/mp4 files with aac(+)/vorbis/mp3 and x264/xvid/real or simple avi with h264/mp3 for fast reencoding using mencoder)
Website : Damrod.com
damrod is offline   Reply With Quote
Old 17th February 2004, 10:16   #4  |  Link
bond
Registered User
 
Join Date: Nov 2001
Posts: 9,770
great to see that you are working on the high-motion treatment, karl (and that the opensource communities work helped you with it)
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau)
I know, that I know nothing (Socrates)

MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide)
Ogg Theora | Ogg Vorbis
use WM9 today and get Micro$oft controlling the A/V market tomorrow for free
bond is offline   Reply With Quote
Old 17th February 2004, 13:00   #5  |  Link
h9903209
Registered User
 
Join Date: May 2003
Posts: 150
wow, that's what you mean before saying "waiting for news!" ... ^^

btw, just come up a question, if I use 450 to encode, the resulting file average bitrate becomes say 550, I suppose it's because it "feels" needs that extra bitrate for better quality, right? so comparing with this new rate control, which the resulting file bitrate must be close to 450, then the qualitity would be lower (compare to the previous one with average bitrate 550) though filesize would be smaller, right?
h9903209 is offline   Reply With Quote
Old 17th February 2004, 13:05   #6  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,484
Quote:
Why 'Elysian'? Because of Champs Elysée in Paris, the final stage of the Tour de France. Maybe I will add more to this explanation later.
Vive Karl, vive la France ... ;-)
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9
Sagittaire is offline   Reply With Quote
Old 17th February 2004, 14:00   #7  |  Link
Sirber
retired developer
 
Sirber's Avatar
 
Join Date: Oct 2002
Location: Canada
Posts: 8,978
YS RealAnime is on it's way with those new features. May take some days, developping in Delphi is not as fast as developping in VB.
__________________
Detritus Software
Sirber is offline   Reply With Quote
Old 17th February 2004, 14:53   #8  |  Link
damrod
Registered User
 
damrod's Avatar
 
Join Date: Jun 2003
Location: Elyseum
Posts: 640
delphi gui is not like vb ;-))
__________________
Projects :
(dev stopped) DamBatch, MBatch
(generate mkv/mp4 files with aac(+)/vorbis/mp3 and x264/xvid/real or simple avi with h264/mp3 for fast reencoding using mencoder)
Website : Damrod.com
damrod is offline   Reply With Quote
Old 17th February 2004, 18:20   #9  |  Link
kamiller42
Registered User
 
Join Date: Jan 2004
Posts: 17
Quote:
Originally posted by Sirber
YS RealAnime is on it's way with those new features. May take some days, developping in Delphi is not as fast as developping in VB.
The IDE is different than VB, but once you learn it, you'll love it.

FYI, if you would like something a bit more useful than the component palette, try using CompBAR. Since installing it, I hide the component palette and never use it.

http://www.geocities.com/componentbar/

If you have any questions, I can try to help. You can reach me on Yahoo IM via kylethedelphiguy.
kamiller42 is offline   Reply With Quote
Old 17th February 2004, 19:20   #10  |  Link
JaTeMaTec
Registered User
 
JaTeMaTec's Avatar
 
Join Date: Feb 2004
Location: Imatra, Finland - Hyper Superator ;-)
Posts: 41
Quote:
Originally posted by kamiller42
The IDE is different than VB, but once you learn it, you'll love it.
Agree (off-topics i quess) - i used VB6 for a looong time, because it was so dooomn easy, but always: slow code, hard to implement system dll's, needed vb runtimes etc...

Once i found Delphi i realized it's Pascal with Windows and i had used pascal for 10 years before (at DOS) - so combining these 2 ideas (vb easyness and pascal knowhow, i chose Delphi. It makes much more faster code and dll's & assembler can be embedded into it easily!

AND : good luck to RealVideo 10 encoder - i like to see it ready ready (twice said hoping for a bugfree fine encoder soon to inherit all kind of containers into it from AAC (MP4) to RA10 and produce good videos for broadcasting, which is one of my hobbies (200 to 300kbps with audio from my 512kbps ADSL upload-line ...)

Peace!
__________________
Avatar: Which one came first - Egg or Vorbis?
JaTeMaTec is offline   Reply With Quote
Old 17th February 2004, 20:48   #11  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
Quote:
Originally posted by h9903209
just come up a question, if I use 450 to encode, the resulting file average bitrate becomes say 550, I suppose it's because it "feels" needs that extra bitrate for better quality, right? so comparing with this new rate control, which the resulting file bitrate must be close to 450, then the qualitity would be lower (compare to the previous one with average bitrate 550) though filesize would be smaller, right?
I am not sure I understand your question, but yes, an encoded clip at a bitrate of 450 kbps will have a smaller filesize and lower quality than 550 kbps If you are not very concerned about filesize, and you have a short clip, then perhaps the old rate control is just what you need. If you would like very accurate filesize and/or achieve constant quality for the whole clip, low and high action, then this new rate control is just right.

I used the new rate control to encode an important demo, 15 minutes or so of high and low action, categorized as very hard material. The requested parameters were 352x152 @ 800 kbps Someone else first used the old rate control, and even at 480x208 the high action scenes looked rather blurry with the old rate control. With the curve compression method the whole clip looked great throughout at 640x272. So it has already gotten some useful mileage.

Oh, while I remember, on another topic:

Previous B frame parameters

Generally these are not needed, especially not with this update, However:
patternAdaptivity: still works, but locks the B frame pattern, i.e. turns off adaptivity. Allow values are 0,1,2,3.
scalingFactor: Works only with previous rate control. Turns off adaptive quant scaling for B frames, and locks the scaling factor.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.
karl_lillevold is offline   Reply With Quote
Old 18th February 2004, 02:29   #12  |  Link
h9903209
Registered User
 
Join Date: May 2003
Posts: 150
just 2 questions:
1. is this new rate control required 2-pass? can 1-pass also use it?
2. can you explain a bit more about what it means by old way being not that "constant quality"? because high action rather blurry so it's not "constant"?
h9903209 is offline   Reply With Quote
Old 18th February 2004, 02:48   #13  |  Link
Sirber
retired developer
 
Sirber's Avatar
 
Join Date: Oct 2002
Location: Canada
Posts: 8,978
1) The new RC is 2-pass VBR only.
2) Old RC was tweaked for streaming, so it's not delivering constant quality.

Hopes this helps
__________________
Detritus Software
Sirber is offline   Reply With Quote
Old 18th February 2004, 05:02   #14  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
How to avoid a large file output for 1st pass separate encoding

Tip: when running the first pass as a separate encoding, Producer does not know about this feature yet, and thinks that it is encoding normally. It will therefore output a large file corresponding to the reference encoding. To avoid this, call the output filename something that ends with .null, for instance filename.rmvb.null Then there will be no file output.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.
karl_lillevold is offline   Reply With Quote
Old 18th February 2004, 05:12   #15  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,926
Nice finaly the possibility to turning off the Inloop filter karl and Neelesh
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004
CruNcher is offline   Reply With Quote
Old 18th February 2004, 07:14   #16  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
bond: Yes, as I was trying out the latest XviD myself, I was curious how it managed to keep the quants so constant during the 2nd pass, leading to great quality in the high action parts. So I had to learn the simple and elegant curve compression technique. Now if the GPL had been compatible with the Helix open-source RPSL license, it might have been possible to have used the XviD RC with all its advanced options as an open-source plugin in Helix for anyone to tweak on, but alas, I had to implement it from scratch. The basic technique is not too complicated, but the advanced settings are a little troublesome to get right, and are left out for now. Using a common first pass analysis format is very useful that since the .pass file can then be read by already existing tools, for instance this Java tool:
http://atlas2.tgv.net/~media-video/f...pic.php?t=3594
(And this same tool can also plot graphs indicating motion, and frame type distribution. Very nice. EDIT: version 0.40 of this tool had a minor bug where it would not read the realvideo .pass file, but the developer fixed it right after I mentioned it to him. Try it out!)

CruNcher: Agreed, finally: inloop is now an option, it took some time to convince us. First after making the rate control work as well as XviD's I realized there was still something missing. Your low + high action videos continue to be challenging for accurate rate control. For instance, one of my test clips has a profile like this:



With the new rate control, there is no overspending or filling the MSL buffer, even for this high action towards the end clip.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.

Last edited by karl_lillevold; 22nd February 2004 at 05:46.
karl_lillevold is offline   Reply With Quote
Old 18th February 2004, 10:38   #17  |  Link
damrod
Registered User
 
damrod's Avatar
 
Join Date: Jun 2003
Location: Elyseum
Posts: 640
is this a stable release?
__________________
Projects :
(dev stopped) DamBatch, MBatch
(generate mkv/mp4 files with aac(+)/vorbis/mp3 and x264/xvid/real or simple avi with h264/mp3 for fast reencoding using mencoder)
Website : Damrod.com
damrod is offline   Reply With Quote
Old 18th February 2004, 13:49   #18  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Quote:
Originally posted by damrod
is this a stable release?
I think it is still a preview. So Rv10 isn't finish yet.

I suppose Now with all this imporvement Rv10 does decerve to its Number up from 9 to 10.
iwod is offline   Reply With Quote
Old 18th February 2004, 14:21   #19  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,484
Function of this decoding RV10 key ... strength for In-Loop filtering perhaps ... ???

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV10HFE]
"strength"=dword:00000001
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9
Sagittaire is offline   Reply With Quote
Old 18th February 2004, 15:10   #20  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
@damrod: yes, it is a stable release, but not the final build going into Producer 10 Gold. I do expect only minor tweaks though, nothing in the codec itself. In particular the default inloopCutOff threshold parameters for the 'sharp' setting needs to be found.

@Sagittaire: This is a new postfilter: HFE = High Frequency Emphasis. I will add a short description of it later today. This was my colleague Neelesh' invention. (The inloop filter is not adjustable on the decode side, but its cutoff treshold can be adjusted on the /encode/ side)
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.
karl_lillevold 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 04:34.


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