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 29th January 2020, 08:42   #181  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
There may be no known UI yet, as the whole project is quite experimental still, and full control over the encoding process requires a configuration file due to the amount and complexity of parameters. So it's only for users who can handle all that easily.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 29th January 2020, 11:13   #182  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Every week the commands change in config. You add config as a preset and import commands.
EncoderApp_360.exe --SummaryVerboseness -c "encoder_randomaccess_vtm.cfg" --InputFile=video_yuv444inraw.yuv --BitstreamFile=video_1.vvc --SourceWidth=1920 --SourceHeight=1080 --FrameRate=29.970 --InputBitDepth=10 --InternalBitDepth=10 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=444 --ChromaFormatIDC=444 {--MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 [SDR] or --MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 [HDR]} --Level=6.2 --ConformanceWindowMode=0 --FramesToBeEncoded=750 --BDPCM=1 --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=30

Level 8bit 420 FullHD 4.1
Level 8bit 420 VGA<>SVGA 3.1
Level 8bit 420 EGA 2.1
Level 8bit> 444 VGA> 6.2
Level 10bit 420 4K 5.1

Function crop:
CropOffsetLeft : 10
CropOffsetTop : 10
CropOffsetRight : -10
CropOffsetBottom : -10

VVC has GOP only 16, thread only one. I don't know but level probably isn't auto.

