Jag försöker konvertera mitt videobibliotek till HEVC-format för att få plats. Jag körde följande kommando på alla videofilerna i mitt bibliotek:

 #!/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  

Nu konverterar de flesta videor bra och kvaliteten är densamma som tidigare. Några videoklipp som är av mycket hög kvalitet (t.ex. ett filmutskrift på 5 GB) tappar dock kvalitet – videon är helt pixelerad.

Jag är inte säker på vad jag ska göra i det här fallet. Måste jag ändra parametern crf på min kommandorad? Eller något annat?

Saken är att jag gör en masskonvertering. Så jag behöver en metod där avconv automatiskt justerar vilken parameter som behöver justeras för varje video.

UPDATE-1

Jag fann att crf är vredet jag behöver justera. Standard CRF är 28. För bättre kvalitet kan jag använda något mindre än 28. Till exempel:

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

Problemet är dock att CRF för vissa videor värdet 28 är tillräckligt bra, medan för vissa videor krävs lägre CRF. Det här är något som jag måste kontrollera manuellt genom att konvertera små delar av de stora videorna. Men vid masskonvertering, hur skulle jag kontrollera varje video manuellt? Är det på något sätt att avconv kan justera CRF enligt ingångsvideon på ett intelligent sätt?

UPDATE-2

Jag fann att det finns en --lossless alternativ i x265: http://x265.readthedocs.org/en/default/lossless.html .

Jag vet dock inte hur jag använder den korrekt. Jag försökte använda den på följande sätt men det gav motsatta resultat (videon var ännu mer pixelerad):

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

Kommentarer

  • --lossless kanske faktiskt förstorar filen om den avkodar den tidigare förlorade codec och sedan kodar vad den gjorde avkoda förlustfritt. Kvaliteten kommer att förbli exakt densamma som inmatningen.
  • Om dina källor är kodade i lossy (vilket troligtvis är), är det du försöker uppnå omöjligt. Omkodning som är inte förlustfri kommer att försämra kvaliteten ytterligare (även om den inte syns direkt för dig) och om du konverterar från förlustlös till förlustfri får du större filstorlekar .

Svar

Från min egen erfarenhet, om du absolut inte vill ha någon kvalitetsförlust, är – lossless vad du letar efter.

Inte säker på avconv men kommandot du skrev ser identiskt ut med vad jag gör med FFmpeg. I FFmpeg kan du skicka parametern så här:

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

Mest x265 switchar (alternativ utan värde) kan anges så här (förutom de endast CLI, de används bara med x265 binärt direkt).

Med det ur vägen vill jag dela min erfarenhet med x265 -kodning. För de flesta videor (vare sig det är WMV, MPEG eller AVC /H.264) Jag använder crf=23. x265 bestämmer resten av parametrarna och vanligtvis gör det ett tillräckligt bra jobb.

Men ofta innan jag förbinder mig att omkoda en video i sin helhet testar jag mina inställningar genom att konvertera en liten del av videon i fråga. Antag att en mkv-fil med ström 0 är video, ström 1 att vara DTS-ljud, och ström 2 är en underrubrik:

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" 

Observera att backslash-signalraden bryts i ett långt kommando, jag gör det för att hjälpa mig att hålla koll av olika bitar av en komplex CLI-ingång. Innan jag förklarar det rad för rad är den del där du bara konverterar en liten del av en video den andra raden och den näst sista raden: -ss 0 betyder söka till 0 sekund före börjar avkoda ingången och -t 120 betyder att sluta skriva till utgången efter 120 sekunder. Du kan också använda hh: mm: ss eller hh: mm: ss.sss tidsformat.

Nu rad för rad:

  1. -hide_banner hindrar FFmpeg från att visa bygginformation vid start. Jag vill bara inte se det när jag rullar uppåt i konsolen.
  2. -ss 0 försöker till 0 sekunder innan avkodning av ingången börjar. Observera att om den här parametern ges efter inmatningsfilen och före utdatafilen blir det ett utdatalternativ och säger till ffmpeg för att avkoda och ignorera ingången till x sekunder, och börja sedan skriva till utdata. Som inmatningsalternativ är det mindre exakt (eftersom sökning inte är korrekt i de flesta behållarformat), men tar nästan ingen tid.Som ett outputalternativ är det väldigt exakt men det tar mycket tid att avkoda hela strömmen före den angivna tiden, och för teständamål vill du inte slösa bort tid;
  3. -i "INPUT.mkv": Ange inmatningsfilen;
  4. -attach "COVER.jpg": Bifoga en omslagsbild (miniatyrbild, affisch, vad som helst) till utgången. omslagsbild visas vanligtvis i filutforskare;
  5. -map_metadata 0: Kopiera över alla metadata från ingång 0, som i exemplet bara är ingången;
  6. -map_chapters 0: Kopiera över kapitelinformation (om sådan finns) från ingång 0;
  7. -metadata title="TITLE": Ställ in videoklippets titel;
  8. -map 0:0 ...: Kartström 0 för ingång 0, vilket betyder att vi vill att den första strömmen från ingången ska skrivas till utgången Eftersom den här strömmen är en videoström är den den första video -strömmen i utdata , därav strömspecifikatorn :s:v:0. Ställ in dess språk tag till engelska;
  9. -map 0:1 ...: Liknar rad 8, kartlägg den andra strömmen (DTS-ljud) och ställ in dess språk och titel (för enklare identifiering när du väljer från spelare);
  10. -map 0:2 ...: Liknar rad 9, förutom att den här strömmen är en underrubrik;
  11. -metadata:s:t:0 ...: Ställ in metadata för omslagsbilden. Detta krävs för mkv-containerformat.
  12. -c:v libx265 ...: Alternativ för videokodek. Det är så länge att jag har delat upp det i två rader. Den här inställningen är bra för högkvalitativ bluray-video (1080p) med minimal bandning i lutning (som x265 suger på). Det är troligtvis en överdrift för DVD-skivor och TV-program och telefonvideor. Den här inställningen är oftast stulen från detta Doom9-inlägg ;
  13. crf=22:...: Fortsättning av videokodek parametrar. Se foruminlägget som nämns ovan;
  14. -c:a copy: Kopiera över ljud;
  15. -c:s copy : Kopiera över undertexter;
  16. -t 120: Sluta skriva till utdata efter 120 sekunder, vilket ger oss ett 2-minuters klipp för att förhandsgranska trancoding-kvalitet;
  17. "OUTPUT.HEVC.DTS.Sample.mkv": Utdatafilnamn. Jag märker mina filnamn med videokodeken och den primära ljudkoden.

Whew. Detta är mitt första svar, så om det är något jag saknar, vänligen skriv en kommentar. Jag är ingen videoproduktionsexpert, jag är bara en kille som är för lat för att titta på en film genom att sätta in skivan i spelaren.

PS. Kanske tillhör denna fråga någon annanstans som den är inte starkt relaterad till Unix & Linux.

Kommentarer

  • Exakt vad jag letade efter ! Trevlig täckning av alternativ. Vet du om ffmpeg kommer att stråla vid c:s copy om det inte finns något textinnehåll?
  • @ElderGeek Nej, ffmpeg säger bara något om det alternativet har någon effekt.
  • @TheBitByte Ja och nej, tror jag. Du vill inte ’ t förlustfria h265-filer. Det ’ är bara rå bitström utan någon form av komprimering. Det ’ är enormt. Från vad jag förstår om h265 eller specifikt x265-implementering är det inte en förlustfri komprimeringsmetod. Varje grad av komprimering kommer att leda till förlust av information, men inte nödvändigtvis förlust av visningskvalitet. Men jag ’ är inte expert på h265-ämnen, så det är ’ möjligt att jag saknade något
  • @ TheBitByte Jag tror inte ’ att det finns en förlustfri komprimeringsnivå i h265. För det komprimeringsfria alternativet är det ’ bara --lossless. Jag sökte förgäves efter en förlustfri omvandling från h264 till h265, och vad jag ’ har lärt mig säger att det ’ är matematiskt omöjligt.
  • Du bör verkligen redigera kommandot som innehåller --lossless byta från det här svaret, för lägg det som ett svar på den här frågan det låter som du ’ säger det ’ s förlustfri komprimering, vilket är vilseledande.

