Freitag, 31. Juli 2015

Konvertierung Videos nach Matroska-Container mit FFV1 v3 Codec und WAV PCM



Als kleines Snippet:
ffmpeg -i inputvideo.webm -c:v ffv1 -level 3 -g 1 -coder 1 -context 1 -slices 16 -slicecrc 1 -report -c:a pcm_s32le -y outputvideo.mkv
Die Optionen kurz erklärt:
  • -i inputvideo.webm  – Lese von Video inputvideo.webm
  • -c:v ffv1– Verwende Videocodec FFV1
  • -level 3 – von diesem die Variante 3 (besonders für LZA geeignete Variante)
  • -g 1– Verwende GOP von 1 (group of pictures)
  • -coder 1– Verwende range-coder (ist 'ne Art arithmetischer Komprimierung)
  • -context 1 – Verwende größeren Kontext für Symbolkodierung
  • -slices 16 – Verwende 16 Slices, dh. jeder Frame wird in 16 Scheiben geschnitten, die je in einem Thread kodiert werden können
  • -slicecrc 1 – Füge CRC-Prüfsummen zu jedem Slice hinzu
  • -report – Schreibe alle Infos in ein Report-file
  • -c:a pcm_s32le – Verwende Audiocodec Wav-PCM signed 32bit little endian
  • -y – überschreibe vorhandene Datei ohne Rückfrage
  • outputvideo.mkv – Schreibe Video outputvideo.mkv
Weitere Infos zu den Parametern von FFV1 unter https://trac.ffmpeg.org/wiki/Encode/FFV1

 

Offene Fragen (Update 2015-08-03)

Nicht unterstütztes pcm-Format?

pcm_u24le wird von ffmpeg mit "[matroska @ 0x1a0adc0] No wav codec tag found for codec pcm_u32le" quittiert. Warum?

Matroska unterstützt diesen Codec nicht.

    Bedeutung der verschiedenen PCM-Subformate?

    Ist pcm_s24le Wave mit linear PCM oder linear differential PCM?

    Nach Antworten auf Nachfrage auf der FFMPEG-Mailingliste sieht es so aus, daß alle Formate linear PCM sind (nur in unterschiedlichen Codec Ausprägungen, bei signed int ist "Stille" definiert als Wert 0, bei unsigned int liegt "Stille" als Wert in der Hälfte des Wertebereiches).

    Von der Verwendung von float-Varianten wird abgeraten, da die bitgenaue Rekonstruktion bei unterschiedlichen Architekturen nicht sichergestellt ist.

    Montag, 20. Juli 2015

    Konfigurierbarer TIFF-Validator in Arbeit…

    Die bestehenden TIFF - Validatoren/Extraktoren, wie JHove und Co. sind zwar ganz nett, allerdings ist es schwierig unsere Policy abzufragen, sprich, welche Tags mit welchen Werten erlauben wir, welche sind Pflicht.

    Dies war die Geburtsstunde für einen konfigurierbaren Validator. Die Regeln werden in einer einfachen Abfragesprache formuliert, die der Validator übersetzt und danach das TIFF entsprechend auswertet.

    Es liegt noch etliche Arbeit vor uns, und einiges an Funktionalität fehlt noch. Dennoch möchten wir Euch auf das Tool hinweisen, damit ihr uns vlt. schon frühzeitig Rückmeldungen geben könnt.

    Den Quellcode gibt es hier: https://github.com/SLUB-digitalpreservation/fixit_tiff/tree/master/checkit, der Code steht unter der gleichen Lizenz, wie der der LibTIFF (sh. http://www.libtiff.org/)

    Hier ein Beispiel für eine einfache Abfrage:

    # tag; required; values
    #
    # works as whitelist
    # * tag: any tag number in TIFF
    # * required: mandatory | optional | depends( $tag.$value ) 
    # * values: range($start, $end) | logical_or( $a, …) | only($a) |any
    
    # This defines a sample config for baseline tiffs
    # Remember, because it works as whitelist for each required tag we need an
    # entry here
    
    #####
    # Required Baseline Tags
    #####
    
    # 256 0100 ImageWidth The number of columns in the image, i.e., the number of pixels per row.
    256; mandatory; range(1, 4294967295)
    
    # 257 0101 ImageLength The number of rows of pixels in the image.
    257; mandatory; range(1, 4294967295)
    
    # 258 0102 BitsPerSample Number of bits per component.
    ##########################258; mandatory; logical_or(8,16)
    # Bitonal is optional, grey & RGB is mandatory. If 262 AND 258 exist, then the values need to be in the specified range.
    258; depends(262.2); only(8,8,8)
    258; depends(258.any); logical_or(4, 8)
    
    # 259 0103 Compression Compression scheme used on the image data 
    ### (1 means no compression)
    259; mandatory; only(1)
    
    # 262 0106 PhotometricInterpretation The color space of the image data.
    ### 2 means RGB, 0 and 1 means bilevel or grayscale, 0 is unusual, 3 is Palette Color (FORBIDDEN), 4 is Transparency Mask (FORBIDDEN)
    262; mandatory; range(0, 2)
    
    # 273 0111 StripOffsets For each strip, the byte offset of that strip.
    273; mandatory; any
    
    # 277 0115 SamplesPerPixel The number of components per pixel.
    ### if RGB then 3 else 1
    ### Even though Baseline TIFF allows for SamplesPerPixel>3, we do NOT allow this for long term archival.
    277; depends(262.2); only(3)
    277; depends(262.1); only(1)
    277; depends(262.0); only(1)
    
    # 278 0116 RowsPerStrip The number of rows per strip.
    278; mandatory; range(1, 4294967295)
    
    # 279 0117 StripByteCounts For each strip, the number of bytes in the strip after compression.
    279; mandatory; range(1, 4294967295)
    
    # 282 011A XResolution The number of pixels per ResolutionUnit in the ImageWidth direction.
    282; mandatory; range(300, 1200)
    
    # 283 011B YResolution The number of pixels per ResolutionUnit in the ImageLength direction.
    283; mandatory; range(300, 1200)
    
    # 296 0128 ResolutionUnit The unit of measurement for XResolution and YResolution. 1 = No absolute unit of measurement. 2 = Inch. 3 = Centimeter. Default: 2
    296; mandatory; only(2)
    
    

    Sonntag, 31. Mai 2015

    Digital(isiert)e Dokumente sind lebende Daten – Nachlese zum 104. Bibliothekartag


    Quelle: openclipart, public domain

    Digital ist anders


    Auf dem Bibliothekartag in Nürnberg blieb mir ein Vortrag besonders im Gedächtnis, da er den Finger in die Wunde legte. Klaus Kempf von der Bayrischen Staatsbibliothek München stellte in seinem Vortrag "Data Curation oder (Retro)Digitalisierung ist mehr als die Produktion von Daten" die berechtigte Frage "Jetzt haben wir alles digitalisiert – und dann?".

    Der Unterschied zwischen alten Büchern, die in den Regalen von Bibliotheken die Zeiten verschlummern und digital(isiert)en Dokumenten zeigt sich in zwei wesentlichen Punkten:

    1. digitale Objekte verschwinden schnell und dann vollständig, während Bücher nur ganz, ganz langsam zu Staub zerfallen
    2. digitale Objekte erlauben einen unvorstellbaren Mehrwert durch ihre digitale und damit verknüpfbare und reinterpretierbare Identität

    Digital ist billiger


    Durch die Loslösung des Inhalts vom Medium können Bücher in völlig neue Kontexte gesetzt werden. Wurde im ersten Schritt das Buch digitalisiert, sprich als Bilddatei zugänglich gemacht, so erreichte man eine Schonung des Originals durch die beliebig oft und in unveränderter Qualität ermöglichte digitale Kopie. 

    Auch wenn die Digitalisierung und die damit verbundenen Aufwände der sicheren Speicherung anfangs kostenintensiver als die klassische Bestandsbewahrung von totem Baum ist, Kempf erwähnte Kostenfaktor von 1:8, so zeigen die Nutzungszahlen der Digitalisate, daß diese Kosten mehr als gerechtfertigt sind. Denn vorher war der Zugriff auf das gedruckte Exemplar schlicht nicht zu stemmen, von den Beschädigungen des Originals bei derart hohen Zugriffen nicht zu reden.

    Wenn 2014 zB. knapp 3 Millionen Zugriffe auf die Digitalen Sammlungen der SLUB Dresden gezählt werden zeigt dies, wie sich der Zugriff auf die Digitalisate mittlerweile etabliert hat. Für Wissenschaftler und andere Interessierte ist es nicht mehr notwendig sich die Mühe zu machen monatelang in den Lesesälen von Archiven und Bibliotheken herumzutreiben. Sie können bequem über Internet recherchieren und direkt oder über Portale, wie die der Deutschen Digitalen Bibliothek oder Europeana auf zusammengehörige aber in Europa verstreute historische Materialien zugreifen.

    Auch dies ein Vorteil, den Bibliotheken auf ihre Seite der Waagschale packen sollten.

    Digital wird immer besser


    Wie Kempf in seinem Vortrag gut dargestellt hat, sind digitale Medien als lebende Dokumente zu behandeln. Entweder man pflegt sie – oder sie sterben und dann dauerhaft und ohne Spuren zu hinterlassen.

    Der Bereich der digitalen Langzeitarchivierung versucht, diese Daten so zu sichern, daß sie auf lange Sicht verfügbar gehalten werden können. Aber dies ist nur der eine Aspekt, vergleichbar mit modernen medizinischen Geräten, die zwar in der Lage sind, den menschlichen Körper warm zu halten und vor dem Verfall zu bewahren – nicht aber das Leben lebenswert machen (im eigentlichen Sinn)

    Doch digitalen Dokumenten wohnt ein "Mehr" inne. Wie oben erwähnt, war der erste Schritt die Digitalisierung. Doch welche neuen Möglichkeiten ergeben sich, wenn man diese Scans weiter veredelt? Kommt anfangs eine OCR-Variante hinzu, kann man die Digitalisate nun volltext-durchsuchbar gestalten. Ist der Volltext vorhanden, kann man diesen Tiefenerschliessen. Aus dem Buch, welches über Jahrhunderte im Magazin schlummerte, wurde nun ein Bestseller, der die Geheimnisse seiner Zeit enthüllt. Von einem Buch zum anderen über die dort jeweils verknüpften Akteure, Orte oder Zeiten springen, oder breite statistische Untersuchungen über die Entwicklung der Sprache in bestimmten Regionen sind jetzt ganz neue Sachverhalte untersuchbar.

    Data curation, aktives Managment des digitalen Bestandes und das Bewusstsein daß es sich um lebende Dokumente handelt, ist nach Kempf nunmehr vorrangige Aufgabe von (wissenschaftlichen) Bibliotheken.

    Digital erfordert Qualität


    Für mich bleibt daher als Fazit, es geht bei Digitalisierung nicht um Quantität, sondern um Qualität. Es nützt nichts *nur* zu Digitalisieren. Aus Digitalisierung folgt Langzeitarchivieren. Aus Langzeitarchivierung folgt Langzeitverfügbarkeit und aus Langzeitverfügbarkeit folgt Anreicherung. Und aus Anreicherung folgt Qualität. Und Qualität fängt bei der Quelle an.

    Wenn ich schlecht scanne, reicht es nicht für gute OCR. Wenn ich keine gute OCR habe, reicht es nicht für gute Volltexte. Wenn ich keine guten Volltexte habe, reicht es nicht für eine Tiefenerschliessung. Wenn ich keine gute Tiefenerschliessung habe, kann ich Dokumente nicht gut anders verknüpfen…

    Daher: Alles was wir aus der Digitalisierung bisher lernen konnten –  es gibt immer neue Nutzungsmöglichkeiten, die sich aber erst manifestieren, wenn man den Möglichkeitenraum öffnet.

    Bibliotheken sind in dem Sinne nicht mehr nur Bücherbewahrer sondern Datenveredler und sollten sich auch dazu bekennen.

    Samstag, 23. Mai 2015

    Vertrauensfrage

    Was ist Vertrauen?


    CC-SA-3.0, von Dellex, Quelle: Wikimedia
    In der Vorbereitung für einen Vortrag auf dem Bibtag2015 habe ich mich intensiv mit der Frage auseinandergesetzt, wie vertrauenswürdig unsere Technik und unsere Prozesse sind, wenn wir diesen wertvolle digital(isierte) Dokumente anvertrauen.

    Immerhin, ein kleiner Fehler und ganze Bestände können vernichtet sein. Im digitalen geht das oft schneller, unbemerkter und mit deutlich fataleren Folgen, als in der materiellen Welt. Ein versehentliches "rm -Rf /" löscht dann in Sekunden mal gleich ein ganzes Dateisystem.



    Vertrauen ist nicht wissen – und mehr als glauben


    Wenn wir unseren Prozessen vertrauen, dann, weil unsere Erfahrung gezeigt hat, daß diese auch in Krisensituationen funktionieren. Wenn wir unserer Software vertrauen, dann weil sie sich so verhält, wie wir das erwarten.

    Wenn wir anderen Personen vertrauen, dann umso mehr, je länger wir mit dem Anderen verläßlich zusammenarbeiten.

    Wenn wir Neuem begegnen, dann schöpfen wir Zutrauen und mit der Zeit mehr Vertrauen durch dessen Offenheit.

    Offene Personen, offene Prozesse und offene Technologie sind Katalysatoren Vertrauen schneller zu erreichen.

    Aufbau von Vertrauen erfolgt also durch
    • Vorhersagbarkeit
    • Verlässlichkeit
    • langjährige Erfahrung
    • Offenheit
    Im Bereich der digitalen Langzeitarchivierung spielt Vertrauen eine zentrale Rolle. Wir wollen ja gerade unsere wertvollen Dokumente für kommende Generationen nutzbar halten und sind auf vertrauenswürdige Archive angewiesen.

    Vertrauenswürdige Software

    Da ein digitales Langzeitarchiv mehrere Komponenten umfasst, müssen wir all diese Komponenten bezüglich ihrer Vertrauenseigenschaft untersuchen.

    Eine zentrale Rolle in digitalen Langzeitarchiven nimmt das Thema Software ein. Dies reicht von Betriebssystem, über Zugriffskomponenten, Datenbanken bis hin zur Steuerungssoftware (Archivsoftware) für die Realisierung der OAIS-Funktionalitäten.

    Auch hier gelten og. Punkte:

    • Verhält sich die Software konsistent?
    • Ist die Software sicher? Und tut sie, was sie soll?
    • Ist sie über die Jahre stabiler geworden?
    • Wird sie weiterentwickelt?
    • Können wir "hineinschauen"?

    Freie Software hat hier den Charme, daß sie durch ihre Offenheit ermöglicht, daß wir die Arbeitsweise besser verstehen, Fehler finden und ggf. beseitigen können.

    Doch reicht unser Blick? Ist es ausreichend auf unsere Erfahrung mit der Software zu vertrauen? Sollten wir es lieber auch mal prüfen, wenn die Software meldet, sie hätte erfolgreich etwas ins Archiv gesichert? Ist frei einsehbarer Quellcode genug?

    Nach einiger Erfahrung hier im Team, müssen wir diese Fragen mit einem klaren Nein! beantworten (auch bei Verwendung freier Software nicht, dies hat ua. auch mit dem Stichwort Komplexität zu tun).

    Es ist notwendig, über kleine Helferlein stichprobenartig nachzuprüfen, daß unsere Erwartungen an Software erfüllt sind.

    Wir haben im Laufe der Zeit einige Hilfsprogramme entwickelt, die unabhängig von der Archivsoftware Prüfungen vornehmen, zB.:

    • Hat jedes Archivpaket auch alle Dateien?
    • Sind wirklich alle Kopien identisch?
    • Funktioniert die Web-Schnittstelle nach dem Update noch wie erwartet?
    • Landen alle Archivpakete tatsächlich auf Band?
    • Wurde die Prüfsumme korrekt berechnet? Oder ist das Programm fehlerhaft?

    Vertrauenswürdige Hardware


    Auch bei der Hardware ist es sinnvoll, unabhängige Pfade und Prüfungen einzubauen.
    Wie schnell kann ein Treiberproblem Teile des Archivs gefährden? Was, wenn das Netzwerk ausfällt? Was wenn Puffer voll laufen?

    Auch hier haben wir im Laufe der Zeit Helfer gebaut und uns notiert, was wir bei der nächsten Hardwareablösung anders konzipieren würden:
    • Mindestens ein Kopienpfad über alternative Hardware (Storage)
    • Stete Mitspeicherung spezieller Monitoringdateien parallel zu den Archivpaketen um frühzeitig Fehler zu entdecken
    • Anbindung an Monitoring-Systeme
    • Prüfung von Checksummen nach jedem Kopiervorgang

    Vertrauenswürdige Archive

    Ein Archiv ist dann umso vertrauenswürdiger, wenn es sich dem Prinzip Offenheit und Peer Review (durch andere LZA-Kundige) verpflichtet fühlt.

    Die bestehenden Zertifizierungsangebote Data Seal of Approval und nestor-Siegel unterstützen dieses Prinzip, da sie über ihren Kriterienkatalog eine Offenlegung der Dokumentation über Organisation, Prozesse, Umgang mit den digitalen Objekten und Technologien des jeweiligen Archives verlangen und damit Archive vergleichbarer machen.