A videokönyvtáramat HEVC formátumba konvertálom, hogy helyet szerezzek. A következő parancsot futtattam a könyvtáram összes videófájlján: 

 #!/bin/bash for i in *.mp4; do #Output new files by prepending "X265" to the names avconv -i "$i" -c:v libx265 -c:a copy X265_"$i" done

Most a legtöbb videó kiválóan konvertálódik, és a minőség ugyanaz, mint korábban. Néhány nagyon jó minőségű videó (pl. Egy 5 GB-os filmnyomtatás) minősége romlik – a videó mind pixeles.

Nem vagyok biztos benne, mit tegyek ebben az esetben. Módosítanom kell a parancssorom crf paraméterét? Vagy valami más?

A helyzet az, hogy tömeges átalakítást végzek. Szükségem van egy módszerre, ahol a avconv automatikusan beállítja az összes videó beállításához szükséges paramétert.

UPDATE-1

Megállapítottam, hogy crf az a gomb, amelyet be kell állítanom. Az alapértelmezett CRF 28. A jobb minőség érdekében 28-nál kevesebbet használhatok. Például: 

avconv -i input.mp4 -c:v libx265 -x265-params crf=23 -c:a copy output.mp4

Azonban a probléma az, hogy egyes videóknál CRF A 28-as érték elég jó, míg egyes videók esetében alacsonyabb CRF szükséges. Ezt manuálisan kell ellenőriznem a nagy videók kis szakaszainak konvertálásával. De tömeges átalakításban hogyan ellenőrizhetném manuálisan az egyes videókat? Van valamilyen módja annak, hogy avconv intelligensen beállíthatja a CRF-t a bemeneti videó szerint?

UPDATE-2

Megállapítottam, hogy van --lossless opció x265-ben: http://x265.readthedocs.org/en/default/lossless.html .

Azonban nem tudom, hogyan kell helyesen használni. A következő módon próbáltam használni, de ellentétes eredményeket hozott (a videó még pixelesebb volt): 

avconv -i input.mp4 -c:v libx265 -x265-params lossless -c:a copy output.mp4

Megjegyzések

  • --lossless valójában megnövelheti a fájlt, ha dekódolja a korábban veszteséges kodeket, majd titkosítja, amit veszteségmentesen dekódolt. A minőség pontosan ugyanaz marad, mint az input.
  • Ha a forrásait veszteséges kódolja (ami nagy valószínűséggel), akkor az, amit megpróbál elérni, lehetetlen. Bármilyen átkódolás, amely nem veszteségmentes, az tovább rontja a minőséget (még ha nem is látható azonnal Önnek), és ha veszteségesről veszteségmentesre konvertál, akkor nagyobb fájlméreteket kap .

Válasz

Saját tapasztalataim szerint, ha egyáltalán nem akar minőségromlást elérni, a – lossless is amit keres.

Nem biztos a avconv kérdésben, de a beírt parancs megegyezik azzal, amit a FFmpeg. A FFmpeg mezőben a következő módon adhatja át a paramétert: 

ffmpeg -i INPUT.mkv -c:v libx265 -preset ultrafast -x265-params lossless=1 OUTPUT.mkv

A legtöbb x265 kapcsolók (érték nélküli opciók) így adhatók meg (kivéve azokat a csak CLI-t használókat, amelyeket csak közvetlenül a x265 bináris fájlokkal használunk).

Ennek hiányában szeretném megosztani tapasztalataimat a x265 kódolással. A legtöbb videó esetében (legyen az WMV, MPEG vagy AVC) /H.264) A következőt használom: crf=23. x265 dönt a többi paraméterről, és általában elég jó munkát végez.

Azonban gyakran, mielőtt elkötelezném magam egy videó teljes átkódolása mellett, tesztelem a beállításokat a szóban forgó videó kis részének konvertálásával. Itt van egy példa, tegyünk fel egy mkv fájlt, amelynek 0 adatfolyam videó, 1. adatfolyam. mivel DTS audio, és a 2. adatfolyam felirat: 

