This company uses machine learning and voice recordings to keep frustrated telemarketers on as long as possible after you merge calls with them: jollyrogertelephone.com

Funny how is number of users is 2^10 + 2^9 - 1. 'Lot of code smell in this article.

This is because release groups are completely, utterly clueless about video. The file size is set ahead of time. Most groups set e.g. "8GB for 1080p movie", "4GB for a 720p movie" etc. in x264. Historically speaking, these pre-selected sizes were designed to fit on different media types, such as CD, single-layer DVD, dual-layer DVD.
Few people use DVDs anymore, but most groups still make files far larger than they need to be.

I rarely download pre-made videos because of this, so haven't downloaded any encoded in h.265, but I suspect they simply chose a smaller pre-set size.

The correct, non-stupid thing to do is to set the quality and let the movie be however large it needs to be, usually under 4GB. This allows more easily encoded video, like CGI films (Toy Story, etc.) to be small while very difficult films (anything with a lot of noise and movement, like war films) are large but don't look terrible.

I always use Staxrip
https://github.com/stax76/stax...

Forgot to add: I was using recent builds (about a month back) of x265.
Whenever a comparison is made, the x265 folks always say that the latest versions are much improved over whatever was used in the comparison. They may be, but they still need some work based on my tests.

I have done my own comparisons of AVC (using x264, single-thread, veryslow preset) and HEVC (using x265, disabling wavefront processing because it slightly reduces quality, veryslow preset). All 1080p video, significant because HEVC is supposed to scale to 4K better than AVC.

My conclusions:

1) x265 takes FAR longer to encode, but we knew that. Understandable.
2) When "low in bits", x265 blurs images rather than making them look blocky. This sometimes looks better but to me often looks worse.
3) x265 seems to force a denoise filter. Video is far easier to encode efficiently when denoised, so I figure this is part of the data savings. It's a bit of a cheat, however, because I can get far smaller file sizes by running a denoise filter myself for x264-encoded video.

I looked closely, for example, at Captain America the Blu-ray. Much of the detail of, e.g. car leather and grass and tree leaves is lost in an x265 encode, even at about the same overall data rate as x265/

x265 supports "--tune grain", roughly analogous to "--tune film" for x264, but it makes the video vastly larger -- often larger than x264's version, and it often looks worse. It does a better job of keeping grain, however.

My experience is very similar to many others' in forums. I had committed to switching my encoding to HEVC, but the results of my tests showed it is not ready for prime time. Some may not mind blurry ("soft" is probably a better word) video, or video that looks like it has been through a denoise filter, but I do.

This is not to say that x265 is junk. I am sure it will mature over time just like x264 had to over time. x264 started out as being not all that much better than divx, the previous generation.

Many GUI applications can be controlled via GUI commands. Showing this helps students understand the link between the magic that goes on under the hood, and the actual action that takes place to make that happen.
Sure, not everything is a GUI shell over a CLI program, but the concept of typing a command isn't that different from one of making an API call to Qt or GTK+.

That's funny, I was just in several of the buildings in Redmond last week and found that all drinks -- even those in the cafeteria, are gratis. Paying isn't even an option -- there's simply nowhere to put the change.

For any personal issues you may find with Microsoft as a company, I have seen and heard nothing but good things from their employees.

Digital images are displayed in RGB, yes.

But colors are printed in CMYK (Cyan Magenta Yellow Black), and you'll notice that the best photo inkjet printers have more than just those four color cartridges. They often have the four plus "photo cyan", "photo magenta", etc. and it does make a huge difference.

As you know, some colors cannot be accurately expressed in CMYK, nor can some in RGB (even though theoretically any color is possible, but theory is not reality in this case).

While the extra color may or may not make a big difference, there is at least precedent indicating that the idea is sound.

Author: I think this article is simply very well written. I plan to send a link to all the CS professors I know.

If only the Python documentation were written half as well.

Seems economical.

Until they try to restore the backup.