Skocz do zawartości
13x0r

ffmpeg: zmniejszanie plików wideo

Rekomendowane odpowiedzi

Chciałbym trochę ujednolicić i przy okazji zmniejszyć posiadane przeze mnie pliki wideo w formacie mp4 - wszystkie wyświetlają się w formacie 16:9, jednak część z nich jest "wyższa" (720 pixeli w pionie) a część "niższa" (576 pixeli w pionie). Próbując przekonwertować "wyższe" pliki do "niższych" przy pomocy ffmpeg trafiłem na jedną zastanawiającą dla mnie rzecz: pliki "wyższe" mają rozdzielczość 1280x720 i po konwersji (bez utraty proporcji ekranu) robi się z tego 1024x576, natomiast te "niższe" mają 720x576 (czyli mimo że wyświetlają się jako 16:9 nie są 16:9?) - czy ktoś moze mi wytłumaczyć o co tu chodzi?

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

Wszystko zamyka się w proporcjach piksela :) Rozdzielczość 720x576 jest zapisana z innymi proporcjami piksela. Domyślnie ta rozdzielczość jest w proporcjach 4:3 ale by było można zapisać film z innymi proporcjami obrazu np. 16:9 piksele mają inne proporcje. Takie "masło maślane" ;) Niektóre programy edycyjne "widzą" nagranie 720x576 własnie jako 1024x576 jeżeli faktycznie zostało nagrane w proporcjach 16:9. I to jest dobrze. Inne  podają rozdzielczość 720x576 ale we właściwościach zawarta jest informacja o proporcjach piksela - Pixel Aspect Ratio - to też jest dobrze. W obu przypadkach obraz wyświetli się jako 16:9.

Podsumowując. Jest dobrze.

Edytowane przez skypan

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

@skypan Dziekuję za wytłumaczenie, jednak pojawia mi się kolejne pytanie.

Jeśli mam zamiar zmniejszyć pliki 1280x720 do wysokości 576 pixeli w pionie, to (zakładając ten sam rozmiar pliku wynikowego) który format da mi lepszą wizualnie odczuwalną końcową jakość? Ten który wychodzi mi "domyślnie" (1024x576) czy też powinienem postarac się o uzyskanie 720x576?

Na mój "chłopski rozum" (nie mam zbyt dużego doświadczenia w konwersji plików) wydaje mi się że 1024x576, ponieważ "wszystkie" dane są w obrazie i odtwarzacz nie musi sobie "dorabiać" dodatkowych pionowych linii (aby uzyskać 16:9), ale z drugiej strony poszczególne klatki w formacie 720x576 zawierają mniej danych to może przy tym samym rozmiarze będą one lepszej jakości?

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Przy łączeniu różnych rozdzielczości najlepiej dostosować się do "większości". Przynajmniej ja tak robię. W twoim przypadku (wg tego co napisałeś) pozostał bym w rozdzielczości 1280x720. Rozdzielczość to raz a dwa to ilość k/s (FPS) Tu też warto by było zobaczyć jaki klatkaż wybrać. No chyba, że nagrania są w jednym klatkażu. Teraz tak do kupy:

1. Rozdzielczość 1208x720. Poniżej nie ma sensu. Największy wpływ na wielkość będzie miał bitrate

2. Wybór ilości klatek

3. Osobiście do tego tupu "zadania" użyłbym normalnego programu do montażu z odpowiednio ustawionym projektem. Można skorzystać z Davinci Resolve wersja Free https://www.blackmagicdesign.com/products/davinciresolve/ Nie przejmuj się złożonością tego programu. To co chcesz zrobić zrobisz w paru krokach:

- ustawienie projektu ze zwróceniem uwagi na rozdzielczość i ilość k/s

- import klipów do programu

- położenie klipów na oś montażową

- eksport do mp4

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

@skypan Na początku napiszę kilka dodatkowych wyjaśnień:

- zdecydowana większość moich plików ma rozmiar 720x576 lub zbliżony (odnosząc się do tego co napisałeś o "większości")

- nie są to jakieś "arcyważne" pliki - chciałbym je zachować w celach archiwizacyjnych (gdybym jeszcze musiał kiedyś do nich wrócić)

- rozmiar plików 1280x720 jest ponad dwa razy większy niż 720x576, a po konwersji 1280x720 do 1024x576 "nie zauważam różnicy"

 

Myślę więc, że zdecyduję się na takie "lekkie zmniejszenie", jednak wciąż pozostaje pytanie z mojego poprzedniego postu: 1024x576 czy 720x576? Co da mi ostatecznie lepszą wizualnie jakość?

Spróbowałem przekonwertować jeden z plików na oba formaty i chyba 1024x576 wydaje mi się ciut lepszy jakościowo - czy to może być jedynie siła sugestii?

Przeczytałem, że format 720x576 jest też jakimś powszechnie ustanowionym standardem (znacznie powszechnieszym od 1024x576) - może z tego powodu to w niego "powinienem zainwestować"?

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

W taki razie zostań przy 1024x576

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)
W dniu 3.07.2020 o 21:36, 13x0r napisał:

zastanawiającą dla mnie rzecz: pliki "wyższe" mają rozdzielczość 1280x720 i po konwersji (bez utraty proporcji ekranu) robi się z tego 1024x576, natomiast te "niższe" mają 720x576 (czyli mimo że wyświetlają się jako 16:9 nie są 16:9?) - czy ktoś moze mi wytłumaczyć o co tu chodzi?

Jedno i drugie to 16:9. Po prostu inna rozdzielczość natywna (720 jest bliżej SD, 1280 to HD, wiadomo).

Nie musisz robić downscalingu, jeśli chcesz niższą wagę pliku. Wystarczy użyć wyższego CRF przy kodowaniu.

Spróbuj czegoś takiego:

Cytat

pushd %~dp0

echo Encoding 720p ...
ffmpeg.exe -i "%~1" -vf scale=1280x720:flags=spline,format=yuv420p, -map_metadata -1 -movflags faststart -c:v libx264 -profile:v main -level:v 4.0 -preset medium -crf 20 -maxrate 20M -bufsize 25M -x264-params colormatrix=bt709 -c:a copy "%~n1_720p.mp4"

popd

echo Done.

PAUSE

Jak dalej będzie za dużo to:

preset slow

crf 22

Edytowane przez Kamiyan

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Po co się tak trudzić, polecam FormatFactory 5.3, sam używam, ustawisz tam wszystko jak chcesz, program jest intuicyjny oraz prosty, no i najnowsza wersja wykorzystuje moc GPU i CPU, możesz nawet kodować w 8K i H265 nie ma problemu. :)

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Ja bym podszedł do sprawy w jeszcze inny sposób, czyli czy gra w ogóle wara świeczki?
Ile tych nagrań jest? Jak długo się będzie przekodowywać jedno, ile czasu zajmie przemielenie wszystkich?
Ile zajmują miejsca na dysku, ile się zwolni?

Jeżeli zajmują powiedzmy 50GB, przeliczy się to w 1000h i zwolni 5GB, to zdecydowanie szkoda czasu na taką zabawę.
Przy 100GB, czasie konwersji 100h i zwolnieniu połowy miejsca, to może warto się bawić.
Przy średnich zarobkach 4000 na rękę, dysk 4TB to jakieś dwa dni pracy. Przy takich rozdzielczościach bitrate pewnie też nie jest wysoki, więc taki dysk starczy na lata.

Jak na razie bawiłem się tylko ffmpeg i kodowanie na moim Haswellu trwa wieki (ok, mam "trochę" większe rozdzielczości, bo 1080, 1440 i 2704 (jak dla mnie dziwna no ale taką ma kamerka) w większości w 60kl/s). Jeżeli materiału jest dużo, to będzie mordęga przemielić to wszystko.
Jak Davinci Resolve  czy FormatFactory potrafią skorzystać lepiej z akceleracji sprzętowej, to może będzie lepiej ale warto brać pod uwagę ile będzie z tym zabawy i czy efekt jest jakiś sensowny.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

@Bono[UG] FormatFactory koduje 30 min film z 1920p na 720p przy użyciu mojego GPU 1050Ti i CPU FX6300 w 2 min, to pokazuje jakie potężne są dzisiaj GPU. :)

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

To będę musiał się pobawić.

Nie poszaleję. 4min materiał 2.7k @60 do 1080@60 h264 przemielił w 10min...
Wygląda, że zupełnie nie potrafi wykorzystać akceleracji sprzętowej. Przy testowaniu wypisuje, że nic nie jest wspierane, ani Nvidiowe ani Intelowskie kodowanie :(
Procesor to Xeon E3-1225v3 (Haswell z iGPU), GPU GTX970.

Edytowane przez Bono[UG]

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Uuu u mnie wspiera kodowanie nVidii musiałem tylko nowsze stertowniki zainstalować i działa od 436.15, pewnie wspiera akceleracje od serii Pascal dopiero.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
W dniu 8.07.2020 o 16:37, Stjepan napisał:

@Bono[UG] FormatFactory koduje 30 min film z 1920p na 720p przy użyciu mojego GPU 1050Ti i CPU FX6300 w 2 min, to pokazuje jakie potężne są dzisiaj GPU. :)

GPU akurat nie potrafi kodować. Ogólnie nie jest to zalecane w żadnym wypadku. FF to też kijowy program, bo prosty skrypt w .bat zrobi to lepiej. Wystarczy użyć FFmpega i dać dobre CRF.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Tylko skrypty trzeba umieć pisać, a przeciętna osoba korzystająca z Windy nie potrafi.

Odnośnie jakości, to nie wiemy jaki jest materiał wejściowy. Z jakością też nie ma co przesadzać, bo się zaraz okaże że po zmniejszeniu rozdzielczości pliki i tak wyszły większe, bo bitrate wyjdzie wyższy niż był.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

"GPU akurat nie potrafi kodować. Ogólnie nie jest to zalecane w żadnym wypadku" - możesz rozwinąć zagadnienie ?

 

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Godzinę temu, Bono[UG] napisał:

Tylko skrypty trzeba umieć pisać, a przeciętna osoba korzystająca z Windy nie potrafi.

Temu podrzuciłem skrypt.

43 minuty temu, T_G napisał:

"GPU akurat nie potrafi kodować. Ogólnie nie jest to zalecane w żadnym wypadku" - możesz rozwinąć zagadnienie ?

CPU encoding is focused on quality where GPU encoding is focused on speed - if you can accept lower quality or higher final bitrate then GPU encoder will be faster, if your goal is highest possible quality at lowest possible bitrate then CPU based encoder will be closer to your goal at a cost of encoding time.

Podobnie jest przy dekodowaniu przez NVDEC – odciążasz CPU, ale obraz jest gorszy.

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

tak myślałem... zacytowana jakaś kupa z internetu bez ładu i składu, bo gdzieżby jakieś odniesienie do porównań algorytmów, engineów itp. 

 

  • Upvote 1

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
2 godziny temu, Kamiyan napisał:

Temu podrzuciłem skrypt.

CPU encoding is focused on quality where GPU encoding is focused on speed - if you can accept lower quality or higher final bitrate then GPU encoder will be faster, if your goal is highest possible quality at lowest possible bitrate then CPU based encoder will be closer to your goal at a cost of encoding time.

Podobnie jest przy dekodowaniu przez NVDEC – odciążasz CPU, ale obraz jest gorszy.

Czizus krajz - te brednie już dawno zostały obalone ...

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)
13 minut temu, miemik napisał:

Czizus krajz - te brednie już dawno zostały obalone ...

To sobie przełącz w MPV na NVDEC i zobacz, jak ci obraz sypie.

Nie wiem, przez kogo to niby miało być obalone. Żaden normalny koder nie używa GPU.

27 minut temu, T_G napisał:

tak myślałem... zacytowana jakaś kupa z internetu bez ładu i składu, bo gdzieżby jakieś odniesienie do porównań algorytmów, engineów itp. 

I co chcesz konkretne porównywać? To, że GPU ssie przy x264? Przecież to jest oczywistość.

Nie wiem, za ile lat GPU będzie zdolne kodować na akceptowalnym poziomie. Jak chcesz robić kupiasty encode na jakimś 20-letnim Xividzie, to wszystko może być. Nawet Handbrake.

Edytowane przez Kamiyan

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

nie wiem kto to jest normalny koder bo w twoim przypadku ani normalny ani koder... rozumiem, że 2+2 policzone na rdzeniach cpu jest lepsze niż 2+2 policzone na rdzeniach gpu ?

czyli enkodowanie do bezstratnego profilu h265 (nie mówiąc już o kompresjach bezstratnych albo 7-zipie dla porównania), 5 razy szybsze (gpu vs cpu) jest gorsze ?

język na poziomie gimnazjum ale nie wiem za ile lat będziesz zdolny wiedzę z gimnazjum przyswoić

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)
9 minut temu, T_G napisał:

język na poziomie gimnazjum ale nie wiem za ile lat będziesz zdolny wiedzę z gimnazjum przyswoić

To pewnie dlatego nie zaczynasz zdań wielką literą i nie słyszałeś o podstawowych zasadach interpunkcji? Litości.

9 minut temu, T_G napisał:

nie wiem kto to jest normalny koder bo w twoim przypadku ani normalny ani koder... rozumiem, że 2+2 policzone na rdzeniach cpu jest lepsze niż 2+2 policzone na rdzeniach gpu ?

czyli enkodowanie do bezstratnego profilu h265 (nie mówiąc już o kompresjach bezstratnych albo 7-zipie dla porównania), 5 razy szybsze (gpu vs cpu) jest gorsze ?

Tak, bo to inny kodek. Mam ci podstawy tłumaczyć jak krowie na rowie?

Co to znaczy profil "bezstratny"? Zagadka dla laika, bo widzę, że w ogóle nie ogarniasz tematu – czy przekodowanie w CRF 0 oznacza, że encode jest naprawdę bezstratny? O ile w ogóle wiesz, o czym mówię.

Edytowane przez Kamiyan
  • Upvote 1

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

to przykre, że nie wie wiesz co to jest bezstratny profil lub kompresja bezstratna, to przykre, że ograniczyłeś się do skryptów i ffmpega, którego zasad działania też nie rozumiesz, to przykre, że jak ogarniesz wiedzę na poziomie gimnazjum to się dowiesz, że temat jest "nieco" szerszy

w sumie podsumowując twoją wiedzę i porady ... to przykre

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)

Kolego a może Tobie o render na iqsv chodzi ? 

Edytowane przez miemik

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach
Napisano (edytowane)
20 minut temu, T_G napisał:

to przykre, że nie wie wiesz co to jest bezstratny profil lub kompresja bezstratna, to przykre, że ograniczyłeś się do skryptów i ffmpega, którego zasad działania też nie rozumiesz, to przykre, że jak ogarniesz wiedzę na poziomie gimnazjum to się dowiesz, że temat jest "nieco" szerszy

w sumie podsumowując twoją wiedzę i porady ... to przykre

To w końcu encode czy konwersja? Bo jak nie rozróżniasz pojęć, to szkoda mi czasu na tę rozmowę.

A najbardziej przykre jest moim zdaniem używanie spacji przed i po wielokropku. Mnie tam w gimnazjum zasad pisowni uczyli.

14 minut temu, miemik napisał:

Kolego a może Tobie o render na iqsv chodzi ? 

Ech, najprościej jak się da – czy Xvid i h264 przy tym samym bitrejcie będą wyglądać tak samo czy nie?

No to tak samo jest z kodowaniem sprzętowym.

Edytowane przez Kamiyan
  • Upvote 1

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

nie odróżniasz kompresja/konwersja ? czy nie rozumiesz, że z mp4-ek zrobienie kolejnych mp4-ek to konwersja i enkodowanie ? z postu na post co raz większa kupa a te rozszerzone zasady pisowni to chyba na matematyce miałeś

 

 

Udostępnij tę odpowiedź


Odnośnik do odpowiedzi
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się

  • Ostatnio przeglądający   0 użytkowników

    Brak zarejestrowanych użytkowników przeglądających tę stronę.

×
×
  • Dodaj nową pozycję...