ffmpeg: zmniejszanie plików wideo

[Kamiyan 1544]

Dlatego zapytałem, co rozumiesz przez "bezstratne" i nie potrafisz mi na to pytanie odpowiedzieć...?

I co ma MP4 do tego? Rozróżniasz w ogóle video od kontenera, w jakim się znajduje? Bo widzę elementarne braki wiedzy.

[T_G 489]

ależ ty jesteś prześmieszny, przeczytaj co jest napisane w pierwszym poście, poproś kogoś żeby ci przetłumaczył/skonwertował na twoje a jak nie wiesz co to jest kompresja bezstratna to w ogóle nie powinieneś się udzielać w takich tematach, zwłaszcza, że Fransua już odpisał sensownie a twoje brednie i uogólnienia odnośnie enkodowania  gpu vs cpu to wynikają tylko z twoich ograniczeń i tych, których wiedzę lub jej brak cytujesz (widać doświadczenia brak, żeby własnymi słowami odpowiedzieć, ale jakie "kupiaste" gimnazjum taka i "kupiasta" wiedza)

[Bono[UG] 1915]

@T_G Czy ty zawsze musisz sprowadzać temat do kłótni?
Tyle się produkujesz atakując innych, nie lepiej zamiast tego podać przykłady dobrego oprogramowania, które robi prawidłowy użytek z karty graficznej? Było by to z dużo większym pożytkiem dla forum i ludzi pytających niż próby zdyskredytowania kilku osób.

Jak się już dyskusja rozwija w kierunku akceleracji sprzętowej przy kodowaniu wideo, to na litość niech będzie konstruktywnie.

Ja w tym sporze widzę to tak:
- wbudowane kodeki w GPU czy CPU są szybkie ale kiepskie, nie dają takiej jakości jak przeliczenie kompresji na standardowych instrukcjach procesora
- dobre programy (autorskie algorytmy twórców oprogramowania od wideo?) wykorzystują możliwości obliczeniowe GPU do szybkich obliczeń przy użyciu ich interfejsu GPGPU, nie różnią się jakością od kodowania przy użyciu standardowych instrukcji procesora

Ja z chęcią się dowiem jakim programem (najlepiej darmowym) mogę sobie szybko i dobrze, a może i wygodnie, przemielić filmiki nagrywane kamerką. Obecnie korzystam tylko z ffmpeg i to jest katorga jeżeli chodzi o czas obróbki. Zmusić do akceleracji sprzętowej nie udało mi się i nawet nie wiem czy coś źle ustawiam, czy np. Nvidia wspaniałomyślnie blokuje pewne rzeczy (z tego co wyczytałem, to w pewnym momencie usunęli jakieś kodeki na CUDA ze sterowników).
Niestety id ciebie taka informacja nie wychodzi, jedziesz tylko po ludziach, z którymi się nie zgadzasz.

[T_G 489]

nie jadę po ludziach z którymi się nie zgadzam tylko przestrzegam ludzi przed debilizmami serwowanymi rodem z tyłka

przykład

"- wbudowane kodeki w GPU czy CPU są szybkie ale kiepskie, nie dają takiej jakości jak przeliczenie kompresji na standardowych instrukcjach procesora"

nie da się merytorycznie rozmawiać na takim poziomie, można tylko ludziom zwrócić uwagę, że doradzacz nie wie w ogóle o czym mówi i niech weryfikują to w internecie ogólnie lub na branżowych forach, bo tam takie wyziewy są od razy wycinane

[miemik 14]

 

38 minut temu, Bono[UG] napisał:

@T_G
- wbudowane kodeki w GPU czy CPU są szybkie ale kiepskie, nie dają takiej jakości jak przeliczenie kompresji na standardowych instrukcjach procesora

moje stare serce dostaje palpitacji jak to czytam więc wyłączam się z rozmowy - co do DARMOWEGO programu do szeroko rozumianej odrobki video polecam Davinci resolve.

 

Kompletne Podstawy. Jak dobrze zacząć? Najnowsza wersja ▪ DaVinci Resolve #54 | Poradnik ▪ Kurs

Edytowane 10 Lipca 2020 przez miemik

[T_G 489]

w sumie masz racje...

[Kamiyan 1544]

9 minut temu, miemik napisał:

moje stare serce dostaje palpitacji jak to czytam więc wyłączam się z rozmowy - co do DARMOWEGO programu do szeroko rozumianej odrobki video polecam Davinci resolve.

To jest akurat nawet napisane w instrukcji FFmpega.

Cytat

Hardware encoders typically generate output of significantly lower quality than good software encoders like x264, but are generally faster and do not use much CPU resource. (That is, they require a higher bitrate to make output with the same perceptual quality, or they make output with a lower perceptual quality at the same bitrate.)

https://trac.ffmpeg.org/wiki/HWAccelIntro

Nawet przy dekodzie, na przykład przy MPV (obecnie najlepszy player), widać jak obraz się sypie. W temacie chodzi o "re-encode", czyli raczej nie o podkręcone CRF i filtry.

44 minuty temu, Bono[UG] napisał:

Ja z chęcią się dowiem jakim programem (najlepiej darmowym) mogę sobie szybko i dobrze, a może i wygodnie, przemielić filmiki nagrywane kamerką. Obecnie korzystam tylko z ffmpeg i to jest katorga jeżeli chodzi o czas obróbki. Zmusić do akceleracji sprzętowej nie udało mi się i nawet nie wiem czy coś źle ustawiam, czy np. Nvidia wspaniałomyślnie blokuje pewne rzeczy (z tego co wyczytałem, to w pewnym momencie usunęli jakieś kodeki na CUDA ze sterowników).
Niestety id ciebie taka informacja nie wychodzi, jedziesz tylko po ludziach, z którymi się nie zgadzasz.

Czas kodowania zależy od wybranego presetu i jakości (CRF).

Dobrze też wgrać sobie najnowszy static, żeby mieć r160 (wersja kodeka).

https://trac.ffmpeg.org/wiki/Encode/H.264#Preset

Edytowane 10 Lipca 2020 przez Kamiyan

[miemik 14]

Dobra jeszcze raz - serio ostatni.  Kodeki zaszyte wewnątrz intelowskiego procesora graficznego (IQSV) to nie to samo co render przez CUDA (to tylko moc obliczeniowa) . Dlatego pytałem się o to czy jak mowisz gpu jest brzydkie ale szybki a CPU wolne ale żyleta nie chodzi Ci o IQSV.  Powiedziałeś, że nie - o to to ten dym. . A tu jak byk pisze ze iqsv jest szybkie ale gorsze i z tym się zgodzę - zresztą kiedyś na sony vegas na tym jechalem i potwierdzam, że z samego rendera na CPU (bez sensu)  lub CPU+ GPU  (ok) można o wiele więcej wycisnąć niż IQSV. Tu jest coś za coś.

13 minut temu, Kamiyan napisał:

To jest akurat nawet napisane w instrukcji FFmpega.

Nawet przy dekodzie, na przykład przy MPV (obecnie najlepszy player), widać jak obraz się sypie. W temacie chodzi o "re-encode", czyli raczej nie o podkręcone CRF i filtry.

Czas kodowania zależy od wybranego presetu i jakości (CRF).

Dobrze też wgrać sobie najnowszy static, żeby mieć r160 (wersja kodeka).

https://trac.ffmpeg.org/wiki/Encode/H.264#Preset

 

[Bono[UG] 1915]

50 minut temu, T_G napisał:

nie jadę po ludziach z którymi się nie zgadzam tylko przestrzegam ludzi przed debilizmami serwowanymi rodem z tyłka

przykład

"- wbudowane kodeki w GPU czy CPU są szybkie ale kiepskie, nie dają takiej jakości jak przeliczenie kompresji na standardowych instrukcjach procesora"

nie da się merytorycznie rozmawiać na takim poziomie, można tylko ludziom zwrócić uwagę, że doradzacz nie wie w ogóle o czym mówi i niech weryfikują to w internecie ogólnie lub na branżowych forach, bo tam takie wyziewy są od razy wycinane

Niestety ale jedziesz. Już niejedną taką "dyskusję" z twoim udziałem widziałem.

