Delphi-PRAXiS
Seite 6 von 11   « Erste     456 78     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Multimedia (https://www.delphipraxis.net/16-multimedia/)
-   -   Optimierung von Pixel (https://www.delphipraxis.net/188798-optimierung-von-pixel.html)

Uwe Raabe 8. Apr 2016 17:39

AW: Optimierung von Pixel
 
Übrigens: Der Buffer-Overflow schlägt gnadenlos auf das Scanlines-Array zu. Der Code funktioniert nur, wenn man
Delphi-Quellcode:
SetLength(Buffer, 256);
verwendet.

Zacherl 8. Apr 2016 18:10

AW: Optimierung von Pixel
 
Zitat:

Zitat von EWeiss (Beitrag 1335088)
Aber ich verwende davon nur 160 Floats.
Es dürfte doch kein Problem sein aus einem Array nur so viele Einträge zu verwenden wie man sie benötigt
vorausgesetzt ich verwende nicht mehr wie enthalten sind. :)

Das ist alles korrekt. Du darfst zu wenig lesen, aber du darfst nicht zu viel lesen und ebenfalls nicht zu viel schreiben. Aber genau das zu viel Schreiben passiert beim
Delphi-Quellcode:
BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512)
Aufruf.

Zitat:

Zitat von Medium (Beitrag 1335086)
Schreibt das nicht sogar 512 Bytes? Die letzten 256 sind zwar eine Spiegelung der ersten, aber eigentlich gehören sie dazu.

Laut Dokumentation werden mit dem FFT512 Parameter 256 Floats geschrieben, also 1024 Bytes.

Nach eine generelle Frage:
Würde es nicht mehr Sinn machen, nur die ersten paar Sekunden zu visualisieren und danach on-demand jeweils die nächsten paar Sekunden ab aktueller Abspielposition?

Medium 8. Apr 2016 18:55

AW: Optimierung von Pixel
 
Zitat:

Zitat von EWeiss (Beitrag 1335088)
Aber ich verwende davon nur 160 Floats.

Du ja, aber die Bass.dll der du genau diesen Buffer zum rein Schreiben gibst schert sich nicht darum. Mit dem Parameter "BASS_DATA_FFT512" forderst du explizit 256 (danke für die Klärung) Werte (Floats) an, und so viele schreibt die DLL dann auch. Völlig egal auf welche Länge das übergebene Array gesetzt wurde. (Genau genommen weiss die DLL nichtmals, dass es ein Array ist. Nur, dass sie ab Speicheradresse X (=Pointer(Buffer), aber das weiss nur dein Code, nicht die DLL) seine 256 Floats schreiben darf. Dass sie das auch wirklich darf, das ist in deinem Verantwortungsbereich.)

EWeiss 8. Apr 2016 20:01

AW: Optimierung von Pixel
 
Zitat:

Dass sie das auch wirklich darf, das ist in deinem Verantwortungsbereich.)
Ah ok jetzt weiß ich was ihr meint.
Ich bin nur von meinem Code ausgegangen die Bass.dll hat mich dabei weniger interessiert ;)
Gut das macht die Profis (Informatiker) aus.

Letztendlich habe ich mich nur um meinen Code gekümmert so das dieser Fehlerfrei läuft.
Wie oder ob die Bass.dll das abfängt liegt nicht in meinem ermessen.

Zumindest werden keine Exception geworfen.

Zitat:

Übrigens: Der Buffer-Overflow schlägt gnadenlos auf das Scanlines-Array zu. Der Code funktioniert nur, wenn man SetLength(Buffer, 256); verwendet.
Habe ich bedacht..
Und ja wird verwendet.

Delphi-Quellcode:
SetLength(Buffer, BUFFER_SIZE);


Zitat:

Würde es nicht mehr Sinn machen, nur die ersten paar Sekunden zu visualisieren und danach on-demand jeweils die nächsten paar Sekunden ab aktueller Abspielposition?
Das mache ich ebenfalls schon nur nicht in diesen Code vom Spectrogram.
Ich möchte nicht zur Laufzeit in Realzeit Rendern sondern erst das komplette Bitmap erstellen deshalb dieses Example.

Also ich möchte erst sehen wie das Spectrogram aussieht und dann mit "LineTo" anzeigen wo man sich gerade an welcher Position im Stream befindet.
Mit einem Loop könnte man dann später einen bestimmten Bereich immer wieder spielen. (Dafür muss ich aber vorher schon sehen wo ich mich befinde)

Realzeit Render, was ich nicht möchte ;)
Delphi-Quellcode:
        begin
          OffsetX := 2; // normal 256x512
          for i := 0 to pred(Height) do
          begin
            MagLn := round(Sqrt(FFTData[i + 1]) * 3 * Width);
            k := Height - i - 1;

            x := BuffBMP.ScanLine[k];

            if bRTLScroll then
            begin
              //copy original scanline
              Move(x[OffsetX], x[0], (Width - OffsetX));

              //draw new pixels
              for m := 0 to pred(OffsetX) do
                x[Width - OffsetX + m] := MagLn;
            end
            else
            //Left to right
            begin
              //copy original scanline
              Move(x[0], x[OffsetX], (Width - OffsetX));

              //draw new pixels
              for m := 0 to pred(OffsetX) do
                x[m] := MagLn;
            end;
          end;
        end;
Zitat:

Eventuell kannst du noch etwas Performance herausholen, wenn du die Scanlines cached:
Werde ich mir mal genau anschauen.. Danke für den Code

Ich könnte das Bitmap noch verkleinern\zusammenschrumpfen und zusätzlich noch interpolieren
Aber ich möchte jedes Pixel sehen (etwas fürs Auge) und nicht alles zusammenstauchen nur damit es auf dem Bitmap beliebiger länge passt.