Last edited by Jamaika; 31st January 2020 at 12:21.
Jamaika is offline   Reply With Quote
Old 30th January 2020, 23:30   #183  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Can I get a suggested config for max compression efficiency (exercise all the coding tools) 1080p SDR? Fixed QP is fine.
Blue_MiSfit is offline   Reply With Quote
Old 31st January 2020, 11:56   #184  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
New version 7.3 plus fix Jamaika plus updates 31.01.2020
#define JVET_O1143_SUBPIC_BOUNDARY 1 // treat subpicture boundary as piucture boundary
#define JVET_P0101_POC_MULTILAYER 1 // POC derivation for pictures in dependent layers
#define JVET_P0117_PROFILE_TIER_LEVEL_SCALABILITY 1 // JVET-P0117: profile, tier and level for VVC scalability
#define JVET_Q0042_VUI 1 // Modifications to VUI syntax
#define JVET_Q0054 1 // fix for long luma deblocking decision
#define JVET_Q0055_MTS_SIGNALLING 1 // JVET-Q0055: Check for transform coefficients outside the 16x16 area
#define JVET_Q0089_SLICE_LOSSLESS_CODING_CHROMA_BDPCM 1 // JVET-Q0089: RRC slice-level switch for lossless coding and one SPS flag for luma and chroma BDPCM.
#define JVET_Q0110_Q0785_CHROMA_BDPCM_420 1 // JVET-Q0110/Q0785: Enable chroma BDPCM for 420, separate contexts for chroma BDPCM and bug-fixes.
#define JVET_Q0114_CONSTRAINT_FLAGS 1 // JVET-Q0114: AHG9: A few more general constraints flags
#define JVET_Q0117_PARAMETER_SETS_CLEANUP 1 // JVET-Q0117: cleanups on parameter sets
#define JVET_Q0119_CLEANUPS 1 // JVET-Q0119: AHG12: Cleanups on signalling of subpictures, tiles, and rectangular slices
#define JVET_Q0121_DEBLOCKING_CONTROL_PARAMETERS 1 // JVET-Q0121: Add deblocking control parameters for Cb and Cr and extend the parameter ranges
#define JVET_Q0128_DMVR_BDOF_ENABLING_CONDITION 1 // JVET-Q0128: Cleanup of enabling condition for DMVR and BDOF
#define JVET_Q0147_JCCR_SIGNALLING 1 // JVET-Q0147: Conditional signaling of sps_joint_cbcr_enabled_flag based on ChromaArrayType
#define JVET_Q0150 1 // fix for ALF virtual horizontal CTU boundary processing
#define JVET_Q0155_COLOUR_ID 1 // JVET-Q0155: move colour_plane_id from PH to SH
#define JVET_Q0156_STSA 1 // JVET-Q0156: Enable inter-layer prediction for STSA
#define JVET_Q0249_ALF_CHROMA_CLIPFLAG 1 // JVET-Q0249: Cleanup of chroma clipping flags for ALF
#define JVET_Q0267_RESET_CHROMA_QP_OFFSET 1 // JVET-Q0267: Reset chroma QP offsets at the start of each chroma QP offset group
#define JVET_Q0293_REMOVAL_PDPC_CHROMA_NX2 1 // JVET-Q0293: Removal of chroma Nx2 blocks in PDPC
#define JVET_Q0297_MER 1 // JVET_Q0297: Merge estimation region
#define JVET_Q0353_ACT_SW_FIX 1 // JVET-Q0353: Bug fix of ACT
#define JVET_Q0420_PPS_CHROMA_TOOL_FLAG 1 // JVET-Q0420: add pps_chroma_tool_offsets_present_flag in PPS
#define JVET_Q0433_MODIFIED_CHROMA_DIST_WEIGHT 1 // modification of chroma distortion weight (as agreed during presentation of JVET-Q0433)
#define JVET_Q0444_AMVR_SIGNALLING 1 // JVET-Q0444: Conditional signaling of sps_affine_amvr_enabled_flag based on sps_amvr_enabled_flag
#define JVET_Q0446_MIP_CONST_SHIFT_OFFSET 1 // JVET-Q0446: MIP with constant shift and offset
#define JVET_Q0447_WP_PARAM_ESTIM 1 // JVET-Q0447: Add search iterations for method 2,3 and 4
#define JVET_Q0468_Q0469_MIN_LUMA_CB_AND_MIN_QT_FIX 1 // JVET-Q0468: add support of min Luma coding block size; JVET-Q0469: fix for signaling of Intra Chroma Min QT size
#define JVET_Q0471_CHROMA_QT_SPLIT_ON_HEIGHT 1 // JVET-Q0471: Chroma QT split
#define JVET_Q0480_RASTER_RECT_SLICES 1 // JVET-Q0480: Eliminate redundant slice height syntax when in raster rectangular slice mode (tile_idx_delta_present_flag == 0)
#define JVET_Q0481_PARTITION_CONSTRAINTS_ORDER 1 // JVET-Q0481: Ordering of partition constraints syntax elements in the SPS and PH
#define JVET_Q0483_CLIP_TMVP 1 // JVET-Q0483: Clip TMVP when no scaling is applied
#define JVET_Q0487_SCALING_WINDOW_ISSUES 1 // JVET-Q0487: Fix scaling window issues when scaling ratio is 1:1
#define JVET_Q0495_NLALF_CLIP_CLEANUP 1 // JVET-Q0495: Cleanup of clipping table for NL-ALF
#define JVET_Q0500_CCLM_REF_PADDING 1 // JVET-Q0500: Reference samples padding for CCLM
#define JVET_Q0501_PALETTE_WPP_INIT_ABOVECTU 1 // JVET-Q0501: Initialize palette predictor from above CTU row in WPP
#define JVET_Q0503_Q0712_PLT_ENCODER_IMPROV_BUGFIX 1 // JVET-Q0503/Q0712: Platte encoder improvement/bugfix
#define JVET_Q0512_ENC_CHROMA_TS_ACT 1 // JVET-Q0512: encoder-side improvement on enabling chroma transform-skip for ACT
#define JVET_Q0516_MTS_SIGNALLING_DC_ONLY_COND 1 // JVET-Q0516/Q0685: disable MTS when there is only DC coefficient
#define JVET_Q0517_RPR_AFFINE_DS 1 // JVET-Q0517: affine down-sampling filters for RPR
#define JVET_Q0695_CHROMA_TS_JCCR 1 // JVET-Q0695: Enabling the RD checking of chroma transform-skip mode for JCCR at encoder
#define JVET_Q0775_PH_IN_SH 1 // JVET-Q0755: Allow picture header in slice header
#define JVET_Q0784_LFNST_COMBINATION 1 // lfnst signaling, latency reduction and a bugfix for scaling from Q0106, Q0686, Q0133
#define JVET_Q0787_SUBPIC 1 // JVET-Q0787: fix subpicture location signalling
#define JVET_Q0795_CCALF 1 // Cross-component ALF
#define JVET_Q0806 1 // Geo related adoptions (JVET-Q0059, JVET-Q0077, JVET-Q0123, JVET-Q0188, JVET-Q0242_GEO, JVET-Q0309, JVET-Q0365 and JVET-Q0370)
#define JVET_Q0814_DPB 1 // JVET-Q0814: DPB capacity is based on picture units regardless of the resoltuion
#define JVET_Q0819_PH_CHANGES 1 // JVET-Q0819: Combination of PH related syntax changes
#define JVET_Q0820_ACT 1 // JVET-Q0820: ACT bug fixes and reversible ACT transform
#define FIX_INIT_RESET_BEFORE_DEBLOCK 1

