• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[solved] Problemchen mit Kalva

gameboy

Hacker
Zunächst einmal: Kalva ist m.E. ein echt geniales Programm, das ich vom ersten Tag an total ins Herz geschlossen habe. Bei der Aufnahme von TV-Sendungen gibt es derzeit nur zwei Kleinigkeiten, die mir noch Probleme bereiten...

Das erste Problem besteht darin, daß es mir jetzt schon zweimal passiert ist, daß bei einer geplanten Movie-Aufnahme mit einer eingegebenen Dauer von 2 Stunden nur exakt 2 Minuten lang aufgenommen wurde. Beim ersten mal habe ich zunächst natürlich an mir selbst gezweifelt und in Betracht gezogen, daß ich vielleicht versehentlich 2 min. als Dauer angegeben hätte. Aufgrund dieser Erfahrung habe ich dann heute ganz besonders genau darauf geachtet, die Dauer korrekt einzugeben (02:00:00). Das Resultat war eine .avi-Datei mit einer Größe von gut 23 MB und einer Dauer von genau 2 Minuten. :(

Zum fraglichen Zeitpunkt hat niemand am System gearbeitet, weder direkt am Rechner noch per Remote-Zugriff. Es gibt auch keinen Cronjob, der während der Aufnahme zur Ausführung angestanden hätte. Gibt es irgendeine Möglichkeit, im Nachhinein herauszufinden (z.B. anhand irgendeiner Logdatei), was für ein Problem da aufgetreten ist? - Meine bisherigen Ansatzpunkte haben leider keine Erkenntnisse gebracht... (in /var/log/messages kein Eintrag, betreffende Partition hat noch ca. 160 GB freien Platz)

Der zweite Punkt, der mir noch am Herzen liegt, ist der, daß ich den Ton gern mit konstanter Bitrate aufnehmen würde (anstelle von variabler Bitrate). Leider habe ich auf meine Nachfrage in http://www.linux-club.de/viewtopic.php?t=48834 keine Antwort erhalten, wie das geht. Ich vermute mal, daß es aber grundsätzlich möglich ist...?

Hier noch die Daten meines Systems:

- OS: SUSE 9.3
- kalva-0.8.50-1
- MEncoder 1.0pre7-SUSE-9.3-i686-Packman-3.3.5 (C) 2000-2005 MPlayer Team

Danke im voraus für alle Antworten.

Viele Grüße,
gameboy.
 

taki

Advanced Hacker
zu 1
Hier muss ich leider passen.

Wenn bei der Aufnahme etwas schief läuft, solltest Du eigentlich vom crond (bei Serien) bzw. vom atd (bei Spielfilmen) eine Email erhalten (lokale Zustellung an Deine lokale Benutzerkennung). In dieser Mail sind alle Ausgaben vom MEncoder enthalten. Das sollte helfen, den Fehler einzugrenzen.


zu 2
Leider bietet Kalva hier keine Option im Profil an, um von abr auf cbr umzustellen.

Du kannst den Eintrag ändern, wenn Du Kalva so einstellst, dass es immer alle Kommandos anzeigen soll (setzt KDE >= 3.4 voraus, weil erst dann die editierbare Messagebox verfügbar ist). Das ist allerdings ein wenig lästig, weil Du das bei jeder Aufnahmeplanung machen müsstest.

In die Profileinstellungen würde ich das ungerne aufnehmen, weil es die Profile noch komplexer macht als sie eh schon sind. Hier wäre vielleicht interessant, wieviele Anwender dieses Feature verwenden wollen würden. Es wäre abzuwägen, ob das Feature wichtig genug ist, noch mehr Optionen in die Qualitätsprofile aufzunehmen.
 
OP
G

gameboy

Hacker
Hallo taki,

danke für die super-schnelle Antwort.

Zu 1: Leider wurde keine Mail erstellt (weder an den User, mit dem ich die Aufnahme geplant habe noch an root).

Zu 2: Mit der Anpassung des Kommandos in der editierbaren Messagebox könnte ich gut leben. Mein Problem ist nur, daß ich immer noch nicht herausgefunden habe, was ich genau am Kommando ändern muß... (Ersetzung von '-lameopts abr:br=128:mode=0' durch '-lameopts cbr:br=128:mode=0' produziert bei mir eine Aufnahme komplett ohne Ton). --> Weißt Du, wie der Aufruf korrekt lauten muß?
 

taki

Advanced Hacker
Wenn ich die Manpage von MEncoder richtig verstehe, hätte das funktionieren sollen. Evtl. schafft das die Hardware nicht. Das könnte man evtl. bei Sofort-Aufnahme in der Konsole sehen, wenn Du Kalva von der Konsole aus startest.

Die Manpage hat aber auch ein Beispiel für eine CBR-Anwendung, wo nicht br=, sondern preset= verwendet wird:

man:mencoder schrieb:
cbr:preset=192
Encodiere mit ABR-Preset bei erzwungener konstanter Bitrate von 172 kBit/s.

Noch mal zur Mail: Hast Du einen MTA laufen (bei SUSE wäre das i.d.R. postfix)? Hast Du in Deinen Mail-Client (KMail?) auch eine Identität für den lokalen Benutzer eingerichtet?
 
OP
G

gameboy

Hacker
Also wegen dem Thema Mail muß ich mich zunächst einmal entschuldigen, war wohl doch schon etwas spät gestern abend... :) - Ich habe gar nicht mehr daran gedacht, daß ich vor ein paar Tagen den postfix gestoppt hatte. Da meine normale eMail-Korrespondenz über einen komplett anderen Weg läuft, brauche ich den normalerweise nicht. Jetzt läuft postfix aber wieder...

Heute nacht habe ich jetzt nochmal eine geplante Movie-Test-Aufnahme mit folgenden Ergebnissen durchgeführt:
  • - Diesmal kein Abbruch, .avi-Datei hat exakt 2h Länge
  • - Ton ist vorhanden (Aufnahme erfolgte mit 'cbr' anstelle von 'abr'), aber Audio und Video haben am Ende einen Versatz von mehreren Sekunden, d.h. die Aufnahme ist leider komplett unbrauchbar
  • - Eine Mail wurde generiert, mit der ich aber nicht viel anfangen kann (siehe unten).
Hier die generierte Mail:

Date: Tue, 3 Jan 2006 02:02:01 +0100 (CET)
From: ...
To: undisclosed-recipients: ;
Subject: Output from your job 28

call failed
Um zu verstehen, was mir die Mail sagen möchte, muß ich wohl erstmal eine andere Frage stellen: Warum werden eigentlich immer zwei at-Jobs erzeugt, wenn man eine Movie-Aufnahme plant? Wenn ich also z.B. (wie letzte nacht) eine Aufnahme mit Startzeit 01:59 Uhr plane, dann zeigt mir 'at -l' anschließend zwei Jobs, einen um 01:59 Uhr und einen weiteren um 02:02 Uhr. Wofür der zweite Job gut ist, habe ich bisher noch nicht herausgefunden (at -c <jobid> zeigt mir 'dcop --user td --all-sessions kalva DCOP_kalva DcopMovieManagerRead'), auf jeden Fall wurde bei der Testaufnahme letzte nacht nur für den zweiten Job die obige Mail generiert.

Was das Thema Abbruch der Aufnahme angeht, so werde ich wohl weitere Tests machen müssen, weil das Problem heute nacht nicht aufgetreten ist. Das Thema Aufnahme mit konstanter Bitrate scheint sich dagegen so darzustellen, daß es schlicht und ergreifend nicht zufriedenstellend funktioniert - auch wenn für mich nicht nachvollziehbar ist, woran das liegt.

Bei meinen ersten Gehversuchen mit TV-Aufnahmen unter Windows (damals mit VirtualDub) war es übrigens so, daß der Audio-Teil mit Rücksicht auf die Systemressourcen zunächst unkomprimiert gespeichert wurde. Erst nachträglich (d.h. nach Abschluß der Aufnahme) wurde bei der resultierenden .avi-Datei dann der Audio-Track nach MP3 konvertiert. Eventuell wäre eine solche Vorgehensweise (sofern mit MEncoder möglich) für mich auch noch überlegenswert, da mein System (Athlon XP 3200+, 1 GB RAM, SUSE 9.3) während der Aufnahme mit dem Qualitätsprofil 'PAL_4_3_576x432' so stark ausgelastet ist, daß es für andere Aufgaben praktisch völlig blockiert ist...

Nochmals vielen Dank für Deine Unterstützung taki!
 

taki

Advanced Hacker
Der zweite at-Job soll dafür sorgen, dass die Aufnahme aus dem Spielfilmmanager in einem möglicherweise noch laufenden Kalva-Fenster verschwindet (Kalva wird über die DCOP-Schnittstelle aufgerufen, um die Liste neu einzulesen).

Code:
dcop --user td --all-sessions kalva DCOP_kalva DcopMovieManagerRead

Wenn Kalva zu diesem Zeitpunkt nicht läuft, mailt der Atd eine Fehlermeldung, die man getrost ignorieren kann.

Ich denke nicht, dass es hilft, den Ton unkomprimiert aufzunehmen. Es fallen enorm viel mehr Daten an, die alle auf die Festplatte geschrieben werden müssen. Ich muss aber gestehen, dass ich dazu keine Erfahrungswerte aufweisen kann.

Mein Rechner müsste etwas schwächer sein als Deiner ( 2,6 GHz P IV im Aldi-Rechner von März 2003, seit Ende Dezember auch 1G RAM). Ich nehme i.d.R. mit einem der Profile auf, die eine Auflösung von 576x720 ausgeben und hatte dabei bisher nur selten Probleme mit Audio/Bild-Synchronisation, für die es dann immer auch einen Grund gab: Manchmal vergesse ich, dass gerade eine Aufnahme läuft und gehe online (ist wahrscheinlich die Firewall, die dabei die Ressourcen frisst?) oder kompiliere etwas. Dann kann ich die Aufnahme auch wegschmeissen.

Jeder Prozess mit hoher IO-Last ist da tödlich. Dazu zählen übrigens auch gelegentlich gestartete Systemskripte wie updatedb (für die locate-Datenbank). Was mir auch schon mal eine Aufnahme zerstört hat ist ein rechenintensiver Bildschirmschoner. Je weniger während der Aufnahme läuft, desto besser.

Wichtig ist immer auch ein schneller Zugriff auf die Festplatte (DMA ist eingeschaltet, meine Platte hat 7200 Upm).
 

mca

Hacker
moin taki,
ich möchte auf den vorschlag von gameboy eingehen, den ton im nachhinein zu komprimieren. auch ich habe probleme mit dem audio-versatz, einfach weil ich während der aufnahme nicht die maus zur seite legen will, ich will halt weiterarbeiten am pc. am ende ist da fast immer ein kleiner a/v-versatz, weil "frames gedropped". festplattenplatz ist doch heutzutage kein problem mehr. 10-20GB freien platz findet man doch eigentlich auf jedem rechner, oder?
ich benutze übrigens auch manchmal noch dein kalva perl-script, das leider nicht mehr auf deiner seite zum download steht :wink:
grüsse mca (hassan)
 
OP
G

gameboy

Hacker
Habe das mit der Aufnahme von unkomprimiertem Ton inzwischen mal ausprobiert (-oac copy) und festgestellt, daß es in Bezug auf die CPU-Last keine spürbare Verbesserung bringt.

Dafür habe ich einen anderen Parameter gefunden, der ein paar Prozent Rechenleistung einspart: In Kalva unter Settings --> Video Format --> Other --> mbd habe ich den Wert von 2 auf 0 geändert. Eine erste 45-minütige Test-Aufnahme mit konstanter Audio-Bitrate war erfolgreich, nennenswerte Einbußen bei der Bildqualität konnte ich dabei nicht ausmachen. Heute abend werde ich mal versuchen, auf diese Weise einen 2-stündigen Film aufzunehmen... (Fortsetzung folgt)
 
OP
G

gameboy

Hacker
OK, ich glaube, wir können das Thema jetzt abschließen:

Die Aufnahme-Abbrüche sind zuletzt nicht mehr aufgetreten, so daß ich dieses Problem (zunächst) als erledigt ansehe.

Das Aufnehmen mit konstanter Audio-Bitrate funktioniert inzwischen auch perfekt. Der Schlüssel dazu war wohl die Reduzierung der CPU-Last durch diverse Änderungen am Quality-Profile (Capture-Auflösung geändert auf 640x480, etc.) . Inzwischen habe ich hier Einstellungen gefunden, die bei für mich akzeptabler Bildqualität während der Aufnahme so wenig Last ziehen, daß ich nebenher weiter am Rechner arbeiten kann.

Dazu habe ich zwei Test-Aufnahmen durchgeführt, bei denen ich jeweils versucht habe, den Rechner nebenbei noch durch andere Tasks zu belasten:

Test 1:
- auf der Konsole: apt-get update
- wildes Rumklicken/Fenster wechseln
- Thunderbird gestartet
- OpenOffice-Writer gestartet
- Synaptic gestartet
- im Firefox eine Gruppe mit 9 Tabs gleichzeitig aufgerufen/geladen