ffmpeg -hide_banner \ -ss 0 \ -i "INPUT.mkv" \ -attach "COVER.jpg" \ -map_metadata 0 \ -map_chapters 0 \ -metadata title="TITLE" \ -map 0:0 -metadata:s:v:0 language=eng \ -map 0:1 -metadata:s:a:0 language=eng -metadata:s:a:0 title="Surround 5.1 (DTS)" \ -map 0:2 -metadata:s:s:0 language=eng -metadata:s:s:0 title="English" \ -metadata:s:t:0 filename="Cover.jpg" -metadata:s:t:0 mimetype="image/jpeg" \ -c:v libx265 -preset ultrafast -x265-params \ crf=22:qcomp=0.8:aq-mode=1:aq_strength=1.0:qg-size=16:psy-rd=0.7:psy-rdoq=5.0:rdoq-level=1:merange=44 \ -c:a copy \ -c:s copy \ -t 120 \ "OUTPUT.HEVC.DTS.Sample.mkv"

Ne feledje, hogy a visszavillant jelvonal megszakad egy hosszú parancsban, azért teszem, hogy segítsek a nyomon követésben egy komplex CLI bemenet különféle bitjeiből. Mielőtt soronként elmagyaráznám, az a rész, ahol a videónak csak egy kis részét konvertálja, a második sor és a második utolsó sor: -ss 0 azt jelenti, hogy 0 másodpercre kell törekedni megkezdi a bemenet dekódolását, és a -t 120 azt jelenti, hogy 120 másodperc után leáll a kimenetre való írás. Használhatja a hh: mm: ss vagy a hh: mm: ss.sss időformátumokat is.

Most soronként:

  1. megakadályozza, hogy a FFmpeg megjelenjen az építési információk indításakor. Csak nem akarom látni, amikor felfelé görgetek a konzolon;
  2. -ss 0 0 másodpercre törekszik, mielőtt megkezdené a bemenet dekódolását. Vegye figyelembe, hogy ha ez a paraméter a bemeneti fájl után és a kimeneti fájl előtt meg lesz adva, ez output opcióvá válik és megmondja a ffmpeg a bemenet dekódolásához és figyelmen kívül hagyásához x másodpercig, majd elkezdi írni a kimenetet. Beviteli opcióként kevésbé pontos (mert a keresés nem pontos a legtöbb konténer formátumban), de szinte nem vesz igénybe időt.Kimeneti opcióként nagyon pontos, de jelentős időbe telik az összes adatfolyam dekódolása a megadott idő előtt, és tesztelés céljából nem akarja pazarolni az időt;
  3. -i "INPUT.mkv": Adja meg a bemeneti fájlt;
  4. -attach "COVER.jpg": Csatoljon egy borítót (indexkép, poszter, bármi) a kimenethez. a borító általában a fájlfeltárókban jelenik meg;
  5. -map_metadata 0: Másolja át az összes metaadatot a 0 bemenetről, amely a példában csak a bemenet;
  6. -map_chapters 0: Másolja át a fejezetadatokat (ha vannak) a 0 bemenetről;
  7. -metadata title="TITLE": Állítsa be a videó címét;
  8. -map 0:0 ...: A 0 bemenet 0 adatfolyamja, ami azt jelenti, hogy azt akarjuk, hogy az első adatfolyam a bemenetről a kimenetre kerüljön . Mivel ez a stream egy video stream, ez az első video adatfolyam a output ban, ezért az adatfolyam-specifikátor :s:v:0. Állítsa be a nyelvét címke angolra;
  9. -map 0:1 ...: Hasonlóan a 8. sorhoz, térképezze fel a második adatfolyamot (DTS audio), és állítsa be annak nyelvét és címét (az azonosítás megkönnyítése érdekében a választásnál) játékosoktól);
  10. -map 0:2 ...: Hasonló a 9. sorhoz, azzal a különbséggel, hogy ez a stream felirat;
  11. -metadata:s:t:0 ...: A borító metaadatainak beállítása. Erre az mkv tároló formátumhoz van szükség;
  12. -c:v libx265 ...: Videokodek beállításai. Olyan hosszú, hogy két sorra bontottam. Ez a beállítás jó minőségű, bluray videóhoz (1080p), minimális sávos átmenettel (amit x265 szippant). Valószínűleg a DVD-k, a tévéműsorok és a telefonos videók túlteljesítése. Ezt a beállítást többnyire ellopják erről a Doom9 bejegyzésről ;
  13. crf=22:...: videokodek folytatása paraméterek. Lásd a fent említett fórumbejegyzést;
  14. -c:a copy: Másolás hanggal;
  15. -c:s copy : Feliratok másolása;
  16. -t 120: 120 másodperc után hagyja abba az írást a kimenetre, amely 2 perces klipet ad nekünk a trancoding minőség előnézetéhez;
  17. "OUTPUT.HEVC.DTS.Sample.mkv": Kimeneti fájl neve. Címkézem a fájlneveimet a videokodekkel és az elsődleges audiokodekkel.

Whew. Ez az első válaszom, ezért ha hiányzik valami, kérem, hagyjon megjegyzést. Nem vagyok videoprodukció-szakértő, csak egy srác vagyok, aki lusta filmet nézni a lemez behelyezésével a lejátszóba.

PS. Lehet, hogy ez a kérdés máshova tartozik, mivel nem “szorosan kapcsolódik a Unix & Linuxhoz.

Megjegyzések

  • Pontosan azt, amit kerestem ! Szép a lehetőségek lefedettsége. Tudja, hogy az ffmpeg kibillen az c:s copy oldalon, ha nincs felirat tartalma?
  • @ElderGeek Nem, az ffmpeg csak akkor mond valamit, ha ennek az opciónak van hatása.
  • @TheBitByte Igen és nem, azt hiszem. Nem ‘ nem akar veszteségmentes h265 fájlokat. ‘ csak nyers bitfolyam, mindenféle tömörítés nélkül. ‘ óriási. A h265 vagy konkrétan az x265 megvalósításának megértése alapján nem veszteségmentes tömörítési módszer. Bármilyen mértékű tömörítés információvesztést, de nem feltétlenül a nézési minőség romlását eredményezi. De ‘ nem vagyok szakértő a h265 témákban, ezért ‘ lehetséges, hogy valamit elmulasztottam
  • @ Nem hiszem, hogy a BitByte ‘ veszteség nélküli tömörítési szint van a h265-ben. A tömörítés nélküli opcióhoz ‘ csak --lossless. Hiába kerestem egy veszteség nélküli átalakulást h264-ről h265-re, és amit megtanultam, azt ‘ matematikailag lehetetlen.
  • A --lossless kapcsolót tartalmazó parancsot valóban ki kell szerkesztenie ebből a válaszból, mert erre a kérdésre válaszként úgy hangzik, mintha ön ‘ újra elmondja ‘ veszteség nélküli tömörítését, ami félrevezető.

Válasz

Nemrégiben átéltem a problémát, amikor átkódoltam a teljes videokatalógusomat a HEVC-re. A >

a következő beállításokkal.

h265ize -v -m medium -q 20 -x –no-sao – -aq-mode 3 –delete –stats

-v – Bővített kimenet
-m közepes – közepes kódolja a sebességet (kisebb, jobb minőségű, bármi, amit lassabban találok, nem éri meg az idő / minőség különbséget)
-q 20 – a használt CRF, 20 hasonló az x264-es 18-hoz, de hé.Ez 1080p tartalomra vonatkozik (a tévém 90% -a). 22-et szoktam használni 4K-s filmjeimhez
-x – Használjon x265 központi definiált parancsokat

–no-sao kikapcsolja az adaptív eltolás mintáját (javítja a kódolás sebességét)
– aq-mode 3 – használja az adaptív kvantálást automatikus varianciával, segíti a 8 bites kódolásokat, különösen sötét területeken, leáll az előforduló sávozás nagy része (bár a kódolási idő rovására megy)
–delete – cserélje le a kódolási fájlt kódolt fájl (tesztelje, mielőtt használná ezt)

– stats – Statisztikákat írjon ki a gyökér csv fájljába az útvonal, amelyről lefutott.

A kódolási sebesség kb. 30 kép / mp (a legtöbb 1080p-s anyag esetében) a fúrótornyomon. Dual Xeon E5 2687W v2, de arra kényszerítem az FFMPEG folyamatot, hogy ne használja az egyik processzor első oldalát (Ez a Plex szerverem, ezért meg kell győződnünk arról, hogy szükség van-e átkódolásra, ha szükséges lejátszáskor stb.)

Igen, a legtöbb átalakítása egy ideig tartott, és most van egy ütemezett feladatom, amely naponta kétszer fut, hogy az adott naptól kezdve x265-ig kódolja a dolgokat.

A helymegtakarítás óriási. A kezdeti SAN-om 20 TB-os volt, most 12 körül van, de nyilvánvalóan hozzá lett adva 6 hónappal több tartalommal is.

Az összes filmemet is átkódoltam, de ez folyamatban lévő folyamat, mivel azonosítanom kell a minőségi szinteket (a Radarr szerencsére szépen felcímkézi), és a három átkódolási beállítás egyikét kell használnom:

-m slower -q 18 -x --no-sao --aq-mode 3 720p átkódokhoz
-m medium -q 20 -x --no-sao --aq-mode 3 1080p-hez
-m medium -q 22 -x --no-sao a 2160p-hez

Remélem, hogy néhány embernek segít. Kiabáljon, ha valakinek szüksége van És mielőtt mindent kódolna x265-re, gondoljon a lejátszásra, ha az ügyfél nem támogatja az x265 natív verzióját, akkor a transzkád drága lehet a CPU és a minőség szempontjából.

Megjegyzések

  • x265 2.4 és újabb verziókkal (élesebb kódolást biztosító új lambda táblákkal ) az ÁSZ általában jó dolog a bitráta / minõség minõségében. Még mindig kissé elkenődik, de az egyéb műtárgyakat eléggé csökkenti ahhoz, hogy megérje.
  • -q 20 nem CRF 20, hanem ‘ s konstans QP ellenőrzési vezérlés . Az alapértelmezett és az ajánlott mód, a CRF, felemeli a QP-t nagyon bonyolult jelenetekben, így nem ‘ nem költenek túl sok bitet olyan jelenetekre, amelyeket túl nehéz kódol. (Ha közelebb akar szállni az egységes QP-hez, emelje fel a qcomp -t az alapértelmezett 0,6-ról talán 0,7-re vagy 0,8-ra. Közelebb az 1.0-hoz közelebb van a CQP-hez.)
  • hogyan kezeled a hdr / sdr kódolásokat, amikor nem tudod ‘, hogy mi a forrás?

Válasz

Az x265 kódoló veszteség nélküli módjának ffmpegben történő engedélyezéséhez a helyes szintaxis -x265-params lossless=1 (hozzá kell adnia a =1).

A veszteségmentes kódoláshoz azonban jobb kodek választási lehetőségek vannak. Teszteléssel azt tapasztaltam, hogy az FFV1 sokkal jobb tömörítést (fájlméret = az x265 ~ 80% -a) legalábbis bizonyos típusú videóknál (ha mindkettőhöz a legjobb beállításokat választják) kodekek). És gyorsabban is működik, és az (AFAIK) szabadalmak nem terhelik. Vagyis minden szempontból felülmúlja a veszteségmentes H.265-öt a videók archiválásában. A kompromisszum azonban kompatibilitás a jelenlegi lejátszási szoftverekkel és hardverekkel.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük