Jeg prøver å konvertere videobiblioteket til HEVC-format for å få plass. Jeg kjørte følgende kommando på alle videofilene i biblioteket mitt: 

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

Nå konverterer de fleste videoer fint, og kvaliteten er den samme som før. Imidlertid mister noen få videoer som er av veldig høy kvalitet (f.eks. En filmutskrift som er på 5 GB) kvaliteten – videoen er pikselisert.

Jeg er ikke sikker på hva jeg skal gjøre i dette tilfellet. Må jeg endre crf -parameteren på kommandolinjen min? Eller noe annet?

Saken er at jeg gjør en massekonvertering. Så jeg trenger en metode der avconv automatisk justerer hva som helst parameter som trenger justering, for hver video.

UPDATE-1

Jeg fant ut at crf er knotten jeg trenger å justere. Standard CRF er 28. For bedre kvalitet kan jeg bruke noe mindre enn 28. For eksempel: 

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

Problemet er imidlertid at for noen videoer CRF verdien på 28 er god nok, mens det for noen videoer kreves lavere CRF. Dette er noe jeg må sjekke manuelt ved å konvertere små deler av de store videoene. Men når jeg konverterer masse, hvordan kan jeg sjekke hver video manuelt? Er det slik at avconv kan justere CRF i henhold til inngangsvideoen på en intelligent måte?

UPDATE-2

Jeg fant ut at det er en --lossless alternativ i x265: http://x265.readthedocs.org/en/default/lossless.html .

Jeg vet imidlertid ikke hvordan jeg bruker den riktig. Jeg prøvde å bruke den på følgende måte, men det ga motsatte resultater (videoen var enda mer pikselert): 

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

Kommentarer

  • --lossless kan faktisk forstørre filen hvis den dekoder den tidligere tapte kodeken og deretter koder for det den dekodet tapsfritt. Kvaliteten vil forbli nøyaktig den samme som input.
  • Hvis kildene dine er kodet i lossy (noe som er mest sannsynlig), er det du prøver å oppnå umulig. Enhver koding som er ikke tapsfri, vil degradere kvaliteten ytterligere (selv om den ikke er umiddelbart synlig for deg), og hvis du konverterer fra tapsfri til tapsfri, vil du få større filstørrelser .

Svar

Fra min egen erfaring, hvis du absolutt ikke ønsker noe tap av kvalitet, er – lossless det du leter etter.

Ikke sikker på avconv men kommandoen du skrev ser identisk ut med hva jeg gjør med FFmpeg. I FFmpeg kan du sende parameteren slik: 

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

Mest x265 brytere (opsjoner uten verdi) kan spesifiseres slik (unntatt de eneste CLI-ene, de brukes bare med x265 binært direkte).

Med det ute av veien vil jeg dele min erfaring med x265 -koding. For de fleste videoer (det være seg WMV, eller MPEG eller AVC /H.264) Jeg bruker crf=23. x265 bestemmer resten av parametrene og vanligvis gjør den en god nok jobb.

Men ofte før jeg forplikter meg til å kode en video i sin helhet, tester jeg innstillingene mine ved å konvertere en liten del av den aktuelle videoen. Her er et eksempel, anta at en mkv-fil med stream 0 er video, stream 1 å være DTS-lyd, og stream 2 være en undertekst: 

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"

Legg merke til at tilbakeslagslinjens brudd i en lang kommando, jeg gjør det for å hjelpe meg å holde rede på av forskjellige biter av en kompleks CLI-inngang. Før jeg forklarer det linje for linje, er delen der du bare konverterer en liten del av en video den andre linjen og den nest siste linjen: -ss 0 betyr søke til 0 sekund før begynner å avkode inngangen, og -t 120 betyr å stoppe å skrive til utgangen etter 120 sekunder. Du kan også bruke hh: mm: ss eller hh: mm: ss.sss tidsformater.