Test 2:
- Film (DivX, super Qualität/DVD-Rip) abgespielt mit MPlayer (File auf anderem Rechner/Windows-Share)
- MP3 abgespielt mit XMMS (File auf anderem Rechner/Windows-Share)
- Download Knoppix-DVD mit Firefox
- Konsole: cd /usr; find . -name ".*e.*"

Beim zweiten Versuch war die CPU-Idle-Anzeige von KSensors permanent auf 0 Prozent.

Das Resultat war bei beiden Tests eine brauchbare Aufnahme ohne sichtbare Beeinträchtigungen durch die zusätzliche CPU-Belastung. Es wurden jeweils keine Frames gedropped. Audio und Video waren auch am Ende der Aufnahme noch synchron, soweit ich das bei einer schnellen Test-Ansicht der Aufnahme erkennen konnte.

@taki: Falls Du es für sinnvoll hältst, würde ich das Qualitätsprofil zur Verfügung stellen/hochladen. - Wie funktioniert das?

Viele Grüße,
gameboy.
 

taki

Advanced Hacker
gameboy schrieb:
@taki: Falls Du es für sinnvoll hältst, würde ich das Qualitätsprofil zur Verfügung stellen/hochladen. - Wie funktioniert das?

Bei www.kde-files.org einen Account eintragen

http://www.kde-files.org/usermanager/new.php

Einen neuen Eintrag erzeugen

http://www.kde-files.org/content/add.php

Anmelden, Formular ausfüllen und Typ aus der Liste auswählen ("Kalva hardware profile" fürs Hardwareprofil, "Kalva quality profile" fürs Qualitätsprofil und "Kalva Channels" für die Kanalliste).
Das Web-Interface ist ziemlich selbsterklärend.

Bei "Content File 1" klickst Du auf "Durchsuchen". Wenn Du Dir das Suchen im Dateidialog sparen möchtest, kannst Du im Einstellungen-Dialog von Kalva den vollständigen Pfad zum Profil aus dem Anzeigefeld markieren und über die Zwischenablage in den Dateidialog kopieren. Dann brauchst Du nicht lange nach dem Profil zu suchen.
 
OP
G

gameboy

Hacker
Hi again.

@taki: Es hat ein bißchen gedauert (war ein paar Tage krank), aber nun habe ich das Quality-Profile (PAL_4_3_624x464) zur Verfügung gestellt. Wenn Du Lust hast, kannst Du es ja mal testen und mir Deine Meinung dazu mitteilen...

Viele Grüße,
gameboy.
 

taki

Advanced Hacker
Habs gerade installiert :) und werde es demnächst mal testen, hört sich sehr vielversprechend an :).

Mir ist der sehr hohe Wert von vratetol aufgefallen. Ich vermute mal, dass dieser Wert wesentlich dazu beiträgt, dass die Aufnahme resistenter gegen konkurierende Prozesse wird. Leider kann ich mit der Beschreibung in der Manpage nicht so viel anfangen.

man:mencoder schrieb:
vratetol=<Wert>
ungefähre Dateigrößentoleranz in kBit. Werte im Bereich 1000-100000 sind vernünftig. (Warnung: 1kBit = 1000 Bits) (Standard: 8000)
ANMERKUNG: vratetol sollte im zweiten Durchlauf nicht zu groß sein, es kann sonst in Verbindung mit vrc_(min|max)rate zu Problemen kommen.
 
OP
G

gameboy

Hacker
taki schrieb:
Mir ist der sehr hohe Wert von vratetol aufgefallen.
Huch? - Daran habe ich eigentlich gar nichts geändert...

Mein Profil ist wie folgt entstanden: Ausgangspunkt war das Profil "PAL_4_3_576x432". Bei der Verwendung dieses Profils konnte ich während der Aufnahme nicht am Rechner weiterarbeiten, ohne das Resultat unbrauchbar zu machen. Daran habe ich dann nur drei Änderungen vorgenommen, um den Ressourcenverbrauch während der Aufnahme zu reduzieren:

- capture resolution reduziert (Überlegung: 1/4 weniger Daten durch geringere Auflösung --> weniger Encoding-Aufwand)
- scale (post) deaktiviert (Aufwand für Umrechnen/Eindampfen der Auflösung entfällt)
- mbd auf 0 gesetzt (die Hilfe sagt ja bereits, daß das Ressourcen spart)

Das war's auch schon. Habe gerade zur Überprüfung nochmal die beiden Textdateien verglichen: Die restlichen Einstellungen sind gegenüber dem oben genannten Profil unverändert geblieben.
 
Oben