Ständig Resyncs beim grabben von PW-Direkt Kanälen

Hallo Gemeinde,

wenn ich von PW-Direkt grabbe, kriege ich entweder ständig Resyncs oder Bild und Ton sind nach kurzer Zeit asyncron. Probiert habe ich es mit: DBoxtimer2, Tuxvision, ngrab, WinGrabZ und 1.5er und 1.6er AlexW-Images. Rechnerseitg hab ich einen Atlon800@1000 mit 80GB HD an Raid am laufen. Geschwindigkeitsmäsig sollte das ausreichend sein, was man so liest.
Wenn ich normale (PW)Kanäle grabbe, gibt's keine Probleme.

Ist das ein generelles Problem bei Direct, oder hängt's an was anderem?
Kennt jemand 'ne Lösung?

Box ist: Nokia, 2xIntel, GTX

Hi ...

also ein P-Direkt Problem ist das nicht !
Denn mit meiner 1er dBox kann ich über SCSI ohne Probleme davon aufnehmen !
Mit der 2er habe ich aber auch verstärkt Resyncs ! Zumindest bei der einen Aufnahme die ich bis jetzt gemacht habe !

Gruß

Beitrag von **Gorcon** » Sonntag 15. September 2002, 23:05

Bei Direkt ist die Datenrate auch mit abstand am höchsten. Auf keinen fall sollte man mehrere Tonspuren gleichzeitig graben.
Gruß Gorcon

Gorcon hat geschrieben:Auf keinen fall sollte man mehrere Tonspuren gleichzeitig graben.

Das könnte es vielleicht sein. Werde am Wochenende nochmal das 1.6er flashen und es ausprobieren. Die Auswahl der Tonspuren geht imho nur bei WinGrabZ, oder kann ich das bei Dboxtimer2 auch irgendwo einstellen?

Hab's jetzt mal probiert Direct mit nur einer Audiospur aufzunehmen. Leider wieder Resyncs.

WingrabE gibt folgendes aus:

15:54:08.740 [Muxer] Resync successful
15:54:08.730 [Muxer] warning: audio (1) pts discontinuity detected [-86400 pts cycles]
15:54:08.730 [Muxer] warning: video dts discontinuity detected [-86400 dts cycles]
15:54:08.730 [Muxer] invalid video sequence: more than 1 picture with same temporal_reference found [sequence skipped, need resync]
15:54:02.671 [Muxer] Resync successful
15:54:02.661 [Muxer] warning: audio (1) pts discontinuity detected [-43200 pts cycles]
15:54:02.661 [Muxer] warning: video dts discontinuity detected [-43200 dts cycles]
15:54:02.651 [Muxer] invalid video sequence: temporal_reference > picture count in sequence [sequence skipped, need resync]
15:54:00.598 [Muxer] Resync successful
15:54:00.598 [Muxer] warning: audio (1) pts discontinuity detected [-43200 pts cycles]
15:54:00.588 [Muxer] warning: video dts discontinuity detected [-43200 dts cycles]
15:54:00.588 [Muxer] invalid video sequence: temporal_reference > picture count in sequence [sequence skipped, need resync]
15:54:00.588 [Muxer] Resync successful
15:54:00.578 [Muxer] warning: audio (1) pts discontinuity detected [-43200 pts cycles]
15:54:00.578 [Muxer] warning: video dts discontinuity detected [-43200 dts cycles]
15:54:00.568 [Muxer] invalid video sequence: temporal_reference > picture count in sequence [sequence skipped, need resync]
15:52:46.451 [Muxer] Resync successful
15:52:46.431 [AudioProcessor0] locked on stream id 192
15:52:44.288 [VideoProcessor] locked on stream id 224
15:52:44.068 [AudioHTTP0] HTTP streaming started successfully
15:52:44.058 [AudioHTTP0] started
15:52:44.058 [VideoHTTP] HTTP streaming started successfully
15:52:44.058 [VideoHTTP] started
15:52:44.058 [AudioPesParser0] started
15:52:44.058 [AudioProcessor0] started
15:52:44.058 [VideoPesParser] started
15:52:44.058 [VideoProcessor] started
15:52:44.058 [Muxer] started
15:52:44.058 [MuxWriter] started

Wenn ich die Meldung:
15:54:08.730 [Muxer] invalid video sequence: more than 1 picture with same temporal_reference found [sequence skipped, need resync]
richtig verstehe kommt der Videostream ins stocken. Auch grabben in zwei streams und anschließendes Muxxen bringt den selben Fehler.

Irgendwelche Ideen ???

Na ja, ich denke wenn das wirklich an den zu hohen Bitraten liegt, dann wird das so einfach (wenn überhaupt) nicht zu beheben sein !
Und die Direktfilme haben nunmal Bitraten(peaks) von 6 Mbit/s und noch mehr !

Gruß

@Gorcon
Wie nimmt man denn 2 Tonspuren gleichzeitig auf ?

Mit WingrabE und dann die Audio und Video PIDs aus der Streaminfo (blaue Taste) eintragen. Bei 3 Spuren ist die letzte Zahl nicht lesbar. Ist aber auf Direkt meistens ne 3.

Kann man denn mehrere AudioPID's angeben ?

Klar, sonst hätte ichs ja nicht empfohlen.

Hab' ich noch nie probiert, werde es aber gleich heute nachholen.
Und wehe Dir es klappt nicht.

Gruss
Astak

Wenn's nicht klappt, liegts an Deinem System. Ich hab' schon erfolgreich einen Film 3 Audiospuren gegrabbt. Allerdings nicht ohne resync.

@chkdesign
Kann das sein, das das nur mit WinGrabE und Enigma funktioniert ?

Nö. Bei mir gehts auch unter neutrino.

Also ich habe WingrabN 0.8 und alexw 1.6.
Ich kann zwar mehre Audio Streams anwählen (nicht aber die PID eingeben !!!), aber er nimmt immer nur einen Audio-Stream auf. Hab's aber nicht auf Direkt probiert, sondern auf P1, da mir das keine 3â‚¬ wert ist.

Gruss
Astak

Beitrag von **paoli** » Freitag 20. September 2002, 20:20

