ggrab: Neue Version (0.20) mit neuen Features!

Beitrag von **dboxP** » Sonntag 27. April 2003, 23:52

Ich bin begeisterter ggrabber!
Mich stört, da ich nun seit einigen Tagen verstärkt von Premiere grabbe, dass selbst unter Linux der Standardwert für die Dateigröße bei 2GB liegt. OK, wendet nun der kundige Readmeleser ein, sieh doch mal in die Parameter - hab ich!
Problem ist, wenn ich z.B. -s 4000 angebe, hört ggrab/sserver (ich nehme meistens über Timer auf) irgendwann VOR Filmende auf. Interessanterweise liegt dieses "irgendwann" meistens vor den 2 GB, hm.
Hat auch schon jemand dieses beobachtet?

Beitrag von **Gandalfx** » Montag 28. April 2003, 14:29

also, eigentlich kann da kein Zusammenhang bestehen (schau ruhig in den Code). Mit -s 0 hat du (fast) keine Begrenzung in der Größe.
Wenn du einen Abbruch vor dem Ende hast, was kommt für eine Fehlermeldung?

Beitrag von **grubi** » Montag 28. April 2003, 15:43

>>Mich stört, da ich nun seit einigen Tagen verstärkt von
>>Premiere grabbe, dass selbst unter Linux der Standardwert
>>für die Dateigröße bei 2GB liegt.

Ich vermute Du versuchst unter Linux auf eine FAT32 Partition zu grabben ?

Die Größenbeschränkung von FAT32 unter Linux ist mir auch schon aufgefallen.

Gruß,
Grubi.

Beitrag von **grubi** » Montag 28. April 2003, 16:18

@Grandalfx

Hab mir mal die Sourcen von deinen Monifikationen angeschaut.
Welche binary(ies) sind denn davon betroffen ?
Eine avia_gt_dmx.o habe ich nicht finden können.

Danke.
Gruß,
Grubi.

Beitrag von **dboxP** » Montag 28. April 2003, 21:15

grubi hat geschrieben:>>Mich stört, da ich nun seit einigen Tagen verstärkt von
>>Premiere grabbe, dass selbst unter Linux der Standardwert
>>für die Dateigröße bei 2GB liegt.

Ich vermute Du versuchst unter Linux auf eine FAT32 Partition zu grabben ?

Die Größenbeschränkung von FAT32 unter Linux ist mir auch schon aufgefallen.

Gruß,
Grubi.

Grubi, danke für den Tipp. Aber vielleicht hatte ich das für zu selbstverständlich gehalten. Die 2GB Begrenzung unter FAT ist nicht das Problem, ich grabbe auf eine EXT2-Partition.
Vielleicht noch zur Ergänzung: das Phänomen, dass ggrab einfach aufhört, scheint immer unterhalb des Standardwertes 2000 MB zu liegen. ...???

Beitrag von **Gandalfx** » Dienstag 29. April 2003, 08:58

@dboxP
kommt von ggrab eine Fehlermeldung, oder beendet sich es ohne Kommentar?

Wenn mit ....Waiting for Data... beendet wird, liegt es an einem Bug im Linux-Kernel auf der Box. Da weigert sich, der Socket weitere Daten zu versenden. Da ich den Fehler nicht finde, habe ich nur einen Workaround: Streame (wenn du ein Image ab 18.2. hast) per udp. Funktioniert unter Linux prima. Da ist ein Workaround für den Bug drin.

2. Möglichkeit: Eine 7.x Version (ich weiß nicht mehr welche) von Suse konnte keine Files > 2 G trotz 2.4.x Kernel. Bei mir laufen definitiv Files > 2 G ohne Probleme.

@grubi
das wird in die avia_gt.o gelinkt. Es sind 2 Modifikationen drin:
1. Im Avia Demuxer wird der Block-Interrupt benutzt, dadurch nur noch 1 Interrupt alle ca. 8 K. Dadurch geht die Prozessorlast beim Streamen deutlich runter.
2. Der Avia Demuxer Ringpuffer wird nicht mehr in einer normalen Prozessumgebung (keventd) ausgeräumt, sondern in einer höher priorisierten (bottom half). Die Latency war vorher bis 150 ms. Da der Ringpuffer nur 64 K groß ist (Hardware), lief der bei hohen Datenraten über und sorgte für Resyncs.

Beitrag von **grubi** » Dienstag 29. April 2003, 13:50

@Gandalfx

Danke für die Info.

Beitrag von **grubi** » Donnerstag 1. Mai 2003, 14:39

@Grandalfx

Hallo Grandalfx.

Habe auf deiner Hompage gesehen, daß Du dort auch eine strempes hast in der Du einen workaround für das blocking durch den write Aufruf drinnen hast (zumindest für UDP).
Würdest Du die Sourcen dafür public machen (interessiert mich brennend) oder ist das topsecret ?

Danke
Gruß,
Grubi

Beitrag von **grubi** » Donnerstag 1. Mai 2003, 22:26

@Grandalfx.

Schon wieder ich.
Ich weiß, das Du momentan sehr wenig Zeit hast aber ich habe nach wie vor die Vermutung, daß in Ggrab die Audio-Timestamps fÃ¡lsch geschreiben werden. Hier die entsprechenden Zeilen aus dem DS.JAR logfile:

-> take only first Audio PTS (to sync the starttime
Audio PTS: first packet 00:00:00.256, last packet 00:00:00.256
Video PTS: start 1.GOP 00:00:00.199, end last GOP 01:13:56.399

DS.JAR meldet. daß alle Audiopakete den gleichen Timestamp haben. Dies wäre auch die Erklärung dafür, daß wenn man die Option "take only first Audio PTS to sync the starttime" ausschaltet das Audiofile nur wenige bytes groß ist.

Ich saug mir mal die Sourcen.
Villeicht finde ich ja was.

Gruß,
Grubi.

Beitrag von **Gandalfx** » Freitag 2. Mai 2003, 09:16

@grubi
die Timestamps sollten eigentlich ok sein. Kannst auch mal hiermit checken:
http://www.offeryn.de/dv.htm#mpgaz
Da werden die ganzen Header angezeigt...

Der streampes ist im Rel-Stand im CVS eingecheckt.

Beitrag von **grubi** » Freitag 2. Mai 2003, 13:33

>>Der streampes ist im Rel-Stand im CVS eingecheckt

Hab ich mitterlweile gefunden. Mit Blindheit geschlagen sorry.

>>die Timestamps sollten eigentlich ok sein.
>>Kannst auch mal hiermit checken:

Hmm ?

Dann doch ein Fehler von DS-JAR ?
Warum gibts das Problem dann nicht mit Streams
der Wingrab Engine. Ich werd die ganze Sache nochmal
aufrollen. Villeicht finde ich ja was.

Danke.
Grubi.

Beitrag von **dboxP** » Sonntag 4. Mai 2003, 23:26

[quote="Gandalfx"]@dboxP
kommt von ggrab eine Fehlermeldung, oder beendet sich es ohne Kommentar?

Wenn mit ....Waiting for Data... beendet wird, liegt es an einem Bug im Linux-Kernel auf der Box. Da weigert sich, der Socket weitere Daten zu versenden. Da ich den Fehler nicht finde, habe ich nur einen Workaround: Streame (wenn du ein Image ab 18.2. hast) per udp. Funktioniert unter Linux prima. Da ist ein Workaround für den Bug drin.

Hallöle, habe mich die letzten paar Tage nicht im Forum rumgetrieben, aber Danke für die Antwort. Leider kann ich zum Abbruch nichts Genaues mehr sagen. Ich werde mal Tests mit -s 0 machen. UDP hat letztens ganz gut funktioniert. Deshalb habe ich noch das Image vom 5. März mit Gandalfs Änderungen drauf.
Sind die übrigens in den offiziellen Bereich aufgenommen worden???
Mein Linux ist ein Debian 3.0. Problem mit großen Dateien sind noch nicht aufgefallen.

Beitrag von **schmalzz** » Montag 5. Mai 2003, 02:15

Hi Allz,

teste ggrab grade unter W2k. Leider ist der erzeugte Stream überhaupt
nicht abspielbar. Abgespielt wird die Datei nur es kommt weder Ton noch
Bild.
Jemand eine Idee? Fehlermeldung erhalte ich vom Programm leider keine.

Gruss

schmalzz

Beitrag von **patrickwolf** » Montag 5. Mai 2003, 09:20

Hallo,

den Fehler habe ich auch auf allen meinen Rechnern

Abhilfe bei mir: Einfach die cygwin Standardinstallation (~30MB) gemacht und siehe da, es funktioniert plötzlich.

Viele Grüße
Patrick

Beitrag von **schmalzz** » Montag 5. Mai 2003, 10:38

patrickwolf hat geschrieben:Hallo,

Abhilfe bei mir: Einfach die cygwin Standardinstallation (~30MB) gemacht und siehe da, es funktioniert plötzlich.

Viele Grüße
Patrick

Hi,

danke für den Tip. Hab grad versucht das runterzuladen, irgendwas mit
Standardinstallation hab ich aber nicht gefunden. Nur ne Setup.exe die
mir verschiedene Pakete zur Auswahl bring. Wenn ich alles übernehme
wie angezeigt komm ich aber nicht auf die 30 MB. Vielleicht kannst du
mir nochmal weiterhelfen.

Gruss

schmalzz

Beitrag von **patrickwolf** » Montag 5. Mai 2003, 10:42

Also ich habe (wie Du auch) die setup.exe von http://www.cygwin.com genommen,
einen deutschen Server ausgewählt und einfach die Paketauswahl übernommen.
Die ~30MB habe ich von meinem cygwin Verzeichnis.
Kann sein, dass der Download natürlich kleiner ist

Patrick

P.S. Habe das übrigens gestern erst auf einem anderen Rechner erfolgreich gemacht.

Beitrag von **grubi** » Montag 5. Mai 2003, 15:54

@dboxP

>>Wenn mit ....Waiting for Data... beendet wird, liegt es an
>>einem Bug im Linux-Kernel auf der Box. Da weigert sich,
>>der Socket weitere Daten zu versenden. Da ich den Fehler
>>nicht finde, habe ich nur einen Workaround: Streame
>>(wenn du ein Image ab 18.2. hast) per udp.
>>Funktioniert unter Linux prima.
>>Da ist ein Workaround für den Bug drin.

Verstehe ich nicht.
Hab mir mal das CVS angeschaut und dort finde ich den
Workaround nur im strempes fork mit der Version 1.4.2.5.
In der Head Version 1.8 finde ich keinen Workaround hierfür ?

Gibt es dafür eine Erklärung ?

Danke.

Beitrag von **Zottl** » Montag 5. Mai 2003, 16:22

Hallo zusammen!

Ich weiß nicht ob ich das hier fragen darf, aber ich hoffe trotzdem auf antwort!

Ich habe ein Problem mit dem Aufnehmen von RTL & RTL2. Beide sind auf dem selben Transponder (Die anderen auf diesem Transponder hab ich nicht getestet) und NGRAB schreibt beim Start der aufnahme das der Audiostream kein MPEG Layer I oder II ist und der Stream bricht nach ungefähr 2min ab. Kann mir jemand helfen?
Dachte zuerst es wär das Image AlexW 28.11.02 habe jetzt das Baseimage 1.6.9 und das letzte cdk.cramfs von AlexW. (Nokia 2, Avia500)

Beitrag von **petgun** » Montag 5. Mai 2003, 18:25

Hi,

Zottl hat geschrieben:Ich weiß nicht ob ich das hier fragen darf

Antwort in dem andern Thread...Du weisst in welchem, oder? Hier wird eigentlich ueber ggrab diskutiert und Doppelpostings finde ich jetzt nicht ganz so prickelnd.

cu,
peter

--
"Du kennst mich doch, ich hab' nichts gegen Fremde.Einige meiner besten Freunde sind Fremde. Aber diese Fremden da sind nicht von hier!"
(Methusalix)

Beitrag von **Tschoertschill** » Montag 5. Mai 2003, 20:55

Ich war so frei und habe bommelid's diffs überarbeitet.

http://www.noid-project.de/sserver.cpp.diff
http://www.noid-project.de/sserver.h.diff

sollte tun

Auch der obige Patch beinhaltet Fehler, wenn man mehrere Aufnahmen nacheinander mit unterschiedlichen Streams aufnehmen möchte.
Daher habe ich die obigen Patches nochmals überarbeitet.

Ich hoffe das sie jetzt Fehlerfrei sind. Zum Einspielen werden die Original-Sourcen, die obigen Patches und mein u.a. Patch benötigt.

68c68,70
< int lang_de_both;
---
> int lang_de_both;
> // added by Tschoertschill
> int anzahl_arg;
143,146c145,153
< //a_arg[n++] = "-nos";
< a_arg[n++] = "-p";
< a_arg[n++] = a_vpid;
<
---
> //a_arg[n++] = "-nos";
>
> // changed by Tschoertschill
> //a_arg[n++] = "-p";
> //a_arg[n++] = a_vpid;
>
> // added by Tschoertschill
> anzahl_arg = n;
>
176c183,185
< {
---
> {
> // added by Tschoertschill
> n = anzahl_arg;
213,214c222,224
< */
< apids=0;
---
> */
> // changed by Tschoertschill
> apids=1;
270c280,285
< fprintf(stderr, "***********************************************************\n");
---
> fprintf(stderr, "***********************************************************\n");
>
> // added by Tschoertschill
> a_arg[n++] = "-p";
> a_arg[n++] = a_vpid;
>
275,276c290,292
< }
< if (apids >= 2){
---
> }
> // changed by Tschoertschill
> if (apids >= 2 && recdata.apid2 != 0){
279,280c295,297
< }
< if (apids >= 3){
---
> }
> // changed by Tschoertschill
> if (apids >= 3 && recdata.apid3 != 0){

Gruss

Tschoertschill

Beitrag von **schmalzz** » Montag 5. Mai 2003, 20:56

patrickwolf hat geschrieben:Also ich habe (wie Du auch) die setup.exe von http://www.cygwin.com genommen,
einen deutschen Server ausgewählt und einfach die Paketauswahl übernommen.
Die ~30MB habe ich von meinem cygwin Verzeichnis.
Kann sein, dass der Download natürlich kleiner ist

Patrick

P.S. Habe das übrigens gestern erst auf einem anderen Rechner erfolgreich gemacht.

@Patrick: Danke, jetzt funktioniert es!

Beitrag von **Gandalfx** » Montag 5. Mai 2003, 23:19

@grubi
in der Rel-Version ist der Workaround drin, aber noch nicht im HEAD. Ich habe im Moment keine Zeit, mir ein Head-CDK zu bauen und zu testen...

@Tschoertschill
Thx, bau ich ein..., wenn ich mal wieder mehr Zeit hab ;-)

Beitrag von **hugohuetzel** » Dienstag 6. Mai 2003, 07:33

@Tschoertschill

Wollte gerade Dein Diff testen, hat aber leider nicht funktioniert da alle Tabs fehlen und an jedem Zeilenende ein Leerzeichen eingefügt wurde. Also nix mit Copy&Paste (HTML machts möglich

).

Die Fehler waren mir auch schon aufgefallen, und ich hatte sie auch schon behoben. Ich hatte nur noch keine Zeit ein neues Diff zu veröffentlichen.
Allerdings hatte sich (glaube ich) noch ein Fehler eingeschlichen. Ich werde das heute Abend mal nachschauen.

Beitrag von **grubi** » Dienstag 6. Mai 2003, 10:18

Gandalfx hat geschrieben:@grubi
in der Rel-Version ist der Workaround drin, aber noch nicht im HEAD. Ich habe im Moment keine Zeit, mir ein Head-CDK zu bauen und zu testen...

Hab ich dann wohl falsch verstanden. Ich dachte es wäre im Head drin.

Danke.

@hugohuetzel

Leider habe ich zur Zeit keinen Webspace zur Verfügung. Ich maile aber bei Interesse das Patch-File (bis es irgentwann in ein offizielles Release veröffentlicht wird) zu.

Email:

tschoertschill@arcor.de

Gruss

Tschoertschill