Beiträge von tenim

hallo,

also, ich bin vor einiger zeit durch zufall auf brother johns "schneller erster pass"-einstellungen gestolpert und habe die für einige meiner anstehenden eoncodings benutzt, da ich ausschliesslich mit nur einem pass (crf 21) kodiere.
bisher war ich immer der meinung, daß das zuschalten von allen möglichen dingen weight prediction, umfassende bewegungsabschätzungseinstellungen,
allen partitionstypen uws. die zielqualität im vergleich zum schnellen 1pass erhöhen müsste, da beim schnellen 1pass fast alle diese einstellungen nicht gemacht werden. wohlgemerkt, ich jede nur von 1pass encodings mit crf.
jetzt kam für mich das ergebniss: die bildqualität des ziels beim schnellen 1pass ist im vergleich zum 1pass mit allen einstellungen wie z.b. hexagon motion estimation und subme 6 gleich gut bis besser!!!

nach einigem überlegen kam mir die eine mögliche erklärung, warum das so sein könnte:

fast alle cli-einstellungen in x264 beziehen sich direkt oder indirekt nur auf die kodiereffizienz des videomaterials, also um wieviel byte das ziel kleiner ist als die quelle -die einstellungen haben nichts mit der bildqualität zutun(ausser z.b. die inloop-filter einstellung).
sie beeinflussen die bildqualität nur indirekt, nämlich wenn man eine zu harte komprimierung "fordert" und dadurch zwangsläufig bilddetails geopfert werden müssen. die cli-einstellungeen beschreiben doch nur die art, auf die man versucht die datenrate zu senken, z.b. durch gute b-frame-verteilung oder gute bewegungsabschätzung.

dadurch, das beim schnellen ersten pass fast alle diese dinge deaktiviert sind, braucht der encoder das videomaterial z.b. nicht in kleinere partitionen zu zerlegen und diese dann zu versuchen einzeln zu kodieren(was eventuell verlustbehafteter sein könnte), sondern er kodiert einfall alles in maximaler grösse und die datenrate spielt keine rolle. so ist der qualitätsverlust am minimalsten.

meine zeildateigrösse war aber trotzdem in ordnung, ungefähr ein drittel der originalgrösse.

ich weiss nicht ob ich da richtig liege, aber die qualität ist nunmal gleich oder besser der anderen methode. ich habe mehrere schlüsselszenen bestimmt 20mal genau angeschaut, und es gab keine unterschiede und oft sogar bessere quali beim fast 1pass.

kann das jemand bestätigen bzw. gibt es eine andere und bessere erklärung dafür?

vielen dank ! das wusste ich nicht. hatte ich irgentwie immer übersehen, diese einstellung. wer kommt auch darauf, das "preview" etwas mit schneiden zutun hat.

mal schauen, wie das genau funktioniert, anscheinend kann man ja nauch mehrere schnittblöcke definieren.

ok, habs selbst rausbekommen.:)
ich lasse einfach dgindex nochmal laufen, nachdem staxrip es beim ersten demuxen benutzt hat. muss dann nurnoch den dateinamen des neuen audio-output von dgindex in staxrip anpassen, wenn der einen neuen delay-wert hat. alles andere bleibt gleich.

hallo,

ich habe einen film mit ner dvb-karte aufgenommen (.pva), dann mit pvastrumento nach mpg2 übergeführt. soweit so gut. der film muss allerdings jetzt um einige frames gekürzt werden, um die werbung rauszukriegen.
jetzt meine frage: wie mache ich das in staxrip?
einen filter hinzufügen mit trim() kriege ich irgentwie nicht hin und selbst wenn, wie soll ich dann die beiden trim-parameter startframe und endframe herausfinden? staxrip zeigt mir keine framewerte an. und selbst dann müsste doch der ton nicht mehr synchron laufen, denn staxrip zerteilt das video doch schon am anfang, bevor ich dann mit avisynth schneide.

geht das villeicht mit dgindex manuell? nur wie bringe ich das dann staxrip bei, die manuell extrahierten daten zu verwenden?

hab auch probiert, zuerst mit cuttermaran zu schneiden, geht nicht, der kann keine mpg2-dateien von dvb verarbeiten ("packetsized streams are not supported").

hab noch eine 2. frage. wie kann ich in staxrip mit sicherheit feststellen, ob das quellmaterial interlaced ist, und muss ich dann in jedem fall den deinterlace-filter anwenden?

danke

wenn man nach staxrip noch das mkvmerge-gui zum manuellen zweitmuxen nimmt (z.b. um .srt untertitel dem container hinzuzfügen) muss man noch auf etwas wichtiges achten: die audiodateien, die man dann auch hinzufügt, werden AUTOMATISCH mit ihrem uhrsprünglichen delay-wert den staxrip am anfang ermittelt hat eingefügt. das heisst, wenn man ein delay <>0 hat, ist dann auch im mkvmerge-gui dieser wert eingetragen und man muss ihn auf 0 zurücksetzen, weil ja besweet die anpassungen schon vorgenommen hat(hab ich aus dem encodingwissen:) ). sonst ist der sound nicht syncron zum video. hatte ich neulich.

es lag eindeutig an meinem quellmaterial. hab jetzt sehr hochwertiges videomaterial genommen, bei dem man auch visuell absolut keine fehler sieht. und siehe da, nach dem encoden mit crf=20, inloop filter 1:1 (singe pass)
=
eine für mein dafürhalten indentische kopie! hab auch nach längerem schauen keine artefakte oder mosaikbildungen ausmachen können. ausserdem ist die zeildateigrosse nur ca. 21% der originaldatei. mit dem guten ausgangsmaterial es ist dem encoder halt leicht gefallen, die erforderliche qualitätsstufe zu halten, ohne grosse klimmzüge machen zu müssen. gleichfarbige flächen sind leichter zu komprimieren als flächen mit geringer mosaikbildung, weil er da ja nicht wissen kann, das dieses "muster" nicht gewünscht ist und alles versucht das identisch zu kopieren.
bei meinem alten material war auch die zieldateigrösse ca. 33% der originaldatei (und das bild etwas schlechter).

den convert-filter brauchst du eigentlich nicht, wenn du nur mpeg2 source und crop als filter hast. villeicht hasttest du vorher noch andere filter drin, bei denen diese fehlermeldung kam?

klicke mal auf tools->extern applications und schaue, ob er auch wirklich alle benötigten programme installiert hat. wenn nicht, auf "download" gehen, er macht dann den rest.

die mosaiks sind auch im original vob-file zu sehen. aber dort ist deren grösse sehr klein und die farbunterschiede sind auch nicht so gross.
das videomaterial ist "aika new missions", die erste misson, erste 6s.

bei meinen bisherigen encodings waren dann meine mosaiks viel grösser und auch die farbunterschiede waren imho stärker.

jetzt hab ich einen single pass mit crf=18 und deblocking-filter auf 1:1 encodiert. damit geht es jetzt einigermassen. wenn ich das ae-profil von sharktooth für maximale quali nehme, ist das ergebniss am besten, aber dann dauert jeder encodingvorgang ca. 8x so lange wie der clip läuft(2.8-3fps). das ist mir eindeutig zu lange, vorallem weil ich vorhabe meine ganze anime-sammlung umzuwandeln. aber 70 minuten encoding für 28 minuten film sind ok.

ich könnte natürlich auch mit zonenangaben arbeiten und der kritischen zone crf=12 zuweisen, sonst crf 20. aber ich kann doch nicht auf dauer jedes video das ich umwandeln will, erst anschauen und analysieren.
ich brauche einfach ein optimales profil für anime mit min. 10fps renderspeed für hardware >=athlon 64 x2 4400+.:)

Zitat

Warum dann das Quellmaterial nicht behalten?

quelle sind meine dvd´s. die rips sind quasi schutzkopien und gleichzeitig abspielquellen für meinen medienrechner der mit dem tv verbunden ist.
auserdem muss ich dann nicht jedesmal in den dvd-taschen suchen, wenn ich einen film schauen will.

Zitat

Adaptive Quantizer

der parameter ist doch crf, oder?
wenn ich crf=12 nehme, sind die mosaiks weg, allerdings ist die datei dann auch
fast 3/4 so gross wie das mpeg2-original.

ok, hab den letzten satz rausgenommen. *rolleyes*

hallo,

