mboost-dp1
Ja, så godt artiklen igår da vi diskuterede Google's støtte til Theora, og hvis de frigiver VP8 kan det blive det vigtigste element i valget af et fælles codec til HTML5 video.
Jeg håber inderligt at det er sådan det bliver, flere standarder på nettet tak, og de må gerne være frie :D
Jeg håber inderligt at det er sådan det bliver, flere standarder på nettet tak, og de må gerne være frie :D
#2 Tror mere det omhandler at folk er paranoide omkring Googles ophobning af data... Hvilket jeg ikke rigtigt forstår.
Men det her er et kæmpe plus, og jeg håber bare at de andre store spillere (Apple, MS, Opera) også hurtigt kommer ind og understøtter... Dog har jeg ikke de ville forventninger.. :/
Men det her er et kæmpe plus, og jeg håber bare at de andre store spillere (Apple, MS, Opera) også hurtigt kommer ind og understøtter... Dog har jeg ikke de ville forventninger.. :/
#3 Forstår godt paranoiaen, jf. de mange data Google besidder. Om Google er god eller ond er selvfølgelig en meningsløs diskussion, men fakta er jo at der kommer nye ledere til, over tid, og hvem ved om nogle af dem får en interesse i at udnytte den potentielle magt der ligger i dataene? Derfor er det da på sin plads i det mindste at være opmærksom på faren herved.
#data
AOL udgav på et tidspunkt anonymiseret data fra søgninger. Der var en journalist der kiggede på de data, og fandt ret hurtigt frem til hvem een af brugerne var + en masse mere eller mindre personlige data. Nogle gange kan data bruges til mere end man umiddelbart tror.
AOL udgav på et tidspunkt anonymiseret data fra søgninger. Der var en journalist der kiggede på de data, og fandt ret hurtigt frem til hvem een af brugerne var + en masse mere eller mindre personlige data. Nogle gange kan data bruges til mere end man umiddelbart tror.
Spørgsmålet er så, hvordan Google i bedste Google stil vil tjene penge på at frigive sådan et codec. Så vidt jeg kan tænke mig til kunne det være noget med at sende data til Google om hvilke film man ser. På den anden side tror jeg ikke det ville være en smart taktik. De kunne også være ude på at få noget Goodwill.
VP8 ville være helt suverænt det bedste valg i Internet videoformat krigen (HAH I SAID IT FIRST), hvis Google frigiver det. Det ville være OS, hurtigst og bedst kompression (plus så får vi ikke problemer med langsomme CPU'er som H.264 giver).
VP8 ville være helt suverænt det bedste valg i Internet videoformat krigen (HAH I SAID IT FIRST), hvis Google frigiver det. Det ville være OS, hurtigst og bedst kompression (plus så får vi ikke problemer med langsomme CPU'er som H.264 giver).
"Med tiltaget vil Google, ifølge kilden, benytte VP8 i HTML 5 i Chrome, men også Mozilla, der er stor modstander af h.264, vil annoncere understøttelse af VP8 til Google I/O."
Er Google stor modstander af h.264, eller det Mozilla der er stor modstander?
Jeg forstår ikke sætningen - der er for mange indskudte sætninger.
Er Google stor modstander af h.264, eller det Mozilla der er stor modstander?
Jeg forstår ikke sætningen - der er for mange indskudte sætninger.
#8
h.264 sænker clock-frekvensen på din cpu permanent. :) jeg forstår ikke hvad du snakker om
Jeg forstår ikke hvad de mener. Er det et rygte eller hvad? Det lyder som om at det er meget klart at de frigiver VP8 i ovenstående citat. Resten siger ret grundigt at det er et rygte. Word...
h.264 sænker clock-frekvensen på din cpu permanent. :) jeg forstår ikke hvad du snakker om
Med tiltaget vil Google, ifølge kilden, benytte VP8 i HTML 5 i Chrome, men også Mozilla, der er stor modstander af h.264, vil annoncere understøttelse af VP8 til Google I/O.
Jeg forstår ikke hvad de mener. Er det et rygte eller hvad? Det lyder som om at det er meget klart at de frigiver VP8 i ovenstående citat. Resten siger ret grundigt at det er et rygte. Word...
#11: I sammenligningen af Theora mod H.264 er argumentet altid at H.264 (grundet højere kompression) opnår bedre billedkvalitet per KiB/s. Dette stemmer. Problemet er at højere kompression altid vil betyde større krav til CPU'en for at udpakke dataene. VP8 er, så vidt jeg mindes, ikke nær så komprimeret og samtidig nemmere end Theora (som er deres store kritik punkt) - det er, med andre ord, en mellemting - men den vil så være fri, så den burde vinde.
#11: Det er et rygte, men det kommer åbenbart fra en ekstrem pålidelig kilde.
#11: Det er et rygte, men det kommer åbenbart fra en ekstrem pålidelig kilde.
#12 vrøvl... H.264 har hardwareunderstøttelse mange steder, inkl. i mange grafikkortløsninger, så der behøver ikke være noget særligt CPU-krav.
Desuden er det ikke korrekt at højere kompression altid betyder større krav til en CPU ved udpakning. I mange tilfælde gør det kun en forskel under pakningen.
VP8 er med garanti væsentlig mere komprimeret (forstået som kvalitet pr. bit) end Theora, som er baseret på VP3. Theora er H.264 klart underlegen. VP8 burde være på linie.
Desuden er det ikke korrekt at højere kompression altid betyder større krav til en CPU ved udpakning. I mange tilfælde gør det kun en forskel under pakningen.
VP8 er med garanti væsentlig mere komprimeret (forstået som kvalitet pr. bit) end Theora, som er baseret på VP3. Theora er H.264 klart underlegen. VP8 burde være på linie.
#13:
Grafikkort. Mmhmm. Sådan et har min EEE PC. Det er ikke særlig godt. Youtube (m. Chrome beta) streamer fint musik men video lagger som intet andet. Guess why.
Medmindre du påpeger ineffektiv pakning, så jo. Skal noget pakkes ind skal det også pakkes ud. Højere kompression = Større krav til CPU, medmindre opgaven kan håndteres på GPU, som du nævner.
Men det er ikke alle, der kan det. Specielt indbyggede grafikkort lider her.
Det er heller ikke al kompression der kan udpakkes af GPU'en.
Theora er kun underlegen med henblik på kompression. Kvaliteten er fin. VP8 burde kunne enten modificeres til opgaven (ligesom Theora sikkert kan), men med Google bag kunne man forestille sig at det blev gjort rigtig godt og meget hurtigt - hvis de ønsker den position i markedet, hvilket jeg, hvis jeg ejede Google ville. :-)
#12 vrøvl... H.264 har hardwareunderstøttelse mange steder, inkl. i mange grafikkortløsninger, så der behøver ikke være noget særligt CPU-krav.
Grafikkort. Mmhmm. Sådan et har min EEE PC. Det er ikke særlig godt. Youtube (m. Chrome beta) streamer fint musik men video lagger som intet andet. Guess why.
Desuden er det ikke korrekt at højere kompression altid betyder større krav til en CPU ved udpakning. I mange tilfælde gør det kun en forskel under pakningen.
Medmindre du påpeger ineffektiv pakning, så jo. Skal noget pakkes ind skal det også pakkes ud. Højere kompression = Større krav til CPU, medmindre opgaven kan håndteres på GPU, som du nævner.
Men det er ikke alle, der kan det. Specielt indbyggede grafikkort lider her.
Det er heller ikke al kompression der kan udpakkes af GPU'en.
VP8 er med garanti væsentlig mere komprimeret (forstået som kvalitet pr. bit) end Theora, som er baseret på VP3. Theora er H.264 klart underlegen. VP8 burde være på linie.
Theora er kun underlegen med henblik på kompression. Kvaliteten er fin. VP8 burde kunne enten modificeres til opgaven (ligesom Theora sikkert kan), men med Google bag kunne man forestille sig at det blev gjort rigtig godt og meget hurtigt - hvis de ønsker den position i markedet, hvilket jeg, hvis jeg ejede Google ville. :-)
#14
Du kan ikke kigge på kvaliteten alene. Ellers kan jeg snildt smække et codec sammen der er tabsfrit men uden kompression og sige at mit codec er bedre end både H.264 og VP8.
Som det står i dag, så vinder H.264 over VP8 ved samme bitrate.
ZiN (14) skrev:
Theora er kun underlegen med henblik på kompression. Kvaliteten er fin.
Du kan ikke kigge på kvaliteten alene. Ellers kan jeg snildt smække et codec sammen der er tabsfrit men uden kompression og sige at mit codec er bedre end både H.264 og VP8.
Som det står i dag, så vinder H.264 over VP8 ved samme bitrate.
Aner ikke hvad I fabler om med ud- og indpakning, men jeg er glad for mine 2-5% CPU når jeg ser 1080p rips :D
H.264 er ikke "pakket" som i pakket i en zip-fil og skal derfor ikke pakkes ud. Komprimeringen sker alene på samme måde som MPEG2 - der er så bare nogle bedre algoritmer og lidt flere tweaks.
At min GPU så sveder lidt kan jeg bedre leve med.
H.264 er ikke "pakket" som i pakket i en zip-fil og skal derfor ikke pakkes ud. Komprimeringen sker alene på samme måde som MPEG2 - der er så bare nogle bedre algoritmer og lidt flere tweaks.
At min GPU så sveder lidt kan jeg bedre leve med.
ZiN (8) skrev:Spørgsmålet er så, hvordan Google i bedste Google stil vil tjene penge på at frigive sådan et codec.
Først og fremmest vil en forbedring af komprimering på 50% spare youtube for milioner af dollars.
Dernæst kommer at et fælles format vil gøre video på internettet endnu mere udbredt. Det betyder at internettet bliver mere brugbart, hvad igen betyder at flere bruger det. Og som Google siger med Android: Jo flere, der bruger internettet, jo flere bruger Google.
Jeg kan slet ikke se, hvorfor Google skulle købe Vp8 i første omgang, hvis det ikke var for at gøre fixe hele H264 problematikken.
#16 Og algoritmer kan ikke være tunge eller hvad mener du? Edit: Om man så kalder det kompression eller pakning kan vel være det samme
#12
Din formulering var bare lidt underlig. CPUen bliver jo som sådan ikke langsommere, den får bare mere at lave. Og det er jo kun mens du ser video.
ah, tak for din opklaring. Nu kan jeg bedre forstå det.
Din formulering var bare lidt underlig. CPUen bliver jo som sådan ikke langsommere, den får bare mere at lave. Og det er jo kun mens du ser video.
ah, tak for din opklaring. Nu kan jeg bedre forstå det.
@ #14, #15 og #19
Det er forskellig komprimering vi snakker om.
Zip/RAR og den slags er "lossless"(intet original data må tabes) komprimering, der i langt de fleste tilfælde vil kræve mere at dekomprimere jo hårdere komprimeringen er.
Komprimering af billeder og video er for det meste "lossy" (noget af den originale data må godt smides væk) koprimering.
En lossy komprimering kan godt være mere effektiv i "kvalitet/bit" uden at det kræver mere regning at dekomprimere, fordi at komprimeringen bruger en masse energi på at vælge det data der skal smides væk, så billedet stadig ser tilfredsstillende ud.
Det data der bliver smidt væk bliver aldrig dekomprimeret og kræver derfor ikke regnekraft.
Det er forskellig komprimering vi snakker om.
Zip/RAR og den slags er "lossless"(intet original data må tabes) komprimering, der i langt de fleste tilfælde vil kræve mere at dekomprimere jo hårdere komprimeringen er.
Komprimering af billeder og video er for det meste "lossy" (noget af den originale data må godt smides væk) koprimering.
En lossy komprimering kan godt være mere effektiv i "kvalitet/bit" uden at det kræver mere regning at dekomprimere, fordi at komprimeringen bruger en masse energi på at vælge det data der skal smides væk, så billedet stadig ser tilfredsstillende ud.
Det data der bliver smidt væk bliver aldrig dekomprimeret og kræver derfor ikke regnekraft.
Kraftigere kompression vil (typisk) øge behovet for CPU ved dekodning, da algoritmerne for kraftig kompression er mere komplicerede, men det vil på den anden side mindske mængden af RAM access, hvilket igen peger den anden vej. Det er nok svært at generelisere over slutresultatet rent performancemæssigt.
Anyway, H.264 er mig bekendt det mest effektive videocodec. Så valget er svært: Frit og open-sauce, eller "bedste codec"? Den er ikke nem.
Og ved at vælge at supporte alle formater og container-formater, åbner HTML5 op for et sandt kaos af "gyldige" formater. Man skubber problemet med kompatibilitet videre til medieafspilleren.
Det kunne ellers have været smart, hvis f.eks. validator.w3.org kunne sige f.eks. "Din webside er ikke gyldig html5, da du har valgt .mov som container i stedet for .mkv til dine H.264 videofiler" eller lign. Men som det ser ud nu, vil alle audio-, video- og container-formater blive accepteret.
Anyway, H.264 er mig bekendt det mest effektive videocodec. Så valget er svært: Frit og open-sauce, eller "bedste codec"? Den er ikke nem.
Og ved at vælge at supporte alle formater og container-formater, åbner HTML5 op for et sandt kaos af "gyldige" formater. Man skubber problemet med kompatibilitet videre til medieafspilleren.
Det kunne ellers have været smart, hvis f.eks. validator.w3.org kunne sige f.eks. "Din webside er ikke gyldig html5, da du har valgt .mov som container i stedet for .mkv til dine H.264 videofiler" eller lign. Men som det ser ud nu, vil alle audio-, video- og container-formater blive accepteret.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund