Sign in with
Sign up | Sign in
Your question
Closed

HD Encoding Face-Off: WMV-HD vs. DivX-HD

Last response: in Tom's Guide
Share
July 5, 2006 6:13:58 PM

Thanks for the comparisons on different file formats. It made it easy to see differences.
One note though. Why not give Divx the same high bit-rate as WMV? Then there may not be any difference in quality.
Also, I will like to see how the Quicktime and Real video works vs. older avi, mpg, mpg2 formats in high-res. (if mpg and avi can be high-res)

I have a collection of old Divx 3.11 files I want to convert. I hope someone can tell me a good way to convert them to a new Divx 6.25 or WMV-HD without losing quality (AGAIN).
I've used virtual-dub which works sometimes. But this makes noticabily larger files. Maybe the Divx 6.2 converter is better at doing this? Is there a good way to convert 3.11 to WMV? (I am guessing not)
Thanks!
July 5, 2006 6:28:46 PM

I have to agree with enewmen. You should have also compared similar bit rates...or at least compared Best Quality Divx vs Lowest quality WMV (which still has a higher bitrate than Divx). Yes, if you're looking for bestquality divx may fall short, but if you really want best quality, you probably don't want to use WMV either. I know I have a friend that always left programs in the original uncompressed format.
July 5, 2006 6:50:36 PM

I use BeyondTV (and BeyondTV Link) 4.3 and was wondering why the settings were not changed for the Divx to get the better quality, even at the tested bitrates. BeyondTV does a single pass encode with the standard Divx mode by default to give you a faster conversion. The settings that you have control over are Frames Per Second, Dimensions, Two Pass Encoding, Average Video Bitrate, Audio Bitrate, Resize Style, Resize Algorithm, Bidirectional Frames, Noise Filtering, Performance Mode, and Psychovisual Mode. Just turning on the Two Pass Encoding and Very Slow Performance Mode would greatly improve the look with the lower tested bitrates.
July 5, 2006 6:58:21 PM

Interesting read along with the Beyond TV article.

I do wonder if using an Athlon XP adversely affected the WMV encoding. Video encoding is one of the few areas that P4s outperform Athlon's and Windows media encoders seem to favor Intel SSE2/3.
July 5, 2006 7:17:35 PM

Great article. It was really nice to see the screenshot comparisons that you did. Given the peformance/quality ratio, it looks like the clear winner here is Divx. There are of course noticable differences between WMV and Divx, but when you consider the file size and encoding times... it seems like Divx is a no-brainer to me. I for one don't want to spend hours at a time encoding stuff in WMV.

Again, good article. Thanks!
July 5, 2006 7:28:42 PM

When getting BeyondTv setup, I have tested a few different combos. The one setup has been an Athlon 64 3800+ AM2 with the Biostar TForce 6100 with 1Gb Patriot DDR2-800 vs an Athlon 64 3400+ S754 with the ECS 755-A2 with 1 Gb Patriot DDR400 (2-3-2-5). Doing the Divx conversion from the source, the 3400 with the ECS motherboard is a full 6 minutes faster in converting 15 minutes of source material than the 3800 Biostar setup. Doing the conversion to WMV, the Biostar setup is faster.
July 5, 2006 8:42:33 PM

I must admit to being a little perplexed at your choice of source material. Golf??

I am not a golfer, nor do I play one on TV. But golf is a rather slow-moving sport, with each frame looking almost exactly like the previous one. One thing that differentiates the various compression schemes is how motion compensation is handled. It is quite likely that you would get different results if you were to choose a video clip with more actions, such as a scene from "The Matrix."

Just my opinion.
July 5, 2006 9:02:43 PM

if you read what he said he explained why he chose golf. it was to do with how well the different formats presented the detail that the scenery offered.
July 5, 2006 11:10:46 PM

Sounds like they are almost as good as H.264 :) 
July 5, 2006 11:50:37 PM

That original "HD" image is INTERLACED. BLECH. Ugly. Cough. ACK!

Comparing interlaced originals to de-interlaced versions isn't intuitive when the images are static. It might make sense viewing dynamic playback - but Mike, you really should have de-interlaced the original before comparinh them in this article. Hell, Photochop even has a de-interlace feature specifically for this sort of thing; and because there'll be virtually zero movement in this shot (OK, so the golfer is walking, but not at 30mph one can bet!) the de-interlaced image will actually look like an HD image would in its dynamic playback form.

So - I'm not giving any props to Mike Baggaley at all here: it was an apples to shovels comparison (which is to say, not a valid experiment in my view) when the altered bitrates are concerned.

To leave comparative bitrates out of this article makes it seriously flawed.
July 6, 2006 12:04:47 AM

Hello all,

I'm the product lead for the DivX Codec, and I'd like to address a few of the points you've made in this thread.

@enewmen: The WMV-HD samples in the experiment do use 2x - 3x as much data (bitrate) as the DivX-HD versions. Because bitrate is the largest factor to quality and the difference in bitrate is so large the WMV-HD versions will naturally appear to be of better quality than the DivX versions in the side-by-side screenshots. I think this is quite confusing. However, you will find that the DivX encoder can produce better quality than WMV for equal bitrate, and that it's perfectly possible to configure the DivX encoder to produce files using much higher bitrates than were used here by Beyond TV.

The DivX encoder provides 6 individual modes that allow you to balance encoding time against quality, ranging from modes that make it one of the fastest modern encoders available through to one of the highest quality encoders. I'm not entirely sure, aside from setting the bitrate, which options specifically were used by Beyond TV.

@A64: Yes, two-pass encoding does lead to better quality (in fact, it leads to more consistent quality == fewer scenes with bad artifacting). It can, however, lead to longer encoding times. If your encoding application allows you to configure each pass individually, try using "Balanced (default)" mode with "H.263 quantization" for 1st pass and then a slower mode (e.g. "Extreme quality" with "H.263 Optimized quantization") for the 2nd pass. (Do not use anything less than "Balanced" for first pass, though). Usually I use "Extreme quality" and "H2.63 Optimized" quantization for most videos, but I'm all for quality and don't care so much for encoding time ;) 

@mpjesse: DivX 6.2.5 (current version) features a "High performance" mode. While it sacrifices a small degree of quality, if you're looking for fast encoding it can run through SD material at hundreds of frames per second on recent hardware, and should perform very nicely with HD also. The small quality drop can be avoided if you can afford to increase the bitrate/filesize slightly.

@Chemware: H.264 really does not have any significant advantage for HD video. Many of it's features, such as smaller block sizes and in-loop deblocking, are optimized for low spatial resolution (i.e. low resolution video). As your resolution grows from 720 upwards you see less and less difference.

@Mobius: Yes, it is important that the source be de-interlaced. If the host application (e.g. Beyond TV) does not do this directly, the DivX Codec includes an option to do it during export (which must be set manually). Encoding an interlaced source as progressive will lead to rather blocky output at these bitrates, so hopefully the material was de-interlaced during export.

@all:

You should also try the new "Sharpening" feature of DivX 6.2.5 for quite amazing playback results!

See here:
http://go.divx.com/divx/codec/shinynewfeatures

I recommend that if you install the latest codec you also apply this patch, which will be rolled into the main installers within the next week:
http://community.divx.com/forum/viewTopic.php?id=1353

All the best,

-Al
July 6, 2006 12:46:16 AM

Quote:
Hello all,

@A64: Yes, two-pass encoding does lead to better quality (in fact, it leads to more consistent quality == fewer scenes with bad artifacting). It can, however, lead to longer encoding times. If your encoding application allows you to configure each pass individually, try using "Balanced (default)" mode with "H.263 quantization" for 1st pass and then a slower mode (e.g. "Extreme quality" with "H.263 Optimized quantization") for the 2nd pass. (Do not use anything less than "Balanced" for first pass, though). Usually I use "Extreme quality" and "H2.63 Optimized" quantization for most videos, but I'm all for quality and don't care so much for encoding time ;) 



The conversion is happening in BeyondTV with the ShowSqueeze automagically between midnight and 6am. Snapstream has not given us access to all of the neat settings for Divx at this point. I am currently running 2 Plextor PX-TV402U tuners my system (limited to 720x480) and an ADS Tech InstantHDTV PCI. The Plextors do allow for on-the-fly Divx encoding, but the SSX format that the system creates initally does not always convert to AVI on shows over 2 hours or so. The file size is also larger than encoding as the MPEG-2 Record/Divx Conversion process (by about 20%). Using a motherboard with the SIS 755 chipset, the speed of conversion to Divx is substantially faster than other chipsets (as reported around the web in reviews of motherboards). The one advantage of converting to Divx over other formats is that the files can be put to DVD and played in a LiteOn LVW-5115 player or on other OS platforms, such as Zeta 1.2.

For those that haven't used BeyondTv, when on the system, just point your web browser to http://localhost:8129 and you can go to town on customizing your settings for Divx, MPEG-2, WMV, etc. Of course, you can access the system from other systems on your network.
July 6, 2006 12:56:40 AM

Quote:
Hello all,

You should also try the new "Sharpening" feature of DivX 6.2.5 for quite amazing playback results!



On this note, yes it looks great, but there are issues on the BeyondTV 4.3. The video card that works extremely well for playback is a simple nVidia 6200TC. You cannot get the card to work in the 3D Accellerated mode, just the overlay. In BeyondTV 4.3, when trying to use a 6600, 7300GS, and 7800GT, they would work in 3D Accellerated mode, but had major issues in the playback (skipping, stuttering, tearing, blanking, artifacts, etc), especially with the shapening mode. The overlay mode had none of these issues and looked much better. When going to the Overlay mode of playback, there was no reason to use a more expensive video card.
July 6, 2006 1:54:28 AM

@DigitAl56K: What tools do you use to transcode Divx33 to DX50? I find I can get the size down nicely (with no perceived loss of quality), but I get a lot of subtle audio sync problems using Virtdubmod and nandub. (Yes I have the latest pro codecs from DivX, and the not very useful -- for transcoding -- DivX converter). Thanks for the tip on how you tune 2 pass encoding.

This is a very topical subject -- video encoding is a great application for forthcoming massively powerful multi-core systems.

I do remain baffled as to this aptly characterized 'apples to shovels' comparison. Kudos to the author -- he was very clear, but if this was intended to be a "here's what we can do with BeyondTV, and it won't let you use DivX properly" then perhaps that should have been the thrust of the article rather than "Divx vs WMV-HD". Honestly, comparison of Divx at low data rates to WMV at high data rates is virtually pointless.

On the sharpening feature in Divx 6.2.5. I note that it's only demo'd using nature scenes. I do wonder what it's like with very different forms of video. To date, I've found it's mediocre with older PAL (converted from 625-line broadcast and 576-line tape) TV stuff (generally non-nature). Here and there it is indeed spectacular.

@DigitAl56K: H.264 has no sigificant advantage for HD video? I find this a surprising assertion, no offense intended. I readily admit, 576, 625, and 720 are the highest verticals I usually use. Certainly for those resolutions, it beats Divx, though only at a huge CPU cost.

Despite my criticism above, I use (and very much like) Divx. Nothing seems faster while still being quite good quality. A couple years back Xvid seemed on par... that's just not the case now. WMV, I've played with, but if encoding's going to take that long, might as well use x264.
July 6, 2006 2:05:29 AM

I've watched a couple of videos encoded with this three formats:

XviD-HD ( not DivX, XviD ... even if it sounds similar, it's a different MPEG4 encoding scheme )
WMV-HD
x264 ( variant of H264 )

The quality is best for x264, then WMV-HD and on the last place XviD-HD

However, x264 is most taxing to the processor, even for playback, while the encoding time is enormous. However, it preserves almost every detail so it's worth it...
July 6, 2006 2:15:18 AM

There is no way WMV is better than XVID (on average)! Maybe the videos you watched were not encoded very well :)  If your WMV-HD sampling came from the clips posted on the MS website then they were also low motion and very high bitrate, making for a nice showcase piece but not really the type of content you'll come across very often.

@Holmwood: H264 can looka little bit nicer at lower resolutions when bitrate is quite tight. My point is mainly that as you approach HD at 720 and higher you loose most of the benefit it has to offer, yet are still burdened with the high CPU use that a couple of people have commented on.

Anyway, we diverge from the topic.

@A64: I don't quite understand what you said in your last post, but if you think there is a problem with the codec feel free to e-mail me at amayo [at] divxcorp (dot) com .
July 6, 2006 2:25:49 AM

Well, since the manufacturest already have or will offer hardware h264 decoding ( example: nVidia PureVideo ) it's quite clear that they do this for a reason. And the only reason is that the quality IS better for this codec.

+ it's open source so easy to improve it...

And no, I'm not talking about the m$ clips, but high-motion music videoclips and generally high-detail documentaries (about construction or so)
July 6, 2006 2:28:49 AM

@wavetrex: One reason for hardware decode is that this standard on HD-DVD, along with MS VC-1 (which reportedly uses many of the same techniques and should be very similar to WMV9). This is similar to the way that MPEG-2 (current DVD spec) was accelerated in hardware previously.

BTW, is anyone doing an equal bitrate comparison with DivX-HD / WMV-HD?

P.S. I'm out for the night, I'll check back tomorrow :) 
July 6, 2006 3:52:13 AM

There should be a part two made for this. One that includes the MPEG4 variants(DivX, XviD, h.264, MS-MPEG4(WMV3?) to name a few), the number of passes, same bit-rates, utilizing a progressive or de-interlaced source video.
July 6, 2006 6:08:47 AM

Hello everyone. Sorry it has taken me so long to address some of your comments. (It's been a busy day) :) 

First of all, thanks for the responses you're comments are all great and I appreciate the feedback.

This article evolved from the beyond TV article that I did recently. I got curious during the process of reviewing BTV regarding the showsqueeze function. After testing some video that I had recorded during the course of the review I began to put together some comparisons. All of the encoding from this article was performed by Beyond TV's "Showsqueeze" function on several of their default preset decoding settings. This is why there was a difference in bitrates between the WMV and DivX samples.

Quote:
The settings that you have control over are Frames Per Second, Dimensions, Two Pass Encoding, Average Video Bitrate, Audio Bitrate, Resize Style, Resize Algorithm, Bidirectional Frames, Noise Filtering, Performance Mode, and Psychovisual Mode.


Hi A64, I went back and checked, but I wasn't able to find anywhere in the web interface or the main BTV 4.3 show squeeze settings that allowed me to change any of the settings that you mentioned. Would you mind posting again and walk through the setup process for us in case there are other BTV users out there that want to benefit from the changes in showsqueeze options? Thanks! Also, thanks for the heads up on the Biostar/ECS comparison. I guess it's true what they say about ECS. :lol: 

Quote:
I do wonder if using an Athlon XP adversely affected the WMV encoding


That's very likely. I generally build Athlon machines as a personal preference, but Intel processors have always enjoyed the upper hand with encoding video.

Quote:
That original "HD" image is INTERLACED. BLECH. Ugly. Cough. ACK! So - I'm not giving any props to Mike Baggaley at all here: it was an apples to shovels comparison (which is to say, not a valid experiment in my view) when the altered bitrates are concerned.


Sorry mobius, I'm a writer first, and a photochopper second. :wink: The images that you see are the direct screenshots that I pulled from the video. I debated with myself on the best way to portray the differences in quality because even the differences in resolution make a direct comparison hard to achieve.

Quote:
I'm the product lead for the DivX Codec, and I'd like to address a few of the points you've made in this thread.


Thanks for addressing the questions in this thread DigitAl56K. Hopefully we can re-address DivX HD encoding in the future using an encoding application that has a bit more flexibility in options than Showsqueeze.

Again, thanks for your comments everyone.

-Michael
July 6, 2006 10:11:40 AM

I'm inclined to take much the same position as mobius. I think, that from a technical standpoint, this article is fairly rubbish.

Firstly, I have to question the intelligence of storing a 1080i programme in 720p format, the correct format to re-encode it in was 1080i, as you're likely to lose less quality by keeping the larger image size and reducing the file size other ways (I won't go into the details of how MPEG works).

More importantly, your TV certainly can't display both resolutions natively, so by converting the file you've allowed the set to do the rough and ready upconversion back to 1080 (if it's a 1080 line set) or you've been watching 720 line tv you might find that the compressed images look better! (as your computers doing the resizing and taking more time over it)

Admittedly, resolution conversion is fairly good with a motion-compensated converter/encoder, but then you convert the stills back into 1080? and accept the inherent loss of quality when increasing resolution by non-integer ratios? then use these as evidence of conversion quality on a reputable computer website, while comparing to a poorly deinterlaced (it's just taken 2 fields and combined them) frame from the transport stream? It makes you appear clueless.

However, not only this, when you put you're arrows on the images to indicate when the differences were visible, you then decided to use a lossy photo compression format, masking the bits you were trying to point out with the compression artefacts from that!

I'm also disappointed that there's not mention of how well motion is dealt with.

Having now posted this aggressive but (hopefully) informed flame, I'm now going to say that though your methodology is flawed, it's probably more representative of "normal" than doing it a more controlled way. Video is complicated. Compression massively more so. Making them simple is difficult, but the average person doesn't want to invest the time or effort to get the best possible results - even the selection between WMV-HD or DivX is far more than most will do - so your tests are probably a fairly representative of real world usage.

The video software companies need to get their acts together, and sort us out with some smarter compression tools, that will auto-select and appropriate format based on the input file and probable output device (tv/monitor), and also do the re-encoding in a way that doesn't need to go via the uncompressed video, because the only times anyone actually compresses video for the first time are in portable cameras, or on the output of a tv station.
July 6, 2006 11:27:35 AM

I'm afraid I have to agree with Sendo. I can't vouch for the codecs in use, but changing the image resolution (and then changing it back again) seems crazy; if you're going to encode at 720p then there's not much point in starting with anything other than a 720p source - the scoreboard would have looked dreadful even with lossless encoding having gone through two image rescalings.

It's not strictly true that the TV can't necessarily deal with both (if playback is on a CRT, or one of the few 2160 screens out there). Also if the TV is in my pet hate resolution (1366x768), it could make a different kind of mess of either resolution. Even a 1080 panel might do a better job with a 720p source than with the same source mangled to 1080i - the internal scaler might target 1080p. Both formats have their use - but going between them just to save a bit of bandwidth is always going to mangle the image quality.

It's also a bit hard to compare codecs on the basis of one frame - speaking in MPEG terms, one codec might be on an I frame and another might be on a B frame, with varying amounts of bandwidth associated with that particular frame; other frames in the sequence might look better or worse compared with another codec. Especially after going through JPEG, an MPEG2 I-frame might look better than other encodings (since the MPEG2 I-frames effectively *are* JPEG, IIRC, and the blocks would line up for the DCT encoding). Obviously it's hard to represent the whole sequence on the web site without doing terrible things to bandwidth usage, so we have to take the author's word for the results.

Quick correction: you've said 1280x720dpi a few times. Please drop the "dpi". (I'll let you off if you have a *very* small screen, or possibly if you're looking straight at the projector's chip...) Also interesting that you've shown us the full 1920x1088, including the 8 lines intended to be cropped at the bottom. Looks like at least one of the 720p images has been scaled to 1088 pixels vertically, rather than 1080, which is probably making the image comparison even worse. I notice the 1080i signal isn't being converted to 1080p with a proper motion-predicting deinterlacer (or if it is, it's doing a bad job) - the next question is whether the conversion to 720p did the interpolation better.

Interesting article, but it's hard to draw anything definitive from it. I also agree that a comparison with some H.264 encoding would be interesting - especially for those of us in the UK who get their HD over H.264 (not that I've taken the HD plunge yet), and for comparison with next-gen DVD formats (at least when there are disks encoded properly - *why* are commercially produced blu-ray disks using MPEG2 in this day and age?)

Interesting to see the edge-of-screen artifacts that everyone's been telling me about, though!

--
Fluppeteer
July 6, 2006 1:36:02 PM

Hey Sando and Flupeteer, thanks for your comments. I do agree that there are better and more definitive tests that can and should be made in a comparison between HD formats. Keep in mind however, that I wrote this article as a follow-up to my recent piece on BeyondTV. The encoding options that are available in BTV's built-in encoder are preset to the resolutions and bitrates that I used. Since I was unable to find a way to adjust the quality of the images in ShowSqueeze beyond the presets of "low, medium, and high" I did the best that I could with the tool that I was working with. The article has created enough interest that I think that the topic is probably worth re-addressing with a more robust compression tool.
At this point, I think that it's probably best to think of the article as more of a comparison between the best images that I was able to achieve with BTV's showsqueeze. Actually, in Snapstream's defense, I thought that ShowSqueeze did a great job at trying to get file sizes down without sacrificing too much quality so I believe that it did it's job as a space saving tool. Beyond that, a follow up article is probably in order.

Thanks again for your well thought out comments. I appreciate the feedback!

-Michael
July 6, 2006 1:38:57 PM

Glad that somebody tried to take a look at video codecs, but a little disappointed that it only did two codecs. I sent a little email recommendation into Tom's Hardware a while ago, maybe a month or two, recommending that they take a general look at compression on PCs as it's very common. Audio, video, images, file archives, etc. It would be nice if Tom's took a thorough look at what file formats, programs, settings, hardware, etc gave the highest quality, fastest, smallest, etc results.

I really think it would be relevant right now, because a lot of media-related technologies are seeing vast improvements now and in the near future. Quad core processors are under a year away, Blu-Ray and HD DVD drives and media as well. Hard drives are going up quickly in storage capacity due to perpendicular recording, HD will increasingly become the standard for video files and monitors. With all this capacity for high-definition video at the least, I'd think it would be important for people to know what will give them the best quality, performance, etc before they start working with it.

Alright, so maybe that's primarily a video quality/compression article. But I for one am also interested in the other stuff as well. When you go to rip a CD for example, what format would you be best off using? When does increasing bitrate have a pronounced effect or little effect on the perceived quality? And for images, what file formats and compression levels are best, and where do the benefits drop off? If I want to archive some files in a ZIP or RAR file, which is best?

Anybody else interested in an article like this? I know Tom's Hardware can't fulfill every article request, or maybe they don't do it at all, but if there's enough interest maybe they'd look into it.
July 6, 2006 2:32:24 PM

Hello all,

We obviously have hit a nerve! If anyone wants to trash someone for this article, point your flames at me, not Mike. As Mike pointed out, he did this work as part of the Beyond TV article using its Showsqueeze features. I thought it would be better as a stand-alone article, so made it so.

As a few of you have pointed out, video encoding/compression is a huge topic. This article has shown that there is a lot of interest, so we'll be doing more on it.

This was not meant as a definitive study on HD compression, nor the last word on the subject... if that's even possible. Obviously it's difficult to convey in a few still images the overall viewing experience and quality of various HD encodings. Thanks to those of you for pointing out errors and things we can do better the next time.

Speaking of the next time, if anyone is interested in writing the next article, please PM or use the feedback form. Neither Mike nor I claim to be the smartest guys in the room on this topic and we (and our readers) could always benefit from those with more expertise to share.

Thanks again for your interest and feedback.
July 6, 2006 2:53:03 PM

I won't re-hash the comments of others here, the point has been made.

However, I always find it interesting that the request for feedback or input on these articles (that are neither NDA nor Time sensitive) is after the fact; instead of getting insight, suggestions and proper preparation before hand so that such seemingly obvious, but honest, mistakes can be avoided.

Also it would allow the articles to be taylormade to fit their intended audience as well as add to the reasons others might become interested because of the strength of the content as reference material.

It's also be nice to get an idea of hardware loads/differences, but that's almost a whole seperate article.
July 6, 2006 3:00:09 PM

so are you suggesting they should, a few weeks before an article post up on the forums that they are going to be doing such and such and article and ask what people would like it to include.
July 6, 2006 3:12:42 PM

OK, sure write something while I slowly write at work, and address my question before I can ask it!

Quote:

Speaking of the next time, if anyone is interested in writing the next article, please PM or use the feedback form. Neither Mike nor I claim to be the smartest guys in the room on this topic and we (and our readers) could always benefit from those with more expertise to share.


I can guarantee I'm the smartest guy in the room right now...
Of course I'm alone in my office, so I guess... that also makes me the dumbest guy in the room too.

Quote:
so are you suggesting they should, a few weeks before an article post up on the forums that they are going to be doing such and such and article and ask what people would like it to include.


Sure something like a... "if we were to look into video encoding/decoding article, what suggestions can you make, what would you like to see, and if you can think of any special things we should consider or take into account please mention it."

Of course the response from a request like that is likely to be less enthusiastic than criticizing something that is there and an easy target, so it's a tough situation for the author either way. No matter what they're bound to miss something, do something that someone doesn't like/agree with or potentially even miss somewhat hidden features as was the case here.

But it does reduce the potential for those issues, and it also gives them carte blanche somewhat.

I know it's alot easier to suggest than to implement, but I think there's been alot of cases like this before (like the 'Future 3D features' article, won't comment further on that).

It's tough, but I suspect that for the enthusiasts they're looking for a little more than your average article, input from the reps/developers first is also great, and that way if there's any issues, they're also culpable for not helping the author, which is something the average enthusiast even wouldn't have access to).

Just random thoughts from my feeble brain, and of course as always, my two frames' worth.
July 6, 2006 4:36:06 PM

Quote:
Or this tool for subjective video quality evaluation:
http://www.compression.ru/video/quality_measure/percept...

Thanks for the links. The subjective tool looks interesting. Too bad there isn't a web form of the comparison tool. But the Web isn't reliable enough to deliver the video, especially in HD forms!
July 6, 2006 5:15:18 PM

Hello,

well.... depending on the encoding target bitrate it could still be conceivable to perform perceptual comparisons through a web form but at that point a lot of uncontrolled factors could bias the subjective test like the color rendition and color temperature of the computer monitor of the end user or just the environment lighting.

For these tests keeping everything (or as much as possible) under control is paramount.

the VQM tool is on the other hand a more objective tool especially when used specifying the VQM metric.

Sarnoff Corp have a professional tool called JNDmetrix for Visual Quality measurements:
http://www.sarnoff.com/products_services/video_vision/j...
which was awarded an Emmy in 2000.
Obviously a much more expensive solution than the MSU VMT application.

andrea
July 6, 2006 9:26:54 PM

OK, first of all, please go back and fix all the references to "dpi" in the article. Nothing you are takling about is 1280x720dpi (Dots Per Inch). You mean pixels, or resolution, but most certainly not dpi.

I strongly suggest you do not down-rez your video when you encode it. Set the bitrate where you want it, but leave the resolution alone (unless you're encoding for a low-res device such as a PSP, iPod, etc.). Yes, there will be more artifacts in a 1920x1080 image than in a 1280x720 image encoded at the same bitrate, but if you're blowing them both up to 1920x1080 on playback, the one left at the original resolution will almost always look better.
July 7, 2006 3:00:20 AM

It is good to compare image quality of image form HD Videos. However it can be improved in serveral ways:

1. Using JPEG for comparision is less than satisfactory, adding a link(like the way of Tom's video) to image using lossless format(PNG/TIFF) is better.

2. Produce a "pixel difference" image for pin-pointing areas that look different(although some sort of threshold is needed), just like the way of comparing 3D game rendering quality using ATI & nVidia hardware.

3. The image for comparision should be in the same dimension. Therefore either compress the video in 1080p this time or downscale the original source to 720p first and use the 720p one as reference. Also, use progressive source if possible.

4. I will be happy if H.264 HD (eg. x264) comparsion will be included as it is already one of the video standards used by Blu-ray or HD-DVD video.

5. A screenshot on the encoding codec/encoder is appriciated.

p.s. I still need to figure out how to use hardware acceleration on H.264 decoding on recent display cards(I'm using a 6600agp)
July 7, 2006 3:15:43 PM

Quote:
OK, first of all, please go back and fix all the references to "dpi" in the article. Nothing you are takling about is 1280x720dpi (Dots Per Inch). You mean pixels, or resolution, but most certainly not dpi.

Removed all two of them.

Quote:
I strongly suggest you do not down-rez your video when you encode it. Set the bitrate where you want it, but leave the resolution alone (unless you're encoding for a low-res device such as a PSP, iPod, etc.). Yes, there will be more artifacts in a 1920x1080 image than in a 1280x720 image encoded at the same bitrate, but if you're blowing them both up to 1920x1080 on playback, the one left at the original resolution will almost always look better.

Good suggestion. Thanks.
July 7, 2006 5:12:19 PM

I ran my own test using the Lost Season 2 finale (I squeezed 9.25 GB of 1hr 24 minutes - 720p to to 4.05 GB in a matter or 14 hours and 31 minutes). I also put a 10 second clip through three squeeze profiles:

1) DivX HD (High - 3417 kbps) - 41 seconds to encode
2) WMV9 HD (High - 6835 kbps) - 2 minutes 18 seconds to encode
3) WMV9 HD (Low - 4882 kbps) - 2 minutes 2 seconds to encode

I did this on 1 of my Xeon 3.2 GHz processors (HT enabled) w/ 2GB ECC RAM. On all of my tests (not just these), the WMV audio had some crackling and the encoding time was horrendous. DivX encoding was speedy and looked great.

See for yourself, as I've put all of the clips on my site:

http://ErichMoraga.com/Squeeze

-----------------------------------------------------------------------------

Longer clips show that quality varies throughout the DivX encoded ones, while the WMV versions are consistently high quality through the whole duration. In addition, the crackling seems to only be present during the first few seconds. It may be a bug. The BeyondTV 4.3 release notes mention the addition of DivX 6.1 double-pass, but it would be nice to get down to really advanced settings. Since I'll be archiving my video (quality is important), WMV will be the way to go for now. I'll just bite the bullet regarding encoding time since it can be done while I'm at work or sleeping.

-Erich
July 8, 2006 12:46:30 PM

Hi guys.
I just read that the article author said he was using a RAID 0 config to increase speed.
But I have read some many dozens of benchmarks at www.storagereview.com that prove that RAID 0 does not improve at all the speed of any system (maybe you can notice a 1-2% increase at most).
So please stop perpetuating this false rumor : RAID 0 is a fake system optimization.
And there is no security of your data.
Better go for RAID 5 with a minimum of 3 (better 5) drives : there you have very good performance increase + security.
Unfortunately, only the latest Intel Southbridges ICH-6 or 7 are capable or RAID 5.
Otherwise you are limited with RAID 0 or 1 : forget about it !
Thanks.
July 8, 2006 10:26:42 PM

Quote:


The settings that you have control over are Frames Per Second, Dimensions, Two Pass Encoding, Average Video Bitrate, Audio Bitrate, Resize Style, Resize Algorithm, Bidirectional Frames, Noise Filtering, Performance Mode, and Psychovisual Mode.


Hi A64, I went back and checked, but I wasn't able to find anywhere in the web interface or the main BTV 4.3 show squeeze settings that allowed me to change any of the settings that you mentioned. Would you mind posting again and walk through the setup process for us in case there are other BTV users out there that want to benefit from the changes in showsqueeze options? Thanks! Also, thanks for the heads up on the Biostar/ECS comparison. I guess it's true what they say about ECS. :lol: 



Launch your browser (IE or FireFox/SeaMonkey - Opera doesn't work right), on the address line type the following:

http://localhost:8129

or if your system's address is for example 192.168.1.1
http://192.168.1.1:8129

Next, select the Setting button on the menu at the left.
Recording Preferences
Default Qualities - Hit the "List All Qualities"
Now you can make your own quality settings and modify existing.
July 9, 2006 7:33:43 AM

Thanks a bunch A64. It's too bad that Snapstream seems determined to hide most of these settings. I would never have known that they were there if you hadn't posted here.

Interestingly enough I found the settings in a slightly different location than you had listed. Once you pointed me in the right direction though I was able to find them. Again, thanks!

My path:
http://localhost:8129
Settings (On the right panel)
ShowSqueeze
Intelligent Quality Selection must be set to "Disabled"
Then the link appears called "Edit Video Qualities"
Then you have to scroll down and hit the "Create New quality" button

Finally the advanced settings can be adjusted. Audio and Video Bitrates, resolutions, Number of passes, Etc etc. Make sure to change the first selection to "show more options" to view all of the options available.
July 9, 2006 2:07:03 PM

Reader comment:
Quote:
Hey Mike, I recently read your article entitled "HD Encoding Face-Off: WMV-HD vs. DivX-HD". It was a very interesting article and I learned a lot about each codecs strengths and weaknesses. However, I believe there was one thing missing from your article, and that is the inclusion of the relatively new H.264 codec. The H.264 codec offers the same quality at even lower bitrates than Divx-HD, but requires a slightly more powerful computer to play the video file. Neverless, I was wondering If you could expand upon or write a new article on H.264 comparing it to other codecs. The free, open source version of the H.264 codec is named X264, and can be found at http://x264.nl/.

An encoder i have found that supports X264 is VirtualDub, which can be found at http://virtualdub.sourceforge.net/.

Some extra software is required to play the encoded files, and can be found at the previously mentioned X264 site. I believe the software needed is the ffdshow decoder. And mediaplayer classic, However i think other players can be used as lond as ffdshow is installed. I know this extra software can be a hassle, but I know that people who are extremely hard drive space consious will appreciate your inclusion of this codec.
July 10, 2006 9:31:00 PM

Reader feedback from Eric
Quote:
I read your review. And wanted to let you know I came to many of the same conclusions as you did. But you failed to mention what happens to the audio 5.1 stream during compression. I was curious what you found in that area?
July 10, 2006 10:07:54 PM

Quote:
Reader feedback from Eric
I read your review. And wanted to let you know I came to many of the same conclusions as you did. But you failed to mention what happens to the audio 5.1 stream during compression. I was curious what you found in that area?

My observation was that is gets converted to 384 kbps 2-channel stereo. Ideally I would be able to keep the original 384 kbps AC-3 track, as I've done with AC3 DivX before, with other programs. I'm not sure if it can be done with WMV. I'm pretty sure I downloaded a video from Microsoft a few months ago that showcased 5.1 channel surround, but I'm not sure if it was .WMV. I do remember I had problems with the playback on that file though. Also, I have an open ticket with SnapStream for the initial crackling on WMV squeezes.

For those who were curious how I obtained my Transport Stream:

The TS was sourced from an OTA signal relayed from a Samsung SIR-T165 to a JVC HM-DH30000U digital-VHS tape, which was relayed again (to the PC) via firewire using the program DVHSTool v2.13. The final cutting/splicing of the TS is done with HDTVtoMPEG2 v1.11.89.

-Erich
July 11, 2006 1:36:18 PM

Reader feedback from Dan:
Quote:
Good afternoon. Nice article by the way. I have one comment though. I believe it might be worth the time at some point to do an XviD comparison as well. What I've noticed is the majority of encodings are done using the XviD Codec rather than the DivX Codec. It may be worth looking into to see if there is a quality difference between DivX and XviD. If there is a notable difference, it would be cool to see it posted in a follow up article or addendum. Just a suggestion. Thanks!
September 19, 2010 3:23:42 PM

This topic has been closed by Reynod
!