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.
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 ;-).
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 😉 )
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.
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.
A świstak siedzi i zawija… 😀
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.
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ł.
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.
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…
Jest lepszy tylko w niektórych zastosowaniach.
A w których i czemu? Cierpię na niedobór konkretów i linków…
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…
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.
Znając historię open-sourcowych projektów googla, bardziej prawdopodobne jest to, że VP8 będzie na licencji Apache.
@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.
Wystarczy żeby standard był otwarty, implementację zawsze można napisać na jakiej tylko licencji chcesz.
Znajac zycie skonczy sie na 10ciu formatach i braku wyraznej przewagi ktoregokolwiek z nich 😉
Kodeków do grafiki (tag <img/>) też nie ustandaryzowano, a jakoś da się żyć.
Celny strzał 🙂
Oby z kodekami wideo było podobnie.
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.
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ą?
@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.
Używanie nie wymaga opłat – opłat wymaga redystrybucja.
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.
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.
@vf: MSIE obslugiwal format PNG od co najmniej wersji 6.5. Wiem, bo wtedy mialem jeszcze z MSIE jakistam kontakt.
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.
@o3a: Tak, ale byl na to workaround. MSIE i tak potrzebowal masy workaroundow, wiec jeden wiecej roznicy nie robil.
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 😉 ).
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.
Ogg nie jest żadnym standardem. Cytat z ximh.org:
,,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!
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.
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)?
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.
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.
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.
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.
Update:
Czyli obsługuje jeszcze większe rozdzielczości.
Nie widać.
Jak robiłeś test? Podaj parametry mencodera – sam bym chętnie zobaczył.
Używałem ffmpeg:
ffmpeg -i [input] -vcodec h264 -sameq [output]
ffmpeg -i [input] -vcodec snow -sameq [output]
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.
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?
Sprawdź – też nie mogłem uwierzyć…
Ok, jutro przetestuję i trzymam za słowo 😉
Albo i nie przetestuję, bo na obecnej wersji ffmpeg coś nie działa…
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
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)
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.
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.
JPEG2000 ma tryb bezstratny, ale, cytując za Wikipedią: