Wymagania techniczne

Pytania ogólne

Wszystko na naszej platformie działa w przeglądarce, więc wymagania są cztery. Wspierany system operacyjny, aktualna przeglądarka, wystarczające pasmo i sieć, która przepuszcza nasz ruch. Wszystkie cztery są w porządku, a coś i tak nie działa? Wtedy zajrzyj na koniec strony, gdzie czeka lista kontrolna usterek.

Wspierane systemy operacyjne

Prowadzący i uczestnicy mogą korzystać z każdego znanego systemu operacyjnego, w tym z macOS, iOS, iPadOS, Microsoft Windows, Linuksa, Chrome OS i Androida. Platformę sprawdziliśmy na wszystkich.

Ograniczenie jest jedno. W Linuksie nie działa pokaz ekranu i niedostępna jest nasza bezpieczna alternatywna technologia transmisji na TCP. Reszta zachowuje się tak samo jak na innych systemach.

Przeglądarki

Uczestnicy wchodzą na wydarzenia z każdej dużej przeglądarki, w tym z Safari, Microsoft Edge, Mozilla Firefox, Google Chrome i Opery.

Prowadzącym radzimy Google Chrome albo dowolną przeglądarkę na Chromium, na przykład Brave. Chrome trzyma jakość strumienia wychodzącego równo, a odpowiada za to technologia simulcast. Daje też najpewniejsze połączenie po protokole WebRTC na UDP i przez naszą wtyczkę na TCP. Safari, Firefox, Opera i Edge też są sprawdzone i działają poprawnie.

Którąkolwiek przeglądarkę wybierzesz, trzymaj ją aktualną. Minimum to Chrome 60, Firefox 71, Safari 12, Edge 79 i Opera 60, a wszystko starsze pokoju webinarowego nie otworzy wcale. Aktualizuj dzień przed wydarzeniem, a nie pięć minut przed wyjściem na antenę.

Wszyscy, którzy mówią jednocześnie, muszą mieć jedną przeglądarkę i jedną jej wersję. Chrome i Firefox gaszą echo inaczej. Jeden prowadzący siedzi w pierwszej, drugi w drugiej, i obaj słyszą echo własnego mikrofonu, kiedy mówią razem. Ustal jedną przeglądarkę ze współprowadzącymi zawczasu.

Telefony i tablety

Platforma jest zoptymalizowana pod telefony i tablety, w tym iPhone, iPad i urządzenia na Androidzie. Wejdź na wydarzenie, czy to prowadzącym, czy uczestnikiem, przez Safari na iPhonie i iPadzie albo przez Google Chrome na Androidzie.

Instalować nie trzeba nic. Aplikacji mobilnych ani tabletowych nie wydajemy, bo w przeglądarce i tak wszystko działa. Siły włożyliśmy w co innego, żeby platforma zachowywała się przyzwoicie na małym ekranie.

A nadawać kamerę, mikrofon czy ekran lepiej jednak z komputera stacjonarnego albo laptopa. Dotyczy to każdego, kogo zaprosisz do pokazania prezentacji. Na dowolnym urządzeniu, przy zdrowym łączu, uczestnik mieści się w tym samym zakresie co prezenterzy, od 100 do 600 ms, a granice starszej przeglądarki albo starszego sprzętu rozciągają to do kilku sekund, w najgorszym razie do trzech albo siedmiu.

Transmisja adaptacyjna

Mamy własną implementację adaptacyjnego protokołu transmisji z pełnym trybem zgodności. To właśnie ona dostarcza dźwięk i wideo tym, którzy siedzą w restrykcyjnej sieci, na starszym urządzeniu albo w rzadszej przeglądarce. Włącza się sama, we wszystkich stałych pokojach webinarowych i na zaplanowanych wydarzeniach. Czego nie umie, to wymyślić pasma. Zbyt wolne albo zbyt niestabilne łącze i tak odbierze uczestnikowi obraz, a potem i transmisję. Sposoby na to zebrał artykuł co robić, gdy wideo zamiera albo uczestników wyrzuca.

Protokół nie opiera się na WebRTC i w większości przypadków wystarcza mu jeden port TCP 443. Dzięki temu dźwięk i wideo prowadzącego docierają do wnętrza sieci firmowych, gdzie UDP jest zamknięty. Przechodzą też przez najbardziej znane serwisy VPN. To ten sam transport, z którego korzysta wtyczka DTS, gdy pokój przełącza się ręcznie, więc opóźnienie mieści się w tym samym zakresie co przesyłanie przez przeglądarkę. Sam strumień pozostaje stabilny i ciągły jak zwykle.

Sprawdź sprzęt przed wydarzeniem

Zamierzasz poprowadzić wydarzenie i mówić na nim? Sprawdź sprzęt zawczasu. Nasz tester połączenia w kilka minut sprawdzi internet, przeglądarkę, porty i urządzenia.

Kroków jest siedem i większość z nich po prostu zadaje zrozumiałe pytanie, zamiast decydować za ciebie. Dobry wynik to zielony ptaszek przy każdej pozycji na ostatnim ekranie. Wszystko gorsze wskazuje na niestabilną sieć albo na urządzenie, które zawiedzie w dniu transmisji, zwykle na kamerę lub mikrofon. Spróbuj innej sieci, innej przeglądarki albo kabla zamiast Wi-Fi, a przeczytaj też rozdział o firewallu niżej.

Czyste przejście wygląda tak.

Krok 1: Uruchomienie sprawdzenia sprzętu

Ekran startowy testera połączenia z przyciskiem uruchomienia

Krok 2: Sprawdzenie potrzebnych otwartych portów i dostępnych protokołów

Tutaj naraz idą cztery sprawdzenia, czyli internet, porty, protokoły i WebRTC, a tester pyta, czy przy każdym stoi zielony ptaszek.

Tester pokazuje, że internet, porty, protokoły i WebRTC są zaliczone

Krok 3: Sprawdzenie łączności i prędkości internetu

Wskazówka zatrzymuje się po kilku sekundach, a ważne są dwie liczby pod nią, pobieranie po lewej i wysyłanie po prawej.

Tester pokazuje zmierzoną prędkość pobierania i wysyłania

Krok 4: Sprawdzenie kamery

Wybierz kamerę z listy, jeśli właściwa nie ustawiła się sama. Opcja «Odbicie lustrzane wideo» ("Mirror video") odwraca tylko twój podgląd, a uczestnicy zobaczą wszystko tak jak było.

Tester wyświetla podgląd z kamery, żebyś potwierdził jej działanie

Krok 5: Sprawdzenie mikrofonu

Powiedz coś. Linia powinna drgać w takt głosu.

Tester pokazuje, jak poziom mikrofonu odpowiada na głos

Krok 6: Sprawdzenie poziomu głośności głośników

Tester odtwarza próbny dźwięk, żebyś potwierdził działanie głośników

Krok 7: Zielony ptaszek przy każdym kroku

Końcowy ekran testera, gdzie wszystkie pięć sprawdzeń zaliczono i oznaczono zielenią

Na końcowym ekranie napisano jeszcze raz, jaka kamera i jaki mikrofon brały udział. Warto na to zerknąć, jeśli komputer ma po kilka jednych i drugich.

Prędkość łącza

Żeby wejść do stałego pokoju webinarowego albo na zaplanowane wydarzenie, potrzeba minimum 256 Kb/s w każdą stronę.

Prowadzącemu z kamerą i mikrofonem potrzeba około 1,6 Mb/s na wysyłanie, a z pokazem ekranu albo wideo około 3,2. Uczestnikowi pasmo potrzebne jest na każdego prelegenta na antenie, bo każdy przychodzi osobnym strumieniem. Dlatego liczba rośnie razem z wielkością twojego zespołu, a nie stoi w miejscu. Prelegent po prelegencie wylicza to artykuł prędkość internetu dla pokoju webinarowego. Gdy pasma brakuje, nasz program najpierw obniża jakość wideo, a dźwiękowi daje pierwszeństwo.

Prędkość to tylko połowa sprawy. Stabilność łącza liczy się tak samo, a zależy od tego, ile osób dzieli z tobą linię. Niestabilny kanał gubi pakiety w trakcie spotkania, a ty słyszysz to jako drżenie i przerwy w dźwięku. Gdzie się da, bierz kabel zamiast Wi-Fi, a domowników albo zespół poproś, żeby nie ściągali ciężkich plików w czasie wydarzenia.

Stare maszyny dokładają własne ograniczenia. Wolny procesor albo wolny dysk pociągną wydarzenie w dół nawet na szybkim łączu.

Ustawienia firewalla

Każdy, kto wychodzi na antenę, nadaje po protokole WebRTC. Stoi on na UDP i działa niemal w każdej sieci. Sieci firmowe z restrykcyjnym firewallem potrzebują czasem dodatkowej konfiguracji, i tę część oddaj swojemu działowi IT. Z uczestnikami, którzy tylko oglądają, jest prościej, o nich na końcu rozdziału.

Dopisz do listy dozwolonych te domeny.

  • *.myownconference.com
  • *.mywebinar.com
  • *.mywebinar.io

I te porty.

  • Porty UDP od 1025 do 65535
  • Porty TCP 80 i 443

Dla jakości dźwięku i wideo wolimy UDP, i domyślnie pracujemy właśnie na nim. Ten protokół ceni czas dostarczenia wyżej niż jego pewność, a ludzki słuch działa tak samo. Mózg łata drobne dziury niepostrzeżenie, a opóźnienie zauważa od razu. Dla najlepszego wyniku otwórz porty UDP od 1025 do 65535.

Zakres UDP potrzebny jest tylko tym, którzy nadają. Uczestnik, który ogląda i słucha, dostaje wszystko po zwykłym HTTPS na TCP 443. Więc jeśli dział IT otwiera drogę samej publiczności, cała prośba sprowadza się do portu 443.

