VideoHelp Forum
+ Reply to Thread
Page 1 of 4
1 2 3 ... LastLast
Results 1 to 30 of 116
Thread
  1. Hello all video gurus and others

    I capture x264 video in 1080p@30FPS with a GoPro HD Hero 3 Black Edition camera.
    When I play the footage on my computer the quality is outstanding.

    But as I'm always editing the footage in Sony Vegas there comes a time for re-encoding.
    I do this to MainConcept AVC MP4 and use a variable bitrate between 14000kbps and 20000kbps and select two pass encoding. Deblocking is left at default mode which is 'OFF'.

    Now, the quality is poor I'd say. Especially when looking at sequences with color gradients such as a blue sky.
    Looks like the color are grouping into blocks, like when you set your display card to display 16bit colors on your desktop.


    Now If you look at 1080p movie samples downloaded off the internet, the standard seem to be they are encoded at bitrates around 8000-9000kbps and they look stunning.

    How is this? What am I missing? How do I achieve such good quality at so low bitrates 8-9000Kbps? If anyone could shed some light on this for me I'd appreciate it!
    Quote Quote  
  2. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Capturing to lossy formats, even with x264, is an inherently lossy process. Video encoding is not like ZIP or RAR compression, which are lossless. You can decompress a ZIP file, recompress it, compress again and again, with no loss. Editing with lossy formats involves data loss with each re-encode. The videos that you see looking so great with fairly low bitrates have been captured and processed using lossless formats or lossless compression such as huffyuv or Lagarith. Encoding to lossy formats like h264, MPEG, etc., would be the last step in the total processing chain.
    Last edited by sanlyn; 26th Mar 2014 at 07:27.
    Quote Quote  
  3. Different video compresses differently.

    https://forum.videohelp.com/threads/347893-Best-x264-settings-for-SD?p=2176491&viewfull=1#post2176491

    And from what I've heard, Vegas' h.264 encoder isn't very good.
    Quote Quote  
  4. Formerly 'vaporeon800' Brad's Avatar
    Join Date
    Apr 2001
    Location
    Vancouver, Canada
    Search PM
    As jagabo said, MainConcept's H.264 encoder sucks compared to x264.
    Quote Quote  
  5. Thank you all for your replies.


    If I may bother you with more questions, do you know if there's a way to make Vegas use huffyuv or this lagarith (codecs or what are they?) methods for compression?

    Or better yet, how would you suggest I do, what codecs or workflows to use when editing end rendering with Sony Vegas. It's the only editor I know/can handle.

    My goal is great quality (lossless compression if possible) and as small files as possible.

    Thanks again for all your replies!
    Quote Quote  
  6. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Originally Posted by chrisofsweden View Post
    If I may bother you with more questions, do you know if there's a way to make Vegas use huffyuv or this lagarith (codecs or what are they?) methods for compression?

    Or better yet, how would you suggest I do, what codecs or workflows to use when editing end rendering with Sony Vegas. It's the only editor I know/can handle.

    My goal is great quality (lossless compression if possible) and as small files as possible.
    You mean, I think, "as small as is practical without quality loss". You get smaller files with higher, lossy compression. Lossless compressors reduce storage space, but not at the expense of data loss. Editing, filtering, etc., should ideally be done with lossless media. Huffyuv and Lagartith are fast compressors designed for real-time AVI capture and playback; they don't shrink as much as something like ZIP or RAR on uncompressed source, but they're much faster.

    I haven't used Vegas in a while, but if memory serves I used Lagarith AVI in Vegas. However, I believe Vegas utilities work with RGB (as does VirtualDub and others). Current Vegas users might correct me on that. Huffyuv can compress YUY2 and RGB. Lagarith works with RGB, YUY2, and YV12 colorspaces. The colorspace used depends on the filters and the app.
    Last edited by sanlyn; 26th Mar 2014 at 07:27.
    Quote Quote  
  7. Originally Posted by chrisofsweden View Post
    do you know if there's a way to make Vegas use huffyuv or this lagarith (codecs or what are they?) methods for compression?
    I dont' know Vegas so I can't answer that. But your files will grow 10 to 20 times bigger going from h.264 to huffyuv or lagarith. Expect something like 2 to 3 GB per minute.
    Last edited by jagabo; 25th Mar 2013 at 15:37.
    Quote Quote  
  8. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    A 720x480 YUY2 AVI capture from 90-minute VHS using Lagarith will run about 35-40GB (it does on my system, anyway). Will be somewhere in that neighborhood. It won't be the same tiny files you've been looking at.
    Last edited by sanlyn; 26th Mar 2014 at 07:27.
    Quote Quote  
  9. Originally Posted by sanlyn View Post
    A 720x480 YUY2 AVI capture from 90-minute VHS using Lagarith will run about 35-40GB (it does on my system, anyway). Will be somewhere in that neighborhood. It won't be the same tiny files you've been looking at.
    He's working with 1080p at 30 fps. His files will be much larger than yours unless he's downscaling to DVD resolutions.
    Quote Quote  
  10. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Oh, yeah. a LOT bigger. My bad. I go into denial every time I see 1920x1080. Hate working with it.
    Quote Quote  
  11. Thanks again for your replies. I actually downloaded and tried rendering a snippet of my project to an avi with the huffyuv codec, and as several of you mentioned, files ger huge. ~20 secs of 1080p@30fps turned out to a hefty ~700mb (yikes).

    My entire project is going to be around 40 minutes and I was hoping to find a way to keep that below 4GB with as much quality as possible. I'm going to do the final encode with Vegas.

    What codecs and and settings would you suggest I use to achieve the below 4GB Limit and have good quality?
    Is it even possible?

    A thought worth mentioning; The video files that the gopro produces are compressed hard since I sadly have not used the close-to lossless ProTune mode for this footage. BUT it is suggested by many GoPro enthusiasts that you use CineForm Studio to convert the original footage to CineForm AVIs, and use those files for editing because it's easier for the computer and editor to handle the less compressed video, as I understand it.
    From what I can see the resulting CineForm AVIs turn out all around 6 to 10 times bigger than the source files.
    The conversion seem to be (and is claimed to be) close to lossless.

    Would editing with the bigger AVI files as the intermediate format and then rendering to a more compressed final format turn out better quality-wise you think?
    If so, why is that? Help me understand this stuff


    Thanks for your help all!
    Last edited by chrisofsweden; 25th Mar 2013 at 17:55.
    Quote Quote  
  12. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Originally Posted by chrisofsweden View Post
    My entire project is going to be around 40 minutes and I was hoping to find a way to keep that below 4GB with as much quality as possible. I'm going to do the final encode with Vegas.

    What codecs and and settings would you suggest I use to achieve the below 4GB Limit and have good quality?
    Is it even possible?
    No lossless codec is going get 40 monutes in 4GB.


    Originally Posted by chrisofsweden View Post
    A thought worth mentioning; The video files that the gopro produces are compressed hard since I sadly have not used the close-to lossless ProTune mode for this footage. BUT it is suggested by many GoPro enthusiasts that you use CineForm Studio to convert the original footage to CineForm AVIs, and use those files for editing because it's easier for the computer and editor to handle the less compressed video, as I understand it.
    From what I can see the resulting CineForm AVIs turn out all around 6 to 10 times bigger than the source files.
    The conversion seem to be (and is claimed to be) close to lossless.
    "Close to lossless" isn't lossless. If you want standfard DVD, BD, or AVCHD, you'll have to re-encode.

    Originally Posted by chrisofsweden View Post
    Would editing with the bigger AVI files as the intermediate format and then rendering to a more compressed final format turn out better quality-wise you think?
    If so, why is that? Help me understand this stuff
    Process in lossless. Encode once, at the end. CineForm is a high-bitrate, low-compression deal that requires re-encoding every time you save an edit job, and ultimately has to be encoded again for the standard formats you want. It's up to you.
    Last edited by sanlyn; 26th Mar 2014 at 07:28.
    Quote Quote  
  13. Originally Posted by chrisofsweden View Post
    Would editing with the bigger AVI files as the intermediate format and then rendering to a more compressed final format turn out better quality-wise you think?
    Unless Vegas has problems with your source, no. Cineform is probably easier for Vegas to handle (in terms of seeking while editing) but it is not lossless. It will degrade your source even further (though by only a little). Then, unless Vegas has some particular liking for Cineform, encoding that again will result in worse quality than editing your original files directly.

    Since you're using a GoPro camera I'd assume you have very shaky, jerky, noisy video. That is simply not going to compress as well as professionally shot film (low noise) shot from a stable platform (no shaking).

    Of course, we haven't seen you source or your re-encoded video so we can't say for sure if what you're getting is unusually bad.
    Quote Quote  
  14. Member
    Join Date
    Jan 2003
    Location
    India
    Search Comp PM
    Originally Posted by chrisofsweden View Post
    Hello all video gurus and others


    Now, the quality is poor I'd say. Especially when looking at sequences with color gradients such as a blue sky.
    Looks like the color are grouping into blocks, like when you set your display card to display 16bit colors on your desktop.
    Blue sky is always a problem for h264 encoding. It is inherent in h264.
    First of all try to use latest x264 with film tuning, constant quality encoding mode with crf (quality)18 or less, select your target playback device if needed, and encode.
    You may need to use adaptive quantization/ check No Fast P-skip/ add noise to overcome the problem
    Quote Quote  
  15. @mgh:
    Blue sky is always a problem for h264 encoding. It is inherent in h264.
    From what I know of the standard, it both allows higher calculation precision than the default 8bit and it allows the choice of the color space that is used. From what I know aside from choosing bad encoding settings (wrong quantize distribution), these are the main two reasons for problems with flat areas and color transitions.
    So from my point of view these problems are either user made or a limitation/problem of the encoder used.

    -> Why do you think this is an inherent problem of H.264?
    Quote Quote  
  16. Originally Posted by mgh View Post

    Blue sky is always a problem for h264 encoding. It is inherent in h264.
    First of all try to use latest x264 with film tuning, constant quality encoding mode with crf (quality)18 or less, select your target playback device if needed, and encode.
    You may need to use adaptive quantization/ check No Fast P-skip/ add noise to overcome the problem
    I'm sure you just gave great and sound advice but I have no idea what you just said I'm afraid...

    How do I
    Originally Posted by mgh View Post
    "use x264 with film tuning, constant quality encoding mode with crf (quality)18 or less, select your target playback device if needed, and encode.
    Also, CRF?;Adaptive quantization? No Fast P-skip? Thanks for trying to help, really! But dude...
    Quote Quote  
  17. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Originally Posted by mgh View Post
    Originally Posted by chrisofsweden View Post
    Now, the quality is poor I'd say. Especially when looking at sequences with color gradients such as a blue sky. Looks like the color are grouping into blocks, like when you set your display card to display 16bit colors on your desktop.
    Blue sky is always a problem for h264 encoding. It is inherent in h264.
    I go along with selur: macroblocks are not an inherent problem with h264. Many things can cause it, but it's almost always low bitrate encoding, over filtering and improper denoising, invalid luma and chroma levels....and more directly, working with previously encoded and lossy encoded video. There's no way around it.

    Long time members here warn users again and again to avoid capturing to lossy media, to avoid working with it, and to avoid re-encodes. One would think that users would get the message by now. But I guess they're in denial...or something.

    Meanwhile, we have no video or samples here, and the detailed advice is basically second-guessing about something we've never seen. Without sight of what you're working with, answers are going to be general and confusing. It's far too early to get into quants and whatnot when shooting blind this way, and many of those factors are sometimes managed pretty well by defaults with better encoders.

    This thread could go in circles forever without specific examples of what is being processed.
    Last edited by sanlyn; 26th Mar 2014 at 07:28.
    Quote Quote  
  18. I think Selur is right in theory. But mgh is right in practice. Sure we can avoid posterization by using x264 in 10 bit mode. In practice no consumer devices play 10 bit h.264 so we're forced to use 8 bit. 8 bit YUV simply doesn't have enough precision to encode smooth gradients. Hence the requirement for noise and higher bitrates (to retain that noise) to prevent posterization. And shots with lots of sky is one of the most common places where you see smooth gradients.
    Quote Quote  
  19. @jagabo: my point was mainly that H.264 as standard is not the problem like mgh stated it and I wanted to know why he stated that it was an inherent problem from H.264.
    Quote Quote  
  20. Originally Posted by Selur View Post
    @jagabo: my point was mainly that H.264 as standard is not the problem like mgh stated it and I wanted to know why he stated that it was an inherent problem from H.264.
    I know what your point was. And my reply was that it's an inherent problem with h.264 as it's commonly used. And I think that's what mgh's point was.
    Quote Quote  
  21. Thank you all for taking the time to help me out. I understand its difficult to guesstimate issues at hand without material to review.
    Tomorrow I'll try to upload 2 short clips to my dropbox and post the links here. One 'raw' clip straight from the camera and one reencoded in vegas and a screenshot of encode settings. And if you want to, review it and post suggestions. If not, well thats OK too! Thanks again!
    Quote Quote  
  22. First, get a tripod. Mandatory for a hand-held camera in standard resolution, for HD, a no-brainer.

    Second, get a better encoder. Yes, you will have to learn how to use it. Virtually guaranteed it will beat Vegas in quality.

    Third, decompress to something lossless, then edit, combine clips into one file. This you can do in Vegas because there is little opportunity for it to screw it up. Do not change resolution or any other parameters except codec. Vegas has a tendency to do this unless you pay attention.

    Fourth, use the better encoder on this new file that has been compressed ONCE, decompressed ONCE, and not further messed with.
    Quote Quote  
  23. Now when I got some sleep and got my head around it, how can I trim one of my "raw" straighfromcamera MP4's without touching its fomat/encoding?
    Quote Quote  
  24. Member
    Join Date
    Mar 2011
    Location
    Nova Scotia, Canada
    Search Comp PM
    Originally Posted by chrisofsweden View Post
    Originally Posted by mgh View Post

    Blue sky is always a problem for h264 encoding. It is inherent in h264.
    First of all try to use latest x264 with film tuning, constant quality encoding mode with crf (quality)18 or less, select your target playback device if needed, and encode.
    You may need to use adaptive quantization/ check No Fast P-skip/ add noise to overcome the problem
    I'm sure you just gave great and sound advice but I have no idea what you just said I'm afraid...

    How do I
    Originally Posted by mgh View Post
    "use x264 with film tuning, constant quality encoding mode with crf (quality)18 or less, select your target playback device if needed, and encode.
    Also, CRF?;Adaptive quantization? No Fast P-skip? Thanks for trying to help, really! But dude...
    This usually happens with newer users of encoders. Don't feel bad. There are tons of threads here started by newbies who want simple step by step instructions. They don't exist.

    A lot of the problems come from (mostly paid) programs that claim to make it all look easy. It may seem that way until you scratch the surface and it very quickly becomes very complicated. Not just encoders do this. I've seen video players that seem really simple until you want to change the settings. I think maybe the free stuff ... that at least looks as complicated as it is ... may be better.

    You can't just plug in numbers for those advanced settings. You need to be able to tell which ones you'll need. Unfortunately you will need them because they're really the main reason that h.264 quality is better than other codecs as far as I can tell.

    I'm afraid you are going to need to do some research if you want to get into h.264 advanced settings. I'd recommend the docs on the handbrake and avidemux sites.
    Quote Quote  
  25. Originally Posted by chrisofsweden View Post
    But as I'm always editing the footage in Sony Vegas there comes a time for re-encoding.
    I do this to MainConcept AVC MP4 and use a variable bitrate between 14000kbps and 20000kbps and select two pass encoding. Deblocking is left at default mode which is 'OFF'.

    Now, the quality is poor I'd say. Especially when looking at sequences with color gradients such as a blue sky.
    Looks like the color are grouping into blocks, like when you set your display card to display 16bit colors on your desktop.
    Am I missing something here? Deblocking is disabled by default..... for reasons I don't understand.
    The problem relates to blocking. Has anyone suggested enabling deblocking yet?

    As has been suggested though, the x264 encoder would probably be a better choice. Using the default settings and a high enough quality setting (CRF value) generally produces encodes without any noticeable blocking. There's always the odd exception, but banding tends to be more of a problem than blocking. This sort of thing, but it doesn't sound like that's your problem.

    Click image for larger version

