To wyszło jakby "ogranoleptycznie" i sumarycznie jakość odbioru jest wówczas najwyższa. Poza tym, jeśli na streamie montujesz w jakieś mniejsze okno przechwytywany obraz a na "programie" masz dodatkowo jeszcze jakiś livechat czy inne dziadostwo to nie ma sensu schodzić poniżej fhd.

Jakościowo najlepiej by było grabować wielokrotność rozdzielczości materiału źródłowego i to dawało mi w testach dość wierne odwzorowanie i ostrość obrazu, jednakże mój cudowny grabber przechwyci wówczas max 30fps. A to już sensu żadnego nie ma.

ehhh, teraz widzę ze masę błędów popełniałem. Posiedziałem trochę z tym OBS'em i zoptymalizowałem jego działanie pod kątem możliwości sprzętowych PC. Zwiększyłem też o 40% bitrate generowanego strumienia, co przełożyło się na jakość zwłaszcza obrazu. Dodatkowe spostrzeżenie to fakt, że jeśli coś ma być płynne w 50fps a chodzi nam np. o projektor wpięty pod dualhead'a (na jakimś party) to na czas projekcji polecam zrzucanie OBS'a na pasek tak, by na dwóch ekranach nie trzeba było renderować tej samej treści. Do wydajności renderowania jakoś to znaczenia bardzo nie ma - ale ma znaczenie w przypadku chęci utrzymania stabilnie płynnego wyświetlania np. SCROLLI - szczególnie tych przesuwanych poziomo ;) grabber rozdziałka do proporcji 4:3, tyle fps co strumień wyjściowy, wyjściowy na 50fps (co i tak nie jest dokładnie tym co wychodzi z Atari, jakieś 49.86 czy jakoś tak) i filtr na źródło z grabbera deinterlace Yadifx2 z początkiem od górnej linii. Zakres kolorów "pełny". Chyba nic więcej lepszego nie da się zrobić.

Wstępne wnioski są nieco zaskakujące. Testowo zrezygnowałem z renderowania strumienia poprzez GPU i wróciłem do CPU, które kiedyś tam po prostu nie "wyrabiało". Przestało wyrabiać po instalacji VScode jak musiałem do Fujineta przekompilować wsad ... no ale po drodze robiłem reinstalkę windy, więc poszło to wszystko w kosmos i generalnie jest teraz czasowo jakby trochę więcej luzu. Trochę oznacza mniej więcej tyle, ze jak wcześniej średni czas renderowania klatki przez GPU w OBS miałem w przedziale 9-12ms przy jakości umownie średniej, tak teraz co mnie mocno zdziwiło - poprzez CPU mam w granicach 2.5-3ms i to w najwyższej jakości plus audio na poziomie 320kbps i strumień na 6000kbps. Jakościowo różnica dość znaczna. Ha, no i te 3ms to mam z równoległym zapisem streamu do pliku na dysk - to jest lol.

Przy okazji zaorałem wszystkie sterowniki audio i zainstalowałem to jeszcze raz. Czyli sterownik do Presonusa 1818vsl i całe ASIO, plus wirtualny kabel - "carla". Nie chciałbym chwalić dnia przed zachodem słońca (choć jest już jakby mocno ciemno) ale po 2.5h testowego streamingu wygląda to mocno obiecująco.

Reasumując, jeśli to zadziała to być może zrobię stream z Grawitacji i Krakowskich Retrospekcji. Jeśli nie, to najkrótszą drogą wy*** te graty do najbliższego punktu zbiórki elektrozłomu i chyba dam sobie siana, bo mam obecnie mocno zerowe fundusze na tę zabawę.

Ok. Test taki. (ten sam kodek w przypadku zapisu do pliku, jak i streamingu)

1. OBS i grab do pliku, następnie upload do YT:

https://www.youtube.com/watch?v=QAQgm6pPfJU

2. OBS i streaming do YT:

https://www.youtube.com/watch?v=9cYBi2X3oBc

... tak w sumie, to jak by się dokładnie przysłuchał temu, to w przypadku zapisu do pliku też minimalnie słyszę wspomniane tu gdzieś "skwarki" ale - jest to jakkolwiek akceptowalne. To samo jednak w przypadku streamu ... masakra. Teraz, to już zgłupiałem i nie wiem gdzie szukać przyczyny.

Próbowałem też ustawić cały system audio oraz OBS w 48khz ... ale niestety o ile OBS ma opcje do takiego trybu pracy tak w takim ustawieniu staje się "bezdźwięczny".

materiał źródłowy był tak skompresowany.

Co do samego testu, spróbuję wieczorem zrobić zrzut polegający na zapisaniu jakiegoś MP4 z C1 - C2 i zrobię upload tego do YT celem porównania ilości zakłóceń. No i ciekawe jak to będzie z kodekami YT w tym przypadku.

bo nie ma nad czym się doktoryzować. Technicznie od późnych lat '90 w zasadzie nic się nie zmieniło. Podstawą jest RAM i opcjonalnie stereo. A jakieś tam nowości, jeśli już występują w kompo to są wydzielane w oddzielny konkurs. Np. bywało tak z VBXE GFX.

No właśnie takie były reguły na Silly Venture, że na demo kompo poszedł film odtwarzany ze Side2. Ten zlot to chyba regulaminowy dla ciebie wzorzec, przynajmniej z kontekstu twoich wypocin jasno to wynika. Do tego właśnie doprowadza dowolne podejście do reguł. Inne zapisy reguł na innych parties mają zazwyczaj na celu utrzymanie produkcji w ramach pozwalających na bezproblemowe uruchamianie ze STANDARDOWYCH urządzeń I/O podłączanych do komputera i obsługiwanych poprzez OS na ten przykład. I nie naginaj rzeczywistości - bo nikt jak do tej pory nie wstawił w jedno kompo produkcji na Rapidusa i 6502, czy na antic i VBXE. To są całkowicie odmienne sprawy. Pamięć ram? No właśnie, czyli jest OK jak ktoś przyniesie demo na niemodyfikowane Atari 65XE w postaci 1MB carta? Czy to nie jest ok, bo nie wiem? Z drugiej strony, jeśli pojawią się dema w kategorii 64kB to jaki w tym problem by taką kategorię powołać do życia? Będą chętni - czemu nie.

@pajero - ślepy nie jestem i nadal uważam, że jest to koszmarny potworek. Oryginalny projekt obudowy od XE jest śliczny, ale to dla odmiany - już nie.

patrząc po zdjęciach to przynajmniej jest pewność, że są zajebiste. As - jak pijesz to nie pisz na forum i oszczędź nam tych głupot ;)

... ten Omicron XE to niezłe brzydactwo.

bo wpisałem w post i wyedytowałem pierwszego ;)