Ik probeer mijn videobibliotheek om te zetten naar HEVC-indeling om ruimte te winnen. Ik heb de volgende opdracht uitgevoerd op alle videobestanden in mijn bibliotheek:

 #!/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 converteren de meeste videos prima en is de kwaliteit hetzelfde als voorheen. Een paar videos van zeer hoge kwaliteit (bijv. Een filmafdruk van 5 GB) verliezen echter kwaliteit – de video is allemaal korrelig.

Ik weet niet zeker wat ik in dit geval moet doen. Moet ik de parameter crf op mijn opdrachtregel wijzigen? Of iets anders?

Ik ben bezig met een bulkconversie. Dus ik heb een methode nodig waarbij avconv automatisch de parameter aanpast die moet worden aangepast, voor elke video.

UPDATE-1

Dat vond ik crf is de knop die ik moet aanpassen. De standaard CRF is 28. Voor een betere kwaliteit zou ik iets minder dan 28 kunnen gebruiken. Bijvoorbeeld:

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

Het probleem is echter dat voor sommige videos CRF waarde van 28 is goed genoeg, terwijl voor sommige videos een lagere CRF vereist is. Dit is iets dat ik handmatig moet controleren door kleine delen van de grote videos te converteren. Maar hoe kan ik bij bulkconversie elke video handmatig controleren? Is er een manier waarop avconv CRF intelligent kan aanpassen aan de video-invoer?

UPDATE-2

Ik ontdekte dat er een --lossless optie in x265: http://x265.readthedocs.org/en/default/lossless.html .

Ik weet echter niet hoe ik het correct moet gebruiken. Ik heb het op de volgende manier geprobeerd, maar het leverde tegengestelde resultaten op (de video was zelfs nog meer korrelig):

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

Reacties

  • --lossless zou het bestand in feite kunnen vergroten, als het de eerder lossy codec decodeert en vervolgens omsluit wat het heeft gedecodeerd zonder verlies. De kwaliteit blijft precies hetzelfde als de invoer.
  • Als uw bronnen met verlies zijn gecodeerd (wat hoogstwaarschijnlijk is), is wat u probeert te bereiken onmogelijk. Elke transcodering die is niet zonder verlies zal de kwaliteit verder verslechteren (zelfs als dit niet direct zichtbaar is voor u) en als u converteert van lossy naar lossless, krijgt u grotere bestanden .

Antwoord

Uit eigen ervaring, als je absoluut geen kwaliteitsverlies wilt, is –lossless wat je zoekt.

Weet niet zeker over avconv maar het commando dat je hebt getypt ziet er identiek uit aan wat ik doe met FFmpeg. In FFmpeg kun je de parameter als volgt doorgeven:

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

Meeste x265 schakelaars (opties zonder waarde) kunnen op deze manier worden gespecificeerd (behalve die CLI-alleen, die worden alleen gebruikt met x265 binair direct).

Met dat uit de weg, “wil ik mijn ervaring delen met x265 codering. Voor de meeste videos (of het nu WMV, MPEG of AVC is) /H.264) Ik gebruik crf=23. x265 bepaalt de rest van de parameters en meestal doet het goed werk.

Maar voordat ik een video in zijn geheel ga transcoderen, test ik mijn instellingen door een klein deel van de betreffende video te converteren. Hier is een voorbeeld, stel dat een mkv-bestand met stream 0 video is, stream 1 zijnde DTS-audio en stream 2 als ondertitel:

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" 

Merk op dat de backslashesignaallijn breekt in een lange opdracht, ik doe het om me te helpen bij te houden van verschillende bits van een complexe CLI-invoer. Voordat ik het regel voor regel uitleg, is het deel waar je slechts een klein deel van een video converteert de tweede regel en de voorlaatste regel: -ss 0 betekent zoek naar 0 seconden voor begint met het decoderen van de invoer, en -t 120 betekent dat het schrijven naar de uitvoer na 120 seconden stopt. U kunt ook hh: mm: ss of hh: mm: ss.sss tijdnotaties gebruiken.

