Forum

Kodowanie Mac Mini M1 H.265?

SWAON

Oryginalny plakat
2 września 2017 r.
Europa
  • 19 lis 2020
Cześć ludzie,

Mam dużą kolekcję seriali na iTunes i chciałbym przekonwertować wszystkie filmy H.264 na H.265, aby zmniejszyć moje miejsce na dane. Z tego powodu rozważyłbym zakup Maca Mini M1. Do tych, którzy już to kupili, czy ktoś próbował przekonwertować x264 na x265 i powiedzieć mi, jak poszło? Jakiego oprogramowania używałeś (np. Hamulec ręczny lub inne imprezy 3D?), jakie uzyskałeś wyniki i tak dalej. Naprawdę byłbym wdzięczny za wszelkie informacje na ten temat, ponieważ jest to moja najważniejsza uwaga dotycząca mojego zakupu. Z góry dziękuję.
Reakcje:Minijabłko m

MadCar

21 paź 2014


Internet
  • 19 lis 2020
Rzuciłbym okiem na fora Plex. Wydają się być bardzo zadowoleni z wydajności, nawet z aplikacjami działającymi pod Rosettą, więc wydaje się to bardzo pozytywne w odniesieniu do kodowania za pomocą M1 Mini.
Reakcje:SWAON m

MadCar

21 paź 2014
Internet
  • 19 lis 2020
Oto wątek, który może Ci się przydać.

Plex Media Server działający na chipsecie Apple Silicon M1, tj. nowy Mac mini, MacBook itp.

@Balthazar2k4 Mam Maca mini M1 8GB, który będzie moim zamiennikiem Plex Media Server, ponieważ mój Mac mini 2012 nie może działać w nieskończoność. Niestety po prostu nie mogę uruchomić PMS. Jeśli go uruchomię, mogę uzyskać najkrótsze migotanie szewronu Plex na pasku menu, a potem nic. Nie ma nawet komunikatu o błędzie... fora.plex.tv
Również hamulec ręczny ma teraz natywną aplikację M1 w wersji beta.

Wersja 1.4.0 Beta Universal Binary dla macOS · HandBrake/HandBrake 8
Reakcje:zoltm, ElectronGuru, T'hain Esh Kelch i 2 innych

SWAON

Oryginalny plakat
2 września 2017 r.
Europa
  • 19 lis 2020
MadCar powiedział: Również hamulec ręczny ma teraz natywną aplikację M1 w wersji beta.

Wersja 1.4.0 Beta Universal Binary dla macOS · HandBrake/HandBrake 8
Dzięki za link do plexa. Wygląda na to, że pierwsze wrażenia z jazdy z hamulcem ręcznym z Rosettą 2 były pozytywne. Nie wiedziałem, że zaczęli już robić beta M1. Dobra robota zespołu.

ShredDude

30 lis 2020
  • 30 lis 2020
Przeprowadziłem dość obszerne testy z natywną aplikacją HandBrake na M1. Możesz zrobić szalenie szybkie (180-220 fps) kodowanie sprzętowe za pomocą VideoToolbox dla treści HD (x264/265), ale rozmiar i jakość pliku nie są optymalne. Przy kodowaniu programowym 264->265 1080p działa około 30 klatek na sekundę, co nie jest złe! Te same ustawienia w ffmpeg pod Rosettą dają około 15 FPS. Kodowanie oprogramowania prawie pochłania wszystkie moje rdzenie, ale system pozostaje responsywny. To dosłownie jedyna rzecz, która może sprawić, że moi fani MBP się włączą, i chłopcze, czy oni kiedykolwiek.
Reakcje:SamRyouji, Frank Philips i SWAON

SWAON

Oryginalny plakat
2 września 2017 r.
Europa
  • 1 grudnia 2020 r.
ShredDude powiedział: Przeprowadziłem dość obszerne testy z natywną aplikacją HandBrake na M1.
Czy używasz nowej wersji beta czy starej wersji Intel dla hamulca ręcznego?

ShredDude

30 lis 2020
  • 1 grudnia 2020 r.
SWAON powiedział: Czy używasz nowej wersji beta czy starej wersji Intel dla hamulca ręcznego?
Wersja beta 1.4.0-beta.1 (2020111100)
Reakcje:SWAON D

dhy8386

13 sierpnia 2008
  • 3 grudnia 2020
