Seite 1 von 1
Probleme mit GGrab-Engin und Projekt-X...
Verfasst: Mo 21 Jun 2004, 14:28
von Samson71
Habe gestern via JTG mit ggrab-Engin The Stand & Babylon 5 gestreamt.
Nun wollte ich die MPG-Datei mit Projekt-X, wie ich es bis her immer gemacht habe, Demuxen.
Sowei alles ok, aber wenn Projekt-X die Audiospur schreiben möchte, bekomme ich die Meldung
Skippesframe.........
Das am laufenden Band und immer das selbe Frame.
Was ist hier los? kann mir jemand Helfen, habe keine lust jede Datei einzeln mit TMPG-Encoder zu Demuxen.
Verfasst: Mo 21 Jun 2004, 14:58
von Treito
oste mal das Log von PX
Verfasst: Mo 21 Jun 2004, 15:14
von Samson71
So hier nun das log
Code: Alles auswählen
Montag, 21. Juni 2004 16.04 Uhr CEST
ProjectX 0.81.7_int03 (31.05.2004)
=== session infos ===
=> working with collection 0
-> write output files to :
E:\
=> File 0: D:\DVD\2004-06-21-Hulk\2004-6-21-1600 - Hulk - SCI FI1.mpg (5920768 bytes)
=> File is MPEG-2 PS/SS (Video/Audio PES)
=> demux
-> found PES-ID 0xE0 (MPEG Video) @ 32
-> found PES-ID 0xC0 (MPEG Audio) @ 106510
-> video basics: 480*576 @ 25fps @ 0.6735 (4:3) @ 15000000bps, vbvBuffer 112
-> starting export of video data @ GOP#0
!> dropping useless B-Frames @ GOP#0 / new Timecode 00:00:00.000
-> video: fr/ ct/ 1p/ cg/ og/ dg = 505/ 1/ 0/ 0/ 45/ 0
-> video length: 505 frames @ 00:00:20.200
-> GOP summary: min. 12, max. 30 fields; contains progressive frames
===> new File: E:\2004-6-21-1600 - Hulk - SCI FI1.m2v
--> MPEG Audio (0xC0)
Audio PTS: first packet 00:00:00.290, last packet 00:00:20.574
Video PTS: start 1.GOP 00:00:00.199, end last GOP 00:00:20.399
-> adjusting audio at video-timeline
-> 4 frame(s) (96ms) pre-inserted @ 00:00:00.000
=> src_audio: MPEG-1, Layer2, 48000Hz, stereo, 192kbps, CRC @ 00:00:00.096
-> skipped sourceframe(s) @ 00:00:00.168
-> skipped sourceframe(s) @ 00:00:00.240
-> skipped sourceframe(s) @ 00:00:00.384
-> skipped sourceframe(s) @ 00:00:00.432
----- Ab hier nur wiederholungen wiederholung ----
-> skipped sourceframe(s) @ 00:00:00.432
----------------------------------------------------------
-> skipped sourceframe(s) @ 00:00:00.432
audio frames: wri/pre/skip/ins/add 18/4/101/0/0 @ 00:00:00.432 done..
===> new File: E:\2004-6-21-1600 - Hulk - SCI FI1.mp2
summary of created media files:
.Video (m2v): 505 Frames 00:00:20.200 E:\2004-6-21-1600 - Hulk - SCI FI1.m2v
Audio 0 (mp2): 18 Frames 00:00:00.432 4/101/0/0 E:\2004-6-21-1600 - Hulk - SCI FI1.mp2
=> 5279673 bytes written...
Egal was für eine Aufnahme ich nun mache, ist immer das gleiche
Verfasst: Mo 21 Jun 2004, 15:27
von Treito
Ist das eine Testaufnahme?!
Verfasst: Mo 21 Jun 2004, 20:15
von Samson71
Ja, es ist eine Testaufnahme, hatte gestern eine 3 Stunden Aufnahme, da hat Projekt-X wegen Out of Memory Error abgebrochen.
Wie gesagt, es ist egal wie lange die Aufnahme ist, ob ein paar Sekunden oder gar Stunden.
Verfasst: Mo 21 Jun 2004, 20:42
von Treito
Sieht fast nach Netzwerk-Problem aus...
Was für ucodes verwendest Du?
Verfasst: Mo 21 Jun 2004, 22:39
von Samson71
Also es ist kein problem von mein System her und auch keins der Programme, es ist ein Problem der GGrab-Engin
Hab den Fehler gefunden.
Es liegt am GGrab-Engin, es wird kein Resync gemacht wenn eine Aufnahme Startet, die WinGrab zeigt mind. 1 Resync an am Aufnahme Start an.
Wenn ich die Testaufnahme mit TMPGenc demultiplexe und wieder Multiplexe, und dann diese in Testweise mit Projekt-X wieder demuxe bekomme ich nicht diesen Fehler.
Mein Netzwerk ist ein 1000MBit-Netzwerk, und unterstützt 10/100/1000MBits
Da die Box das einzige Gerät ist was nur mit 10MBit-Maximal arbeitet, kommt das dem übrigen Netzdatenverkehr nicht ins gehege.
Hatte bis Dato auch nie probleme mit dem Streamen gehabt
Das ganze läuft über einen 5 Port Switch/Hub, und selbst wenn 2 Rechner im Internet unterwegs sind und auch sonst noch zwischen den Rechnern Datenverkehr statt findet, wird die Box in keinster weise gestört oder der Datenstrom unterbrochen.
Das unterbrechen passiert nur, wenn mein rechner 100% CPU last hat und daher nix mehr für den Datenverkehr von der Box zum PC übrig bleibt.
Werde mal mit UDRec streamen, leider hat UDRec den nachteil das immer auf PMT gewartet werden muss, was leider keine unmittelbare Aufnahme ermöglicht, dadurch fehlen dann ein paar Sekunden.
Verfasst: Mo 21 Jun 2004, 22:42
von jmittelst
Wieso nutzt Du nicht einfach Udrec ggf. mit TS-Streamin und gut ist?
Wingrab ist eh ... out! Wenn Du unbedingt ein Mpg-File brauchst > Muxxi!
cu
Jens
Edit -@Teito: mit dem Udrec-Tip war ich diesmal schneller
Verfasst: Mo 21 Jun 2004, 22:42
von Treito
Samson71 hat geschrieben:Also es ist kein problem von mein System her und auch keins der Programme, es ist ein Problem der GGrab-Engin
Hab den Fehler gefunden.
Es liegt am GGrab-Engin, es wird kein Resync gemacht wenn eine Aufnahme Startet, die WinGrab zeigt mind. 1 Resync an am Aufnahme Start an.
Wenn ich die Testaufnahme mit TMPGenc demultiplexe und wieder Multiplexe, und dann diese in Testweise mit Projekt-X wieder demuxe bekomme ich nicht diesen Fehler.
Dir ist aber schon klar, dass ggrab und wingrab verschiedene Ausgaben haben? Versuche doch einfach mal die udrec-Engine (Update auf 0.12e bitte manuell durchführen), wenn Du ES streamst, kannst Du Dir mit der Option "Timecode neu berechnen" PX sparen und hast zudem demuxxte Files...
Verfasst: Mo 21 Jun 2004, 22:51
von reinergu
Von Udrec gibt es schon eine neuere Version als die 0.12e!! *malkurzanmerk*
Gruß,
Günter
Verfasst: Mo 21 Jun 2004, 23:21
von Treito
reinergu hat geschrieben:Von Udrec gibt es schon eine neuere Version als die 0.12e!! *malkurzanmerk*
Gruß,
Günter
Oh auch gut, thx, aber siehe meine Sig. Wozu noch udrec?
Verfasst: Mo 21 Jun 2004, 23:34
von reinergu
Ich wollt's nur mal kurz erwähnen, für die die sie noch nicht haben!
Verfasst: Di 22 Jun 2004, 8:41
von Samson71
Habe gerade letzte nacht auf udrec alles eingestellt
Und noch eins, udrec0.12e ist veraltet, gibt schon udrec0.12f
Nur bei udrec, kann ich keine Sofortaufnahme starten, jetzt nicht verwechseln mit dem Button Sofortaufnahme.
Wenn ich Manuell oder via Timer eine Aufnahme starte, wird erst noch auf PMT gewartet, und da vergehen einige Sekunden, die mir dann fehlen würden.
Die meistezeit über Programmiere ich immer den Timer und der hat eine Vorlaufzeit von 2 Minuten.
*** EDIT ***
Hab die Zeit mal gemessen, PMT braucht ca 15-20 Sekunden bis die Datenübertragung begint.
*** EDIT END ***
Verfasst: Di 22 Jun 2004, 9:20
von Treito
Samson71 hat geschrieben:Habe gerade letzte nacht auf udrec alles eingestellt
Und noch eins, udrec0.12e ist veraltet, gibt schon udrec0.12f
Nur bei udrec, kann ich keine Sofortaufnahme starten, jetzt nicht verwechseln mit dem Button Sofortaufnahme.
Wenn ich Manuell oder via Timer eine Aufnahme starte, wird erst noch auf PMT gewartet, und da vergehen einige Sekunden, die mir dann fehlen würden.
Die meistezeit über Programmiere ich immer den Timer und der hat eine Vorlaufzeit von 2 Minuten.
*** EDIT ***
Hab die Zeit mal gemessen, PMT braucht ca 15-20 Sekunden bis die Datenübertragung begint.
*** EDIT END ***
Welche Einstellungen für udrec verwendest Du denn?
@Jens, mist, da warst du tatsächlich mal schneller als ich, allerdings habe ich Deinen Beitrag auch eben erst entdeckt...
Verfasst: Di 22 Jun 2004, 9:30
von wingman
Hab die Zeit mal gemessen, PMT braucht ca 15-20 Sekunden bis die Datenübertragung begint.
vergiss aber nicht daß udrec erst eine ganze weile in den pufferspeicher schreibt, daher ist nicht gleich in jack eine anzeige zu sehen. deswegen könnte man denken es geht nicht gleich los, ist aber definitiv so daß die aufnahme trotzdem schon läuft. hat also evtl. mit pmt gar nix zu tun.