Mir ist auch klar das ich nur die ersten 512 Blöcke verwende und diese nicht den gesamten Frequenzbereich zurückgeben.
Deshalb kann ich für 44100 Hz, den Bereich von 22,5 kHz bis 0 (Nyquist-Transformation) nicht anzeigen.
Aber das sind bekannte Probleme.
Wichtiger ist erst mal die Performance (Geschwindigkeit)

Andere frage kann es sein das ScanLine nicht richtig funktioniert
weil das Spectrogram vertikal zeichnet und ScanLine horizontal arbeitet?

gruss

Medium 8. Apr 2016 20:40

AW: Optimierung von Pixel
 
Zitat:

Zitat von EWeiss (Beitrag 1335104)
Wie oder ob die Bass.dll das abfängt liegt nicht in meinem ermessen.

Implizit schon, da ab dem Moment klar ist, dass keine (tatsächlichen) Längeninformationen übergeben werden, ab dem ein typloser Pointer übergeben wird. Aber das muss man natürlich erst mal wissen.

Zitat:

Zumindest werden keine Exception geworfen.
Wie gesagt: Glück! Solche Dinge sind nicht selten die Ursache für richtig fiese, extrem schwer zu findende Fehler, weil sie gerne Symptome an Stellen verursachen, die augenscheinlich so überhaupt nichts mit der eigentlich fehlerhaften Stelle zu tun haben.

EWeiss 8. Apr 2016 20:44

AW: Optimierung von Pixel
 
Zitat:

Wie gesagt: Glück! Solche Dinge sind nicht selten die Ursache für richtig fiese, extrem schwer zu findende Fehler, weil sie gerne Symptome an Stellen verursachen, die augenscheinlich so überhaupt nichts mit der eigentlich fehlerhaften Stelle zu tun haben.
Danke für deine ausführliche Erklärung werde ich mir merken ;)
Habe das Bitmap auf 256 hochgesetzt dauert jetzt zwar 5 Sek länger aber was soll's
Ich denke da kann man noch an verschiedenen stellen schrauben.

Wenn ich analysiert habe warum ScanLine nicht das gewünschte Ergebnis liefert.
wenn Pixel und ScanLine das gleiche liefern +- 1 Sec kann was nicht stimmen.

gruss

Uwe Raabe 8. Apr 2016 21:11

AW: Optimierung von Pixel
 
Zitat:

Zitat von EWeiss (Beitrag 1335108)
Habe das Bitmap auf 256 hochgesetzt dauert jetzt zwar 5 Sek länger aber was soll's

Die Bitmap muss gar nicht größer werden, nur der Buffer. Allerdings musst du dann die Schleife anders aufbauen

Zitat:

Zitat von EWeiss (Beitrag 1335108)
Wenn ich analysiert habe warum ScanLine nicht das gewünschte Ergebnis liefert.
wenn Pixel und ScanLine das gleiche liefern +- 1 Sec kann was nicht stimmen.

Ich habe mal eine MP3-Datei (320kBit/s, 4:52 Dauer, 11,1 MByte) geladen. Die auf meinem System gemessenen Zeiten:

SetPixel: 4,0 s
ScanLine: 1,5 s
ohne Grafik: 1,3 s

Rechnet man die Basiszeit von 1,3 s runter, ergeben sich 2,7 Sekunden bei SetPixel und 0,2 Sekunden bei Scanline. Das ist immerhin ein Faktor von 13,5!

EWeiss 8. Apr 2016 21:24

AW: Optimierung von Pixel
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1335109)
Zitat:

Zitat von EWeiss (Beitrag 1335108)
Habe das Bitmap auf 256 hochgesetzt dauert jetzt zwar 5 Sek länger aber was soll's

Die Bitmap muss gar nicht größer werden, nur der Buffer. Allerdings musst du dann die Schleife anders aufbauen

Zitat:

Zitat von EWeiss (Beitrag 1335108)
Wenn ich analysiert habe warum ScanLine nicht das gewünschte Ergebnis liefert.
wenn Pixel und ScanLine das gleiche liefern +- 1 Sec kann was nicht stimmen.

Ich habe mal eine MP3-Datei (320kBit/s, 4:52 Dauer, 11,1 MByte) geladen. Die auf meinem System gemessenen Zeiten:

SetPixel: 4,0 s
ScanLine: 1,5 s
ohne Grafik: 1,3 s

Rechnet man die Basiszeit von 1,3 s runter, ergeben sich 2,7 Sekunden bei SetPixel und 0,2 Sekunden bei Scanline. Das ist immerhin ein Faktor von 13,5!

Die frage wäre mit meinem Example?
Wenn ja wie sieht die Aktualisierung aus?

Mariah Carey - Breakdown.mp3 320k, 10,8 MB
Pixel 5:97 sec (liegt daran weil mein Bitmap jetzt 256 Hoch ist)
ScanLine kann ich im Moment nicht testen.. muss erst den Fehler vom Medium Code beheben.
Fehler "Bereichsüberschreitung bei ZeilenIndex" wenn mein Buffer 256 groß ist.

gruss

Uwe Raabe 8. Apr 2016 21:54

AW: Optimierung von Pixel
 
Zitat:

Zitat von EWeiss (Beitrag 1335110)
Die frage wäre mit meinem Example?

Hast du das irgendwo hier angehängt? Ich kann gerade nichts finden.

EWeiss 8. Apr 2016 22:01

AW: Optimierung von Pixel
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1335112)
Zitat:

Zitat von EWeiss (Beitrag 1335110)
Die frage wäre mit meinem Example?

Hast du das irgendwo hier angehängt? Ich kann gerade nichts finden.

Seite 4

gruss


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:21 Uhr.
Seite 6 von 11   « Erste     456 78     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz