Posts by gumbel

Nur der Vollständigkeit halber:
mit Requestsoverride bewirkt man genau das Gegenteil dessen, was meine Absicht ist: durch Requestsoverride werden Anfragen von Anwendungen NICHT in den Standbymodus zu wechseln ignoriert damit der PC TROTZ laufender Anwendung schlafen geht.
Nette Sache bei Einschlafstörungen, hier aber völlig wertlos.

Da auch andere Versuche keinen Erfolg brachten, bin ich auf die Lösung ausgewichen vor dem Encoden den Enersparplan auf Höchstleistung zu wechseln (powercfg -setactivescheme) und nachher wieder zurückzustellen. Mit -getactivescheme und -aliases lassen sich die Profile ganz gut verwalten.

Quote from gumbel

Win7 legt sich selbst bei 100% CPU Auslastung schlafen, wenn keine User-Eingaben via Maus/Tastatur erfolgen.
Nach meinen Recherchen müssen Applikationen müssen selbst aktiv den Standby verhindern. Die "neue" x264.exe tut dies nach meinen Beobachtungen.

Edit: nein, tut sie doch nicht. Der PC ist mittlerweile mehrmals bei der Arbeit eingeschlafen *lol*.

Derzeit experimentiere ich mit powercfg herum.
Mit "powercfg -requestsoverride prozess x264.exe system" sollten sich die Ruhezustandsfunktionen deaktivieren lassen.

Jupp, der Renderer wars!
Vielen Dank, Leute, ihr habt mir viel Zeit erspart ;D

(weil an dem HTPC nur ne Röhre hängt hab ich mir die Videos übers NEtz von einem anderen Rechner aus angesehen: mit dem VLC - Dort war was im Eimer, denn der Render ließ sich nicht wechseln. Mit einer neueren Version war das "Problem" dann verschwunden.)

Mangels Zeit (Diplom-Arbeit steht an) muss sich das Encoding-Thema damit für mich leider schon wieder erledigt haben.
An ein automatisches Cropping wag ich mich vielleicht später mal. Also, vielen Dank noch mal - man ließt sich...

Quote from Selur

Was hat sich denn durch den OS-Wechsel geändert, das eine neue Betrachtung nötig ist?

Das Handling des Standby Modus von XP bzw. Win7.
Bei XP war es so, dass es selbst entschieden hat, welche Prozesse einen Standby verhindern können.
Keinen Plan was genau da die Kriterien waren, aber ein Encoding mit x264 war offenbar ein guter Grund für den Rechner sich nicht schlafen zu legen (wohingegen eine pausierte Batch-Datei keiner war).

Win7 legt sich selbst bei 100% CPU Auslastung schlafen, wenn keine User-Eingaben via Maus/Tastatur erfolgen.
Nach meinen Recherchen müssen Applikationen müssen selbst aktiv den Standby verhindern. Die "neue" x264.exe tut dies nach meinen Beobachtungen.
Und im Vergleich zu meiner Version (war, mein ich, noch ne 0.9xx) hat sich einiges an den Optionen geändert, alte weg, neue dazu, Ihr kennt das Spielchen...

Die Bilder sind nicht ganz gleich weil ich die von Hand mitm VLC geschossen hab (oder ist das ein klares no-go?). Ein passendes AVI-Synth Skript um beide Videos gleichzeitig darzustellen hat ich grad nicht bei der Hand.

Das mit dem Croppen ist so eine Sache.
Ich mach die Video-Aufnahmen nur nebenbei (nicht als Haupt-Hobby) und hab mir zu dem Zweck mit Batch etwas zusammengescriptet was meine Intervention auf Haken in TV-Info setzen und gelegendlich Schnittpunkte in Cuttermaran kontrollieren reduziert.
Einen Weg automatisch zu croppen hab ich nicht realisieren können, also belass ich es bei der Quellauflösung - was erstmal der einfachere Weg ist.

Aber ok etwas mehr deblocking könnte ich mal testen und auch ein anderen Renderer werde ich vorher auch ausprobieren.
Mit Mediaportal oder dem DVBviewer sollte ich das vorgeben können - beim DVBviewer gehts in jedem Fall.

Ein intelligenteres Upscaling schon im avi-synth Script macht wenig Sinn weil dass den Speicherbedarf überflüssiger Weise erhöht, hm?

hi,
gezwungen durch den XP -> Win7 x64 Umstieg bin ich mal wieder gewungen worden mich mit der Materie zu beschäftigen...