hab heute mal memento auf direkt2 gegrabt, nur ac3-ton, nur start-resynch (neutrino v.1.8., wingrabe 0.

.

paoli hat geschrieben: hab heute mal memento auf direkt2 gegrabt, nur ac3-ton, nur start-resynch (neutrino v.1.8., wingrabe 0..

OT: Ich weiß wirklich nicht warum man den Film auch noch konservieren sollte !

@all
Hat eigentlich auch noch jemand anders Fehler im Stream, selbst wenn es keinen Resync gegeben hat ? Also eigentlich alles OK sein sollte ?
Ich hatte das nämlich jetzt schon mehrfach ! Auch mit Neutrino v 1.8.

Gruß
BOP

Beitrag von **PeterB** » Samstag 21. September 2002, 10:33

Hallo,

also ich habe folgendes beobachtet bzgl. ReSyncs. Wenn kein Übertragungsfehler vorliegt, immer bedenken bei solchen hohen Daten reicht es schon wenn irgendwo im gleichen Stromnetz ein Verbraucher an- / ausgeschaltet wird, da sieht man evtl. keinen Fehler auf dem Fernseher, aber der Decoder (und somit die Übertragung) kommt für eine Zeiteinheit aus dem Takt (evtl. hört man einen Tonknackser) aber der Stream reißt eben ab und es kommt zum ReSync.

Sollte auf dem Rechner der den Stream grabbt nur eine NIC aktiviert sein, die HD defragmentiert oder am besten noch eben Quickformat behandelt sein. Zudem keine Freigaben auf die Capture HD machen oder überhaupt Freigaben von Ordnern etc., jenes löst immer einen Interrupt und ne Anfrage aus, ist der Rechner beim streamen eh schon am Limit kommt es zum ReSync. Alles was mit USB zu tun hat, deaktivieren beim grabben.
Und alles im Hintergrund (Programme die nicht gebraucht werden) beenden, ebenso Firewalls&AntiVirensoftware.

Dann sollte es mit dem grabben auch besser klappen.

@BirdOfPrey : Meinst du das jetzt so : es wird ein Filmstream aufgenommen und laut Programm ist alles okay, aber du hast Fehler wie MPEG Klötze im stream drinnen? Wenn ja, gibt es folgende Ursachen - zum einen Fehlerhafte übertragung auf die HD (sehr selten) oder zu scharfe Timesettings beim RAM bzw. zu heftig OC. Ja ja, viele machen es und haben keine Probleme, jenes sollte aber nicht als Aussage "Wenn es bei mir klappt, dann klappt es überall" verleiten

. Bestes Beispiel sind ASUS MainBoards mit gleicher CPU (Herstellungsdaten) und gleiches RAM. Der eine kann sein System OC bis zum Limit und hat keine Probleme und das andere System (alles gleiche Bauteile) macht das nicht mit.

Beitrag von **paoli** » Samstag 21. September 2002, 12:39

bei halbwegs normgerechter abschirmung und einem nicht gerade uralten oder verkorkst konfigurierten rechner braucht man sich keine gedanken um äußere einflüsse und verarbeitungsfehler des rechners zu machen. habe hier diverse computer, 2 2er und einer 1er dbox im netzt und viele verbraucher an der selben sicherung, da gibts in keiner konstellation von der seite probleme.
ganz wichtig ist eine sauber konfigurierte und ungestört arbeitende (firewall, anderer trafic im netz) verbindung zwischen box und rechner.
fehler im stream tauchen bei sauberer konfiguration des systems trozdem auf, wenn die datenrate zu hoch wird (nur bei 2er box, seit dem image vom 1.8. ist abgesehen von dem flaschenhals 10mbit-netzt kaum noch ein unterschied zwischen 1er und 2er box). ab und zu kommen auch fehler vom sender, dann haben alle ihn (siehe z.b. : http://www.visar.ch/voyager/forum.php?t_id=131).
auch kann der stream schon auf seinem weg von z.b. pw zur box irgendwo gestört werden, es kommt bei seriensammlern vor, daß mehrere, aber nicht alle leute den selben fehlern auch haben.
fehler müssen also nicht immer hausgemacht sein.
alle gängigen grab-programme überprüfen paket- und frame-header, wenn da was falsch ist, wird das gemeldet bzw. der resynch ausgeführt. es kann aber auch vorkommen, daß der fehler nur innerhalb eines frames bzw. pictures auftaucht, dann merken die recorder-progs nichts davon, ist aber selten.

paoli hat geschrieben:es kann aber auch vorkommen, daß der fehler nur innerhalb eines frames bzw. pictures auftaucht, dann merken die recorder-progs nichts davon, ist aber selten.

Ja, aber das kann es bei mir nicht sein ! Denn diese Fehler treten dann ja nicht alle 20 bis 30 Sekunden auf ! Ich bin mir auch nicht ganz sicher ob die Fehler im Stream überhaupt sichtbar sind ! Das müßte ich erst noch überprüfen ! Denn auf dem TV sind diese Fehler im Originalstream ja nicht zu sehen. Die machen sich nur durch ein kurzes stehen bleiben des Bildes bemerkbar. Ein neu muxen bringt auch keinen Erfolg. Das einzige was hilft ist ein neu encoden. Und da habe ich bis jetzt noch nicht (ausführlich) überprüft, ob wirklich sichtbare Fehler im Stream sind ! Aber ein kurzes Reinschauen sah so aus !

@PeterB
Der Rechner ist weder übertaktet, noch sind die Speichersettings zu scharf. Das hätte ich dann schon bemerkt. Allerdings war ziemlich viel Müll auf dem Rechner installiert.
Im übrigen muß man beim OCen, wenn man schon vergleicht, den selben Prozessor benutzen ! Ein Freund von mir hat sich jetzt auch, Übergangsweise, bis der 2400+ raus kommt, einen 1800+ geholt. Und erst den vierten den er ausprobiert hatte lief auch als 2100+ stabil ! Es ist also meistens die Serienstreuung der Prozessoren die ein OCen verhindern !

Gruß

Beitrag von **PeterB** » Samstag 21. September 2002, 16:37

Hatte doch extra geschrieben, es kann so etwas sein UND MUSS NICHT SEIN. Mensch liest denn heutzutage nur noch jeder Oberflächlich? So langsam nervt es. Alle Nase lang heulen die Leute rum xyz geht nicht, ich habe hier ein Problem und da auch noch. Okay, kein Thema, aber kaum jemand macht genaue Angaben über das System was er nutzt und wehe jemand stellt mal eine Vermutung (was ich noch nicht einmal gemacht habe) dann geht der Tanz los. Sowas nervt...

@PeterB
Was hast Du denn für ein Problem ??? Es hat doch überhaupt niemand Behauptet das Du Unrecht hättest oder sonst irgend etwas in der Art !? Deswegen verstehe ich Deine Reaktion jetzt überhaupt nicht !
Und ehrlich gesagt vertehe ich auch nicht so ganz worauf sich Deine Reaktion bezieht !?

Aber sicher ! Es wird viel rumgestöhnt in den Boards. Es gibt auch haufenweise Leute die immer nur Fordern und nichts dafür tun wollen ! So ist es leider nunmal ! Und so Diskussionen hatte ich schon zu genüge !

Gruß
BOP

Beitrag von **paoli** » Sonntag 22. September 2002, 12:41

ups, zitat-funktion hat nicht hingehauen, man siehts aber auch so :

[quote="BirdOfPrey"]paoli : es kann aber auch vorkommen, daß der fehler nur innerhalb eines frames bzw. pictures auftaucht, dann merken die recorder-progs nichts davon, ist aber selten.
Ja, aber das kann es bei mir nicht sein ! Denn diese Fehler treten dann ja nicht alle 20 bis 30 Sekunden auf !
[/quote]

was hat das mit der zeit zu tun ? es können bits falsch sein, wenn dies nur innerhalb eines einzelnen bildes ist, wird die kontrolle des programms nicht anspringen, das bild wird aber falsch (artefakte oder aussetzer wenn zu viel im a.. ist) wiedergegeben. wenn es ein i- oder p-frame war, kann sich der fehler auf das ganze gop auswirken.

[quote="BirdOfPrey"]Ein neu muxen bringt auch keinen Erfolg. Das einzige was hilft ist ein neu encoden. Und da habe ich bis jetzt noch nicht (ausführlich) überprüft, ob wirklich sichtbare Fehler im Stream sind ! Aber ein kurzes Reinschauen sah so aus !
[/quote]

wen du neu encoden kannst, muß die datenstructur des stream relativ heile sein, dazu muß ja auch decodet werden und der decoder wird alle notwendigen daten bekommen, sonst würde er oder der encoder aussteigen.

hast du mal ein stream-analyse-programm drüberlaufen lassen, welches genau die mpeg2 - syntax überprüft ?
da auf der untersten ebene (block) nur bestimmte codierungen mit variabler länge zulässig sind, ergeben falsche bits mit großer wahrscheinlichkeit keine gültigen werte und lassen sich deshalb leicht ausfindig machen.

paoli hat geschrieben:was hat das mit der zeit zu tun ?

Na ja, ich wollte damit sagen, das ich dann halt ziemlich viele Bitfehler hätte ! Halt so alle 20 - 30 Sekunden ! Sprich alle 500 bis 750 Frames !
Und das kann ich mir eigentlich nicht vorstellen ! Und das decodieren klappt auch mit Fehler ! Es kommt halt nur drauf an womit decodiert wird. Nur kann ein Decodieren mit anschließendem Codieren natürlich keine Fehler mehr beheben ! Deswegen müßten die eigentlich sichtbar sein ! Ich kanns nur leider nicht mehr überprüfen.

Gruß