Na początek, krótka historia. Pewnego razu zostałem poproszony, aby umieścić wideo w tle strony klienta. Pomyślałem: „Task jak task, będzie easy”. Pierwsze wersje widea hulały nawet lokalnie i zwykły loader spełniał swoje wymagania. Z tym, że wideo trwało zaledwie 8 sekund, puszczane było w pętli i wszystko działało perfekcyjnie.

Oczywiście wszystko co dobre kiedyś się kończy. Klient wysłał nowe wideo do wstawienia. Było pięciokrotne dłuższe, a kompresja bezstratna wiele nie dała. Kolorystyka i efekty sprawiały, że kompresja stratna doprowadzała do zbyt dużych blurów.

Rozwiązaniem był oczywiście stream wideo z YouTube’a lub Vimeo. Background musiał ładować się na każdym urządzeniu (z wyłączeniem komórek, o tym później), o każdej możliwej prędkości internetu. Dlaczego wybrałem właśnie Vimeo API i dlaczego urzekło mnie swoimi możliwościami, o tym właśnie będzie ten krótki poradnik.

Efekty działania kontroli filmu z VimeoApi, można zobaczyć na matchbeta.pl i toggl.com. W obu przypadkach wideo jest przykryte przez zdjęcie będące pierwszą klatką wideo, które znika w momencie wywołania funkcji wykrycia działania wideo.

Na początek potrzebujemy dwóch rzeczy: kodu embed filmu na vimeo, a także player.js. Po podpięciu skryptu, dodajmy do strony iframe z filmem:

<iframe
 id="bgvid"
 src="https://player.vimeo.com/video/202214153?api=1&autoplay=1&loop=1&color=00000&title=0&byline=0&portrait=0;player_id=bgvid"
 frameborder="0">
 </iframe>

Na początek kilka słów o samym src tego iframe’a. Początek raczej nie wymaga zbyt dużego tłumaczenia, „przedrostek” player, a także następujące po „video” cyfry, oznaczają, iż jest to właśnie embedowane video, pochodzące z serwisu vimeo.com. Kolejne elementy są ciekawsze.

  • Api=1 – wykorzystanie sterującego tym video Player.js
  • Autoplay=1 – automatyczny start filmu
  • color=#000000 – kolor tła
  • title=0 – zablokowanie wyświetlania tytułu filmu
  • player_id=bgvid – przypisuje do tego konkretnego playera, konkretne id, najlepiej jest ustawić identyczne jak całego iframe’a

Reszta atrybutów jest mniej ważna.

CSS

Umiejscowienie iframe’a, a także jego konkretne atrybuty zależą poniekąd od formatu video. Aby zniwelować „czarne pasy” po lewej i prawej stronie odtwarzacza, należy dodać poniższy kod CSS:

#bgvid {
  display: block;
  position: absolute;
  top: 0;
  left: 0;
  width: 105%;
  height: 350%;
  z-index: -999;
  transform: translateY(-35%);
  background: #000;
}

Pozycja absolutna lub fixed – wybór jest Wasz. W przykładzie, na którym się wzoruję, wykorzystałem absolute, głównie „dzięki” słabemu działaniu przyklejonego wideo na IE11. Skąd zatem ta dziwna szerokość i wysokość można by zadać pytanie…

W skrócie: uzyskałem ją metodą prób i błędów, okazało się, że dla takich wartości znikają wszelkie problemy takie jak czarne paski i tym podobne. Musimy bowiem pamiętać, że bezpośrednio w wideo ingerencji nie mamy, jedynie na „wyświetlacz” playera, a także na sygnały/komunikaty, które nam wysyła.

Kolejną rzeczą, której potrzebujemy jest pierwsza klatka filmu. Pobieramy ją po prostu screenshotem, a następnie ustawiamy jako background-image na elemencie kryjącym, który koniecznie musi mieć z-index o 1 mniejszy.

#vidWrapper {
  background: url(../img/screenshot.jpg) no-repeat center center fixed;
  overflow: hidden;
  display: block;
  -webkit-background-size: cover;
  -moz-background-size: cover;
  -o-background-size: cover;
  background-size: cover;
  min-height: 100%;
  min-width: 1024px;
  z-index: -99;
  width: 100%;
  height: auto;
  position: fixed;
  top: 0;
  left: 0;
}

Element div oznaczony jako #vidWrapper jest zwykłym divem, posiadającym background typu cover.

Końcowy HTML wygląda w ten sposób:

