Größensteuerung bei x264 im crf-Mode?

  • Moin,


    ja - crf ist Qualität und schwankende Größe (Punkt - darüber bitte keine Diskussion) ;)


    Aber gerade bei älteren und verrauschten Sachen bekomme ich selbst bei crf20 oder 22 relativ große Files.
    Ich habe jetzt schon verschiedenes ausprobiert, u.a. auch deblock auf 0,0.


    Daher meine Frage an die x264-Fachleute: Gibt es Möglichkeiten, die Dateigröße im crf-Mode minimieren zu können?


    LG
    MacLeod

  • ja das ist eine witzige frage :P


    außer den CRF wert zu ändern, kannste nur noch mit ein paar einstellungen rumspielen... ref hoch, bframes hoch, mixed ref an, decimate an, fast-p-skip an, bpyramid auf 2...


    aber an sich ist CRF ja dafür da um die selbe qualität zu bekommen um dateigröße zu bestimmen.... finde es immer witzig wenn leute mit CRF encoden und dann wenn mal ne ep doppelt so groß wie die anderen wird nen anderen CRF wert nehmen weil der größenunterschied zu hoch war... haben den sinn von CRF nicht verstanden.. :P


    anyways, neben den genannten x264 settings gibt es natürlich noch einen weg um die dateigröße runter zu bekommen, gerade bei "älteren und verrauschten Sachen" undzwar avisynth filter zum degrainen, etc etc.. im endeffekt verlierst du so detail, aber bekommst aber eben die sachen die das encode groß machen aus dem bild...
    kannst dich damit mal beschäftigen.... aber eben beachten, wenn man da was anständiges raus haben will, braucht man eben viel zeit....


    um zu testen empfehle ist avspmod... damit kannste die scripte erstellen und live an videos/bilder testen... so kann man sehr gut vergleichen, indem man 2 mal das selbe video läd, einmal es original lässt, das 2te mit den filter und dann mit interleave(a,b) die frames abwechselnd vom originalvideo und video mit den filter zeigt.. so sieht man direkt was anders ist..

  • Wobei hohe re&b frames nur begrentzt die Filegröße senken, da darf man keine Wunder erwarten. das kann je nachdem ob SD oder 1080p ein paar hundert MB einsparen, das encoden dauert aber wesentlich länger.


    Bin selbst gerade dabei 1080p crf20 Encodes von Die Tudors zu erstellen. In den ersten Staffeln haben die Folgen noch so um die 5000MB pro Folge ab Season 2 schon durchschnittlich 6000MB da das Bild etwas grainiger ist.


    Und ab S03 zwecks DTS sogar teilweise 7000MB, hab aber gemerkt das die hohen Bitraten einfach nötig sind, schließlich will man ja auch Qualitativ hochwertige Rips haben. Wem das zu Groß ist muss sie ja nicht laden...


    Noise Reduction kam für mich nicht in Frage, wobei niedrige NR-werte zb. 30-60 absolut keinen Nutzen haben, da muss man schon min. 100-200 oder höher einstellen, aber bei solchen Werten verliert das bild sichtlich seine Schärfe. :eek:


    Und welche Dateigrößen bekommst du da in etwa raus? Und sind das SD oder HDRips?

  • Also die Noise Reduction von x264 ist eigentlich nicht so aggressiv.


    Bis 200 kann man bei SD Material durchaus gehen.


    Es wird ja auch nicht in dem Sinne Rauschen/Grain entfernt, sondern x264 sagt einfach


    "Ok, ohne NR würde ich diesen und jenen Makroblock nicht für identisch erklären, mit der NR aber schon. Also setze ich hier eine Referenz, die viel Platz spart, als den Makroblock nochmal extra zu speichern."

    Postfächer laufen über. Lange Wartezeiten!

  • Ich komme nochmal auf das Thema zurück ;)


    Wollte die Tage Highlander S4 zum Ansehen coden ...


    crf18: 1,6 GB
    crf20: 1,1 GB
    crf22: 780 MB


    Nur schlechter als crf20 wollte ich nicht unbedingt gehen, aber > 1 GB finde ich dann schon etwas heftig ...


    Hier mal die Mediainfo vom crf18:


    Wer Zeit hat, kann gern mal selbst testen: HTSTest
    Bin für konkrete Optimierungsverschläge empfänglich ;)



    PS: In Stax war eigentlich 12 ref + 6bf eingestellt. :confused:

  • hab aktuell das selbe mit der lindenstrasse die ich von einsfestival cappe


    bei 30min laufzeit sind da dateien von 1gb raus gekommen (crf 21), bin zum endschluß gekommen das ich die alten folgen in avi staxxe, aktuelle folgen staxxe ich auch in crf 21 und da kommen so um die 200mb pro folge raus mit einer ac3 192kbps tonse


    wie du sagst 1gb für sd material ist zu heftig


  • Wenn 12 Ref, dann kann auch bluray compat weg, dann kann bframe-pyramid strict weg, tune film würd ich lassen, geht zu sehr auf die Größe, die Gop-Size muss, so wie bei dir im Bild gesetzt, auch nur für blu-ray compat gemacht werden, nimm lieber 25-250 und open gop, 4 slices erhöhen den speicherplatzbedarf ebenfalls und sind nur für blu-ray strikte Player nötig, ebenso bufsize und maxrate, aud und nal-hdr kann auch weg.
    Dann kannst du auch gleich auf 16 ref gehen und b-frames rauf auf 8 könnte auch nochmal n klitzekleinesbisschen bringen. Den AQ mode schau dir auch nochmal an, auto-variance verbrät mehr als variance und bringt relativ wenig. MB-Tree ist eingeschaltet?


    Die Reframe-Anzeige ist in Mediainfo seltsamerweise immer 1 weniger. Wollte irgendwann mal rausfinden warum.

    Postfächer laufen über. Lange Wartezeiten!

  • Hab nen ähnliches Problem mit Tom und Jerry:
    Die 90 Min Files mit ner Auflösung von 704x560 werden um die 3gb groß, die 10min Files mit selber Auflösung zwischen 180 und 265mb (bisher)




    Mir kommt das viel zu viel vor.


    Irgendwelche Vorschläge oder soll ich doch aufs "gute alte" Xvid zurückgreifen bei dieser uralten Serie? *grad verdammt verunsichert bin*

  • Stell am besten mal 16 Re- und 16 B-Frames ein @ crf20... wenns dann immernoch zu groß ist geh auf crf21 und nimm ein offizielles x264 build.


    btw. croppe das Bild lieber auf 700x560 mit output mod 2, dann hast du eine AR von 4:3 und aktualisiere mal dein mkvmerge, ist mittlerweile schon bei V6.4.1 :eek:


    Das sollte reichen um die Filegröße deutlichst zu veringern... ^^

  • Gna... mir grauts davor, das erste 90 Minuten File erneut durch stax zu jagen.
    Hab für den ersten Durchlauf schon 5 Stunden gebraucht, und das is eindeutig zu heftig (die 10 Minuten Files dauern im Schnitt ne halbe Stunde und das bei Quad Core 3,2gHz und 8gb RAM).


    Die Dauer des Encodes ist ja auch nicht normal bei SD und dieser kurzen Video-Laufzeit, oder?

  • Naja ist eigentlich relativ normal für die Hardware, allerdings dauert bei hohen Re + B-Frames das encoden noch länger, lohnt sich aber meiner Meinung nach auf jeden Fall.


    nochmal btw: rc_lookahead würde ich noch unbedingt auf 60 stellen... und me_range=16 anstatt 24...

  • Normal für die Hardware? Find ich nicht, denn bei Niklaas hab ich mit selben Einstellungen und Resize (was ich hier nicht gemacht hab) grad mal 30 Minuten für nen gut 24 Minuten File gebraucht. Mir kommt 30 Minuten encoden bei nem nicht mal 10 Minuten Film da verständlicherweise schon recht heftig vor *Kopf kratz*


    Ob sich das längere encoden bei der Serie lohnt, wage ich zu bezweifeln, da das Ausgangsmaterial auch nicht viel besser is. Kann es mal versuchen, aber viel Hoffnung hab ich nicht, zumal mir dazu das Auge fehlt, um Feinheiten zu entdecken




    Tante edit sagt;
    Ich hab das File jetzt mal durch den VidCoder gejagt, heraus kamen folgende (evtl. noch anpassungsfähige, sobald ich rausgefunden hab, wie genau) Einstellungen (UTs hab ich mal weg gelassen)



    File ist knapp 800mb kleiner (auch ein paar Unterschiede in den Einstellungen, ich weiß), aber immer noch viel zu groß und hat mich statt 5 Stunden "nur" knappe 70 Minuten gekostet (Logik in der Dauer? Ich hab keinen blassen Dunst)



    Ich kann euch auch gerne mal die vob von Folge 6 zur Verfügung stellen, wo mit meinen (bisher ungeänderten) Einstellungen (siehe mediainfos anderer Post) in stax ne 264 mb raus kommt . Langsam bin ich echt am verzweifen :o

  • Hallo Leute, hallo Engelchen!


    Im Augenblick steh ich leicht auf dem Schlauch..! Was aber wahrscheinlich daran liegt, dass die "Staxxperten" hier oft so schön 'krumme' Werte raushauen. Ich arbeite, wie wohl mitlerweile hinlänglich bekannt, nicht mit STAXX, sondern mir dem (mir) wohlbekannten XMR..! Und von daher kenne ich viele der manchmal eher 'komischen' Einstellungen bei Staxx gar nicht..?! :eek:


    Wenn ich mir die Logs oben ansehe, und dann sehe, dass z.B. MacLeod die Pixel bei einer AR von 4:3 auf 720x540 Pixel, Engelchen den Wert auf 704x560 Pixel, Spezi We$eN wiederum auf 700x560 Pixel stellt, komme ich doch etwas ins Grübeln. Wie kommt ihr eigentlich auf diese Werte? Ich meine.., das soll jetzt beileibe keine Kritik an euren Einstellungen sein, aber etwas komisch isses schon, denn lt. Adam Riese weisen alle diese Einstellungen einen Aspect-Error auf, der letztendlich wieder 'hingebogen' wird, wenn das AR-Flag einfach auf 4:3 eingestellt wird..?! :huh:


    Sollte ich wirklich so daneben liegen, wenn ich hier für meinen XMR im MOD8 bei einem Seitenverhältnis von 4:3 ein Pixelverhältnis von z.B. 704x528 für HQ-MKV (X264) einstelle, wobei mir ein Aspect-Error von '0' angezeigt wird..? ICH entnehme meine Einstellungswerte dem Programm ASPECT , indem ich in dem Programm erst die AR und dann MOD8 (Multipliers = 8 ) einstelle, um mir bei 'Resolution' einen Wert zu suchen, (bei 'Pick Resolution' nur unteren Haken setzen oder selbst ausprobieren!), bei dem der erste Wert bei 720 oder kurz darunter, der Aspect-Error hingegen aber immer bei '0' liegt..! 8)


    Die Einstellungen, die ich mir dort hole (und die ich mittlerweile fast alle auswendig kann!), passen immer, wobei ML der Sache ja noch am Nächsten kommt, gelle..? :D


    Und wenn ich schon mit X264 eine HQ-MKV (aus DVD oder so) erstelle, reicht mir eine Bitrate zwischen 1300kbps und 1500kbps allemal aus, um eine Top-Quali hinzukriegen. Ein 90min-MKV-File liegt dann in etwa bei 1,2 - 1,4 GB, je nach Audio-Spuren, die bei mir fast immer nur in Stereo und 128kbps daherkommen. Für mich reicht das allemal aus..!


    Aber.., jedem das Seine (und mir das Meiste) .., oder so..! ^^


    Gruß, Dragon41

  • Zitat

    mod 8 bei x264 = 6 setzen ;)




    mod 2 ist pflicht bei x264


    Danke, john-doe, für die Notenvergabe..! Aber das mit MOD2 weiss ich doch. Aber die von mir gewählten Einstellungen haben den Vorteil, dass sie gleichermaßen für x264, als auch für x263 (XviD oder DivX) gesetzt werden können. Ich brauche mir nur bestimmte Einstellungen merken, die dann für Beides o-k- sind..! Da passt der Wert für MOD 8 genau so wie MOD2, solange die Werte eine Potenz von 2^x haben.., oder? ^^


    Mein Rechner, mein HDD-Player und mein TV haben sich bisher jedenfalls noch nie über meine Einstellungen bei mir beschwert. Alles dreht sich, alles bewegt sich.., und das in der richtigen Auflösung..! ICH bin zufrieden mit dem, was ich fabriziere.., und das schon seit etlichen Jahren. Und Beschwerden von Leuten, denen ich meine 'Philosophie' auf's Auge gedrückt habe, gab es auch noch nie.., also muss ich doch wohl was richtig machen.., gelle? :D


    Gruß, Dragon41

  • Hm eigentlich wurde ja die Frage gestellt wie man die Filegröße im CRF Mode beeinflussen kann und nicht welches Frontend/AR das bessere ist. :P


    1. crf erhöhen (bis crf 22 sinnvoll)


    2. Re- und B-Frames erhöhen (max. 16)


    3. Kein Tune wie Film etc. verwenden


    4. Bei kornigen Bild Noise Reduction verwenden

  • Keine Kritik jetzt, aber mod2 ist mod8 nur eben mathematisch schärfer ;)


    Setzen 6 ist immer mit bedacht zu wählen, hier ist niemand Oberlehrer und weiß alles.


    720, bzw 704 ergibt sich aus der Digitalisierung, wie ich ja bereits oben ansprach. Die Pixel auf einer DVD sind quasi nie quadratisch. selbst wenn das Material nicht anamorph codiert ist.
    Da ist einfach der Bezug zur Analogwelt sehr tief verankert.
    Der maximale Fehler den man sich aber dadurch einhandeln kann, liegt im Rahmen dessen, was wir alle gewohnt sind und uns nie auffallen würde. Daher kann man das durchaus vernachlässigen.


    Der eine skaliert von 716 auf 704, der andere lässt es bei 716, der nächste cropped auf 704 und freut sich, dass ers so lassen kann. Noch einer cropped auf 718 und nutzt die mod2 Fähigkeit von x264.


    Da ist nichts falsch oder richtig, sondern alles ein Übel. Wichtig ist, dass das was hinterher rauskommt möglichst einen maximalen Fehler von 1% nicht überschreitet, und zwar nach beiden möglichen Digitalisierungswegen. Stax macht das aber schon ordentlich, sofern man die mod-Werte richtig eingestellt hat, zuerst präzise cropped und dann die Zielauflösung einstellt. Um dann noch minimalste Abweichungen zu korrigieren, kann man nochmal das Crop-Fenster öffnen und dort mit der Taste "s" Smartcrop aufrufen, das nimmt ggf. noch mal 2-4 Pixel an den Stellen weg, wo es nötig ist, um den AR-Error zu minimieren.


    Alles keine Teilchenphysik.



    Übrigens, wirklich richtig wäre es mit x264 nur zu croppen, auf resize zu verzichten und in der mkv das Bildseitenverhältnis einzutragen. Warum nicht ein Feature des Containers nutzen, was hilft die maximale Qualität zu erhalten.

    Postfächer laufen über. Lange Wartezeiten!

  • Klein Angel hat nicht resized :D


    Hier mal die


    Is das nu ok so? (auch wenn ich die Zieldatei immer noch riesig finde, aber das Ausgangsmaterial is echt bescheiden)

  • Übrigens, wirklich richtig wäre es mit x264 nur zu croppen, auf resize zu verzichten und in der mkv das Bildseitenverhältnis einzutragen. Warum nicht ein Feature des Containers nutzen, was hilft die maximale Qualität zu erhalten.


    naja, eigentlich wäre es richtig wenn man bei x264 den korrekten sar wert einträgt und das nicht den DAR wert nachträglich im container macht ^^
    Genau berechnet wäre das bei ner 4:3 PAL DVD 16:15, wenn sich die DVD aber an ITU specs hält und dein encode sich auch an die ITU specs halten soll, dann 12:11... da der unterschied aber so minimal ist und wir sowieso nochmal in matroska nen DAR flag haben ist es relativ egal ob man das eine oder das andere nimmt....


    btw Stax stellt selber den sar wert nach ITU specs, ABER es erkennt nicht immer den korrekten wert (je nach dem wie die DVDs gemastert sind, nehme ich an)...
    bei Highlander trägt Stax --sar 16:11 ein, was der sar wert nach ITU specs für 16:9 PAL DVDs ist.... Highlander ist aber 4:3, also muss man bei "Command Line" "Custom switches" noch "--sar 12:11" eintragen, damit es das mit dem richtigen wert encoded...
    kannste auch am ende merken, mit 16:11 wird die mkv mit DAR 16:9 gemuxt, mit 12:11 wird die mkv mit DAR 4:3 gemuxt, mkvmerge erkennt das..


    kurze info zu x264:


    gleich flags die eingestellt werden, überschreiben immer die vorherige...
    wenn man also --sar 16:11 --sar 12:11 in der line hat, wird --sar 12:11 encoded, wenn man --ref 8 --ref 12 drin hat, wird --ref 12 encoded etc etc...
    wenn man was bei custom switches bei stax einstellt wird das an das ende gesetzt, also kann man bei custom switches theoretisch alles überschreiben, was man bei den anderen tabs eingestellt hat....

  • MacLeod, könntest du das Sample auch auf uploaded.net hochladen?


    Sony KDL-40EX720, Sony Playstation 3 Slim, XBox 360 Elite + HDDVD Drive, Pioneer DVD/LD Player DVL-909 + Yamaha APD-1 RF Demodulator, AV-Receiver Onkyo TX-SR608 - Model 2010, Teufel Concept G THX 7.1 Sound System