[gelöst] Bitratenber., Dateigrößenerm., Hilfe für Kalva

taki · 23 Aug. 2005

Hallo liebe Leute.
Das Projekt Kalva könnte rege Mithilfe bei folgendem Problem brauchen...

Aus einem Posting von Migo [1] hatte ich in Kalva [2] übernommen, die Bitrate zu verringern, wenn die resultierende Dateigröße bei einer Bitrate von 2000 über 2 GB anwachsen würde (noch mal Danke, migo).

migo schrieb:

(...Auszug...)

Code:

#!/bin/sh
#
[...snip...]
#
# Abfrage der Aufnahmedauer
#
dauer=`kdialog --title "Dauer der Aufnahme" --inputbox "Aufnahmedauer? (Format hh:mm)"`
#
# Umrechnung der Aufnahmedauer in Minuten
# FS: "Field Separator" = "Feldtrennzeichen" für awk
#
minuten=`echo $dauer | awk 'BEGIN { FS= ":" } { print ( $1 * 60 ) + $2 }'`
#
# Festlegung der Bitrate: Unter 120 Minuten Filmdauer stets 2000 kByte/s, darüber Anpassung an max. 2 GB Dateigröße
# lt: "less than" = "kleiner als", Shell-Befehl zum Vergleich zweier Zahlen
# scale: Festlegung der Nachkommastellen der bc-Berechnung, hier: keine ("0"), sonst Fehlermeldung von mencoder
#
if test $minuten -lt 120
then bitrate=2000
else bitrate=`echo "scale=0;(1995-0.9375*$minuten)*8192/(60*$minuten)"|bc`
fi
[...snip...]

Dabei ist folgende Funktion herausgekommen:

Code:

double KalvaRecorder::setBitrate()
{
  int hours   = m_duration->time().hour();
  int minutes = m_duration->time().minute();
  int seconds = m_duration->time().second();
  double bitrate = 2000;
  minutes     = minutes + (hours * 60);
  if ((minutes > 0) and (seconds > 0))  {
     minutes -= 1;
  }
  seconds     = seconds + (60 * minutes);
  // computation of the vbitrate: up to 128 minutes we use 2000 kByte/s,
  // from 129 minutes on we compute a lower bitrate to keep the
  // resulting filesize <= 2 GB 
  if ( minutes > 128 )
     bitrate = std::floor(((1995 - 0.9375 * minutes) * 8192/seconds ));
  return bitrate;
}

Nun kommt das Problem: Kalva soll zukünftig nicht mehr die Bitrate konstant mit 2000 vorgeben, sondern diese soll konfigurierbar werden.

Wenn ich aber nicht mehr 2000 als konstante Bitrate verwende, stimmt die Rechnung ja nicht mehr. Ich würde gerne anders herum herangehen. Aber ich muss gestehen, dass ich von Mathematik so gut wie keinen Schimmer habe. Ich verstehe die Rechnung kaum, muss sie aber jetzt umwandeln.

Mir schwebt folgendes vor: Berechnung, wie groß die Datei mit der (variablen, vorgegebenen) Bitrate bei vorgegebener Dauer in Sekunden wird.
Verringerung der Bitrate zur Reduzierung der Dateigröße auf 2GB, wenn die ermittelte Größe den Grenzwert übersteigt.

Kann mir jemand den (oder die) Algorythmus aufzeigen, den ich dafür benötige? Oder wenigstens den alten Algorhythmus so erklären, dass ich die Terme verstehe?

Insbesondere sind mir die im folgenden rot markierten Konstanten nicht klar.

bitrate = std::floor((( 1995 - 0.9375 * minutes) * 8192 /seconds ));

Ich vermute, dass die erste Konstante die Wunschgröße in GB ist (mit einer gewissen Reserve). Die anderen Werte sind mir aber völlig unklar.

Gruß,
Andreas

----------
[1] http://www.linux-club.de/viewtopic.php?p=153350#153350
[2] http://www.linux-club.de/viewtopic.php?t=31795

TeXpert · 23 Aug. 2005

taki schrieb:
Hallo liebe Leute.
Das Projekt Kalva könnte rege Mithilfe bei folgendem Problem brauchen...
[...]

Wenn ich aber nicht mehr 2000 als konstante Bitrate verwende, stimmt die Rechnung ja nicht mehr. Ich würde gerne anders herum herangehen. Aber ich muss gestehen, dass ich von Mathematik so gut wie keinen Schimmer habe. Ich verstehe die Rechnung kaum, muss sie aber jetzt umwandeln.

mehr Details

konstante Bitrate über die ganze Zeit?
unter Bitrate verstehst Du das übliche Bps (Bit pro Sekunde)

Mir schwebt folgendes vor: Berechnung, wie groß die Datei mit der (variablen, vorgegebenen) Bitrate bei vorgegebener Dauer in Sekunden wird.
Verringerung der Bitrate zur Reduzierung der Dateigröße auf 2GB, wenn die ermittelte Größe den Grenzwert übersteigt.

Kann mir jemand den (oder die) Algorythmus aufzeigen, den ich dafür benötige? Oder wenigstens den alten Algorhythmus so erklären, dass ich die Terme verstehe?

Bitte, bitte, das hat nix mit Musik und Rhytmen zu tun, die Dinger heißen Algorithmen

Ansonsten: trivialer Dreisatz

Limit: 2GB => ca. 1.7*10^10 Bits (wir rechnen Dezimal wird etwas einfacher... bei zweifeln bitte Taschenrechner bemühen)

Laufzeit: HH:MM:SS => ( 60 * HH + MM ) * 60 + SS = Gesamtsekunden (1H = 60 Minuten, 1M = 60 Sekunden)

dann

Code:

if (gesamtsekunden * defaultbitrate) > limit 
then
  calc_bitrate
fi

Bitrate berechnen, was heißt das: Bits pro Sekunde, d.h. wir wollen dass diese Gleichung passt:

gesamtsekunden * bitrate) = limit

also Umformen:

bitrate = limit / gesamtsekunden.

da limit in Bit und zeit in Sekunden passt das. jetzt noch mir der unteren Gaußklammer ganzzahlig machen (floor ist die Gaußklammer)

Insbesondere sind mir die im folgenden rot markierten Konstanten nicht klar.

bitrate = std::floor((( 1995 - 0.9375 * minutes) * 8192 /seconds ));

mir auch nicht, nur, dass die 8192 irgendeine Umrechnung von KByte in Bit ist -> da stecken die 1024 und 8 drin.

taki · 23 Aug. 2005

Danke TeXpert für Deine Erläuterungen.
Inzwischen habe ich die Lösung aber selber gefunden. Ich hatte nur Tomaten auf den Augen...

Die Berechnung der Bitrate war schon vorher völlig unabhängig davon, welche Bitrate man als Wunsch-Bitrate verwendet. Sie berechnet eben, wie hoch die Bitrate bei gegebener Dauer und gegebener Maximalgröße der Datei sein darf.

Kalva hat nun drei Stufen, in denen die Bitrate bei Bedarf eingeschränkt werden kann:

Im Qualitätsprofil wird die Wunschbitrate vorgegeben.

Im Hardwareprofil kann man eine maximal zulässige Bitrate vorgeben, welche von den Fähigkeiten der eigenen Hardware abhängt. Diese Bitrate darf nie überschritten werden.

Wenn man die Dateigröße von 2GB nicht überschreiten möchte, wird immer die Bitrate errechnet, die sich aus der gegebenen Dauer und Dateigröße ergibt.

Überschreitet die Wunschbitrate (aus dem Qualitätsprofil) bzw. Maximalbitrate (aus dem Hardwareprofil) die errechnette Bitrate, wird begrenzt. Auf Wunsch fragt Kalva und erlaubt, dennoch die höhere Bitrate zu verwenden.

Das ganze funktioniert schon recht gut und ist seit einigen Minuten im SVN eingecheckt :wink:

Ich lese mir aber trotzdem gleich nochmal Deine Ausführungen durch, damit ich was daraus lerne , denn Verstehen ist schon besser als nur anwenden.

P.S. Hier die geänderte Funktion aus kalva_recorder.cpp:

Code:

double KalvaRecorder::setBitrate()
{
   int    hours          = m_duration->time().hour();
   int    minutes        = m_duration->time().minute();
   int    seconds        = m_duration->time().second();
   double bitrate        = Settings::bitrate();
   double maxBitrate     = Settings::maxBitrate();
   double reducedBitrate = 0;

   // if the hardware profile defines a maximum bitrate
   // the bitrate from the quality profile must not be
   // greater
   if ( maxBitrate )  {
       if ( maxBitrate < bitrate )
           bitrate = maxBitrate;
   }

   // Only test resulting filesize when the user wants this
   if ( ! Settings::testBitrate() )
       return bitrate;

   // compute the maximum bitrate that is allowed if the filesize should
   // stay under 2GB
   minutes     = minutes + (hours * 60);
   if ((minutes > 0) and (seconds > 0))  {
      minutes -= 1;
   }
   seconds = seconds + ( minutes * 60 );
   reducedBitrate = std::floor((( 1995 - 0.9375 * minutes) *
                                 8192/( seconds )));

   // test if bitrate is exceeding the computed bitrate
   if ( reducedBitrate < bitrate )  {
      int ret = KMessageBox::Continue;
      if ( Settings::bitrateWarnOnly() )  {
         ret = KMessageBox::warningContinueCancel ( this,
                  i18n("<qt>Using the bitrate <b>%1</b> would result in a <i>filesize >= 2GB</i>. Shall I <i>reduce</i> the bitrate to <b>%2</b> to keep the filesize < 2GB ?</qt>")
                      .arg(bitrate)
                      .arg(reducedBitrate), 
                  i18n("Reduce bitrate?") );
      }
      if ( ret == KMessageBox::Continue )
         return reducedBitrate;
   }
   return bitrate;
}

oc2pus · 23 Aug. 2005

mal paar Sachen vom "Hacker":

Code:

   if ( maxBitrate )  {
       if ( maxBitrate < bitrate )
           bitrate = maxBitrate;
   }

besser so:

Code:

   if ( maxBitrate && ( maxBitrate < bitrate ))
           bitrate = maxBitrate;
   }

Code:

   seconds = seconds + ( minutes * 60 );

besser so:

Code:

   seconds += ( minutes * 60 );

und stack-Variablen vermeiden ...

früher ging das alles mit 640k

stell ich mal zur Diskussion ...

taki · 23 Aug. 2005

oc2pus schrieb:
mal paar Sachen vom "Hacker":

Code:

if ( maxBitrate ) { if ( maxBitrate < bitrate ) bitrate = maxBitrate; }

besser so:

Code:

if ( maxBitrate || ( maxBitrate < bitrate )) bitrate = maxBitrate; }

Ist " || " nicht "oder"?

Das wäre dann etwas völlig anderes als was ich haben möchte. Den Vergleich möchte ich nur machen, wenn maxBitrate gesetzt ist. Ansonsten nehme ich gerne mehr Hinweise entgegen ;-)

oc2pus · 23 Aug. 2005

ja, in deinem Falle && ("und"), mir ging es um's Prinzip, also keine kaskadierenden if-if-if ...

und schau dir mal an wieviele "return" du in der kleinen Funktion hast. Du kannst mindestens eins los werden

TeXpert · 25 Aug. 2005

oc2pus schrieb:
ja, in deinem Falle && ("und"), mir ging es um's Prinzip, also keine kaskadierenden if-if-if ...

und schau dir mal an wieviele "return" du in der kleinen Funktion hast. Du kannst mindestens eins los werden

hier ist immer die Frage, wieviel der Compiler da mitspielt, diese Pauschalen Aussagen sind erst mal falsch.

nehmen wir die kaskadierten ifs, ich baue ein simples Beispiel:

Code:

#include <stdio.h>
int main() {
  int a, b;
  printf("a: ");
  scanf("%d", &a); 
  printf("b: ");
  scanf("%d", &b); 
  if (a > 5) {
    if (b > 5) {
       printf("foo\n");
    }
  }
  return 0;
}

bzw.

Code:

#include <stdio.h>
 int main() {
  int a, b;
  printf("a: ");
  scanf("%d", &a); 
  printf("b: ");
  scanf("%d", &b); 
    if (a > 5 && b > 5) {
       printf("foo\n");
  }
  return 0;
}

ich denke wir sind uns einige, dass die Funktionsäquivalent sind, jetzt nehmen wir den gcc und kompilieren dass mit Optimierung (-O2) und schauen uns die Unterschiede an, dazu lasse ich den Assembler-Code ausgeben: gcc -o" -S foo.c

das für beide Varianten (seien die Ausgaben block.s und Schachtel.s) dann kommt folgeder Unterschied raus:

Code:

$ diff schachtel.s block.s
35c35
<       jg      .L4
---
>       jg      .L3
42c42
< .L4:
---
> .L3:

wir reden von einer Umbenennung eines Labels und sonst _nix!_ das kann bei komplexeren Problemen anders aussehen, aber bitte unterschätzt den Compiler nicht.

schauen wir auch auf ein 2. Beispiel:

Code:

#include <stdio.h>
int main() {
  int a, b;
  printf("a: ");
  scanf("%d", &a); 
  printf("b: ");
  scanf("%d", &b); 

  a = a+ b;

  return 0;
}

bzw.

Code:

#include <stdio.h>
int main() {
  int a, b;
  printf("a: ");
  scanf("%d", &a); 
  printf("b: ");
  scanf("%d", &b); 

  a += b;

  return 0;
}

jetzt wieder den Asm-Code produzieren und passend umbenennen und dann das heir:

Code:

$ diff a_plus_b.s a_plusgleich_b.s
$

kein Unterschied.... Die modernen Compiler sind besser als Ihr glaubt

also erst mal ganz locker wegprogrammieren, dann profilen und die Problemstellen optimieren

oc2pus · 25 Aug. 2005

@TeXpert:
korrigiere mal deinen "cut&paste" Fehler in deinem Posting

ok, wie du schon sagst, heutige Compiler sind besser geworden.

Ich wollte ja auch kein Dogma aufstellen. Letzendlich ist Verständlichkeit und Wartbarkeit eines der obersten Ziele. Und manchmal ist es durchaus auch sinnvoll kaskadierende if-if zu haben. Es sollte nur eine Anregung für taki sein.

und der += Operator in dem Fall mit Basisdatentypen wird sicher vom Compiler optimiert. Der += ist ein unärer Operator, d.h. es wird garantiert, das er mit weniger Schritten ausgeführt wird, auch wenn der Compiler nichts optimiert! D.h. man ist immer auf der richtigen Seite.
Bei anderen Datentypen in C++ wird der Unterschied zu Gunsten des += sehr viel stärker greifen, ist aber auch dort wieder Implementationsabhängig und natürlich Compilerabhängig.

Und die GNU Compiler Family ist eh sehr gut

TeXpert · 25 Aug. 2005

oc2pus schrieb:
@TeXpert:
korrigiere mal deinen "cut&paste" Fehler in deinem Posting

ups

macht so natürlich keinen Sinn

ok, wie du schon sagst, heutige Compiler sind besser geworden.

Ich wollte ja auch kein Dogma aufstellen. Letzendlich ist Verständlichkeit und Wartbarkeit eines der obersten Ziele. Und manchmal ist es durchaus auch sinnvoll kaskadierende if-if zu haben. Es sollte nur eine Anregung für taki sein.

für lesbaren und wartbaren code bin ich immer

dazu kommt dann aber, dass && und || die Sache IMHO schnell mal unübersichtlicher machen

Geschmackssache.

ich hab mir mit der Zeit angewöhnt immer leserlich und möglichst ausführlich zu programmieren (dann kann man das auch nach ein paar Tagen noch leichter lesen) und erst nachher einzelne routinen zu optimieren (wenn es denn Probleme gibt) Daher gefällt mir wahrschienlich auch Python so gut

und der += Operator in dem Fall mit Basisdatentypen wird sicher vom Compiler optimiert. Der += ist ein unärer Operator, d.h. es wird garantiert, das er mit weniger Schritten ausgeführt wird, auch wenn der Compiler nichts optimiert! D.h. man ist immer auf der richtigen Seite.

