Probleme mit GGrab-Engin und Projekt-X...

Nachricht

Samson71 · #1 Beitrag von **Samson71** » Mo 21 Jun 2004, 14:28

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.

Treito · #2 Beitrag von **Treito** » Mo 21 Jun 2004, 14:58

oste mal das Log von PX

Samson71 · #3 Beitrag von **Samson71** » Mo 21 Jun 2004, 15:14

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

Treito · #4 Beitrag von **Treito** » Mo 21 Jun 2004, 15:27

Ist das eine Testaufnahme?!

Samson71 · #5 Beitrag von **Samson71** » Mo 21 Jun 2004, 20:15

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.

Treito · #6 Beitrag von **Treito** » Mo 21 Jun 2004, 20:42

Sieht fast nach Netzwerk-Problem aus...
Was für ucodes verwendest Du?

Samson71 · #7 Beitrag von **Samson71** » Mo 21 Jun 2004, 22:39

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.

#8 Beitrag von **jmittelst** » Mo 21 Jun 2004, 22:42

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

Treito · #9 Beitrag von **Treito** » Mo 21 Jun 2004, 22:42

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...

reinergu · #10 Beitrag von **reinergu** » Mo 21 Jun 2004, 22:51

Von Udrec gibt es schon eine neuere Version als die 0.12e!! *malkurzanmerk*

Gruß,
Günter

Treito · #11 Beitrag von **Treito** » Mo 21 Jun 2004, 23:21

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?

reinergu · #12 Beitrag von **reinergu** » Mo 21 Jun 2004, 23:34

Ich wollt's nur mal kurz erwähnen, für die die sie noch nicht haben!

Samson71 · #13 Beitrag von **Samson71** » Di 22 Jun 2004, 8:41

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 ***

Treito · #14 Beitrag von **Treito** » Di 22 Jun 2004, 9:20

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...

wingman · #15 Beitrag von **wingman** » Di 22 Jun 2004, 9:30

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.