Svar

Jag har nyligen gått igenom besväret med att konvertera hela min videokatalog till HEVC. Jag använder https://github.com/FallingSnow/h265ize med följande inställningar.

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

-v – Omfattande utdata
-m medium – Medium kodhastighet (mindre högre kvalitet, allt långsammare som jag tycker är inte värt tiden / kvaliteten dif)
-q 20 – CRF används, 20 liknar 18 eller så i x264 men hej.Det här är för 1080p-innehåll (90% av min TV) Jag brukar använda 22 för mina 4K-filmer
-x – Använd x265 centraldefinierade kommandon
–no-sao stänger av Sample Adaptive Offset (förbättrar kodens hastighet)
–aq-mode 3 – använd adaptiv kvantisering med automatisk varians, hjälper 8bit-kodning, särskilt i mörka områden, stopp det mesta av bandet som kan hända (på bekostnad av kodningstiden dock)
–delete – ersätt kodningsfilen med kodad fil (testa innan du använder den här)
–stats – Skriv statistik till en csv-fil i roten av vägen du sprang från.

Kodningshastigheterna ligger runt 30 fps (för de flesta 1080p-saker) på min rigg. Dual Xeon E5 2687W v2, men jag tvingar FFMPEG-processen att inte använda den första sidan av en av processorerna (det är min Plex-server, så måste se till att det är kostnad för transkod om det behövs vid uppspelning etc)

Ja det tog ett tag att konvertera det mesta av det, och nu har jag en schemalagd uppgift som körs två gånger om dagen för att koda saker från den dagen till x265.

Utrymmesbesparingarna har varit enorma. Min ursprungliga SAN var vid användning av 20Tb, nu är den cirka 12 men uppenbarligen har den lagts till med 6 månader mer innehåll.

Jag har börjat koda om alla mina filmer också, men det är en pågående process, eftersom jag måste identifiera kvalitetsnivåer (Radarr märker lyckligtvis sedan snyggt) och använda en av tre transkodsinställningar:

-m slower -q 18 -x --no-sao --aq-mode 3 för 720p transkoder
-m medium -q 20 -x --no-sao --aq-mode 3 för 1080p
-m medium -q 22 -x --no-sao för 2160p

Hoppas det hjälper vissa människor. Ropa om någon behöver en hand ställa upp allt. Och innan du kodar allt till x265, tänk på uppspelning, om klienten inte stöder x265 native, kan transkaden vara dyr när det gäller CPU och kvalitet.

Kommentarer

  • Med x265 2.4 och senare (med de nya lambda-tabellerna som ger skarpare koder) är SAO vanligtvis en bra sak för kvalitet per bithastighet. Det smutsar fortfarande lite ut, men minskar andra artefakter för att vara värt det.
  • -q 20 är inte CRF 20, det ’ s konstant QP-ratkontroll . Standardläget och rekommenderat läge, CRF, höjer QP i scener med hög komplexitet så att det inte ’ t spenderar för många bitar på scener som är för svåra att koda. (Om du vill närma dig enhetlig QP höjer du qcomp från standard 0,6 till kanske 0,7 eller 0,8. Närmare 1,0 är närmare CQP.)
  • hur hanterar du hdr / sdr-koder när du inte ’ inte vet vad källan är?

Svar

Den korrekta syntaxen för att aktivera förlustfritt läge för x265-kodaren i ffmpeg är -x265-params lossless=1 (du måste lägga till =1).

För förlustfri kodning finns det dock bättre codec-val. Jag hittade genom att testa att FFV1 komprimerar mycket bättre (filstorlek = ~ 80% av x265) åtminstone på vissa typer av video (om bästa inställningar väljs för båda codecs). Och det fungerar också snabbare, och (AFAIK) belastas inte av patent. Det är, det är överlägset förlustfritt H.265 på alla sätt för videoarkivering. Kompromissen är dock kompatibilitet med aktuell uppspelningsprogramvara och hårdvara.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *