ggrab: Neue Version (0.20) mit neuen Features!
-
- Einsteiger
- Beiträge: 394
- Registriert: Mittwoch 9. Oktober 2002, 11:12
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
Hi,
>Hauptvorteil von udp: Keine Kollisionen mehr auf der Halbduplexverbindung.
hmm...ich hab' mal mit ifconfig nachgeschaut und habe sehr wenige Kollisionen beim streamen....._15_ bei 200MB uebertragenen Daten. Das kann man wohl vergessen, oder?
>Kleinerer Vorteil: Etwas weniger Prozessorlast auf der Box.
das hatte ich als Hauptvorteil angesehen....was heisst denn etwas weniger? Du hast mal von 8 % gesprochen...das faende ich aber schon bemerkenswert und wuerde imho auf meiner Kiste sicher noch mal fuer zusaetzliche 500kbit/sek sorgen. Mir ist aufgefallen das die Prozessorlast von streampes (Kerlimann/Simplex/Insolvenzia) (unter TCP/IP) gesunken ist aber die von keventd dafuer gestiegen ist?? Ich hoffe das UDP da noch was mehr bringt.
Weiterhin ist das fuer mich alles etwas konfus mit den verschiedenen streampes Versionen die ich getestet habe:
Deine streampes Version wird wie die 'alten' Versionen beim streamen 2 mal gestartet (Video/Audio?) und die Prozessorlast ist wie bei den 'alten' Versionen. Die von Kerlimann ,Simplex, Insolvenzia (frisch kompiliert mit den aktuellen Sourcen) sind beim streamen 6 mal aktiv und die Prozessorlast ist niedriger und unabhaengig von der Datenrate....aber leider mit dem Anstieg bei keventd. Also irgendwas hakt da noch, oder?
cu,
peter
--
Gegen Langeweile hilft nur Neugier, gegen Neugier hilft nichts.
>Hauptvorteil von udp: Keine Kollisionen mehr auf der Halbduplexverbindung.
hmm...ich hab' mal mit ifconfig nachgeschaut und habe sehr wenige Kollisionen beim streamen....._15_ bei 200MB uebertragenen Daten. Das kann man wohl vergessen, oder?
>Kleinerer Vorteil: Etwas weniger Prozessorlast auf der Box.
das hatte ich als Hauptvorteil angesehen....was heisst denn etwas weniger? Du hast mal von 8 % gesprochen...das faende ich aber schon bemerkenswert und wuerde imho auf meiner Kiste sicher noch mal fuer zusaetzliche 500kbit/sek sorgen. Mir ist aufgefallen das die Prozessorlast von streampes (Kerlimann/Simplex/Insolvenzia) (unter TCP/IP) gesunken ist aber die von keventd dafuer gestiegen ist?? Ich hoffe das UDP da noch was mehr bringt.
Weiterhin ist das fuer mich alles etwas konfus mit den verschiedenen streampes Versionen die ich getestet habe:
Deine streampes Version wird wie die 'alten' Versionen beim streamen 2 mal gestartet (Video/Audio?) und die Prozessorlast ist wie bei den 'alten' Versionen. Die von Kerlimann ,Simplex, Insolvenzia (frisch kompiliert mit den aktuellen Sourcen) sind beim streamen 6 mal aktiv und die Prozessorlast ist niedriger und unabhaengig von der Datenrate....aber leider mit dem Anstieg bei keventd. Also irgendwas hakt da noch, oder?
cu,
peter
--
Gegen Langeweile hilft nur Neugier, gegen Neugier hilft nichts.
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
-
- Einsteiger
- Beiträge: 394
- Registriert: Mittwoch 9. Oktober 2002, 11:12
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
nunja, aber es muesste doch zumindest eine udp verbindung zwischen box und server zu sehen sein.Gandalfx hat geschrieben:@kerlimann
nimms mir net übel, aber wenn mans nicht verstanden hat.....
Es wird zustätzlich die tcp-Verbindung gebraucht, um den Datenstrom beim Beenden auch wieder zu stoppen.
werd ich gleich mal testen, danke.Start mal tcpdump und schau mal genauer
PS: irgendne idee, warum die streams nicht standard konform sind? wie schon oefters hier geposted.. anschauen kann man sich die ja problemlos, aber auf DVD bringt man die nicht.
IMHO laesst du den audiostream konstant weiter aufzeichnen, obwohl zwischendurch bildaussetzer drin sind. ich vermute mal, das haengt damit zusammen?
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
hier mein ggrab aufruf:Gandalfx hat geschrieben:Start mal tcpdump und schau mal genauer
/ggrab/ggrab -p 0x0259 0x025a -s 8000 -udp
und hier tcpdump bezueglich dbox:
20:31:54.061659 dbox.31338 > localhost.34080: P 1479979123:1479980491(1368) ack 1431305643 win 5792 <nop,nop,timestamp 7520030 8589746> (DF)
20:31:54.061773 localhost.34080 > dbox.31338: . ack 1368 win 63712 <nop,nop,timestamp 8589752 7520030> (DF)
20:31:54.062956 dbox.31338 > localhost.34080: . 1368:2816(1448) ack 1 win 5792 <nop,nop,timestamp 7520030 8589746> (DF)
20:31:54.064243 dbox.31338 > localhost.34080: . 2816:4264(1448) ack 1 win 5792 <nop,nop,timestamp 7520030 8589746> (DF)
20:31:54.064366 localhost.34080 > dbox.31338: . ack 4264 win 63712 <nop,nop,timestamp 8589752 7520030> (DF)
20:31:54.065486 dbox.31338 > localhost.34080: . 4264:5712(1448) ack 1 win 5792 <nop,nop,timestamp 7520030 8589746> (DF)
usw..
also ich finde da echt nichts, was ueber port 30.000 geht.
-
- Einsteiger
- Beiträge: 394
- Registriert: Mittwoch 9. Oktober 2002, 11:12
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
jau:
21:07:42.579628 dbox.1024 > localhost.30000: udp 1444 (DF)
waehrend ich gerade WDR streame (zum testen).. welches format wird denn nun gespeichert? du erlaubst als extension wahlweise VOB oder was anderes. ist das denn ein VOB file?
PS: um 23:50 kommt auf WDR vangelis, mythodea. hoffentlich klappt das! wenn ich das nicht auf DVD bringen kann waers echt schade drum.
21:07:42.579628 dbox.1024 > localhost.30000: udp 1444 (DF)
waehrend ich gerade WDR streame (zum testen).. welches format wird denn nun gespeichert? du erlaubst als extension wahlweise VOB oder was anderes. ist das denn ein VOB file?
PS: um 23:50 kommt auf WDR vangelis, mythodea. hoffentlich klappt das! wenn ich das nicht auf DVD bringen kann waers echt schade drum.
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
aua:
/ggrab/ggrab -p 0x0259 0x025a -host dbox -s 8000 -udp
000:10 rt:3332 rt:0183
000:20 rt:3188 rt:0191
000:30 rt:3293 rt:0191
000:40 rt:3473 rt:0194
000:50 rt:2385 rt:0192
001:00 rt:3296 rt:0191
001:10 rt:4085 rt:0192
001:20 rt:2072 rt:0192
001:30 rt:2861 rt:0194
001:40 rt:3780 rt:0190
001:50 rt:4364 rt:0201
video pts gap = 1.5 s
002:00 rt:4948 rt:0191
xlist::getelem timeout wait for data
gerade mal 2 minuten.. hmpf
/ggrab/ggrab -p 0x0259 0x025a -host dbox -s 8000 -udp
000:10 rt:3332 rt:0183
000:20 rt:3188 rt:0191
000:30 rt:3293 rt:0191
000:40 rt:3473 rt:0194
000:50 rt:2385 rt:0192
001:00 rt:3296 rt:0191
001:10 rt:4085 rt:0192
001:20 rt:2072 rt:0192
001:30 rt:2861 rt:0194
001:40 rt:3780 rt:0190
001:50 rt:4364 rt:0201
video pts gap = 1.5 s
002:00 rt:4948 rt:0191
xlist::getelem timeout wait for data
gerade mal 2 minuten.. hmpf
-
- Einsteiger
- Beiträge: 394
- Registriert: Mittwoch 9. Oktober 2002, 11:12
Gespeichert wird immer, auch von den anderen Programmen, egal wie die Extension ist, ein MPEG-Program Stream. Der ist auch auf ner DVD.
Bei mir spielt der DVD-Player den File direkt ohne Authoring direkt ab.
Manche Authoring-Programme haben Probleme mit den Fehlern im Stream, wie er von der Box kommt. Ich laß dann den Stream (falls notwendig) von PVAstrumento korrigieren.
Bei mir spielt der DVD-Player den File direkt ohne Authoring direkt ab.
Manche Authoring-Programme haben Probleme mit den Fehlern im Stream, wie er von der Box kommt. Ich laß dann den Stream (falls notwendig) von PVAstrumento korrigieren.
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
ja klar, aber bei wingrabe oder ngrab sind diese probleme nicht vorhanden. klar sind dann da droputs drin, bei resyncs, aber der stream an sich ist korrekt, und wird von den authoring programmen nicht bemaengelt.Gandalfx hat geschrieben: Manche Authoring-Programme haben Probleme mit den Fehlern im Stream, wie er von der Box kommt.
-
- Neugieriger
- Beiträge: 12
- Registriert: Dienstag 24. Dezember 2002, 19:11
Genau das Problem hatte ich weiter oben im Thread ja auch schon mal geschildert... Leider muss PVAStrumento bei ggrab-Streams aber _deutlich mehr_ Fehler korrigieren, als ich mit z.B. WinGrab Resync's erhalte ... Meistens sind in den ggrab Strams so viele Fehler, daß diese nach einem PVAStrumento durchlauf völlig ungeniessbar sind (Bildfehler und Aussetzer, Tonfehler, ...).kerlimann hat geschrieben:ja klar, aber bei wingrabe oder ngrab sind diese probleme nicht vorhanden. klar sind dann da droputs drin, bei resyncs, aber der stream an sich ist korrekt, und wird von den authoring programmen nicht bemaengelt.
Bye
VD Filters
-
- Neugieriger
- Beiträge: 8
- Registriert: Dienstag 7. Januar 2003, 23:17
Hilfe bin zu blöd!!!! Denke ich zumindest *gg*
Also wenn ich versuche ggrab zu starten mit übergabe der pid usw funktioniert das grabben ( zumindest wird ein file erstellt) Wenn ich jedoch den sserver starte mit gleichen Parametern jedoch ohne pid's bekomme ich an der dbox die meldung dass keine Verbindung zum Streaming Server aufgebaut werden konnte.
Und was mach ich da jetzt falsch????
Also wenn ich versuche ggrab zu starten mit übergabe der pid usw funktioniert das grabben ( zumindest wird ein file erstellt) Wenn ich jedoch den sserver starte mit gleichen Parametern jedoch ohne pid's bekomme ich an der dbox die meldung dass keine Verbindung zum Streaming Server aufgebaut werden konnte.
Und was mach ich da jetzt falsch????
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
du hast der dbox die IP des streamingservers nicht mitgeteilt? unter EINSTELLUNGEN -> STREAMINGSERVERkleiner hat geschrieben:Wenn ich jedoch den sserver starte mit gleichen Parametern jedoch ohne pid's bekomme ich an der dbox die meldung dass keine Verbindung zum Streaming Server aufgebaut werden konnte.
Und was mach ich da jetzt falsch????
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
tja. also wirklich, die arbeit von gandalfx in allen ehren! das was sein tool da abspeichert ist OK um es auf dem PC(!) anzuschauen, hat aber wirklich den makel, das der stream absolut nicht mpg2 konform ist. er hat fehler, die er "irgendwie" ausbuegelt, so das der ton weiterlaeuft und das bild fehler hat. das KANN SO nicht gehen. das fuehrt sogar so weit, das beim beenden von PowerDVD sich sogar W2K sich im schlimmsten fall mit einem BlueScreen verabschiedet. einen lockup auf W2K schaffte bisher nur BSE mit tuxvision <g>.vdfilters hat geschrieben:völlig ungeniessbar sind (Bildfehler und Aussetzer, Tonfehler, ...).
auch ist das ja nett, wenn gandalfx eine firmware in seinem dvdplayer hat, welche mpg2 streams ohne authoring information auf der dvd abspielt. alles schoen und gut. "laeuft ja".
MIR geht es allerdings darum, das WENN ich eine DVD brenne, diese dann auch KONFORM zu sein hat, zu ALLEN playern. ja, ich hab auch ne firmware fuer meinen yamakawa, da ginge das auch. aber mal ernsthaft:
ich brenne mir doch nicht ne DVD, wo fehler drin sind. also noe, da speicher ich auf VHS oder besser (wenns fuer mich wichtig ist) auch miniDV und gut. das ist fehlerfrei (wenn auch analoge aufnahme).
ICH PERSOENLICH (ego rauskehr <g>) empfinde es als durchaus stoerend, ueberhaupt fehler beim fernsehen zu haben. mich lenkt sowas total ab. und viel schlimmer ist es, wenn man sich das dann mal zum 2ten mal ansieht: "ach scheisse, gleich kommt wieder der dropout".
nee, sorry. das fuehrt doch die DVD an sich absolut ad absurdum.
ein guter ansatz ist es allerdings allemal, nur wire gesagt hat mir UDP nix gebracht. nach 2 minuten und 7 sekunden ist ggrab ausgestiegen, und da wurde dann garnix mehr aufgenommen. das kanns nicht sein. vangelis mythodea hab ich nun mit wingrabe gestreamed:
00:53:48.413 [Muxer] Resync successful
00:53:48.413 [Muxer] warning: audio (1) pts discontinuity detected [-86400 pts cycles]
00:53:46.600 [Muxer] warning: video dts discontinuity detected [-86400 dts cycles]
00:53:46.400 [Muxer] invalid video sequence: more than 1 picture with same temporal_reference found [sequence skipped, need resync]
00:53:16.467 [Muxer] Resync successful
00:53:16.467 [Muxer] warning: audio (1) pts discontinuity detected [-86400 pts cycles]
00:53:15.355 [Muxer] warning: video dts discontinuity detected [-86400 dts cycles]
00:53:14.594 [Muxer] invalid video sequence: more than 1 picture with same temporal_reference found [sequence skipped, need resync]
00:53:08.405 [Muxer] Resync successful
00:53:08.385 [Muxer] warning: audio (1) pts discontinuity detected [-86400 pts cycles]
00:53:06.212 [Muxer] warning: video dts discontinuity detected [-86400 dts cycles]
00:53:05.711 [Muxer] invalid video sequence: more than 1 picture with same temporal_reference found [sequence skipped, need resync]
00:52:51.340 [Muxer] Resync successful
00:52:51.330 [Muxer] warning: audio (1) pts discontinuity detected [-43200 pts cycles]
00:52:51.320 [Muxer] warning: video dts discontinuity detected [-43200 dts cycles]
00:52:51.320 [Muxer] invalid video sequence: temporal_reference > picture count in sequence [sequence skipped, need resync]
00:52:08.529 [Muxer] Resync successful
00:52:08.519 [Muxer] warning: audio (1) pts discontinuity detected [-86400 pts cycles]
00:52:06.556 [Muxer] warning: video dts discontinuity detected [-86400 dts cycles]
00:52:06.546 [Muxer] invalid video sequence: more than 1 picture with same temporal_reference found [sequence skipped, need resync]
23:47:44.413 [Muxer] Resync successful
aergerlich, der patzer in "movement 10", aber immerhin dvd konformer stream. die spitzen gingen (sofern ichmal raufgeschaut habe) bis 5700k. fehlerfrei! koennte man "fast" brennen. <g>. ja nee, legal. ich zahle GEZ!
PS: bei nem spielfilm waers mir egal gewesen, bei vangelis isses echt aergerlich.
-
- Neugieriger
- Beiträge: 8
- Registriert: Dienstag 7. Januar 2003, 23:17
kerlimann hat geschrieben:du hast der dbox die IP des streamingservers nicht mitgeteilt? unter EINSTELLUNGEN -> STREAMINGSERVERkleiner hat geschrieben:Wenn ich jedoch den sserver starte mit gleichen Parametern jedoch ohne pid's bekomme ich an der dbox die meldung dass keine Verbindung zum Streaming Server aufgebaut werden konnte.
Und was mach ich da jetzt falsch????
doch hab ich sogar ziehmlich sicher die richtige und erreichen kann er den rechner auch ist nämlich der gleiche wie der router.
Muss ich beim starten vom sserver auch pid's angeben????
-
- Einsteiger
- Beiträge: 394
- Registriert: Mittwoch 9. Oktober 2002, 11:12
@kleiner
neine, eigentlich brauchst du bei sserver überhaupt keine Parameter. Kandidat für Ärger ist allerdings n lokaler Firewall auf dem Rechner.
@all, die udp testen,
vergesst das für den Moment: Ich teste immer im CDK, da hab ich ca. 30-50 % Prozessorlast bei 5000 kBit/s. Mache ich den streampes ins aktuelle (5.1.) Alexw, hab ich 100 %, davon allein 60 % keventd. -> Übrigens auch beim "normalen" streampes das gleiche Verhalten.
neine, eigentlich brauchst du bei sserver überhaupt keine Parameter. Kandidat für Ärger ist allerdings n lokaler Firewall auf dem Rechner.
@all, die udp testen,
vergesst das für den Moment: Ich teste immer im CDK, da hab ich ca. 30-50 % Prozessorlast bei 5000 kBit/s. Mache ich den streampes ins aktuelle (5.1.) Alexw, hab ich 100 %, davon allein 60 % keventd. -> Übrigens auch beim "normalen" streampes das gleiche Verhalten.
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
Hi,
Hast Du irgendeine Idee woran das liegen koennte?
cu,
peter
--
"Wirf den Stein als erster, sonst nennt man dich einen Epigonen" (Lec)
vielen Dank fuer diesen Hinweis!!! Ich find's mehr als schade wieso das erst jetzt auffaellt (aber danke das Du es bemerkt hast!!)....Hinweise auf diese hohen Prozessorlast-Werte hat's ja schon genuegend von uns Usern gegeben....werden unsere Bemuehungen und Tests so wenig beachtet und ernst genommen? Also ich komme mir dabei ziemlich verarscht vor....ich bin mir darueber klar das ich zu der Horde von Betatestern gehoere (die ihr braucht!), aber dass unsere Hinweise anscheinend direkt in dev0 landen war mir nicht klar.Gandalfx hat geschrieben: vergesst das für den Moment: Ich teste immer im CDK, da hab ich ca. 30-50 % Prozessorlast bei 5000 kBit/s. Mache ich den streampes ins aktuelle (5.1.) Alexw, hab ich 100 %, davon allein 60 % keventd. -> Übrigens auch beim "normalen" streampes das gleiche Verhalten.
Hast Du irgendeine Idee woran das liegen koennte?
cu,
peter
--
"Wirf den Stein als erster, sonst nennt man dich einen Epigonen" (Lec)
-
- Einsteiger
- Beiträge: 134
- Registriert: Montag 22. April 2002, 13:52
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
hi,
kanns damit zusammen haengen:
http://www.kernelnewbies.org/kernels/rh ... entd.patch und http://lists.insecure.org/lists/linux-k ... /0505.html ?
Auf welcher Linux Version basiert das Alexw und welche Version hast Du wenn Du ueber Yadd testest?
cu,
peter
--
Wer bis zum Hals im Wasser steht sollte den Kopf nicht haengen lassen.
kanns damit zusammen haengen:
http://www.kernelnewbies.org/kernels/rh ... entd.patch und http://lists.insecure.org/lists/linux-k ... /0505.html ?
Auf welcher Linux Version basiert das Alexw und welche Version hast Du wenn Du ueber Yadd testest?
cu,
peter
--
Wer bis zum Hals im Wasser steht sollte den Kopf nicht haengen lassen.
-
- Einsteiger
- Beiträge: 134
- Registriert: Montag 22. April 2002, 13:52
-
- Einsteiger
- Beiträge: 134
- Registriert: Montag 22. April 2002, 13:52
-
- Semiprofi
- Beiträge: 1208
- Registriert: Donnerstag 26. Dezember 2002, 07:26
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
Hi,
ok, an dem Patch scheints als nicht zu liegen....
Eigentlich muesste bei mir jetzt Freude aufkommen, da ich weiss, dass ich meine Wette (streamen klappt bis Endes dieses Jahres fehlerfrei)gewonnen habe, aber im Moment ueberwiegt noch der Frust ueber die Riesenscheuklappen und Ignoranz die hier einige haben...alle dev's und nicht nur die, haben doch eine yadd am laufen, oder?
cu,
peter
PS:Nochmals danke an Gandalfx!
--
Um klar zu sehen, genügt oft schon ein Wechsel der Blickrichtung.
[Antoine de Saint-Exupéry]
ok, an dem Patch scheints als nicht zu liegen....
...aber hast Du Dir mal den kompletten Thread von dem zweiten Link durchgelesen? '..don't (ab)use keventd for Disk I/O..' was ich auch auf R/W Operationen in ein langsames Speichermedium anwende. In dem Zusammenhang wieder der Hinweis auf das Konzept von tonsel, der es geschafft hat gerade diese R/W Operationen deutlich zu reduzieren was imho zu der sehr niedrigen CPU-Last bei keventd gefuehrt hat. Es kann doch wohl nicht so schwer sein den Unterschied zwischen yadd und einer geflashten Version herauszufinden, oder? Ich tippe mal auf langsamere R/W Vorgaenge in der Box und zusaetzlich auf eine konzeptionelle Schwaeche...die Loesung von tonsel ist imho besser.boxi hat geschrieben:hab jetzt mal mit ner yadd getestet... aber die probleme treten immer noch auf, obwohl die cpu-belastung wesentlich geringer ist...
es gibt immer noch dmx queue overflows.
Eigentlich muesste bei mir jetzt Freude aufkommen, da ich weiss, dass ich meine Wette (streamen klappt bis Endes dieses Jahres fehlerfrei)gewonnen habe, aber im Moment ueberwiegt noch der Frust ueber die Riesenscheuklappen und Ignoranz die hier einige haben...alle dev's und nicht nur die, haben doch eine yadd am laufen, oder?
cu,
peter
PS:Nochmals danke an Gandalfx!
--
Um klar zu sehen, genügt oft schon ein Wechsel der Blickrichtung.
[Antoine de Saint-Exupéry]