Moooment. += ist kein unärer Operator sondern nur eine Kurzform, hierzu hab ich auf die Schnelle nur im K&R was gefunden:

K&R schrieb:
sind exp1 und exp2 Ausdrücke, dann ist exp1 op= exp2 äquivalent zu exp1 = (exp1) op (exp2).

Weiterhin: Ein Blick in den Stroustrup zeigt mir, dass die X= (mit X in {* ,/, +. -, ....}) Operatoren alle in der gleichen (recht niedrigen) Prioritätsklasse sind wie die einfache Zuweisung, d.h. erst wird die rechte Seite komplett zu einem rvalue ausgewertet und dann zugewiesen, bzw. addiert und zugewiesen, so dass hier bei jedem Datentyp ein a += b und ein a = a + b als äquivalent aufgefasst werden können. d.h. solange der Ausdruck rechts ein a + ( mach viel Zeug) ist, sollte das egal sein.

Bei anderen Datentypen in C++ wird der Unterschied zu Gunsten des += sehr viel stärker greifen, ist aber auch dort wieder Implementationsabhängig und natürlich Compilerabhängig.

bei allen anderen Datentypen kommt es auf die Implementierung des Operators an, ob er überhaupt sinnvoll zu definieren ist.

Und die GNU Compiler Family ist eh sehr gut

diese Dinge können auch andere Kompiler...

oc2pus · 25 Aug. 2005

ad op= instead of stand-alone op:

Scott meyers, More effective C++, Addison Wesley, Item 22:

... Three aspects of efficiency are worth mentioning here. The first is that, in general assignement versions of operators are more efficient then stand-alone versions, because stand-alone versions must typically return a new object, and that costs us the construction and destruction of a temporary. Assignment versions of operators write to there left-hand argument, so there is no need to generate a temporary to hold the operators return value. ...

Leider ist dieses chapter nicht online verfügbar... deshalb nur ein kleiner Auszug, wo ich meine Weisheit her habe.

TeXpert · 25 Aug. 2005

Stimmt, das ist ein Problem

aber hier kommt es dann auf die Implementierung bei den Objekten an. Ich bin da eher kein Freund der Operatorüberladung bei komplexen Klassen, also nur dann wenns sein muss

da ich mit eindeutigen Methoden einfacher das geschehen beschreiben kann. Denn Du musst immer die Implementierung der Operatoren im Kopf haben

oc2pus · 25 Aug. 2005

Ich kann die beiden Bände von Scott Meyers, "Effective C++" und "More Effective C++" nur empfehlen. Dort werden genau solche Sachen sehr gut und mit Beispielen beschrieben.

Und oft ist man (jedenfalls war ich es) verblüfft wie einfach man sein C++ verbessern kann!

Aber das soll taki nicht abschrecken: keep on and have fun

TeXpert · 25 Aug. 2005

oc2pus schrieb:
Ich kann die beiden Bände von Scott Meyers, "Effective C++" und "More Effective C++" nur empfehlen. Dort werden genau solche Sachen sehr gut und mit Beispielen beschrieben.

stimmt

die sind immer wieder nett zu lesen.

Und oft ist man (jedenfalls war ich es) verblüfft wie einfach man sein C++ verbessern kann!

nicht nur verbessern, auch welche trivialen Fehler man manchmal übersieht ..

TeXpert · 26 Aug. 2005

taki schrieb:
Insbesondere sind mir die im folgenden rot markierten Konstanten nicht klar.

bitrate = std::floor((( 1995 - 0.9375 * minutes) * 8192 /seconds ));

ich musste gerade beim Lesen in einem C++ Buch wieder an diesen Thread denken und ich dachte, ich sollte Euch das Zitat nicht vorenthalten

Use Constants
Bad code is often littered with “magic numbers.” In some function, the code is dividing by 24. Why 24? Is it because there are 24 hours in a day? Or because the average price of cheese in New Brunswick is $24? The language offers constants to give a symbolic name to a alue that doesn’t change, such as 24.

const int kAveragePriceOfCheeseInNewBrunswick = 24;