Nå linje for linje:

  1. -hide_banner forhindrer FFmpeg fra å vise byggeinformasjon ved start. Jeg vil bare ikke «se det når jeg ruller opp i konsollen;
  2. -ss 0 søker til 0 sekunder før du begynner å dekode inngangen. Merk at hvis denne parameteren er gitt etter inndatafilen og før utdatafilen, blir den et utdatealternativ og forteller ffmpeg for å dekode og ignorere inngangen til x sekunder, og begynn deretter å skrive til utdata. Som inndatealternativ er det mindre nøyaktig (fordi søking ikke er nøyaktig i de fleste containerformater), men tar nesten ingen tid.Som et alternativ for utdata er det veldig presist, men det tar lang tid å dekode all strømmen før den angitte tiden, og for testformål vil du ikke kaste bort tid;
  3. -i "INPUT.mkv": Angi inndatafilen;
  4. -attach "COVER.jpg": Fest et omslagsbilde (miniatyrbilde, plakat, hva som helst) til utgangen. omslagsbilder vises vanligvis i filutforskere;
  5. -map_metadata 0: Kopier over alle metadata fra inngang 0, som i eksemplet bare er inngangen;
  6. -map_chapters 0: Kopier over kapittelinfo (hvis det finnes) fra inngang 0;
  7. -metadata title="TITLE": Sett tittelen på videoen;
  8. -map 0:0 ...: Kartstrøm 0 av inngang 0, noe som betyr at vi vil at den første strømmen fra inngangen skal skrives til utgangen Siden denne strømmen er en videostrøm, er den den første video strømmen i utdata , derav strømspesifikatoren :s:v:0. Sett språk tag til engelsk;
  9. -map 0:1 ...: I likhet med linje 8, kartlegg den andre strømmen (DTS-lyd), og angi språk og tittel (for enklere identifisering når du velger fra spillere);
  10. -map 0:2 ...: Lik linje 9, bortsett fra at denne strømmen er en undertekst;
  11. -metadata:s:t:0 ...: Angi metadata for omslagsbildet. Dette kreves for mkv-containerformat;
  12. -c:v libx265 ...: Alternativer for videokodek. Det er så lenge at jeg har brutt det i to linjer. Denne innstillingen er god for uskarphetsvideo av høy kvalitet (1080p) med minimal gradering (som x265 suger av). Det er mest sannsynlig en overkill for DVDer og TV-programmer og telefonvideoer. Denne innstillingen er for det meste stjålet fra dette Doom9-innlegget ;
  13. crf=22:...: Fortsettelse av videokodek parametere. Se foruminnlegget nevnt ovenfor;
  14. -c:a copy: Kopier over lyd;
  15. -c:s copy : Kopier over undertekster;
  16. -t 120: Stopp skrivingen til utgangen etter 120 sekunder, noe som gir oss et 2-minutters klipp for forhåndsvisning av trancoding-kvalitet;
  17. "OUTPUT.HEVC.DTS.Sample.mkv": Utdatafilnavn. Jeg merker filnavnene mine med videokodeken og den primære lydkodeken.

Whew. Dette er mitt første svar, så hvis det er noe jeg savnet, kan du legge igjen en kommentar. Jeg er ikke en videoproduksjonsekspert, jeg er bare en fyr som er for lat til å se en film ved å sette platen i spilleren.

PS. Kanskje dette spørsmålet tilhører et annet sted som det er ikke sterkt relatert til Unix & Linux.

Kommentarer

  • Akkurat det jeg lette etter ! Fin dekning av opsjoner. Vet du om ffmpeg vil slå på c:s copy hvis det ikke er noe undertekstinnhold?
  • @ElderGeek Nei, ffmpeg vil bare si noe hvis det alternativet har noen effekt.
  • @TheBitByte Ja og nei, tror jeg. Du ønsker ikke ‘ tapsfrie h265-filer. Det ‘ er bare rå bitestrøm uten noen form for komprimering. Det ‘ er enormt. Fra det jeg forstår om h265 eller spesielt x265-implementering, er det ikke en tapsfri komprimeringsmetode. Enhver grad av komprimering vil føre til tap av informasjon, men ikke nødvendigvis tap av visningskvalitet. Men jeg ‘ er ikke en ekspert på h265-emner, så det er ‘ mulig at jeg savnet noe
  • @ TheBitByte Jeg tror ikke ‘ t det er et tapsfritt kompresjonsnivå i h265. For det komprimeringsløse alternativet er det ‘ bare --lossless. Jeg søkte forgjeves etter en tapsfri konvertering fra h264 til h265, og det jeg ‘ har lært, forteller meg at det ‘ er matematisk umulig.
  • Du bør virkelig redigere kommandoen som inneholder --lossless byttet ut av dette svaret, for legg det som et svar på dette spørsmålet det høres ut som du ‘ sier det ‘ s tapsfri komprimering, noe som er misvisende.

Svar

Jeg har nylig gått igjennom bryet med å konvertere hele videokatalogen til HEVC. Jeg bruker https://github.com/FallingSnow/h265ize med følgende innstillinger.

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

-v – Formidlet utgang
-m medium – Medium kodehastighet (mindre høyere kvalitet, noe tregere jeg finner er ikke verdt tiden / kvaliteten dif)
-q 20 – CRF brukt, 20 ligner 18 eller så i x264, men hei.Dette er for 1080p-innhold (90% av TV-en min). Jeg pleier å bruke 22 til 4K-filmene mine. -x – Bruk x265 sentralt definerte kommandoer
–no-sao slår av Eksempeladaptiv forskyvning (forbedrer hastigheten på kodingen)
–aq-mode 3 – bruk adaptiv kvantisering med automatisk varians, hjelper 8bit-koder, spesielt i mørke områder, stopper mesteparten av bandingen som kan skje (på bekostning av kodetiden skjønt)
–delete – erstatt kodingsfil med kodet fil (test før du bruker denne)
–statistikk – Skriv statistikk ut til en csv-fil i roten av banen du løp fra.

Kodehastighetene er rundt 30 bilder per sekund (for de fleste 1080p-ting) på riggen min. Dual Xeon E5 2687W v2, men jeg tvinger FFMPEG-prosessen til ikke å bruke den første siden av en av prosessorene (det er min Plex-server, så må du sørge for at det er overhead for transkode om nødvendig ved avspilling osv.)

Ja, det tok litt tid å konvertere det meste av det, og nå har jeg en planlagt oppgave som kjører to ganger om dagen for å kode ting fra den dagen til x265.

Plassbesparelsen har vært enorm. Min opprinnelige SAN var på 20 TB bruk, nå er den rundt 12, men tydeligvis har den blitt lagt til med 6 måneder mer innhold.

Jeg har begynt å kode alle filmene mine også, men det er en pågående prosess, da jeg må identifisere kvalitetsnivåer (Radarr merker heldigvis pent) og bruker en av tre transkodeinnstillinger:

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

Håper det hjelper noen mennesker. Rop hvis noen trenger en hånd sette opp det hele. Og før du koder alt til x265, tenk på avspilling, hvis klienten ikke støtter x265 native, så kan transkaden være dyr når det gjelder CPU og kvalitet.

Kommentarer

  • Med x265 2.4 og senere (med de nye lambda-tabellene som gir skarpere koder), er SAO vanligvis en god ting for kvalitet per bithastighet. Det smøres fortsatt litt ut, men reduserer andre gjenstander nok til å være verdt det.
  • -q 20 er ikke CRF 20, det ‘ s konstant QP-ratekontroll . Standard og anbefalt modus, CRF, hever QP-en i scener med høy kompleksitet, slik at den ikke ‘ ikke bruker for mange biter på scener som er for vanskelige å kode. (Hvis du vil ha nærmere ensartet QP, løft qcomp opp fra standard 0,6 til kanskje 0,7 eller 0,8. Nærmere 1,0 er nærmere CQP.)
  • hvordan håndterer du hdr / sdr-koder når du ikke ‘ ikke vet hva kilden er?

Svar

Den riktige syntaksen for å aktivere tapsfri modus for x265-koderen i ffmpeg er -x265-params lossless=1 (du må legge til =1).

For tapsfri koding er det imidlertid bedre kodekvalg. Jeg fant ut ved å teste at FFV1 komprimerer langt bedre (filstørrelse = ~ 80% av x265) i det minste på noen typer video (hvis de beste innstillingene er valgt for begge kodeker). Og det fungerer også raskere, og (AFAIK) er ikke belastet med patenter. Det vil si at den er overlegen tapsløs H.265 på alle måter for videoarkivering. Kompromisset er imidlertid kompatibilitet med gjeldende avspillingsprogramvare og maskinvare.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *