Kategorie:
32

Google uwolni VP8

Być może nastąpi to już w przyszłym miesiącu na konferencji Google I/O. Informacja ma na razie status plotki, jednak potwierdziło ją rzekomo kilka niezależnych źródeł wewnątrz Google. Na tej samej konferencji ma zostać ogłoszona obsługa nowego kodeka w przeglądarkach Chrome i Mozilla Firefox.

Google kontroluje kodek VP8 od momentu sfinalizowania przejęcia On2 Technologies w lutym tego roku. Jednak wówczas firma nie ogłosiła żadnych planów w związku z nowym kodekiem.

Ewentualne uwolnienie VP8 wychodzi naprzeciw oczekiwaniom społeczności FLOSS (wyrażonych np. w liście otwartym FSF). Pomogłoby również wydawcom treści, którzy mogliby wdrożyć wsparcie dla HTML5 w oparciu o kodek, który z jednej strony zapewni odpowiednią jakość, a z drugiej nie jest obwarowany opłatami za licencje. Do jego zalet należą przede wszystkim brak opłat licencyjnych i jakość co najmniej porównywalna z H.264 przy mniejszej wymaganej przepustowości. Największą przeszkodą w szybkiej adaptacji nowego standardu byłoby przede wszystkim nikłe wsparcie dla sprzętowego dekodowania VP8. Również korporacje, takie jak Apple czy Microsoft, zainwestowały duże pieniądze w celu używania kodeku H.264 i trudno wyobrazić sobie, że porzucą swoje inwestycje. Być może jednak zwycięzcą boju między Theorą a H.264 będzie właśnie VP8.

Więcej informacji: http://newteevee.com/2010/04/12/google-t...ml5-video/

«
»

Znalazłeś literówkę? Zgłoś ją używając formularza!


Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.

Niusy na podobny temat:

Komentarze (RSS)

Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.

51 komentarzy

zwiń wątek Cyber Killer  13 kwietnia 2010 o godz. 10:23 #
Gravatar

Słowa "porównywalna jakość" są IMHO ciut naciągane. Na mój gust Theora wygląda wystarczająco dobrze, w końcu wideo wstawione na stronkę www nie musi być uber-piękne, więc drobne okazyjne przekłamania kolorów można wybaczyć. No ale też dobrze jeśli padnie na VP8, byle nie h.264 i byle było to zaimplementowane w Operze ;-) .

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek abcd  14 kwietnia 2010 o godz. 0:09 #
Gravatar

Nie musi? Pamiętaj, że większość nowych monitorów teraz ma rozdzielczości większe niż 1280×720 (tzw. HD-Ready), a szybkość łączy rośnie (w cywilizowanych krajach, gdzie ADSL nie jest jedyną metodą dostępu do sieci ;) )

 
 
zwiń wątek Emdek  13 kwietnia 2010 o godz. 10:35 #
Gravatar

Kurcze, znowu bajzel się szykuje, już nie dwa, ale trzy formaty mogą pretendować do roli "standardowego", którym miał być OGG…

Chociaż z drugiej strony to dobrze, że mamy szansę na otrzymanie dobrego kodeka.

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek Aix  13 kwietnia 2010 o godz. 10:11 #
Gravatar

kodek VP8 ma rewelacyjne parametry, jest lepszy od dotychczas najlepszego h264. Jeśli będzie uwolniony od opłat licencyjnych i będzie łatwe jego stosowanie lub będzie miało otwarty kod na licencji GPL to bardzo szybko stanie się nie tylko standardem w sieci, ale i na ziemi. Bo nie trzeba będzie płacić opłat za H264.

zwiń wątek :P  13 kwietnia 2010 o godz. 12:56 #
Gravatar

A świstak siedzi i zawija… :D

Przed głoszeniem teorii o ub3rowości VP8 proponuje zapoznać się z testami użytkowników doom9, a nie tylko z marketingowym bełkotem on2.

zwiń wątek kocio  13 kwietnia 2010 o godz. 12:20 #
Gravatar

Nawet jeśli będzie podobny, ale bez opłat licencyjnych oraz pułapek patentowych i np. szybszy na urządzeniach mobilnych, to będzie miał fory.

A propos – jakieś konkretne linki? Chętnie bym poczytał.

 
zwiń wątek kocio  13 kwietnia 2010 o godz. 12:40 #
Gravatar

To nie jest test, ale uwagi krytyczne ze strony dewelopera x264 – o VP8 jest dużo pod koniec:

http://x264dev.multimedia.cx/?p=292

Na Doom9 nie znalazłem na razie nic ciekawego, tylko ogólne dyskusje.

 
zwiń wątek :P  14 kwietnia 2010 o godz. 0:39 #
Gravatar

No właśnie – jak na razie on2 mówił, że ma ub3r kodek, ale jeszcze nie wypuścił zestawu do samodzielnego przetestowania ilości kłamstw w tym stwierdzeniu. Bo cóż, wszystkie te gadania o wielkości VP8 (patrz wyżej) są śmieszne – bo H.264 było już "bite" przez VP6 – http://www.on2.com/index.php?id=470&news_id=2

 
 
zwiń wątek Reddie  13 kwietnia 2010 o godz. 15:30 #
Gravatar

Jest lepszy tylko w niektórych zastosowaniach.

zwiń wątek kocio  13 kwietnia 2010 o godz. 14:32 #
Gravatar

A w których i czemu? Cierpię na niedobór konkretów i linków…

 
zwiń wątek Reddie  13 kwietnia 2010 o godz. 17:54 #
Gravatar

Trochę źle się wyraziłem – pisząc "lepszy niż H.264" mam na myśli wolną implementację H.264, x264. O ile standard określa zawartość ścieżki i sposób jej dekodowania, to np. algorytmy wykrywania ruchu mogą być indwidualnie implementowane w kodeku.

Ogólnie rzecz biorąc, VP8 daje w najlepszym wypadku obraz jednolity – mało widocznych makrobloków, ale też kiepska ostrość. Sprawdza się to w przypadku np. starych animacji. Nowe są często robione techniką komputerową i mają dużo detali, natomiast stare składają się z mało skomplikowanych kształtów geometrycznych, tudzież linii które już w momencie powstania ostre nie były ;) Mam tu na myśli produkcje w stylu "Bolka i Lolka".

x264 jest bardzo wszechstronny, więc _tylko_ na takim materiale i _tylko_ przy niskim bitrate wyglądałby gorzej (byłyby widoczne makrobloki, a w połączeniu z ostrym obrazem efekt wygląda paskudnie).

Zaznaczam, że to moje przewidywania, ale pozwolę sobie usprawiedliwić wypowiadanie ich jako faktu:

1) znam się dość dobrze na temacie,

2) mało kto ma dostęp do tego (komercyjnego) kodeka, dostępne są tylko sample

3) On2 prowadzi politykę dezinformacji, podając np. takie porównania:
http://www.on2.com/index.php?599
Obrazki mają pokazywać jakość kodeków, ale same są podane kompresji JPEG i jako takie bezużyteczne w porównywaniu. Podobnie wideo niżej, gdzie H.264 i VP8 i tak są skodowane Flashem…

 
zwiń wątek kocio  14 kwietnia 2010 o godz. 15:11 #
Gravatar

Jeśli chodzi o ostrość, to w Theorze 1.1 się widocznie poprawiła dzięki poprawie DCT:

http://web.mit.edu/xiphmont/Public/theora/demo7.h

Być może VP8 też dałoby się w tym poprawić do dobrego poziomu.

 
 
zwiń wątek Magik  13 kwietnia 2010 o godz. 19:56 #
Gravatar

Znając historię open-sourcowych projektów googla, bardziej prawdopodobne jest to, że VP8 będzie na licencji Apache.

zwiń wątek trasz  13 kwietnia 2010 o godz. 20:34 #
Gravatar

@Magik: I dzieki bogu – zastosowanie licencji GPL uniemozliwiloby wykorzystanie kodeka w jakimkolwiek oprogramowaniu na innych licencjach, czyli m.in. w dowolnej popularnej przegladarce WWW. Licencja Apache nie stwarza takich problemow.

 
zwiń wątek Reddie  14 kwietnia 2010 o godz. 16:35 #
Gravatar

Wystarczy żeby standard był otwarty, implementację zawsze można napisać na jakiej tylko licencji chcesz.

 
 
 
zwiń wątek krzabr  13 kwietnia 2010 o godz. 10:51 #
Gravatar

Znajac zycie skonczy sie na 10ciu formatach i braku wyraznej przewagi ktoregokolwiek z nich ;)

 
zwiń wątek el.pescado  13 kwietnia 2010 o godz. 11:45 #
Gravatar

Kodeków do grafiki (tag <img/>) też nie ustandaryzowano, a jakoś da się żyć.

zwiń wątek pps  13 kwietnia 2010 o godz. 12:00 #
Gravatar

Celny strzał :)

Oby z kodekami wideo było podobnie.

 
zwiń wątek Sparrow1  13 kwietnia 2010 o godz. 12:12 #
Gravatar

Ale na formaty plików z grafiką nie obowiązują płatne licencje. Jedyny problem był z GIFami, a odpowiedzią na nie stało się PNG. Tu jest inaczej, bo z góry wiadomo, że MPEG-LA będzie chciało kasę za h264 i nie da się tego łatwo przeskoczyć. Gdyby np. Mozilla odmówiła (hipotetycznie) obsługi plików JPEG, to prawdopodobnie szybko zniknęłaby z rynku. Dlatego niebezpieczna jest sytuacja, w której np. h264 staje się "nowym JPEGiem" czyli standardem de-facto.

zwiń wątek pps  13 kwietnia 2010 o godz. 12:15 #
Gravatar

Pisząc "podobnie" miałem właśnie na myśli kilka otwartych i nielicencjonowanych kodeków. Również nie chciałbym, żeby powtórzyła się sprawa z GIFem…

BTW. x264 też jest obwarowany jakąś licencją?

 
zwiń wątek Sparrow1  13 kwietnia 2010 o godz. 12:23 #
Gravatar

@pps:x264 jest na GPLu, ale MPEG LA posiada patenty na algorytmy wykorzystane w tym kodowaniu. Więc w zależności od kraju jego używanie(bez opłat patentowych) może być legalne, albo nie.

 
zwiń wątek el.pescado  13 kwietnia 2010 o godz. 15:57 #
Gravatar

Używanie nie wymaga opłat – opłat wymaga redystrybucja.

 
zwiń wątek vf  14 kwietnia 2010 o godz. 13:42 #
Gravatar

Sparrow1: JPEG nie jest de-facto standardem tylko normalnym standardem ISO, a konkretnie ISO/IEC 10918. Mało tego JPEG jest również standardem ITU-T.

 
 
zwiń wątek vf  14 kwietnia 2010 o godz. 13:48 #
Gravatar

Być może się da żyć, ale lepiej było by jakby się mogło dobrze żyć a nie tylko żyć. Przypominam jaka jest sytuacja w kodekach obrazków – spora część stron używa śmiesznego standardu GIF, który przechowuje 256 kolorów czyli tyle co ja mam kredek w domu :) . Niby jest PNG, który mimo, że istnieje od wielu lat ale dopiero teraz IE zaczyna go obsługiwać, a animacji nie ma… OK są APNG który nie jest implementowany prawie nigdzie i MNG, który już został olany przez twórców przeglądarek. Tyle jeśli chodzi o grafikę bezstratną… A co z grafiką stratną (która głownie jest wykorzystywana w zdjęciach) – też nieciekawie. Mamy JPEG, który od wielu lat został zastąpiony przez znacznie lepszy JPEG2000. I co? I nic w przeglądarkach nikt tego nie zaimplementował. Tak z grubsza wyglądają kodeki w obrazkach. Jednym słowem: średniowiecze.

zwiń wątek trasz  14 kwietnia 2010 o godz. 14:01 #
Gravatar

@vf: MSIE obslugiwal format PNG od co najmniej wersji 6.5. Wiem, bo wtedy mialem jeszcze z MSIE jakistam kontakt.

 
zwiń wątek o3a  14 kwietnia 2010 o godz. 14:45 #
Gravatar

Nie do końca obsługiwał. Konkretnie – nie dawał rady z przezroczystością. Trzeba było używać sztuczek, a i tak zabawa z animacją via opacity generowała czarna kaszankę. Nie wiem jak jest w ie8.

 
zwiń wątek trasz  15 kwietnia 2010 o godz. 11:39 #
Gravatar

@o3a: Tak, ale byl na to workaround. MSIE i tak potrzebowal masy workaroundow, wiec jeden wiecej roznicy nie robil.

 
 
 
zwiń wątek Maciej Piechotka  13 kwietnia 2010 o godz. 12:24 #
Gravatar

Hmm. Czy mi się wydaj czy VP8 to kodek tak jak Theora a OGG to kontener tak jak AVI?

Tzn. można używać OGG/Theora, OGG/VP8, OGG/MPEG-4, OGG/Dirac… (nie wspominając o OGG/Vorbis ;) ).

zwiń wątek eee  13 kwietnia 2010 o godz. 21:36 #
Gravatar

uhm, ale standard ogg miał definiować nie tylko kontener, ale też domyślny kodek wideo. inaczej nie byłby standardem, a jedynie formatem, ew. standardem kontenera.

zwiń wątek el.pescado  13 kwietnia 2010 o godz. 23:14 #
Gravatar

Ogg nie jest żadnym standardem. Cytat z ximh.org:

Ogg is a multimedia container format, and the native file and stream format for the Xiph.org multimedia codecs. As with all Xiph.org technology is it an open format free for anyone to use.

 
 
 
 
zwiń wątek Tomasz Torcz  13 kwietnia 2010 o godz. 11:48 #
Gravatar

,,Informacja ma na razie status plotki, jednak potwierdziło ją rzekomo kilka niezależnych źródeł wewnątrz Google.''

Anonimowe źródła rzekomo potwierdzają plotkę. Proszę, nie sprowadzajcie Linuxnews.pl do poziomu brukowców, piszcie o faktach i konkretach!

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek kocio  13 kwietnia 2010 o godz. 12:18 #
Gravatar

Uważam, że w takiej ważnej sprawie dobrze zredagowany nius z odpowiednim tytułem jest OK. Inaczej by było, gdyby autor pisał jak o sprawie pewnej i się nie zastrzegał albo sformułował tytuł jak sensację – tak nie jest i bardzo dobrze.

Główna różnica między brukowcami a poważnym podejściem nie jest w tym, o czym się pisze, tylko czy się tam ładuje dodatkowe emocje, czy oddziela fakty od spekulacji.

 
 
zwiń wątek wojtekm  13 kwietnia 2010 o godz. 14:05 #
Gravatar

Kurde mają otwartego i wolnego SNOW-a w ffmpeg i nikt się nim nie interesuje. Wszyscy się tak bardzo boją falek (tak wiem, że ich średnia złożoność obliczeniowa jest większa niż DCT, ale stosunek jakość/bitrate też jest zauważalnie większy)?

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek kocio  13 kwietnia 2010 o godz. 13:11 #
Gravatar

Wiesz, zastosowania mobilne rosną w siłę, więc złożoność obliczeniowa raczej będzie jeszcze przez jakiś czas istotnym argumentem za lub przeciw danemu kodekowi. Z tym, że faktycznie w ogóle nie słyszałem o tym, żeby się rozwijał, a to już szkoda.

zwiń wątek wojtekm  13 kwietnia 2010 o godz. 16:57 #
Gravatar

Ale od kiedy w embedded wszystkie zadania pakuje się do jednego CPU? W zdecydowanej większości służą temu dedykowane układy, jak w najpopularniejszych obecnie telefonach z takimi możliwościami.

zwiń wątek maciek  14 kwietnia 2010 o godz. 1:47 #
Gravatar

A z drugiej strony wszelkie iphony (i ich konkurenci na oprogramowaniu Google/Microsoft) są tak na prawde nieistotne dla sprawy dystrybucji treści wideo, bo mają żałosne rozdzielczości i szybkości transmisji, zaś ceny internetu mają koszmarnie wielkie.

 
zwiń wątek el.pescado  14 kwietnia 2010 o godz. 10:24 #
Gravatar

iPhone i iPod touch mają rozdzielczość ekranu 480×320, z taką też rozdzielczością są też domyślnie kodowane filmy dla tych urządzeń (np. przez Handbrake). Dla porównania, wideo w youtube domyślnie jest w 320×240. Co do szybkości transmisji – u mnie, przez WiFi, jest bardziej niż wystarczająca.

 
zwiń wątek el.pescado  14 kwietnia 2010 o godz. 10:30 #
Gravatar

Update:

Video formats supported: H.264 video, up to 1.5 Mbps, 640 by 480 pixels, 30 frames per second, Low-Complexity version of the H.264 Baseline Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats;

H.264 video, up to 768 Kbps, 320 by 240 pixels, 30 frames per second, Baseline Profile up to Level 1.3 with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats;

MPEG-4 video, up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats

Czyli obsługuje jeszcze większe rozdzielczości.

 
 
 
zwiń wątek Reddie  13 kwietnia 2010 o godz. 18:40 #
Gravatar

stosunek jakość/bitrate też jest zauważalnie większy

Nie widać.

zwiń wątek Mieszko Kaczmarczyk  13 kwietnia 2010 o godz. 21:33 #
Gravatar

Jak robiłeś test? Podaj parametry mencodera – sam bym chętnie zobaczył.

zwiń wątek Reddie  14 kwietnia 2010 o godz. 0:17 #
Gravatar

Używałem ffmpeg:

ffmpeg -i [input] -vcodec h264 -sameq [output]

ffmpeg -i [input] -vcodec snow -sameq [output]

 
zwiń wątek wojtekm  14 kwietnia 2010 o godz. 12:58 #
Gravatar

Po pierwsze SNOW praktycznie nie jest rozwijany jak już pisałem na początku a x264 jest cały czas udoskonalany, co w zasadzie tylko potwierdza moją tezę.

Po drugie parafrazując pewną reklamę: skoro nie widać różnicy to po co przepłacać (patenty) abstrahując od faktu, że pewnie szybko nadrobił by zaległości gdyby zaczęto go bardziej rozwijać.

Po trzecie '-sameq' to niewłaściwa opcja, zmniejsz bitrate do 128-256 kbps i wtedy porównuj. Gwarantuję Ci, że różnica będzie spora na korzyść falek.

 
zwiń wątek Reddie  14 kwietnia 2010 o godz. 15:49 #
Gravatar

Napisałem, że nie widać różnicy na korzyść Snow. W drugą stronę owszem ;)

Taki niski bitrate używa się dla audio, chcesz powiedzieć, że Snow dobrze sobie poradzi z materiałem choćby w jakości SD?

 
zwiń wątek wojtekm  14 kwietnia 2010 o godz. 16:28 #
Gravatar

Sprawdź – też nie mogłem uwierzyć…

 
zwiń wątek Reddie  14 kwietnia 2010 o godz. 16:37 #
Gravatar

Ok, jutro przetestuję i trzymam za słowo ;)

 
zwiń wątek Reddie  15 kwietnia 2010 o godz. 13:37 #
Gravatar

Albo i nie przetestuję, bo na obecnej wersji ffmpeg coś nie działa…

Could not write header for output file #0 (incorrect codec parameters ?)

 
 
 
 
zwiń wątek Gghhhg  13 kwietnia 2010 o godz. 18:35 #
Gravatar

Jak trzeba to se kupcie. Teraz Palm prawdopodobnie będzie sprzedany. Może by ich system kupić? Sam bym wysuplal trochę kasy. Webos to śmieć ale ten poprzedni ma sens. Haiku by się uciesylo:)

tak samo tu. Google może uwolnić ale jak by zarzadalo kasy to tez bym na to poszedł . A png jest na razie sto lat do tylu od nowych jpegow ba nawet starego jpeg2000 jest do tylu

(Poniżej tego poziomu komentarze nie będą zagnieżdżane)
zwiń wątek abcd  14 kwietnia 2010 o godz. 0:13 #
Gravatar

A jpeg2000 ma jakiekolwiek zastosowania poza DCI (kina cyfrowe, obraz w 2K skompresowany właśnie tym kodekiem, chyba nawet bez wektorów ruchu, same klatki, wtedy jeden przeciętny film zajmuje gdzieś 130-150 GB przy rozdzielczości niemal identycznej jak konsumenckie HD, trochę bardziej dopasowanej do szerokiego – 2,35:1 ekranu)

zwiń wątek borizm  14 kwietnia 2010 o godz. 16:22 #
Gravatar

A JPEG2000 nie miał być z założenia komercyjny?

Już Przecież po ten stary, dobrze znany JPEG, twórcy jakiś czas temu wyciągali rączki do zbierania pieniążków, ale coś chyba poszło nie po ich myśli.

 
 
zwiń wątek Beorn  15 kwietnia 2010 o godz. 19:43 #
Gravatar

Nie rozumiem tego stwierdzenia, że PNG jest "sto lat do tyłu" za JPEG.

Pod względem jakości? PNG jest formatem bezstratnym (w przeciwieństwie do JPEG), jak więc może być gorszy?

Pod względem rozmiaru? Jak już napisałem, PNG jest bezstratny, więc to chyba jest do przewidzenia.

Pod względem ilości literek w skrócie nazwy? Tu masz rację, JPEG ma ich więcej, a JPEG2000 to już prawdziwy lider wśród formatów graficznych.

zwiń wątek el.pescado  16 kwietnia 2010 o godz. 14:04 #
Gravatar

JPEG2000 ma tryb bezstratny, ale, cytując za Wikipedią:

Although JPEG 2000 format supports lossless encoding, it is not intended to completely supersede today's dominant lossless image file formats.

The PNG (Portable Network Graphics) format is still more space-efficient in the case of images with many pixels of the same color, such as diagrams, and supports special compression features that JPEG 2000 does not.

 
 
 

Uwaga! Niektóre komentarze, m.in. te dodane przez niezalogowanych i nowych użytkowników, są ręcznie moderowane. Jeśli Twój komentarz nie ukaże się od razu, nie dodawaj go ponownie, tylko cierpliwie poczekaj na akceptację.

W komentarzach możesz używać prostych znaczników HTML. Przykłady:
  • Link: <a href="http://osnews.pl">OSnews: niusy IT</a>,
  • Wytłuszczenie: <strong>tekst pogrubiony</strong>,
  • Kursywa: <em>tekst pochylony</em>,
  • Przekreślenie: <strike>tekst przekreślony</strike>,
  • Kod: <code>printf("blok kodu");</code>,
  • Cytat: <blockquote>cytat</blockquote>
Uwaga: jeśli dodasz nieznany znacznik, będzie on niewidoczny, gdyż system filtruje takie znaczniki.

Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.

Twoja sugestia