(aus Solter & Kleper; Professional C++; WROX)

taki · 26 Aug. 2005

@Texpert
Hast ja recht. Und ganz frei heraus: Eine Anweisung quasi blind übernehmen ohne sie zu verstehen ist auch nicht die feine Art. Aber getestet ist es... funktioniert

Erst einmal möchte ich alle Features beisammen haben und bin soweit auch für den Anfang schon fast zufrieden. Wenn Kalva seine Videocollection erhalten hat, ist es bei Version 0.9.0. Dann ist erstmal die Jagd nach Features am Ende und es steht eine komplette Überarbeitung an.

Anwender werden sich nur über eines wundern: Von 0.00.001 bis 0.9 wird Kalva wenig mehr als ein viertel Jahr gebraucht haben. Von 0.9.0 bis 1.0 wird die Entwicklung erheblich langsamer, obwohl für Anwender kaum wahrnehmbare Veränderungen dazukommen...

Den ersten Band von Meyers habe ich überigens auch. Den würde ich auch unbedingt emfehlen. Mit einer C++-Erfahrung von etwa drei Monaten ist aber wohl klar, dass da noch einiges zu optimieren ist. Ich lerne eben noch. Meine bisherigen praktischen Programmiererfahrungen rühren leider eher aus Steinzeitsprachen und Umgebungen her (insbes. Ansi 85 COBOL auf BS2000 und Unix und eine seltsame Skriptsprache für PC-Oberflächen, die niemand freiwillig verwenden würde...).

Erst muss Kalva vollständig werden und dabei trotzdem so stabil bleiben wie es derzeit ist.

Dann wird optimiert und restrukturiert. Einige Punkte weiss ich schon, wo dringend Überholungsbedarf ist.

oc2pus · 26 Aug. 2005

taki schrieb:
Anwender werden sich nur über eines wundern: Von 0.00.001 bis 0.9 wird Kalva wenig mehr als ein viertel Jahr gebraucht haben. Von 0.9.0 bis 1.0 wird die Entwicklung erheblich langsamer, obwohl für Anwender kaum wahrnehmbare Veränderungen dazukommen...

das ist normal

taki schrieb:
Den ersten Band von Meyers habe ich überigens auch. Den würde ich auch unbedingt emfehlen. Mit einer C++-Erfahrung von etwa drei Monaten ist aber wohl klar, dass da noch einiges zu optimieren ist. Ich lerne eben noch.

deshalb helfen wir dir ja, weil du Lösungen selbst erarbeitest und nicht reinplatzt "wer schreibt mir dies oder das ...". Und es ist noch kein Meister vom Himmel gefallen, also nicht den Kopf hängen lassen und sich entmutigen lassen, die Praxis kommt von selbst

Und bedenke auch, du machst das freiwillig! Lass dich nicht hetzen, es ist DEIN Projekt. Nimm dir die Zeit die DU brauchst. Setze DEINE Planung um, alles andere wird nix und du verzettelst dich.
Lieber ein stabiles Programm mit wenigen guten features, als die eierlegende Wollmichsau die nix richtig kann. Und unterschätze nicht die Community, die Patches und Änderungen kommen dann schon von selbst dazu ...

TeXpert · 26 Aug. 2005

damit wollte ich kein Salz in irgendwelche Wunden streuen

der viel mir nur gerade so auf...

BTW: ich überfliege das Buch gerade mal so und muss sagen, dass dieses Professional C++ sehr ansprechend geschrieben ist. Die 08/15-Dinge werden nur kurz angerissen und dann gehts direkt in Richtung Softwareengeneering, Modellierung, ... ich hab ja erst die ersten paar Seiten detaillierter überflogen, aber ich glaube das das Buch einen festen Platz neben Kernighan/Ritchie, dem Stroustrup und den Meyers-Bänden bekommt...

oc2pus · 26 Aug. 2005

TeXpert schrieb:
... ich hab ja erst die ersten paar Seiten detaillierter überflogen, aber ich glaube das das Buch einen festen Platz neben Kernighan/Ritchie, dem Stroustrup und den Meyers-Bänden bekommt...

dann hätte ich noch einen Tipp für die Büchersammlung:
Herb Sutter, Exceptional C++, 47 technische Denkaufgaben, Programmierprobleme und ihre Lösungen.

ISBN:3-8273-1711-8

Scott Meyers sagt dazu: "... das ist ein bemerkenswertes Buch. Allerdings habe ich erst, nachdem ich es fast zu Ende gelesen hatte, gemerkt, wie bemerkenswert es ist. Gut möglich, dass dies überhaupt das erste Buch ist, das jemals für Leute geschrieben wurde, die bereits mit C++ vertraut sind - mit ALLEN Seiten von C++...."

TeXpert · 26 Aug. 2005

oc2pus schrieb:
dann hätte ich noch einen Tipp für die Büchersammlung:
Herb Sutter, Exceptional C++, 47 technische Denkaufgaben, Programmierprobleme und ihre Lösungen.

ISBN:3-8273-1711-8

das steht auch schon auf meiner Liste

da gibts BTW auch 2 davon Exceptional und more Exceptional C++...

ich hab nur noch keine Bücherei gefunden die die hat und ich schau vor dem kauf immer gerne mal da rein.

taki · 28 Aug. 2005

Vielen Dank für Eure aufmunternden Worte, aber...

TeXpert schrieb:
damit wollte ich kein Salz in irgendwelche Wunden streuen der viel mir nur gerade so auf...

oc2pus schrieb:
...nicht den Kopf hängen lassen und sich entmutigen lassen

Mache ich etwa diesen Eindruck 8) .

oc2pus schrieb:
Lieber ein stabiles Programm mit wenigen guten features, als die eierlegende Wollmichsau die nix richtig kann.

Ich denke, dass Kalva schon einige Eier legen und Wolle erzeugen kann. Fehlt nur noch die Milch (sprich die Video collection) :lol:

...Instabil ist es trotzdem nicht.

oc2pus schrieb:
Und unterschätze nicht die Community, die Patches und Änderungen kommen dann schon von selbst dazu ...

Weniger als ich erwartet hatte, aber einige wenige sehr wertvolle Patches kamen schon herein. Die wertvollsten Patches kamen und kommen hoffentlich auch weiterhin von Matthias Wieser.

Übrigens habe ich trotz einiger Schwächen (sparsame Verwendung von Speicher aufgrund mangelnder Erfahrung mit Pointern, Referenzen, Verstecken der Implementierung und anderen fortschritlichen C++ spezialitäten etc.) neulich eines der schönsten Komplimente auf mein Coding erhalten: Der Autor von KTvSchedule hatte sich gefreut, dass meine Source so gut zu lesen ist, dass er damit lernen konnte, wie man einer KDE Applikation ein Plugin-System verpasst

Gruß,
Andreas

BTW: Ein guter Nebeneffekt dieses Threads ist, dass hier die wahrscheinlich besten Bücher über C++ genannt wurden. Schade, dass gute EDV-Bücher immer so verdammt teuer sind. Aber wenn ein Buch wirklich etwas taugen soll, ist unter 29,-€ eigentlich nichts drin. Drüber geht immer...

Zu guter Letzt möchte ich noch ein Buch empfehlen. Dieses hat mir den Einstieg ermöglicht (*):

C++ Entwicklung mit Linux
Eine Einführung in die Sprache und die wichtigsten Werkzeuge
dpunkt.verlag
ISBN 3-932588-74-6

(* ...gefolgt von Scott Meyers "Effektiv C++ programmieren", welches ich aber sicher noch öfters werde lesen müssen - letzteres ist keine Einsteigerliteratur, aber trotzdem möchte ich es noch einmal nenne, weil sehr gut)

[gelöst] Bitratenber., Dateigrößenerm., Hilfe für Kalva

Advanced Hacker

Guru

Advanced Hacker

Ultimate Guru

Advanced Hacker

Ultimate Guru

Guru

Ultimate Guru

Guru

Ultimate Guru

Guru

Ultimate Guru

Guru

Guru

Advanced Hacker

Ultimate Guru

Guru

Ultimate Guru

Guru

Advanced Hacker