VideoHelp Forum
+ Reply to Thread
Page 1 of 3
1 2 3 LastLast
Results 1 to 30 of 72
Thread
  1. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    tom's has done a nice comparison between the two and as expected x265 wins hands down:

    http://www.tomshardware.com/reviews/x265-hevc-encoder,3565.html

    the important points to take away from the article are these:

    It’s currently x86-only (albeit with support for advanced instruction sets like AVX2), lacks B-frame support (preventing it from achieving maximum compression), and doesn’t yet include some of the optimizations taken from x264 (like look-ahead and rate control).
    With that in mind, let’s take a quick peek at how pre-alpha x265 stacks up against the well-optimized x264. For this one, we're using the following command: x264 --preset placebo --sar 1920:1080 --fps 24 --frames 500 --psnr -o x264Kimonoq24.264 Kimono1_1920x1080_24.yuv, again with quantization parameters between 24 and 42. We could have used the --tune psnr switch to generate higher values, though this negatively affects subjective quality compared to the settings used here.
    x265 --input Kimono1_1920x1080_24.yuv --width 1920 --height 1080 --rate 24 -f 240 -o q24_Kimono1.out --rect --max-merge 1 --hash 1 --wpp --gops 4 --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip, with quantization parameters between 24 and 42. It's notable that we're employing GOP (Group Of Picture)-level parallelism to keep our quad-core -4770K busy. I'm also adding the --cpuid switch to control the instruction sets being used.
    performance is abysmal as the moment, i think they said they are getting 4 fps on a 4770k though the guys behind x265 hope to be able to see real time 1080p30 encodes on xeon based server with 16 physical cores by next month.

    the good thing is that tom's didn't skimp on the x264 settings, they could have used somewhat more aggressive settings but "placebo" should leave little wiggle room for x264 apologists to moan about.

    i can't help but think that this would be a perfect time for nvidia to strike with a cuda based h265 reference encoder of their own; at 4 fps with the fastest quad core haswell, a gpu powered h265 encoder that can hit say half real time speed on a mid range video card would certainly be a big selling point for nvidia.

    edit: extremetech also did a comparison and in there's x265's win was by a larger margin:

    http://www.extremetech.com/computing/162027-h-265-benchmarked-does-the-next-generation...o-expectations
    Quote Quote  
  2. Extremetech didn't say which h.264 encoder they used. Or what settings beyond constant quantizer values.

    Oh, nevermind. I see in the reader comments the author reported that he used (x264). That wasn't there this morning when I read the story. I don't know why they started with such a poor source (full of macroblocks).

    Of course, everybody expects h.265 to do better than h.264. It uses more advanced techniques.

    Anyone seen MulticoreWare's OpenCL-accelerated version of x264?
    Last edited by jagabo; 23rd Jul 2013 at 20:45.
    Quote Quote  
  3. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Apologies for the semi-OT, but could someone please get the .265 Windows binary from

    Code:
    https://mega.co.nz/#!fF51VYiD!VBnffARHirnKbDI7GrP9aAdKzEBU5Dl-7-BUjzChlwE
    and upload a copy to this thread?

    The stupid mega.co.nz does not work with Opera. With Seamonkey, it does attempt to install some sort of spyware on my machine.
    Quote Quote  
  4. Attached...
    Image Attached Files
    Quote Quote  
  5. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    One million THANKS, jagabo
    Quote Quote  
  6. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    reading through the evaluators guide makes it seem like x265 already supports a tons of advanced encoding features, i don't know what tom's means by "doesn't support b frames", the documentation makes it clear that it not only supports b-frames but weighted p, weighted b, rdo and a slew of other image enhancing features.
    Quote Quote  
  7. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Just perusing the docs for the time being... hmmmmm........

    Still am not sot sure if this crude binary is worth the hassle, certainly it is so half-assed as the Microsoft VC-1 SDK sample-code , and even worse than ffmpeg2theora --- which at least accepts being "piped" with avs2yuv

    IMPORTANT:

    **INPUT FILE must be a raw video – 8bit I420 planar in either YUV or Y4M format.
    But fear not --- if I don't manage to create some sample encodes with this sub-pre-alpha x265,

    vhelp will, granted
    Quote Quote  
  8. This thread is titled ¨ x265 vs x264¨ and everybody so far talked blah... blah... blah... too much!
    Nobody actually posted what are the exact differences between x264 and x 265.

    Out many differences I will cite only two differences...
    1) There are two loop-filters in H265 for reducing macroblock artifacts, and to achieve higher compression.
    2) H265 does not support Context Adaptive Variable Length Coding (CAVLC)
    Rest differences I leave up to readers.

    Even though original source code is released under BSD, Mac users are not able to compile it successfully. At this time of writing only MSVS 2010+SP1 or later supports Advanced Vector Extensions (AVX). The people who do not have Hanswell, SandyBridge, AMD Bulldozer, or later are out of HEVC game here. First upgrade your system, we will talk. And, Here I AM to talk.
    Last edited by enim; 24th Jul 2013 at 01:20.
    Quote Quote  
  9. Member vhelp's Avatar
    Join Date
    Mar 2001
    Location
    New York
    Search Comp PM
    sorry, was busy working on dev project and finally figure out the problem there. anyway. too tired now and going to bed.

    enim, the only way for anyone to "compare" 265 to 264 is by first doing their own 265 encodes, based on the said h265 (hevc) encoder. then, compare that to an h264 encoder of their choice. that's why all the talk. anyway.

    i can't be bothered with the x265.exe (x265 23.07.2013 (x86).zip) app because it is not a 32 bit, ..it is 64bit. won't load on my machine, gives me error message:

    "the procedure entry point interlockedcomparedexchange64 could not be located in the dynamic link library KERNEL32.dll"

    i guess they (or some entities) are excluding 32bit os's now. so i'm out of this one.
    Quote Quote  
  10. When I said...
    and everybody so far talked blah... blah... blah... too much!
    I am not addressing it to any forum members here, but it is in general, there is too much blah... blah... blah... on web without knowing technical details. At one point, I tried to bring it to the notice with humor that I am extending current HEVC to SDHEVC on IBMPC-AT with WordStar4 and Hanswell, SandyBridge or AMD Bulldozer PCs with MSVS2010SP1 are given out for the free to the volunteers, some missed the whole point and some considered it as a troll. Some one told me that you can only talk and understand the people are on same level. I can not help people with many barriers.

    i can't be bothered with the x265.exe (x265 23.07.2013 (x86).zip) app because it is not a 32 bit, ..it is 64bit. won't load on my machine, gives me error message:
    According to your feedback, the people with 32 bit OS are also out of HEVC game.
    Even though I am on 64 bit OS, I need to get latest update to compile. For which I do not see any possibilities. Itś also too late here and time to go.
    Last edited by enim; 24th Jul 2013 at 02:44.
    Quote Quote  
  11. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by vhelp View Post
    sorry, was busy working on dev project and finally figure out the problem there. anyway. too tired now and going to bed.

    enim, the only way for anyone to "compare" 265 to 264 is by first doing their own 265 encodes, based on the said h265 (hevc) encoder. then, compare that to an h264 encoder of their choice. that's why all the talk. anyway.


    i can't be bothered with the x265.exe (x265 23.07.2013 (x86).zip) app because it is not a 32 bit, ..it is 64bit. won't load on my machine, gives me error message:

    "the procedure entry point interlockedcomparedexchange64 could not be located in the dynamic link library KERNEL32.dll"

    i guess they (or some entities) are excluding 32bit os's now. so i'm out of this one.
    Someone please correct me if I'm wrong this time ---

    --- it's not a matter of 32-bit OS versus 64-bit OS, it's because the application was written/compiled without support for Windows XP

    Up-to-date versions of VisualStudio do not have this stupid artificial limitation anymore, BUT when the programmers themselves have a blind faith in the greatest and latest MISTAKES of Microsoft, there ain't much we can do (except call them bad names, of course).
    Quote Quote  
  12. Someone please correct me if I'm wrong this time --- ...
    just making it WinXP compatible wouldn't be enough, from the "x265 Evaluation Guide 07-23-13.pdf":
    SYSTEM REQUIREMENTS
    Hardware: AVX capable CPU recommended
    At least 8GB of RAM
    Software: Win7/8 x86_64
    Microsoft Visual C++ Redistributable Update 3
    -> assuming this is correct, anything with a CPU from before 2011 or Windows XP and at least 8GB RAM is out.
    Quote Quote  
  13. The H265 whole game is based on to support bit depth more than 8bits at least 10bits, upto 12bits.

    This release does not even supports all aspects of Main 10 HEVC profile and Rec. 2020 color space in full. As the Main 10 profile allows for a bit depth of 8-bits to 10-bits per color with 4:2:0 chroma sub-sampling. The readers of this post who are on 64bit OS can try to encode 10bit sample with this release to verify my claim. Forget that you can ever encode HEVC Ultra HD (4K) with this release. There is a long...very long.. way to go and rocky road ahead. I am too tired and I have no more energy and time to join the team of .....
    ---------------------------------------------------------------------------------------------------------------------------------------------------
    Today morning when I was jogging with my better (sometimes bitter) half, we passed by a backyard of holy place, where a priest was preaching to the buffalo. Out of curiosity I asked the priest who is the buffalo here? He replied ¨You¨. I was really confused and amused. I asked by bitter-half ¨Do You Think So?¨ The reply was ¨NO, I think you are stupid.¨ I asked ¨Why?¨. The reply was ¨You nerd, fallen for me, I am smarter than you.¨ Not too far, I pretended I fall down while jogging, my better-bitter half rushed to me and said "Grab my hand, I will help you." I looked in to the eyes and smirked. The reply was I got it, idiot.
    Last edited by enim; 14th Aug 2013 at 00:45.
    Quote Quote  
  14. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by deadrats View Post
    reading through the evaluators guide makes it seem like x265 already supports a tons of advanced encoding features, i don't know what tom's means by "doesn't support b frames", the documentation makes it clear that it not only supports b-frames but weighted p, weighted b, rdo and a slew of other image enhancing features.
    Then please feel free to edit the Wikipedia article about x265

    x265 is currently limited to x86 CPUs, a bit depth of 8-bits per color, and does not support B-frames.[1][2][3] x265 does not currently support some of the optimizations that were made with x264 such as lookahead, multi-pass encoding, and rate control.[1][2][3] MulticoreWare has said that based on peak signal-to-noise ratio (PSNR) the decrease in bit rate when going from x264 to x265 will be between 25% and 35% and that coding efficiency for x265 will increase as improvements are made to the encoder.[2] In a video comparison done in July 2013 by ExtremeTech with an encoding preset of veryslow it took 129 seconds to encode a video clip with x264 and 247 seconds to encode it with x265.[1]
    {
    http://en.wikipedia.org/wiki/X265#Technical_details
    }
    Quote Quote  
  15. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    [ place commercial here ]
    Last edited by El Heggunte; 30th Jul 2013 at 10:06. Reason: :-)
    Quote Quote  
  16. Issue is not in encoding performance as encoding is performed only once - issue is how decoding is performed compared to existing H.264 decoders.

    Is there any decent H.265 decoder that will run on 1080p30 with for example Core2Duo?
    Quote Quote  
  17. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Time for an overdue reply... Better late than jamais, I hope
    enim, apologies for the looooong delay, but your name was on my Ignore List

    Originally Posted by enim View Post
    ...........
    Even though original source code is released under BSD, Mac users are not able to compile it successfully.

    At this time of writing only MSVS 2010+SP1 or later supports Advanced Vector Extensions (AVX).

    The people who do not have Hanswell, SandyBridge, AMD Bulldozer, or later are out of HEVC game here.
    BOOLSHEET --- and here is the proof:

    Yasm 1.2.0 Release Notes

    Features

    Changes from 1.1.0 to 1.2.0:

    Add AVX2 instructions (rev 11 of Intel AVX reference) (#227).
    Allow 64-bit LFS/LGS/LSS.
    Improve LAR instruction support (#224).
    Default win64 .xdata to nobase, add support for “..imagebase” (#135).
    Fix “TIMES” relocation handling.
    Fix no-suffix push and pop in GAS mode (#212).
    See the bug tracker for a full list of bug fixes.
    Besides, from http://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Compiler_and_assembler_support ,

    Compiler and assembler support

    Recent releases of GCC starting with version 4.6 (although there was a 4.3 branch with certain support) and the Intel Compiler Suite starting with version 11.1 support AVX.
    And finally,

    Operating system support

    AVX adds new register-state through the 256-bit wide YMM register file, so explicit operating system support is required to properly save & restore AVX's new registers between context switches. The following operating system versions will support AVX:

    Apple OS X: Support for AVX added in 10.6.8 (Snow Leopard) update released on June 23, 2011.
    Linux: supported since kernel version 2.6.30, released on June 9, 2009.
    Windows: supported in Windows 7 SP1 and Windows Server 2008 R2 SP1; hotfix 2517374 available for non-SP1 version of Windows Server 2008 R2.; Windows 8
    Windows Server 2008 R2 SP1 with Hyper-V requires a hotfix to support AMD AVX (Opteron 6200 and 4200 series) processors, kb 2568088
    FreeBSD in a patch submitted on 21 January 2012, which was included in the 9.1 stable release
    DragonFly BSD added support in early 2013.
    Solaris 10 Update 10 and Solaris 11
    {
    http://en.wikipedia.org/wiki/Advanced_Vector_Extensions#Operating_system_support
    }
    Quote Quote  
  18. Originally Posted by El Heggunte View Post
    Time for an overdue reply... Better late than jamais, I hope
    enim, apologies for the looooong delay, but your name was on my Ignore List

    Originally Posted by enim View Post
    ...........
    Even though original source code is released under BSD, Mac users are not able to compile it successfully.

    At this time of writing only MSVS 2010+SP1 or later supports Advanced Vector Extensions (AVX).

    The people who do not have Hanswell, SandyBridge, AMD Bulldozer, or later are out of HEVC game here.
    BOOLSHEET --- and here is the proof:
    Is there any AVX code inside x265? If not there whole discussion about compilers is irrelevant.
    Without inline-manual asm code that explicitly use AVX, code after compilation should be capable to run on AVX and non-AVX capable CPU's.
    Quote Quote  
  19. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by pandy View Post
    ................
    Is there any AVX code inside x265?
    Yes, lots of AVX code which take ages to compile

    Without inline-manual asm code that explicitly use AVX,

    code after compilation should be capable to run on AVX and non-AVX capable CPU's.
    Wrong. Just like x264, x265 will use the CPU-optimizations available on the host machine. If this latter supports AVX, then AVX will be used as necessary; otherwise, SSE2, SSE3, SSSE3, SSE4.1, or SSE4.2 will be used instead.
    Last edited by El Heggunte; 2nd Aug 2013 at 05:13. Reason: .....
    Quote Quote  
  20. Originally Posted by El Heggunte View Post
    Originally Posted by pandy View Post
    ................
    Is there any AVX code inside x265?
    Yes, lots of AVX code which take ages to compile

    Without inline-manual asm code that explicitly use AVX,

    code after compilation should be capable to run on AVX and non-AVX capable CPU's.
    Wrong. Just like x264, x265 will use the CPU-optimizations available on the host machine. If this latter supports AVX, then AVX will be used as necessary; otherwise, SSE2, SSE3, SSSE3, SSE4.1, or SSE4.2 will be used instead.

    This is contradictory - OR AVX is used explicitely or NOT? And optimization is up to the compiler - from my point of view there is huge and cardinal difference for plain C(+,++,# etc) code is optimized by compiler and C(+,++,# etc) with INLINE ASM and/or other PRAGMA's compiled by compiler.
    Quote Quote  
  21. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by pandy View Post
    .......This is contradictory
    Why would it be "contradictory"
    Quote Quote  
  22. Originally Posted by El Heggunte View Post
    Originally Posted by pandy View Post
    .......This is contradictory
    Why would it be "contradictory"

    Because it is different to leave compiler decision how to perform procedure or function with particular command extension (MMX,SSE,AVX) from explicitly create procedure or function in ASM and use it later automatically later based on capabilities (supported extensions) reported by CPU like this

    Code:
    ;-----------------------------------------------------------------------------
    ; void mbtree_propagate_cost( int *dst, uint16_t *propagate_in, uint16_t *intra_costs,
    ;                             uint16_t *inter_costs, uint16_t *inv_qscales, float *fps_factor, int len )
    ;-----------------------------------------------------------------------------
    %macro MBTREE 0
    cglobal mbtree_propagate_cost, 7,7,7
        add        r6d, r6d
        lea         r0, [r0+r6*2]
        add         r1, r6
        add         r2, r6
        add         r3, r6
        add         r4, r6
        neg         r6
        pxor      xmm4, xmm4
        movss     xmm6, [r5]
        shufps    xmm6, xmm6, 0
        mulps     xmm6, [pf_inv256]
        movdqa    xmm5, [pw_3fff]
    .loop:
        movq      xmm2, [r2+r6] ; intra
        movq      xmm0, [r4+r6] ; invq
        movq      xmm3, [r3+r6] ; inter
        movq      xmm1, [r1+r6] ; prop
        punpcklwd xmm2, xmm4
        punpcklwd xmm0, xmm4
        pmaddwd   xmm0, xmm2
        pand      xmm3, xmm5
        punpcklwd xmm1, xmm4
        punpcklwd xmm3, xmm4
    %if cpuflag(fma4)
        cvtdq2ps  xmm0, xmm0
        cvtdq2ps  xmm1, xmm1
        fmaddps   xmm0, xmm0, xmm6, xmm1
        cvtdq2ps  xmm1, xmm2
        psubd     xmm2, xmm3
        cvtdq2ps  xmm2, xmm2
        rcpps     xmm3, xmm1
        mulps     xmm1, xmm3
        mulps     xmm0, xmm2
        addps     xmm2, xmm3, xmm3
        fnmaddps  xmm3, xmm1, xmm3, xmm2
        mulps     xmm0, xmm3
    %else
        cvtdq2ps  xmm0, xmm0
        mulps     xmm0, xmm6    ; intra*invq*fps_factor>>8
        cvtdq2ps  xmm1, xmm1    ; prop
        addps     xmm0, xmm1    ; prop + (intra*invq*fps_factor>>8)
        cvtdq2ps  xmm1, xmm2    ; intra
        psubd     xmm2, xmm3    ; intra - inter
        cvtdq2ps  xmm2, xmm2    ; intra - inter
        rcpps     xmm3, xmm1    ; 1 / intra 1st approximation
        mulps     xmm1, xmm3    ; intra * (1/intra 1st approx)
        mulps     xmm1, xmm3    ; intra * (1/intra 1st approx)^2
        mulps     xmm0, xmm2    ; (prop + (intra*invq*fps_factor>>8)) * (intra - inter)
        addps     xmm3, xmm3    ; 2 * (1/intra 1st approx)
        subps     xmm3, xmm1    ; 2nd approximation for 1/intra
        mulps     xmm0, xmm3    ; / intra
    %endif
        cvtps2dq  xmm0, xmm0
        movdqa [r0+r6*2], xmm0
        add         r6, 8
        jl .loop
        RET
    %endmacro
    https://bitbucket.org/multicoreware/x265/src/de3e6c30815ccc11ed6a33835f7d0c0d13e07f8c/...asm?at=default


    You have detection of the CPU capabilities and explicitly, manually tuned code that use best possible combination available - later for compiler decision is limited to select particular implementation, not invent own that can be (and probably it will be) suboptimal - this is main difference between plain and PRAGMA coding - there is no justification for much longer compilation with such thing as AVX (probably just compiler is not optimized yet and do some exhaustive search - probably can be improved later (or not) - compiler is smart only as compiler creator can be and compiler creator can be less smart(experienced) from guy that doing inline asm).

    But im not a software guy and for all differences you should ask a good coder.

    Quote for today - "program right down on the bare metal!" http://www.cs.utah.edu/~elb/folklore/mel.html

    http://en.wikipedia.org/wiki/Intrinsic_function
    Quote Quote  
  23. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Thanks for the clarification The problem was, we used different "wordings" to express the same idea (and your wording is clearer than mine, granted).

    FWIW: I only download the source-code from the MCW site, run Msys, then cmake, and make. From the little that I understand of the subject, and I may be understanding it all wrong, x265 DOES contain assembly-optimizations for SSE2, blah-blah-blah, and AVX. None of my three computers support AVX, and still they all run x265.exe without a complaint.
    Last edited by El Heggunte; 2nd Aug 2013 at 07:30.
    Quote Quote  
  24. Originally Posted by El Heggunte View Post
    Thanks for the clarification The problem was, we used different "wordings" to express the same idea (and your wording is better than mine, I admit).

    Anyway, it still seems to me that you think/believe that,
    if a program supports AVX instructions, then it cannot run on a machine that doesn't have AVX support

    Originally Posted by pandy
    Without inline-manual asm code that explicitly use AVX, [ then ]

    code after compilation should be capable to run on AVX and non-AVX capable CPU's.
    FWIW: I only download the source-code from the MCW site, run Msys, then cmake, and make. From the little that I understand of the subject, x265 DOES contain assembly-optimizations for SSE2, blah-blah-blah, and AVX. None of my three computers support AVX, and still they all run x265.exe without a complaint.
    OK i see - sorry for not being precise - my point was - if code will use only AVX instructions and will provide no substitute for this coded AVX function but without AVX then probably such code will be not useable on machines without AVX - however if code provide various functions that use various ecxtensions and if AVX coded functions can be substitued with for example SSE then such code will run perfectly on all type machines with AVX and SSE, only SSE and only AVX.
    However not sure if x265 will run for example on Pentium 1 or 386 without FPU - as there can be no substitutes for particular functions.
    I hope that now my point is clear - previously i didn't check source for x265 so i was not sure is there any AVX code inside - now it is clear that AVX is supported but not mandatory (there are substitutes for AVX - SSE at least) - so AVX code will be probably faster but on AVX machines it will be still usable.
    Quote Quote  
  25. For greater performance with x265, pls turn on the --no-rdo parameter and try it out. there is a slight increase in bit rates but performance gains are good
    Quote Quote  
  26. Member
    Join Date
    Aug 2009
    Location
    New Zealand
    Search Comp PM
    is there anything out there yet to convert videos to x265
    Quote Quote  
  27. doesn't make sense to convert anything to H.265 atm. since all implementations are still to new to be sure that they are really standard conform.
    Quote Quote  
  28. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    The title of this thread is x265 vs x264, so me thinks this attachment is 100% On-Topic,

    freenode-x265-log.txt, downloaded from akuvian.org,
    which belongs to pengvado / akupenguin / Loren Merritt / The X264 Man
    Image Attached Files
    Quote Quote  
  29. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    Originally Posted by El Heggunte View Post
    The title of this thread is x265 vs x264, so me thinks this attachment is 100% On-Topic,

    freenode-x265-log.txt, downloaded from akuvian.org,
    which belongs to pengvado / akupenguin / Loren Merritt / The X264 Man
    i fail to see how this adds to the topic at hand, the penguin barely says 3 words and they add nothing to the discussion.

    did you link to the wrong irc?
    Quote Quote  
  30. Originally Posted by deadrats View Post
    i fail to see how this adds to the topic at hand, the penguin barely says 3 words and they add nothing to the discussion.
    did you link to the wrong irc?

    I think that point is clear - there is no x265 vs x264 - x265 is in stage not even pre-alfa thus comparing it to x264 is simply unfair (for x265). We need more time, x265 need lot of work then perhaps thread like such can be reborn. For today x265 can't be compared to mature x264.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!