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

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/
Eingestellt von um Keine Kommentare:
Labels: , , , ,

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.



Eingestellt von um Keine Kommentare:
Labels: , , , , , ,

Donnerstag, 30. März 2017

Nestor - DIN - Workshop "Digitale Langzeitarchivierung", Nachlese

Gestern fand in den Räumen des DIN e.V. ein Workshop des Kompetenznetzwerkes digitale Langzeitarchivierung nestor und der DIN statt. Dies soll nur eine kleine Zusammenfassung für die Zuhausegebliebenen sein und erhebt keinen Anspruch auf ein objektives oder gar vollständiges Protokoll :)
Falls Fehler vorliegen bitten wir um eine Email mit Korrekturhinweisen ;)

Arbeiten des NID 15 Ausschuß


Im Kern ging es  im Workshop um die Frage, welchen Standard wollen wir in der digitalen Langzeitarchivierung in den nächsten 5-8 Jahren haben und wie kommen wir dahin?

Mit dieser Frage startete Prof. Keitel den Workshop und skizzierte nachfolgend die Ausgangslage von 2005.

  • abstraktes Thema "digitale Archivierung"
  • DIN 31646/31644/31645 aus Nestor "Dunstkreis"
  • DIN 31647 "Beweiserhaltung kryptograf. signierter Dokumente"
  • Rücklauf, ob Norm in Praxis verwendet werden ist schwierig zu erkennen
  • beziehen sich auf OAIS (ISO14721)
  • zeigen, ob man sich noch im Rahmen der digitalen LZA bewegt.

Aktuell ergänzen praktische Erfahrungen diese frühen theorethischen Überlegungen. Die Frage ist daher, ob es Bereiche gibt, wo sich die Ausgangsthesen mittlerweile überholt haben?

Es gilt, so Prof. Keitel,
  •  Schwerpunkte, die sich zur Standardisierung eignen, herauszukristallisieren
  •  Mitarbeitern zu finden, die sich in der Normierungsarbeit in den neuen Feldern einbringen wollen

Ob man für Normungsarbeit geeignet sei, läßt sich launisch an folgenden Kriterien festmachen (Zitat):
  • Lange auf Stuhl sitzen
  • Verbessere gern Geschriebenes anderer Leute
  • bei genauen terminologischen Definitionen verstehe ich keinen Spaß und mache keine Kompromisse
  • ich lese gerne Dokumente mit Titelen, wie...
Im Anschluss wurde die Schwierigkeit angesprochen, Feedback zu bestehenden DIN Normen zu erhalten.

PDF Standardisierung


Olaf Drümmer von der callas software GmbH skizzierte einführend die Geschichte von PDF und wies auf die neue Version 2 hin:

  • 1993-2006 Adobe PDF 1.0 -> 1.7
  • 2008 ISO: PDF 1.7 als ISO 32000-1
  • 2017 ISO: PDF 2.0 als ISO 32000-2 (im nächsten Quartal, >1000 Seiten)
    • neue kryptografische Verfahren
    • tagging überarbeitet
    • Problemfeld im Normungsprozess waren Farben
    • Namespaces wurden eingeführt, zB. um Tags aus HTML 5 einbinden
Er ging dann auf die PDF-Spezialisierungen ein:

  • 2001 PDF/X Übermittlung von Druckvorlagen
  • 2005 PDF/A Archivierung, ISO Reihe 19005
    • entstanden aus Notwendigkeiten der US Courts, Library of Congress
  • 2008 PDF/E ISO 24517, Engineering (CAD), noch nicht stark verbreitet, Ende des Jahres auch 3D Modelle
  • 2010 PDF/VT ISO 16612-2 + PDF/VCR ISO 16612-3, variabler Datendruck (großvolumige Rechnungen, Serienbriefe)
  • 2012 PDF/UA ISO 14289 Reihe, Barrierefreiheit
Die Bedeutung der Normung ergibt sich nach Drümmer allein schon aus der
Verbreitung von PDF Dokumenten:
  • Anzahl PDF Dokumente weltweit, mind. Billionen (10¹²), davon 6 Millionen allein beim US Court
  • Lebenserwartungen pro PDF: Stunden bis Jahre
Weiter ging er auf die Herausforderung Variantenvielfalt ein:
  • PDF/X, 8 Normteile, insgesamt 12 Konformitätsstufe
  • PDF/A Normenreihe, 3 Normteile, insgesamt 8 Konformitätsstufen
  • Unübersichtlich, mangelnde Trennschärfe?
  • Flexibilität bzw. Mächtigkeit
  • offener Charakter
  • breite Abdeckung
Wie es mit der Normierung ab 2017 weitergehen soll skizzierte er anschliessend:
  • PDF2.0 weitgehend rückwärtskompatibel, keine Validierung bei Veröffentlichungen vorgesehen
  • Projekt "Camelot2" soll klassische PDF-Dokumentenwelt und Open Web Platform zusammenbringen, mehr Infos zu PDF Days Europe 2017, Berlin, 15.-16. Mai 2017
  • PDF/A4 als Ziel: keine Konformitätsstufen
  • PDF/E erlaubt interaktive Elemente (JS), PDF/E-2 soll eher eine Archivausprägung weniger eine Arbeitsdokumentausprägung bekommen
  • XMP kann im PDF an *allen* Stellen angebracht werden, so dass man darin auch Quellen oder zB. UUIDs dafür hinterlegen kann
  • PDFA/3 kann auch alternative Verknüpfung zum Inhalt beliebiger Dateien hinterlegen, Problem: nicht verpflichtend und muss über Policy geregelt werden

nestor


Prof. Keitel skizzierte kurz die Arbeit von nestor:

  •  …ist auf jeden Fall Kooperationsnetzwerk
  • stellt AGs vor

Vertrauenswürdige Archive

  • * 2004-2008 Nestor Kriterienkatalog
  • * 2008-2012 DIN31644
  • * 2013-… nestor Siegel

Submission Information Packages - Überarbeitung der Ingest-Standards


Dr. Sina Westphal und Dr. Sebastian Gleixner (Dt. Bundesarchiv) regten in einem Impulsvortrag die Normierung des Ingestvorgangs und der SIPs an.

  • Bundesarchiv 4PB/Jahr Zuwachs
  • Anreiz zur allmählichen Angleichung der Systeme
  • vereinheitlichte Metadaten
  • verbesserter Datenaustausch
  • vereinheitlichte Schnittstellen
Konsequenzen:
  • Vereinheitlichung bestehender SIPs (ggf. auch AIPs/DIPs)
  • Vereinheitlichung bestehender digitaler Archivsysteme

Zwei Teilbereiche:
  • Standardisierung des SIP (konkret)
    • Struktur
    • Metadaten
    • Primärdaten
    • vgl. E-ARK, e-CH, EMEA
  • Standardisierung des Ingest-Prozesses (abstrakt)
    • Verbindung zum Erschliessungstool
    • Validierung
    • Ingest
    • Umgang mit Primärdaten

Fragen:
  • Vereinheitlichung möglich?
  • Ist Standardisierung AIPs/DIPs und der damit verbundenen Prozesse notwendig?

Im Anschluss erfolgte eine Diskussion über Abgrenzung und konkrete Austauschverfahren mit ff. Ergebnis:

  • Trend geht hin zu abstrakter Modulbeschreibung
  • konzeptioneller Rahmen erwünscht
  • Festlegung welche Module verpflichtend, welche optional sind
  • empfohlener Einstiegspunkt für Automatisierung

Videoarchivierung als neue Herausforderung, Langzeiterhaltung audiovisueller Medien jenseits von Film- und Fernsehen


In diesem Impulsvortrag von Alfred Werner, HUK Coburg wurde die Problematik der Langzeitarchivierung von Videos skizziert.

  • Bandbreite Außenstelle 5-15MBit/s
  • wandeln in Multipage-TIFF monochrom (kleine Dateien) und in JPG um,
  • Videos erwünscht,
    • 2011 5 Videos/Tag
    • 2016 20 Videos/Tag (im Gegensatz zu 10.000 Schadensfälle pro Tag)
    • 2021 100?/1000? Videos/Tag
  • Dashcam-Videos seit diesem Jahr erlaubt

Problem: unterschiedlichste Formate, Tendenz steigend, es wird nicht besser (3D, HDR, 4k, 2 Objektive, Spezialsensoren)