Original: [Blocked Image: http://www.abload.de/thumb/original4bcm.jpg]

Ergebnis: [Blocked Image: http://www.abload.de/thumb/ergebnisa9xk.jpg]

Im Vollbild (1280x1024) zeigen sich deutliche Verpixelungen, kann man das noch optimieren? Ich weiß, mehr Details als das Original gibts nicht, aber eine rein subjektive Verbesserung wäre auch ok.

- - -

Quelle des Materials ist DVB-S. Ich verwende ein avs-script mit yadif() und Fluxsmooth(4). Das hatte ich bei der letzten Test-Session als gut befunden. Auflösung ist 720x576 (ja ich weiß man könnte croppen...)

%x264% --profile high --preset slower --tune film --crf 20 --b-pyramid normal --sar %SAR% --direct auto --videoformat pal --fullrange on --output "%REENCODE%\%NEXTFILE%.mkv"

Quote from LoRd_MuldeR

BTW: Meinen Encode um Player/Renderer/Treiber Bugs drumherum zu basteln, is das letzte was ich tun würde. Das kann bei dem nächsten Treiber-/Software-Update zu einer bösen Überraschung führen

hm, ja klingt nachvollziehbar. Ich wunder mich nur dass die Optionen so versteckt sind und der Effekt (zumindest bei meinen Encodern) quasi erzwungen werden muss.
Da deine Tipps bisher prima geklappt haben, dank ich dir schon mal im Voraus

Ist die Konvertierung auf den anderen Farbbereich denn so "tiefgreifend"?
Sorry, wenn die Frage blöd ist, bin nicht so sehr in der Theory bewandert... (hatte iegendlich nur den Videodemux und Schnitt-Crashkurs gebucht und dann schon das x264-Intro draufgelegt )

ja danke! Das behebt den Fehler...

Ich schaffs mit dem zoomplayer nicht die richtige Einstellung zu finden.

Der Zoomplayer verwendet bei der Wiedergabe des mkv den Haali Media Splitter (da finde ich aber keine Option bezgl. Farben, YUV, o.ä.) und dann ffdshow und en Video Mixing Renderer 9.
ffdshow hat zwar enige Optionen unter anderen unter RGB Conversion eine Einstellung für die Range, die die bewirkt nichts?

Sprechen denn Gründe gegen die andere Methode? Wie gesagt, SAP ist kein Thema, ich hab einen HTPC und werde diese Richtung auch weiterverfolgen.
(Der Anschluss eines "Fernsehers" über HDMI gilt ja als PC Monitor, oder?)

phu... die Optionen konnt ich bisjetzt noch nicht finden... Der VLC Player sollte doch vollkommen unabhängig von den Einstellungen sein, weil der seine eigenen Dekoder mitbringt? Der hats Problem jedenfalls auch.

Bringt die Änderung in der Quelle denn Nachteile mit sich? Die Videos werden immer von einem PC abgespielt werden... SAP ist kein Thema.

weniger Optionen. Find ich gut.

Juhu! Der Tipp war gut.

ColorYUV(levels="TV->PC")

löst das Problem.

Aber was bedeutet das nun? "Erkennt" der Zoomplayer an der Ausgabe des Avisynthscriptes (die ja als avi erfolgt) dass er den Farbraum anpassen muss und macht das automatisch im Hintergrund?

Eidt: an welche Stelle packt man das sinnvollerweise im Script? An die erste? Oder hinters deinterlacen?

oh danke!
Das mit dem aq-mode hab ich nicht mitbekommen... auch wenn ich mich schon wunderte, dass der in --help nicht auftauchte.
Die anderen beiden hab ich trotz standardwert drin, weil ich die häufiger variert habe um die Auswirkungen zu testen.

Ich habe mal zwei screenies gemacht von dem Farbproblem.
Bild Nr. 6 ist von der Quelle.m2v Bild Nr. 7 ist von einem *.avs mit nahezu beliebigem Inhalt. Hier z.B: "nur"

DGDecode_mpeg2source("h:\quelle.d2v".cpu=0)

und die Farben sehen viel kräftiger aus. Das mkv ähnelt leider mehr dem m2v...

N' abend,

wärt ihr vielleicht so lieb euch die 3 Video samples anzusehen die ich aus dem Fernsehen (DVB-S) aufgenommen habe?

Mir ist beim Vergleich der beiden x264 inputs (*.avs per zoomplayer betrachtet) und des outputs aufgefallen, dass nach dem codieren die Farben verblasst und verwaschen sind.
Allerdings ebenso die der Quelle? Avisynth scheint die Farben zu "verbessern" aber der Effekt schlägt sich nicht im Encoding ergebnis nieder?

Woran könnte das liegen, und (wie) könnte ich das korrigieren?

(bitte nicht über den Inhalt wundern, der ist zusammengeschnipselt. Auch habe ich den Eindruck die die gesendete Quali unter aller Sau ist. Und ja, sar 64/45 ist nicht "richtig", erzeugt aber die "richtige" DAR ohne cropping)

Origrinal: http://rapidshare.com/files/150091214/quelle.m2v.html

AVS-Script 1:

DGDecode_mpeg2source("c:\quelle.d2v",cpu=0)
#deinterlace
Load_Stdcall_Plugin("C:\AviSynth 2.5\plugins\yadif.dll")
Yadif(order=-1)
#crop
#resize
#denoise
FFT3DFilter(sigma=2, sharpen=0.3)

x264 CLI 1
"c:\x264.exe" --crf 19 --partitions all --8x8dct --subme 6 --ref 5 --me umh --mixed-refs --bframes 16 --direct auto --aq-mode 2 --aq-strength 1.0 --bime --b-rdo --weightb --b-pyramid --trellis 1 --deblock 1:1 --sar 64/45 --progress --no-ssim --no-psnr --thread-input --threads auto --output "c:\ziel v1.mkv" "c:\quelle v1.avs"

Ergebnis 1: http://rapidshare.com/files/150090025/ziel_v1.mkv.html

AVS-Script 2:

DGDecode_mpeg2source("h:\quelle.d2v",cpu=0)
#deinterlace
Tdeint(mode=2, full=false)
#crop
#resize
#denoise

x264 CLI 2: (maßgeblich von Akapuma übernommen - ich wollt mal mit was erprobtem vergleichen)
"c:\x264.exe" --crf 22 --sar 64/45 --keyint 500 --min-keyint 125 --scenecut 80 --ref 6 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --me umh --merange 32 --b-rdo --bime --weightb --subme 6 --partitions all --qpstep 8 --aq-strength 0.5 --direct auto --b-bias 30 --thread-input --threads auto --progress --no-psnr --no-ssim --output "ziel v2.mkv" "quelle v2.avs"

Ergebnis 2: http://rapidshare.com/files/150089107/ziel_v2.mkv.html

Ich danke euch für euere Vorschläge und Meinungen!

Ich muss HQ-LQ leider zustimmen.

Ein unbearbeiteter ts Stream (DVBviewer, DVB-S) sieht im zoomplayer und im VLC Player auf "abgeleitet" nur dann exakt genauso aus, wie der x264 output, (ohne croppen, resizen & co.) wenn ich als sar 64/45 angebe.

Und das macht doch auch Sinn...?
Die 720x576 Pixel erzeugen ein 5/4 Seitenverhältnis, korrigiert mit 16/15 ergibts 3/4.

Wenn ich auf PAL croppe (704x576) entsteht 11/9, korrigert mit 12/11 machts 4/3.

btw: es wird Zeit für einen einfacheren Standard. 4/3 stirbt ja auch.

äh...ne, fand mein ursprüngliches statement schon eindeutig, wenn auch nicht so schön formuliert, wie beim 2. Anlauf, aber egal :cool:

ja, sicher, ich nutze es jetzt nicht.
Wollt mir nur ne zweite Meinung dazu einholen... könnt ja sein dass auf jeden Fall ein Unterschied spürbar sein müsste... z.b. wie zwischen crf und 2-pass^^ (ok, zeitlich gesehen ist es das auch).

ich mach erst noch eine zeitlang zwei Konfigs parallel, einmal mit 1000 und einmal mit ner höhren bitrate, da das doch der maßgebende Einfluss ist.
Mal schauen, wie die Videos dann so insgesamt werden...

ich red nich vom 2-pass sondern von --ref 16.

"Die Option Max Ref Frames legt fest wieviele andere Bilder auf der Suche nach Ähnlichkeiten durchsucht werden. Bei Auflösungen die größer oder gleich der Auflösung einer DVD sind sollte man hier nicht mehr als 5 nehmen, da man sonst nur seltenst noch eine Verbesserung erziehlt jedoch einiges mehr an Zeit beim Kompromieren benötigt. Bei sehr niedrigen Auflösungen, etwas 320x240 und kleiner kann man hier aber durchaus auch Werte bis 16 nehmen." [http://www.flaskmpeg.info/board/thread.php?threadid=5138]

"Anzahl der erlaubten Referenzframes. In Xvid und DivX sind P-Frames auf genau ein Referenzbild beschränkt, und zwar auf das vorangehende Bild. x264 erlaubt auch mehrere Referenzframes. Sinnvoll sind etwa 5. Deutlich mehr steigert hauptsächlich die Codierzeit, nicht mehr die Qualität. Die Einstellung wirkt sich auch auf B-Frames aus."
[http://encodingwissen.de/codecs/x264-cli.html]

In meinem Test brachte --ref 16 nur einen sehr viel höheren Zeitaufwand ohne gleichermaßen großen Effekt auf die Quali oder Dateigröße, daher meine Frage.

@ selur: welchen sinn machen die vielen ref frames in deinem config-vorschlag? nach meinen neuesten Test erhöht sich dadruch die encoding Dauer extremst (~3), ohne positive Auswirkung auf die Dateigröße...

werde nun mal folgendes benutzen:

x264 --pass 1 --bitrate 1515 --ref 1 --bframes 16 --b-bias 0 --b-pyramid --b-rdo --bime --weightb --direct auto --ratetol 2 --qpmin 10 --qpmax 49 --qpstep 8 --partitions none --me dia --subme 1 --mixed-refs --8x8dct --trellis 0 --no-dct-decimate --no-fast-pskip --aq-mode 2 --aq-strength 0.8 --deadzone-inter 8 --deadzone-intra 8 --threads auto --thread-input --filter -2,-1 --no-psnr --no-ssim --stats "test.stats" --progress

x264 --pass 2 --bitrate 1515 --ref 5 --bframes 16 --b-bias 0 --b-pyramid --b-rdo --bime --weightb --direct auto --ratetol 2 --qpmin 10 --qpmax 49 --qpstep 8 --partitions all --me umh --subme 6 --mixed-refs --8x8dct --trellis 1 --no-dct-decimate --no-fast-pskip --aq-mode 2 --aq-strength 0.8 --deadzone-inter 8 --deadzone-intra 8 --threads auto --thread-input --filter -2,-1 --no-psnr --no-ssim --stats "test.stats" --progress

F**K!:motz:

vlc ist schuld, dass alles gleich aussieht! Mitm zoomplayer sieht das gleiche File völlig anders aus!

Selurs config hat ebenso wie das crf 18 encoding ohne weitere Optionen kaum Blocking, aber ~ die halbe Dateigröße.
Mit LTJs config, crf 25 und Aq-strength 1 gibts fast ein ebenso gutes Bild, aber nochmal ein drittel kleiner. Gegenüber aq-strength 0.5 sinkt die Größe sogar.

probleme welcher Art?

mich beschleicht, das Gefühl, dass hier ebenfalls keine sichtbaren Unterschiede (in der Quali) auftreten...http://rapidshare.com/files/11324655…t_LTJ_.zip.html
und das trotz doppelter Filegröße bei crf18?

Kann sich das bitte wer angucken?

Edit: ok, bei aqstrengh hab ich vergessen umzustellen^^ ist nicht 1 sondern weiterhin 0.5

Edit: neuer Versuch mit aq an/aus und einer minimalen Konfig die nur --crf 18 enthält : http://rapidshare.com/files/11326733…_LTJ_3.zip.html

Die qualitativen Unterschiede sind minimalst. Wie kann ich x264 zwingen in vermeintlich homogenen Farbbereichen keine Makroblocks zu hinterlassen?

hm Qualitätsparanoia hab ich nicht (Verleugnung is das erste Anzeichen, oder? :D), nur eben diese schlechtere Grundqualität vom DVB gegenüber DVD muss sich ja auch irgendwo in der Config/Dateigröße bemerkbar machen?

Ich bin erst jetzt (besser spät als nie) dahinter gekommen bin, dass ich die Videos am besten vergleichen kann, wenn ich sie nebeneinander und daher seitlich beschnitten auf dem Bildschirm synchron ablaufen lasse.
Ein Standbildvergleich ist blöd, da zu sehr vom einzelnen Frame abhängig (das hab ich gemerkt, als ich zwei gleiche Files verglichen hab und eines besser fand^^) und auf zwei -unterschiedlichen- Monitoren bringts auch nichts.

Nu muss ich doch feststellen, dass ich im Ergebnis keine optischen Unterschiede zwischen dem kleinsten (LTJ) und größten (Brother John) Ergebnis feststellen kann. Könnt ihr mir da beipflichten, oder hab ich Tomaten auf den Augen?:cool:

Ich habe ja gar nicht die Anfordung das beste Bild bei kleinster Größe zu erhalten, aber für eine bestimmte Dateigröße möchte ich schon das optimale Bild.
Da ist deine Konfig vermutlich ein sehr guter Treffer, da meines Erachtens bei den beiden Alternativen trotz 36% größerer Datei keine Unterschiede festellbar sind. - Sind halt beide, wenn ich das richtig sehe auf DVD Config optimiert, wo die Ausgangsquali erheblich besser ist.
Durch die Umwandlung verbessert sich die DVB Quali sogar etwas, weil das Bildrauschen wegrationlisiert wird^^

Nu werd ich wohl versuchen noch ein paar von den Blöcken weg, bzw. diese kleiner zu bekommen. Die Zeit für den Durchlauf find ich völlig ok, sodass ich natürlich am liebsten auf Kosten dieser die Quali erhöhe....

Irgendwelche Vorschläge? sonst fang ich mal mit --crf 18 und --me tesa an?

hast du denn noch was im aviscript?

nach den erkentnissen aus king kong tendiere ich dazu ein Mittelding zwischen deiner und selurs konfig finden zu wollen.

D.h. bei deiner config den crf etwas runter (ist das der richtige weg um die quali zu justieren, oder sind da noch andere optionen maßgebend?) oder bei der von selur die Filesize etwas eintampfen. (auch hier: primärer parameter dafür ist die Bitrate?)

edit: original Aufnahme (wild zusammengeschnitten):
http://rapidshare.com/files/11304915…g_test.mpg.html

edit:der Übersichthalber die verwendeten Konfigs:

Brother John:

--partitions none --me dia --subme 1 --ref 1 --bframes 16 --direct auto --no-dct-decimate --deblock -2:-1 --pass 1 --bitrate 1515 --progress --no-ssim --no-psnr --stats "file.stats" --output NUL "input.avs"--partitions all --8x8dct --ref 5 --mixed-refs --bframes 16 --direct auto --bime --b-pyramid --trellis 1 --no-dct-decimate --deblock -2:-1 --sar %SAR% --pass 2 --bitrate 1515 --progress --no-ssim --no-psnr --stats "file.stats" --output "output.mkv" "input.avs"

Selur:

--pass 1 --bitrate 1515 --level 5.1 --ref 1 --keyint 500 --min-keyint 25 --scenecut 40 --bframes 16 --b-bias 0 --b-pyramid --b-rdo --bime --weightb --direct auto --ratetol 2 --rceq "blurCplx^(1-qComp)" --cplxblur 20 --qcomp 0.4 --qblur 0.5 --qpmin 1 --qpmax 51 --qpstep 16 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --direct-8x8 1 --partitions i4x4,i8x8,p8x8,b8x8 --me dia --subme 1 --mixed-refs --8x8dct --trellis 0 --no-fast-pskip --aq-mode 2 --aq-strength 1 --deadzone-inter 8 --deadzone-intra 8 --threads auto --thread-input --filter -2,-1 --no-psnr --no-ssim --stats "file.stats" --progress --output NUL "input.avs"--pass 2 --bitrate 1515 --level 5.1 --ref 16 --keyint 500 --min-keyint 25 --scenecut 40 --bframes 16 --b-bias 0 --b-pyramid --b-rdo --bime --weightb --direct auto --ratetol 2 --rceq "blurCplx^(1-qComp)" --cplxblur 20 --qcomp 0.4 --qblur 0.5 --qpmin 1 --qpmax 51 --qpstep 16 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --direct-8x8 1 --partitions all --me umh --merange 40 --subme 7 --mixed-refs --8x8dct --trellis 1 --no-fast-pskip --aq-mode 2 --aq-strength 1 --deadzone-inter 8 --deadzone-intra 8 --threads auto --thread-input --filter -2,-1 --no-psnr --no-ssim --stats "file.stats" --progress --output "output.mkv" "input.avs"

lessthanjake:

--crf 25 --ref 3 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --sar %SAR% --aq-strength 0.5 --output "output.mkv" "input.avs"