Dual PC do streamingu przy 240 Hz brzmi jak proste lekarstwo na mikroprzycięcia i spadki płynności, ale przed zakupem drugiego komputera pojawiają się pytania, które realnie decydują o efekcie końcowym: czy problemem jest spadek FPS, czy skaczący frametime? Czy to enkoder zabija płynność, czy kompozycja scen w OBS? Czy dołożenie toru przechwytu nie dorzuci opóźnienia albo nie „zablokuje” monitora do 120/144 Hz?
Jeśli grasz kompetetywnie i celujesz w stabilne 240 klatek (a nie tylko „czasem 240 FPS”), dual PC ma sens wtedy, gdy drugi komputer przejmie to, co najczęściej miesza w frametime: kodowanie, kompozycję scen, źródła przeglądarkowe, nagrywanie, pluginy, alerty. Natomiast źle dobrana architektura (np. nieprzemyślane klonowanie ekranu) potrafi przynieść efekt odwrotny: dodatkowe problemy z EDID, VRR, przełączaniem trybów pełnego ekranu, a nawet gorszą responsywność.
Żeby trzymać się praktyki, przyjmijmy dwa cele: (1) PC do gry ma być „czysty” i stabilny pod 240 Hz, (2) PC streamingowy ma zapewnić stabilny stream 1080p60 bez gubionych klatek i bez rozjechanego audio. Poniżej znajdziesz decyzje i ustawienia, które najczęściej robią różnicę — z kontrastem rozwiązań, konsekwencjami i pułapkami.
dual PC streaming 240 Hz, karta przechwytująca PCIe vs USB, HDMI passthrough 240 Hz, OBS render lag encode lag, frametime microstutter, klonowanie ekranu EDID, NDI streaming opóźnienie, audio routing Voicemeeter, NVENC AV1 x264 preset, 1080p60 ustawienia OBS, HDCP czarny ekran
Dual PC przy 240 Hz: kiedy to ma sens, a kiedy szkodzi
Pytania decyzyjne, które warto sobie zadać przed rozbudową
Najpierw trzeba rozdzielić dwie rzeczy, które gracze często wrzucają do jednego worka: spadki FPS i skoki frametime. Spadek FPS zobaczysz jako wyraźny zjazd z 240 do np. 170–200, zwykle w ciężkich momentach gry. Skoki frametime to coś innego: licznik FPS może nadal pokazywać „wysoko”, ale obraz robi się „szarpany”, bo klatki nie przychodzą w równych odstępach. Streaming na single PC potrafi wywołać właśnie ten drugi problem — szczególnie gdy OBS, przeglądarka z alertami, pluginy albo nagrywanie powodują krótkie „piki” obciążenia GPU/CPU.
Drugie pytanie: czy problem pojawia się tylko podczas streamu/nagrywania? Jeśli bez OBS gra jest idealnie płynna, a po uruchomieniu streamu zaczynają się mikroprzycięcia, to jest mocny sygnał, że walczysz nie z samą grą, tylko z dodatkowym obciążeniem renderu/enkodera/kompozycji. Wtedy dual PC ma największy sens, bo przenosi „bałagan” multimedialny na drugi komputer.
Trzecie pytanie jest niewygodne, ale kluczowe: czy Twój setup streamowy jest prosty? Jeśli masz jedną scenę, mało źródeł i używasz sprzętowego enkodera (NVENC/AMF/QSV) w rozsądnych ustawieniach, single PC potrafi działać świetnie. Dual PC zaczyna wygrywać wtedy, gdy scena jest ciężka (wiele browser sources, animacje, filtry na kamerze i mikrofonie, przejścia, pluginy), a gra jest GPU-bound i wrażliwa na drobne skoki obciążenia.
Co realnie znika z PC do gry po przejściu na dual PC, a co zostaje
Największy zysk z dual PC to to, że PC do gry przestaje zajmować się kodowaniem i miksowaniem produkcji. Przy single PC to nie tylko sam enkoder, ale też render sceny OBS, kompozycja źródeł, filtry, przechwytywanie, a często również przeglądarka (alerty, chat, dashboard). Nawet jeśli enkoder jest sprzętowy, OBS nadal „dotyka” GPU i CPU, a to potrafi zaburzyć frametime w grach, które są wrażliwe na wahania.
Jednocześnie dual PC nie usuwa z komputera do gry tego, co jest sednem: renderowania gry, sterowników, zarządzania energią, overlayów, a czasem także kosztów związanych z klonowaniem wyświetlacza lub przechwytem obrazu. Jeśli wybierzesz architekturę „clone/duplicate”, PC do gry nadal będzie obsługiwał drugi „monitor” logiczny, co w niektórych układach potrafi wpływać na VRR/pełny ekran i zachowanie odświeżania.
W praktyce najlepszy efekt daje podejście: PC gamingowy ma być jak konsola — minimalna liczba procesów w tle, brak przechwytywania, brak nakładek, brak przeglądarki, brak Discorda w wersji z akceleracją, a najlepiej także brak OBS. Wszystko, co związane z produkcją, idzie na PC streamingowy.
Koszty i ryzyka: gdzie dual PC potrafi „ukąsić”
Dual PC wnosi trzy typowe ryzyka. Pierwsze to opóźnienie w torze wideo lub audio, jeśli zaczniesz grać z podglądu w OBS albo wymusisz nieoptymalny sposób przechwytywania. Drugie to problemy EDID/HDCP, czyli sytuacje, w których komputer lub karta przechwytująca „dogadują się” na złe parametry sygnału (zła rozdzielczość, niższe odświeżanie) albo w ogóle dają czarny ekran. Trzecie ryzyko to kolejny punkt awarii: dodatkowe kable, porty, sterowniki, aktualizacje, konflikty z USB, a nawet zasilanie.
Dlatego minimalny sensowny podział ról wygląda tak: PC do gry ma dać 240 FPS i stabilny frametime, PC do streamu ma być „maszyną do OBS” — mocną w enkodowaniu i stabilną w IO (karta przechwytująca, audio, sieć). Dopiero przy takim rozdzieleniu obowiązków dual PC spełnia obietnicę „odciążenia GPU”.
Trzy architektury połączenia obrazu: passthrough, clone/duplicate, NDI — konsekwencje dla 240 FPS
Capture z passthrough: najbliżej „jakby go nie było”, ale zależne od standardu
Passthrough to układ, w którym sygnał idzie: GPU (PC do gry) → wejście karty przechwytującej → wyjście karty → monitor, a PC streamingowy przechwytuje obraz z tej karty. Dla wielu osób to najczystsze rozwiązanie, bo PC do gry widzi po prostu monitor, a karta przechwytująca „podsłuchuje” sygnał.
Kluczowy haczyk: passthrough musi obsłużyć Twoje parametry. W marketingu łatwo trafić na hasła typu „4K capture”, które nie mówią nic o tym, czy urządzenie przepuści 1080p240 albo 1440p240. Często urządzenie przechwytuje np. 1080p60, a passthrough ma inne limity (czasem wyższe, czasem niższe). Jeśli passthrough nie wspiera 240 Hz, monitor może spaść do 120/144 Hz, a Ty zauważysz „czegoś brakuje”, mimo że FPS w grze jest wysoki.
Passthrough bywa też bardziej przewidywalny niż klonowanie, bo unikasz scenariusza „dwa monitory o różnych odświeżaniach”. Jeśli priorytetem jest minimalny input lag i najmniej niespodzianek w Windows, passthrough często jest najbezpieczniejszą drogą — ale pod warunkiem, że specyfikacja naprawdę pokrywa 240 Hz na odpowiedniej rozdzielczości.
Capture bez passthrough: clone/duplicate i problem „drugiego monitora”
Druga architektura to podłączenie monitora bezpośrednio do GPU, a kartę przechwytującą jako osobne „wyjście” z PC do gry. Wtedy robisz duplikowanie/klonowanie ekranu: obraz na monitorze i na „wirtualnym monitorze” (capture) ma być taki sam. Zaletą jest elastyczność: możesz zachować DP do monitora 240 Hz, a HDMI wysłać do capture, nawet jeśli capture nie ma passthrough 240.
Wadą jest to, że Windows i sterownik GPU zaczynają traktować to jak konfigurację wielomonitorową. A to potrafi wywołać skutki uboczne: VRR potrafi się wyłączyć, pełny ekran zachowuje się inaczej, czasem odświeżanie „wyrównuje się” do niższego, a w skrajnych przypadkach frametime robi się mniej stabilny. Nie dzieje się tak zawsze — ale to ten typ problemu, który pojawia się dopiero po godzinie grania albo po aktualizacji sterownika.
Clone/duplicate jest często najlepszym wyjściem, gdy chcesz monitor 240 Hz bez kompromisu, a przechwyt i tak ma być 1080p60. Wtedy nie próbujesz „przepchnąć” 240 Hz przez capture, tylko wysyłasz do capture sygnał, który ono stabilnie łyka, a monitor dostaje pełny sygnał po DP.
NDI po sieci: zero capture card, ale sieć staje się krytyczna
NDI (lub podobne rozwiązania IP) kusi brakiem kabli HDMI/DP i brakiem problemów EDID. W teorii PC do gry wysyła obraz po sieci do PC streamingowego, a ten robi resztę. W praktyce przy celu „utrzymać płynne 240 klatek” NDI ma dwa minusy: (1) zwraca część obciążenia na PC gamingowy, bo obraz trzeba zakodować/skomponować do strumienia NDI, (2) stabilność zależy od sieci i jej jittera, co potrafi generować nieregularność.
To rozwiązanie ma sens, jeśli priorytetem jest prostota okablowania albo jeśli capture card powoduje problemy z HDCP/EDID, a sieć masz naprawdę solidną (najlepiej przewodową) i jesteś gotów zaakceptować, że „część OBS-owego świata” wraca na PC do gry. Dla gracza, który poluje na perfekcyjny frametime, NDI zwykle jest wyborem drugiego rzędu.
Szybkie kryteria wyboru: co wybrać przy priorytecie 240 Hz
Jeśli Twoim numerem jeden jest 240 Hz i minimalny input lag, najczęściej wygrywa: passthrough, ale tylko gdy urządzenie realnie obsługuje Twoje parametry — albo bezpośrednie podłączenie monitora + duplicate do capture, jeśli passthrough nie ogarnia 240. Jeśli priorytetem jest „zero problemów z kablem i sygnałem”, NDI potrafi być wygodne, ale rzadko jest najczystsze dla frametime.
Karta przechwytująca i tor wideo pod 240 Hz: na co patrzeć, żeby nie zabić odświeżania
PCIe vs USB — kiedy która droga ma sens
PCIe kojarzy się z „najlepszą wydajnością” i często faktycznie daje stabilniejszy przechwyt oraz mniej problemów z magistralą, szczególnie gdy masz już zajęte porty USB przez kamerę, interfejs audio i peryferia. Z drugiej strony, USB bywa wystarczające, jeśli przechwytujesz 1080p60 i nie chcesz grzebać w środku obudowy. W dual PC ważniejsze od samego „PCIe vs USB” jest to, czy urządzenie daje stabilne przechwytywanie bez gubienia klatek i bez kaprysów przy zmianie trybów.
USB jest bardziej wrażliwe na jakość kontrolera, huby, długość i jakość kabla, a także na to, co jeszcze wisi na tej samej gałęzi. Jeśli masz objawy typu „czasem znika obraz” albo „po godzinie pojawiają się dropy”, winny bywa nie sam capture, tylko zasilanie/USB. PCIe eliminuje sporą część tej loterii, ale nie rozwiązuje problemów EDID/HDCP i nie gwarantuje, że passthrough ma 240 Hz.
Specyfikacje, które naprawdę mają znaczenie (i jak je czytać praktycznie)
Przy 240 Hz kluczowe są trzy warstwy: (1) co potrafi przechwycić, (2) co potrafi przepuścić (passthrough), (3) w jakim standardzie portów. Urządzenie może przechwytywać 1080p60, a passthrough mieć np. 1080p240 — albo odwrotnie. Dlatego nie wystarczy „4K” na pudełku.
W praktyce patrz na:
- Passthrough refresh rate dla Twojej rozdzielczości (np. 1080p240, 1440p240).
- Rozdzielczość i FPS przechwytywania (np. 1080p60 to standardowy cel streamowy).
- Obsługę VRR/HDR — nie po to, by streamować HDR, tylko by nie rozwalić zachowania monitora, jeśli używasz VRR w grach.
- HDMI 2.1 vs 2.0 (albo DP, jeśli w danym rozwiązaniu występuje) — jako realny limit przepustowości.
- Format sygnału (czasem capture wymusza określone próbkowanie koloru), co może wpływać na kompatybilność i ostrość.
Jeśli grasz na monitorze 240 Hz, to paradoksalnie częściej potrzebujesz „pewności toru do monitora” niż przechwytywania w 240. Stream i tak najczęściej kończy jako 60 FPS, więc przechwyt 1080p60 bywa wystarczający — ale monitor musi dostać 240 Hz bez negocjacji w dół.
Gdy capture nie obsługuje 240 passthrough: obejścia bez utraty płynności
Najczęstszy scenariusz: masz monitor 1080p240 lub 1440p240, ale karta przechwytująca nie przepuści 240 Hz. Wtedy nie wciskasz jej „w środek” toru do monitora. Zamiast tego stosujesz podejście monitor bezpośrednio do GPU, a capture dostaje drugi sygnał z drugiego wyjścia GPU i robisz duplicate/EDID. To zwykle pozwala zachować 240 Hz na DP do monitora, a jednocześnie dać capture stabilne 1080p60.
W praktyce są tu dwa „tryby”, które zachowują się zupełnie inaczej. Pierwszy to zwykłe Duplicate w ustawieniach ekranu — szybkie, ale podatne na to, że Windows zacznie negocjować wspólne parametry dla obu wyświetlaczy. Drugi to EDID emulator (albo „HDMI dummy plug”), czyli wymuszenie na wyjściu GPU stałego trybu dla capture niezależnie od monitora. To drugie podejście częściej kończy się stabilnie, bo nie prosisz sterownika o „pogodzenie” 240 Hz z 60 Hz; po prostu dajesz mu dwa konkretne, rozłączne cele.
Jeśli pojawia się zjawisko „monitor niby 240 Hz, a jednak czuć 120/144”, zwykle winny jest nie sam FPS, tylko negocjacja trybu: VRR się wyłącza, gra przełącza się w borderless i zaczyna dzielić kompozycję z pulpitem, albo duplikowanie wymusza niższy pixel clock. Najprostszy test to sprawdzić w OSD monitora realne odświeżanie i porównać je z tym, co pokazuje panel sterownika. Gdy te wartości się rozjeżdżają, to nie jest „wina gry” — to tor wideo albo ustawienia wielomonitorowe.
W konfiguracjach, gdzie priorytetem jest czysty frametime, sensownie jest też rozdzielić „komfort streamu” od „komfortu grania”. Do monitora idzie DP/HDMI bezpośrednio z GPU w najwyższym trybie (240 Hz, VRR jeśli używasz), a do capture wysyłasz sygnał, który nie będzie się zmieniał co chwilę: 1080p60, bez HDR, z przewidywalnym próbkowaniem koloru. To jest ten przypadek, gdzie świadomie upraszczasz sygnał dla karty przechwytującej, zamiast walczyć o maksymalne parametry wszędzie naraz.
Typowy przykład z praktyki: ktoś ma monitor 1440p240 po DP i chce „po prostu” przechwycić grę na stream w 1080p60. Jeśli spróbuje wcisnąć capture w passthrough bez pełnego wsparcia 1440p240, kończy się to spadkiem odświeżania albo losowym zachowaniem VRR. W wersji z duplicate + wymuszonym EDID dla capture monitor dalej działa jakby nic się nie stało, a streamingowy PC dostaje stabilny obraz, który OBS nie musi „ratować” resamplingiem.
Gdy celem jest 240 Hz bez kompromisu, wybór zwykle sprowadza się do prostej decyzji: jeśli masz capture z passthrough, który realnie trzyma Twoją rozdzielczość i 240 Hz — idź w passthrough dla najmniejszej liczby zmiennych. Jeśli passthrough odpada, stawiaj na bezpośrednie podłączenie monitora i duplikowanie sygnału do przechwytu (najlepiej z wymuszonym EDID), a NDI traktuj jako opcję wygodną, ale mniej „pewną” tam, gdzie liczy się idealna powtarzalność frametime.
OBS na PC streamingowym: ustawienia, które robią różnicę bez „kradzieży” płynności z PC do gry
Decyzyjne pytanie brzmi: czy PC streamingowy ma być tylko „rejestratorem” (capture + kodowanie), czy też ma przejąć całą kompozycję (sceny, przeglądarki z alertami, filtry, źródła, replay buffer). Im bliżej drugiej opcji, tym bardziej liczy się nie sam enkoder, tylko to, jak OBS zarządza renderowaniem scen i jak stabilnie trzyma czas klatki po swojej stronie.
x264 vs NVENC/AV1/QSV: co wybierać, żeby nie wpaść w pułapkę jakości kosztem stabilności
W dual PC kuszące jest pójście w x264 „bo przecież gaming PC już nie koduje”. To ma sens, ale tylko wtedy, gdy streamingowy CPU jest w stanie kodować bez skoków i bez dławiącego się „encode time”. x264 daje przewidywalny look w niższych bitrate’ach, ale też potrafi zabić spójność, jeśli w tle dzieje się dużo (alerty w przeglądarce, kamerka, filtry audio, nagrywanie jednocześnie).
Sprzętowe enkodery (NVENC/AV1/QSV) zwykle wygrywają w dual PC prostą rzeczą: zostawiają zapas. Nie chodzi o to, że x264 jest „złe”, tylko o to, że w praktyce streamingowy PC rzadko robi wyłącznie czyste kodowanie. OBS renderuje scenę na GPU, miesza źródła, często trzyma kilka instancji przeglądarki — i nagle okazuje się, że CPU + iGPU/GPU są jednocześnie dociskane w sposób, który generuje nierówny frametime po stronie streamu (a widz widzi mikroprzycięcia mimo braku dropów po sieci).
Jeśli masz wybierać „najmniej problematyczny” wariant dla stabilnego streamu 1080p60, często sensownie wygląda:
- NVENC na GPU NVIDII (prosto, stabilnie, mało kaprysów w OBS),
- QSV na Intelu (zależnie od generacji bywa bardzo solidne; ważne, by iGPU było aktywne i miało sterowniki),
- AV1 wtedy, gdy platforma i serwis docelowy realnie to wspierają i nie dokładujesz sobie problemów kompatybilnością.
Gdy priorytetem jest 240 FPS w grze, paradoksalnie lepiej mieć po stronie streamu enkoder, który „nie jest wybitny, ale zawsze jedzie równo”, niż taki, który czasem wygląda minimalnie lepiej, ale potrafi złapać czkawkę.
Preset i opcje „ulepszacze”: kiedy je zostawić, a kiedy wyłączyć
Najczęstsza pomyłka w OBS na PC streamingowym to włączenie wszystkiego, co brzmi jak poprawa jakości: look-ahead, agresywne B-frames, psycho-visual tuning, dodatkowe skalowania, redukcje szumu w kamerze, filtry „upiększające” w łańcuchu. To bywa OK, dopóki scena jest prosta. W scenach „turniejowych” (kamera + overlay + chat + alerty + capture + czasem replay buffer) te dodatki potrafią podnieść render/encode time na tyle, że pojawiają się mikro-stuttery na streamie.
Praktyczne rozróżnienie wygląda tak:
- Jeśli stream czasem „szarpnie” bez oczywistego powodu, pierwsze podejrzenie pada na ciężkie źródła (Browser Source, animowane overlaye) i na opcje typu look-ahead. Lepiej mieć trochę prostszy obraz, ale stabilny.
- Jeśli wszystko jest stabilne, ale brakuje jakości w ruchu, wtedy dopiero ma sens delikatne „doprawianie” ustawień enkodera, a nie dokładanie filtrów w pięciu miejscach naraz.
W dual PC klasycznie wygrywa podejście konserwatywne: trzymasz enkoder na ustawieniach, które nie skaczą obciążeniem, a jakość „robisz” bitrate’em, dobrą bazową rozdzielczością i czystym sygnałem z capture.
Canvas, skalowanie i filtr: gdzie najczęściej tracisz ostrość i dokładność ruchu
Jeśli grasz w 1440p, a stream leci w 1080p, masz dwa podejścia: skalowanie po stronie karty przechwytującej/drivera albo skalowanie w OBS. W praktyce kontrolę daje OBS, ale jest jeden warunek: nie możesz doprowadzić do sytuacji, w której obraz jest skalowany dwa razy (np. GPU robi downscale do 1080p na wyjściu, a OBS znów skaluje w ramach canvasu).
Najczystszy układ zwykle wygląda tak: capture dostaje stały sygnał (często 1080p60), OBS ma canvas zgodny z docelową kompozycją, a wszelkie „dopasowanie” dzieje się raz, przewidywalnie. Jeśli jednak chcesz przechwytywać w wyższej rozdzielczości i downscale robić w OBS, trzymaj się jednego filtra (najczęściej Lanczos dla ostrości albo Bicubic dla mniejszego obciążenia) i nie miksuj kilku konwersji na różnych etapach.
Audio w dual PC bez echa i bez rozjazdu: dwa podejścia, które najczęściej działają
Drugie decyzyjne pytanie, które realnie „psuje” dual PC: czy chcesz mieć audio w pełni rozdzielone (osobno gra, osobno Discord, osobno mikrofon, osobno alerty), czy wolisz prosty miks, który zawsze jest spójny. Da się zrobić oba, ale każdy ma inną cenę: rozdzielenie daje kontrolę, a prosty miks daje stabilność i mniej punktów awarii.
Podejście A: prosty miks analogowy / interfejs jako centrum
To jest droga dla osób, które wolą pewność niż dłubanie w wirtualnych kablach. Mikrofon wpinasz w interfejs/mikser, odsłuch robisz lokalnie (żeby nie mieć opóźnienia), a do PC streamingowego wysyłasz gotowy miks albo dwa tory (np. mic + reszta). Kluczowa korzyść: nie walczysz z opóźnieniami aplikacji i nie gonisz desyncu między tym, co idzie z capture, a tym, co idzie osobnym kanałem z gaming PC.
Najczęstszy błąd przy tym wariancie to podwójny odsłuch: dźwięk wraca z OBS i słyszysz echo. Odsłuch powinien być w jednym miejscu: albo bezpośrednio z interfejsu/miksera, albo z PC streamingowego — nie z obu.
Podejście B: cyfrowe rozdzielenie i synchronizacja w OBS
Jeśli zależy Ci na tym, żeby np. Discord był ciszej niż gra, a alerty nie wchodziły w mikrofon, wtedy idziesz w rozdzielanie torów na poziomie systemu. W praktyce kończy się to jednym z dwóch układów: audio z gry przechodzi przez HDMI razem z obrazem do capture (to jest spójne czasowo), a mikrofon oraz Discord trafiają do OBS inną drogą. To działa, ale wymaga świadomego ustawienia opóźnienia dla jednego z torów, bo capture potrafi dodać stałą latencję wideo/audio.
Gdy widz mówi „usta się nie zgadzają”, a Ty widzisz, że sieć nie dropi i OBS nie gubi klatek, to zwykle problemem nie jest enkoder, tylko różnica czasowa między:
- audio przychodzącym przez HDMI/capture,
- mikrofonem podpiętym bezpośrednio do PC streamingowego (który jest „szybszy”),
- Discordem, który czasem ma własne buforowanie.
W tym wariancie lepiej mieć mniej „sprytnych” wtyczek i wirtualnych urządzeń, a więcej konsekwencji: jeden punkt miksu i jeden punkt synchronizacji.
Utrzymanie 240 FPS w praktyce: co potrafi zepsuć frametime mimo dual PC
Dual PC usuwa presję kodowania z gamingowego GPU/CPU, ale nie usuwa „klasycznych” źródeł nieregularności. Przy 240 Hz problemem rzadko jest średni FPS — częściej są to skoki frametime, które czujesz jako szarpnięcie mimo licznika 240.
Limiter FPS i tryb wyświetlania: mniej „magii” sterownika, więcej powtarzalności
Jeżeli grasz bez limitu, GPU dobija do 99% i zostawia minimalny margines na wszystko inne: obsługę urządzeń, schedulowanie, overlaye, czasem nawet na samą obsługę wielomonitorowości przy duplicate. To typowy powód, dla którego „po przejściu na dual PC dalej czasem tnie” — bo render i tak jedzie na ścianie.
Przy celu 240 FPS często lepiej działa limit minimalnie poniżej odświeżania (zależnie od VRR i preferencji), niż „ile fabryka da”. Zyskujesz stabilniejszy frametime, mniejszą zmienność temperatur i mniej przypadków, w których system musi nagle coś „odebrać” grze.
Druga rzecz to tryb pełnoekranowy: część gier w borderless potrafi mieć gorszą przewidywalność, szczególnie w konfiguracjach z klonowaniem ekranu. Jeśli masz wrażenie, że po włączeniu duplicate gra „zachowuje się inaczej”, to nie musi być placebo — zmienia się sposób kompozycji i priorytety okien.
Overlaye, akceleracja przeglądarki i „niewinne” rzeczy na gaming PC
Dual PC nie oznacza, że gaming PC ma być sterylny, ale przy 240 Hz różne drobiazgi potrafią wrócić jako mikroprzycięcia: nakładki (Steam/Discord/GFE), monitoringi, rejestratory, czasem nawet przeglądarka z włączoną akceleracją sprzętową na drugim monitorze. Różnica między „działa” a „jest idealnie równo” bywa właśnie w takich rzeczach.
Jeśli po złożeniu dual PC zauważasz, że sporadycznie łapiesz szarpnięcie, test diagnostyczny ma sens w odwrotnej kolejności niż większość robi: najpierw wyłączasz rzeczy, które dotykają renderu (overlaye, monitoring OSD, nagrywanie w tle), dopiero potem grzebiesz w sterownikach. W wielu przypadkach to nie karta przechwytująca jest winna, tylko dodatkowa warstwa, która zaczęła „podglądać” klatki.
Dwa scenariusze spięcia kabli i ustawień, które zwykle nie generują niespodzianek
Scenariusz 1: passthrough z pełnym wsparciem 240 Hz (najmniej zmiennych)
To układ dla osób, które kupiły capture świadomie pod swoje parametry i chcą możliwie prostego toru. Gaming PC wysyła sygnał do capture, a z passthrough idzie on do monitora. PC streamingowy przechwytuje i koduje. Zaletą jest to, że system nie widzi „drugiego monitora” na gaming PC, więc rzadziej pojawiają się efekty uboczne wielomonitorowości.
Ten scenariusz przegrywa tylko wtedy, gdy w praktyce passthrough nie trzyma parametrów (albo sypie się VRR/HDR). Jeśli widzisz, że po wpięciu capture monitor nagle przestaje zgłaszać 240 Hz lub VRR, to nie ma sensu walczyć z ustawieniami tygodniami — to jest sygnał, że trzeba przejść na drugi scenariusz.
Scenariusz 2: monitor bezpośrednio do GPU + osobny sygnał do capture (najbezpieczniejsze dla 240 Hz)
To układ „kompetetywny”: monitor dostaje pełny sygnał z GPU po DP/HDMI, a capture dostaje osobne wyjście (zwykle HDMI) w trybie 1080p60. Jeśli duplicate zaczyna mieszać w trybach, wtedy wchodzi w grę wymuszenie stałego EDID dla wyjścia do capture, żeby sterownik nie próbował negocjować wspólnego mianownika między 240 Hz i 60 Hz.
Po stronie PC streamingowego zaleta jest prosta: dostajesz stabilny, powtarzalny sygnał, który łatwo utrzymać w OBS bez sztuczek. Po stronie gaming PC zaleta jest jeszcze prostsza: nie dotykasz toru do monitora, więc minimalizujesz ryzyko, że cokolwiek zmieni się w odświeżaniu lub w opóźnieniu.
Naturalny punkt decyzji: gdzie dual PC faktycznie „odciąża GPU”, a gdzie tylko dodaje kolejne ryzyka
Jeśli głównym problemem był encode i kompozycja po stronie gaming PC (spadki w chwilach walki, niestabilny frametime przy scenach z wieloma źródłami), dual PC z capture zwykle daje natychmiastową poprawę — pod warunkiem, że tor wideo do monitora pozostaje nienaruszony albo passthrough jest faktycznie zgodny z 240 Hz. Jeśli natomiast problemem były rzeczy typowo „renderowe” (gra dobija GPU do ściany, overlaye, niestabilny limiter, kapryśny borderless), to drugi komputer tego nie naprawi. Wtedy zyskasz lepszy stream, ale 240 FPS dalej będzie wymagało dyscypliny po stronie gaming PC: limitu, czystego toru wyświetlania i ograniczenia rzeczy, które podkradają czas klatki.
OBS na PC streamingowym: ustawienia, które robią różnicę między „ładnie” a „stabilnie”
Najbardziej podstępna pułapka w dual PC to myślenie, że skoro gaming PC jest odciążony, to na streamingowym można „na bogato” włączyć wszystko. Da się, ale przy streamie liczy się nie tylko jakość obrazu, lecz też to, czy OBS utrzymuje równy rytm: bez przeciążeń renderu sceny, bez nagłych skoków opóźnienia i bez zrywania klatek przy przełączaniu źródeł.
W praktyce masz trzy „koszyki” obciążenia: render (kompozycja sceny, filtry, przeglądarkowe alerty), encode (enkoder) i network (wysyłka). Dual PC głównie odcina Ci encode od maszyny do gry, ale na PC streamingowym dalej możesz zabić stabilność renderem, jeśli zrobisz z OBS-a mini After Effects.
x264 vs NVENC/AV1: wybór zależy bardziej od celu niż od internetowych wojenek
Jeśli PC streamingowy ma mocny CPU i jest złożony „pod stream”, x264 nadal ma sens — szczególnie tam, gdzie chcesz przewidywalnej jakości w trudnych scenach (dym, trawa, szybkie obroty kamery) i masz czas ustawić to raz, a dobrze. Cena jest prosta: CPU będzie pracował ciężej, a każde dodatkowe zadanie w tle (przeglądarka, boty, wtyczki) może mieć większy wpływ na stabilność.
NVENC (albo inny sprzętowy enkoder) zwykle wygrywa „spokojem”: mniejsza zmienność obciążenia CPU, mniej przypadków, w których OBS zaczyna gubić klatki kodowania, bo system postanowił coś przestawić w tle. Przy dual PC to często najbardziej bezproblemowy wybór, bo streaming PC i tak ma GPU — nawet średnie — które może robić encode bez dramatów.
AV1 to osobna kategoria: świetny, jeśli platforma i odbiorcy realnie na tym korzystają, ale w praktyce ważniejsze jest, żeby nie dokładać sobie ryzyka kompatybilności i nagłych „dziwnych” zachowań sprzętowego enkodera. Jeśli stream ma być po prostu stabilny, a nie „laboratoryjny”, NVENC/H.264 wciąż jest rozwiązaniem, które rzadko zaskakuje.
Presety, B-frames i „ulepszacze”: kiedy je wyłączać zamiast dokręcać
W ustawieniach enkodera najłatwiej przesadzić z funkcjami, które brzmią dobrze, ale w zamian zwiększają nieprzewidywalność obciążenia. Dwa klasyczne przykłady to mechanizmy typu look-ahead i agresywne „psycho” ulepszanie detali. Czasem poprawiają obraz, ale jeśli zauważasz, że stream potrafi złapać mikro-dropy tylko w najbardziej chaotycznych momentach, to często te opcje są winowajcą — bo dokładnie w tych chwilach rośnie złożoność sceny i enkoder zaczyna potrzebować więcej czasu.
Praktyczny kompromis jest prosty: lepiej mieć minimalnie gorszą ostrość w trawie niż stracić spójność klatek. Widownia wybaczy „trochę bardziej streamingowy” obraz, ale nie wybaczy skoków płynności i rozjazdów audio.
Sceny i źródła: render potrafi zabić nawet mocny PC streamingowy
Jeśli OBS zaczyna raportować render lag (a nie encode lag), problemem są źródła i filtry. Typowe miny to: kilka źródeł przeglądarkowych z animacjami, zbyt ciężkie filtry na kamerze, dynamiczne skalowania i wielokrotne przechwyty tego samego sygnału w kilku scenach.
W dual PC często działa podejście „jedno źródło, jedna prawda”: jeden capture jako baza, a reszta jako lekkie nakładki. Jeśli potrzebujesz tej samej kamery w kilku scenach, lepiej użyć jednego źródła i kopiować je jako reference w OBS, niż tworzyć kilka niezależnych instancji z osobnymi filtrami. Różnica jest mała na papierze, a w praktyce bywa tym, co decyduje o stabilności przy długim streamie.
Synchronizacja audio-wideo: ustaw to raz, żeby nie „naprawiać” co tydzień
W dual PC łatwo wpaść w pętlę: dziś wszystko gra, jutro ktoś mówi, że usta „idą pół klatki później”, a pojutrze po aktualizacji sterowników opóźnienie jest inne. Najlepsze układy to te, w których masz jeden dominujący zegar i minimalną liczbę miejsc, gdzie system coś buforuje.
Najczystszy punkt odniesienia: audio razem z wideo przez capture
Jeżeli dźwięk z gry idzie przez HDMI do karty i w OBS widzisz go jako część urządzenia przechwytującego, to masz duże szanse na stabilną relację audio-wideo, bo to jedna ścieżka z jednym opóźnieniem. Wtedy dostrajasz tylko mikrofon (lub Discord), a nie wszystko naraz.
Gdy robisz odwrotnie — wideo z capture, a audio z gaming PC osobnym kablem lub po sieci — ryzykujesz, że jedna ścieżka będzie pływać, bo Windows/sterowniki lubią „pomagać” buforowaniem. To nie znaczy, że to się nie da, tylko że trudniej utrzymać stałość po aktualizacjach i zmianach urządzeń.
Praktyczny test zamiast zgadywania: klaśnięcie i jedna poprawka
Do ustawienia synchronizacji lepiej sprawdza się banalny test niż długie dyskusje: krótki klaps/klik w kadrze (żeby był i obraz, i dźwięk), nagranie lokalne w OBS i sprawdzenie, czy pik audio pokrywa się z momentem zamknięcia dłoni. Jeśli nie, korygujesz tylko jeden tor opóźnieniem w OBS. Kombinowanie kilkoma suwakami naraz to proszenie się o chaos.
Typowy, sensowny wybór: jeśli obraz z capture jest „wolniejszy”, a mikrofon wchodzi bezpośrednio do PC streamingowego, to zwykle opóźnia się mikrofon, nie „przyspiesza” wideo. Wideo i tak ma swoje stałe opóźnienie w przechwytywaniu — próbując je obejść, kończysz z niestabilnością.
HDCP, EDID i czarne ekrany: problemy, które wyglądają jak awaria, a są negocjacją sygnału
W konfiguracjach 240 Hz najwięcej „dziwnych” problemów nie wynika z tego, że coś jest zepsute, tylko z tego, że urządzenia próbują dogadać się co do trybu pracy. Capture, monitor, GPU i czasem nawet kabel — każdy ma swoje ograniczenia, a Windows potrafi je „zinterpretować” po swojemu.
Czarny ekran po podłączeniu capture: najpierw format sygnału, potem panika
Jeżeli po podpięciu karty przechwytującej widzisz czarny obraz w OBS albo urządzenie „znika” po przełączeniu gry, najczęściej winne są skoki trybu: gra przechodzi w inny fullscreen, zmienia częstotliwość, HDR, przestrzeń barw, a capture nie łapie renegocjacji tak szybko jak monitor.
W praktyce pomagają dwie rzeczy: utrzymanie stałego trybu wyjścia na porcie do capture (np. zawsze 1080p60 SDR) oraz ograniczenie automatyki typu „włącz HDR tylko w tej grze”. Dla monitora możesz mieć 240 Hz i VRR, ale port do capture niech będzie nudny i przewidywalny. Dual PC nie lubi niespodzianek w sygnale.
EDID jako „kotwica”: gdy duplicate próbuje zbić Ci odświeżanie
W scenariuszu z osobnym wyjściem do capture i duplikowaniem, Windows czasem próbuje znaleźć wspólny mianownik dla dwóch „ekranów”. Efekt uboczny: nagle Twój główny monitor ma mniej Hz niż powinien albo VRR przestaje działać, mimo że bez capture było idealnie.
Rozwiązaniem nie zawsze jest walka z ustawieniami gry. Częściej działa wymuszenie EDID na wyjściu do capture (sprzętowo lub programowo), tak aby ten „drugi ekran” zawsze zgłaszał to, co chcesz przechwytywać, a nie to, co akurat Windows uzna za wygodne. To nie jest tuning „dla sportu” — to stabilizacja negocjacji, która przy 240 Hz potrafi wywrócić cały sens dual PC.
NDI i przechwytywanie po sieci: kiedy to ma sens, a kiedy wraca bumerang w postaci opóźnień
NDI (i podobne rozwiązania) kusi, bo odpada karta przechwytująca i kable wideo. W realnym świecie to jest zamiana jednego typu złożoności na inny: zamiast sygnału HDMI masz sieć, kompresję i dodatkowe warstwy oprogramowania.
Jeżeli grasz kompetetywnie i walczysz o frametime, NDI ma dwa typowe minusy. Po pierwsze: na gaming PC dochodzi proces, który musi ten obraz przygotować i wysłać, a więc coś jednak dotyka renderu/IO. Po drugie: sieć bywa stabilna… dopóki nie przestanie — a wtedy diagnozujesz, czy to switch, sterownik karty sieciowej, oszczędzanie energii, czy inna aplikacja, która nagle zaczęła wysycać łącze lokalne.
NDI ma za to sens w dwóch przypadkach: gdy grasz w tytuły mniej wrażliwe na mikroprzycięcia i bardziej cenisz wygodę, albo gdy capture card nie jest w stanie utrzymać parametrów toru (np. przez ograniczenia HDMI/VRR) i wolisz stabilny pipeline software’owy kosztem odrobiny opóźnienia. To nie jest „lepsze lub gorsze”, tylko inna hierarchia priorytetów.
Decyzje przed zakupem drugiego PC: minimalny streaming PC i „punkt, w którym dopłata ma sens”
Dual PC potrafi być króliczą norą zakupów, a tymczasem streaming PC ma jedno zadanie: przejąć przechwytywanie, kompozycję i kodowanie w sposób powtarzalny. Najczęściej nie potrzebujesz potwora do gier, tylko maszyny, która nie zadławi się w OBS i nie zacznie mielić dysku przy kilku źródłach.
Jeśli idziesz w x264, rośnie sens inwestycji w CPU i chłodzenie, bo stabilny zegar pod obciążeniem jest ważniejszy niż „peak” w benchmarku. Jeśli idziesz w NVENC/AV1, CPU może być skromniejszy, ale wtedy łatwo przesadzić z dodatkami w scenach (render) i wtyczkami. W obu podejściach pamięć i dysk mają znaczenie bardziej praktyczne niż marketingowe: system, który nie robi przycinek przy przełączaniu scen i nie dławi się na I/O, to system, który trzyma stabilne klatki.
Najczęściej sensowna granica dopłaty pojawia się nie w samym enkoderze, tylko w momencie, gdy chcesz jednocześnie: kamerę w wysokiej jakości z filtrami, kilka źródeł przeglądarkowych, odtwarzacze multimediów i częste przełączanie scen bez „chrupnięcia”. Jeśli stream ma być prosty (gra + cam + alerty), dużo łatwiej osiągnąć stabilność nawet na umiarkowanym sprzęcie — i to jest często najbardziej rozsądny punkt startu, zanim zaczniesz dokładać kolejne warstwy.
