Mozilla Hacks: Firefox, YouTube i WebM

W dzisiejszym odcinku tłumaczeń z Mozilla Hacks notka Chrisa Blizzarda, jednego z głównych „ewangelizatorów” Mozilli, na temat formatu WebM. Wprawdzie sam napisałem o tym formacie w poprzedniej notce, ale myślę, że warto posłuchać oficjalnego głosu Mozilli. Jak większość treści z MozHacks, zarówno oryginalny artykuł, jak i poniższe tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.

Dzisiaj pięć ważnych rzeczy:

1. Google wyda VP8 jako open-source i bez żadnych opłat (royalty-free). VP8 to wysokiej jakości kodek, w którego posiadanie Google weszło po zakupie firmy On2. Kodek VP8 jest znacznie lepszy pod względem stosunku jakości do liczby bitów niż Theora, a sama jego jakość porównywalna jest z H.264.

2. Kodek VP8 zostanie połączony z kodekiem audio Vorbis i podzbiorem formatu kontenera Matroška w jeden nowy standard otwartego wideo dla WWW – zwany WebM. Więcej na ten temat można znaleźć na w nowej witrynie projektu: http://www.webmproject.org/.

3. Dodamy obsługę WebM do Firefoksa. Już teraz można pobrać bardzo wczesne kompilacje Firefoksa z obsługą WebM. WebM będzie również obsługiwany przez Google Chrome i Operę.

4. Wszystkie filmy na YouTube zostaną przekodowane do WebM. Dziś w tym formacie YouTube udostępnia około 1,2 miliona filmów, a w najbliższym czasie Google zajmie się przekodowaniem archiwum. Obiecują wspierać wszystko.

5. Nowy format jest wspierany przez wielu partnerów – a nie tylko Google i paru innych. Dostawcy treści – jak Brightcove – zadeklarowali wsparcie WebM jako część kompletnego rozwiązania wideo HTML5. Na liście wspierających WebM firm są producenci sprzętu, dostawcy enkoderów i innych elementów stosu technik związanych z wideo. Także Adobe będzie wspierać WebM we Flashu. Firefox, dzięki swemu udziałowi w rynku i dzięki wartościom, które za nim stoją, oraz YouTube, z największym zasięgiem wśród dostawców wideo, to najważniejsi partnerzy w tym przedsięwzięciu, ale jesteśmy tylko drobną częścią większego ekosystemu wideo.

Cieszymy się niezmiernie widząc, jak Google dołącza do nas, by wspierać Otwarte Wideo. Udostępniają technologię na warunkach spójnych z ideą Otwartego WWW i zasad licencyjnych Royalty-Free W3C. Co najważniejsze, Google zapewnia o całkowitym wsparciu pełnego stosu technologii Otwartego Wideo na największej witrynie z wideo na świecie. Ten ruch całkowicie zmienia krajobraz internetowego wideo, określając nowe podstawy, które inne witryny muszą spełniać, żeby dotrzymać kroku YouTube’owi i nowościom technicznym. Ważne też jest wsparcie ze strony przeglądarek o rosnącym udziale w rynku i popychających naprzód technologię w sieci WWW.

Mozilla zawsze chciała, by wideo na WWW rozwijało się tak szybko, jak reszta WWW. Potrzebna była więc podstawa oparta na otwartej technologii, na której można budować nowe rzeczy. Theora była dobrym pierwszym krokiem, VP8 jest znacznie lepsze. Spodziewajcie się od nas mocnego nacisku na dalsze innowacje związane z wideo. Będziemy rozwijać nowe technologie tak, jak rozwija się WWW, przesuwając się z krańców do środka, dzięki dziesiątkom małych rewolucji, które po połączeniu stają się czymś więcej niż tylko sumą elementów. VP8 to jeden z tych elementów, HTML5 to następny. Jeśli zaglądacie na ten blog (lub moje jego tłumaczenia – przyp. tłum.), zauważycie, jak pojawiają się kolejne kawałki. Sieć WWW pełna jest coraz to nowych technologii, a Firefox jest tutaj liderem. Zamierzamy w dalszym ciągu być w awangardzie rozwoju sieci WWW ponad HTML5, do następnego miejsca, w którym powinna być.

Dziś jest dzień wielkiej zmiany. Jutro będzie kolejny.

Advertisements

WebM – nowy format wideo dla HTML5

Dzisiaj Google we współpracy z Mozillą i Operą udostępniło WebM – nowy format wideo, oparty na:

Wsparcie dla nowego formatu powinno pojawić się w najnowszych conocnych kompilacjach Chromium (testowe wydania Chrome pozbawione części niebędących wolnym oprogramowaniem) i Firefoksa, a wkrótce także w oficjalnych paczkach z Google Chrome z kanału developerskiego i testowym wydaniu Opery.

Co ważne – nowy format wspierany jest także przez YouTube – wszystkie filmy o jakości 720p i lepszej wgrane od dziś na YouTube’a dostępne będą w formacie .webm i odtwarzane przez odtwarzacz oparty na HTML5.

Wśród innych organizacji popierających nowy format są także m. in.: Adobe, projekt Android, Skype, AMD, nVidia, Logitech, Texas Instruments, Freescale Semiconductor, Broadcom – mamy więc tu zarówno firmy software’owe jak i zajmujące się sprzętem. WebM jest więc (na razie potencjalnie) pozbawiony największej wady formatu Ogg Theora – braku silnego wsparcia sprzętowego, a ma wszystkie jego zalety.

Czy dni h.264 są policzone? Mam nadzieję. :-)

Ogg Theora czy h.264 – co wybrali użytkownicy w Polsce

Język HTML 5 wprowadził znacznik <video>, służący do osadzania filmów na stronach internetowych. W pierwotnej wersji specyfikacji znalazł się format Ogg z kodekiem Theora, wskutek protestów m. in. Apple aktualna robocza wersja specyfikacji nie określa formatu wideo.

Przeglądarki z silnikiem Gecko (w tym Firefox 3.5+), a także Opera (aktualnie w wersji beta 10.50) i Google Chrome (od wersji 3, także w opensource’owej wersji – Chromium) obsługują Ogg Theora. Format h.264 z kolei obsługuje jedynie Apple Safari (od wersji 3.2) i Google Chrome (od wersji 3, tylko oficjalne wydania komercyjne Google).

Zobaczmy, jak wsparcie dla obu formatów oraz znacznika <video> HTML5 wygląda pośród polskich użytkowników WWW. Poniżej wykorzystałem dane z najnowszej edycji rankingu gemiusTraffic (za tydzień 15-21.02.10). W danych tych pominięto niektóre przeglądarki w wersjach testowych, w szczególności nie zawierają one liczby użytkowników Firefoksa pre-3.7 i Safari 4.x (gdzie x>0), ale wpływ tego ograniczenia na ogólny błąd w tym zestawieniu jest niewielki.

Jak więc to wygląda?

Liczba odsłon Udział % Ogg H.264
Wszystkie odsłony 7382509245 100
Firefox 3.5 2433559952 32,96 T N
Firefox 3.6 545454889 7,39 T N
Opera 10.50 4622237 0,06 T N
Chrome 3 9653886 0,13 T T
Chrome 4 345356590 4,68 T T
Chrome 5 5791210 0,08 T T
Safari 3.2 1314478 0,02 N T
Safari 4.0 29105252 0,39 N T
Obsługa <video> 3374858494 45,71
Wszystkie Ogg 3344438764 45,3
Wszystkie H.264 391221416 5,3

Przeglądarki obsługujące w ogóle znacznik <video> z HTML 5 generują więc już 45,71% odsłon wszystkich serwisów monitorowanych przez Gemius. Przeglądarki obsługujące HTML 5 oraz format h.264 – jedynie 5,3%, natomiast przeglądarki obsługujące HTML 5 i Ogg Theora – 45,3%.

Wraz z migracją użytkowników do nowszych wersji przeglądarek (w szczególności – z Firefoksa 3.0 do 3.6) oraz po wydaniu finalnej Opery 10.50, udział HTML5+Ogg Theora powinien przekroczyć połowę użytkowników – dzisiaj liczba użytkowników brandów (grup) przeglądarek, których najnowsze wersje obsługują otwarte wideo, przekracza 2/3.

Wkrótce więc zdecydowanej większości użytkowników będzie można serwować filmy bez konieczności korzystania z niestabilnych wtyczek (co gwarantuje nam HTML 5) i bez konieczności ponoszenia opłat licencyjnych (co zapewnia otwarte wideo – format Ogg Theora). Użytkownicy przeglądarek internetowych w Polsce wybrali te, które obsługują lub będą wkrótce obsługiwać otwarty format wideo. Każdy, kto poważnie zajmuje się kwestią multimediów w sieci, powinien zwrócić na to uwagę.

Powtórzmy jeszcze raz: już prawie połowie użytkowników w Polsce można serwować wideo bez konieczności instalowania przez nich wtyczek, jednocześnie zapewniając sobie (czy też własnej firmie) niezależność od producentów wtyczek (Adobe Flash) i opłat licencyjnych (h.264). 1

Widownia dla Theory już jest, czas na dostawców treści! :)


1) Użytkownikom pozostałych przeglądarek można serwować te same filmy w formacie Ogg Theora przy użyciu wtyczek (XiphQT, aplet Javy Cortado) lub Video for Everybody.

Mozilla Hacks: Korzystanie z Web Workers

W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie artykułu Using Web Workers – Working Smarter, Not Harder. Oryginalny artykuł i jego tłumaczenie dostępne są na warunkach licencji Creative Commons Attribution 3.0 USA.


Korzystanie z Web Workers – jak pracować mądrze, a nie ciężko

Autorem tego artykułu jest Malte Ubl, który wykonał sporo dobrej roboty przy użyciu technologii Web Workers w ramach projektu bespin.

W ostatnim czasie aplikacje webowe stały się znacznie bogatsze. Programy działające w przeglądarce, takie jak GMail, Meebo i Bespin pokazują nam, jak WWW będzie wyglądać i zachowywać się w przyszłości. Kluczowym aspektem tworzenia przyjaznej dla użytkownika aplikacji jest wysoka responsywność. Użytkownicy nie lubią czekać, a szczególnie nie lubią sytuacji, w których wydaje się, że program działa, po czym przestaje reagować.

W sercu współczesnych aplikacji WWW po stronie klienta leży język programowania JavaScript. JavaScript wraz z obiektowym modelem dokumentu DOM jest całkowicie jednowątkowy. Oznacza to, że w JavaScripcie tylko jedna rzecz może się zdarzyć w danej chwili. Nawet jeśli komputer ma 32-rdzeniowy procesor, tylko jeden rdzeń będzie zajęty podczas długich obliczeń. Na przykład, obliczając idealną trajektorię lotu na Księżyc nie można jednocześnie renderować animacji, która pokazuje trajektorię w tym samym czasie i nie ma możliwości reagowania na zdarzenia użytkownika, takie jak kliknięcia myszą czy pisanie na klawiaturze podczas obliczeń.

Współbieżność

Dla zachowania responsywności podczas intensywnych obliczeń większość współczesnych języków programowania wykorzystuje współbieżność. W przeszłości do uzyskania współbieżności często wykorzystywano wątki. Klasyczne wątki utrudniają jednakże programiście zrozumienie przebiegu programu, co często prowadzi do trudnych do zrozumienia błędów i chaotycznego zachowania w chwili, gdy różne wątki próbują równocześnie operować na tych samych danych.

Technologia wątków roboczych – Web Workers – zalecana przez WHATWG, pojawiła się w Firefoksie 3.5, pozwalając na wzbogacenie programów w JavaScripcie o współbieżność, unikając problemów związanych z typowymi programami wielowątkowymi. Rozpoczęcie wątku roboczego jest bardzo proste – wystarczy użyć konstruktora new Worker.

W tym przykładzie plik worker.js zostanie wczytany i uruchomiony w nowym wątku, dla niego utworzonym.

// Utwórz wątek roboczy na bazie pliku "worker.js"
var worker = new Worker("worker.js");

Komunikacja między głównym wątkiem interfejsu użytkownika a wątkami roboczymi opiera się na przesyłaniu komunikatów przy użyciu metody postMessage. Metoda ta została dodana do Firefoksa 3 by zapewnić komunikację między oknami. Aby przesłać komunikat z wątku roboczego do strony, wystarczy użyć tej metody:

// Wyślij komunikat do głównego wątku UI
postMessage("Witaj, strono!");

Aby odebrać wiadomość od wątku roboczego, na obiekcie typu Worker należy określić procedurę obsługi zdarzenia “onmessage”. Tutaj po prostu wyświetlimy dane zdarzenia, przekazane do tej procedury. W naszym przypadku własność “event.data” zawiera tekst “Witaj, strono!”, przesłany powyżej.

worker.onmessage = function (event) {

  alert(event.data);
  // Wyślij wiadomość do wątku roboczego
  worker.postMessage("Witaj, wątku!");

}

Do wysłania komunikatów do wątku roboczego wywołujemy metodę postMessage na obiekcie wątku. Aby odebrać te komunikaty w wątku, należy zdefiniować funkcję onmessage, która będzie wywoływana po każdym przesłaniu do niego komunikatu.

Obsługa błędów

Istnieją dwa sposoby obsługi błędów czasu wykonania w wątku. Po pierwsze, wewnątrz wątku można zdefiniować funkcję onerror. Po drugie, można obsłużyć błędy z zewnątrz wątku, przypisując procedurę onerror obiektowi typu Worker:

worker.onerror = function (event) {

  alert(event.message);
  event.preventDefault();
}

Metoda event.preventDefault() zapobiega wykonaniu domyślnej operacji, którą byłoby tutaj wyświetlenie błędu użytkownikowi lub wypisanie jej w konsoli błędów. Zamiast tego, w tym miejscu wyświetlmy treść błędu w oknie powiadomienia.

Brak współdzielenia

Wątki robocze nie dzielą żadnych stanów ze stroną, z którą są powiązane, ani z żadnymi innymi wątkami roboczymi; jedyną możliwą interakcją jest przesyłanie komunikatów przy użyciu metody postMessage. Wątki robocze nie mają dostępu do DOM, nie mogą więc manipulować stroną WWW. W ten sposób nie ma żadnego ryzyka dla integralności danych w sytuacji, gdy wiele wątków chce równocześnie operować na tych samych danych.

Typowe wykorzystanie wątków roboczych składa się ze strony-komponentu JavaScript, oczekującej na zdarzenia użytkownika. Kiedy nastąpi zdarzenie wywołujące intensywne obliczenia, do wątku roboczego przesyłany jest komunikat, który powoduje rozpoczęcie obliczeń. Skrypt na stronie może jednak natychmiast powrócić do oczekiwania na dalsze zdarzenia. W momencie, gdy wątek roboczy skończy pracę, przesyła wiadomość do strony, która może wówczas np. wyświetlić wyniki.

nigdy-wiecej
Ostrzeżenie przed nieresponsywnym skryptem, wyświetlane przez przeglądarki, gdy skrypt wykonuje się zbyt długo, odchodzi w przeszłość dzięki wątkom roboczym.

Przykład – ciąg Fibonacciego

W kolejnym przykładzie wątek roboczy oblicza w tle liczby Fibonacciego od 0 do 99. W rzeczywistości, ponieważ obliczanie liczb Fibonacciego tą nieefektywną
metodą może trwać długo przy większych liczbach (np. większych niż 30), skrypt może nawet nigdy nie zakończyć się na komputerze (albo „wyłożyć sie” z powodu przepełnienia stosu), ale ponieważ dzieje się to w wątku roboczym, nie ma to żadnego skutku co do responsywności strony. Można więc nadal wyświetlać skomplikowaną animację, by uprzyjemnić oczekiwanie na kolejną liczbę.

Poniższa strona HTML zawiera skrypt uruchamiający wątek roboczy z pliku „fib-worker.js”. Komunikaty z wątku roboczego wyświetlane są w konsoli przeglądarki (czy raczej Firebuga – przyp. tłum.) przy użyciu console.log.

<!DOCTYPE html>
<html>
    <head>
      <title>Web Worker API Demo</title>
      <script type="text/javascript">

        var worker = new Worker("fib-worker.js");
        worker.onmessage = function (event) {
          console.log(event.data.index +" -> " + event.data.value)
        }
      </script>  
    </head>
    <body>
    </body>

</html>

Plik JavaScript z implementacją wątku roboczego zawiera pętlę, która wylicza liczby Fibonacciego i przesyła wyniki do strony.

// Plik fib-worker.js
function fib(n) {

   return n < 2 ? n : fib(n-1) + fib(n-2);

}
 
for(var i = 0; i < 100; ++i) {

   postMessage({
      index: i,
      value: fib(i)

   })
}

W powyższym przykładzie widać też, że przy użyciu postMessage można przesyłać złożone obiekty. Obiekty takie mogą zawierać wszystko to, co można przesłać w formacie JSON. Oznacza to, że nie można przesłać funkcji, a obiekty przekazywane są przez wartość, a nie przez referencję.

API wątków roboczych

Wątki robocze obsługują funkcję o nazwie importScripts. Dzięki niej można wczytać do wątku roboczego więcej plików źródłowych.

importScripts("file.js");

importScripts("foo.js", "bar.js");

Jeśli funkcja zostanie wywołana z wieloma argumentami, skrypty zostaną pobrane równolegle, ale wykonane w kolejności zdefiniowania. Funkcja ta jest blokująca – bieg wątku zostanie wstrzymany do momentu pobrania i wykonania wszystkich skryptów.

W kolejnym przykładzie wczytujemy zewnętrzny plik JavaScript, który oblicza wartość funkcji SHA-1 z ciągów znaków, a następnie wykorzystujemy go do wyliczania wartości SHA-1 dla zawartości odczytanej poprzez żądanie AJAX. Używamy tu standardowego obiektu XMLHttpRequest do pobrania zawartości z adresu URL przekazanego do zdarzenia onmessage. Co ciekawe, nie musimy budować tutaj asynchronicznego żądania AJAX, jako że wątek sam w sobie jest asynchroniczny względem strony, tak więc oczekiwanie na żądanie HTTP nie jest tu żadnym problemem.

importScripts("sha1.js")
 
function onmessage(event) {
    var xhr = new XMLHttpRequest();

    xhr.open('GET', event.data, false);
    xhr.send();

    postMessage(sha1(xhr.responseText));
}

Inne API dostępne dla wątków roboczych

Wątki mogą używać XMLHttpRequest do żądań AJAX, jak w powyższym przykładzie, jak również mają dostęp do bazy danych po stronie klienta dzięki API Web Storage. API te w wątkach roboczych są takie same jak w „zwykłym” JavaScripcie.

Funkcje setTimeout i setInterval (oraz clearTimeout i clearInterval) są dostępne, co pozwala na wykonywanie kodu po upływie danego czasu lub co pewien interwał. Dostępny jest też obiekt navigator object, udostępniający informacje o przeglądarce.

Dodatkowe API mogą zostać dodane w przyszłości.

Zgodność z przeglądarkami

W momencie pisania tego artykułu, o ile wiadomo jego autorowi, tylko Firefox 3.5 obsługuje możliwość przesyłania złożonych obiektów poprzez postMessage i implementuje rozszerzone API opisane powyżej. Safari 4 zawiera prostą implementację API Worker. W innych przeglądarkach można korzystać z Workers poprzez wtyczkę Google Gears, w której technologia ta pojawiła się na początku.

Przykład wykorzystania na prawdziwej stronie

W ramach projektu Bespin, opartego na przeglądarce edytora kodu źródłowego, z powodzeniem wykorzystujemy wątki robocze do implementacji intensywnych dla procesora funkcji, takich jak sprawdzanie poprawności kodu na bieżąco czy podpowiadanie kodu. Stworzyliśmy także nakładkę, implementującą API Worker w ramach Google Gears, która także dodaje brakującą funkcjonalność w Safari 4, a także umożliwiliśmy korzystanie ze transparentnych zdarzeń własnych, na bazie interfejsu postMessage. Komponenty te zostaną upublicznione jako odrębna biblioteka, do wykorzystania przez inne projekty.

Technologia Web Workers odgrywa istotną rolę w próbie uczynienia z Otwartej Sieci WWW jeszcze potężniejszej platformy dla złożonych programów. Jako że wszystko, co robią wątki robocze, to wykonywanie JavaScriptu, łatwo jest napisać skrypty, które działają także w przeglądarkach nie zapewniających luksusu wątków roboczych. Polecamy dodanie Web Workers do Twoich programów, aby stały się bardziej responsywne i przyjemniejsze w użyciu.

Przełom nadchodzi? :)

W najnowszym rankingu GemiusTraffic MSIE wyprzedza przeglądarki oparte na Gecko tylko o 0,9 punkta procentowego:

obrazek-11

Firefox we wszystkich wersjach ma łącznie 44,7% (sam Firefox 3: 38.4%), Opera – 7,7%, wszystkie WebKitopodobne – 1,2% (z tego większość ma Chrome – 0,8%). MSIE 7 nieco wyprzedza swojego starszego brata – o 0,8 pkt proc. (23,3% do 22,5%).

Czy w przyszłym tygodniu IE zasłużenie utraci prowadzenie? Zobaczymy. Fajnie by było. :-)

MDN

Better JavaScript docs for a better Web on MDN

Archiwum