Hallo,
ich habe mal eine Frage zum Framebuffer unter Linux. Es handelt sich dabei ja quasi um eine Abbildung des Speichers der Grafikkarte im Arbeitsspeicher des Computers, in die lesende und schreibende Zugriffe moeglich sind. Kann mir jemand verraten, welche Komponenten des Computers fuer die Geschwindigkeit dieser Zugriffe bestimmend sind ? Ich nutze den Framebuffer mit dem Tool "fbtv" aus dem Xawtv-Paket zum Fernsehen und habe bei Farbtiefen hoeher als 8 Bit Probleme, es kommt zu Ausfaellen einiger Rasterzeilen, wenn das Bild sehr stark bewegt ist. Gibt es eine Moeglichkeit, den Framebuffer softwareseitig zu "tunen" ? Bitte entschuldigt die ungenaue Fragestellung, aber ich habe von der ganzen Problematik so gut wie keine Ahnung ;-)
Dann noch eine Frage: kennt jemand ein Tool, mit dem ich avi-files in mpeg-filme komprimieren kann, oder noch besser, online vom video- device grabben & packen (in einem Arbeitsgang).
Viele Gruesse und noch eine schoene Woche, Matthias
-- http://www.peticom.de matthias.petermann@gmx.de ICQ-ID: 72522106
Matthias Petermann wrote:
Hallo,
moeglich sind. Kann mir jemand verraten, welche Komponenten des Computers fuer die Geschwindigkeit dieser Zugriffe bestimmend sind ?
Dafuer ist es am wichtigsten, wie dieser Frame-Buffer erzeugt wird ... Meiner Erfahrung nach, ist dieser Standard-VESA-Frame-Buffer gaehnend langsam und nur als Text-Console zu gebrauchen (Leute mit mehr Ahnung werden den Grund vielleicht im VESA-Standard finden ?).
Evtl. sind die speziellen Frame-Buffer-Devices fuer Matrox z.B. schneller ?
BTW: Ich dachte immer die TV-Karten schieben das TV-Bild per Bus-Mastering direkt in den Speicher der Grafikkarte ... Aber das scheint unter Linux nicht so recht der Fall zu sein, da das Bild dort merklichen Rucklern unterliegt (auch bei mir).
Hat da irgendjemand mehr Ahnung ?
Dann noch eine Frage: kennt jemand ein Tool, mit dem ich avi-files in mpeg-filme komprimieren kann, oder noch besser, online vom video- device grabben & packen (in einem Arbeitsgang).
MPEG in Echtzeit komprimieren duerfte auch mit heutiger Rechenpower ein Problem sein (auuser vielleicht Briefmarkenformat). Relativ schwach komprimiertes AVI koennte gut gehen, wenn alle Komponenten gut zusammenarbeiten. (volle Video-Aufloesung)
Ich wuerde die Konvertierung zweistufig machen. Erst AVI mit xanim dekomprimieren (wenn das geht, sprich xanim einzelne Bilder speichert und den passenden AVI-Codec integriert hat - die sind sehr haeufig nicht OpenSource) und dann mit den mpegutils wieder einpacken ... oder mit MainActor probieren, der macht's vielleicht direkt.
Egal womit du es machst, du solltest dich auf eine lange Wartezeit einstellen ...
Bye.
Jens
Am Mon, 26 Jun 2000 schrieb Matthias Petermann:
kommt zu Ausfaellen einiger Rasterzeilen, wenn das Bild sehr starkbewegt ist.
Das ist aber Normal beim TV am Computer und hat mit dem fbtv eigentlich nichts zu tun. Das Fernsehbild besteht aus 2 Halbbildern (ungerade und gerade Zeilen) und die werden von der TV-Karte zusammengematscht. Das klappt meißt prima, nur bei schnellen Bewegungen kommt es zu Ausfranzungen an den Grenzstellen.
Am Mon, 26 Jun 2000 schrieb Jens Lorenz:
moeglich sind. Kann mir jemand verraten, welche Komponenten des Computers fuer die Geschwindigkeit dieser Zugriffe bestimmend sind ?
Dafuer ist es am wichtigsten, wie dieser Frame-Buffer erzeugt wird ... Meiner Erfahrung nach, ist dieser Standard-VESA-Frame-Buffer gaehnend langsam und nur als Text-Console zu gebrauchen (Leute mit mehr Ahnung werden den Grund vielleicht im VESA-Standard finden ?).
Evtl. sind die speziellen Frame-Buffer-Devices fuer Matrox z.B. schneller ?
VESA ist generell sehr langsamm, da ProtectedMode-BIOS-Aufrufe getätigt werden. Und Ja, die speziellen Devices wie Matrox sind wesentlich schneller.
BTW: Ich dachte immer die TV-Karten schieben das TV-Bild per Bus-Mastering direkt in den Speicher der Grafikkarte ... Aber das scheint unter Linux nicht so recht der Fall zu sein, da das Bild dort merklichen Rucklern unterliegt (auch bei mir).
Dann macht ihr irgendwas falsch, hier ist das der Fall. Die Last des TV-Programms sollte dir sagen ob das per Bus-Mastering(overlay) passiert, oder per Copy and Paste.
Bye, Stephan
Stephan Goetter wrote:
Hallo,
BTW: Ich dachte immer die TV-Karten schieben das TV-Bild per Bus-Mastering direkt in den Speicher der Grafikkarte ... Aber das scheint unter Linux nicht so recht der Fall zu sein, da das Bild dort merklichen Rucklern unterliegt (auch bei mir).
Dann macht ihr irgendwas falsch, hier ist das der Fall. Die Last des TV-Programms sollte dir sagen ob das per Bus-Mastering(overlay) passiert, oder per Copy and Paste.
Und die Last sagt halt 100%. Sprich nix Bus-Mastering. Das KWinTV weisst ja auch darauf hin und gibt irgendwelche Parameter fuer das bttv-module an, damit das den Grafik-Speicher der Grafik-Karte findet, lt. /proc/pci liegt der auch da, nur heisst das leider noch lange nicht, dass das dann auch mit dem Bus-Mastering funktioniert ... Beim Starten von kwintv kommt naemlich immer noch diesselbe Meldung. (xawtv gibt Warnung aus, aber faellt dann auf Copy & Paste zurueck)
Grafikkarte ist 'ne ATI Rage IIc, TV-Karte halt Hauppauge mit BT848 (etwas aelteres Modell) ...
Bye.
Jens
On Mon, 26 Jun 2000, Stephan Goetter wrote:
kommt zu Ausfaellen einiger Rasterzeilen, wenn das Bild sehr starkbewegt ist.
Das ist aber Normal beim TV am Computer und hat mit dem fbtv eigentlich nichts zu tun. Das Fernsehbild besteht aus 2 Halbbildern (ungerade und gerade Zeilen) und die werden von der TV-Karte zusammengematscht. Das klappt mei�t prima, nur bei schnellen Bewegungen kommt es zu Ausfranzungen an den Grenzstellen.
Kann es auch vorkommen, dass diese Zeilen auch nur teilweise (also nicht auf die volle Breite bezogen) ausfallen - quasi wenn sich in Bildmitte etwas schnell bewegt, dass es dann auch nur in der Bildmitte Stoerungen gibt ?
BTW: Ich dachte immer die TV-Karten schieben das TV-Bild per Bus-Mastering direkt in den Speicher der Grafikkarte ... Aber das scheint unter Linux nicht so recht der Fall zu sein, da das Bild dort merklichen Rucklern unterliegt (auch bei mir).
Dann macht ihr irgendwas falsch, hier ist das der Fall. Die Last des TV-Programms sollte dir sagen ob das per Bus-Mastering(overlay) passiert, oder per Copy and Paste.
fbtv laueft bei mir mit kaum erwaehnenswerter Last (1%). Das Busmastering scheint also zu funktionieren. Bedeutet das, dass die Stoerungen von der Hardware der TV-Karte erzeugt werden, weil die nicht in der Lage ist, ein entsprechend grosses Bild mit maximaler Farbtiefe zu verarbeiten ?
Matthias
Am Die, 27 Jun 2000 schrieb Matthias Petermann:
Kann es auch vorkommen, dass diese Zeilen auch nur teilweise (also nicht auf die volle Breite bezogen) ausfallen - quasi wenn sich in Bildmitte etwas schnell bewegt, dass es dann auch nur in der Bildmitte Stoerungen gibt ?
Was meinst du denn mit Ausfallen ? Sind die Schwarz oder nur farblich verschoben:
In etwa so:
######### äääää ######## ääää #######
Wenn sich also z.B. ein Arm schnell bewegt und an der Grenze zw. Arm und Hintergrund Ausfranzungen auftreten ist das ganz normal. Und schau dir mal was schnell bewegtes unter X11 oder M$ an, da sollte das genauso sein.
fbtv laueft bei mir mit kaum erwaehnenswerter Last (1%). Das Busmastering scheint also zu funktionieren. Bedeutet das, dass die Stoerungen von der Hardware der TV-Karte erzeugt werden, weil die nicht in der Lage ist, ein entsprechend grosses Bild mit maximaler Farbtiefe zu verarbeiten ?
Also ich hab bei meiner WinTV Radio (Bt848) und fbtv mit 800x600x16 und 640x480x16 keine Probleme. Besser ist natürlich wenn das komplette PAL-Bild reinpasst.
Bye, Stephan
Hallo!
Jens Lorenz wrote:
Matthias Petermann wrote:
Hallo,
moeglich sind. Kann mir jemand verraten, welche Komponenten des Computers fuer die Geschwindigkeit dieser Zugriffe bestimmend sind ?
Dafuer ist es am wichtigsten, wie dieser Frame-Buffer erzeugt wird ... Meiner Erfahrung nach, ist dieser Standard-VESA-Frame-Buffer gaehnend langsam und nur als Text-Console zu gebrauchen (Leute mit mehr Ahnung werden den Grund vielleicht im VESA-Standard finden ?).
Meinst du vielleicht fbdev? Ich habe zu Real-Mode-Zeiten mal eine VESA-Bibliothek programmiert, und das hatte einige Haken, z.B. haben ATI-Grafikkarten andere Read/Write-Seiten als normal, andere verkraften nicht den gesamten Initialisierungsprozeß und so weiter. Ich könne mir vorstellen, daß ein generischer Vesa-FB vielleicht alle diese Fälle abdecken muß und deshalb langsamer ist. Ein weiterer Hauptgrund (nur spekulativ, da ich mich nicht in Assembler auf Linux auskenne) ist, daß z.B. das Setzen eines Pixels sowohl per Interrupt als auch per direktem IO-Aufruf möglich ist. Jedenfalls ist auch die SVGAlib etwas fußkrank. Zur Not also mal Tuningmaßnahmen anwenden, ich werde mir nun erstmal die Implementation anschauen.
Josef Spillner
-- if(!NO_GNUCHESS) { fprintf(gnuoutio, "quit\n"); sleep(1); kill(pid, SIGQUIT); sleep(2); kill(pid, SIGKILL); }
lug-dd@mailman.schlittermann.de
-
Jens Lorenz -
Josef Spillner -
Matthias Petermann -
Stephan Goetter