Bild mit JEDI ZLib komprimieren

[ByTheTime]

@himitsu: Ja, davon habe ich schonmal gehört. Die Frage ist, wie lange es dauert das auszuführen. Ich bastel gerade mit Jpg's. Also wenn ich Quality 30 setzte, das hämmer ich ein 1,1MB BMP runter auf ein 14KB JPG! Finde ich ziemlich gut, den ich sehe keinen großen Unterschied. Und bei meiner langsamen Leitung (6000 Down, 600 UP!; Durch Ausbau im Dorf bald 50.000 :D), wäre das dann optimal :)

Aber es hängt an einer Stelle. Habe es bis zum Empfangen umgesetzt, bekomme aber den JPEG Fehler #42:

Delphi-Quellcode:

procedure TfrmCam.CamServerExecute(AContext: TIdContext);
var
  FStream: TMemoryStream;
  ReceivePic: TJPEGImage;
begin
  FStream := TMemoryStream.Create;
  ReceivePic := TJPEGImage.Create;

  try
    AContext.Connection.Socket.ReadStream(FStream);
  finally
    try
      FStream.Position := 0;
      ReceivePic.LoadFromStream(FStream);
      RVideo.Picture.Assign(ReceivePic);
    finally
      FStream.Free;
      ReceivePic.Free;
    end;
  end;
end;

Okay, meinen ersten Fehler habe ich gelöst, gab ein Problem bei der größe des VideoFensters auf der ClientSeite (oben ist der Server). Doch nun gibt es beim stoppen einen fehler, ich schau nochmal und poste dann mal meinen Arbeitstand.

[Bummi]

Zacherl hatte zu einem verwandten Thema eine Thread
http://www.delphipraxis.net/171035-s...-netzwerk.html

[sx2008]

Zitat:

Zitat von ByTheTime (Beitrag 1191755)

Habe es bis zum Empfangen umgesetzt, bekomme aber den JPEG Fehler #42:

Du darfst nicht einfach "blind" aus dem TCP/IP-Stream lesen, sondern für jedes Bild muss die Grösse beim Empfänger bekannt sein.
Wenn z.B. ein bestimmtes Jpeg-Bild 16548 Bytes hat, dann müssen auch genau die Anzahl von Bytes in den temporären Memorystream geschrieben werden, bevor man ein JPegImage rekonstruiert.
Der Sender muss dazu zuerst die Anzahl der Bytes (L) gefolgt von den Nutzdaten (n) abschicken.
Auf der "Leitung" sieht das so aus.

Code:

LLLLnnnnnnnnnnnnnnnnnnnnnnnn...nLLLLnnnnnnnnnnnnnnnnnnnn...n

Der Empfänger muss also immer 4 Bytes Längenangabe lesen und dann so lange Bytes lesen und sammeln bis die Länge erreicht wird.

Die Senderseite ist sehr leicht zu programmieren; die Empfangsseite ist schon deutlich kniffliger.

[himitsu]

Ob es sich beim JPeg lohnt noch einen Binärdiff anzufertigen :gruebel:
Ich glaub bei Assarbad(Olly) hatte ich mal auf der Webseite ein Diff-Programm/Code gesehn, welcher von Binärdateien ein Differenzabbild erzeugt.
- Das war eine Datei, wo "nur" drinsteht, was man alles in einer Ursprungsdatei ändern muß, damit eine Zieldatei entsteht.
Ich glaub das ging auch recht flott, aber ob das hier, beim JPeg, was "Positives" (Datenreduzierung) bewirkt, weiß ich nicht.

Ein Differenzbild von einem BitMap ist sehr flott erstellt, aber nach der JPeg-Komprimierung und Dekomprimierung dürften sich solche "Fehler" enschleichen, bei der starken Komprimierung, daß man das nun verfälschte Differenzbitmap vermutlich nicht mehr so gut verrechnen kann.

Delphi-Quellcode:

Und bei meiner langsamen Leitung (6000 Down, 600 UP!; Durch Ausbau im Dorf bald 50.000 ), wäre das dann optimal

Merkel hat versprochen, daß in 2 Jahren (also bis Ende 2011) alle Bürger mindestens 10 MBit daheim haben werden ... egal wo sie wohnen.
An deiner Stelle würde ich die Alte mal darauf ansprechen.

Aber sei froh, daß du kein LTE von der Telekom hast ... 100 MBit/s für nur 10€ im Monat und nach 48sec hat man das Traffic-Limit erreicht :lol:

[ByTheTime]

@Bummi: Ja ganz am Ende, steht eine fertige Codec Unit, schau ich mir auf jeden Fall an :)
@sx2008: Ich befasse mich erstmal mit der Unit, in Zacherl's Thread. Aber danke für den Hinweiß :)
@himitsu: Also ich schau mir erstmla die Unit von oben an. Aber ich bin mit meines ersten Ergebniss erstmal zufrieden, den 14Kb sind ja fast nichts :) Ich denke, vllt. würde die berechnung des Differenzbildes sogar etwas mehr Zeit in anspruch nehmen, als das senden:?: Und über die Rechenleistung habe ich mir auch keine Gedanken gemacht. Aber es wäre schön, < 20000K zu bleiben. Zum Internet: Ja, schön wärs :D Wir haben zwar ne LTE Antenne direkt neben dem Haus, aber ich warte jetzt lieber noch 4-5 Wochen, bis ich die 50.000er nutzen kann. Zum Glück steht mein Kaff besser dar als die Nachbardörfer :) Die freuen sich über 6000 bei ihrer 1000er Leitung da :D

[ByTheTime]

Eine Frage hab ich aber nochmal, ich habe mir mal die Unit in dem Thread von Zacherl angeschaut:

Delphi-Quellcode:

procedure WriteDiffPkg(last, next: TBitmap; zipPkg: TMemoryStream; var startLine: Byte; lineStep: Byte);  
procedure ReadDiffPkg(last: TBitmap; zipPkg: TStream);

Ich verstehe leider die beiden prozeduren nicht ganz.
1. Prozedure:

• last = ?
• next = ?
• // Kommt da eine Bitmap rein, oder wird sie dann da ausgegeben?!
• zipPkg = Der verpackte Stream
• startLine = Die Zeile, in der er anfangen soll sie umzuwandeln?
• lineStep = Schickt jede "n"-te Zeile

2. Prozedure:

• last = Das ankommende, entpackte Bild
• zipPkg = Der ankommende Stream // Muss das nicht auhc TMemoryStream sein, ich dachte TStream, gibt es garnicht mehr

So habe ich das jetzt verstanden. Schade, dass das angehängte Beispielprogramm nicht Quellenoffen ist, dann würde sich mir vllt. mehr erschließen :/

[ByTheTime]

@sx2008: Eine Sache ist mir aber noch ausgefallen: Der JPEG-Fehler #42 kommt nicht bei dem lesen aus dem Stream, sondern wenn ich dem TImage wo das Bild reinkommt das Bild eines anderen TImage zuweiße (damit dan wieder ein WebCam-Logo zu sehen ist :) ). Allerdings ist das ein PNG. :?: Mal schauen.