Nokia nie chce Ogg w standardzie HTML5

co do szczegółów technicznych, to nie będę się kłucił, bo nie znam się na tyle na tym zagadnieniu. Ale jeśli miałbym wyierać między nieco gorszą jakością dźwięku a wogóle możliwością jego odbioru, to wolę to pierwsze. Otwarty kodek zawsze zapewnia mi tą możliwość – niezależnie od tego jakiego systemu używam i z jakiej przeglądarki korzystam. Mam też pewność, że nie wcisną mi jakiegoś DRMu. Natomiast z zamkniętych kodeków mogą korzystać tylko ci którym na to pozwoli twórca tego kodeka (czyli tylko ci, którzy korzystają z systemu/przeglądarki, którą twórca kodeka łaskawie uzna za odpowiednią).

W takiej sytuacji niech adobe i nokia spadają na drzewo

sory – apple a nie adobe:P

swoją drogą apple to coraz bardziej wczuwa się w rolę następcy mikrosoftu…

@tomek: H.264 i AAC jest otwarte, problemem są tylko właśnie patenty i opłaty licencyjne.

Vorbis mniej więcej podobnie.

Z tego co mi wiadomo, to Vorbis nie jest opatentowany. Theora jest, ale _nie_ są pobierane opłaty patentowe.

Wystarczy poczytać "W3C Patent Policy":
http://www.w3.org/Consortium/Patent-Policy-200402…
żeby się dowiedzieć, że H.264 i AAC nie spełniają kryteriów wyznaczonych przez W3C (jak napisał val-gaav – istnieją opłaty licencyjne). vorbis i theora spełniają (oprócz otwartości, brak opłat licencyjnych i patentowych).

AAC+ jeśli już (albo HE-AAC) Ten format kompresji korzysta z technologii SBR (technika poszerzania pasma częstotliwości sygnału), tak samo jak i MP3Pro, oba formaty przy niskich bitrate ładnie brzmią, a nawet nie da się ich skompresować w wyższym niż bodajże 128 kbps. Jednak oba formaty z jakąś nadzwyczajną kompresją mają mało wspólnego, bo technika ta polega na pewnego rodzaju "odgadywania" wysokich częstotliwości, których wcale nie ma w zakodowanym utworze, są jedynie śladowe ilośći zapisane w mniejszych bitrate'ach, których to zadaniem jest "pomoc w odgadywaniu". OGG nie posiada technoligii SBR, więc dla wyrównania szans proponuję porównać zwykłe MP3, zwykłe AAC i wtedy oceniać jaką te 3 formaty oferują jakość… Wniosek? Zdecydowanie OGG bije konkurencję. Gdyby jednaką taką technikę kodowania wdrożyć do OGG, to te "super" formaty jak MP3Pro i AAC+ też by zdecydowanie przegrały.

Pozdrawiam

AAC+ w bitrate 24kbps brzmi podobnie do mp3 128kbps i ogg 96kbps, a wiec nawet nie ma o czym mowic…

@dave

To sobie weź człowieku porównaj AAC+ z MP3Pro skoro już taki mądry jesteś. Na tym polu AAC+ z MP3Pro przegrywa.

Dave troche przesadziłes podobnie nie brzmią, ale brzmią na takim poziomie że da się tego słuchać.

OGG nie posiada technoligii SBR, więc dla wyrównania szans proponuję porównać zwykłe MP3, zwykłe AAC

A dlaczego? ktoś zabrania implementacji SBR w OGG ??

To tak jakby powiedzieć że nie wolno porównywać czarnobiałego telewizora sprzed 40 lat do Sony Bravia bo tamten nie ma kolorów.

Dla ekstremalnie niskich przepustowości HE-AAC nie ma raczej konkurencji, i żaden wolny kodek pod tym względem na razie nie jest lepszy.

Dowody :

http://myk750.lasyk.net/sub/127/ALL/date/1/K750-S…

oraz

http://stefans.datenbruch.de/k750i/

ThemeCreator używa starego GStreamera i nie bardzo da się go uruchomić w nowszym systemie…

Ale licencja BSD nie zmienia faktu, że dostosowanie kodu do ich potrzeb, optymalizacja na komórkowe platformy itd. to kupa roboty. AAC/H.264 zoptymalizowane na ARM-y na pewno można kupić w paru firmach i problem z głowy. Założę się, że z Vorbis/Theora nie jest tak różowo.

w.

??

kodu się nie optymalizuje pod konkretną architekturę… no chyba że piszesz w asm… a założę się że wyżej wspomniane biblioteki są napisane w C.

odpowiednich optymalizacji dokonuje kompilator.

nie wypowiadajcie się na tematy na których się nie znacie…

po prostu takie firmy jak apple i nokia chcą mieć jak największą kontrolę nad formatami mediów w swoich urządzeniach.

Ależ oczywiście, że się optymalizuje. Zobacz sobie niskopoziomowy kod w jądrze lub mplayerze. Jak chciałbyś np. wydajnie użyć SSE bez konkretnego kodu (niekoniecznie asm zobacz funkcje wbudowanie w gcc)? Podpowiedź: nie, kompilatory nie radzą sobie jeszcze z tym dobrze.

> nie wypowiadajcie się na tematy na których się nie znacie…

Otóż to.

w.

hmm… no dobra. może się nie do końca znam na sposobach optymalizacji wykorzystywanych w kodekach. w każdym razie niejasno się wyraziłem w pierwszym poście – chodziło mi nie ogólnie o każdy kod pisany w języku wysokopoziomowym, ale o biblioteki i soft pisany dla user space. Co innego jądro – to nie jest jakaś tam biblioteka. Sam zdaję sobie sprawę, że niektóre (wszystkie?) implementacje Standard C Library są pisane w asm, ale to co innego niż kodeki.

W "zwyczajnym" sofcie kod powinien być jak najbardziej przenośny (przynajmniej ten otwarty), więc optymalizacje dla konkretnego sprzętu to według mnie zła praktyka.

Jeśli są implementacje AAC/H.264 zoptymalizowane pod konkretne architektury, to przyznaję – nie wiedziałem o czym piszę:P ale według mnie to najzwyczajniej w świecie głupia głupota – nawet telefony komórkowe są obecnie na tyle wydajne, że takie optymalizacje to przerost formy nad treścią. (a zanim finalna wersja html5 zostanie opublikowana, to miną przynajmniej 2 lata i wydajność komórek i podobnych urządzeń się jeszcze zwiększy)

Cóż optymalizacja czasem ma kluczowe znaczenie, czasem to tylko przerost formy nad treścią. W takich powiedzmy telefonach użycie libvorbisa jest zdecydowanie bzdurne, bo ARM'y (i inne cośie pewnie tak samo) nie mają jednostki zmienno przecinkowej, a jej emulacja jest bardzo nie wydajna. No ale tutaj na ratunek powinien przyjść Tremor (operuje tylko na operacjach stałoprzecinkowych). Tym razem sprawdziłem Tremor też jest na BSD…

A co do samej optymlizacji, tak na innym przykładzie – mianowicie dekodowania mp3, porównajcie sobie możliwości powiedzmy takiego libmad'a (który też nie jest taki zupełnie niewydajny) z dekoderem Helixa. Helix potrafi dekodować mp3 mając kilkdziesiąt kilo pamięci do dyspozycji, przy odrobinie zabiegów w samej warstwie sprzętowej można nawet jeszcze zjechać z ilością niezbędnej pamięci. Dla porównania libmad to już (grube) setki kilko. Czasami może mieć to znaczenie gdy producent chce zaoszczedzić na samym sprzecie, a użyć wydajniejszych algorytmów. Co innego PC'et czy taki MAC, im to rybka i tak procek i pamięć pozostaną w 99% niewykorzytane niezależnie jakiej implementacji się użyje.

> Sam zdaję sobie sprawę, że niektóre (wszystkie?) implementacje

> Standard C Library są pisane w asm, ale to co innego niż kodeki.

Mhm.

> W “zwyczajnym” sofcie kod powinien być jak najbardziej przenośny

> (przynajmniej ten otwarty), więc optymalizacje dla konkretnego

> sprzętu to według mnie zła praktyka.

Powiedz to wszystkim firmom, które specjalizują się w optymalizacji kodeków na konkretne platformy [1]. Możliwe, że zechcą zmienić swoje ,,złe'' praktyki i przerzucą się na inny biznes. Powiedz to ludziom, którzy dekodują MP3 na 50-megahercowym ARM-ie [2]. Albo po prostu zrozum, że w systemach wbudowanych zwykle nie umieszcza się ,,zwyczajnego'' softu.

> (…) ale według mnie to najzwyczajniej w świecie głupia głupota

> – nawet telefony komórkowe są obecnie na tyle wydajne, że

> takie optymalizacje to przerost formy nad treścią.

Nie mylisz przypadkiem telefonów komórkowych ze smartphone'ami? Zresztą nawet jeśli, to mój smartphone Nokii z zeszłego roku (więc nie taki znowu stary) nie radzi sobie z odtwarzaniem H.264 z prędkością ponad 12fps przy rozdzielczości ~CIF. Nie każdy telefon to 400-megahercowy PDA, który radzi sobie z DivX-ami bez rekompresji i jeszcze długo tak pobędzie.

w.

[1] http://www.spiritdsp.com, http://www.google.pl/search?q=intel+ipp
[2] http://www.google.pl/search?q=arm+mp3+helix

> nie wypowiadajcie się na tematy na których się nie znacie…

dooobre szczegolnie gdy kolo widac sam sie nie zna na temacie, a tym bardziej, ze kieruje to do wojtkka

no ja wcale nie twierdzę że każdy telefon to jakiś superkomputer. Mój telefon na przykład obsługuje tylko midi i dźwięki monofoniczne:P

ale żaden producent komórek czy smartfonów nie będzie instalował przeglądarki czytającej html5 w starym sprzęcie, a za 2 lata (mniej więcej wtedy prace nad html5 mają zostać ukończone) technologia będzie o wiele bardziej zaawansowana niż rok temu, kiedy produkowali Twojego smartfona:P

co do firm specjalizujących się w optymalizacji kodeków pod konkretne platformy – niedługo chyba będą musiały zmienić profil działalności

> W takich powiedzmy telefonach użycie libvorbisa jest

> zdecydowanie bzdurne, bo ARM’y (i inne cośie pewnie tak

> samo) nie mają jednostki zmienno przecinkowej, a jej

> emulacja jest bardzo nie wydajna.

ARM11 chyba już ma. A to już można znaleźć na przykład w N95.

> No ale tutaj na ratunek powinien przyjść Tremor (operuje

> tylko na operacjach stałoprzecinkowych).

A i owszem, radzi sobie bardzo dobrze.

> co do firm specjalizujących się w optymalizacji kodeków pod

> konkretne platformy – niedługo chyba będą musiały zmienić profil

> działalności

A Ty dalej swoje. W tej chwili mój nie-tak-stary P4C 2GHz jest zbyt wolny do oglądania H.264 w 720p dekodowanych ffmpegiem, za to znajomi windowsiarze mówią, że CoreAVC sobie na takim sprzęcie radzi z palcem w nosie. Za parę lat to przestanie być problemem, ale jto zoptymalizuje następców AAC i H.264, żeby dało się z nich korzystać na zaledwie 5-gigahercowych maszynach?

w.