"Vreemde moderatie" omdat je ontzettend koppig bent

Jaja, very early software maar het is een teken aan de wand. H.265 gaat zeker niet sneller worden dan H.264. Maar goed, dat hoeft ook niet.
Hier kan ik enkel op antwoorden: jij bent ofwel zo jong, ofwel zo kort van geheugen, ofwel zo koppig dat je niet weet/wilt inzien dat dit niet anders is dan x264. Lees er eens oude benchmarks op na:
http://www.hardwarecanuck...-processor-review-14.html (eerste van voor 2010 die ik kon vinden).
Daar kan je zien dat de allernieuwste CPUs (de Nehalem serie) slechts 27 fps haalden, terwijl gewone consumenten CPUs zoals de E8400 amper 9 fps haalden. En dat voor een 720p video. En, dan moet je erbij bedenken dat H.264 toen al 5 jaar gefinaliseerd was. HEVC is er nu nog maar 3 jaar. H264 was dus ook enorm traag in het begin, dat is nu eenmaal zo voor
nieuwe betere codecs. MPEG2 is not altijd sneller dan H264, maar gebruik jij het nog? natuurlijk niet, want eht is kut, en H264 is snel genoeg. Zo gaat het net zo met H265 binnen een paar jaar: het is gewoonweg beter, en zodra het snel genoeg is, is er geen reden meer om voor H264 te kiezen.
Het doel van een codec?
Snel en goed coderen, waarbij voor mij iig de bestandsgrootte niet op de eerste plaats staat.
Het doel van een codec is vooreerst compressie. En daarin is H265 beter dan H264. Daarnaast is encoding time niet erg belagrijk: belangrijker is decoding time. Een geëncodeerde video wordt namelijk veel, veel vaker afgespeeld dan hij wordt geëncodeerd (duhu). Daarom is voor elke codec de decode veel sneller dan de encode. Encoding time staat pas op de derde plaats: als een encoder drie dagen zou moeten stampen om 1 film te encoderen aan optimale efficiëntie, dan doet Sony dat gewoon: op die manier kunnen ze namelijk de allerbest mogelijke kwaliteit op hun bluray proppen.
Gebruikers commentaar:
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. BRON
Het lijkt dus zeker niet allemaal rozegeur en maneschijn
Sorry hoor, maar jouw "bron" is de comment secite van een website? Die notabene nog eens ingaat tegen een uitgebreide studie van de BBC. Maar goed, mijn bedenkingen bij zijn 'punten'.
1) geen minpunt, zoals ettelijke keren herhaalt. Grootste reden btw: X264 is intussen volledig geoptimaliseerd, en heeft op bijna elk platform hardware versnelling. H265 nog niet. Dit mindere issue wordt dus toch sowieso opgelost.
2) nee, H.265 blurt niet, of toch niet zoals hier wordt beweerd. In de encode en decode zit wel een inloop deblocking filter ingebouwd: bij encoding wordt er gezocht naar waar er blocking artifacts optreden, en wanneer hij edges vindt die niet in het bronmateriaal zitten, zoekt hij naar blur-parameters die objectief het beste resultaat (dichtste bij bronmateriaal) geven. De decoder past deze blurring toe. Dit is eigenlijk post-processing op amphetamines: vele H264 decoders passen namelijk al deblocking toe door edges te blurren, echter is dit process hit-and-miss: de decoder weet namelijk niet of een edge een artifact is, of deel van het bron materiaal. Bij H.265 geeft de encoder mee waar de blur nuttig is en waar niet. Dit principe wordt voor verschillende filtertechnieken toegepast. Dit is een enorme vooruitgang, en zal de nood voor extra post-processing in decoders enorm verlagen.
Bij de encoder kan je dit overigens uitzetten, maar dat is dom: de encoder heeft namelijk opgezocht waar die blur objectief gezien de kwaliteit verhoogt en waar niet, enkel waar het objectief beter is, is er een blur. De deblocking filter uitzetten geeft dus slechter beeldkkwaliteit, zowel subejctief als objectief. De gebruiker die jij quote heeft dus zijn huiswerk niet gemaakt: hij zag gewoon dat blocking artefacts gemaskeerd werden en nam domweg aan dat dit niet op een gepaste manier gebeurt (blind blurren is namelijk altijd ongewenst).
3) sleutelwoord lijkt mij 'seems to me': ik betwijfel ten zeerste of dit waar is, in de spec is denoise namelijk helemaal niet opgenomen.