Name:	colour_banding_example01.png
Views:	873
Size:	23.1 KB
ID:	16955

    If the problem is blocking, which looks more like this:

    Click image for larger version

Name:	blocks.png
Views:	851
Size:	147.7 KB
ID:	16956

    then enable deblocking when encoding, and if the problem persists, using a better encoder might be in order.

    In my opinion, most encoding artefacts can be eliminated without the need for messing with advanced encoder settings. Increasing the bitrate or using a higher quality setting will do the job 99% of the time. It sounds like you're already doing that though, which gets back to enabling deblocking and/or using the x264 encoder instead.

    I don't know anything about the MainConcept encoder, but x264 can encode using 2 pass encoding and single pass quality based encoding. Most people use the latter, as that way you don't need to think about bitrates. You you pick the quality and the average bitrate will change from encode to encode accordingly. 2 pass lets you pick the bitrate/file size while the quality is unknown. CRF (single pass) encoding lets you pick the quality but the file size will be unknown. At the same average bitrate, and using the same encoder settings, 2 pass and CRF both encode the video in pretty much exactly the same way.
    Last edited by hello_hello; 27th Mar 2013 at 09:23.
    Quote Quote  
  26. You load your original clips into Vegas , play around, dissolves, titles, more tracks,..., if preview drops frames and you do not like it and then you set preview to render half, quarter etc. and you still do not like it you just encode with Cineform before you load your clips into Vegas.

    You want best quality encoding to H.264 while having smallest volume possible. You are not going to find out balanced bitrate in this manner using 2pass VBR encoding. BTW, I hope you did not use 1 pass VBR. CRF method is good for this purpose, you set quality, CRF factor, and encoder distributes bitrate for scenes to keep that quality. Vegas encoders use only VBR or CBR. CRF is not available in Vegas!, so you'd have to tackle the whole process getting video out of Vegas in some lossless form and encode it with x264 encoder OR you check out debugmode frame server.

    To simply put it, debugmode frame server is a plugin for Vegas that basically allows you to load Vegas' timeline into some x264 encoder directly withou needing rendering lossless first. I do not use anything else to render videos from Vegas. Using it first time is not straight forward though.
    Quote Quote  
  27. Originally Posted by hello_hello View Post

    Am I missing something here? Deblocking is disabled by default..... for reasons I don't understand.
    The problem relates to blocking. Has anyone suggested enabling deblocking yet?
    No one has actually, but I have tried enabling it. If it did do anything it was by a so small amount it was virtually impossible to see a difference. And yes, it does look like your example so I know it's blocking artefacts.

    Originally Posted by hello_hello View Post

    As has been suggested though, the x264 encoder would probably be a better choice. Using the default settings and a high enough quality setting (CRF value) generally produces encodes without any noticeable blocking. There's always the odd exception, but banding tends to be more of a problem than blocking. This sort of thing, but it doesn't sound like that's your problem.
    Originally Posted by _Al_ View Post

    CRF is not available in Vegas!, so you'd have to tackle the whole process getting video out of Vegas in some lossless form and encode it with x264 encoder OR you check out debugmode frame server.
    God damnit. I guess I'll just have to either render to something lossless from vegas first (suggestions on that lossless format/codec?) or try to learn that debugmode frame server plugin.

    Originally Posted by hello_hello View Post

    x264 can encode using 2 pass encoding and single pass quality based encoding. Most people use the latter, as that way you don't need to think about bitrates. You you pick the quality and the average bitrate will change from encode to encode accordingly. 2 pass lets you pick the bitrate/file size while the quality is unknown. CRF (single pass) encoding lets you pick the quality but the file size will be unknown. At the same average bitrate, and using the same encoder settings, 2 pass and CRF both encode the video in pretty much exactly the same way.
    Thanks again, that was quite understandable for a person with my basic knowledge about this.
    Last edited by chrisofsweden; 27th Mar 2013 at 09:48.
    Quote Quote  
  28. well you can use 2pass VBR , it is not like CRF encodes better or something, just you'd have to test average 15.000.000 and test it, you set average 17.000.000 and you encode, different videos need different average bitrate set to achieve certain quality, so you need to do some testing all the time. After some time you get some feelings , sure, what average bitrate should be about right , but still you could be off something ...

    CRF is just more straight forward way of encoding, it does it for you right away, meaning you only test once what value you need, say CRF=18 for example, so you use it next time with different video and you will know what you are going to get, once you get used to this kind of encoding you do not go back to 2pass VBR (only for if you encode to size)

    Some folks install x264VFW codec and Vegas can export into that one, not sure if there is CRF included, perhaps yes. But you get H.264 encoded into avi wrapper, which is weird. Never used it, how it is compatible with hardware players or how it behaves uploading to YouTube etc. Maybe you can just rewrapp it into mkv with mkvmerge (simple drop file and remux process without encoding).
    Quote Quote  
  29. Originally Posted by chrisofsweden View Post
    Thanks again, that was quite understandable for a person with my basic knowledge about this.
    No worries!
    I think the default CRF value for x264 is 20, which will give you a very nice quality encode. The higher the value, the lower the quality and the smaller the file size.
    I think most people would use between 18 and 22. Around 18 is where the x264 encoder is considered to be "transparent". I generally use CRF18 for everything except 1080p, where I use CRF20 (higher resolutions seem to be able to get away with higher CRF values) but it's all personal preference.

    The x264 encoder also has speed presets and tunings. The default speed preset is medium (and perfectly fine to use) but slower speed presets may increase the quality a little for a given CRF value. A tuning can be chosen according to the type of video you're encoding. Other than that, it's generally not necessary to mess with any of x264's advanced options, and not a good idea unless you really know what you're doing. Claims encoding is "complicated", and you need to know how to adjust x264's advanced settings to achieve good results seem like nonsense to me. For us mere mortals, x264's own speed presets and tunings are all you really need. There's always the odd exception.... a particular section of video that doesn't encode well...... but once again, lowering the CRF value......

    I'm not suggesting you need to use it, but one way to familiarise yourself with x264's various options might be to look at MeGUI's x264 encoder configuration. By default, it just lets you change a few basic settings (ie speed preset and tuning etc) but if you check the box to enable "advanced options" you can look at the various x264 settings and see how their default values change accordingly as you change the speed preset or tuning. It's not something you need to know in order to use the x264 encoder.... the presets are there so you don't need to..... but if you want to understand what they do in terms of x264's advanced settings..... plus it'll also show you how the various options are added to the x264 command line, if you're not using a GUI for encoding. And if you hover the mouse of most of the x264 settings, the tooltip will offer a brief explanation as to what each does. Don't feel silly if you don't always understand the explanation though.....

    And depending on the editing you're doing..... if it's just basically cutting sections of video..... MeGUI can do that while encoding. You'd open the source video, let MeGUI index it, and then set up the encode when the AVS Script creator window opens (cropping and resizing etc). When you're done you can save the script and then open it with the AVS cutter, which uses a preview to allow you to specify various "cuts". When you're done, you save the cuts to the script, and the encoded video will contain only the sections you specified.... effectively editing and encoding at the same time. If you're just editing, and not adding effects etc, you can probably bypass Sony Vegas completely. MeGUI will save a file to use in order to "cut" the audio in the same way while re-encoding it, or it can "cut" many common audio formats without re-encoding, then you can add the edited audio to the edited video when the encoding is done.
    Last edited by hello_hello; 27th Mar 2013 at 10:54.
    Quote Quote  
  30. Some minor corrections and additional observations for the OP:

    Originally Posted by hello_hello View Post
    I think the default CRF value for x264 is 20
    The default is 23. http://mewiki.project357.com/wiki/X264_Settings#crf

    Originally Posted by hello_hello View Post
    Around 18 is where the x264 encoder is considered to be "transparent".
    There are some types of material where CRF=18 yields obvious artifacts. Dark, grainy video for example:

    https://forum.videohelp.com/threads/345427-Handbrake-Should-i-leave-it-on?p=2156674&vie...=1#post2156674

    Originally Posted by hello_hello View Post
    I generally use CRF18 for everything except 1080p, where I use CRF20 (higher resolutions seem to be able to get away with higher CRF values) but it's all personal preference.
    If you are encoding at low resolution and viewing at full 1080p (A standard defintion source watched on a 1080p HDTV, for example) all the small artifacts in the small frame are enlarged on the big screen, so they are more obvious. Whereas small artifacts in an 1080p encoding remain small when viewed on that same HDTV.
    Quote Quote  



Similar Threads

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