I welcome our new h.265 10bit overlords.

>>85846722
h.265 is 10bit by default

>not using VP9
plebeians

File: 1368964537802.jpg-(26 KB, 400x400, jewdar.jpg)

26 KB JPG

>>85846777
botnet shill pls
also VP9 is inferior in picture quality to h.265

>>85846818
[citation needed]

>>85846902
>>>/google/

>>85846818
>free video compression
nice try

File: 1368964747447.jpg-(10 KB, 450x394, 201303-vp9-vs-h265.jpg)

10 KB JPG

>using h.26*
>2013

>>85846936
>jewgle
>free
lol
enjoy your shit quality and being data mined and fucking the web standards for even more data mining

File: 1368964862697.jpg-(31 KB, 272x385, lol 01.jpg)

31 KB JPG

>>85846935
can't even provide proof

File: 1368965140805.jpg-(17 KB, 589x394, 1368964747447.jpg)

17 KB JPG

>>85846957
You suck at labelling axes.
I fixed it for you.

While I can't say if VP9 or H.265 is better as a standard, as far as the current encoders go, x264 > HEVC reference encoder > VP9 reference encoder.

>>85847019
They said it's 1% more efficient in bitrate for trading image quality compared to h.265. It actually delivers h.264 quality at the bitrate of h.265. Watch jewgle I/O you imbecile.
also >>>/v/
Fuck google and all their shit. They promised to discontinue h.264 support in botnet browser and lied fucking mozilla in the process.

>>85847179
h.265 is better, but also paid. And as far as I know, VP9 is closed to being actually usable.

File: 1368965276673.jpg-(49 KB, 414x465, nigga are you serious 01.jpg)

49 KB JPG

>>85846986
>doesn't understand how encoders/decoders/renderers work.

I can't wait. I wonder how far they're going to be able to take this? Where does the limit lie in encoding quality?

>>85847257
>20XX
>not sending data to Google on every frame, from the decoder

File: 1368965465241.gif-(2.22 MB, 388x356, jewpc.gif)

2.22 MB GIF

>>85847257
>google shit
>good encoder
VP8 encoder is slow as shit as VP9
They also lack quality.
shill please

File: 1368965495781.jpg-(130 KB, 1046x882, even socially inept is la(...).jpg)

130 KB JPG

>>85847221
[citation needed]

>>85847221
>h.264 quality at the bitrate of h.265
But I want h.265 quality.
>Watch jewgle I/O you imbecile.
Why would anyone watch propaganda willingly?

File: 1368965557807.jpg-(157 KB, 560x570, satensmug2.jpg)

157 KB JPG

>>85847385
>Watch jewgle I/O you imbecile.
you seem mentally disabled, shill

>>85847301
I assume there is no theoretical limit as long as hardware keeps improving.

>>85847423
[citation needed]

>>85847447
https://en.wikipedia.org/wiki/you-are-mentally-disabled

>>85847445
From what I've understood there are quantum computers already. Even with those, I don't think you could put 22/23 minutes to 50mb is good quality. Right? There has to be a real limit, right?

>>85847363
In fact the reference encoder for VP8 had some bugs and since they did not document the codec properly, the reference encoder was the "documentation", thus the bugs from the reference encode became the codec specifications, which is just sad.

DAIZ!

>>85847493
In the future, a whole 50 episode series in 4000p by Coalgirls will be one megabyte, and it will still be considered bloated.

I'm waiting for an H.265 encoder by Dark Shikari and co.

>>85847553
he's too busy smoking cock

People saying that either VP9>h265 or h265>VP9 are retards considering neither of them are actually available right now. Just fucking wait until both of them are released officially and then you can start measuring to see who got the bigger dick.

>>85847674
Well VP9 is free, so.... fu

>>85847674
>VP9>h265
No. In image quality h.265 is superior.

>>85847493
The current quantum computers aren't as powerful as the ones we currently have sadly.
But if we can achieve an infinite amount of calculations, we can theoretically make the file incredibly small. Of course there's always going to be a limit since you can't compress keyframes and inbetween data to 0.

>>85847704
Shit is free too, it doesn't mean it's better than a high class dessert.

>>85847704
fuck off botnet shill
the only true free format is daala

>>85847718
No it's not stop being a shill neither of them are actually released yet.

>>85847654
I'm waiting for madvr support.

>>85847750
What? Then why did Google and NASA buy a 15 million dollar quantum computer? If it's slower, what's the point in even making them?

>>85847752
VP9 is slightly worse, but it's still good and free.

>>85847799
Research on how to make them better? duh...

>>85847781
lyl
there's comparison VP9 looks like shit compared to h.265 at the same bitrate

>>85847799
Because they will get faster as technology advances, it's just the beginning.

>>85846678 (OP)
>implying it actually started

>>85847807
You get what you pay for.

File: 1368966306568.jpg-(69 KB, 1200x1200, 28449694.jpg)

69 KB JPG

>>85847793
Madvr is irrelevant. It just renders raw formats.(NV12, P010 and such) What we need is, H.265 libavcodec opensource decoder.

>>85847831
Show me the comparison where both use similar bitrates, oh yeah that's right you fucking can't since there is no comparison like that yet. Stop being a fucking shill

>>85847793
MadVR is a renderer, it has support by default.

File: 1368966366255.jpg-(5 KB, 1280x720, hi444p+opt.jpg)

5 KB JPG

