Video și codecuri
Aproape orice lucru confuz despre fișierele video provine dintr-o singură distincție - între cutie și ceea ce e în ea. Acestea sunt cuvintele pentru ambele și pentru operațiunile care mută lucrurile între ele.
-
Container
ambalaj, format -
Structura de fișier care ține împreună pistele video, audio și de subtitrare și descrie unde se află fiecare. MP4, MKV, AVI și WebM sunt containere. Un container nu comprimă nimic.
Gândește-te la el ca la o cutie de arhivare cu o etichetă de conținut. Cutia spune: aici e o pistă video, codificată așa; acolo două piste audio, în aceste limbi; subtitrări la acest decalaj. Nu are nicio părere despre cum a fost comprimat vreunul dintre ele.
De asta același videoclip poate exista într-un MP4 și un MKV cu calitate a imaginii identică și dimensiune de fișier identică, și de asta unul dintre cele două se deschide pe un iPhone, iar celălalt nu. Diferența e cutia, nu conținutul.
-
Codec
codificator-decodor -
Metoda folosită pentru a comprima un flux video sau audio și pentru a-l decomprima din nou la redare. H.264, HEVC, AV1, AAC și MP3 sunt codecuri. Un codec nu e un format de fișier.
Numele e o contracție de la codificator-decodor (coder-decoder). Codificarea aruncă detalii într-un mod calculat să fie greu de observat, iar decodificarea reconstruiește o aproximare a originalului din ce a fost păstrat. Cu cât codecul e mai bun, cu atât pierderea e mai puțin vizibilă la o dimensiune dată.
Un dispozitiv redă un fișier când poate citi containerul *și* decoda fiecare codec din interior. Ambele jumătăți sunt necesare, iar când un fișier se deschide dar nu arată nimic, a doua jumătate e cea care a eșuat.
Vezi și: ContainerDecodare hardware
-
H.264
AVC, MPEG-4 partea 10 -
Codecul video pe care totul îl poate decoda. Publicat în 2003, încă cea mai sigură alegere pentru compatibilitate și accelerat hardware pe fiecare telefon, computer și televizor produs în ultimii cincisprezece ani.
H.264 a câștigat atât de temeinic încât „se redă asta peste tot” și „e H.264” sunt aproape aceeași întrebare. Nu e cel mai eficient codec disponibil — HEVC și AV1 fac mai mult cu mai puțini biți — dar nimic altceva nu se apropie ca amploare a suportului.
Are profiluri, iar unul dintre ele provoacă probleme pe dispozitivele Apple: High 10, adesea scris Hi10P, codifică zece biți pe canal de culoare în loc de opt. Decodoarele hardware sunt doar pe 8 biți, așa că un fișier Hi10P redă sunetul fără imagine pe un dispozitiv fără cale software de rezervă.
Vezi și: HEVCDecodare hardware10 biți
-
HEVC
H.265 -
Succesorul lui H.264, la aproximativ jumătate din dimensiune pentru aceeași calitate. Fiecare dispozitiv Apple din 2015 încoace îl decodează în hardware, și e ceea ce înregistrează un iPhone.
HEVC e ce a făcut 4K practic pe telefoane: aceeași imagine la aproximativ jumătate din rata de biți. Apple l-a adoptat devreme și temeinic, așa că pe hardware Apple e o alegere la fel de sigură ca H.264.
În altă parte e mai complicat. Licențierea de brevete din jurul HEVC a fost destul de contestată încât browserele web au fost lente să-l accepte, exact golul pe care AV1 a fost creat să-l umple.
Vezi și: H.264AV1Rata de biți
-
AV1
-
Un codec fără taxe de licență publicat în 2018, mai eficient decât HEVC și, spre deosebire de acesta, lipsit de dispute de licențiere. Decodarea hardware a ajuns abia pe dispozitivele Apple începând cu iPhone 15 Pro.
AV1 există pentru că licențierea HEVC a făcut ca cele mai mari companii de streaming și browsere web să vrea o alternativă pe care s-o livreze fără să plătească pe nimeni. Acum e formatul în care e livrată o mare parte din video-ul web.
Costul e decodarea. Fără suport hardware, AV1 e decodat în software, ceea ce e posibil dar consumă vizibil bateria și poate sacada la rezoluții mari. Pe dispozitivele mai vechi, o versiune H.264 a aceluiași videoclip e fișierul mai bun.
Vezi și: HEVCDecodare hardware
-
Rata de biți
-
Câte date folosește o secundă de video sau audio, de obicei în megabiți pe secundă. E principalul lucru care decide atât dimensiunea fișierului, cât și cât de mult trebuie să lucreze un dispozitiv.
Rezoluția atrage atenția, dar rata de biți decide cum arată de fapt un fișier. Un fișier 4K la o rată de biți mică arată mai rău decât unul 1080p la una mare, pentru că encoderul a trebuit să arunce mai mult ca să atingă ținta.
E și motivul obișnuit al unui fișier care sacadează. Când un videoclip se redă pe un computer și sacadează pe un telefon, nimic nu e în neregulă cu fișierul: pur și simplu cere mai multă muncă de decodare pe secundă decât vrea acel cip să facă.
Vezi și: CodecRata de biți adaptivă
-
Remux
reîmpachetare -
Mutarea fluxurilor video și audio existente dintr-un container în altul fără recodare. Fără pierderi și suficient de rapid încât e limitat de viteza discului, nu de procesor.
Un remux copiază fluxurile; nu atinge niciun cadru. Un MKV de o oră cu H.264 și AAC devine un MP4 în câteva secunde, identic bit cu bit în imagine și sunet.
Funcționează doar când containerul țintă acceptă ce ține sursa — MP4 acceptă H.264 și AAC, și nu acceptă VP9 sau Vorbis. Când oamenii spun că o conversie a fost „instantanee”, au remuxat. Când a durat o oră, ceva a fost recodat.
Vezi și: TranscodareContainer
-
Transcodare
recodare, conversie -
Decodarea unui flux și codificarea lui din nou, de obicei într-un codec diferit sau la o rată de biți mai mică. Lentă și cu pierderi de fiecare dată - calitatea nu revine niciodată.
Transcodarea e ce vor oamenii să spună prin „conversia unui videoclip”, și e o operațiune cu adevărat costisitoare: fiecare cadru e decodat, procesat și comprimat din nou. E răspunsul corect atunci când codecul e cu adevărat neacceptat, sau când un fișier trebuie făcut mai mic.
E răspunsul greșit la „telefonul meu nu deschide asta”, când un remux ar fi fost suficient, și e un răspuns slab pentru un fișier a cărui singură problemă e o pistă audio DTS — înlocuirea doar a acelei piste lasă imaginea neatinsă.
Vezi și: RemuxRata de biți
-
Decodare hardware
-
Decodarea video pe un cip dedicat, nu pe procesorul principal. Mult mai rapidă, mult mai rece și mult mai blândă cu bateria - dar se ocupă doar de codecurile pentru care a fost construit.
Fiecare telefon conține un decodor video cu funcție fixă care face H.264 și HEVC extrem de eficient. Orice nu e acceptat cade pe software, ceea ce funcționează dar costă baterie și căldură, și poate să nu țină pasul la rezoluții mari.
De asta suportul de format pe un telefon nu e un simplu da sau nu. Un dispozitiv poate reda un codec perfect la 1080p în software și poate eșua la același codec la 4K, și niciun rezultat nu spune ceva despre fișierul fiind greșit.
-
10 biți
Hi10P, High 10 -
Video care stochează zece biți pe canal de culoare în loc de opt, pentru gradiente mai fine. În HEVC e normal și bine acceptat; în H.264 e cea mai comună cauză a unui fișier care are sunet, dar nu are imagine pe un iPhone.
Mai mulți biți pe canal înseamnă pași mai fini între nuanțe, ceea ce elimină benzile pe care le vezi în cerurile întunecate și fadeurile lente. Pentru HDR e o cerință, nu o rafinare.
Problema e specific H.264. H.264 pe 10 biți e în afara a ce implementează decodoarele hardware, iar playerul de sistem al Apple n-are nicio cale software pentru el, așa că audio se redă și imaginea nu ajunge niciodată. Lansările de anime îl folosesc intens, motiv pentru care asta apare mult mai des decât ar sugera cota generală a formatului.
Vezi și: H.264Decodare hardware
-
Cadru cheie
I-cadru -
Un cadru stocat în întregime, nu ca diferență față de cadrul dinainte. Căutarea poate ajunge doar la unul, motiv pentru care un videoclip sare uneori într-un moment ușor diferit de cel pe care l-ai cerut.
Compresia video funcționează descriind majoritatea cadrelor ca schimbări față de vecinii lor. Doar cadrele cheie stau singure, și de obicei sosesc la fiecare două până la zece secunde.
Când tragi o bară de derulare, un player găsește cel mai apropiat cadru cheie și pornește de acolo. Cadre cheie distanțate mai mult fac un fișier mai mic și căutarea mai grosieră; acel compromis se decide la codificare și nu poate fi schimbat ulterior fără recodare.
Vezi și: TranscodareSegment