<div id="#widWrapper"></div>
<iframe
 id="bgvid"
 src="https://player.vimeo.com/video/202214153?api=1&autoplay=1&loop=1&color=00000&title=0&byline=0&portrait=0;player_id=bgvid"
 frameborder="0">
 </iframe>

Na koniec pozostała oczywiście kontrola tego wszystkiego. Minimalny skrypt, dzięki któremu wszystko będzie działać:

var iframe = document.querySelector('iframe');
var player = new Vimeo.Player(iframe);
var refreshIntervalId = setInterval(function(){
  player.getCurrentTime().then(function(seconds) {
    if(seconds > 1) {
      $('#vidWrapper').fadeOut(500);
      clearInterval(refreshIntervalId);
    }
  });
}, 200);

Na początek do znalezionego w DOM’ie iframe’a przypinamy łatkę „Playera”. Następnie w postępującym co 200ms intervale, sprawdzamy w jakim momencie znajduje się odtwarzanie filmu w playerze. Dlaczego akurat ten sposób? Ponieważ okazał się być najbardziej efektywny. Inne metody znalezione w dokumentacji Player.js, pozostawiały zawsze to drobne „ale”. Działały, ale było np. widać przez ułamek sekundy czarne tło. Ten sposób eliminuje taką możliwość nawet na komputerach ze słabym łączem internetowym.

Słowem zakończenia dodam, że należy pamiętać o wyłączeniu wideo w tle dla mobile’ów, a nawet dla tabletów. W jego miejsce można ustawić zwykłe zdjęcie.

Jeśli ktoś jest zainteresowany tematem tego typu kontroli, to proszę o zadawanie pytań. W przypadku dużego zainteresowania nie omieszkam napisać kolejny artykuł 🙂

Pobierz paczkę z plikami.

 

Ten artykuł jest wpisem gościnnym. Uważasz, że znasz bardzo dobrze jakiś temat związany z Web Developmentem i chciałbyś się podzielić wiedzą? Napisz na kontakt@devcorner.pl.

  • Brudka

    Sama prawda, 200 ms też polecam przy sterowaniu video przykładowo po mp4.
    A to dlatego, że nawet ustawiając „currentTime” player musi „złapać” klatkę kluczową i by przykładowo nie było przeskoku albo flasha początku animacji musimy odczekać minimum te 200 ms by sobie już tą klatkę załadował.
    Robiłem taki skrypt, który puszczał video „do przodu” i „do tyłu” oraz pauzował w odpowiednim momencie i właśnie to jest jedyny sposób na wyeliminowanie tego zjawiska. 🙂

    • Krzysiek Wąsowicz

      Dokładnie stanąłem przed tym problemem, dlatego currentTime uznałem za sposób idealny. Tym bardziej byłem zdziwiony, że nawet na git’ie player.js’a nie „forsują” tego sposobu. Ale cieszę się, że się ze mną zgadzasz 🙂

      • Brudka

        Dokładnie 🙂
        To jak już wałkujemy klatki kluczowe 😉 nie polecam stosować webm jako formatu wideo dla html5. Zdecydowanie lepszym jest mp4. Strumieniowanie webm to jakaś totalna pomyłka, nawet przy lokalnym źródle skok przez currentTime trwa do dwóch sekund, oczywiście wypluwając przy tym stosowną ikonę ładowania. 😉 Przy zastosowaniu mp4 temat nie istnieje, skok jest natychmiastowy. Jedyną bolączką są wtedy te wspomniane nieszczęsne klatki kluczowe. 😉

        • Krzysiek Wąsowicz

          Wemb jest najlepszy jak się o nim nie mówi 😛 Testowałem różne formaty i faktycznie mp4 najlepiej działało z lokala, aczkolwiek trzeba go ładnie skompresować, żeby dobrze działał też na słabszym połączeniu internetowym. Gorzej to wygląda na macach i ogólnie jabłkach, ale tam stosowało się ogv bodajże i też dobrze działało 🙂

          • Brudka

            A to dobrze wiedzieć. 🙂
            No ja miałem przyjemność robić interfejs pod raczej lokalne zastosowanie. Po prostu JS był tylko api dla obsługi i stworzenia interfejsu prezentacji. I wtedy wyszły bolączki webm. Myślałem, że jako format webowy pozwoli wyeliminować problem klatek kluczowych i problemu flashowania – efekt był porażający, ale w drugą stronę 😉
            Więc pozostałem przy mp4 z .delay(200) w jquery. 😉
            Ale trzeba będzie też obadać i ogv. 🙂