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

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.



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