Du kannst im crf-Modus nicht auf die Dateigröße schließen.
Ich habe teilweise bei 20 Folgen einer Serie Abweichungen zw 650MB und 1.1GB Dateigröße.
Bei SD habe ich "--crf 20 --preset slow --tune film (manchmal auch grain)" für mich als Optimum ermittelt.
Jetzt mussich nur noch wissen wie viele Kerne ich eintragen muss....
Du mußt/kannst eine 0 eintragen (steht für automatisch).
Wenn ich ein Verfahren habe, welches funktioniert und dann ein anderes versuche, welches nicht funktioniert.
Was mache ich dann wohl?
Egal wie, ein einheitlicher Standard wäre schön (sagen wir mal in 3 Größen 576p, 720p und 1080p).
Ich fürchte aber, daß wird in den alt hergebrachten Strukturen ein Wunschtraum bleiben.
Aber vielleicht gibts in 10 Jahren ja nur noch iTunes-TV oder sowas.
Also rein technisch betrachtet, würde ich die Daten nicht nochmal reencoden.
Offensichtlich wurden sie ja schon einmal nach DivX gewandelt und sind quallitätsmäßig nicht so der Bringer.
Sie werden davon nicht besser und es kostet dich nur Rechenzeit.
Cutte doch einfach die überflüssigen Teile mit vdub oä.
Ich würde da weiter keine Zeit verschwenden, Neuron zu überzeugen.
Ich lad mir grad mal dein .rar runter.
Nur mal so interessehalber: hast du die Probleme nur mit Dateien von OTR?
Also ich hab noch sone transportable Schüssel.
Da waren ein Saugfuß dabei (um das Ding an ne Fensterscheibe pappen zu können)
und eine Art Schraubzwinge (zB für Geländer).
Wenn du das Ding ohne zu Löchern auf den Boden stellen willst, würde ich sowas wie einen Schirmständer nehmen (möglichst schwer).
zwischen 1376 und 1391 gabs glaube keine veröffendlichten Versionen.
Mit 1391 wurden die neuen Inputmöglichkeiten eingeführt (lavf, ffms2).
Mann könnte nun alle Quellen direkt an x264 übergeben, die ffmpeg auch beherrscht.
Es fehlen aber noch die Filtermögichkeiten (crop, resize usw.)
Deine MeGUI-Version (zu alt) und deine x264-Version passen nicht zusammen.
Ein Update sollte das lösen.
Kann es sein, daß Hybrid Probleme macht, wenn es mkv-Dateien vorgesetzt bekommt, die Kapitel enthalten.
Es stürzt dann gleich bei der Analyse ab (bzw schließt sich komplett).
Grüße Pitti
es wird immer noch als vermißt gemeldet (Hybrid_100128_2_64bit_binary)
Warum suchst du eigendlich danach?
Kannst du nicht einfach nen Probeaufruf machen zB.: mediainfo --Version
bei mir wird jedenfalls das angezeigt:
mediainfo --Version
MediaInfo Command line,
MediaInfoLib - v0.7.25
liegt in /usr/bin
zu Hybrid unter Linux: beim Starten kommt ne Melde, daß Mediainfo nicht installiert wäre (Ist es aber).
Danke für die Info, habe auch etwas recherchiert und die meisten verwenden CRF 18 - 22 für ihre Rips. Da ich auch auf Beamer und auf dem geplanten 4x Zoll Fernseher noch anständig schauen will, werde ich wohl sicherheitshalber mal auf --preset veryslow schalten und dann mal mit crf 18-20 probieren und vergleichen mit bisherigen Rips.
Mußte eben mal bissel mit kurzen Schnipseln rumtesten, wie es für dich am angenehmsten ist. Letztlich ist es beim runterkomprimieren immer ein Kompromiss.
Also ich bin mittlerweile vollständig auf crf-encoding umgestiegen.
Mit der Qualität bin ich sehr zufrieden. Der Haken daran ist, daß du die Endgröße nicht abschätzen kannst.
Ich hatte bei anamorphen SD-Material teilweise Schwankungen zw. 450mb und 1gb (aber immer noch kleiner als die Orginale)
Bei DVD sieht meine line so aus:
x264 --demuxer yuv --crf 20 --preset slow --tune grain (oder film)
Bei 720p --crf 18 bis 20 --preset slower
Bei Digisataufnahmen reicht mir crf 22
Ich hoffe Selur ist uns für die Abschweifungen nicht all zu böse ;D
Also du willst ja nur recoden ohne irgendwie zu filtern.
Dann probier doch mal die neuen Inputmöglichkeiten von x264 ab 1391 selber aus.
zB so:
x264 --crf 20 --preset slower --tune film --output "neu.mkv" "alt.mkv"
2pass geht auch (siehe x264 --fullhelp)
"-lavcopts threads=4 -lavdopts threads=4" evtl auch mal auf 1 stellen.
Das bringt eh kaum Vorteile. (ich konnte zumindest keine ertesten)
Das mit den Farbverwirrungen kommt, wenn -pix_fmt yuv420p (oder format=i420 bei mencoder) fehlen.
Mit x264 v1391 wurden zB auch neue Inputformate hinzugefügt (lavf und ffms).
Ich muß zB in meiner Config nun x264 mitteilen, welcher Demuxer verwendet werden soll (--demuxer yuv in meinem Fall).
Standard wäre --demuxer auto, aber das funktioniert nicht immer.
vermute aber eher, dass es an dem großen Sprung von x264 liegt
Das wollte ich mit meiner obigen Ansage eigendlich entkräften.
Ich habe hier unter Linux mit selbst compiliertem x264 keine Einbrüche festgestellt. Ich habe seit (sagen wir mal) einem halben Jahr ca 20fps bei SD-Material.
dass die Betroffenen mit etwas mehr Details herausrücken
jep, ohne geht nix.
