StaxRip Encoding-Frontend (Diskussion)

Möglich aber sehr unwahrscheinlich,... da ist es schon wahrscheinlicher, dass ein Virenscanner oder ne personnal Firewall für so etwas verantwortlich ist.

Zitat

(Prozessor ist sogar auf 4,0 GHz übertaktet und nach Stundenlangem benchmarktest nicht wärmer als 50 Grad

-> Würde die Kiste mal runtertakten (nur weil sie keine Hitze Probleme bei der CPU hat kann es trotzdem am Übertakten liegen)
Auch wenn man 99.99% sicher ist, dass es daran ja eigentlich nicht liegen könnte, sollte man ruhig mal runtertakten um sicher zu sein. (wenn es doch daran liegt und man Stunden nach der Fehlersuche verschwendet hat wäre es schon ärgerlich die 10min nicht geopfert zu haben)

Wie sieht den das verwendete AvisynthSkript aus?

Cu Selur

gut, läuft nun auf normaltakt, immernoch so langsam
aktuell habe ich gar nicht zB am AvisynthSkript geändert, nur staxrip neu geladen und entpackt alles einstellungen auf standard

Zitat

aktuell habe ich gar nicht zB am AvisynthSkript geändert, nur staxrip neu geladen und entpackt alles einstellungen auf standard

d.h. dann da steht was drinnen? So als nicht StaxRip-Nutzer sagt mir das Du nichts geändert hat leider gar nichts.

Der Übersicht wegen habe ich das ganze Problem noch einmal zusammengefasst und meinen text überarbeitet und in einen Post gepackt!

-----------------------------------------------------------------------------------------------------------------------------------

Also, ich benutze aktuell die neueste Version von Staxrip (1.1.8.0) und habe das Problem, dass meine Encodes einmal ganz normal ablaufen (von der Encodinggeschwindigkeit her gesehen) und mehrheitlich total langsam,
selbst wenn die Presets und sogar die Ausgangsadatein die selben sind!
(habe schon viel herumprobiert, auch neu aufsetzen brauchte keine Lösung, selbst wenn bis auf Staxrip und die benötigten Programme
(ffdshow, AVISynth, Xvid, MatroskaSplitter, CoreAVC) am PC nichts drauf, wirklich gar nichts, neu aufgesetzt mit nur den 5 Programmen installiert und Staxrip, kommt der Fehler vor)

Ab besten liefer ich dazu mal ein Bild, das jeder weiß wovon ich nun eigentlich spreche

[Blockierte Grafik: http://i.imagebanana.com/img/2u00bkft/PC.PNG]

sprich der Encodingvorgang ist unglaublich langsam (an der Hardware kann das nicht liegen, ich habe einen i7-2600k Prozessor, der dabei nichtmal zu 50% ausgelastet ist!)
das komische ist ja, dass wenn ich den PC neu starte, dann kann ich manchmal ein Video mit voller Geschwindigkeit encoden (40 fps+) meist, wenn das der Fall ist, wird das ganze erst beim 2.Video so langsam
was auch noch hilft ist meistens den Job abbrechen, neugestartet, war wieder so langsam, wieder abgebrochen, wieder neu gestartet (den Job, nicht den PC) und dann fängt es meist mit voller Geschwindigkeit an
(mit 40 oder mehr fps, davor sind es max. 1-2 fps)

Ich hoffe ich konnte einmal halbwegs mein Problem beschreiben, sodass es mal jeder versteht und schonmal danke für eure Hilfe, hat denn jemand eine Idee woran das liegen könnte?
(das es mit irgendwas von meinem PC zusammenhängt ist mir irgendwie klar, da anscheinend sonst niemand im Internet ein derartiges Problem hat, jedoch fällt mir keine Ursache ein, die soetwas auslösen könnte)

------------------------------------------------------------------------

Also zu heiß sollte der PC auf keinen Fall sein (hat nun guten CPU Lüfter, Synce Mugen 3)

Was auch komisch ist, es hilft meistens sogar wenn ich den Encodingvorgang abbreche (wenn es so langsam beginnt) und einfach neu starte und schon ist es so schnell wie sie sein soll,
zB habe ich (Bild siehe oben) den Encode abgebrochen neugestartet und dann sieht es so aus:

[Blockierte Grafik: http://i.imagebanana.com/img/n97whxa4/PC2.PNG]

Werde mir mal das mit der Taktfrequenz ansehen wie du gesagt hast wobei das eigentlich nicht sein dürfte (Prozessor ist sogar auf 4,0 GHz übertaktet und nach Stundenlangem Benchmarktest nicht wärmer als 50 Grad)
Ok, daran liegt es auch nicht, selbst wenn der Encode nur so langsam ist, taktet sich der Prozessor nicht runter sondern läuft auf 4,0 Ghz

Das mit den 40-50% Auslastung ist wenn eben sagen wir mit 2fps encoded wird

[Blockierte Grafik: http://i.imagebanana.com/img/ycg5atjs/CPUvieleFPS.PNG] im 1.Durchgang

Wenn zb mit 40 fps encoded wirs ist der Prozessor im 1.Durchgang wie im linken Bild ausgelastet
und dann zu 100% ausgelastet im 2.Durchgang (bei 2pass)
Wenn der erste Durchgang so langsam ist, ist der Prozessor auch im 2.Durchlauf so wie im rechten Bild ausgelastet, also um die 50%

RAM sind 8GB vorhanden, Festplatte ist eine SSD, also daran sollte es auch nicht liegen
Zu 100% bewusst lässt sich das auch nicht reproduzieren, meistens ist es halt langsam und selten ist ein Video einmal schnell encoded!

-------------------------------------------------------------

Muss der Vermutung mit dem CPU Takt nochmals nachgehen, habe gerade gemerkt, dass ich falsche Werte abgelesen habe
Habe nämlich zum auslesen AIDA 64 genommen statt CPU-Z
Draufgekommen bin ich erst weil ich im BIOS heute ausgeschalten habe, dass sie die CPU auf 1,6 GHz im Idle runtertakten soll und AIDA64 immer noch 1,6 GHz anzeigt, CPU-Z aber richtigerweise 3,4 GHz !

Ok, also am Takt der CPU/Temperatur liegt es nicht!
siehe:

[Blockierte Grafik: http://i.imagebanana.com/img/7deknulq/takt.PNG]

Nachdem das so langsam anfing, habe ich den Job abgebrochen, neugestartet, wieder so langsam, wieder abgebrochen, wieder neu gestartet (den Job, nicht den PC) und plötzlich sieht es dann so aus:

[Blockierte Grafik: http://i.imagebanana.com/img/v5uzm6vx/2.PNG]

Zu der Frage von vorhin, das AVISynth Skript ist ganz leer, wenn ich das über das Staxrip Menü öffne kommt das:

[Blockierte Grafik: http://i.imagebanana.com/img/le2zbfxz/svi.png][Blockierte Grafik: http://i.imagebanana.com/img/a57qek7h/AVISYNTH.PNG]

Bin nur schon ziemlich am verzweifeln, da sich anscheinend nichtmal wer hier das erklären kann

Habe gerade etwas bemerkt, das Problem tritt anscheinend nur auf, wenn als Zielformat ein x264 Format eingestellt ist (zB der MKV Container)
Ich habe gerade ein paar Aufnahmen (1080i HD) nach Xvid (im AVI Container) umgewandelt, da gings immer mit vollem Tempo!
Danach direkt im Anschluss die selbe Datei nach x264 (im MKV Container) wieder langsam!

Anscheinend bin ich damit doch nicht ganz alleine:
http://forum.doom9.org/archive/index.php/t-164432.html

Die haben das selbe vor wie ich!
Ich nutze auch VideoReDo, allerdings tritt das Problem auch bei ungeschnittenen Datein auf, also vor Videoredo!

Habe nun endlich feststellen können, was genau das Problem ist!
Es tritt nur auf, wenn ich egal was nach x264 encode (Container ist egal) und einen Deinterlacer verwende!
Habe gerade erst gesehen, dass ich bis jetzt nicht geschrieben habe, was ich für ein Preset nehme!
Also, 1080i Aufnahme nach MKV mit x264 Codec encoden keine Problem, mit Resize auch kein Problem (habe das glaub ich 100 mal ausprobiert, immer voller Speed!)
Sobald ich einen Deinterlacer dazunehme (YADIF) ist es meistens extrem langsam!
Manchmal aber eben auch nicht und genau das verstehe ich nicht, wie kann es denn einmal mit 40+ fps laufen trotz deinterlacer und einmal mit nur 2 fps?
Da aber die ganzen Sender in 1080i senden (SKY, HD+ usw.) muss ich das doch immer deinterlacen oder etwa nicht?

also, hat irgendwer einen vorschlag wie ich das problem lösen kann, bzw kann mir einen anderen guten deinterlacer zum testen empfehlen, ob dieses problem dann nicht mehr auftritt? danke

Eventuell liegt es dann daran, dass dein RAM sehr voll ist, dann muss AviSynth andauernd auf die Festplate auslagern.

danke für die antwort,daran liegt es auch nicht!
während dem encode sind meist 5,5 GB RAM frei!

kannst du mir vllt einen anderen "guten" deinterlacer zum testen empfehlen?

ich vermute mal dir ist es genauso unbegreiflich wie mir, das ein deinterlacer soetwas auslösen kann?

----------------

ich konnte das problem lösen, jedoch ist die lösung nicht gerade zufriedenstellend!
und zwar wenn ich den deinterlacer in der filterreihenfolge ganz an de schluss setzte!
jedoch leidet dadurch logischerweise die qualität enorm darunter!
damit habe ich volle geschwindigkeit, aber schlechte qualität!

vorher: [Blockierte Grafik: http://i.imagebanana.com/img/owh5u0no/bisher.PNG] jetzt: [Blockierte Grafik: http://i.imagebanana.com/img/7p8y9dqq/nun.PNG]

also ohne den Zufall wäre ich auf das wohl nie gekommen!
versteh zwar nicht wie diese kleine Änderung der Reihenfolge solch große Auswirkungen haben kann

hab noch eine letzte Frage, bringt es eigentlich etwas (und wenn ja was?) anstelle der in staxrip integrierten versionen von AVISynth (2.5.0) die 2.6.0 a3 zu nehmen?
oder statt xvid 1.2.2 das neueste xvid 1.3.2? danke

frage, kann es sein, dass Staxrip einfach nicht wirklich auf mehrere Kerne gut angepasst ist?
ich hab jetzt mal im BIOS von meinen 4 kernen 2 abgeschaltet, plötzlich startet der encode jedes mal schnell!
was habt ihr denn für prozessoren?

StaxRip ist eine Benutzeroberfläche. Die benutzt kaum ein Promille der Rechenzeit. Wenn da etwas den Prozessor nutzt, dann sind es AviSynth beim Filtern oder x264 beim Encodieren. x264 skaliert ganz hervorragend. AviSynth nur, wenn man mit SetMTMode gut umgehen kann.

Wenn es mal läuft und mal nicht, dann würde ich mir allerdings zuerst Sorgen um die Hardware machen. Deine bisherigen Beschreibungen weisen für mich noch nicht klar auf eine spezielle Ursache hin. Oder ich übersehe was.

Naja, wo es nicht geht, deinterlacet YADIF HDTV. Und wo es geht, nur SDTV. Liegt es vielleicht daran?

gruß

akapuma

stimmt ja, sry, wenn ich staxrip sag mein ich eigentlich eh immer die ganzen "unterprogramme"
das komische ist ja, das dieser (mittlerweile sag ichs) scheiß nur auftritt, wenn yadif aktiv ist, deshlab zweifel ich an der hardware theorie irgendwie ... (und auch so zB BF3 oder so, nie probleme)
außerdem mit was sollte ich denn zum testen anfangen? (was sind denn für euch die logischsten dinge bzw defekte hardware die sowas auslösen könnten?)
am ehesten prozessor oder?

Heutige Spiele beschäftigen überwiegend die Grafikkarte, aber weniger den Prozessor. Die Encodierung mit x264 dagegen heizt ihm richtig ein.

Ich erinnere mich schwach an den x264-Benchmark und die Diskussion mit Didée um die Empfehlung, den Turbo-Modus zu aktivieren oder zu deaktivieren, zwecks Vergleichbarkeit der Ergebnisse. Vielleicht hat der auch seinen Einfluss, ich kenne da die intel-Core-CPUs nicht so genau.

Das wichtigste hab ich tatsächlich übersehen:

Auf keinen Fall darf der Deinterlacer nach dem Resize kommen! Wenn die Höhe gestaucht wurde, und das Video war im Original tatsächlich interlaced, dann ist der Inhalt mit Matschbalken versaut. Ein Deinterlacer arbeitet nur mit ungefiltertem Video korrekt. Und wenn er dann langsam arbeitet, dann hat er wohl ordentlich zu tun. Hoffen wir nur, dass er dann auch was sinnvolles tut.

Mein Hauptproblem mit StaxRip ist, dass ich selber nur relativ gutes Grundlagenwissen zu Videobearbeitung und AviSynth habe, aber so gut wie keine Erfahrung damit, wie StaxRip das vor seinem Nutzer verbirgt. In dem Moment, wo StaxRip einen Job startet, muss aber ein AviSynth-Skript existieren, denn das wird ja von x264 als Videoquelle verwendet. In der Log-Datei sollte nachzulesen sein, wo das liegt. Diesen Programmaufruf kann man genauso gut auch ohne die StaxRip-GUI ausführen, z.B. als Batch-Datei in einem Konsolenfenster (StaxRip tut so etwas ähnliches ja selber auch, versteckt es nur gut).

Was die Version angeht: Die Multi-Threading-Variante von Version 2.6.0a3 ist heute wohl die aktuelle und empfohlene. Und es sollte StaxRip eigentlich relativ egal sein, ob eine 2.5.8 oder 2.6.0 gerade installiert ist.

hi, das mit dem deinterlacer hab ich selbst schon rausgefunden, nachdem die videoualität danach wirklich mies war (wie du sagst!)
das mit dem deinterlacer verstehe ich nur nicht, denn der tut meiner meinung nach zu wenig!
denn wie kann es denn sonst sein, dass wenn ich das selbe video zwimal hintereinander mit den selben einstellungen encode, dass das erste mal mit deinterlacer 40 fps rausschauen, am nächsten tag aber nur mehr 1,5 fps ...

wegen dem prozessor, ich habe sppedstep (also den turbo) sowie hyperthreating und alles schon ausgeschaltet, auf standardtakt runtergeschraubt usw.
brachte alles keine besserung! mich nervt es nur extrem nicht mal zu wissen, wieso das ganze so langsam ist!

Dann reden wir vielleicht an einer bedeutenden Stelle aneinander vorbei: Was das "erste Mal" und das "zweite Mal" angeht.

Encodierst du im 2-pass-Verfahren? Vergleichst du die beiden Durchläufe, die von einander abhängen?

Ja, selbstverständlich ist der erste von den beiden Durchläufen im 2-pass-Modus viel schneller als der zweite! Das wäre ganz normal. Der erste sammelt nur Statistikdaten. Dazu muss x264 gar nicht die komplette Encodierung berechnen.

Im Moment bin ich mir nicht sicher, ob du dieses Detail selber nicht erwähnt hast, oder ob meine eigene Konzentrationsfähigkeit schon so nachgelassen hat, dass ich es in der Länge deiner Beiträge einfach übersehen habe... :redface: — Leider schreibst du zwar viel, aber von den relevanten Fakten entweder zu wenig oder zu unauffällig. Für mich.

So fehlt beispielsweise auch die detailierte Angabe, welche Optionen für den x264-Encoder du gewählt hast. Solltest du der Meinung sein, dass das "placebo"-Preset eine gute Idee sei, dann wundern mich solche Differenzen zwischen erstem und zweitem Durchlauf gar nicht. Eher, warum die CPU-Auslastung in beiden Fällen so mäßig sei.

Wenn es aber um zwei ansonsten gleichwertige Durchläufe und Optionsmengen geht, dann wäre die Ursache auch technisch völlig anders geartet.

ich encodiere je nach serie und qualitätsanspruch in 2 pass oder CRF, bis jetzt konnte ich mein problem nur im 2 pass verfahren feststelle
was ich mit zweitem mal meine war beides, einmal das einmal das, sprich

in meinem letzten post sprach ich über 2 pass (1. durchgang schnell, 2.druchgang schnell) erst das weite video das in zweipass encoded wurde war dann schon im 1. durchlauf so langsam!
das der zweite druchgang langsamer ist weiß ich (reduktion von ca. 40 auf 30 fps)
jedoch wurde wie gesagt das 2. video dann nur mehr mit 2 fps im 1. und zweiten druchgang encoded!

relevaten fakten, puh, was soll ich noch sagen? mir fällt eigentlich nichts mehr ein, was nicht schon geschrieben wäre, kannst mich auch gerne noch was fragen

Das sicherste ist immer, wenn ein Programm eine Log-Datei erstellt. Darin ist z.B. die komplette Kommandozeile mit allen Parametern für x264 zu finden. Dass mir mindestens das (Speed-) Preset fehlt – ultrafast oder slower oder placebo? – hatte ich bereits erwähnt.

achso, ist SLOW

Das ist ein vollständiges StaxRip-Log?

wenn du mir sagen kannst, wo der gespeichert wird, gerne
oder meinst du den in den temp daten der jeweiligen datei?

hier mal der log aus den temp daten
(habe die datei abgebrochen da es mit nur 1,5 fps begann)

------------------------------------------------------------
                        Environment
------------------------------------------------------------


StaxRip version: 1.1.8.0
OS Name        : Windows 7 Home Premium
OS Version     : 6.1.7601.65536
OS Type        : 64-bit
OS Culture     : German


------------------------------------------------------------
                            .NET
------------------------------------------------------------


v2.0.50727      : 2.0.50727.5420
v2.0.50727\1031 : 2.0.50727.5420
v3.0            : 3.0.30729.5420
v3.5            : 3.5.30729.5420
v3.5\1031       : 3.5.30729.5420
v4\Client       : 4.0.30319
v4\Client\1031  : 4.0.30319


------------------------------------------------------------
                   Source file MediaInfo
------------------------------------------------------------


I:\Testfile.ts


General
ID                                       : 1 (0x1)
Complete name                            : I:\Testfile.ts
Format                                   : MPEG-TS
File size                                : 1.47 GiB
Duration                                 : 21mn 30s
Overall bit rate                         : 9 753 Kbps


Video
ID                                       : 1023 (0x3FF)
Menu ID                                  : 1 (0x1)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.0
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 3 frames
Codec ID                                 : 27
Duration                                 : 21mn 30s
Bit rate                                 : 8 884 Kbps
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 25.000 fps
Standard                                 : Component
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Interlaced
Scan order                               : Top Field First
Bits/(Pixel*Frame)                       : 0.171
Stream size                              : 1.33 GiB (91%)
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709


Audio
ID                                       : 1027 (0x403)
Menu ID                                  : 1 (0x1)
Format                                   : AC-3
Format/Info                              : Audio Coding 3
Mode extension                           : CM (complete main)
Format settings, Endianness              : Big
Codec ID                                 : 6
Duration                                 : 21mn 30s
Bit rate mode                            : Constant
Bit rate                                 : 384 Kbps
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 48.0 KHz
Bit depth                                : 16 bits
Compression mode                         : Lossy
Delay relative to video                  : -40ms
Stream size                              : 59.1 MiB (4%)
Language                                 : German


Text
ID                                       : 32 (0x20)-100
Menu ID                                  : 1 (0x1)
Format                                   : Teletext
Language                                 : German




------------------------------------------------------------
        DirectShow filters used to render the source
------------------------------------------------------------


DirectSound Audio Renderer
Video Mixing Renderer
ffdshow Audio Decoder
ffdshow Video Decoder
Haali Media Splitter


------------------------------------------------------------
                       Source Macros
------------------------------------------------------------


Source Directory:   I:\Testfile\
Source Directory Name:
Source Directory Parent: I:\Testfile\
Source File Path:   I:\Testfile.ts
Source Files Blank: "I:\Testfile.ts"
Source Files Comma: "I:\Testfile.ts"
Source Framerate:   25.00
Source Framerate MediaInfo: 25.000
Source Frames:      32259
Source Image Height: 1080
Source File Name:   Testfile
Source Seconds:     1290
Source Image Width: 1920


------------------------------------------------------------
                      AviSynth Filters
------------------------------------------------------------


DirectShowSource("I:\Testfile.ts", audio=false, convertfps=true, fps=25)
Crop(0,0, -Width % 8,-Height % 8)
ConvertToYV12()
Yadif()
Spline64Resize(1280,720)


------------------------------------------------------------
                            x264
------------------------------------------------------------


"C:\Users\Tester\Desktop\StaxRip_1.1.8.0\Applications\x264\x264.exe" --preset slow --tune film --pass 1 --bitrate 4549 --stats "D:\StaxRip Temp\Testfile temp files\Testfile.stats" --output NUL "D:\StaxRip Temp\Testfile temp files\Testfile.avs"


avs [info]: 1280x720p 0:0 @ 25/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
x264 [info]: profile Main, level 3.1




Start:    03:03:57
End:      03:04:35
Duration: 00:00:38

Wieder einer, der Transport-Streams mit DirectShowSource lädt. Wie oft haben wir in den letzten Monaten immer wieder erklärt, was stattdessen zu empfehlen wäre: Remultiplexen nach MKV und öffnen mit FFmpegSource2.