Posts mit dem Label ffv1 werden angezeigt. Alle Posts anzeigen
Posts mit dem Label ffv1 werden angezeigt. Alle Posts anzeigen

Dienstag, 18. Februar 2020

format zoo for videos - a bad idea in digital preservation

Background 


In an article on https://axfelix.github.io/ffv1, reasons are given not to apply the existing normalization of born-digital videos to FFV1, but to convert to lossy codecs instead. Elsewhere I even heard that normalization is not applied at all because it requires so many resources.


Why is normalization a good idea after all?


Normalization ensures that a manageable set of file formats remains from the huge format zoo, which can be handled well in the future. Normalization therefore reduces the organizational complexity above all.

And why should you use Matroska/FFV1?


FFV1 has the disadvantage of imposing higher storage requirements on its users, but in my opinion, the following points outweigh it:

  • FFV1 is much less complex than h264 (read "reduced technical complexity")
  • FFV1 (like other lossless codecs) allows automatic format migration (see also RAWcooked) — this reduces organizational complexity
  • FFV1 is freely available, widely used, well documented and standardized


The point that FFV1 is also more resistant to bit rot is just the icing on the cake.


Summary


Incidentally, personnel cost is the cost driver in digital preservation, as opposed to the pure storage cost.

Hence, the ultimate question is: how expensive is storage capacity in relation to the reduced technical and organizational complexity?

Mittwoch, 6. September 2017

Hinweis auf interessantes Interview zu FFV1

Ein äußerst interessantes Interview von Jürgen Keiper mit Peter Bubestinger zur Entstehung und Motivation von Matroska/FFV1 als langzeitarchivfähiges Datenformat für audiovisuelle Medien.

Es ist besonders interessant für Archivare, die wissen wollen, warum FFV1/Matroska ihre Probleme lösen kann. Peter schafft es Sachverhalte einfach und anschaulich zu erklären und kommt (fast) ohne technisches Vokabular aus.

Prädikat: Sehenswert!

Hier der Link zum Video:

https://www.memento-movie.de/2017/08/die-geschichte-eines-codecs-ffv1-in-der-archivwelt/

Samstag, 29. April 2017

FFV1 - some compression results

In a pilot we got some retrodigitized films and videos in Matroska/FFV1 format. In the following table I summarized the results:


n/a
film/video12345
description8mm, positive, b/w8mm, positiv, b/w16mm, positive, b/w35mm, combined, color35mm, combined, color
width25002500204840964096
height15241524152034602976
bits per pixel4848484848
pxfmtgbrp16legbrp16legbrp16legbrp16legbrp16le
duration in s121211,4592,52,5
fps2424242424
frames2882882756060
original size658368000065836800005136682844,1651019776004388290560
compressed size38619438803790690517368077971939084753443576745774
compression ratio1,7041,7361,3951,3051,226
(DPX size)65841592326584159232513684160051020774404388390400
(h264 lossless)n/a n/a n/a n/a n/a
(h265 lossless)35734203093559442475275650424730150538222992764833
(jp2k lossless)45898863414534014321373255553938696659163514687046
with audionnnyn


n/a
film/video678910
description35mm, combined, colorvhs, colorbetacam, colorbetacam, colorDigi-beta, color
width4096720720720720
height3200576576576576
bits per pixel4820202020
pxfmtgbrp16leyuv422p10leyuv422p10leyuv422p10leyuv422p10le
duration in s1088,042280280280280
fps2425252525
frames261137000700070007000
original size20536105107467257600000725760000072576000007257600000
compressed size15754151756113565437155383850093434493722804451325952
compression ratio1,3032,0351,8902,1041,630
(DPX size)
2053653333632
17472217728174298880001742988800017429888000
(h264 lossless)
n/a
n/a n/a n/a n/a
(h265 lossless)12480312926343659828688377252225734427392594323623225
(jp2k lossless)15171175605753300899483347043417731507270814022908822
with audionyyyy

All files are encoded with FFV1v3 with slices, slice-crc, GOP=1. If audio exists, it is (lin. PCM 48kHz, 16bit) included in compression-size, but not in original size, because original size is calculated by width*height*pits_per_pixel*frames and compression-size is equivalent to filesize. The count of frames is calculated with the duration value of the MKV-files. The files 1 to 5, and 7-10 are first parts of the movies (each 4GB splits).

Hint: Once the project is completed, rights must be clarified. If possible, I will publish the sources.

Update 2017-06-09

  • added file size for DPX after using "ffmpeg -i input.mkv DPX/frame_%06d.dpx"
  • added file size for h264 after using "ffmpeg -i input.mkv -c:v libx264 -g 1 -qp 0 -crf 0 output.mkv" (RGB without lossy conversion to YUV not supported yet)
  • added file size for h265 after using "ffmpeg -i input.mkv -c:v libx265 -preset veryslow -x265-params lossless=1 output.mkv"
  • added file size for openjpeg2000 after using "ffmpeg -i input.mkv -c:v libopenjpeg output.mkv
Update 2017-06-29

  • added sizes for film no 6
  • in general, the processing time of h265 and jp2k is one magnitude greater than for ffv1

Interpretation


The files 1-3 are all originally b/w. It seems to be that the codec does not decorrelate the color channels. Also the material 1-6 is retrodigitized from film and are noisy. The file 1 is very special. In decoding the FFV1 produces a very high load on the CPU (eight cores at 100%). The most decoding time is spent in method get_rac(). The original film has the highest noise level in contrast to the other files.

I think the compression-ratio difference between video- and film files comes from the different pixel format. A ratio between 1,5 - 2 was expected, but 1,3 is a surprise.

Update 2017-06-09

The reason for high CPU load was, that the digitization service provider has created a file with a framerate of 1000 fps, but the scanner has provided 24 or 25 fps. Therefore 42-40 equal frames  was encoded on block.



Montag, 2. Mai 2016

Problemfälle TIFF und Wünsche an TI-A Initiative

Problemfälle TIFF


Auf der Tagung "Archivierung von Unterlagen aus digitalen Systemen" (AUdS), die diesmal an der FH Potsdam stattfand, wurde ich gebeten einen Vortrag zu den bisher in meiner Arbeit gefundenen, problematischen TIFFs zu halten.

Die Folien sind mittlerweile beim Staatsarchiv St. Gallen zu finden (eigentlich sollte an der FH Potsdam auch eine Vortragsaufzeichnung verfügbar sein, konnte ich aber leider noch nicht finden):

http://www.staatsarchiv.sg.ch/home/auds/20/_jcr_content/Par/downloadlist_1/DownloadListPar/download_3.ocFile/ROMEYKE_Folien_AUdS_2016.pdf 

Ich verzichte hier auf eine nochmalige Auflistung aller Problemfälle und verweise auf obige Folien. Dennoch möchte ich auf ein paar Probleme eingehen:

Die meisten Probleme waren auf fehlerhafte Softwareimplementierungen zurückzuführen. Insbesondere das Tag DateTime (306) war eine Quell stetiger Freude.
Laut Spezifikation soll dort ein String der Form YYYY:MM:DD hh:mm:ss\0
stehen. Stattdessen wurde localtime() verwendet, das Datum in dt. Angabe geschrieben oder falsche Trennzeichen benutzt.

Ein anderes Problem mit TIFF sind manchmal vorhandene, sich widersprechende Informationen. Ein Problem bei der Farbkodierung ist in den Folien genannt. Ein anderes besteht in den privaten TIFF-Tags für EXIF-- und ICC-Daten.

Zwar steht in der Spezifikation, daß der Bereich der privaten Tags im Zweifel nicht ausgewertet werden solle, in der  Praxis ist dies aber oft nicht gelöst.So hatte zB. Gimp (aber auch andere Programme, wie Photoshop) ein TIFF stets im tiefsten Schwarz angezeigt. Ursache war ein verkorkstes ICC-Profil, wurde dies gelöscht, wurde der Bildinhalt sichtbar.

Ausblick in Bezug auf die TI-A Initiative


Seit über einem Jahr sind die Macher des im Rahmen von Preforma von der EU geförderten TIFF-Validators "DPFManager" unterwegs und mobilisieren für eine Archiv-TIFF Spezifikation. Unter http://www.ti-a.org kann man sich an der Diskussion beteiligen. Ich hätte mir einen etwas offeneren Beteiligungsprozess gewünscht, das ist aber eine andere Baustelle.

Da im Rahmen der TI-A Initiative mit ein paar Unzulänglichkeiten von TIFF aufgeräumt werden soll, würde ich mir ff. Punkte wünschen, die beibehalten bzw. beachtet werden sollten:

  1. Die Reihenfolge der Tags, als auch die Offsets an gerade Adressen tragen erheblich zur Robustheit von TIFF bei. Diese Eigenschaften sollten nicht, wie von einigen Beitragenden vorgeschlagen, aufgeweicht werden. Im Gegenteil, diese "Einschränkungen" ermöglichen es, durch Bitfehler zerstörte TIFFs leichter zu reparieren.
  2. Es muss ausgeschlossen sein, daß PhotometricInterpretation (262) auf 0 oder 1 gesetzt ist und das Tag Colormap (320) vorhanden ist. Ev. sollte über eine Vorrangsregelung bei Widersprüchen nachgedacht werden.
  3. Ein weiterer Punkt, der vor allem in sogenannten Wang-TIFFs auftrat sollte klar in Spezifikation geklärt sein: Bisher ist es so, daß es zu jedem in einem IFD vorkommenden Tag ua. ein count-Feld gibt, welches die Anzahl der Werte des entsprechenden Typs des Tags bestimmt. Bei Wang-TIFFs existierten Tags, aber das count-Feld wurde auf 0 gesetzt. Ich würde mir wünschen, daß hier die Regelung greift, wenn Tag vorhanden, dann count > 0.

Als Vorschlag für die privaten Tags hätte ich noch, daß bei der Vergabe von privaten Tags ab zwei zusammengehörenden Arten diese nur noch über ein zugehöriges privates IFD-Tag referenziert werden dürfen. Es ist eine Unsitte, daß in TIFFs private Tags zB. DateTimeOriginal (36867) von Exif im IFD0 direkt referenziert werden. Zum einen macht dies die Extraktion und Validierung aufwendiger, zum anderen verkleinert dies den Adressraum der für private Tags genutzt werden kann. Wenn Exif-Daten ausschliesslich über das Exif-IFD (34665) referenziert wird, ist das sauberer.

Als letzten Wunsch erbitte ich mir, daß (mit Zucker drauf), keine Datenkompression erlaubt wird. Andernfalls sollten wir uns lieber mehr Zeit nehmen und dann TI-A so entwickeln, daß es wie FFV1 (Version 3) Mechanismen mitbringt, die Kompression und Robustheit gleichermaßen erlauben (zB. crc32 gesicherte Slices und Header).

Das waren meine 2¢   ;)

PS.: Wer mithelfen mag, den von uns entwickelten freien TIFF Validator "checkit_tiff" zu verbessern, hier der Link: https://github.com/SLUB-digitalpreservation/checkit_tiff

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.

    Dienstag, 9. Dezember 2014

    Verlustfreie Videocodecs in der Langzeitarchivierung – Ein Vergleich

    Verlustfreie Videocodecs haben den Charme, daß man zum einen sein Videomaterial für die digitale Langzeitarchivierung normalisieren kann und zum anderen, daß bei Formatmigrationen eine automatische, pixelgenaue Inhaltsprüfung die korrekte Migration vereinfacht.

    Hinzu kommt, daß sich das digitale Videomaterial bei den Formatwandlungen nicht weiter verschlechtert.

    Für den Test habe ich den Trailer zum Film "Sentinel" verwendet. Der Film von der Blender Foundation ist frei unter Creative Commons erhältlich und ermöglicht daher jedem die Testergebnisse zu verifizieren und an eigene Tests anzupassen.

    Der Trailer war zum Zeitpunkt des Testes nur als DivX-HD verfügbar, so daß die y-Auflösungen von 1080 Pixeln mit Vorsicht zu genießen sind, da das Ursprungsmaterial dabei hochskaliert wurde.

    Im folgenden die Ergebnisse (auf Megabytes gerundet):


    Codec Auflösung



    1080 720 576
    Orig DivX_Plus 27


    FFV1 v1
    402 228 160
    FFV1 v3 2pass 333 198 139
    FFV1 v3
    360 215 153
    h264lossless 432 240 168
    h264
    20 11 7,3
    mjp2000
    463 261 183
    mpeg2
    24 11 7,2

    MPeg2 läuft außer Konkurrenz mit, da nach der Kodierung deutliche Artefakte sichtbar sind.

    Hier nochmal die Werte normiert auf den jeweils besten Kompressionswert:


    Codec Auflösung



    1080 720 576
    Orig DivX_Plus 27


    FFV1 v1
    20 21 22
    FFV1 v3 2pass 17 18 19
    FFV1 v3
    18 20 21
    h264lossless 22 22 23
    h264
    1 1 1
    mjp2000
    23 24 25
    mpeg2
    1 1 1

    Wie man erkennt, brauchen die Lossless Codecs im Schnitt die 20-fache Speichermenge, wobei sich das Verhältnis bessert, je höher die Auflösung des Quellmaterials wird. Im Test ist außerdem aufgefallen, daß Motion Jpeg2000 (mjp2000) mit Abstand die höchste Rechenzeit an den Tag legte, während FFV1 das Videomaterial nahezu in Echtzeit kodierte.

    In meinen Augen sollten sich die Langzeitarchive bemühen, die Kodierungseffizienz der lossless-Codecs durch Förderung fähiger Entwickler zu steigern. Wenn man zB. FFV1 v1 mit FFV1 v3 vergleicht, so wurde die Kodierungseffizienz um nahezu 10% gesteigert.

    Trotz des um ca. Faktor 20 höheren Speicherplatzverbrauchs von lossless Codecs gegenüber verlustbehafteten Verfahren würde ich erstere bevorzugen. Auch wenn noch Tests notwendig sind, die die Bitfehleranfälligkeit der verschiedenen Codecs miteinander vergleichen, so kann man festhalten, daß zumindest die Entwickler von FFV1 sich bereits Gedanken dazu gemacht haben, wie man die Auswirkung dieser Fehler begrenzen kann

    Script


    Das Script für den Test ist relativ schnell geschrieben:

    #!/bin/bash
    # tests some codecs and reduced screen sizes
    # orig is: Sintel_Trailer.1080p.DivX_Plus_HD.mkv
    # from  http://download.blender.org/durian/trailer/
    orig=Sintel_Trailer.1080p.DivX_Plus_HD.mkv
    for scanlines in 576 720 1080; do
     call="ffmpeg -i $orig -acodec copy -vf scale=-1:$scanlines -y "
     codec=ffv1; variant=standard; $call -vcodec $codec Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     codec=ffv1; variant=v3slices; $call -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     # ffmpeg -i  -threads 8 -an -vcodec ffv1 -coder 1 -context 1 -g 1 -level 3 -slices 24 -slicecrc 1 -pass 1 -passlogfile my_passlog 
     #ffmpeg -i  -threads 8 -acodec copy -vcodec ffv1 -coder 1 -context 1 -g 1 -level 3 -slices 24 -slicecrc 1 -pass 2 -passlogfile my_passlog 
     # 
     codec=ffv1; variant=v3slices2pass; $call -an -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 -pass 1 -passlogfile log.${scanlines}.${codec}.${variant}.log Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     rm -f Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     codec=ffv1; variant=v3slices2pass; $call -threads 8 -g 1 -c:v $codec -level 3 -coder 1 -context 1 -slices 16 -slicecrc 1 -pass 2 -passlogfile log.${scanlines}.${codec}.${variant}.log Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     codec=mpeg2video; variant=standard; $call -vcodec $codec Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     codec=dirac; variant=standard; $call -threads 8 -g 1 -c:v libschroedinger -qscale:v 0 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     codec=h264lossless; variant=standard; $call -threads 8 -g 1 -c:v libx264 -preset fast -qp 0 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     codec=jpeg2000; variant=standard; $call -threads 8 -g 1 -c:v libopenjpeg Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
     codec=h264lossy; variant=standard; $call -threads 8 -c:v libx264 Sintel_Trailer.${scanlines}.${codec}.${variant}.mkv
    done
    rm -f log.*.log
    
    

    Weiteres


    * Infos zu Vor- und Nachteilen von FFV1 und Motion JPeg2000: https://groups.google.com/forum/#!topic/archivematica/HulV96gJ0go
    * Evaluation von FFV1: http://web.archiveorange.com/archive/v/4q4BhyAYa6Fk89AqurTY
    * Weiterer Vergleich von FFV1: http://download.das-werkstatt.com/pb/mthk/ffv1_stats/latest/ffv1_sizediff-mthk-yuv.html