Ich habe jetzt versucht das ganze so in einer Batch-Datei einzufügen oder per Eingabeaufforderung zu starten:
avs2pipemod -y4mp "avs-Bench.avs" | "C:\Program Files (x86)\x264\x264.exe" - --demuxer y4m --output "test.h264" --preset slow --tune film --vbv-bufsize 78125 --vbv-maxrate 62500 --profile high --level 4.1 --crf 20
bekomme nur die Meldung "failed to load avisynth.dll" und "x264[error] could not open input file '-'"...
Hola,
das was ich oben gespostet habe ist die Batch-Datei, daher alles auf Kommandozeile und das Ausgangsmaterial ist auch 1280x720. Ein Fehler ist dann, dass ich die VBV-Werte von den FHD-Einstellung übernommen habe. Das habe ich nun geändert.
Ich verwende LWL da FF bei mir Probleme gemacht hat, der hat dann gerne mittendrinn mit der Fehlermeldung "Invalid initial pts dts" abgebrochen, daher bin ich auf LWL umgestiegen. Bisher hat das auch immer gut funktioniert.
Das mit mkv ist leicht erklärt: Ich gebe die Schnittpunkte beim TSD an und rufe die Stapelabarbeitung dann per Batchdatei auf, in dieser wird die ts-Datei direkt via mkvmerge in mkv umverpackt. So kann ich diese auch vor dem Umrechnen noch mit den meisten Playern anschauen - ts geht auf meinem BD-Player z.B. nicht.
Wo liegt denn genau der Unterschied zwischen LWL uind FF?
Siehe hier:
http://forum.cypheros.de/index.php?topic=1170.0
vorher funktionierten die Vorschaubilder bei mir nicht...
Zudem ist die von Dir gezeigte die 2er-Version, ich habe noch die 1.2x,da ich noch keine neue Lizenzdatei bekommen habe
Also mir wurde damals hierzu geraten, um BD-Konforme Videso zu erstellen...
Die Einstellungen wurden aber auch nicht angetastet...
Hallo zusammen,
mir ist heute beim kodieren meiner Sat-Aufnahmen aufgefallen, dass das System sehr langsam geworden ist. Bei 1280x720 und 50fps gibt mir x264 per Kommandozeile bei einem File von nicht mal 15 Minuten länge eine Zeit von über zwei Stunden an. Das war vor ein paar Monaten noch deutlich anders. Da habe ich in einer Nacht locker 7-8 Dokus wandeln können, jetzt nicht mal die Hälfte. Ich habe bewusst an der Konfiguration meines Rechners kaum etwas geändert, lediglich die GK wurde von AMD auf NVidia geändert. Gestern hab ich zudem die 32Bit-Variante von ffdshow installiert, da der TSDoctor diese verlangte. Die hab ich heute aber wieder deinstalliert, aber daran hat es nicht gelegen. 2 Stunden für nicht mal 15 Minuten Material bei einem i5 2500K mit 4 Kernen und 4,2GHz beim reinen runterrechnen (keine Filter oder so) finde ich dann schon arg langsam.
Als Einstellungen für den Codec benutze ich folgendes:
"C:\Program Files (x86)\x264\x264.exe" "avs.avs" --output "%%~ni.h264" --preset slow --tune film --vbv-bufsize 78125 --vbv-maxrate 62500 --profile high --level 4.1 --crf 20
die avs-Datei schaut so aus:
LoadPlugin("C:\Program Files (x86)\StaxRip\Applications\AviSynth plugins\LSmash\LSMASHSource.dll")
LWLibavVideoSource("Quellvideo.mkv")
ConvertToYV12()
Laut Taskmanager liegt der CPU-Anteil vom Codec bei 99%, es scheint also auch kein anderer Prozess Leistung zu nehmen.
Ist jemanden von euch schon einmal das Phänomen begegnet?
Besten dank
Lapje
Ich will nicht das Seitenverhältnis manuell einstellen, ich war nur irritiert dass es sich jetzt doch noch ändert und ich etwas verunsichert war, welches das "richtige" ist. Und daher dachte ich dass es am Croppen liegen könnte. Mehr nicht...
Ich hab eher den Gedanken gehabt, dass durch das Croppen das Seitenverhältnis aufgrund der fehlenden Pixel ein anderes ist und VLC dies deswegen bei manueller Wahl von 4:3 falsch darstellen könnte (also nicht auf "Standard")...vielleicht greift er dann wirklich auf DAR zurück...
Also ist davon auszugehen dass beim Umschalten auf das 4:3-Seitenverhältnis im VLC-Player diese dann nicht mehr stimmt?
Ich muss doch nmoch mal nachhaken: Kann es sein dass es beim Croppen Probleme mit dem Seitenverhältnis geben kann? Nachdem ich das gemacht habe, habe ich wieder Probleme mit dem Seitenverhältnis. Eigentlich sollte das kodierte Video das gleiche Seitenverhältnis haben wie das Original, hat es aber nicht.
Oder gibt es beim Croppen wieder etwas zu beachten?
Dann weiß ich ja jetzt wie ich das zu machen habe. Mit dem "älter" meinte ich eigentlich meinen BD-Player...^^ Aber ich werde die Switches mal probieren, vielleicht bringt es ja etwas...
Besten dank schon mal für die ganze Hilfe....^^
Lapje
Ja, mein Player kann mit mkv-Files umgehen, es sollte nur mkvmerge bis Version 5.8.0 verwendet werden, ansonsten gibt es Probleme mit dem Vorspulen (ist halt schon etwas älter, finde aber keinen für mich besseren). Daher war ich ja so irritiert, da bei meinen HD-Kodierungen (hauptsächlich Sat-Aufnahmen) dieses Problem nie auftrat. Da hab ich einfach das SAR beim Kodieren auf 1:1 gestellt und bei mkvmerge die Pixelmaße eingegeben. Das lief alles wunderbar...
Ich hab aber auch noch mal ein wenig rumprobiert...
Wenn ich bei mkvmerge nichts eintrage, erhalte ich das richtige Seitenverhältnis, ebenso wenn ich die Pixel mit 768 x 576 angebe. Ich weiß jetzt nur nicht, was "sauberer" wäre, obwohl ein Video mit ursprünglich 720 Pixel beim muxen mit 768 Pixel anzugeben für mich eher wie Flickschusterei erscheint.
Das würde bedeuten? Beim Muxen gar nichts angeben? Oder die Auflösungsmaße?
Ich wollte mein Post gerade noch ergänzen, da ich vergessen habe anzugeben, was ich schon probiert habe: So haben weder die angegebenen 12:11 noch 16:15, von denen ich gelesen habe, etwas gebracht...
Wenn ich das kodierte Video dann am Rechner schaue ist es nach wie vor in die Höhe gezogen (oder an den Seiten gestaucht, je nach dem wie man es sieht)...erst wenn ich das Seitenverhältnis manuell auf 4:3 festlege geht das ganze mehr in die Breite..das Original-Video wird direkt richtig angezeigt...
Was mir gerade nur aufgefallen ist: Kodiere ich das Video mit 12:11 und schaue mir nur das h264-File an, wird das anscheinend richtig angezeigt, womit der Fehler vielleicht beim Muxen liegen könnte. Bei mkvmerge gebe ich das ganze so an:
--display-dimensions "0:704x576"
aber auch ein festes Seitenverhältnis hat nichts gebracht. Ich kann aber nicht ausprobieren, wie es sich mit dem h264-File am TV verhalten würde, da mein Player diesen alleine nicht abspielt..
Hallo zusammen,
ich klopfe hier mal wegen dem leidigen Thema Seitenverhältnis von DVD-Videos an. Ich habe hier ein Video im 4:3-Seitenverhältnis liegen, dass ich einfach nicht vernünftig umgewandelt bekomme - immer wieder ist das wieder leicht in die Höhe gezogen. Dabei ist es egal, ob ich beim muxen die Maße des Videos angebe oder das Seitenverhältnis. Auch die Ratio-Einstellungen am TV haben nicht das gewünschte Ergebnis gebracht.
Aktuell sieht meine Kommandozeile so aus:
"C:\Program Files (x86)\x264\x264.exe" "avs.avs" --output "%%~ni.h264" --preset slow --tune film --profile high --level 4.1 --crf %crf% --sar 1:1
aus. Ich habe heute auch versucht mich in die Problematik einzulesen, aber desto mehr Informationen ich gefunden habe, desto konfuser wurde es für mich (runde Pixel, quadratische Pixel, SAR, PAR usw...). Auch mit den SAR-Werten habe ich etwas rumprobiert, was aber ebenfalls nicht den gewünschten Erfolg gebracht hat.
MediaInfo sagt über das Quellvideo folgendes:
Video
ID : 224 (0xE0)
Format : MPEG Video
Format-Version : Version 2
Format-Profil : Main@Main
Format-Einstellungen für BVOP : Ja
Format-Einstellungen für Matrix : ausgewählt
Format_Settings_GOP : M=3, N=15
Dauer : 28min
Bitraten-Modus : variabel
Bitrate : 3 613 Kbps
maximale Bitrate : 7 500 Kbps
Breite : 720 Pixel
Höhe : 576 Pixel
Bildseitenverhältnis : 4:3
Bildwiederholungsrate : 25,000 FPS
Standard : PAL
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Scantyp : Interlaced
Scanreihenfolge : oberes Feld zuerst
Bits/(Pixel*Frame) : 0.348
Stream-Größe : 615 MiB (85%)
Beim kodierten Video bekomme ich ein Seitenverhältnis von 1,222 angegeben. Ich denke mal die 16 Pixel, welche ich in die Breite Croppe, sollten nicht dafür verantwortlich sein. Ich deinterlace das Video zudem noch, falls das wichtig zu wissen ist.
Vielleicht hat jemand ja noch eine Idee, was ich machen kann.
Besten dank
Lapje
Hallo zusammen,
ich bin hier gerade auf ein recht seltsames Phänomen gestoßen. Ich wollte bei einem mkv-File noch eine Tonspur hinzufügen und habe das ganze daher mit mkcextract in die einzelnen Streams aufgeteilt um diese später mit mkv Merge wieder zusammen zu fügen (ich weiß, könnte das auch direkt mit mkvmerge machen, das ganze soll aber für mehrere Files über eine Batch-Datei laufen).
Seltsamerweise ist die DTS-Spur danach zwei Minuten länger und somit nicht mehr synchron. Ich habe das Gefühl, dass die Spur nach dem demuxen eine andere Framerate besitzt. Das eigentliche mkv-File wie der extrahierte Videostream hat laut mediainfo eine Framerate von 25 Bildern. Aber der Unterschied von den 48 Minuten zu den neuen 50 Minuten ist vom Verhältnis her genau der zwischen 24 und 25 Bildern/Sekunde.
Hätte jemand eine Idee wie ich das genau überprüfen könnte? Und die Frage zudem: Warum wurde der Audio-Stream im alten mkv richtig abgespielt?
Besten dank
Lapje
So, habe die neue Version einige Zeit in Verwendung....aber kann es sein, dass LameXP zumindest bei der Kodierung von mp3s via Lame deutlich langsamer geworden ist? Ich brauche nun für ein knapp einstündiges File (knapp über 600MB) 6 Minuten (AMD 5050e, 320Kbit, empfohlene Qualität)...das ging vorher bei gleichen Bedingungen deutlich schneller...
Nachtrag: Habe gerade mal mehrere Files kopiert: für rund 3,54 GB hat LameXP knapp über 30 Minuten gebraucht. Ich habe mit der vorigen Version damals einen Vergleichstest zwischen Meinem System, meinem Netbook (AMD E350) und meinem Win8-Tablet (Atom Z3735F) gemacht. Alle haben für 1,7 GB knapp über 5 Minuten gebraucht. Wenn man das also angleicht braucht LameXP rund drei Mal soviel für die gleiche Menge (15 Minuten)...
Ich würde das gerne mit einer der älteren Versionen gegentesten, blicke bei GitHub aber nicht so wirklich durch. Gibt es eine Möglichkeit an eine ältere Version zu kommen?
Nachtrag 2:
So, könnte den Unterschied gefunden haben: Kodierung in 320Kbit bei einem 600MB-Wav-File: 6 Minuten, bei V2 2 Minuten...kann mich nicht erinnern das der Unterschied da so groß war...
Kurz eine Rückmeldung. Vielleicht haben sich einige Nutzer bei Avira gemeldet, auf jedenfall tritt das Problem nach dem heutigen Update nicht mehr auf, LameXP startet ganz normal und Files werden ohen "Zwischenfälle" kodiert...yipiiieehhh...^^
was der auslöser ist ist mir bekannt, auch das es sicherlich keine Malware ist. Darum geht es nicht. Das kommt nicht selten vor und normalerweise reicht es dann die entsprechende Datei in die Ausnahmen zu setzen. Das ist hier nicht möglich, da benannte Datei im Temp-Ordner des Benutzer-Verzeichnises abgelegt wird, dort widerum in einem eigenen Ordner, dessen Namen sich ständig ändert. Somit kann ich die Datei zumindest bei Avira Antivir nicht in die Ausnahmen setzen, da hierfür immer der gleiche Pfad von Nöten ist. Vielleicht könnte die Datei wo anders im immer gleichen Pfad abgespeichert werden. Antivir zu deaktivieren nur um mit LameXP zu arbeiten kann ja auch keine Lösung sein. Ich meine mich auch zu erinnern, dass man bei Avira Dateien einreichen kann, die dann überprüft und ausgenommen werden. Mich wundern halt zudem nur, dass ich vorhin mit der alten LameXP-Version das Problem nicht hatte...
Hallo MuldeR,
leider gibt es bei mir mit dem letzten Update Probleme: Habe heute aktualisiert und bei jedem Start meckert Avira AntiVir, dass die "lxp_sox.exe" zum "unerwünschten Programm TR/Crypt.ZPACK.140480" gehört. Ich denke mal nicht dass es sich dabei um einen Virus handelt, ich kann die Datei aber nicht in die Ausnahme setzen, da das Verzeichnis im Temp-Ordner immer einen anderen Namen trägt.
Hast Du eine Idee dazu?
OK...soweit jetzt klar...hoffe ich...
dann hätte ich aber einfach noch eine Frage zunm Verständnis: Was wäre wenn ich ein 1080i-Video mit TGMC deinterlacen würde? Bei Original-Einstellungen habe ich dann ja, wenn ich das richtig in Erinnerung habe, eine doppelte Framerate, also aus 50 Halbbildern werden 50 Vollbilder...Wie verhält es sich da? Level 4.1 würde da doch nicht mehr ausreichen, oder?
Oder habe ich da auch was falsch verstanden? 