Jak najbardziej się da merytorycznie rozmawiać, tylko trzeba chcieć. Tutaj np. w zasadzie jedziesz po mnie, że nie mam wystarczającego poziomu do rozmowy. I z poziomem masz całkowitą rację, bo w tym temacie jestem praktycznie całkowitym laikiem, niestety z twoich wypowiedzi niczego się nie nauczę. Bierz też pod uwagę, że nie każdy zajmuje się obróbką wideo zawodowo. Ja to nawet nie nazwę tego hobby, ot mam kamerkę czy aparat i czasem coś potrzebuję przekodować, żeby gdzieś pokazać.

Ty masz wiedzę i możesz ją przekazać. Ja będąc laikiem mogę nie być w stanie zweryfikować rad "doradzacza" w internecie. Ludzie mają różne doświadczenia, z różnym oprogramowaniem mają styczność. Tutaj widzę tylko przekrzykiwania się kto większe bzdury wypisuje, a nie argumenty, że ten a ten sposób kodowania jest ok, a ten wypluwa syf. Jakieś różnice w implementacji algorytmów muszą być skoro są tak skrajne opinie o jakości.
Nie wiem jak wygląda taka implementacja, czy to jest na poziomie sterowników i wykorzystania uniwersalnych jednostek obliczeniowych GPU/CPU, czy jest to wydzielony kawałek krzemu w układzie ze sztywno osadzonym algorytmem. Wydaje mi się, że jest to ten drugi przypadek, zarówno w przypadku NV i Intela, bo inaczej nie byłoby problemem odpalić jakikolwiek algorytm kompresji, a jednak poszczególne generacje kart czy procesorów mają tabelki kompatybilności z poszczególnymi algorytmami kompresji.

Godzinę temu, miemik napisał:

moje stare serce dostaje palpitacji jak to czytam więc wyłączam się z rozmowy

A zamiast tych żali o palpitacji możesz napisać co z tym stwierdzeniem jest nie tak? Jesteś w stanie opisać jak wygląda implementacja, czy jest sprzętowa (wydzielony kawałek krzemu), czy programowa np. na CUDA? No i czy to jest po stronie producentów kart/procesorów i ich sterowników, czy po stronie twórców oprogramowania?

[T_G 489]

"Jakieś różnice w implementacji algorytmów muszą być skoro są tak skrajne opinie o jakości.
Nie wiem jak wygląda taka implementacja, czy to jest na poziomie sterowników i wykorzystania uniwersalnych jednostek obliczeniowych GPU/CPU, czy jest to wydzielony kawałek krzemu w układzie ze sztywno osadzonym algorytmem. Wydaje mi się, że jest to ten drugi przypadek, zarówno w przypadku NV i Intela, bo inaczej nie byłoby problemem odpalić jakikolwiek algorytm kompresji, a jednak poszczególne generacje kart czy procesorów mają tabelki kompatybilności z poszczególnymi algorytmami kompresji."

i to jest punkt wyjścia do dyskusji, natomiast dalej nie widzę sensu tłumaczenia czegokolwiek kolesiowi który nie potrafi się odnieść do prostej rzeczy czy 2+2 policzone na cpu jest lepsze od 2+2 policzonego na gpu... a niestety dopiero jak ktoś rozumie podstawy to można mówić o implementacjach, algorytmach, sterownikach a nie sprowadzać dyskusję, do jakiś absurdów typu "nikt nie renderuje na gpu" co jest o tyle śmieszne, że w przypadku video jest raczej dokładnie odwrotnie

 

p.s. jeśli keplery w quadro całe lata nie miały wsparcia kodowania i dekodowania h264/h265 a wraz z kolejną wersją api cuda, wsparcie się pojawiło to co to oznacza ?

 

Edytowane 10 Lipca 2020 przez T_G

[Bono[UG] 1915]

19 minut temu, T_G napisał:

p.s. jeśli keplery w quadro całe lata nie miały wsparcia kodowania i dekodowania h264/h265 a wraz z kolejną wersją api cuda, wsparcie się pojawiło to co to oznacza ?

Że Nvidia rypie nas w kakao
Dla mnie oczywiste, że jest to rozwiązanie programowe w sterownikach oparte o GPGPU i pewnie da się dowolny algorytm w ten sposób dopalić kartą graficzną.

Edytowane 10 Lipca 2020 przez Bono[UG]
dodane "w sterownikach"

[T_G 489]

"Że Nvidia rypie nas w kakao "

wybacz, to właśnie odpowiedź dlaczego na labie nie ma sensu na publicu zaczynać poważnej dyskusji, zawsze ktoś to spłyci, inny dorzuci argument "gpu ssie" a kolejny wklei testy ze sklepu, który handluje sprzętem (jako te wiarygodne i miarodajne) i zostaje ripostowanie postów z tyłka rodem

 

[Kyle_PL 3761]

W dniu 4.07.2020 o 13:52, skypan napisał:

Wszystko zamyka się w proporcjach piksela Rozdzielczość 720x576 jest zapisana z innymi proporcjami piksela. Domyślnie ta rozdzielczość jest w proporcjach 4:3

Na DVD nie ma czegoś takiego jak domyślne proporcje. Albo przy tym 720x576 jest "flaga" by było 16:9, albo 4:3.

[skypan 2617]

Dlaczego nie ma już pogromców mitów ? Nie ma różnicy w jakości CPU vs GPU. Już kiedyś dawałem dwa pliki kodowane CPU vs GPU i nikt nie potrafił znaleźć różnicy w jakości. Materiał można przeanalizować klatka po klatce. Jak ktoś chce udowodnić swoją mylną teorię o wyższości CPU nad GPU mogę ponownie udostępnić takie nagrania.

[Kyle_PL 3761]

2 minuty temu, skypan napisał:

Dlaczego nie ma już pogromców mitów ? Nie ma różnicy w jakości CPU vs GPU. Już kiedyś dawałem dwa pliki kodowane CPU vs GPU i nikt nie potrafił znaleźć różnicy w jakości.

Czy oba pliki wynikowe miały podobną wielkość? Czy jakość kompresji ustawiłeś na najwyższą możliwą (tam pamiętam była kiedyś nastawa od Q1 do Q9 i im niższe Q tym wyższa jakość, ale dłuższy czas kompresowania - można było przy tym samym bitrate, przy tym samym codec, uzyskać różną jakość).

Edytowane 10 Lipca 2020 przez Kyle_PL

[skypan 2617]

4 minuty temu, Kyle_PL napisał:

Na DVD nie ma czegoś takiego jak domyślne proporcje. Albo przy tym 720x576 jest "flaga" by było 16:9, albo 4:3.

Dość mocno uprościłem to zdanie. Zgadza się. Jednak proporcje piksela są różne dla 16:9 i 4:3.

Teraz, Kyle_PL napisał:

Czy oba pliki wynikowe miały podobną wielkość? Czy jakość kompresji ustawiłeś na najwyższą możliwą (tam pamiętam byłą kiedyś nastawa od Q1 do Q9, i im niższe Q tym wyższa jakość - można było przy tym samym bitrate uzyskać różną jakość).

A jaki sens było by robienie testu gdyby ustawienia były różne ?

[deton24 50]

4 godziny temu, Bono[UG] napisał:

Ja z chęcią się dowiem jakim programem (najlepiej darmowym) mogę sobie szybko i dobrze, a może i wygodnie, przemielić filmiki nagrywane kamerką. Obecnie korzystam tylko z ffmpeg i to jest katorga jeżeli chodzi o czas obróbki. Zmusić do akceleracji sprzętowej nie udało mi się i nawet nie wiem czy coś źle ustawiam, czy np. Nvidia wspaniałomyślnie blokuje pewne rzeczy (z tego co wyczytałem, to w pewnym momencie usunęli jakieś kodeki na CUDA ze sterowników).
Niestety id ciebie taka informacja nie wychodzi, jedziesz tylko po ludziach, z którymi się nie zgadzasz.

Zobacz najwyżej płatne Nero Video. Jest trial. Tylko nie żadna wersja portable, bo akceleracja na GPU nie zadziała. Przy GCN i C2Q kiedyś to robiło robotę. Nie wiem jak przy GTX 9XX.

Ew. jeśli "zmielenie" plików ma polegać tylko na ich scaleniu bez kompresji, to polecam MKVToolnix, gdzie bezproblemowo się przytnie dowolny plik, a także scali do jednego MKV wiele innych plików w różnych formatach (ale raczej jednym w obrębie jednego kontenera MKV). Ale generalnie to, co potrafi Toolnix, prawdopodobnie ffmpeg też powinien potrafić.

Edytowane 10 Lipca 2020 przez deton24

[Kyle_PL 3761]

6 minut temu, skypan napisał:

A jaki sens było by robienie testu gdyby ustawienia były różne ?

Chodzi o ustawienie maksymalnej jakości kompresji w codec CPU i maksymalnej jakości w codec GPU (i taki bitrate, by w obu przypadkach wielkość pliku wynikowego była taka sama) - nie wiem, czy obie wersje mają dokładnie identyczny zakres nastaw.

Edytowane 10 Lipca 2020 przez Kyle_PL

[Bono[UG] 1915]

33 minuty temu, T_G napisał:

"Że Nvidia rypie nas w kakao "

wybacz, to właśnie odpowiedź dlaczego na labie nie ma sensu na publicu zaczynać poważnej dyskusji, zawsze ktoś to spłyci, inny dorzuci argument "gpu ssie" a kolejny wklei testy ze sklepu, który handluje sprzętem (jako te wiarygodne i miarodajne) i zostaje ripostowanie postów z tyłka rodem

Piję tutaj do tego co zwykły konsument dostaje w pakiecie, kiedy nie ma przeszkód technicznych, żeby kara obsłużyła ale w sterownikach tego nie dają. Gdyby wszystko było cacy, to nie byłoby takich tabelek: https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
Do Quadro na Keplerze wspierającego h265 się nawet nie przyznają, a h264 częściowo.

PS. No chyba że ciągle rozmawiamy o innych rzeczach. Tutaj w tabelce jest NVENC/DEC i jeżeli wierzyć tabelce, to jest związany sprzętowo (#of chips), a ty mówisz o profesjonalnych narzędziach jadących na rdzeniach CUDA.

13 minut temu, deton24 napisał:

Ew. jeśli "zmielenie" plików ma polegać tylko na ich scaleniu bez kompresji, to polecam MKVToolnix, gdzie bezproblemowo się przytnie dowolny plik, a także scali do jednego MKV wiele innych plików w różnych formatach (ale raczej jednym w obrębie jednego kontenera MKV). Ale generalnie to, co potrafi Toolnix, prawdopodobnie ffmpeg też powinien potrafić.

Cięcie i sklejanie w ffmpeg spokojnie się robi, choć jest dłubanina z parametrami przy łączeniu.

Mielenie, to różnie potrzeba, raz wystarczy przyciąć, innym razem wyciąć fragmenty, a jeszcze innym przekompresować w innej rozdzielczości i jakości.

Edytowane 10 Lipca 2020 przez Bono[UG]

[deton24 50]

MKVToolnix nie wymaga specjalnego dłubania przy żadnych parametrach przy łączeniu. Ładne GUI jest. Czasem jedynie kolejność importowanych plików potrafi się pomieszać. Jedynie przycinanie trzeba ustawiać w jakimś okienku na podstawie danych czasowych, a nie w jakimś ładnym edytorze.

Edytowane 10 Lipca 2020 przez deton24

[skypan 2617]

Teraz video potraktowane CPU i GPU

https://mab.to/arIOBen1j

Dla odmiany w HEVC. Oczywiście ustawione identycznie. Jednak algorytm potraktował to wideo tak a nie inaczej ciut jest różny bitrate. Jednak jest na tyle marginalny, że nie ma znaczenia. No ale oczywiście ci co mówią, że GPU jest gorsze od CPU to wychwycą i pokażą tą fatalną jakość. Nagranie 4K, sporo detali. Jest co analizować i punktować.

[Bono[UG] 1915]

Ściągnąłem nowszą wersję ffmpeg i akceleracja zadziałała, koduje się ~7x szybciej.

Oczywiście jest ale czyli jakość wideo na wyjściu. Na najbardziej domyślnych ustawieniach na h264_nvenc wychodzi nawet nie wielka kupa - sieczka pixelozy.
Ok spojrzenie na bitrate i ze źródłowego 100Mb/s wypluło mi w 4Mb/s. Liczone na CPU domyślnie wypluwa mi bitrate około źródłowego
Ok, wymusiłem 40Mb/s ale nadal jest różnica w jakości. Wyjściowy bitrate na CPU jest o kilka Mb/s wyższy, co nie powinno zasadniczo zmieniać jakości. Niemniej liczone na GPU wypluwa widoczną kompresję, spłaszczenie jednolitych powierzchni, gubi się detal.

Użyte polecenia:

ffmpeg -i plik_wejsciowy.mp4 -t 20 -b:v 40M plik_wyjsciowy.mp4
ffmpeg -i plik_wejsciowy.mp4 -t 20 -c:v h264_nvenc -b:v 40M plik_wyjsciowy.mp4

Zrzuty z odtwarzania: https://drive.google.com/drive/folders/16z6Mv15wLlKWFaEUIAGYsgTU-_1WHoT9?usp=sharing
Dorzuciłem też filmy.

Na razie nie zagłębiałem się w dodatkowe opcje, więc nie wiem ile da się wycisnąć z kodowania przy pomocy GPU. Na domyślnych ustawieniach jest słabo i wtedy nie dziwne, że opinie o takim kodowaniu negatywne.
Ja nie jestem na razie w stanie rozstrzygnąć, na razie stawiam na kiepskie domyślne parametry.

Edytowane 10 Lipca 2020 przez Bono[UG]

[Kyle_PL 3761]

@Bono - na Twoich filmach widać ogromną przewagę wersji zakodowanej przy pomocy CPU.

@skypan - użyłeś tak ogromnego bitrate, dla stosunkowo mało wymagającego materiału (co prawda 4K, ale przy skaczącym ~25 FPS, bitrate ponad 50 Mbit, HEVC), że nawet przy znacznie gorszym jakościowo kodowaniu nie będzie widocznych różnic, szczególnie że kamera nie jest najwspanialszych lotów, bo niuanse na fakturach rozmywa.

Edytowane 13 Lipca 2020 przez Kyle_PL

[skypan 2617]

Kyle jeżeli bitrate  ok 50 Mbps przy 4K to dużo to chyba nie wiedziałeś większego. Mam stary sprzęt który może nagrywać w "skaczącym" 25p w FHD z bitrate 50 Mbps lub większym. To co napisałeś tylko potwierdza to, że osoby twierdzące, że CPU lepiej koduje niż GPU nic prócz pustych słów nie mają. Jeżeli CPU "liczyło" by lepiej to na tym nagraniu powinno to widać. A nie widać.

To teraz FHD z niskim bitrate

https://mab.to/NfMjVjMLa

Nagranie powiedzmy w profilu "średnio płaskim" bez żadnej edycji wyplute z HandBrake

 

Edytowane 13 Lipca 2020 przez skypan

[Bono[UG] 1915]

Bitrate nie jest kluczowy (przy sensownych różnicach, a nie np. 100Mb/s vs 12Mb/s), co widać na tym co wyżej dałem i z moich wcześniejszych doświadczeń kamerka vs bezlusterkowiec.

SJCAM SJ8Pro dawała mi przy modyfikowanym oprogramowaniu około 24-36Mb/s, Panas GX9 niecałe 40Mb/s. Jakość nieporównywalnie lepsza na aparacie i nie wynikało to ze znacznie lepszej optyki i matrycy. Kamerka odstawiała kaszanę przy kompresji, gdzie doskonale było widać kiedy szła "keyframe" i szum kompresji na chwilę znikał, a był to kodek h265, gdzie w aparacie h264.

Ja bym chętnie podrążył, co w ffmpeg przy użyciu gpu idzie nie tak, że tak słabo to wygląda. Czy to sam program domyślnie tak kiepskie parametry bierze, czy to słaba implementacja ze sterowników, czy jeszcze inny czort. Czy da radę dać takie ustawienia, że jakość wyjdzie podobna i nadal będzie się szybciej liczyło, czy nie.