habe ein problem beim encoden von anime-material. benutze staxrip und das voreingestellte x264 "constant quality"-profil. damit bin ich eigentlich immer gut gefahren. die ae-profile nehme ich nicht, da bei verschiedenen tests meinerseits das ergebnis nicht anders aussah als beim "constant quality" oder hq-slow profil. ausserdem hab ich bei den ae-profilen im 2. pass nur max. 2.8 fps. (athlon 64x2 4400+!)

wie gesagt, das constant-quality -profil ging eigentlich immer gut, aber jetzt hab ich material, bei dem es bei einer szene grobe mosaikbildungen gibt. in der szene bewegt sich die kamera mit mittlerer geschwindigkeit an grossen, einfarbige flächen vorbei.
und genau auf diesen flächen sieht man dann grobe mosaikbildungen, anstatt der einfarbigen flächen.

habe den verdacht, das er sich denkt: "bei schnelleren bewegungen brauche ich nicht so genau rechnen/auflösen, das sieht der user sowiso nicht."
kann das sein? und wenn ja, gibt es einen kommandozeilenschalter der dieses verhalten abschaltet?
den schalter "no fast p skip" hab ich probiert, ergebniss war dasselbe.

bitraten oder dateigrössen sind mir relativ unwichtig, wichtig ist mir nur das quellmaterial ohne sichtbare verluste in h264 zu kriegen undzwar in einer moderaten zeit (>=10 fps renderzeit).

hab ich. er zeigt alles an: video, 2x audio und einmal S_VOBSUB (ID 4, type:subtitles).
das default track flag ist für den subtitel ausserdem gesetzt.

hab dann einfach die fertigen video und audiodaten die staxrip generiert hat manuell mit dem mkvmerge-gui gemuxt. dann hat alles funktioniert. ich hatte .srt untertitel !

theoretisch ist alles ganz einfach:
1. mit staxrip sein video komplett rippen (aber ohne untertitel).
2. die fertige .mkv-datei mit dem mkvmerge-gui öffnen, die .srt subtitel-datei hinzufügen und neu muxen.
fertig.

neumuxen muss man wohl immer selbst. aber damit kann ich leben, den rest der arbeit nimmt mir ja staxrip ab.

danke für die antwort. hatte dein encodingwissen erst gerstern im internet gefunden, runtergeladen und war mit dem durcharbeiten gerade dabei. sehr gute doku, nur das ganze manuell zu machen wollte ich halt nicht. nun muss ich das aber wahrscheinlich doch.

edit:

habe gerade die neue staxrip-version 1.0.0.0 runtergeladen, installiert und wie dort empfohlen die untertitel mit vsrip aus dem vob extrahiert (eine .idx und eine .sub kamen dabei raus). die .idx hab ich im mkv kontainer angegeben und im unteren fenster den erschienen untertitel auch markiert (er übernimmt das auch in die mkvmerge -kommandozeile). aber im video sehe ich trotzdem keine untertiel, obwohl ich diese im vlc-player zuschalten kann ?!?

naja, ist irgentwie doch komisch.

hallo liebes forum:D

ich probiere jetzt bestimmt schon mehrere stunden rum, krieg es aber einfach nicht hin, in der aktuellen version von staxrip (0.9.9.9) optionale untertitel
bei x264/mkv einzufügen. sonst geht alles bestens.
habe mit subrip eine .srt datei von meinem vob-file erstellt, deren inhalt auch korrekt ist. als permanenten untertitel kann ich die datei einfügen (neuer filter "textsub"...). aber wenn ich auf "container configuration" gehe, erlaubt er als source file nur *.idx -dateien einzufügen?? in der doku von mkvmerge(was staxrip ja wohl zum muxen nimmt) steht aber eindeutig, das .srt files supported sind. wenn ich als container aber mp4 nehme, kann man problemlos das .srt file einfügen. warum nicht mit mkv? ich will unbedingt in diesem format bleiben.

ich habe den dateinamen in der "container configuration" auch manuell angegeben. aber wenn ich dann auf tools->show command line gehe,
sehe ich, das es keinen neuen parameter mit der subtitle-datei gibt.

das kann doch nicht so schwer sein. wenn es bei mp4 so leicht geht, warum dann nicht mit mkv?