Slashdot Mirror

As with VP9 earlier, the first reference AV1 encoder is absolutely slow: currently it's an order of magnitude slower than x265's veryslow preset (which is extremely slow to begin with).

At 40% better efficiency than x265, slowness is a given and perfectly forgivable. For all intents and purposes it's like a next generation codec, but license free. Now it "just" needs the hardware to enable it as a viable choice.

Apple joined the alliance just a few months ago when the development was almost over, which means Apple most likely didn't really contribute to it at all.

I don't see it being a problem except maybe for Apple. The fact they joined shows they reckon its value and I guess it's more than enough "contribution" at this point.

As with VP9 earlier, the first reference AV1 encoder is absolutely slow: currently it's an order of magnitude slower than x265's veryslow preset (which is extremely slow to begin with).

AV1 is not currently supported by anything under the sun except an alpha build of Firefox (where it struggles to decode even a 3Mbps video on powerful PCs).

Most likely ffmpeg will include its own decoder (implementation) because ffmpeg and AV1 developers have contradicting views on coding styles. ffmpeg has its own VP9 decoder.

Apple joined the alliance just a few months ago when the development was almost over, which means Apple most likely didn't really contribute to it at all.

The spec is 619 freaking pages long.

From Doom9 forum rules

Do not ask "what's best" because this question cannot be answered objectively. Each and everyone has their own view about what's best in a certain area. The best is what works best for you!

MPC-BE is still under active development, you can see some minor updates from 15 hours ago (new version of libpng)
https://sourceforge.net/p/mpcb...

The Doom9 support thread is still active
https://forum.doom9.org/showth...

V0lt is still active on the MPC-BE support forum (need google translate unless you can read Russian):
http://mpc-be.org/forum/index....

A while ago, someone made the nnedi upsampler that uses neural networks to upsample. It's still one of the best image upsamplers available.

Google's approach is quite a bit different. Where nnedi worked to better extract detail out of what was already in the image, Google seems to literally fill in detail that was probably in the source but maybe not. Much, I guess, like how our own memories work. It's an interesting approach and the results look quite fantastic. My only question is how well it will work on a random sampling.

Built in 2009, hardware cost: about $900 originally.

Currently:
Gigabyte X58/1366 socket (can't remember the exact model now)
Processor: Core i7 920 (Bloomfield) -- runs stock speed but is undervolted to 1.005v
6 GB DDR3/1600 running in tri-channel configuration
Geforce GTX 670 graphics card (this is actually an upgrade for me from January)

WD Caviar Black - 1 TB -- Boot Drive

Storage drives

WD Caviar Black - 640 GB (this was the original boot drive when I built it)
Samsung - 1 TB
Seagate - 2 TB

Optical drives:

Lite-On DVD burner w. Lightscribe support
Pioneer BD burner

OS: Currently Windows 8.1, originally Windows XP x64

Case: Antec Nine-Hundred
Power Supply: Antec TPQ-850

Monitor: Samsung T240HD (this is a 1920x1200 monitor with TV tuner functionality and component vid inputs) (separate purchase)

I'm not much of a gamer, and the system was built for my hobby of video processing/encoding, so I focused on putting money in the CPU and graphics were less important. I only had the one smaller Caviar and the DVD burner. But as HD video becomes more popular, storage needs grew. I do play games occasionally and have an account on Steam, I originally had a Radeon HD4830/512 for the graphics card and it worked fine. I had to upgrade recently because of the high video processing requirements of MadVR and a friend gifted me a copy of Transistor last Christmas (the system requirements needed a card with at least 1 GB of VRAM). I actually bought the GeForce second-hand from the same friend for a good price (it's an RMA replacement he'd only used for a few months himself before upgrading to a GTX 970).

I might build a new rig this year. I don't really have a processing emergency or anything, but I want to see what Skylake offers. I'd like a system that isn't so large and runs cooler. I have an NCASE M1 in a box here for the next system when I do it, and I already have a small FreeNAS server running I want to transition all the video storage to in the future so I don't need all the spinning drives in the PC. Will likely go to an SSD and 16 GB RAM for the next build.

in most cases you're looking at a firmware upgrade. Go here: http://www.doom9.org/index.htm...

HTH.

"Motion picture subtitles (as they are distributed on disc) are not text-based"

Do you actually do any ripping with hardware/media made this decade?

They dropped the images crap from DVD and went to time-coded text files with a chosen system font to display. Smaller, more efficient.

Uh, no they didn't.
Doom9: How to deal with Blu-Ray subtitles.

They still appear to be PGS (subpicture) based.

This question is better suited for Doom9.

True, but the AC is still right. I've looked at the comparisons and like it has been said elsewhere: VP9 is better than VP8, but that's about it.

See for yourself:
http://forum.doom9.org/showthread.php?p=1620230#post1620230

The third line in that posts links to this image, showing snapshots from the comparison between VP8, VP9, AVC (x264) and HEVC (HM10): http://i3.minus.com/i5vzrESbfwCmX.png

HEVC is just an absolute beast in (perceptual) video compression. If you look at the bitrates here, you assume that the videos must be crap, but they look ridiculously good. And that is with an early days reference encoder!

Most of the early results show that, while VP9 isn't better than h265, it's within a percentage point or two. That's not its problem.

Bull. Percentage points mean diddly squat when comparing different video codecs. Visually, VP9 doesn't even come close to h.265 (HEVC).

Convince yourself: http://forum.doom9.org/showthread.php?p=1620230#post1620230

No. ffmpeg people don't distribute binaries and our mostly outside the US. MPEG-LA has repeatedly affirmed that source code alone is fine with them. This had been affirmed by Ryan Rodriguez of MPEG-LA that shipping source code is not a product.

http://forum.doom9.org/showthread.php?p=1431854#post1431854

There's plenty reasons to dislike MPEG-LA without making shit up.

http://code.google.com/p/sacd-ripper/
http://forum.doom9.org/showthread.php?t=96860

Found within moments of googling for each.

DVD Decrypter is still useful
DVD Fab is also useful
DVD Shrink is useful
Freemake Video Converter can do wonders.

http://www.doom9.net/ is your friend.

DVD Decrypter is still useful
DVD Fab is also useful
DVD Shrink is useful
Freemake Video Converter can do wonders.

http://www.doom9.net/ is your friend.

It makes a difference of 1-2% on x264. Nothing earth-shattering. http://forum.doom9.org/showthread.php?p=1530754#post1530754

Really? I didn't realize this tool was written in the 90s. Coincidentally it isn't and yet still has the same shittiness of a Java GUI since the beginning.

There was a discussion about that here and someone actually talked to the MPEG-LA about that.
Note that the second post contains an edit at the end.

It seems like Blu-Ray support on Linux a bit limited at the moment, but there is at least some freeware/shareware that can handle it: MakeMKV which has a Linux beta and DVDFab which appears to run under Wine. DumpHD may also be worth looking at.

Wow, unbelievable. And it's still on Sourceforge! Since when do they host closed source?

As for an encoder frontend on Windows, Staxrip. Staxrip Staxrip Staxrip. Nothing else.

Unfortunately their statement is very misleading considering how VP8 and H.264 and other MPEG codecs use basically the same transform so their statements of bias against VP8 ring untrue. One of the professors who was part of doing this test even confirmed that the VP8 developers statement was untrue and misleading.

That a free codec like Theora exists is good, and it is estimated that Theora can be competitive with or even a bit better than XviD (MPEG4 ASP) when it is more developed and adaptive quantization (in version 1.2) and other psy optimizations are implemented

Not true at all. Every credible codec developer has come down on Theora like a ton of bricks. I used to believe in a lighter touch, but with the hard-core propaganda coming out of Xiph, Wikipedia, and Stallman/FSF, I'm not inclined to be so polite... Everyone who knows anything about video codecs calls it out as a piece of junk. The claims that H.261 is just as good were panned as biased, but aren't far off the evaluations given from every other technical source.

Let's try x264 developer Dark Shikari, who first said Theora might be able to compete with MPEG-4 ASP, but then looked into the details, and came back trashing the technical capabilities of the codec:

Dark Shikari8th May 2009, 20:38
Actually, it's worse than I thought. xiphmont just told me Theora has no MV prediction.

NONE.

Every MV is coded as either 6-bit X and 6-bit Y, or with a global static huffman table. This is worse than MPEG-1.

I retract my statement that Theora can ever get near MPEG-4 ASP. Removing MV prediction from x264, by the way, reduces PSNR by 1db at 500kbps on BlackPearl.

http://forum.doom9.org/archive/index.php/t-146893.html

but currently the encoder has some problems that need to be addressed.

The problems with the VP3 format are fundamental and can't be optimized out. The lousy deblocker that makes things worse, the lack of B-frames, etc, etc. (no time to get into much detail here...) Let's give Mike Melanson the last word here:

What I would like to get across here is that Theora is rather different than most video codecs, in just about every way you can name (no, wait: the base quantization matrix for golden frames is the same as the quantization matrix found in JPEG). As for the idea that most DCT-based codecs are all fundamentally the same, ironically, you can't even count on that with Theora- its DCT is different than the one found in MPEG-1/2/4, H.263, and JPEG (which all use the same DCT).
http://multimedia.cx/eggs/dct-pr/

[...] which is unfortunate considering how long the format has been in development.

That's...an incredible under-statement on your part!

You are right, and there is also the fact that Youtube used a really bad H.264 encoder back then. They have recently switched to x264, so while the SD clips are still encoded in baseline profile that should give them a little boost in quality.

All in all that comparison linked in the summary probably done more to hurt Theora than to help it, because it has given the codec a bad name in the video encoding community. One of the main developers of x264 recently posted about the comparison and Theora in general.
The part concerning Theora having the same quality as H.264:

On the other hand, the Theora devs themselves are strongly against any such claims. gmaxwell asked me to "bonk on the head" anyone who claimed that Theora was nearly as good, as good, or better than H.264, because such claims not only create unreasonable expectations that the devs cannot possibly live up to, but also create the impression that "Theora supporters are liars", which is obviously rather counterproductive to what they are trying to do.

That a free codec like Theora exists is good, and it is estimated that Theora can be competitive with or even a bit better than XviD (MPEG4 ASP) when it is more developed and adaptive quantization (in version 1.2) and other psy optimizations are implemented, but currently the encoder has some problems that need to be addressed. The current Theora encoder is relatively slow. It should be much faster than x264 because of the simpler format, but it currently only has a rather small speed advantage (using the defaults on both encoders; same bitrate) on a single core CPU and it doesn't support multithreading while x264 scales almost linearly with the number of cores. Then there is the fact that the current Theora encoder is dropping frames in 1-pass and 2-pass mode which is unfortunate considering how long the format has been in development.

There are a couple of comparisons between x264 and Theora 1.1 and currently it looks like an up to date x264 revision can give better quality than Theora at half the bitrate with slightly slower (single core CPU) or much faster (multi core CPU) encoding speed using the default settings in both encoders.
Videos; current Theora and old x264 (pre MB-Tree)
Metrics ; on animated content
Screenshots; TV capture and video game footage

CoreAVC doesn't cheat by lowering quality. The output of a compliant H.264 decoder has to be bit exact in every mode, not just lossless. CoreAVC also uses hardware decoding in newer nvidia cards and there it couldn't cheat even if it wanted to.
Most of the time when people have problems with the look of AVC videos it's a renderer issue that makes the colours look washed out, but that's not really the decoders problem and can easily be fixed. Another popular problem is people turning deblocking off on the decoder because they think it is optional. Most H.264 decoders provide such an option to speed up decoding if you have no other way to play the video smoothly, but that can cause serious artifacts like blocking and colour drifts that get progressively worse throughout the GOP. Also on doom9 you sometimes get people who claim 2 screenshots show differences between decoders while when you compare them bit for bit they are the same. Just goes to show that if you really want to see a difference you'll see it whether it's there or not.
CoreAVC also doesn't decode video much faster than other (free) AVC decoders these days. ffmpeg came a lot closer to its performance and there is also the DivX AVC decoder and DiAVC which offer comparable performance.

While we are at the topic of video and H.264: Theora is not in the same league as H.264 and claiming so doesn't do it any good. In fact the Theora developers discourage such claims.

CoreAVC doesn't cheat by lowering quality. The output of a compliant H.264 decoder has to be bit exact in every mode, not just lossless. CoreAVC also uses hardware decoding in newer nvidia cards and there it couldn't cheat even if it wanted to.
Most of the time when people have problems with the look of AVC videos it's a renderer issue that makes the colours look washed out, but that's not really the decoders problem and can easily be fixed. Another popular problem is people turning deblocking off on the decoder because they think it is optional. Most H.264 decoders provide such an option to speed up decoding if you have no other way to play the video smoothly, but that can cause serious artifacts like blocking and colour drifts that get progressively worse throughout the GOP. Also on doom9 you sometimes get people who claim 2 screenshots show differences between decoders while when you compare them bit for bit they are the same. Just goes to show that if you really want to see a difference you'll see it whether it's there or not.
CoreAVC also doesn't decode video much faster than other (free) AVC decoders these days. ffmpeg came a lot closer to its performance and there is also the DivX AVC decoder and DiAVC which offer comparable performance.

While we are at the topic of video and H.264: Theora is not in the same league as H.264 and claiming so doesn't do it any good. In fact the Theora developers discourage such claims.

I'd be interested to see the comments you alluded to. If you see sub-standard or blurry video, you need to ask for help (you might be doing something wrong) or file a bug report. Any issues I've seen with CoreAVC have been fixed quickly -- there is a small community of experts who expect nothing less than excellent quality.

> Blu-Ray has, to date, been sufficiently designed to prevent an open source player, right?

Not really.

I agree that speed is important, but if you want the best quality at a certain encoding speed everything speaks for ditching DivX and XviD in favor of x264 as an encoder. Neither DivXs nor XviDs threading scales well when encoding on a multi-core processor. The speed gain for more than two cores is very low and going from one to two cores only nets you about 70% speed gain to begin with. When you compare that to x264 which can use all cores to 90+% of their potential thats pretty abysmal. If you search Doom9 you'll find a comparison done years ago that showed that even on single core processors when x264 settings were tuned to match XviDs speed with various settings x264 always came up on top quality wise. Unfortunately the graphs aren't there anymore and the x264 command-line arguments have changed in the meantime, but since the preset system has been added finding a good speed to quality trade off is easy. That was before several features that improve the visual quality with minimal speed loss, like adaptive quantization and the new MB-tree rate-control, were implemented. The x264 developers are constantly working to improve encoding speed as well. Take a look at the changelog.

After years of ripping DVDs and occasionly trying out Theora, my conclusion is that Theora is crap. Definitely better than H263, but not even close to H264.

So with that in mind, I make the following points:

1. Greg Maxwell's comparison does invalidate You Tube's claim that quality would suffer. Theora is quite close to YouTube's encode, and H264's default deblocking actually makes me prefer Theora in some instances.

2. This does not at all show that Theora is better. It's not. YouTube's encoder has to be fast enough to encode all the video submitted to YouTube, something like an hour every minute. Comparing carefully encoded x264 with carefully encoded Theora would be a fair comparison.

And final, a suggestion.

3. H264 should the same thing Blender did and makes the codec copyright and patent free using the street performer protocol. I would certainly donate at least $100 to free H264.

Of course, the suggestion is probably bad business wise. I'd like to know how much money is being made of patent licensing each year.

Nothing beats Xvid for low bitrates. (The bitrates which create ~350MB videos)

x264 pounds xvid into dust at low bitrates.

h.264 gets quite blocky well before Xvid does

Er, no it doesn't. H.264 has a strong in-loop deblocking filter which leads it to degrade into softness well before it loses detail. If you're thinking of a metric like "no annoying artifacts" x264 can go down to half xvid bitrates at the same quality level. Codecs converge as quality goes up, but it's exactly low bitrate non-blocking video where H.264 excels, and what it was designed to do. And designed to do so specifically after the failure of MPEG-4 part 2 (xvid/divx) to be a competitive low bitrate codec.

A presentation with slides occasionally changing works wonderfully in VP7. It'll use a couple hundred kilobytes on the first frame, plus any frame where it suddenly changes, but aside from that it won't use much/any bandwidth. The result is a video that looks like a 32bit gif animation(perfect quality).

All non-pathological codecs will do the exact same thing.

Really, Theora may get to MPEG-4 part 2 Simple Profile quality with a lot of work, but no way will it ever be competitive with H.264 or VC-1.

Read this:

http://forum.doom9.org/showthread.php?t=146893

Turns out there was an error in the methadology used in the original comparison, which hit x264 for more than 4 dB of difference.

http://www.reddit.com/r/programming/comments/8iphn/theora_encoder_improvments_comparable_to_h264/c09eyvc

Edit: HAHAHA! We figured out what was wrong--thanks a ton, gmaxwell, for coming on IRC and resolving this! Turns out his testing methodology was flawed... but not in the way I thought!
Turns he out he did everything correctly... but he used ffmpeg for outputting the raw y4m file to have its quality measured by dump_psnr (but not for theora). Apparently, ffmpeg flags the output chroma as "420mpeg2" instead of "420", which results in over 4db of PSNR being slashed off of x264's results unfairly.
Oops. We already have a patch submitted to ffmpeg for the problem and a retraction of the Theora comparison results is in the works. Thanks to gmaxwell for taking the initiative and David Conrad (Yuvi) for finding the bug!

The Doom9 thread on the same topic:
http://forum.doom9.org/showthread.php?t=146893

Anyway, given H.264 is a more recent codec that is highly optimized for PSNR and has had many years of refinement in a number of implementations, it's hard to conceive of how Theora could even approach it in compression efficiency, let alone beat it.

Apparently this wasn't a test of x264 versus Theora at all. Instead, it was a blog post designed to debunk this incredibly awful paper that claimed H.264 had up to a 20db advantage over Theora.

But then another blogger hijacked the graph and posted it to demonstrate that Theora was now as good as x264. And away it went...

No settings is another sign of the "quality" of that article, after all it is well known what impact they have on encoding quality. It's like saying "look, there's a rotten apple and a fresh peach, so all peaches are better than apples".

Biased, I know, but here's what an x264 developer had to say in response.

Quote: They apparently used the worst possible x264 settings (yes, subme 0 and so forth) in order to make Theora look better--if Theora didn't win such a test I would be shocked indeed! Instead, they just proved the fact that they're a bunch of liars who are no better than the worst of the proprietary companies they claim to compete against.

Main Concept being the best overall.

Oh? this (and this follow up post) seem to indicate that it's not so clearcut. Looks like x264 beat MainConcept in most tests, and the major tests it lost in were rather unrealistic.

But in the interest of full disclosure, Dark Shikari is one of the main developers on x264, so he's got an obvious bias. Doesn't necessarily make him wrong though.

Main Concept being the best overall.

Oh? this (and this follow up post) seem to indicate that it's not so clearcut. Looks like x264 beat MainConcept in most tests, and the major tests it lost in were rather unrealistic.

But in the interest of full disclosure, Dark Shikari is one of the main developers on x264, so he's got an obvious bias. Doesn't necessarily make him wrong though.

I don't mean to belittle Theora, I've really been rooting for them over the years. And this recent test does look fantastic.

But I can't help wonder what settings they are testing x264 with. x264 has recently been shown to be highly sensitive to clips like the Akiyo one tested here -- it also lost to some other H.264 encoders that it usually beats fairly consistently. The version and settings used to encode this one make a WORLD of difference.

With youtube's 720p(*) videos, the quality is actually better than dvd's.

Essentially, you're asserting that more pixels is necessarily better than higher bitrate. The bitrate on youtube looks to be around 600kbps while DVDs max out around 10MBps. From what I've observed and read, YouTube runs H.264 and is typically the same quality at half to a quarter of the bitrate of MPEG2, which is what DVDs use. Using these rules of thumb, DVD quality is unquestionably better, if you're looking at a fixed pixel count.

In reality, low bitrate H.264 will be okay for low motion stuff (people talking into webcams, idiots falling off their roofs or whatever). Upload the first 10 minutes of Saving Private Ryan to YouTube's HD service and then compare that to the DVD. Not that DVD does stuff like that well; you can certainly pick out scenes where DVD doesn't have the bitrate with MPEG2 to handle 480i television (Saving Private Ryan, Fantasia 2000 with the whales and butterflies).

Now, if we wanted to compare CODECs, YouTube wins. If we could even put H.264 on a DVD, the increase in pixels up to 720p wouldn't be a problem -- 1080p might even be decent on all but the worst scenes.

The nice thing about Windows 7 in relation to media is that MS provides a much wider selection of audio and video codecs and splitters for more containers than ever before. That is nice for those that are not into using things like mplayer, vlc, or ffdshow. The bad thing is that somehow Windows 7 treats the system supplied ones as special so things like ffdshow and Maali media splitter stopped working, the MS provided stuff was always used first. By now I think the devs have a handle on stuff like this but it was a pain in the neck. It required changes in a portion of the registry that admin users could not change, SetACL needed to be used to allow modification first:

http://forum.doom9.org/archive/index.php/t-145906.html

There are reasons you might want to use the non-MS stuff. For example the system provided ones seem to be more resource intensive than the alternatives, for example if you have an NV card and CoreAVC (which you had to pay money for) or ffmpeg-mt. The system supplied stuff does not seem to understand chapters in MKV and MP4. There is not a nice way to have subtitles automatically superimposed on your video.

Not to mention most DVDs are encrypted and many DVDs are damaged in creative ways to try to prevent people from copying them.

Never had a problem with DVD Decrypter (you can download from FileHippo). Just take care to turn off 'check for program update' in the settings on DVD Decrypter (MacroVision owns the original domains now so there won't be any more updates anyway). Also, check out Handbrake for your format conversion and shrinking needs. You may also find the guides over on Doom9 to be useful. Good luck and cheers mate.

Last I checked (maybe 1 year ago), doom9 was another very good resource. Concept explanations, tutorials for about anything transcoding-related, software comparison, ... Unfortunately it is very windows-centered.

It's "current" as of September 2008..

O Rly?
*cough*

np: Autechre - We R Are Why? (WAP72 12")

If you like Media Player Classic, be sure to check out the Homecinema adaptation from Casmir666 and others:

http://mpc-hc.sourceforge.net/

MPC-HC adds hardware accelerated H264/VC-1 decoding via DXVA for windows. There's also a new build patched by Beliyaal which uses a new Vsync detection method to substantially reduce jitter for very smooth playback:

http://forum.doom9.org/showthread.php?t=145203

Not true. x264 improves on 1-pass encoding, but there are plenty of ways to improve quality that require 2 passes (or a much larger buffer) to work properly.

The difference between direct spacial and temporal will be trivial. As explained here http://forum.doom9.org/archive/index.php/t-143904.html by Dark Shikari, an active x264 dev, 2-pass encoding is no more efficient than crf.

"CRF, 1pass, and 2pass all use the same bit distribution algorithm. 2-pass tries to approximate CRF by using the information from the first pass to decide on a constant quality factor. 1-pass tries to approximate CRF by guessing a quality factor over time and varying it to reach the target bitrate."

Here http://forum.doom9.org/showthread.php?t=134545 he says "2pass is not measurably better than CRF, in general."

The idea that multiple passes increases quality is left over from the time of mpeg-4 part 2 and part 4 encoders where this was the case.

As for the sliceless multi-threading used by x264 there should be no significant quality loss unless the number of threads exceeds video_width/mvrange, so it depends on what you mean by a large number of threads and what you consider a reasonable mvrange to be. If you are unhappy with this limitation look at how x264farm works: http://omion.dyndns.org/x264farm/x264farm.html. It splits a video at scene-cuts and allows the scenes to be encoded in parallel as mentioned earlier. And yes it does work with multi-pass encoding.

Not true. x264 improves on 1-pass encoding, but there are plenty of ways to improve quality that require 2 passes (or a much larger buffer) to work properly.

The difference between direct spacial and temporal will be trivial. As explained here http://forum.doom9.org/archive/index.php/t-143904.html by Dark Shikari, an active x264 dev, 2-pass encoding is no more efficient than crf.

"CRF, 1pass, and 2pass all use the same bit distribution algorithm. 2-pass tries to approximate CRF by using the information from the first pass to decide on a constant quality factor. 1-pass tries to approximate CRF by guessing a quality factor over time and varying it to reach the target bitrate."

Here http://forum.doom9.org/showthread.php?t=134545 he says "2pass is not measurably better than CRF, in general."

The idea that multiple passes increases quality is left over from the time of mpeg-4 part 2 and part 4 encoders where this was the case.

As for the sliceless multi-threading used by x264 there should be no significant quality loss unless the number of threads exceeds video_width/mvrange, so it depends on what you mean by a large number of threads and what you consider a reasonable mvrange to be. If you are unhappy with this limitation look at how x264farm works: http://omion.dyndns.org/x264farm/x264farm.html. It splits a video at scene-cuts and allows the scenes to be encoded in parallel as mentioned earlier. And yes it does work with multi-pass encoding.

and it definitely does not result in significant quality loss.

Not true. I just don't have the time to argue the point in detail right now... Go do some encodings with/without a large numbers of threads, with PNSR or other objective metric measurement, and try again.

And besides that, x264 is really only multithreaded on the SECOND pass. The first pass will barely use more than a single CPU.

there's hardly any reason to use 2-pass encoding over crf encoding unless you are still burning your videos to optical media.

Not true. x264 improves on 1-pass encoding, but there are plenty of ways to improve quality that require 2 passes (or a much larger buffer) to work properly.

http://forum.doom9.org/showpost.php?p=996114&postcount=2

Media Player Classic is not under active development anymore. There is a fork, MPC Home Cinema, that retains the same interface and adds new features like hardware accelerated AVC and VC-1 decoding on cards that support it. (Geforce 8xxx or newer and any Radeon HD) There are a lot of other improvements as well, see the changelog.

http://mpc-hc.sourceforge.net/

You can also find current development versions of the player on the doom9 forum.
http://forum.doom9.org/forumdisplay.php?f=15

You're thinking of MP3's joint-stereo messing up Dolby Pro Logic (as described here). Not really important to me, I recently ditched my 5.1 setup for a nice pair of stereo speakers.

No, I can't hear the difference. I can't even hear the difference between FLAC and 128kbps MP3s from a modern encoder on most samples.

But I might want to transcode to a lower bitrate for a portable or network player. Or maybe I want to use some funky DSP which has the unfortunate side effect of showing up MP3 artifacts. Who cares? Disk space and bandwidth is just SO FUCKING CHEAP why would you want anything but lossless when it's so damn easy? Sending the actual data is probably the smallest cost of selling music online, so why is it even an issue? Lossless just seems like a no-brainer to me.

There are patches out there to disable Macrovision on ATI cards, the first link on that page is to one such tool. Not sure if it works on current drivers but you could always downgrade while ripping.

The cited preprint claims to have broken the very fundament of RSA:

Theorem 5. The factorization of a composite integer N â â has deterministic logarithmic time complexity
O((log N)c ), c > 0 constant.

I doubt it.

I don't see any quality issue. Its crisp clear.

The relative value of a lossy video codec is in how good the quality is, at a respective bitrate. If you crank up the bitrate on ANY video codec, you'll get something that is true to the original, but at a prohibitive bitrate.

VP3 and Theora have been tested, over and over again, and simply do not provide better quality than practically any other video format, at a reasonable bitrate. Nearly all Divx/MPEG-4 ASP and h.264/AVC codecs substantially outperform it, as has been demonstrated time and time again...

http://www.doom9.org/codec-comparisons.htm
http://www.doom9.org/codecs-quali-105-3.htm
http://ww.osnews.com/story/19019/Theora-vs-h.264/

And yet, it's EXTREMELY computationally intensive... I doubt any CPU out there can decode 1080p Theora videos in real time. Many slightly older systems can't even decode DVD-resolution Theora videos. Putting Theora behind even H.264 in the performance dept.

The only thing VP3/Theora does well is extremely low bitrate videos, because of its deblocking filter. Still, it's not remotely as good as H.263 or H.264/AVC in that aspect, but still, it's something...