Nu regel voor regel:

  1. -hide_banner voorkomt dat FFmpeg build-informatie weergeeft bij het starten. Ik “wil het gewoon niet zien wanneer ik omhoog scrol in de console;
  2. -ss 0 zoekt naar 0 seconden voordat de invoer wordt gedecodeerd. Merk op dat als deze parameter wordt na het invoerbestand gegeven en voor het uitvoerbestand, het wordt een uitvoeroptie en vertelt ffmpeg om de invoer te decoderen en negeren tot x seconden, en dan te beginnen met schrijven naar de uitvoer.Als invoeroptie is het minder nauwkeurig (omdat zoeken niet nauwkeurig is in de meeste containerformaten), maar het kost bijna geen tijd.Als uitvoeroptie is het erg nauwkeurig, maar het kost een aanzienlijke hoeveelheid tijd om alle stream te decoderen vóór de gespecificeerde tijd, en voor testdoeleinden wil je “geen tijd verspillen;
  3. -i "INPUT.mkv": specificeer het invoerbestand;
  4. -attach "COVER.jpg": voeg een albumhoes (miniatuurafbeelding, poster, wat dan ook) toe aan de uitvoer. albumhoezen worden meestal getoond in bestandsverkenners;
  5. -map_metadata 0: kopieer alle metagegevens van invoer 0, die in het voorbeeld alleen de invoer zijn;
  6. -map_chapters 0: Kopieer hoofdstukinformatie (indien aanwezig) van invoer 0;
  7. -metadata title="TITLE": Stel de titel van de video in;
  8. -map 0:0 ...: breng stream 0 van ingang 0 in kaart, wat betekent dat we willen dat de eerste stream van de ingang naar de uitgang wordt geschreven . Aangezien deze stream een videostream is, is dit de eerste video stream in de output , vandaar de streamspecificatie :s:v:0. Stel de taal in tag to English;
  9. -map 0:1 ...: vergelijkbaar met regel 8, breng de tweede stream (DTS-audio) in kaart en stel de taal en titel in (voor eenvoudiger identificatie bij het kiezen van spelers);
  10. -map 0:2 ...: vergelijkbaar met regel 9, behalve dat deze stream een ondertitel is;
  11. -metadata:s:t:0 ...: metadata instellen voor de albumhoes. Dit is vereist voor het mkv-containerformaat;
  12. -c:v libx265 ...: Video codec-opties. Het is zo lang dat ik het in twee lijnen heb opgesplitst. Deze instelling is goed voor onscherpe video van hoge kwaliteit (1080p) met minimale banding in gradiënt (waar x265 slecht aan is). Het is hoogstwaarschijnlijk een overkill voor dvds en tv-programmas en telefoonvideos. Deze instelling is meestal gestolen uit dit Doom9-bericht ;
  13. crf=22:...: voortzetting van videocodec parameters. Zie het forumbericht hierboven vermeld;
  14. -c:a copy: Kopieer over audio;
  15. -c:s copy : Kopieer over ondertitels;
  16. -t 120: Stop met schrijven naar de uitvoer na 120 seconden, wat ons een clip van 2 minuten geeft om een voorbeeld van de trancoderingskwaliteit te bekijken;
  17. "OUTPUT.HEVC.DTS.Sample.mkv": naam van uitvoerbestand. Ik tag mijn bestandsnamen met de videocodec en de primaire audiocodec.

Oef. Dit is mijn eerste antwoord, dus als er iets is dat ik heb gemist, laat dan een reactie achter. Ik ben geen expert op het gebied van videoproductie, ik ben gewoon iemand die te lui is om een film te kijken door de schijf in de speler te plaatsen.

PS. Misschien hoort deze vraag ergens anders bij is niet sterk gerelateerd aan Unix & Linux.

Reacties

  • Precies wat ik zocht ! Mooie dekking van opties. Weet je of ffmpeg zal weigeren bij c:s copy als er geen ondertitelinhoud is?
  • @ElderGeek Nee, ffmpeg zal alleen iets zeggen als die optie enig effect heeft.
  • @TheBitByte Ja en nee, denk ik. U wilt geen ‘ h265-bestanden zonder verlies. Het ‘ is gewoon een ruwe bitstroom zonder enige vorm van compressie. Het ‘ is enorm. Van wat ik begrijp over de implementatie van h265 of specifiek x265, is het geen compressiemethode zonder verlies. Elke mate van compressie leidt tot verlies van informatie, maar niet noodzakelijk tot verlies van weergavekwaliteit. Maar ik ‘ ben geen expert op het gebied van h265-onderwerpen, dus het is ‘ mogelijk dat ik iets heb gemist
  • @ TheBitByte Ik denk niet ‘ dat er een verliesvrij compressieniveau is in h265. Voor de optie zonder compressie is het ‘ slechts --lossless. Ik heb tevergeefs gezocht naar een verliesvrije conversie van h264 naar h265, en wat ik ‘ heb geleerd, vertelt me dat het ‘ s wiskundig onmogelijk is.
  • Je zou echt het commando met de --lossless schakelaar uit dit antwoord moeten bewerken, want als je daar als antwoord op deze vraag zet, klinkt het alsof je ‘ zegt het ‘ s lossless compressie, wat misleidend is.

Antwoord

Ik “heb onlangs de moeite genomen om mijn hele videocatalogus naar HEVC te transcoderen. Ik gebruik https://github.com/FallingSnow/h265ize met de volgende instellingen.

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

-v – Uitgebreide uitvoer
-m gemiddeld – Gemiddeld coderingssnelheid (kleinere hogere kwaliteit, iets langzamer vind ik de tijd / kwaliteit dif niet waard)
-q 20 – de gebruikte CRF, 20 is vergelijkbaar met 18 of zo in x264, maar hey.Dit is voor 1080p-inhoud (90% van mijn tv). Ik gebruik er meestal 22 voor mijn 4K-films
-x – Gebruik x265 centraal gedefinieerde commandos
–no-sao schakelt Sample Adaptive Offset uit (verbetert de coderingssnelheid)
–aq-mode 3 – gebruik Adaptive Quantization met automatische variantie, helpt 8bit-coderingen, vooral in donkere gebieden, stopt de meeste banding die kan optreden (ten koste van de coderingstijd)
–delete – vervang het coderingsbestand door gecodeerd bestand (test voordat u dit gebruikt)
–stats – Schrijf statistieken naar een csv-bestand in de root van het pad waar je vandaan liep.

Coderingssnelheden zijn ongeveer 30 fps (voor de meeste 1080p-dingen) op mijn rig. Dual Xeon E5 2687W v2, maar ik dwing het FFMPEG-proces om de eerste kant van een van de processors niet te gebruiken (het is mijn Plex-server, dus je moet ervoor zorgen dat er overhead is voor transcodering indien nodig bij het afspelen enz.)

Ja, het duurde een tijdje om het meeste ervan om te zetten, en nu heb ik een geplande taak die twee keer per dag wordt uitgevoerd om de dingen van die dag naar x265 te coderen.

De ruimtebesparing zijn enorm geweest. Mijn aanvankelijke SAN had een gebruik van 20 TB, nu is het ongeveer 12, maar het is duidelijk ook toegevoegd met 6 maanden meer inhoud.

Ik ben begonnen met het transcoderen van al mijn films, maar dat is een doorlopend proces, aangezien ik kwaliteitsniveaus moet identificeren (Radarr gelukkig labelt dan netjes) en een van de drie transcode-instellingen moet gebruiken:

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

Ik hoop dat het sommige mensen helpt. Roep als iemand een hand om het allemaal op te zetten. En voordat je alles naar x265 codeert, denk aan afspelen, als de client geen x265 native ondersteunt, dan kan de transcade duur zijn in termen van CPU en kwaliteit.

Opmerkingen

  • Met x265 2.4 en hoger (met de nieuwe lambda-tabellen die scherpere coderingen geven), is SAO meestal een goede zaak voor kwaliteit per bitrate. Het smeert nog steeds een beetje uit, maar vermindert voldoende andere artefacten om het waard te zijn.
  • -q 20 is niet CRF 20, maar ‘ s constante QP-verhoudingscontrole . De standaard en aanbevolen modus, CRF, verhoogt de QP in scènes met een hoge complexiteit, zodat ‘ niet te veel bits uitgeeft aan scènes die te moeilijk zijn om coderen. (Als je dichter bij een uniforme QP wilt, verhoog dan qcomp van de standaard 0,6 naar misschien 0,7 of 0,8. Dichter bij 1,0 is dichter bij CQP.)
  • hoe behandel je hdr / sdr coderingen als je niet ‘ weet wat de bron is?

Antwoord

De juiste syntaxis om de verliesloze modus voor x265-encoder in ffmpeg in te schakelen is -x265-params lossless=1 (u moet =1).

Voor lossless coderen zijn er echter betere codec-keuzes. Ik ontdekte door te testen dat FFV1 aanzienlijk beter comprimeert (bestandsgrootte = ~ 80% van x265) op zijn minst op sommige soorten video (als de beste instellingen voor beide zijn gekozen codecs). En het werkt ook sneller, en (AFAIK) wordt niet gehinderd door patenten. Dat wil zeggen, het is in alle opzichten superieur aan H.265 zonder verlies voor video-archivering. Het compromis is echter compatibiliteit met de huidige afspeelsoftware en -hardware.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *