ZagrajmyW na LetsPlej.pl

Znalazłem kartkę o której wspominałem w innym temacie i przez nockę porobiłem testy z GTX 960 (dopiero wstałem, bo nie pamiętam o której poszedłem spać ). Postanowiłem, że napiszę oddzielny temat w którym wszystko jasno przedstawię i zaprezentuję wyniki oraz spostrzeżenia moich testów. Mam nadzieję, że wyniknie z mojej krótkiej analizy coś fajnego, co pozwoli przyspieszyć renderowanie filmów podejmując takie, a nie inne decyzje. Druga strona medalu jest też taka, że przynajmniej tego tematu nie zgubię jak kartki, więc moje poczynania zostaną utrwalone na stałe

Na samym wstępie może najpierw konfiguracja platformy testowej na której robiłem testy:

CPU: Intel i7-5820K (niepodkręcony)
MB: MSI X99S Gaming 7
GPU: MSI GTX 750Ti / Gigabyte GTX 960
RAM: Kingston HyperX Savage DDR4 3000MHz CL15 2x8GB (testy dzielą się na próby z jednym i dwoma modułami RAM, aby sprawdzić opłacalność dual channel)
SSD: Crucial MX200 250GB
HDD: WD Black 1TB (na tym dysku znajduje się program w którym pracuje i na ten dysk renderuję)
CPU FAN: Be Quiet Dark Rock Pro 3
Obudowa: Silentium Gladius X60
PSU: Be Quiet 730W Pure Power L8 Box
OS: Windows7 HP 64-bit (SP1) -> Zaktualizowany do Windows 10 Home
Monitor: Eizo Foris FS2434
Klawiatura i mysz: Logitech MK520
Napęd: Samsung SH-224DB
Czytnik kart pamięci: Akasa AK-ICR-14

Teraz może słów kilka o samym materiale testowym, który podlegał renderowaniu (przypominam, że to tak naprawdę eksportowanie). Wybrałem dość ciężki materiał ze względu na to co w nim zostało zrobione - przyspieszenia obrazu. Jednak o tym za chwilkę. Materiał który podlegał testom, to tak naprawdę ten filmik:





Proszę nie traktować tego jako reklamę, chciałbym po prostu przedstawić szczegółowo dosłownie wszystko, aby nie było jakichkolwiek niejasności w poczynionych przeze mnie testach. Niech każdy dokładnie widzi na czym pracowałem, jakie dany sprzęt osiągał czasy w jakich konfiguracjach i co pozwala skrócić czas renderowania.

Parametry materiału wejściowego, czyli to co otrzymuję z kamery:



Parametry materiału wyjściowego, czyli wyeksportowanego filmu:



Jak widać parametry jakościowo nie są niskie. Ustawienia przy jakich film był renderowany:



Skoro omówiłem i przedstawiłem materiał testowy, to wypadałoby jeszcze z czystej formalności dopisać środowisko pracy. Jest to Adobe Premiere Pro CS6. Posiadam ten program i tylko na nim pracuje, a eksportowanie materiału odbywa się w Adobe Media Encoder CS6. Innego programu nie posiadam, więc raczej nie zrobię podobnych testów przykładowo w Sony Vegas, gdyż nie będę kupować programu dla jednorazowego użycia, a testy na trialach są niemiarodajne.

Wspomniałem wcześniej o przyspieszeniach w filmie, więc czas wreszcie się do tych słów odnieść. Najpierw krótkie wprowadzenie w jaki sposób program estymuje sobie czas wyświetlany jako czas pozostały do ukończenia procesu. Adobe robi to w bardzo prosty sposób. Patrzy na to co w danej chwili aktualnie przetwarza, drugim okiem zerka ile jest jeszcze materiału do końca i myśli sobie: "jedną sekundę filmu przetwarzam w 1 sekundę, pozostało do końca jeszcze 3 minuty filmu, więc wyświetlę użytkownikowi, że przewidywany czas końca procesu to 3 minuty". Proste, nieprawdaż? Jest jeden haczyk - podczas takiego rozumowania Adobe przyjmuje, że dany materiał jest do końca taki, jaki jest w chwili przetwarzania. Program tak naprawdę nie wie, że za chwilę może trafić na jakiś bardziej wymagający kawałek materiału. Znów jeśli na niego trafi, to myśli, że już taki film jest do końca. Takim bardziej wymagającym elementem jest właśnie przyspieszenie filmu:



Jeśli ktoś nie wierzy, to można sobie samemu sprawdzić. Wyrenderujcie sobie filmik który jest nagrany jednym tempem i ma 10 minut długości i zapiszcie czas, a potem do tego samego filmiku wstawcie urywki które są przyspieszone. Gwarantuję, że czas drugiego filmu będzie sporo dłuższy. W zależności od konfiguracji sprzętowej, na moje oko może wynosić nawet 30-35% więcej. To bardzo dużo, wręcz ogromna różnica. Dlatego uznałem, że jak testować sprzęt, to na wymagającym materiale i decyzja padła na ten filmik.

Jeszcze dla czystego sumienia dodam - warunki eksportowania filmu we wszystkich przypadkach były takie same, a rzynajmniej robiłem co mogłem, aby były identyczne. Przed każdą próbą sprawdzałem wydajność komputera w Cinebench R15, przez co widziałem przykładowo czy nie mam w tle jakiegoś procesu, który pożerałby jakieś zasoby komputera itd.

Czas przejść do samych testów i tego co otrzymałem. Kolejna sprawa - będę podawał wyniki uśrednione z kilku prób.


Test 1
Pytanie: Czy opłaca się stosować tryb Dual Channel? Jeśli tak, to jakiego wzrostu wydajności można się spodziewać?

Prosta sprawa, aby to sprawdzić. Najpierw przeprowadziłem renderowanie z jednym modułem RAM, póxniej zamontowałem drugi i powtórzyłem testy. Dodam, że technologia CUDA jest wyłączona.

Czas renderowania w trybie single channel to 31:09 min.
Czas renderowania w trybie dual channel to 25:02 min.

Na pierwszy rzut oka różnica jest już ogromna. Aby policzyć wartość procentową należy powyższe wyniki zamienić na sekundy, ponieważ kalkulator nie wiem, że minuta ma 60 sekund i liczyłby do 100. Zatem otrzymujemy:

Czas renderowania w trybie single channel to 1869 s.
Czas renderowania w trybie dual channel to 1537 s.
Różnica: 332 s.

Przyspieszenie procesu o 332 sekundy, daje nam przyspieszenie rzędu 17.76%! Jest to piorunująca liczba i naprawdę duże przyspieszenie procesu.

Odpowiedź: Tak, tryb Dual Channel jest jak najbardziej opłacalny. Wzrost wydajności procesów komputera wynosi aż kilkanaście procent.
Pamiętaj - kupując komputer lub dokonując jego modernizacji, koniecznie wybierz opcję dwóch modułów RAM, zamiast jednego!


Test 2
Pytanie: Czy technologia CUDA dużo wnosi do czasu eksportowania filmów? Czy opłaca się tej technologi używać?

W tym miejscu przeprowadziłem próby w dwóch konfiguracjach pamięci RAM i na dwóch kartach graficznych. Zacznijmy może od poczynań MSI GTX 750Ti, która według strony nVidii posiada 640 rdzeni CUDA.

Czas renderowania w trybie single channel, MSI GTX 750Ti, CUDA OFF to 31:09 min.
Czas renderowania w trybie single channel, MSI GTX 750Ti, CUDA ON to 25:02 min.
Czas renderowania w trybie dual channel, MSI GTX 750Ti, CUDA ON to 21:48 min.

Analogicznie do poprzedniego testu, minuty trzeba zamienić na sekundy:

Czas renderowania w trybie single channel, MSI GTX 750Ti, CUDA OFF to 1869 s.
Czas renderowania w trybie single channel, MSI GTX 750Ti, CUDA ON to 1502 s.
Czas renderowania w trybie dual channel, MSI GTX 750Ti, CUDA ON to 1308 s.

Różnica CUDA ON/OFF: 367 s.
Różnica dual/single channel przy CUDA ON: 194s.
Całkowita różnica: 561s.

Na pojedynczym module RAM samo włączenie technologi CUDA daje nam oszczędność czasu w wymiarze 367 sekund, co przekłada się na skrócenie czasu wykonywania procesu aż o 19.63%! Jeśli zaś do tego, dołożymy drugi moduł RAM, to dochodzi nam dodatkowe 194 sekundy, co łącznie z połączeniem technologi CUDA pozwala skrócić czas eksportowania filmu aż o 561 sekund, co przekłada się na wynik 30%!


Druga faza tego testu, to zaspokojenie mojej ciekawości jak wpłynie na szybość renderowania zmiana karty graficznej na taką, która posiada więcej procesorów CUDA. Los chciał, padło na Gigabyte GTX 960, który zgodnie ze stroną nVidii posiada 1024 rdzenie CUDA. Jest to prawie dwukrotność rdzeni posiadanych przez GTX 750Ti. Jak to wpłynie na wydajność? Zobaczmy na czasy:

Czas renderowania w trybie dual channel, MSI GTX 750Ti, CUDA ON to 21:48 min.
Czas renderowania w trybie dual channel, Gigabyte GTX 960, CUDA ON to 21:42 min.

Po zamianie na sekundy:

Czas renderowania w trybie dual channel, MSI GTX 750Ti, CUDA ON to 1308 s.
Czas renderowania w trybie dual channel, Gigabyte GTX 960, CUDA ON to 1302 s.

Bardzo się zdziwiłem i to dzięki temu poszedłem spać jeszcze później niż to miałem w planach, bo powtarzałem testy do znudzenia. Najlepszy wynik uzyskany na GTX 960 to 21:40 min i ani sekundy mniej. Spodziewałem się większej różnicy, ze względu na większą ilość rdzeni CUDA. W zasadzie 6 sekund, to żadna różnica, więc ciężko tutaj o niej mówić. W tym momencie jeszcze nie jestem  wstanie powiedzieć co na to wpłynęło. Jedynym prostym i słusznym domysłem jest, że akurat ten projekt nie potrzebował dużej ilości rdzeni CUDA. Dajmy na to, jeśli w tym projekcie elementy, które mogły zostać wsparte przez technologię CUDA (bo nie wszystko jest wspierane, o tym trzeba pamiętać) były w stanie zużyć moc 400 rdzeni CUDA, to powiększenie ich ilości z 640 do 1024 nic nie dało, bo tak naprawdę zwiększyliśmy tylko rezerwę mocy, która leży odłogiem. Jeśli ten domysł okazałby się słuszny, to wynikłaby z tego bardzo radosna wiadomość dla użytkowników którzy nie posiadają grubego portfela - aby znacząco zwiększyć szybkość procesu eksportowania filmu nie trzeba kupować drogiej karty graficznej, ponieważ 640 rdzeni CUDA w GTX 750Ti jest jak najbardziej wystarczające nawet dla dość wymagającego projektu, jak na wymagania domowego użytkownika.

Przed udzieleniem ostatecznej odpowiedzi dodam, że karty ze stajni AMD posiadają odpowiednik CUDA, aczkolwiek sam osobiście go nie testowałem.

Odpowiedź: Tak, technologia CUDA w znaczny sposób wpływa na czas wykonywania procesu. Zakup karty graficznej posiadającej tą technologię jest jak najbardziej słusznym wyborem.
Pamiętaj - jeśli posiadasz kartę graficzną z technologią CUDA nie zapomnij włączyć funkcji używania CUDA w programie do edycji wideo, jeśli ten posiada taką funkcję!


Podsumowując moje powyższe wypociny - nie trzeba być milionerem, aby przyspieszyć procesy typu renderowanie/eksportowanie filmów. Wystarczy odpowiednio dobrać sprzęt na którym się pracuje i nie musi to być kombajn, który kosztuje nie wiadomo ile. Wiadomo, iż głównym czynnikiem wpływającym na szybkośc renderowania filmu jest procesor, więc tutaj im więcej wydamy, tym lepszą jakość uzyskamy. Aczkolwiek w resztę sprzętu nie trzeba pakować potężnych pieniędzy. Do sprawnego wykorzystywania technologi CUDA w zupełności wystarcza karta pokroju GTX 750Ti, czego przed przeprowadzeniem tych testów bym nie powiedział. Pamięć RAM? Otwórz swoją skrzyneczkę i spójrz co masz. Jeśli masz jeden moduł RAM, dokupienie drugiego używanego nie będzie kosmicznym kosztem. Jeśli zas wybiersz nowy komputer - pamiętaj, lepiej wziąć 2x4GB niż 1x8GB.

Powyższym tesktem mogę również potwierdzić słuszność mojego postępowania podczas wyboru elementów do PC'ta. Zdecydowałem się na konfigurację bardzo nietypową, czyli mocny procesor + słaba karta, gdzie w znakomitej większości przypadków to właśnie karta graficzna jest najmocniejszym elementem komputera, a nie jednym z najsłabszych jak to ma miejsce u mnie. Swojemu komputerowi chciałem postawić zadanie - masz być piekielnie mocny. Udało się i to nawet z kartą MSI GTX 750Ti na pokładzie, bo do zadań które wyznaczyłem mojemu komputerowi karta ta prawdopodobnie oferowała mi nadmiar tego co potrzebuję. Zadziwiające, że jedna z tańszych kart graficznych potrafi tak zaskoczyć. Jak widać wszystko zależy od przeznaczenia komputera i od stawianych przed nim zadań. Trzeba się po prostu nauczyć dobrać sobie sprzęt do wyznaczonych zadań i umiejętnie z niego korzystać

AHA dzięki za info.

Tianse napisał(a):Czas renderowania w trybie dual channel, MSI GTX 750Ti, CUDA ON to 1308 s.
Czas renderowania w trybie dual channel, Gigabyte GTX 960, CUDA ON to 1302 s.

Bardzo się zdziwiłem i to dzięki temu poszedłem spać jeszcze później niż to miałem w planach, bo powtarzałem testy do znudzenia. Najlepszy wynik uzyskany na GTX 960 to 21:40 min i ani sekundy mniej. Spodziewałem się większej różnicy, ze względu na większą ilość rdzeni CUDA. W zasadzie 6 sekund, to żadna różnica, więc ciężko tutaj o niej mówić. W tym momencie jeszcze nie jestem wstanie powiedzieć co na to wpłynęło. Jedynym prostym i słusznym domysłem jest, że akurat ten projekt nie potrzebował dużej ilości rdzeni CUDA.

Sprawa jest prosta. Ilość CUDA nie ma odzwierciedlenia w wydajności karty w obliczeniach. Maxwell zachował świetną wydajność w grach i niski pobór energii także dzięki temu, że architektura została wykastrowana z mocy do obliczeń.

Podstawy podstaw: FP32 , FP64 i DP czyli dual precision - obliczenia podwójne precyzji. Poczytaj o tym i ogólnie o możliwościach architektur w obliczeniach.

FP32, FP64 i DP wraca do kart NV w pascalu.

Ilość procesorów CUDA nie jest wyznacznikiem wydajności karty w obliczeniach. Jeżeli jest to bardzo małym i zależnym od innych rzeczy. Dlatego widzisz właściwie brak różnicy miedzy 750TI, a 960. Kepler z mniejszą ilością CUDAków zrobił by to szybciej, a Fermii jeszcze szybciej. Maxwell to świetna wydajność w grach i niski pobór mocy kosztem pogorszenia wydajności w sprawach obliczeń.


Plusik za test.

Bardzo się cieszę, że to wraca z powrotem. Ma być stosunek 1/3, jeśli chodzi o pojedyncza i podwójną precyzję - wreszcie Niby rdzeń GP100 ma osiągnąć nawet 12 TFLOPS. Maxwell rzeczywiście pod tym względem jest oskubany. DP ma takie, że w zasadzie to go nie ma. Całe zapowiedzi nowych generacji brzmią obiecująco, ale... W październiku mówiło się, że na koniec I kwartału tego roku będzie premiera (przypominam, że ich azjatycki rok zaczyna się miesiąc później, więc termin ten miał być na koniec kwietna), a tu proszę, na koniec kwietna ma być tylko kolejna konferencja. Wyjdzie na to, że Polaris później się zapowiedział, a szybciej zadebiutuje. Wstępnie Pascala odsuwają na przełom czerwca i lipca, ale... jako pierwszy miał być następca GTX 980Ti, a teraz się mówi że Titan ma być dopiero nawet w styczniu 2017. Plotki mówią, że nVidia cały czas ma problem z dostawą odpowiedniej ilości stosów pamięci HBM2. Mało tego, niby chcą najpierw wypuścić wersje serwerowe kart, a potem dopiero wersję na rynek konsumencki. Ja tu się napaliłem jak szczerbaty na suchary, a okaże się, że będę musiał poczekać dodatkowe pół roku. Intrygującą sprawą są jeszcze ceny. Jeśli chodzi o Pascala to ciężko nawet o plotki w tym temacie.

To pytanie z innej beczki, czy użycie CUDA w Premiere, nie wpływa na jakość filmu? Pamiętam jak jeszcze używałem Sony Movie Platinum, tam odpalenie CUDA skracało czas renderowania o 50%, ale mimo tego samego bitrate, jakość nagrania była zauważalnie gorsza, niż przy materiale renderowanym wyłącznie na procesorze.

Najłatwiej było to zauważyć w przypadku gier strategicznych i szczegółowego terenu - przy CUDA podczas obracania kamery robiła się zielona plama zamiast trawy, przy samym procesorze ostrość była zachowana mimo ruchu (mówimy o tym samym bitrate = 28Mbps).

Jest w tym coś z prawdy. Przerabianie materiału z użyciem GPU postępuje inaczej niż na samym CPU, przez co jakość materiału może się różnić. Wiem, ze coś takiego istnieje ale nigdy nie zagłębiałem się w szczegóły. Zainteresowani niech kopią neta

Dobre pytanie! Postaram się na nie odpowiedzieć od tyłu. Wchodzę w folder renderowanych filmów, których jest tam aktualnie pełno (przydałoby się, abym kilka usunął). Jeszcze zanim przejdę do sedna sprawy. Jeśli materiał miałby mieć zauważalnie gorszą jakość, to czysto teoretycznie naturalnym skutkiem tego byłaby jego zmniejszona waga. Spójrzmy zatem teraz na wagę plików, które ja mam wyeksportowane. Oczywiście naturalnym jest fakt, że posiadając całą listę tych filmików nie wiem w których używana była technologia CUDA. Do sedna. W folderze mam dwie wagi plików, które mieszczą się w granicach:

Najmniejszy plik: 2 820 890KB
Największy plik: 2 821 699KB

Hmm... Ktoś powie mi zaraz - "chłopcze drogi, tam u góry żeś nas zapewniał, że symulujesz identyczne warunki dla każdej próby renderowania/eksportowania filmu, a one mają różne wagi? Pleciesz bzdury i Twoje testy można o kant dupy rozbić, za przeproszeniem." Rzeczywiście po takim zarzucie, na pierwszy rzut oka mógłbym się z taką osobą zgodzić i przyznać jej rację. Jednak... chwila refleksji. O ile dany materiał na którym powtarzam próby jest taki sam, o ile mój cały sprzęt jest taki sam, o ile warunki które tworzę przy każdej próbie są niemalże identyczne, o tyle praca podzespołów komputerowych nie jest taka sama. Mamy tutaj do czynienia z elektroniką, która potrafi wykonywać (i wykonuje) obliczenia na bardzo wysokim stopniu zaawansowania. Niestety nie wiem w jaki sposób, czyli jakimi algorytmami, odbywa się proces eksportowania filmu w takim programie jak Adobe Premiere. Co mam na potwierdzenie moich słów? Ano przeprowadziłem obserwację takiego procesu, a było to przy konfiguracji sprawdzania czasu procesu przy trybie single channel. Co mogę Wam pokazać:



Rzut oka na obciążenie procesora. Zdziwię tutaj teraz niektóre osoby, że procesor nie jest wykorzystywany w całej swej mocy przez cały proces jaki zadamy mu do wykonania. Zachowuje się on w sposób nieliniowy i jest można rzec nie jest systemem deterministycznym, czyli tłumacząc z mowy technicznaj na potoczną, nie jest przewidywalny.  Powtarzając te same procesy, za każdym razem procesor pracował w zupełności inaczej. Chwilami miewał przestoje i spadki zużycia nawet do zalediwe kilku %, co widać na powyższym screenie, a czasami łapał wiatr w żagle i popierniczał aż miło (patrząc na zegarek - 5 minut później):



To samo mamy z pamięcią RAM. Pięknie widzimy, jak jej zużycie faluje, nie jest jednostajne. Zapewne tak samo będzie z wykorzystaniem rdzeni CUDA z karty graficznej. Skoro zatem przy każdym procesie powtarzanym w takich samych warunkach sprzęt pracuje inaczej to... kręci różne czasy i daje różne wagi plików. Jednak odstępstwa te są bardzo małe. Wszędzie wyżej podawałem uśrednione czasy z kilku próbek, aczkolwiek na 30 minutach renderowania skrajne czasy różniły się zaledwie o 5-6 sekund. Oznacza to nic innego jak to, że żaden proces nie jest w pełni powtarzalny, one są do siebie bardzo zbliżone. Coś jak funkcja i jej aproksymacja. Mało tego, proces ten jest technologicznie tak skomplikowany, że nie sposób jest go wykonać w identyczny sposób, czyli aby procesor zachowywał się wręcz identycznie w dwóch próbach. To tak jakbym kazał komuś brać przedmiot który stoi z jego prawej strony i by go odkładał na lewą stronę. Ktoś powie, że dojdzie do takiej precyzji, że będzie ręką wykonywał identyczne ruchy. Aczkolwiek tak naprawdę nigdy żaden ruch w pełni się nie powtórzy, bo ruch ręką w przestrzeni wielowymiarowej tworzy wiązkę krzywych przestrzennych (w pewnych odcinkach powstają pęki prostych równoległych - mechanika ogólna, dział statyki) i gdyby przyjrzeć się ruchowi dokładnie, to chociażby nawet o nanometry, a byłaby różnica. Analogicznie mamy tutaj. Proces eksportowania jest na tyle skomplikowany, że my gołym okiem nie potrafimy wychwycić różnic, które się dzieją podczas takiego procesu.

Próbowałem rozgryźć choć trochę jakąś namiastkę procesu eksportoania filmu po przebiegu wykorzystywania pamięci RAM. Z początku kompletnie nie wiedziałem dlaczego ona tak "faluje". Wygląda jak fala PWM. Po czasie przyszedł mi do głowy pomysł, że być może wpływ mają na to przyspieszenie w moim materiale, które wyraźnie wydłużają cały proces. Skoro one proces wydłużają, to starałem się nałożyć na siebie czas renderowania poszczególnych fragmentów z wykresem przebiegu zużycia RAM. Niestety, nie pokryło się. Tam gdzie są wzrosty zużycia RAM wcale nie były renderowane kawałki które zostały przyspieszone 2000 razy. Mało tego, co kolejna próba to przebiegi były diametralnie różne, ciężko było pomiędzy tym szukać jakiejkolwiek zależności, nawet wielomianowej. Na płaszczyźnie zespolonej nie próbowałem, bo w tym wypadku nie ma to sensu. Bardzo lubię tego typu zabawy i być może uda mi się powiązać w jakikolwiek sposób w przyszłości jakąś zależność . Póki co przyznaję się do klęski, nie udało mi się. Jeszcze

Poznając po troszku tajniki procesu, a raczej jego brak jakiejkolwiek powtarzalności poprzez pracę sprzętu mogę odpowiedzieć - różnica wagi plików jest w tym przypadku zupełnie normalna. Mimo iż nie wiem, czy te pliki z technologią CUDA są większe, czy mniejsze, to mogę śmiało rzec, że różnica rzędu 809KB na wielkości pliku 2 820 890KB daje błąd wielkości 0.0287%, co na warunki domowe jestem w stanie zaakceptować. Kiedyś na pewnym forum napisałem pewnemu człowiekowi kilka słów o niskonapięciowych procesorach w laptopach. Ten w odwecie chciał mi udowodnić swoje racje (gdzie ja sobie w laboratorium zbadałem to co mu napisałem i dokładnie wiedziałem co piszę), zrobił swoje domowe nazwijmy to "badania" z błędem pomiarowym wynoszącym 400% i mówił mi, że nie mam racji, bo "on sobie zmierzył". Jak widać w takie Januszowanie ja bawić się nie lubię i staram się być nieco dokładniejszy


Uff, spieszę już (a może dopiero?) z konkretną odpowiedzią. Śmiem twierdzić, iż jeśli wagi plików sa niemalże identyczne, to CUDA nie wpływa na ich jakość. Oglądając wyrenderowane (potocznie będę pisać wyrenderowane, ale umówmy się, że Ty już wiesz, że tak naprawdę on jest wyeksportowany, a nie wyrenderowany, ok?) materiały również nie zauważam jakiegokolwiek spadku jakości filmów. Do renderowania moich filmów na YouTube aktualnie cały czas używam technologi CUDA i nie zdarzyło mi się zaobserwować żadnego ubytku jakości, żadnego przebarwienia, żadnych zielonych plam. Dla ciekawskich - mój odcinek nr 8, który trwa 3:53min, przy ustawieniach 1080/50p, bitrate 20, na i7-5820K (niepodkręcony) + 2x8GB (czyli dual channel) + CUDA (GTX 960), wyeksportował się w 2:45min. Jeśli tylko posiadasz GPU z CUDA i oprogramowanie które potrafi takie wsparcie wykorzystać - korzystaj i ciesz się krótszym procesem


P.S. Pierwszy wątek uporządkuję, zajmę się tym niedługo

Hmm, myślę że to trochę błędne założenie, że ta sama waga = ta sama jakość, bo tak naprawdę waga zależy od bitrate, a tak jak wspomniałem wcześniej, otrzymany plik końcowy miał taką samą (ok, bardzo zbliżoną ) wartość bitrate przy CUDA i przy samym CPU - czyli taką samą wagę, a różnica w jakości była zauważalna. Jak znajdę chwilę to przetestuje ten temat w Premiere.

Inna kwestia jest taka, że jakość testujesz na filmie wideo, gdzie zazwyczaj mamy spokojne sceny, spokojne przejścia w tonach kolorów, a jednak w grach wygląda to zupełnie inaczej, mamy masę jaskrawych barw (do tego mocny kontrast), często poruszających się bardzo szybko po ekranie.

Warto zrobić do testów 2 założenia:
- pierwsze, że plik posiada sporo szczegółów i dużo ruchu (jak to ma miejsce w szybkich grach), czyli np. wspomina jakość terenu w strategii przy szybkim obracaniu kamery.
- drugie, można spróbować wrzucić stosunkowo niskie bitrate np. 8 Mbps (1080p), żeby dostać wspomniane artefakty i porównać w którym przypadku, mimo tego samego bitrate jest mniej "śmieci".

Na chwile obecną zaryzykowałbym stwierdzeniem, że przy nagraniach z kamery, różnica jest na tyle niewielka, że się jej praktycznie nie dostrzeże, jednak przy nagraniach z gier, gdzie czasem jaskrawy element zajmuje kilka pikseli, są one w ruchu i jest ich dużo, już można zobaczyć różnicę. Ostatecznie można wyjść z założenia, że YT i tak zrobi z filmu "masakrę", jednak podchodzę do tematu tak, że przesyłam na serwer plik o najlepszej możliwej jakości.

Corle1 napisał(a):Inna kwestia jest taka, że jakość testujesz na filmie wideo, gdzie zazwyczaj mamy spokojne sceny, spokojne przejścia w tonach kolorów, a jednak w grach wygląda to zupełnie inaczej, mamy masę jaskrawych barw (do tego mocny kontrast), często poruszających się bardzo szybko po ekranie.

Nie zgodzę się z tym. Żaden obrót kamery nie będzie tak dynamicznym procesem jak przyspieszone 2000 razy przeze mnie fragmenty filmu. Dla programu nie ma różnicy, czy w swoim projekcie masz szybkie obroty kamerą i dynamiczne ruchy, czy powolne ale je przyspieszysz. Program po prostu ma wyeksportować film i on mierzy się z podanym mu plikiem końcowym. On nie wie, czy Ty go przyspieszyłeś, zwolniłeś, czy nic nie robiłeś, względem pliku wejściowego. Go to w zasadzie nie interesuje. On chce tylko wykorzystać zasoby sprzętowe aby ukończyć proces w jak najkrótszym czasie.

Corle1 napisał(a):Hmm, myślę że to trochę błędne założenie, że ta sama waga = ta sama jakość, bo tak naprawdę waga zależy od bitrate, a tak jak wspomniałem wcześniej, otrzymany plik końcowy miał taką samą (ok, bardzo zbliżoną ) wartość bitrate przy CUDA i przy samym CPU - czyli taką samą wagę, a różnica w jakości była zauważalna.

Właśnie wagi plików mi nie podałeś, więc teraz strzelasz założenie w ciemno Obronię swoje zdanie i powiem, że waga pliku nie zależy tylko od bitrate. Zależy od wielu, wielu innych czynników. Chociażby od tego, co dzieje się na ekranie. Gdybym chciał wyrenderować nagrane samo niebo, bez zachmurzenia, to przy takich samych ustawieniach, plik ważyłby mniej, niż gdybym chciał wyrenderować nagrany tłum ludzi w środku miasta. Długość pliku byłaby identyczna, ustawienia identyczne, wszystko to samo, a waga końcowa inna. Dlatego śmiem twierdzić, że jeśli w dynamicznej grze wylatywałyby piksele i robiły się plamy, to taki film ważyłby zdecydowanie mniej. Dla sprawdzenia czy dobrze myślę - oczywiście test. Aby nie robić symulacji plamek i znikania pikseli na całym filmie ja zrobię inaczej. Wstawię w jedno miejsce po prostu zamiast filmu chwilkę zielonego tła, o takiego:

Nie mam pojęcia co z tego wyjdzie. Pomysł, aby wykonać taką próbę przyszedł teraz, więc lecę i zrobię. Nie mam pojęcia czy potwierdzi to moje powyższe wywody, czy nie, rezultat i tak wstawię.

(po ponad 20 minutach...)

Zamieniłem jedną krótką scenę na to zielone tło, wyeksportowałem film i... waga jest mniejsza! Potwierdza to zatem moje powyższe rozumoiwanie. Szczerze mówiąc nie spodziewałem się, aczkolwiek tak jest. Więc symulując warunek wypadania pikseli czy robienia się plam, udowodniłem, że waga pliku musi być mniejsza. Nie ma zatem opcji, aby eksportować film z CUDA, miał on taką samą wagę i występowały w nim nieprawidłowości. Myślenie przyczynowo-skutkowe. Dla jasności, wrzucę nawet screen:

Wychodzi nam, że najmniejsza różnica wagi pliku to 32 634KB. Zaś największa to 33 443KB. Liczymy i wychodzi, że procentowo plik jest mniejszy o 1.1569%! Nie ma bata, żeby to co piszesz było realne. Coś musi być skutkiem czegoś. Nie może Ci zginać pikseli i mieć taką samą wagę

Tianse ugryź temat z innej strony, żeby go zrozumieć. Tu chodzi o metody "obróbki". Z użyciem GPU jest inna niż z użyciem CPU i spadek jakości jest potwierdzony. Jak pisałem nie wiem czy zawsze, nie wiem kiedy, nie wiem jak mocno ale na forum cyberlink ( bardzo popularne programy tej firmy ) specjaliści poruszali to nie raz. Dziwnym trafem nigdy się nie zagłębiałem w to, stąd wiem, że spadek jakości przy użyciu GPU może być ale szczegółów nie znam.