Staxrip crasht bei HD-Vorschau

Lowlander

Hallo zusammen,

ich versuche gerade, HD-Aufnahmen meines DVBviewer pro in StaxRip zu verarbeiten. Ich habe zwei Wege gefunden, das TS-File zu laden: Entweder das komplette TS als Quelle mit DirectShowSource als Inputfilter und ein vorher demuxtes .ac3 als Tonspur, oder ein vorher demuxtes .264 als Quelle mit AVCsource als Inputfilter und dem gleichen demuxten .ac3 als Ton.

In der ersten Variante wird das Preview-Fenster beim Scrollen oder frameweisen Springen nur unzuverlässig, meistens aber garnicht upgedatet, was ein Schneiden unmöglich macht. Das Bild bleibt beim Scrollen/Springen einfach stehen.

In der zweiten Variante crasht mir beim Versuch, Schnittpunkte zu setzen, das Vorschaufenster so oft (Meldung CAVIStreamSynth: System exception - Access Violation...), dass es nicht möglich ist, in- UND out-Punkt auf einmal zu setzen. Nach schließen und wieder öffnen des Preview-Fensters ist das Bild wieder da, aber der gerade im x-ten Versuch gesetzte in-Punkt ist futsch.

Hatte dieses Problem schonmal jemand, der mir einen Tipp geben könnte, wo ich da drehen könnte?

Schönen Tach noch,
Low

BeoBiest

Moin,

nutze selber kein StaxRip. Für das evtl. Weiterverarbeiten von HD-Aufnahmen nutze ich in AviSynth: FFmpegSource2. Die Vorschau der als *.mkv vorliegende Quelle funktioniert bei mir zum Testen 1A in VirtualDub.

http://code.google.com/p/ffmpegsource/

Zitat

LoadCPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\FFMS2.dll")

FFVideoSource("d:\aaa.mkv")

Vlt. hilfts ...

Lowlander

Moin auch,

wenn ich in Staxrip FFVideoSource als Sourcefilter wähle (hatte ich noch nicht probiert), wird das TS-File wie auch mit DirectShowSource indiziert und geladen, aber die Vorschau crasht sofort bei der ersten Bewegung des Pointers. Es hat also schon was mit dem Decodieren der Quelle zu tun...

Grüße,
Low

BeoBiest

Hi,

und wenn du das Avisynth-Skript in VirtualDub lädst? Zeigt er es dann korrekt an? Bei mir funktioniert *.ts als Quelle z.B. nicht (fehlerhafte Blöcke). Muss es mit *.mkv füttern.

Aus dem FFmpegSource2 User Manual:

Zitat

Limitations
•Requires Haali's Media Splitter if you want to seek in OGM or MPEG PS/TS. Trying to do non-linear access in those containers without it will end in tears.
•Haali's splitter requires transport streams to be cut at packet boundaries. Use TsRemux to fix the stream before trying to open it.
•Because of LAVF's demuxer, most raw streams (such as elementary h264 and other mpeg video streams) will fail to work properly.
•FFAudioSource() will have to remake any index implicitly created by FFVideoSource() and therefore code like

Lowlander

Hi,

danke für das ernüchternde Zitat aus dem Manual! Wahrscheinlich hat da jeder Source Filter andere Inkompatibilitäten und Anforderungen an die Beschaffenheit des Quellmaterials. Schade nur, dass man deshalb (mit Staxrip) nicht framegenau schneiden kann, obwohl das Material komplett neu encodet wird. Ok, ich säubere dann mal die Streams mit TSdoctor oder TSremux, schneide vorne und hinten grob ab und bewahre die Aufnahmen für Zeiten auf, wo HDTV als Quelle etwas weiter Einzug in Standard-Tools gehalten hat.

-TiLT-

Wie hier schon erwähnt ist doch lediglich der Container ausschlaggebend.

Hab selbst lange mit DVBViewer aufgezeichnet und mit Staxrip weiterverarbeitet und selten große Probleme gehabt.

Also mit gdsmux nach MKV ummuxen und ffvideosource testen, das sollte klappen.

BeoBiest

Moinsen,

naja - machbar wäre es doch!

0.)TSDoctor (wenn verfügbar) zum Reparieren
1.)Eac3To zum Demuxen in *.264 und *.ac3
2.)mit mkvMerge daraus ein *.mkv zaubern
3.)das *.mkv mit "FFVideoSource()" in ein *.avs packen
--stürzt StaxRip dann immer noch ab:
4.)das Skript in VirtualDub laden (und sei es nur zum Testen ob: AviSynth, FFmpegSource2 oder StaxRip das Problem erzeugt) und im Zweifel
5.)die Schnittstellen/Frames aus VirtualDub mittels "Trim()" ins *.avs übertragen

Mal eine andere Frage: Gibt es einen guten Grund für die Neukodierung der HD-Aufnahmen? Evtl. hilft dies:

http://forum.gleitz.info/showthread.php…r-NALUs-etc.%29 oder:
http://forum.gleitz.info/showthread.php…ransport-Stream

Gruss

-TiLT-

Zu Punkt 1 und 2.

mkvmerge hat Schwierigkeiten mit 1080i Aufnahmen und nimmt bekanntlich keine .ts direkt als Input. GDSMux hat die Probleme nicht und sollte daher bevorzugt werden.

BeoBiest

Hi,

Zitat

mkvmerge hat Schwierigkeiten mit 1080i Aufnahmen

Ok - das wusste ich nicht, habe nur HD von den ÖR (720p50) zur Verfügung.

Bevorzuge trotzdem den Umweg über eac3to, zwecks Fehlererkennung des *.ts und Korrektur des erzeugten *ac3-Streams.

Gruss

-TiLT-

Ja, das hat natürlich auch seine Vorzüge. Und die AC3 lässt sich dann auch nochmal durch projectx jagen um die 2.0 Frames mit stillen 5.1 Frames ersetzen zu lassen.
Manche Audio Decoder (wie z.B. foobar2000 mit in_ac3.dll) haben sonst Probleme den Ton zu decodieren.

BeoBiest

Das ist natürlich auch ne Idee, die .ac3-Korrektur generell oder zusätzlich von ProjectX übernehmen zu lassen.

Kleiner Nachtrag zu 2.)mit mkvMerge daraus ein *.mkv zaubern
-bei meinen Quellen (720p50) und nach dem Demuxen mit eac3to muss man mkvmerge manuell die Framerate unter BPS mitteilen. mkvmerge setzt sonst 25 statt 50.

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

Sehe gerade: Badewanne führt Nordwind, fix untertauchen:

http://www.io-warnemuende.de/webcam.html
http://www.bsh.de/aktdat/bm/Warnemuende.htm

Lowlander

Hallo alle,

vielen Dank für die zahlreichen Tipps, werde mich am langen WE ans Probieren machen.

Zitat von BeoBiest

Gibt es einen guten Grund für die Neukodierung der HD-Aufnahmen?

Ja, mein Verbund aus DLNA-Server, Sony BD und Sony TV spielt die originalen HD-Aufnahmen vom DVBviewer nicht ab. Ich werde aber parallel zum Neucodieren mal das reine Umcontainern weiterverfolgen.

-TiLT-

Da hast du schon genug Testmöglichkeiten.

MKV, MP4, M2TS...

Würd ja fast vermuten, dass der BD mit M2TS zurechtkommt.

Jetzt mitmachen!