>>85846938
> 10 whole kilobytes for a tiny 500x566 image
Seriously, it's like you guys don't know how to do proper quantizing and can't be bothered to hand-tune the matrices. See example, that's how you do proper compression.

What are the differences between the VP9, H.264 and H.265.
I know H.265 has a some new macro blocking stuff that H.264 didn't have but what's the actual differences. All that we're doing now is comparing the current encoders.

>>85847874
>>85847876
Oh, great then.

>>85847906
Kyon plz go.

just give me a decoder and a sample
for fucking sake

>>85847825
No, the article explicitly said that Google planned to research speech recognition and NASA wanted to simulate certain situations.

The article also said that it could calculator certain calculations at a rate that's 3600 times faster than a binary architecture computer.

>>85847553
SUMMON. SUMMON.
DAIZ. DAIZ.
FILESIZES. 10bit.
ARISE. ARISE.

>>85847969
they don't exist yet

>>85847906
It's amazing that I can actually make out what that is.

>>85847875
just look the google i/o fag
can't bother to search the entire video

Just imagine the shitstorm about HEVC 14 bits. Man, it will be glorious.

>>85847985
>calculator
calculate.

i remember when everyone was going ham over h.264 like it was yesterday

>>85847991
Your brain has native uncompressors.

>>85847989
Then how come they have HEVC decoding in tech demo's? And didn't google also demonstrate VP9 decoding?

>>85847989
Then why are we even talking about it?

>>85847874
>madvr is irrelevant

You what

>>85847991
You don't want to know what I had to do to make that image.

>>85847985
I'm pulling this out of my ass, but it probably depends on what you're using the computer for. It might be vastly superior at doing certain calculations compared to a binary computer but sucks at others.

Kinda like how graphics cards are good for breaking hashes.

>still using computer to decode videos
>not injecting video into brain for direct consumption
>3013
>ISSHYGDDT

>>85847985
>certain calculations at a rate that's 3600 times faster than a binary architecture computer.
1) certain calculations
2) Compared to the fastest binary architecture computer? It's possible, but they probably meant one of the same size or something.

>>85848064
You can use any decoder with MadVR.

File: 1368966718286.jpg-(72 KB, 1280x720, 54.jpg)

72 KB JPG

>>85847930
well instead of 600-700mb(720p) files you will now have 1-1,2gb filesizes without quality improvement.

>>85848064

Madvr is a renderer not decoder, dumb fucker.

>>85847019
>the source is literally Google

>>85847493
Good quality is subjective. Re-encoding a file is what is known as lossy compression. As well as ordinary (lossless) compression, some data is thrown away.
There is no theoretical limit to lossy compression, because you can throw as much data away as you like. It's a pain to judge what counts as "good"

If it's okay, I'd like to talk about this problem in a purely mathematical sense, since I have no experience in video encoding.

Say we have a function x we want to approximate. We can use something called a taylor expansion to write it down as an infinite long polynomial. Even in these terms it's difficult to judge what a good approximation is, but whatever means you use, the smallest way to write down your approximation is as the coeffients of x^n

In this sense, there is a lower bound on how little data you need to express the approximation.

Of course, more efficient codecs can achieve a smaller lower bound. which is the real question, (in my approximating a function example, we could use a fourier transform, or chebyshev instead which may prove more efficient)
Is there a theoretical lower bound on how efficent an algorithm can be? You'd have to talk to information theorists about that, but I'd hazard a guess and say yes. The trick is finding an algorithm that is efficient for lots of different videos.

>>85848064
encoded data -> decoder -> raw video -> madvr -> screen -> your eyes

The decoder is irrelevant to MadVR, it doesn't care what the source data was

>>85848067
yeh I do.

>>85848218
I had to read a manpage and type commands in a shell interpreter!

what renderer does xbmc use? I've noticed videos look much better on xbmc than it does on mpc.

>>85847875
http://forum.doom9.org/showthread.php?p=1614397#post1614397

Maybe if you googled better you incompetent piece of shit

>>85848040
They did, on very poor screens that were likely to be separate frames.

>>85847301
Lossy compression can pretty much always stand to be improved by throwing more memory and cpu at it. It's not like lossless where there is an inherent limit.

>>85846678 (OP)
Sure.

But animu will doubtless find a niche profile that no device supports that offers benefits no human can perceive. The circle of life will continue.

>>85848317
I don't know what that means.
Thanks though

>>85847906
> not choosing coefficients and writing the bitstream by hand in a hex editor
fucking pleb

Since this is actually the right thread, I'll just go ahead and ask this:

Who the hell is Daiz? Why is he so (in)famous here? Did he push hard for 10bit or something?

inb4 newfag

>>85848628
>inb4 newfag
Not knowing who Daiz is and what he did is 100% prove that you ARE in fact new.

Fuck off, lurk and Google more.

>>85848683
Google won't really tell him much.

>>85848628
>inb4 newfag

Good that you understand.

>>85848628
He does encoding for some subgroups and blogs about it a lot on /a/ over the years.
I don't know when he started but I think I first talked to him in 2008.

>>85848726
It will actually.

Some facts:

1) H.265 and VP9 encoders exist.
2) However, they're nowhere near ready for production usage since they're inconvenient to use and horribly slow (you probably don't want to wait a week or two just for a single 24min 720p encode to finish)
3) Compression quality -wise the likely outcome is H.265 > VP9 > H.264
4) Google's "50% better than H.264 and only 1% worse than H.265" figures for VP9 should be taken with a large grain of salt for now since they have an obvious business interest in seeing VP9 succeed and they haven't provided any solid test data that could be verified by independent third parties.
5) Whether a format is "free" or not has no relevance to fansubs since they're illegal to begin with, so generally speaking what's best is what matters the most.

>>85848628

Daiz is our lord and savior.

>>85848835
Summoning is complete.

>>85848726
>>85848737
fuck you guys. the only times that name appear on /a/ are when anons spew out those "beware of daiz" memeshit, which amounts to the samething by googling:

https://startpage.com/do/search?q=daiz+10bit

I lurked. I searched. I didn't find it. So I asked. this is z-plan.

>>85848835
Summoning successfull

>>85848864
If you went in and read the 5 first links you would immediately know who Daiz is and what he's known for.

Lurk the fuck more.

>>85848835
>Google's "50% better than H.264 and only 1% worse than H.265" figures for VP9 should be taken with a large grain of salt for now since they have an obvious business interest in seeing VP9 succeed and they haven't provided any solid test data that could be verified by independent third parties.
Google is just bullshitting, as they've been known to do.

Why do the primary profiles for both HEVC and VP9 both enforce chroma subsampling? This is disgusting. There is no filesize or quality benefit from using chroma subsampling over having the encoder decide what chroma information needs to be kept.
Chroma subsampling just blindly removes a quarter of it.

>>85848835
Daiz, why is your AB account dead?

Are you encoding again - I remember you taking a break for a while...

>>85848967
Japan only uses 4:2:0 for anime. (digital TV, DVD and BD)

>>85848835
>5) Whether a format is "free" or not has no relevance to fansubs since they're illegal to begin with, so generally speaking what's best is what matters the most.

This. For all we know, fansubbers are using Mac to compress our anime.

>>85849058
> fansubbers are using Mac to compress our anime
How is that even remotely related?

>>85849058
I guess it explains why fansubbing is always at the technology forefront compared to everyone else.

>>85849021
I just haven't had a need for it.

>>85849058
Encoders generally use Windows because of Avisynth and other tools.

>>85848835
When will you change your trip to H.265? I remember last year you talked about it, but you weren't ready yet.

>>85849132
more like when are you going to change your trip to VP9

>>85849132
When H.265 becomes actually relevant. That's still going to take a good while.

>>85849113
I thought macs were the shit for video editing and encoding?
What the fuck are macs good for then?

>>85849053
That's because everything is forced to use chroma subsampling.
But if chroma subsampling was no longer enforced TV stations and future disk formats using HEVC wouldn't be using it at all.

>>85849104
It means they wouldn't give a rat ass about freedom/openness just in care about what works now and what is popular.

>>85849058
Infected Pathogen Virus from hadena uses a mac.

We must perform the Daiz call.
Daiz Daiz I summon you with the power of magic. Please educate us.

>>85849173
>What the fuck are macs good for then?
Music editing and encoding.

Better video editing straight-out-of-the-box.

Being "cool".

>>85849173
Going to Starbucks apparently.

>>85849173
Getting the girlies all wet.

>>85849226
Wow, you're slow.

>>85849226
>completely ignoring the thread before posting

>>85849254
With the latest maps, they're not even good enough to take you to starbucks.

>>85849182
You don't need 4:2:2 and 4:4:4 that much if everything is progressive in future.

>>85849173
Google uses macs to encode apparently. All the presenters seem to have them.

>>85849173
They are good for professional editing, which has different needs from fansubbing.
That said, all of the utilities that matter are developed on *nix and so are available except avisynthavxsynth doesn't count.

>>85849173
>impying hollywood people who buy Mac to edit videos care about anime

>>85849268
>>85849274
I just wanted to perform the Daiz call. He shows up in threads so fast now that I cannot summon him anymore.

>>85849173
Most codec/video editting tools are written for nix
Mac is essentailyl nix with a pretty skin. so yeah, they work just fine.

>>85849317
Repeated summonings have given him enough power to remain in earth realm indefinitely.
Summoning him is no longer necessary.

>>85849294
But BDs are progressive right now and there's still a significant benefit.

Vectorised Streaming Video will be much better than either VP9 or HEVC

>>85848967
Because it's legacy.

Fuck Daiz.

>>85849169
Why not future-proof and go straight to h266?

>>85849169
suck a dick

>>85849450
There are many interlaced BDs, though. They would probably use 4:2:2 for production.

>>85850204
The BD specification enforces 4:2:0.

I don't really know much about encoding but isn't there a format that would be better suited for cartoons specifically, like how .jpg and .png are better at different things? Did no one ever bothered making one or is there no need?

>>85850379
The format is a set of rules that defines how a bitstream may be constructed so that a decoder always knows how to decode it. It's the encoder that works out exactly what needs to go into the bitstream in order to produce the desired result when decoded. x264 performs very well on all sorts of source material depending on what settings you use.

>>85850379
Animated content is not represented well by the common encoding techniques. We have been able to assuage this in the past generation of codecs with extra filtering within the codec.
I don't know anything better to tell you, almost every lossy visual compression method past, present, or upcoming relies on exploiting properties of the source material that are the opposite of anime.
It's "good enough" as is and cartoons are almost surely not a priority for the people who draw up these things and so that is just how it is.

It's more or less bad for the same reason JPEG is, even though motion adds a different dimension to consider, the reasons are the same. Much like in 2D where flat areas are easy to compress, the low motion content of most anime is helpful, but it's offset by the fact that when there is motion it is more abrupt and with a sharper difference. As for the problem in space, it all comes down to sharp lines.

H264 10bit is the top limit for Bluray anime
Even if you use HEVC ot VP9 to a Bluray source it won't be better. It will always depend of source quality.

>>85851405
What you said has no bearing on quality. HEVC/VP9 retain more "quality" than H264 for any given bitrate, which allows encoders to produce smaller releases virtually indistinguishable from the visual fidelity we have become accustomed to.

>>85848835
>5) Whether a format is "free" or not has no relevance to fansubs since they're illegal to begin with, so generally speaking what's best is what matters the most.

Actually, it's legal to implement a patented technology and provide it for free. You only have to pay if you want to sell your implementation of the patented technology. That's why free-software (as in freedom, and monetary price) decoder libraries like FFmpeg have no problem at all providing decoders for H.264 or whatever proprietary formats, and again free-software media players like MPlayer can incorporate those decoders, and free-software operating systems can put these media players in their software repositories from where you can install the media player with pretty much literally a single mouse click, or a single shell command.

That's why I love freedom software not only for philosophical reasons, but also practical ones.

However, as soon as I want to make business as a software engineer, due to living necessities, the patent trolls start to bite.
Therefore, Daala master-race reporting in.
http://xiph.org/daala/

>>85849249

I'd say OS X has superior quality to MS Windows, since Apple really knows well how to rip off of all the best free software projects.

Still, over-priced piece of crap when you can just use Debian for no cost at all and only some very basic maintainance effort.

>>85848967
I want to know this as well.
According to doom9 there's no reason to keep it at all.
"Originally Posted by Dark Shikari View Post
4:4:4 is more efficient than 4:2:0, in that lowering chroma resolution is a very inefficient way of saving bits on chroma. The main gain of 4:2:0 is improved performance, lower memory bandwidth requirements, and so on -- in practical situations, except at very low rates, it should be better to encode chroma with the same number of bits, but with a higher quantizer."

>>85849249
>encoding
no. That has been false since the 80's when Windows used FAT32 instead of NTFS and was limited to 4gb files.

File: 1368973395860.png-(7 KB, 73x73, Dctjpeg-2.png)

7 KB PNG

>>85851208
> As for the problem in space, it all comes down to sharp lines.
Here is the reason why. This picture is for JPEG and MPEG1-4p2, but it's roughly the same for H.264 (more sizes, a faster approximation.)

Every block you see in a picture or video is composed entirely of a combination of these 64 shapes. They are different frequencies of the cosine function, which is smooth, as is most real life imagery, so it turns out that in order to recreate real life imagery you can get by pretty well with only a few of them. With anime, which aside from painted backgrounds is generally large swaths of color punctuated by abrupt, sharp, angular lines or changes in color, it takes a lot of these to faithfully reproduce because you are essentially asking a continuous function to imitate a discontinuous function. You can't get rid of as much without looking like shit, so you can't compress as well.

> my face when that anon probably left

When people talk about DCT coefficients, they are talking about the numbers that say how much to multiply in of each of these bases. Those numbers are what are stored in 10 bits in hi10p instead of 8, and they're what get approximated by quantization. This is basically the key to lossy perceptual compression.

>>85852233
I'm going to keep that as copy pasta because that explained it very well to me.

File: 1368974352997.jpg-(43 KB, 581x600, 1338732507396.jpg)

43 KB JPG

>>85852642

>he has not visited a basic course about multimedia technology in his university

>>85852233
I'm still here, thanks for the explanation, I actually study computer science, but never went in-depth when it comes to this stuff.

>>85852870
>Implying they teach stuff like this in medical uni.

>>85852942
I was CS as well, would have done EE if it was just DSP and not all that other bullshit.

>>85852642
transform coding is not intuitive but it sure is also not explained very well 9 times out of 9. once you can visualize what the DCT actually is you are most of the way there.

This fucking shit doesn't matter at all when the sub groups can't encode for shit.

File: 1368974846593.jpg-(13 KB, 282x360, 1294740459080.jpg)

13 KB JPG

Why not encode in Gentoo?

>>85853229
gentoo is shit for edgy kids

>>85852233

>>85847906
That explains what is going on in each individual block in this image here.

>>85848628
He is responsible for ruining anime and the death of millions.

>>85853519
Yep, that's a perfect demonstration.

File: 1368975512998.jpg-(192 KB, 706x720, 1354672723584.jpg)

192 KB JPG

>>85853229
>Gentoo
>Not Arch or Kali
Get rekt, scrub.

>>85853709
>arch
>the distro for edgy kids too dumb to compile gentoo

>>85853229

No Avisynth.

>>85853943
there is, but it has no plugins

>>85853709
>>85853759

Back to the shit-hole called /g/ with all of you.

OpenBSD master-race reporting in.

In all honesty though, just fucking use Debian.

>>85854059
Why won't plugins work?

Can't you just supply them with the appropriate environment using WINE?

Come to think of it, why can't 64-bit avisynth just twunk between 64 and 32? Isn't complete isolation between components save for a single well-defined interface the whole bloody point of the pipeline pattern?

>>85855123
> Can't you just supply them with the appropriate environment using WINE?
The only thing like that I know of is mplayer's dll loader and that is a giant mess. It would be convenient though.
Also, I wouldn't expect the devs to lift a finger. I'm grateful they did the work to port it, but they've been seriously useless ever since.

File: 1368978014713.jpg-(4 KB, 93x134, 1368637964854.jpg)

4 KB JPG

DAIZ

File: 1368979550859.png-(151 KB, 411x327, churuya.png)

151 KB PNG

d-does anyone else want to talk about tc before this thread dies

>>85851587
>Actually, it's legal to implement a patented technology and provide it for free.

No it is not. Source code might be protected by free speech, but binaries aren't. FFmpeg (and the x264 devs) don't distribute binaries. Also, it makes no sense to sue people who have no money, and widespread use of the format benefits them.

>>85851719
>improved performance
This is very important. 4:4:4 is twice the data as 4:2:0. In general it's probably not worth it.

File: 1368980522841.gif-(20 KB, 199x149, 1334759566970.gif)

20 KB GIF

>People say VP9 is a botnet
>It's actually approved by the FSF
>People defend H.265
>It's actually a botnet and has hidden royalties

Well done, Daiz minions.

>>85857302
it's twice as much data when uncompressed, but this is lossy compression. you can just shave off more bits in the quantization stage instead.

>>85857302
There's not much 4:4:4 video anyways. RGB video game caps are only practical use I can think of.

File: 1368980762940.jpg-(71 KB, 640x480, 1293591410286.jpg)

71 KB JPG

>>85857554
Much like the rest of the FSF's approvals, it's inferior to the competition.

>>85847799
the D-Wave system is not a general purpose quantum computer. It's a quantum annealing device that can only attack a certain kind of NP-hard problems (note: that's not NP-complete). It's also not using full coherence. The whole system is only in a partially coherent state, which is enough for annealing, but not for many other quantum algorithm (e.g. Shor's).

File: 1368980819597.jpg-(34 KB, 640x480, (B-A)Great_Teacher_Onizuk(...).jpg)

34 KB JPG

Hardcore anime talk in this thread. Right now.

>>85857554
It's not like anyone here pays for their h.264 implementations. And there are no good sofware encoders/decoders for h.265 available yet.

>>85857209
depends on jurisdiction really. you can usually claim for-research exceptions or whatever.

Is there anywhere I can get a sample anime h265 encode? Yes, I know good encoders/decoders don't exist yet. I don't care about that.

>>85858074
Ask Daiz to encode a small scene maybe? Apparently the only encoder available for h265 is a pain in the ass and super slow.

File: 1368981513298.jpg-(53 KB, 1280x720, [Happy! Happy! Subs] Devi(...).jpg)

53 KB JPG

I don't know much about any of this but I like a good streaming site to watch anime myself.

http://www.watchanimefree.com/anime/cardcaptorsakura/56.php

>>85858236
anon why do you hate us

why do you want to be so mean

>>85858291
The choice to be mean is within you. You could choose to ignore and report or you could reply with hatred. But if you reply to every retard post then you bring about the end yourself.

What is your choice anon?

>>85858356
Report 'em all. Let moot sort 'em out.

>HEVC 8k encoder

Stop. At a certain point you can't even tell the difference anymore unless your screen was just massive and you were viewing within a certain distance. Better compression, sure, but we don't need shit like SHV.

>>85847445
it's called lossless quality lol

>>85858903
They always want to sell new hardware to us.

>>85858356
B-b-but it's not even a real site

He's just trying to ruse people

Why would he hate his fellow anon so

We have this thread once every other hour now it seems. Too bad its not remotely interesting (or even relevant for years to come according to Our Lord Daiz) or about anime/manga.

>>85859061
Shouldn't you be whining in the daily Japanese thread?

>>85857585
And it goes without saying that intelligently discarding data saves more space than doing so blindly. If there's large areas of flat colour, the encoder may well decide to throw out even more than half the data.

>not already using x265

https://code.google.com/p/x265/downloads/list

Anyway, I found h265 samples of Big Buck Bunny. I wasn't impressed at the quality and holy shit the decoders for this are slow right now.

>>85857209
>No it is not. Source code might be protected by free speech, but binaries aren't.

You're telling me that the dozens if not hundreds of existing GNU/Linux distributions, whose developers are usually well-known, are all illegal?

Source or binary is a trivial difference anyway, since compilation is a trivial process.

>>85857585
>it's twice as much data when uncompressed
Yes, and the encoding/decoding speed is affected accordingly. IIRC when I tested h.264 4:4:4, it was nearly twice as slow both encoding and decoding.

>>85859442
Oh wow, do you really think so?

If you mark that checkbox when installing ubanto, Canonical actually has to pay license fees.

>x264
>not the superior main concept

Jason please

>>85859591
They have a license that isn't per head so it doesn't really hurt them much.

>>85859591
>If you mark that checkbox when installing ubanto, Canonical actually has to pay license fees.

Anon pls.

I've at least used ArchLinux and OpenBSD personally, and both provide FFmpeg/Libav binaries (that can play H.264), and x264, with a single shell command. And you can be sure their devs don't pay any fees.

>>85859715

Is Canonical selling parts of Ubuntu or what? That would explain if they actually *do* pay fees. Otherwise, no, everyone can distribute FFmpeg/Libav/x264/etc. binaries as much as they want, without paying anything, as long as they're not selling it.

>>85859801
> everyone can distribute FFmpeg/Libav/x264/etc. binaries as much as they want, without paying anything, as long as they're not selling it.
That's not even remotely true and I wonder where on earth you got this idea.

These arguments have been repeated year after year. Remember when AVI was king and Xvid appeared? A lot of people kept on saying AVI was superior to Xvid.

Remember when MKV suffixed files appeared? A lot of AVI xvid users kept on saying MKV was not as good and wasteful.

Remember when H.264 8bit appeared? Now, a really huge number of people said h.264 sucked and even preferred the AVI files in comparison. Eventually, h.264 won out.

etcetera.

Since h.265 10-bit seems to be the next major evolutionary step to support hardware decoding in high-resolution tablets and wall-displays, chances are good that it will be part of PC video card hardware decoding too. Certainly, the two major tablet makers had previously indicated they would support h.265 in hardware. So complain all you want, it is coming in hardware.

>>85859955
The whiners have been retarded every time. I remember h264. Someone said "hey check out this h264 encode of the Haruhi OP" and I saw that it was better quality at a smaller size. That's really all that should matter. People are just afraid of change.

>>85859955
>A lot of people kept on saying AVI was superior to Xvid.
What?

>needs 4-5 times the CPU load to decode

Holy shit. Get your Haswells ready.

File: 1368984007713.png-(118 KB, 1307x934, resolution and viewing di(...).png)

118 KB PNG

>>85858903
just depends on the size of your monitor and the viewing distance

File: 1368984050796.jpg-(74 KB, 800x376, Then-Versus-Now.jpg)

74 KB JPG

Aren't some of the more knowledgeable complaints against H.265 more about how encoding could require keys that only AUTHORIZED video makers can have? Thus, the video hardware in tablets or PC cards might only perform their hardware decoding for those videos encoded by licensed keys.

Unlicensed encodes would have to use software encoding and decoding, thus they would be slow or even "laggy" on tablets. Thus, the new h.265 standard would accomplish several things such as making hardware unfriendly to pirates yet being able to claim to be on the high road with an open specification.

File: 1368984105760.jpg-(244 KB, 1366x768, if you actually believe t(...).jpg)

244 KB JPG

>>85859955
>AVI was superior to Xvid.

>>85859955
>A lot of people kept on saying AVI was superior to Xvid.
the fuck am i reading

>>85860092
>People are just afraid of change.
It's understandable though, since people in this care aren't afraid of change per-se, but they're afraid that their toasters won't be able to play back anime any more.

There are still plenty of people who download AVIs, and 480p downscales.

Who gives a fuck about all of these changes? I survived the 10-bit transaction and I will do the same with whatever comes next as long as I am able to watch my chinese cartoons.

>>85860252
yeah, i'm sure companies that make money selling decoder hardware would love to make their decoders not work in 99% of cases

>>85860252
h.265 does not involve any DRM itself. You must be talking about some container format or something.

>>85860191
less than 12% load on my i7-920 (1st gen, nehalem) to decode h.264 10bit 1080p. I don't think h.265 will be an issue. 4k on the other hand will require an upgrade.

File: 1368984457028.jpg-(223 KB, 1024x768, kagamisip.jpg)

223 KB JPG

>>85860252
No, H.265 is just a video coding standard.
There is nothing in MPEG-H that deals with DRM either, so I don't know what the hell you're talking about.

File: 1368984481834.png-(2.47 MB, 1920x1080, [HorribleSubs]_Senyuu_-_0(...).png)

2.47 MB PNG

>>85860252
You really think they'll force licensed keys? You really think people won't get around that shit if they do?

>>85860553
>less than 12% load on my i7-920 (1st gen, nehalem) to decode h.264 10bit 1080p.
hevc decoders will be unoptimized as hell for a while though, so it might be more difficult than you think

Here's some h265 samples for you all to test:

http://www.elecard.com/en/download/videos.html

And of course, you can't play that shit in VLC or mplayyer/mplayer forks, but I'm sure you expected that.

>>85860145
People are afraid of change. When something new comes out, there will be a bunch of scaredy-cats and trollers that attack the new thing. Many years ago when AVI was well-established, and Xvid was the next new thing coming to anime encodes, there was a lot of backlash.

>>85861126
But AVI is a container, not a codec. XviD is a codec.

>>85859911

Could you explain to me then how it's possible that I can install a H.264-capable FFmpeg, with a shell command, from the central repositories of ArchLinux and OpenBSD, whose owners are publicly known?

https://www.archlinux.org/packages/extra/x86_64/ffmpeg/download/

http://ftp.openbsd.org/pub/OpenBSD/5.3/packages/amd64/ffmpeg-20121026p2.tgz

>>85861202
Tell that to the retards. When Daiz put out his 10bit Game of Thrones encodes on TPB, the comments were full of people whining about how avi was a better video type than mkv. Most people have no clue.

>>85861304
>what is make config and make install i don't know what they do

Does LAV support h265 yet or do I need to keep using this special thing?

>>85861369
>make config
Do you even autotools?

>>85861643
The point.

Your head.

>>85861369

They're distributing binaries.
I'm repeating myself here.

Besides, how can you expect an average person to know about make(1)? I guess you might've thought that I'm being edgy or something by mentioning Arch and OpenBSD. I'm developing software as my job though.
Also this >>85861643. Except that it's not really related to autotools. The "./configure && make" duo is older than autotools and they're just generate the configure and Makefile.in files such that they can work on any host without them needing anything else than the standard Bourne shell and make(1) tool which every Unix has anyway. (That's in contrast to shit like Waf, CMake, Scons, etc., which need to be installed on the target host, so they're not really alternatives to autotools.)

>>85861304
Not hosted in U.S.? Just don't give a fuck?

Answer me a question: what do you think was stopping Mozilla from shipping an H.264 decoder all this time?

>>85861848
>what do you think was stopping Mozilla from shipping an H.264 decoder all this time?

Autism.

Most of the distros can generally afford the one time fee for a royalty free x264 license.

http://x264licensing.com/

>>85861947
No, decoder licensing fees.

>>85861994
That's the license for those who want to sell proprietary closed source program with x264.

>>85861994
That's to use x264 in a non-GPL-licensed product and has nothing to do with the matter at hand.

>>85861994
>GPL
>pay

No. Just tweak it a bit inconsequentially, call it a fork and put it up for free. Let them try to sue. It should be a great show.

>>85862092
Patent licensing fees, rather.

>>85861848

$ geoiplookup archlinux.org
GeoIP Country Edition: US, United States

$ geoiplookup openbsd.org
GeoIP Country Edition: CA, Canada

From what I know, Mozilla refused to ship H.264 as a form of protest. Let's see..

http://shaver.off.net/diary/2010/01/23/html5-video-and-codecs/

TL;DR for me, but it seems like they do need to pay for something, for some reason. Might be because in some form they *are* making money out of Firefox. But I'm not sure.

In any case distributing FFmpeg for free is not illegal, or there's some weird reason I can't think of that makes it legal for ArchLinux, OpenBSD, etc.

>>85862152
Some companies have attempted to do that in the past (with Xvid for example). It didn't end up well.

>>85849058
But they use Windows, which is even less free.

>>85849296
Google was fed up with Windows' security, so they got rid of all Windows computers. Now Google staff has a choice between OS X and Linux distros.

>>85861994

>Does the x264 license include AVC patent royalties?

>No, it does not. You will need to get a separate patent license from MPEGLA, see: http://www.mpegla.com for more info .

http://x264licensing.com/faq

>>85860210
>feet
Why do people used this cursed unit?

>>85862224
You clearly don't know jack shit about h.264 licensing, and you keep sprouting that bullshit because there's some package on some distros with an h.264 decoder.

Please read http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsSummary.pdf

>>85862443
>do people used

Why can't people understand tenses, either?

>>85862224
(same anon here)

Quote from linked post:
>For Mozilla, H.264 is not currently a suitable technology choice. In many countries, it is a patented technology, meaning that it is illegal to use without paying license fees to the MPEG-LA. Without such a license, it is not legal to use or distribute software that produces or consumes H.264-encoded content. Indeed, even distributing H.264 content over the internet or broadcasting it over the airwaves requires the consent of the MPEG-LA, and the current fee exemption for free-to-the-viewer internet delivery is only in effect until the end of 2010.

I might've been wrong then in some way, but it still seems implausible that what Arch and OpenBSD are doing is flat out illegal.

An anon who knows more should explain.

>>85862464

You obviously don't know any more either, sadly. Unless you're saying that ArchLinux and OpenBSD (and I'm pretty sure also e.g. Debian, Fedora, FreeBSD, etc.) developers are simply all doing something illegal and getting away with it because magic.

>>85862679
VLC decrypts shit without a license and nobody has cracked down on them. You really think they'll go after OpenBSD which only a few autists even know exists? It's not worth the time and money and bad will from the people who are autistic enough to know what OpenBSD is.

>>85861304
Could you explain to me then how it's possible that I can install Windows 8 from the central repositories of Microsoft whose owners are publicly known?

http://msft.digitalrivercontent.net/win/X17-59183.iso

Possible to download != not infringing copyrights, patents or trademarks.

>>85862679
You better tell Google not to keep spending hundreds of millions in WebM since h.264 is so obviously free.

>>85862949
Microsoft actually pays a lot of money due to h.264 licensing, even though they're in the patent pool.

Patent costs are also the reason DVD playback was removed from Windows 8.

>>85862679
Why don't you just read the AVC licensing agreement? Specifically section a.
Please note that "sold" in these terms means distributed.

>>85863191
Actually, Debian does seem to be taking a "Go ahead and sue us" approach.

http://www.debian.org/legal/patent

>>85862831

OpenBSD is known quite well under more professional circles. It's a project with about 20 years of history, and that after branching off of NetBSD, which branched off of some even older BSD stuff, which is where a shit-load of generic operating-system technology was invented in first place. Microsoft used to just use BSD's TCP/IP stack for some time.

Also
>Slackware
>Debian
>FreeBSD
>Arch
>Fedora
>openSUSE
>CentOS
>...

>>85862949

This post makes zero sense, or is very confused. I guess >>85863034 answered it well.

>>85862970

Google is a business that intends to make money from their products. Did you even read my initial post that started this all?

>Actually, it's legal to implement a patented technology and provide it for free. You only have to pay if you want to sell your implementation of the patented technology. That's why free-software (as in freedom, and monetary price) decoder libraries like FFmpeg have no problem at all providing decoders for H.264 or whatever proprietary formats, and again free-software media players like MPlayer can incorporate those decoders, and free-software operating systems can put these media players in their software repositories from where you can install the media player with pretty much literally a single mouse click, or a single shell command.

It's ambiguous what "sell" means here, so it wasn't all as simple as I thought. Those distros still *do* distribute binaries of FFmpeg/x264 freely though.

>>85863191

Yeah, I don't know why all the distros mentioned above are allowed to do that. Do you? No sarcasm/rhetoric here, I really wonder.

>>85863485
Yes, I get what OpenBSD is. Let me put this another way for you:

OS X is what, 8-10% of the non-moible market? How many of those users know OS X is BSD? How many of them have even heard of BSD? Lots of people know what VLC is and they don't get in trouble for violating licenses. Why would something as numerically irrelevant as OpenBSD get in trouble? Both could, but they won't.

>>85863485
>It's ambiguous what "sell" means here
No it isn't.
http://www.zdnet.com/blog/bott/a-closer-look-at-the-costs-and-fine-print-of-h-264-licenses_p2/2884
> Although the license agreement uses the word sold, the royalties have to be paid even on software that is given away.

It has always been this way, back to the day of xvid.org's "educational loophole" for source hosting and Koepi hosting binaries on his server in germany or whereever that was.

>>85863485
They're not allowed. They are just not sued because it wouldn't be profitable to do so.

Ubuntu is profitable, and pays money to play back MP3s.

>>85863719
ding ding ding

maybe he'll actually comprehend this some day

>>85863485
>Yeah, I don't know why all the distros mentioned above are allowed to do that. Do you? No sarcasm/rhetoric here, I really wonder.
MPEG-LA doesn't care about it, they don't make money from it anyway. But try to make a commercial video player using libavcodec, and they will ring at your door for you to pay the fees per copy and whatnot.

>>85863191

>For (a) (2) branded encoder and decoder products sold on an OEM basis for incorporation into personal computers as part of a personal computer operating system, a Legal Entity may pay for its customers as follows (beginning January 1, 2005):
>0 - 100,000 units/year = no royalty (available to one Legal Entity in an affiliated group) ; US $0.20 per unit after first 100,000 units/year; above 5 million units/year, royalty = US $0.10 per unit.
>The maximum annual royalty (“cap”) for an Enterprise (commonly controlled Legal Entities) is $3.5 million per year in 2005-2006, $4.25 million per year in 2007-08 and $5 million per year in 2009-10 , and $6.5 million per year in 2011-15.

http://www.mpegla.com/main/programs/AVC/Pages/Intro.aspx

>>85854979
I want to use Debian, but then I can't play my chink picture novels.

>>85863719
>mp3
>patents expired everywhere relevant except US

For fuck's sake.

>>85863946
VNs run fine in a VM.

>>85864002
So I guess they can just not sell to the US, then? Sounds like a plan.

>>85864002
Fraunhofer deserves a tip of the hat for their legendary perseverance.

>>85864029
VMWare does not run fine on Debian, and no other virtualisation platform will run Windows.

>>85864152
Now you're just trolling.

>>85863663
>S X is what, 8-10% of the non-moible market?
7% if Net Applications is to be believed.

>>85864152
Huh, VMWare runs perfectly fine. You can also use kvm or Virtualbox.

File: 1368988090437.png-(1.11 MB, 1917x1080, h265test.png)

1.11 MB PNG

>Decide to check out this 'h265' fad
>download reference encoder
>convert [UTW-Vivid]_Suisei_no_Gargantia_-_02_[h264-720p][739A99E9].mkv to raw YUV file using ffmpeg
>TAppEncoder.exe -c test.cfg -i test.yuv
>encoding at q25
>9 days later....
>video stream: 65,626,112 bytes
>mux to mp4 with original audio
>playback with gpac in realtime - looks fucking awesome

h264 mp4: 547,739,225 bytes
h265 mp4: 116,505,990 bytes

Subgroups should stop being fags and start using h265

>>85863663
>>85863719
>>85863760

So MPEG-LA doesn't care about pretty much literally dozens of distros that freely provide FFmpeg/x264 binaries illegally?

It's a weird world.

>>85863789

2legal5me
Is it the "OEM" part that makes it work for distros, perhaps? Since they don't develop equipment?

>>85863946

Tried WINE?

>>85864183

Don't under-estimate the ignorance and/or misinformation of people.

>Daiz invented 10bits for "the hipster club /a/"
>EZTV use 10bits for American Shit

>Daiz mad

>Daiz use 265 for anime

>EZTV use 265 for american shit

>Daiz mad again

>>85864232
>>9 days later....

Anon pls.

>>85864232
How does osmo4 decode it? I thought ffh265 wasn't even close to finished.

>>85864232
>Subgroups should stop being fags and start using h265
>9 days later
Yeah, no.

>>85864234
WINE doesn't work for my untranslated VNs unfortunately.

>>85864232
>convert H264-compressed mkv to raw
Too obvious.

>>85864234
>doesn't care

You got it. It's just not worth the effort. Happens all the time. Bootleg merchandise? They could crack down, but it's not worth the effort. Your local daycare has copyrighted characters on the wall without permission? The lawyers could crack down, but too much hassle. Plenty of things like this happen and it's all illegal but also too much effort to do anything about.

>>85864319
I've gotten Little Busters to work with Wine.

>>85864320

The reference encoder only supports raw yuv input

>>85864369
>little busters
>wine
>not rlvm

>>85864234
https://mailman.archlinux.org/pipermail/arch-general/2011-May/019914.html

>> What is Arch's official policies when it comes to patents?
>> It could have some widespread implications for the distro.
>>
>> Or the distro could purchase or otherwise aquire licenses to all claimed
>> patents... ha... ha...
>
> Licenses and patents are different things. Some stuff cannot legally
> distributed and we respect that. This is usually proprietary/non-free
> software or packages like the Microsoft fonts. (Wasn't there also some
> mplayer codec pack that included some Windows dlls?)
>
> On the other hand there are software patents valid in some countries
> which apply also to a completely free implementation. This means there
> are a bunch of packages which you are not allowed to use in the US for
> example even though they are licensed under e.g. the GPL.

There you have it.