mögliche Lösung: Konvertierung in ein Langzeitarchivformat für Videos

Anforderungen:
  • Standard für die nächsten 50 Jahre
  • Lizenzfrei
  • bestmögliche Qualität
  • geringer Speicherplatz
  • gute Antwortzeiten auch bei geringer Bandbreite

dann noch Funktionen für Sachbearbeiter, wie:
Zoomen, Sprungmarken setzen, Extrahieren Einzelbilder, Schwärzen, Szenen extrahieren.

In der anschliessenden Diskussion wurde das Problem deutlich, dass man sich im Spannungsfeld zwischen Robustheit und originalgetreuer Wiedergabe einerseits und Ressourcenbedarf (Speicher, Bandbreite, Processingzeit) andererseits befindet.

Anmerkung: Dazu wurde auf der nestor-ML ein ergänzender Beitrag verfasst.


Digital Curation


Auch hier hielt Prof. Keitel ein Impulsreferat. Ich hoffe, ich kann den Inhalt korrekt wiedergeben:

Unterschied Data Curation zu Langzeitarchivierung nach OAIS: wir reden nicht mehr von Einrichtungen/Organisationen, sondern von Techniken. D.h., fehlen der organisatorischen Verantwortung.

OAIS goes Records Managment, dh. wie kann man Anforderungen der digitalen LZA an Produzenten bringen (durch digital curation), AIP liegt quasi beim Produzenten.
Wie harmonieren die von OAIS/PREMIS genannten Erhaltungsfunktionen mit den Rgelungen des Records Managment? Welche Elemente/Gruppen müssen wir aus Erhaltungsgründen unterscheiden?

Keitel: "Wir gingen bisher immer von einem Kümmerer aus, der Dinge auf Dauer bewahrt. Digital Curation setzt vorher beim Producer an"

Zusammenfassung


Aus unserer Sicht sollte der Ingest versucht werden besser zu standardisieren. Nur so wäre es möglich, dass man Produzenten Werkzeuge in die Hand geben kann, die nicht archivspezifisch sind. Der Weg dorthin ist steil, zumal allein schon die Wege die Archive und Bibliotheken einschlagen sehr unterschiedlich sind.

PDF ist und bleibt leider ein Minenfeld. Weder wurden mit PDF2 bestehende Ambiguitäten ausgeräumt, noch vereinfacht sich der Standard. Besonders nachteilich dürfte sich die fehlende offizielle Validierung erweisen. Hinzukommt dass der Formatzoo rund um PDF weiter anwächst und Mischformen von Dokumenten möglich sind, d.h. ein PDF kann sowohl PDF/E als auch PDF/A sein.

Der Bedarf nach langzeittauglichen Videoformaten ist vorhanden. Eine Normierung könnte helfen, die Unterstützung durch Hersteller zu forcieren. Am Thema Video wurde deutlich, dass die digitale Langzeitarchivierung Kosten verursacht, die nicht leicht zu vermitteln sind. Datenkompression, insbesondere die verlustbehaftete führt zu einem höheren Schadensrisiko bei Bitfehlern. Die Diskussion über das Spannungsfeld Robustheit/Qualität vs. Kosten muss in der Community geführt werden, ist aber außerhalb von Normungsbemühungen anzusiedeln.

Data Curation ist eine Aktie für sich. Es gibt Lücken, die entstehen, wenn Dokumente Lebenszyklen von mehreren Jahrzehnten aufweisen. Mein Bauchgefühl sagt mir, dass dies ebenfalls unter Langzeitverfügbarkeit subsummiert werden kann, da wir in der Langzeitarchivierung ja die Dokumente auf unbestimmte Zeiten nutzbar halten wollen. Data Curation scheint mir demnach nichts anderes als der Sonderfall zu sein, als das Produzent und Archiv als Rolle zusammenfallen.

Eingestellt von um Keine Kommentare:
Labels: , , , , , , , , , ,

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.
    Eingestellt von um 1 Kommentar:
    Labels: , , , , , , ,

    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
    Eingestellt von um Keine Kommentare:
    Labels: , , , , , , , , , , ,
    Abonnieren Posts (Atom)