https://www.sendspace.com/file/ag482y
Jamaika is offline   Reply With Quote
Old 31st January 2020, 18:56   #185  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
This is amazing. I did some fixed QP tests at 1 Mbps 1080p SDR against x265 placebo, and the VVC version was dramatically better. All the DCT goo from HEVC was totally gone. Soft, yes, but actually watchable.
Blue_MiSfit is offline   Reply With Quote
Old 1st February 2020, 14:57   #186  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Quote:
Originally Posted by Blue_MiSfit View Post
This is amazing. I did some fixed QP tests at 1 Mbps 1080p SDR against x265 placebo, and the VVC version was dramatically better. All the DCT goo from HEVC was totally gone. Soft, yes, but actually watchable.
How does it compare to AV1?
iwod is offline   Reply With Quote
Old 2nd February 2020, 03:35   #187  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Still testing that

Last edited by Blue_MiSfit; 2nd February 2020 at 23:02.
Blue_MiSfit is offline   Reply With Quote
Old 2nd February 2020, 21:40   #188  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by nakTT View Post
Hi, how do I use it with a GUI? I mean something like MeGUI or any other way other than a command line. Thank you in advance.
I don't think anyone made a GUI so far 'cause this whole thing is still a work in progress. Even the command line itself has a pretty "rudimental" (pass me this term) syntax as it takes lossless uncompressed inputs only and is completely different from x262/x264/x265.
Besides it's still not optimised to scale in a multi-threading environment and it also lacks decoding support by pretty much everything other than its internal decoder (decoder.exe).
It's really way too early, but it's definitely worth to have to test it and play with it.
Just don't expect GUIs and mainstream support to pop up out of nowhere.

(By the way, if there's a GUI or something I'd be extremely happy to be proven wrong. As a side note, I noticed that XP support was removed a few releases ago but I actually managed to make it run anyway, so it's just a flag/target in the compiler. @Jamaika... I think you should keep targeting XP for the x86 32bit version as the encoder is absolutely compatible. If you don't wanna do it for any reason, just let me know and I will release my patched XP compatible binaries. Oh and by the way, thank you very much indeed for this new release. ).

Last edited by FranceBB; 2nd February 2020 at 21:42.
FranceBB is offline   Reply With Quote
Old 2nd February 2020, 23:02   #189  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
I did the same test with AV1. I got surprisingly similar results, at least in my initial test clip.

In still frame comparison I preferred the VVC version 100% of the time, but this changed a bit in motion. I still preferred the VVC most of the time, but I was often hard pressed to tell any differences, and I did prefer AV1 in a few cases.

I'm sure a lot of the final results in real world systems will depend heavily on psy tuning and AQ.

In this very quick unscientific test these codecs are clearly in the same ballpark, and way ahead of HEVC. I'm surprised by this, since the BBC report showed HEVC and AV1 basically neck and neck, and with VVC way ahead. They were doing a scientific PSNR analysis and I'm doing a quick and dirty subjective comparison though...
Blue_MiSfit is offline   Reply With Quote
Old 3rd February 2020, 05:35   #190  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
Quote:
Originally Posted by FranceBB View Post
@Jamaika... I think you should keep targeting XP for the x86 32bit version as the encoder is absolutely compatible. If you don't wanna do it for any reason, just let me know and I will release my patched XP compatible binaries. Oh and by the way, thank you very much indeed for this new release. ).
Quote:
Originally Posted by Blue_MiSfit View Post
In this very quick unscientific test these codecs are clearly in the same ballpark, and way ahead of HEVC. I'm surprised by this, since the BBC report showed HEVC and AV1 basically neck and neck, and with VVC way ahead. They were doing a scientific PSNR analysis and I'm doing a quick and dirty subjective comparison though...
I'm aware that my activities aren't professional. I'm not a computer scientist. I merged patches manually in CodeBlock a few hours and out of curiosity I tested what this codec has visual capabilities. It's pathetic because a professionalist does it in five minutes. Then the codec test. Detection of critical errors and irritation VVC developers. Was my volunteering helpful? I made the VVC makers laugh that I was using GCC. I remind you that recent versions of GCC8.0 aren't stable for VVC. GCC8 doesn't support functions without parentheses {}. As an amateur I do not know if the codec is x86 or x64. The only premise for x86 is the libgomp linux plugin. Opensource VVC is available, but who exactly is it for?
My conclusions. This isn't codec for a doom9 forum user with a cheap camera in hand. Converted video source by x262/x264/x265 and then by vvc makes no sense. This codec is made by professionals for specific TV company. The developers have some VVC quality tests BBC out there somewhere. Apparently it's not their company. Their product is targeted at television networks. Adding multi-threads is done in five minutes and isn't currently priority.

Is my codec suitable for testing? Hmmm... Added additions have not been approved by the main moderators. Some work will go into the trash. Many features and security features may not yet be related or subtracted. The corporation researches it on its own video analyzers.

Last edited by Jamaika; 3rd February 2020 at 08:52.
Jamaika is offline   Reply With Quote
Old 3rd February 2020, 09:00   #191  |  Link
iwod
Registered User
 
Join Date: Apr 2002
Posts: 756
Quote:
Originally Posted by Blue_MiSfit View Post
I did the same test with AV1. I got surprisingly similar results, at least in my initial test clip.

In still frame comparison I preferred the VVC version 100% of the time, but this changed a bit in motion. I still preferred the VVC most of the time, but I was often hard pressed to tell any differences, and I did prefer AV1 in a few cases.

I'm sure a lot of the final results in real world systems will depend heavily on psy tuning and AQ.

In this very quick unscientific test these codecs are clearly in the same ballpark, and way ahead of HEVC. I'm surprised by this, since the BBC report showed HEVC and AV1 basically neck and neck, and with VVC way ahead. They were doing a scientific PSNR analysis and I'm doing a quick and dirty subjective comparison though...
If I remember correctly the AV1 used in BBC results were 1 pass results. ( Need to double check when I have time )

Oh well I guess it is game on then. EVE has shown you could push AV1 further with another 20% bitrate reduction at the expense of another 50% INCREASE in encoding time compared to libaom.

Last edited by iwod; 4th February 2020 at 11:10.
iwod is offline   Reply With Quote
Old 3rd February 2020, 20:55   #192  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Yeah all my testing was 1 pass fixed QP, since benchmarking rate control is not fair at this point

I continue to be suspicious of EVE - I've never been able to evaluate it and I'm not the only one. Has anyone ever actually used EVE VP9 or AV1?
Blue_MiSfit is offline   Reply With Quote
Old 4th February 2020, 03:02   #193  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
Quote:
Originally Posted by Blue_MiSfit View Post
Yeah all my testing was 1 pass fixed QP, since benchmarking rate control is not fair at this point

I continue to be suspicious of EVE - I've never been able to evaluate it and I'm not the only one. Has anyone ever actually used EVE VP9 or AV1?
what i find suspicious is that it isn't included in the moscow state university comparison. Why would they not give them a copy of their encoders to do an unbiased comparisons with unless it isn't as good as they claim.
hajj_3 is offline   Reply With Quote
Old 4th February 2020, 17:35   #194  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by hajj_3 View Post
what i find suspicious is that it isn't included in the moscow state university comparison. Why would they not give them a copy of their encoders to do an unbiased comparisons with unless it isn't as good as they claim.
Are there any available EVE encoded streams to evaluate yet? I've only seen Excel plots and screen shots.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 8th February 2020, 17:19   #195  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
https://www.sendspace.com/file/luyjru

New updates and commands
EncoderApp_360.exe --SummaryVerboseness -c "encoder_randomaccess_vtm_2.cfg" --InputFile=113.yuv --BitstreamFile=video_2.vvc --SourceWidth=1280 --SourceHeight=720 --FrameRate=25.000 --InputBitDepth=8 --InternalBitDepth=8 --OutputBitDepth=8 --MSBExtendedBitDepth=8 --InputChromaFormat=420 --ChromaFormatIDC=420 --ConformanceWindowMode=0 --FramesToBeEncoded=750 --MatrixCoefficients=1 --InputColorPrimaries=-1 --LMCSSignalType=0 --Level=4 --BDPCM=1 --Tier=main --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=28 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32

EncoderApp_360.exe --SummaryVerboseness -c "encoder_randomaccess_vtm_2.cfg" --InputFile=111.yuv --BitstreamFile=video_1.vvc --SourceWidth=1280 --SourceHeight=720 --FrameRate=25.000 --InputBitDepth=10 --InternalBitDepth=10 --OutputBitDepth=10 --MSBExtendedBitDepth=10 --InputChromaFormat=422 --ChromaFormatIDC=422 --ConformanceWindowMode=1 --FramesToBeEncoded=750 --MatrixCoefficients=9 --InputColorPrimaries=1 --LMCSSignalType=2 --Level=6.2 --BDPCM=1 --Tier=high --HashME=1 --IBC=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --QP=28 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32

#define JVET_Q0117_PARAMETER_SETS_CLEANUP 1 // JVET-Q0117: cleanups on parameter sets
#define JVET_Q0786_PTL_only 1 // JVET-Q0786: modifications to VPS syntax - PTL part only (signal PTL for single layer OLSs)
#define JVET_Q0203_MULTI_SLICE_IN_TILE 1 // JVET-Q0203: Signalling of multiple rectangular slices within a tile
#define JVET_Q0817 1 // JVET_Q0817: Remove the constraint on single_slice_per_subpic_flag
#define JVET_Q0244 1 // JVET-Q0244 Aspect 3: Signal the slice width(height) in tiles when the number of tile columns(rows) is greater than 1.
#define JVET_Q0246_VIRTUAL_BOUNDARY_ENABLE_FLAG 1 // JVET-Q0246: virtual boundary enable flag in the SPS.
#define JVET_Q0151_Q0205_ENTRYPOINTS 1 // JVET-Q0151 & JVET-Q0205: Make mandatory the tile offsets signalling and move the entropy_coding_sync_enabled_flag entry_point_offsets_present_flag syntax elements to the SPS from the PPS
#define JVET_Q0468_Q0469_MIN_LUMA_CB_AND_MIN_QT_FIX 1 // JVET-Q0468: add support of min Luma coding block size; JVET-Q0469: fix for signaling of Intra Chroma Min QT size


Below quality QP = 28 is visible blur of pixels

Last edited by Jamaika; 10th February 2020 at 09:11.
Jamaika is offline   Reply With Quote
Old 26th February 2020, 08:38   #196  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
New VVC codec v8.0 26.12.2019 plus updates https://github.com/Jamaika1/libbpg_jvetvvc
https://www.sendspace.com/file/0l7su7

Any 4K photo test is unbelievable. Compression time lasts for one and a half hours of one frame I. The following example shows VVC Q28 CTU32 as 350kb.
https://imgsli.com/MTI1NDA

Last edited by Jamaika; 26th February 2020 at 09:01.
Jamaika is offline   Reply With Quote
Old 29th February 2020, 13:18   #197  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
First video decoder VVC analyzer Q1 2020
https://vicuesoft.com/products/analyzer
Jamaika is offline   Reply With Quote
Old 2nd March 2020, 01:52   #198  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Jamaika View Post
Any 4K photo test is unbelievable. Compression time lasts for one and a half hours of one frame I. The following example shows VVC Q28 CTU32 as 350kb.
https://imgsli.com/MTI1NDA
Wow, that's some very impressive image compression. 1.5 hours is completely nuts for a still image, though. Of course, with more interframe techniques applied to intraframe coding, it makes since IDRs will be relatively slower versus other frame types than before (as we saw with HEVC).
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 9th April 2020, 10:23   #199  |  Link
Jamaika
Registered User
 
Join Date: Jul 2015
Posts: 697
New codec JVET VVC 09.04.2020 UNTESTED
https://www.sendspace.com/file/e27jcx
Jamaika is offline   Reply With Quote
Old 13th April 2020, 20:00   #200  |  Link
hajj_3
Registered User
 
Join Date: Mar 2004
Posts: 1,120
https://bitmovin.com/compression-standards-vvc-2020/

A blog from 2 months ago that shows VVC is 35% more efficient in regards to PSNR than HEVC. Requires 1.7x more cpu than HEVC to decode and requires 10x more cpu than HEVC to encode.

Last edited by hajj_3; 13th April 2020 at 20:06.
hajj_3 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 22:53.


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