Siedzisz za bezpieczną siecią firmową, pracujesz pod ostrymi wymogami bezpieczeństwa albo firma trzyma korporacyjny VPN? Wtedy zainstaluj naszą wtyczkę na TCP do alternatywnej technologii transmisji. Omija ona drżenie i zgubione kawałki dźwięku, o których mowa wyżej. Dokłada też dwa regulatory dźwięku, jakich droga przez przeglądarkę nie ma. Pokazuje je i objaśnia jakość dźwięku na webinarach. Najczęściej jednak nie ma czego włączać, bo adaptacyjny protokół włącza się samoczynnie dla stałych pokoi i zaplanowanych wydarzeń, a całą tę trasę omawia transmisja z sieci firmowej.

Dostarczanie maili

Poproś swojego dostawcę poczty albo system zarządzania pocztą, żeby zezwolił na domeny poniżej. Dzięki temu wiadomości platformy naprawdę dojdą do uczestników.

  • *.myownconference.email
  • *.myownconference.com
  • *.mywebinar.com

Co robić, gdy nie działa

Wszystko zrobione, a coś nadal jest nie tak? Przejdź listę dla swojej roli.

Dla prowadzącego albo prelegenta.

  • Najpierw uruchom tester połączenia i prześlij nam wynik przez widżet wsparcia online.
  • Strumień wideo z kamery nie rusza po jakimś czasie? Może tną go ustawienia routera. Zrestartuj domowy router i komputer.
  • Nie pomogło? Poproś dział IT, żeby odblokował protokół WebSocket wss://, protokół WebRTC i port 443 do przesyłania wideo i dźwięku. Pełna lista leży w rozdziale o firewallu wyżej.

Dla uczestnika.

  • Nie widać albo nie słychać wydarzenia? Wyłącz kamerę prowadzącego.
  • Nic się nie zmieniło? Uruchom tester połączenia i prześlij nam wynik przez widżet wsparcia online.
  • I znowu bez skutku? Poproś dział IT, żeby odblokował WebSockety i port TCP 443. Dla widza to cała lista, bo wszystko, co przychodzi do uczestnika, idzie tym samym portem co zwykła strona.
  • A tymczasem spróbuj wejść z innej sieci, na przykład z komórkowego 3G albo LTE.

Nic nie pomogło? Napisz na czacie online i podaj system operacyjny, przeglądarkę z wersją oraz krok testera, na którym wszystko stanęło.

Często zadawane pytania

Dział IT otworzy porty tylko dla publiczności. Czego im trzeba?

Portu TCP 443, i to cała prośba. Uczestnik, który ogląda i słucha, dostaje wszystko po zwykłym HTTPS na tym porcie, tym samym, którym chodzi każda strona. Zakres UDP potrzebny jest tylko tym, którzy nadają. Przy okazji poproś o odblokowanie WebSocketów i domen *.myownconference.com, *.mywebinar.com oraz *.mywebinar.io.

Czy da się prowadzić webinar z Linuksa?

Tak, z dwoma zastrzeżeniami. W Linuksie nie działa pokaz ekranu i niedostępna jest nasza bezpieczna alternatywna technologia transmisji na TCP. Reszta zachowuje się jak na innych systemach, kamera i mikrofon pracują jak zwykle. Musisz wyprowadzić prezentację na ekran? Oddaj tę część współprowadzącemu na dowolnym innym wspieranym systemie.

Czy współprowadzący muszą siedzieć w tej samej przeglądarce co ja?

Tak, i w tej samej wersji, jeśli mówicie jednocześnie. Chrome i Firefox gaszą echo inaczej. Jeden prowadzący siedzi w pierwszej, drugi w drugiej, i obaj słyszą echo własnego mikrofonu. Ustalcie jedną przeglądarkę zawczasu, a prowadzącym radzimy Google Chrome albo dowolną przeglądarkę na Chromium, na przykład Brave.

Czy jest aplikacja na telefon albo tablet?

Nie, instalować nie trzeba nic. W przeglądarce i tak wszystko działa, dlatego aplikacji mobilnych ani tabletowych nie wydajemy. Na iPhonie i iPadzie bierz Safari, na Androidzie bierz Google Chrome, i nieważne, czy wchodzisz prowadzącym, czy uczestnikiem. A nadawać kamerę, mikrofon czy ekran lepiej jednak z komputera stacjonarnego albo laptopa.

Ile pasma potrzeba uczestnikowi, gdy na antenie jest kilka osób?

Liczba rośnie razem z wielkością zespołu, a nie stoi w miejscu, bo każdy prelegent na antenie przychodzi osobnym strumieniem. Dolna granica wejścia do stałego pokoju webinarowego albo na zaplanowane wydarzenie to 256 Kb/s w każdą stronę. A pasmo, prelegent po prelegencie, wylicza artykuł prędkość internetu dla pokoju webinarowego. Gdy pasma brakuje, nasz program najpierw obniża jakość wideo, a dźwiękowi daje pierwszeństwo.

Zacznij już dziś

Gotowy na webinary, które naprawdę konwertują?

Pomagamy prowadzić webinary od 2013 roku. Start jest całkowicie darmowy

Darmowy plan na zawsze • Bez karty kredytowej • Gotowe w 2 min