text: sx264 public alpha - Seite 35 - MPEG-4-Encoding - Gleitz | german Doom9 DVD-Forum
  Könnte durchaus an der x264 Version liegen, hab gerade gelesen, dass die Automatische Inputerkenneung wohl nicht immer fluppt und da der build den Du nutzt (nebenbei: der build ist älter als der im Paket) auch mit "lavf&ffms input" erstellt wurde, kannst Du das Problem eventuell auch lösen, wenn Du unter Analysing als Command line addition --demuxer "yuv" angibst.
  "-lavcopts threads=4 -lavdopts threads=4" evtl auch mal auf 1 stellen.
  Das bringt eh kaum Vorteile. (ich konnte zumindest keine ertesten)
  Das bringt eh kaum Vorteile.
  kommt auf den Input an.
  Dürfte eigentlich keine Probleme machen wenn nicht der MPEG-2 Decoder verwendet wird,...
  Es liegt wohl am Deinterlacer.
  Mit AUTO sieht es aus wie beschrieben.
  Mit LINEAR habe ich statt auf der rechten Seite "nur noch" links einen 10 Pixel verschobenen Streifen und oben einen etwa 10 Pixel breiten Streifen in grün.
  Mit NONE sieht es aus wie bei AUTO(Quelle ist ja auch progressive, daher wird bei AUTO wohl auch NONE gewählt).
  mit IVTC habe ich links einen 5 Pixel breiten verschobenen und oben einen ca 5 Pixel breiten grünen Streifen.
  mit YADIF oben einen 5 Pixel breiten grünen Streifen und rechts rund 40 Pixel verschoben.
  mit BOB das Gleiche wie bei YADIF.
  Bei inverse Telecine scheint zwar das Deinterlacing vom Bild her hinzuhauen, die Streifen links und oben hätte ich aber trotzdem gerne noch weg... Im Quellmaterial sind diese natürlich nicht vorhanden! Achja: das Quellmaterial wurde mit x264 core 61 r938M 9881ffd encodet. 29,970 FPS werden korrekt erkannt von sx264 - einzig die PAR ist mit 1000:1001 (Quelle) anders als beim Encode (1000:1000) aber auch das sollte den Fehler nicht hervorrufen.
  Mal den Vorschlag bzgl. der 'Command line addition' ausprobiert?
  Ansonsten brauch ich halt ein kleines Sample zum Testen, mit meinen Testfiles gibt es keine Probleme.
  Habe ich probiert, und auch 3 x264 Versionen durchprobiert (1171, 1347, 1391)
  nur ergänzend: abgespielt mit VLC, MPC und einem Standalone (WD TV Live) - überall das Gleiche
  Mit FFMPEG sieht es jetzt besser aus.. ich bin auf dem richtigen Weg. Lasse jetzt mal Encodes mit voller Länge durchlaufen und melde mich morgen.
  2 Mal editiert, zuletzt von Jugster ( 26. Januar 2010 )
  Also du willst ja nur recoden ohne irgendwie zu filtern.
  Dann probier doch mal die neuen Inputmöglichkeiten von x264 ab 1391 selber aus.
  x264 --crf 20 --preset slower --tune film --output "neu.mkv" "alt.mkv"
  2pass geht auch (siehe x264 --fullhelp)
  zu CRF habe ich auch direkt eine Frage: ich codiere bisher fest mit 1200 kbit (sowohl DVDs als auch 720p).
  Jetzt fange ich allerdings auch an, höhere Ansprüche an die Rips zu stellen. DVDs sollen in etwa die gleiche Dateigröße beibehalten, von CRF verspreche ich mir das bei gleichzeitig gesunkenem Encodingaufwand.
  Bei Blue Rays will ich natürlich die Qualität auf hohem Niveau halten; wenn ich mir andere Encoder anschaue rippen die dort mit rund 4000-5000 kbit. Was kann ich denn als Richtwert nehmen bei CRF?
  Da ich falls ein Bug in sx264/Hybrid existiert diesen gerne fixen würde möchte ich doch nochmals um ein kleines Sample bitten,... (kann man z.B. bei MedaUpload hochladen und mir per PM einen Link schicken,...)
  Außerdem wäre ein kompletter DebugOutput sinnig.
  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
  Ich hoffe Selur ist uns für die Abschweifungen nicht all zu böse
  Geht so, würde halt gerne wissen ob es sich um ein sx264/hybrid Problem handelt oder nicht,...
  Hybrid ver. 100126
  - m2ts overhead calculations
  (will port this to sx264 when I get some feedback if it works :))
  2 Mal editiert, zuletzt von Selur ( 28. Januar 2010 )
  Es liegt eindeutig am MENCODER, mit FFMPEG habe ich jetzt 5 verschiedene Files umgewandelt und die sind alle einwandfrei. Irgendwie kommt der MENCODER nicht mit dem Inputformat zurecht oder interpretiert es falsch.
  Sei mir bitte nicht böse wenn ich da keine Zeit mehr investieren möchte um dem Fehler auf die Schliche zu kommen. Ich werde allerdings mal in ein paar Tagen die Zeit haben, die Files durch Hybrid zu jagen (statt sx264). Brauche ich dafür das gleiche Grundpaket wie für sx264?
  ps: die beiden von mir weiter oben genannten Bugs (und die du nicht nachvollziehen konntest) sind verschwunden nachdem ich sx264 komplett neu installiert habe.
  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.
  Brauche ich dafür das gleiche Grundpaket wie für sx264?
  Zitat von Jugster
  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.
  Hybrid ver. 100128
  - problem with win32 build (b0rked build environment)
  - revision into debugInfos
  - subtitle, set as forced for mkv output option
  Reset Defaults in Misc-register on first start
  http://www.selur.info/hybrid/Hybrid_100128_64bit_binary.zip
  Einmal editiert, zuletzt von Selur ( 28. Januar 2010 )
  zu Hybrid unter Linux: beim Starten kommt ne Melde, daß Mediainfo nicht installiert wäre (Ist es aber).