ShredDude powiedział: Przeprowadziłem dość obszerne testy z natywną aplikacją HandBrake na M1. Możesz zrobić szalenie szybkie (180-220 fps) kodowanie sprzętowe za pomocą VideoToolbox dla treści HD (x264/265), ale rozmiar i jakość pliku nie są optymalne. Przy kodowaniu programowym 264->265 1080p działa około 30 klatek na sekundę, co nie jest złe! Te same ustawienia w ffmpeg pod Rosettą dają około 15 FPS. Kodowanie oprogramowania prawie pochłania wszystkie moje rdzenie, ale system pozostaje responsywny. To dosłownie jedyna rzecz, która może sprawić, że moi fani MBP się włączą, i chłopcze, czy oni kiedykolwiek.

Widząc dokładnie to samo. Nie porównywałem jeszcze szczegółowo jakości VT z x265, ale test wzroku, wersja VT musiała być zakodowana w 8K+ BR, aby uzyskać porównywalną jakość do x265, która była bliższa 2K BR. I oczywiście wynikowy plik 9 GB vs plik 2,3 GB.
Reakcje:SWAON

Admirał

14 kwi 2015
  • 9 grudnia 2020 r.
ShredDude powiedział: Przeprowadziłem dość obszerne testy z natywną aplikacją HandBrake na M1. Możesz zrobić szalenie szybkie (180-220 fps) kodowanie sprzętowe za pomocą VideoToolbox dla treści HD (x264/265), ale rozmiar i jakość pliku nie są optymalne. Przy kodowaniu programowym 264->265 1080p działa około 30 klatek na sekundę, co nie jest złe! Te same ustawienia w ffmpeg pod Rosettą dają około 15 FPS. Kodowanie oprogramowania prawie pochłania wszystkie moje rdzenie, ale system pozostaje responsywny. To dosłownie jedyna rzecz, która może sprawić, że moi fani MBP się włączą, i chłopcze, czy oni kiedykolwiek.

Robię teraz kodowanie programowe x264 -> x265 na moim nowo przybyłym 8 GB RAM Mac mini M1, a wydajność pod Handbrake 1.4 beta 1 wydaje się być na równi z moim 2018 32 GB RAM Mac mini 6-core i7 w pod względem liczby klatek na sekundę (w tej chwili pracują na tym samym pliku), co jest nieco mniej, niż się spodziewałem na podstawie zgłoszonych wyników Geekbench, ale Mac mini M1 pozostaje bardzo responsywny, a jego wentylator, chociaż działa, pozostaje cichy i z urządzenia wydobywa się bardzo mało ciepła — albo z obudowy, albo z tylnego otworu wentylacyjnego. Porównaj z i7 mini, który jest bardzo ciepły w dotyku, z podmuchem gorącego powietrza z tylnego otworu wentylacyjnego. Wentylator i7 jest bardzo słyszalny.

Prawdziwa istota tego jest taka, że ​​Macbook Pro M1, który również ma wentylator i dlatego będzie działał praktycznie identycznie jak Mac mini M1, całkowicie zniszczy 13-calowego 4-rdzeniowego Macbooka Pro i5, którego właśnie kupiłem w czerwcu. Ale w oparciu o wydajność M1 myślę, że utrzymam suchy proszek w przypadku rzekomych modeli M1X lub M1Z, które powinny zaczynać się co najmniej o 70% szybciej niż M1. Dobre czasy. Ostatnia edycja: 9 grudnia 2020
Reakcje:ElectronGuru i SWAON

SWAON

Oryginalny plakat
2 września 2017 r.
Europa
  • 10 grudnia 2020 r.
Admirał powiedział: Myślę, że utrzymam suchy proszek w przypadku rzekomych modeli M1X lub M1Z, które powinny zaczynać się co najmniej o 70% szybciej niż M1. Dobre czasy.
Planuję zrobić to samo.. Dziękuję za komentarz Reakcje:SWAON P

pmile

12 grudnia 2013 r.
  • 18 grudnia 2020
Chyba nie chcesz transkodować z H.264 na H.265. Jeśli miałeś oryginalne źródło, a następnie transkodowałeś je do H.265, uzyskasz lepsze wyniki... H.264 jest już skompresowany (wyrzucił informacje do kompresji, które są tracone na zawsze). Próba skompresowania skompresowanego formatu tylko wyrzuca więcej informacji. Wyniki będą nieoptymalne.

Wątpię, czy chcesz zrezygnować z jakości miejsca na dysku… ponieważ gdybyś to zrobił, od samego początku użyłbyś bardziej agresywnego formatu kompresji.
Reakcje:zoltm, brucewayne, goodcow i 2 inne DO

apple_iBoy

28 października 2003 r.
Filadelfia, PA
  • 31 stycznia 2021
Admirał powiedział: Robię teraz kodowanie programowe x264 -> x265 na moim nowo przybyłym 8 GB RAM Mac mini M1, a wydajność pod Handbrake 1.4 beta 1 wydaje się być na równi z moim 2018 32 GB RAM Mac mini 6 core i7 pod względem liczby klatek na sekundę (obecnie pracują na tym samym pliku), co jest nieco mniej, niż się spodziewałem na podstawie zgłoszonych wyników Geekbench, ale Mac mini M1 pozostaje bardzo responsywny, a jego wentylator, chociaż działa, pozostaje cichy, a z urządzenia wydobywa się bardzo mało ciepła — albo z obudowy, albo z tylnego otworu wentylacyjnego. Porównaj z i7 mini, który jest bardzo ciepły w dotyku, z podmuchem gorącego powietrza z tylnego otworu wentylacyjnego. Wentylator i7 jest bardzo słyszalny.

Prawdziwa istota tego jest taka, że ​​Macbook Pro M1, który również ma wentylator i dlatego będzie działał praktycznie identycznie jak Mac mini M1, całkowicie zniszczy 13-calowego 4-rdzeniowego Macbooka Pro i5, którego właśnie kupiłem w czerwcu. Ale w oparciu o wydajność M1 myślę, że utrzymam suchy proszek w przypadku rzekomych modeli M1X lub M1Z, które powinny zaczynać się co najmniej o 70% szybciej niż M1. Dobre czasy.
Czy używasz predefiniowanego ustawienia x265 VideoToolBox w hamulcu ręcznym? To lata!
Reakcje:SWAON

Admirał

14 kwi 2015
  • 12 lut 2021
pmiles powiedział: Nie sądzę, że chcesz transkodować z H.264 na H.265. Jeśli miałeś oryginalne źródło, a następnie transkodowałeś je do H.265, uzyskasz lepsze wyniki... H.264 jest już skompresowany (wyrzucił informacje do kompresji, które są tracone na zawsze). Próba skompresowania skompresowanego formatu tylko wyrzuca więcej informacji. Wyniki będą nieoptymalne.

Wątpię, czy chcesz zrezygnować z jakości miejsca na dysku… ponieważ gdybyś to zrobił, od samego początku użyłbyś bardziej agresywnego formatu kompresji.

Z treściami, które sam stworzyłem, oczywiście zaczynam od własnego oryginalnego źródła, aby uzyskać najlepsze wyniki. Z treścią, którą ukradłem, muszę sobie poradzić.

Niezależnie od pochodzenia materiału źródłowego, uważam, że kodowanie programowe jest zdecydowanie lepsze niż kodowanie sprzętowe, niezależnie od producenta. Sprzętowe kodowanie h.264 i h.265 firmy Apple jest rzeczywiście niesamowite, ale oba są tak naprawdę odpowiednie tylko do przesyłania strumieniowego wideo na żywo. Co jest prawdziwym przypadkiem użycia — wybierz narzędzia, które zapewniają najlepsze wyniki dla tego, co chcesz zrobić.
Reakcje:SWAON

Botts85

9 lut 2007
  • 14 lut 2021
M1 leci w kodowaniu sprzętowym. Pali mojego i9 iMaca. Jest 3-4x szybszy (pod względem liczby klatek na sekundę) przy transkodowaniu H265.

Traci jednak jakość wideo na Intel Mac przy kodowaniu sprzętowym.

SWAON

Oryginalny plakat
2 września 2017 r.
Europa
  • 15 lut 2021
Jakiego oprogramowania używasz do kodowania? Przydałoby się to również wiedzieć

Botts85

9 lut 2007
  • 22 lut 2021
FF-Works i hamulec ręczny dla mnie.
Reakcje:SWAON

SWAON

Oryginalny plakat
2 września 2017 r.
Europa
  • 22 lut 2021
Botts85 powiedział: FF-Works i Handbrake dla mnie.
Nigdy nie używałeś FF-Works, jak to się ma do hamulca ręcznego?

Botts85

9 lut 2007
  • 26 lut 2021
SWAON powiedział: Nigdy nie używałem FF-Works, jak to się ma do hamulca ręcznego?
To surowy przód dla ffmpeg, więc nie jest tak wygodny jak hamulec ręczny.

Jest prawdopodobnie znacznie potężniejszy i bardziej konfigurowalny, jeśli chcesz coś poprawić.

Moim regularnym chodem jest jednak hamulec ręczny.
Reakcje:SWAON

phrehdd

25 paź 2008
  • 27 lut 2021
SWAON powiedział: przekonwertuj wszystkie filmy H.264 na H.265, aby zmniejszyć moje miejsce na dane
Czy chcesz wziąć plik H.264 i skompresować go ponownie za pomocą H.265? A może sugerujesz, że najpierw zdekompresujesz plik, a następnie ponownie skompresujesz za pomocą H.265? Pierwsze dałoby kiepskie wyniki, a drugie, nie wiem, jak to zrobić. Co ciekawe, obecnie przechowywanie jest dość tanie, więc nie ma pewności, dlaczego oszczędzanie miejsca jest problemem.
Reakcje:zoltm i SWAON

SWAON

Oryginalny plakat
2 września 2017 r.
Europa
  • 27 lut 2021
phrehdd powiedział: Czy chcesz wziąć plik H.264 i skompresować go jeszcze raz za pomocą H.265? A może sugerujesz, że najpierw zdekompresujesz plik, a następnie ponownie skompresujesz za pomocą H.265? Pierwsze dałoby kiepskie wyniki, a drugie, nie wiem, jak to zrobić. Co ciekawe, obecnie przechowywanie jest dość tanie, więc nie ma pewności, dlaczego oszczędzanie miejsca jest problemem.
Zastanawiałem się to samo, czy warto już konwertować filmy h.264 na pamięć h.265. Wygląda na to, że cały proces zajmuje znacznie więcej czasu i oszczędza stosunkowo niewiele miejsca. h

Honza1

30 listopada 2013 r.
nas
  • 27 lut 2021
H.264->H.265 prawdopodobnie nie jest warte wysiłku, chyba że musisz zrobić coś innego. Niektóre rzeczy H.264 mają absurdalnie wysokie przepływności. Jeśli trzeba coś zmienić, H.265 działa dobrze i M1 może to zrobić. Zarówno przy użyciu VideoToolbox (który jest absurdalnie szybki), jak i przy użyciu kodera programowego. Rozumiem, że chociaż VideoToolbox jest niezwykle szybki, nie jest tak dobry ani wydajny. Kodowanie oprogramowania w Handbrake (wersja beta dla M1) działa dobrze. Konwertuje z prędkością zbliżoną do rzeczywistej (30 kl./s), w zależności od materiału.
Reakcje:SWAON DO

Aleksyd1

14 listopada 2017 r.
  • 14 kwi 2021
Testowałem akcelerowane przez GPU kodowanie wideo na M1 Mac Mini (H.264 VideoToolBox) w trybie Handbrake Beta i stałej jakości (nowa funkcja dla komputerów M1 Mac, działa jak -crf w libx264).
Przy tym samym rozmiarze pliku i opcjach (FullHD, 60p), jakość wizualna znacznie gorsza niż w przypadku libx264 lub nvenc (NVIDIA). Zakodowałem H.264 z NVIDIA Geforce 1060 (nvenc H.264) i jakość wizualna była znacznie lepsza.
Wygląda więc na to, że koder wideo M1 jest zły. Niestety.

Botts85

9 lut 2007
  • 14 kwi 2021
Aleksid1 powiedział: Testowałem akcelerowane przez GPU kodowanie wideo na M1 Mac Mini (H.264 VideoToolBox) w trybie Handbrake Beta i stałej jakości (nowa funkcja dla komputerów M1 Mac, działa jak -crf w libx264).
Przy tym samym rozmiarze pliku i opcjach (FullHD, 60p), jakość wizualna znacznie gorsza niż w przypadku libx264 lub nvenc (NVIDIA). Zakodowałem H.264 z NVIDIA Geforce 1060 (nvenc H.264) i jakość wizualna była znacznie lepsza.
Wygląda więc na to, że koder wideo M1 jest zły. Niestety.
Z mojego doświadczenia w testowaniu wynika, że ​​M1 zbyt agresywnie rozkłada bitrate.

Kodowanie M1 o stałej jakości wygląda znacznie lepiej niż kodowanie QuickSync / NVENC w obszarach z ruchem, M1 daje im większy (zbyt duży) bitrate, ale M1 ma tendencję do wygładzania szczegółów, aby zaoszczędzić bitrate w statycznych scenach, przez co wyglądają trochę plastycznie .

Apple może to dostosować za pomocą oprogramowania układowego. DO

Aleksyd1

14 listopada 2017 r.
  • 14 kwi 2021
Dzięki za potwierdzenie. Testowałem również kodowanie HEVC w Handbrake z opcją M1 VideoToolBox, a jakość wizualna jest taka sama jak H.264 przy tym samym rozmiarze pliku. To bardzo dziwne. Nie widzę wizualnej różnicy między H.264/HEVC przy użyciu kodera VideoToolBox. Jakość naprawdę powinna zostać poprawiona przez Apple.
Reakcje:SWAON