Hi,
ist aber ADH_Build
ich liebe diese Freud´schen "Versprecher"![]()
Ansonsten halte ich diese Idee für sehr gut, habe etwas ähnliches auch schon bei Bildkomprimierung mit verschiedenen anderen Varianten zusammen eingesetzt. Im Deskstream-Programm wurde das aber letztendlich verworfen, später mehr dazu^^
Wie du schon angesprochen hast, ist das "Problem" ja, die "passende" Kodier/Dekodiertabelle aufzubauen. Der "optimale" Baum muss zwangsläufig IMMER mitgesendet werden, wenn es richtig dumm läuft, unterscheidet dieser sich bei ähnlichen Bildern/Texten/Daten kaum, von daher könnte man direkt einige/mehrere "halboptimale" Bäume beim Empfänger abgespeichert lassen und dann nur noch die "Baumnummer" (passt in EIN Byte) mitsenden!
Den Vorteil hast du klar erkannt, Rechenersparnis sowohl beim Sender als auch beim Empfänger!
Bleibt die Zeit, die Nachricht zu übertragen, und letztendlich ist DAS das eigentliche Problem.
Mit heutiger Prozessortechnik und Rechenleistung ist das aufbauen selbst eines "optimalen" Huffmann-Baums in Mikro/Millisekunden erledigt, sowohl beim Sender, als auch beim Empfänger. Aber der Versand/Übertragung per Netzwerk kostet Faktor hundert bis tausend mal so viel Zeit!
Von Latenzen garnicht zu sprechen! Warum sehen denn Videokonferenzen immer noch bescheiden aus, trotz massiver Rechen/Rechnertechnik. Warum laden Videoportale/Streamingdienste massivst Daten vor, und hoffen inständig, dass der User eine "gute" Anbindung zu seinem Provider hat?!
Der Weg zum Empfänger ist zzt. das Problem, nicht die Kodier/Dekodierroutine!