siehe auch: Videos transcodieren

Die älteren Video-Formate sind so ausgelegt, das sie wenig Rechenleistung verbrauchen. Leider werden sie für gewöhnlich auch auf kleineren Datenträgern eingesetzt (z.B. Video-CD), so das man hier fast nie auf die nötigen Spielzeiten kommt.

Aus dem Grund werden Filme meistens transcodiert um Platz zu sparen. Bei der wahl eines geeigneten Ziel-Codecs gibt es mehrere Gesichtspunkte, die man beachten muß. Zum einen muß auf jeden Fall die Kompatibilität beachtet werden!

Es macht keinen Sinn, seine alten MPEG2-Videos in das Dirac-Format umzurechnen, nur weil es zur Zeit der freie Codec mit der besten Kompressionsrate auf dem Markt ist und er absolut Patentfrei ist. Wenn man die Videos mit einem handelsüblichen Media-Player auf dem Fernseher ansehen will… denn es gibt zur Zeit (2006) keine handelsüblichen Media-Player die einen absolut Patentfreien Codec unterstützen (nichteinmal für den Theora-Codec)!

Mittlerweile (2018) gibt es welche, z.B. kann der "LG webOS TV" (laut Dokumentation) Filme abspieln die folgendes freies Format aufweisen: MKV+VP8/Vp9+MP3 (der Codec VP9 wird aber, laut Doku, leider nicht in allen Ländern unterstützt). Vermutlich wird sich in Zukunft WebM+AV1+Opus als stärkstes freies Video-Format durchsetzen.

Ausserdem ist es unsinnig, einen H.264- oder Dirac-Codec zu verwenden, wenn man nur einen schwachen Rechner zum abspielen verwenden möchte. Denn diese Codecs benötigen viel Rechenleistung!

Weiterhin ist zu beachten, dass man theoretisch die meisten Video-Codecs mit den meisten Audio-Codecs in einer ganzen Reihe von Container-Formaten zusammen führen kann. Allerdings kann man diese exotischen Zusammenstellungen dann nur auf dem PC abspielen, denn in den Standardisierungen wurden sogenannte Profile festgelegt!

Profile sind Video-, Audio- und Containerformat-Kombinationen, die üblicherweise verwendet werden sollen. Von handelsüblichen Media-Playern werden in aller Regel nur ein Teil dieser definierten Profile unterstützt.

Zum Schluss sollte man sich überlegen welche Vorteile und welche Nachteile der neue Codec gegenüber dem bisherigen Codec hat, möglicherweise macht es in einigen Fällen dann keinen Sinn mehr zu transcodieren.

Denn jede transcodierung verschlechtert die Bildqualität, selbst wenn man in der Zieldatei einen besseren Codec bei gleicher Dateigröße wählt!

Um die Höchste Tonqualität beizubehalten, sollte man die Tonspur nur verändern wenn es unbedingt sein muss (das gleiche gilt für die Bildqualität). Bei AC3 (a52) ist das oft nicht nötig, da es (im geeigneten Container) praktisch von jedem Gerät abgespielt werden kann. Und im Verhältnis zu den Bilddaten, sind die (komprimierten) Tondaten vernachlässigbar klein.

beispielhaft werden hier die unterstützten Formate von zwei Konsumergeräten von "LG" aufgeführt:

• LG webOS TV - Video-Codec - Stand 2018
• LG BD-P1580 (Benutzerhandbuch Seite 14)
  • DivX
    • CD-R/-RW, DVD-R/-RW, USB
    • Es können Videodateien mit den folgenden Erweiterungen wiedergegeben werden : .avi, .divx, .AVI, .DIVX
    • DivX-VIDEO-Codec-Format : DivX 3.11, DivX 4.x, DivX 5.x (ohne QPEL und GMC)
    • DivX-AUDIO-Codec-Format : “MP3”, “MPEG1 Audio Layer 2”, “AC3”, “DTS”
    • Unterstützte Untertitel-Dateiformate : .smi, .srt, .sub, .psb, .txt, .ass
    • Maximale Auflösung :
      • 720 x 480 zu 30 B/s
      • 720 x 576 zu 25 B/s
    • Mindestauflösung : 16x16
    • Maximale Bildfrequenz bei progressiven Quellen : 30 Bilder pro Sekunde
    • Maximale Feldrate bei Interlace-Quellen : 60 Felder pro Sekunde
    • Es können keine Disks mit höheren Auflösungen als 720 x 576 Pixel wiedergegeben werden.
  • AVCHD (Advanced Video codec high definition)
    • Dieser Player kann Disks im AVCHD-Format wiedergeben. Diese Disks sind normalerweise bespielt und werden in Camcordern eingesetzt.
    • Das AVCHD-Format ist ein digitales HD-Format für Videokameras.
    • Das MPEG-4 AVC/H.264 Format kann Bilder effektiver komprimieren als das konventionelle Bilderkomprimierungsformat.
    • Manche AVCHD Disks arbeiten mit dem “x.v.Color” Format.
    • Dieses Gerät kann AVCHD Disks unter Verwendung des “x.v.Color” formats abspielen.
    • “x.v.Color” ist eine Marke der Sony Corporation.
    • “AVCHD” und das AVCHD Logo sind Marken der Matsushita Electronic Industrial Co., Ltd. und der Sony Corporation

1. VCD → seit 1993
   1. Video: MPEG-1 (auch H.261)
   2. Audio: MP2
2. DVD → seit 1996
   1. Video: MPEG-2 (auch H.262)
   2. Audio: Dolby Digital (auch ATSC A/52 und AC-3)
   3. Der Standard sieht eine Datenrate für Audio und Video von insgesamt bis zu 9,8 Mbit/s vor.
   4. NTSC-Player müssen lediglich die Audio-formate "PCM" und "Dolby Digital" unterstützen, die übrigen Formate (DTS, MP2, "MPEG-2 Multichannel" auch bekannt als "MPEG-2 BC") sind optional.
3. AVI → seit ca. 2000 ein beliebtes Weitergabeformat (viele Konsumergeräte können dieses Format nur mit einer max. Auflösung von bis zu 720x480@30fps / 720x576@25fps abspielen; auch benötigen viele Konsumergeräte ausführliche Informationen im AVI-Container wie z.B. einen sinnvollen Eintrag für "profile")
   1. Video: ASP (auch H.263; gehört zum Standard MPEG-4 Part 2) → siehe auch DivX-5, Xvid
   2. Audio: MP3
4. MP4 (ist ein HTML5-Standard) → seit ca. 2004 ein beliebtes Weitergabeformat
   1. Video: AVC (auch H.264; gehört zum Standard MPEG-4 Part 10) → siehe auch x264 / DivX-7
   2. Audio: AAC (Die ATSC hat auch AC-3 für den mp4-Container spezifiziert, aber MPEG unterstützt diesen Codec offiziell nicht.)
5. Blu-ray Disc → seit 2003 (seit 2009 konkurrenzlos)
   1. Video: AVC (auch H.264; gehört zum Standard MPEG-4 Part 10)
   2. Audio: Dolby Digital (auch ATSC A/52 und AC-3) und andere
6. AVCHD → seit 2006
   1. Video: AVC (auch H.264; gehört zum Standard MPEG-4 Part 10)
   2. Audio: Dolby Digital (auch ATSC A/52 und AC-3)
7. OGG (ist ein HTML5-Standard)
   1. 2004-2012
      1. Video: Theora - (siehe Seite 21) Theora kann jedes Bildformat bis zu einer Größe von 1048560 x 1048560
      2. Audio: Vorbis
   2. ab 2012
      1. Video: Theora
      2. Audio: Opus - wird seit Android 5 'Lollipop' unterstützt
8. Matroska / MKV - wird seit Android 8.1 (?) unterstützt
   1. ???
      1. Video: VP9 - wird seit Android 4.4 'KitKat' unterstützt
      2. Audio: Opus - wird seit Android 5 'Lollipop' unterstützt
9. WebM (ein Abkömmling von Matroska) (ist ein HTML5-Standard) - wird seit Android 2.3 'Gingerbread' unterstützt
   • Only VP8 or VP9 or AV1 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM.
   1. 2012-2015
      1. Video: VP8
      2. Audio: Vorbis (aber ggf. auch schon mit Opus)
   2. 2014-2018
      1. Video: VP9 - wird seit Android 4.4 'KitKat' unterstützt
         • ab Chromium (Mai 2013)
         • ab Opera Version 15 (Juli 2013)
         • ab Google Chrome Version 29 (August 2013)
         • ab Mozilla Firefox Version 28 (März 2014)
      2. Audio: Opus - wird seit Android 5 'Lollipop' unterstützt
   3. seit Ende 2018
      1. Video: AV1 (ist ein HTML5-Standard) - wird ab Android 10 unterstützt / libaom-av1
         • stummer AV1-Test-Film von 1 Sekunde Länge im WebM-Format
         • ab Opera Version 57
         • ab Mozilla Firefox Version 67 (Ende 2018)
         • volle Unterstützung ab Google Chrome Version 70 (Oktober 2018)
         • ab VLC Version 3.0.6
         • ab FFmpeg Version 4.0
      2. Audio: Opus - wird seit Android 5 'Lollipop' unterstützt

• von Android unterstützte Video-Formate

für mich sind diese beiden Varianten am interessantesten:

• sehr kompatibel, weil es ein HTML5-Standard ist:
  • Container: MP4
    • Video-Codec: AVC
    • Audio-Codec: AAC (leider unterstützt FFmpeg keinen AAC-Encoder, der im Profil "HE-AAC" auch VBR beherscht)
• komplett frei:
  • Container: MKV (mit Untertitel) / WebM (kann nur das Untertitelformat WebVTT)
    • Video-Codec: VP9 / AV1
    • Audio-Codec: Vorbis / Opus

Projekt FlatheadV8

Auf der Seite von FireFox, über die unterstützten Vodeo-Formate aus dem HTML5-Standard werden diese Formate/Codecs erwähnt:

• Container-Format
  • .wav, .wave (Audio)
  • .ogg, .ogv (Video)
  • .oga (Audio)
  • .ogx
  • .spx (Audio)
  • .opus (Audio)
  • .webm (Video)
  • .mp4 (Video)
• Video-Codecs
  • Ogg Theora - ca. 30% schlechter als AVC
  • VP8
  • VP9 - ca. 30% besser als AVC
  • AVC
  • AV1 - Dateien sind ca. halb so groß wie von VP9
• Audio-Codecs
  • PCM (WAVE / 8-, 16-Bit pro Sample)
  • Ogg Vorbis
  • Ogg Speex
  • Ogg Opus
  • AAC

draus folgt die Unterstützung folgende populären Formate:

• OGV + Theora + Vorbis
• OGV + VP8 + Vorbis
• OGV + VP8 + Opus
• WebM + VP9 + Vorbis
• WebM + VP9 + Opus
• WebM + AV1 + Opus
• MP4 + AVC + AAC (im Gegensatz zu den anderen Profilen, enthält dieses keine Freien Elemente)

Leider unterstützen die oben genannten freien Container-Formate beide jeweils nur ein einziges Test-basiertes Untertitelformat.

Die Grafiktreiber, die unter Linux am besten funktionieren, kommen von nVidia ⇒ Nvidia-Treiber

Das alte Standard-Format ist 4/3 (1,3333333333/1), das neue Standard-Format ist 16/9 (1,7777777778/1). Die neuen TV-Geräte kennen noch das Format 14/9, es liegt (nimmt man bei 4/3 und 16/9 die selbe Bildhöhe an) genau zwischen 4/3 und 16/9, bezogen auf die Bildfläche.
Bei einem Film im Seitenverhältnis von 112/75 (1,4933333333/1) ist es egal ob man dort oben+unten oder links+rechts schwarze Balken anfühgt, die schwarzen Balken belegen genau die gleiche Fläche.

Das gute alte Daumenkino kennt ja jeder aus der Kindheit, wenn man diese Einzelbilder jetzt als JPG's oder PNG's vorliegen hat, dann kann man daraus einen Film machen.

• http://ubuntuwiki.de/files/stop-motion.html
  • Daumenkino mit Gimp: aptitude install gimp gimp-gap
    • Vorgehensweise für ein animiertes GIF-Bild:
      • Bilder laden, wenn die Bilder fortlaufend nummeriert sind, lassen sie sich alle auf einmal importieren
      • Menü: "video → frames to image"
      • Speichern als .gif
      • Häkchen setzen bei "Als Animation speichern“
  • Daumenkino mit MEncoder
  • Daumenkino mit FFmpeg

• Videoauflösung
• SDTV
• High Definition Video
• HDTV

 480i - NTSC (terrestrisches Fernsehen in den USA und in Japan)
 480p - VGA  (PC-Standard-Monitor von 1991)
 576i - PAL  (terrestrisches Fernsehen in Deutschland)
 720p - HD / HD ready
1080p - FullHD

1. DV: 480i60 (SDTV/NTSC/VGA im Zeilensprungverfahren) entspricht 720x480/640x480
2. DV: 576i50 (SDTV/PAL/SECAM im Zeilensprungverfahren) entspricht 768x576/720x576
3. DVB: 576i50 (SDTV/PAL/SECAM im Zeilensprungverfahren) entspricht 1024x576/720x576
4. HDV1: 720i (HDTV reduziert im Zeilensprungverfahren) entspricht 1280×720
5. HDV1: 720p (HDTV reduziert im Vollbildverfahren) entspricht 1280×720
6. HDV2: 1080i (HDTV nativ im Zeilensprungverfahren) entspricht 1920x1080
7. HDV2: 1080p (HDTV/Blu-ray nativ im Vollbildverfahren) entspricht 1920x1080

1. 4:3 entspricht 640x480 und 768x576
2. 16:9 entspricht 720x432, 1024x576, 1280×720 und 1920x1080
3. 16:10 entspricht 720x404

Beim Fernsehen sind die Bildpunkte nicht quadratisch, sondern rechteckig:

• PAL hat eine tatsächliche Auflösung von 720x576 rechteckigen Bildpunkten, die allerdings eine Fläche ausfüllen, wie sie 768x576 quadratische Bildpunkte ausfüllen würden.
• NTSC hat eine tatsächliche Auflösung von 640x480 rechteckigen Bildpunkten, die allerdings eine Fläche ausfüllen, wie sie 720x480 quadratische Bildpunkte ausfüllen würden.
• Blu-ray Disk setzt zwingend quadratische Bildpunkte voraus!

720p ist weltweit ein selteneres Format. Von allen europäischen Sendern setzten ab 2010 nur die Sender ARTE HD, Das Erste HD, Eins Festival HD, ZDF HD, ORF 1 HD, ORF 2 HD und LUXE TV HD auf die geringer aufgelöste HDTV-Norm.

Der MPEG-1-Standard gehört zur H.261-Familie.

MPEG-1 (maximale Bildgröße 768x576 Pixel) wurde in den 80er Jahren mit dem Ziel entwickelt (1991 vorgestellt), Filme auf die beschränkte Datenrate (bis 1,5 Mbit/s) einer mit normaler Geschwindigkeit abgespielten Audio-CD zu komprimieren. Das Ergebnis, mit dementsprechend eher bescheidener Qualität, wird Video-CD genannt. Die Video-Kompression von MPEG-1 wurde 1994 durch MPEG-2 deutlich verfeinert und verbessert.

Der Video-CD-Standard (VCD) wurde 1993 von einem Konsortium japanischer Elektronik-Hersteller verabredet und im so genannten White Book festgehalten. Er gehört zu den offiziellen CD-Formaten, die das Compact-Disc-Logo tragen dürfen – in diesem Fall Compact Disc Digital Video. Er beschreibt das Abspeichern von Videodaten nach dem MPEG-1-Standard auf einer Standard-CD. Die im Standard festgelegte Auflösung beträgt für PAL 352 × 288 Bildpunkte mit 25 Bildern pro Sekunde, für NTSC 352 × 240 Bildpunkte mit 29,97 oder 23,976 Bildern pro Sekunde. Das Bildformat ist 4:3. 16:9 ist nicht vorgesehen. Der Ton ist Stereo. Joint-Stereo, digitaler Surround-Sound, mehrere Tonspuren oder wählbare Untertitel sind auf VCDs nicht möglich, Mono-Sound muss bei Bedarf wie bei der Audio-CD durch identische linke und rechte Tonspuren realisiert werden. Die Daten werden also zweimal gespeichert. Die Bitrate muss bei maximal 1.151.929 bit/s für die Bilddaten, genau 224.000 bit/s für die Stereo-Tondaten (im MP2-Format) und genau 1.411.200 bit/s für die gesamten Daten liegen. Letzteres entspricht der Bitrate von Audio-CDs; somit ist die maximale Laufzeit identisch, und VCD-Player können dieselbe Laufwerksmechanik wie normale CD-Player verwenden. Variable Bitraten sind nicht vorgesehen. Auf einer standardkonformen Video-CD muss eine Abspielsoftware für CD-i-Spieler gespeichert sein, da diese keine solche eingebaut haben. Diese Software kostet knapp eine Minute Laufzeit.

Die Bildqualität entspricht ungefähr einem VHS-Video, ist allerdings etwas schlechter als bei einer hochwertigen und mit guten Profi-Aufzeichnungsgeräten bespielten VHS-Kassette. Das VHS-typische Bild- und Farbrauschen entfällt zwar, dafür sind auf Video-CDs Unschärfen, Kompressionsartefakte („Klötzchen“, Ringbildung um Objekte) und ruckartige Bewegungen zu erkennen. Die Tonqualität ist wesentlich besser als Mono-VHS, aber oft schlechter als HiFi-VHS. Die Bildqualität schwankt je nach der verwendeten Enkodier-Software und ihren Einstellungen, kann aber ein gewisses Maximum nicht übersteigen. Dadurch und durch die maximale Abspieldauer von ursprünglich nur gut 73 Minuten (heute gut 79 Minuten bei Verwendung einer 700MB-CD-R), sind VCDs als Medium für Spielfilme nur bedingt geeignet.

Ein weiterer Nachteil der Video-CD ist die gegenüber der TV-Vollauflösung (576 sichtbare Zeilen in Europa, 480 in Amerika) reduzierte Vertikalauflösung (288 bzw. 240 sichtbare Zeilen), d.h. jede zweite Rasterzeile wird „weggeworfen“, wodurch auch das Interlacing des Originalsignals und damit Zeitauflösung verlorengeht. Viele analoge Videoformate, wie z.B. VHS, haben diese Eigenschaft systembedingt nicht. Die horizontale Auflösung der VCD (352 Pixels) ist jedoch deutlich besser als die von VHS (220 bis 240 Linien).

MPEG-2 Part 2 ist seit 1994 das DVD-Standard-Format, wobei von 1994 bis 1995 MP2 als Audio-Codec verwendet wurde und ab 1995 AC3.

Der MPEG-2-Standard gehört zur H.262-Familie.

Verwendet wird MPEG-2 unter anderem bei DVD.

• Video-Codec: MPEG2
• Audio-Codec: MP2, AC3
• Container-Format: TS, PS
• Dateiendungen: MPG, MPEG, VOB

mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd:tsaf -vf scale=720:576,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=2560:keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:vqmin=1:lmin=1:dc=10:vstrict=0:acodec=ac3:abitrate=256:aspect=16/9 -ofps 25 -o Film.mpg Film.mkv

Der Videostandard MPEG-4 Part 2 erhielt die Bezeichnung Advanced Simple Profile (ASP), der bekannteste Codec, der in diesem Standard mit einfloss, ist der DivX-Codec in den Versionen 3 bis 6. Die freie Version davon nennt sich Xvid.

DivX 3.11 und frühere Versionen des Codecs entstanden, indem Microsofts MPEG-4-Codec gehackt wurde; dieser war durch einen französischen Hacker namens Jérôme Rota (Pseudonym: Gej, okzitanisch für „verrückt“) aus einer Betaversion des Windows Media Players extrahiert worden. Das „Project Mayo“ war geboren, dem sich kurze Zeit später vier weitere Programmierer anschlossen. In den frühen Versionen des „DivX Player“ zierte ihn noch das „Project Mayo“-Emblem, das jedoch aufgrund vieler Rückfragen von Nutzern später entfernt wurde. Der Hack modifizierte den Microsoft-Codec, um das komprimierte Video nicht nur als ASF-Datei, sondern auch als AVI-Datei speichern zu können. Außerdem unterstützte der ursprüngliche Microsoft-Codec nur Bitraten von maximal 256 kbps; in der gehackten Version hingegen waren es bis zu 6.000. Die von Rota gegründete Firma DivXNetworks, Inc. entwickelte später eine völlig neue Version, um in den USA Patentverletzungen zu vermeiden. DivXNetworks hat in den USA ein Patent auf den neuen Codec angemeldet.

Der (eigentliche) DivX-Codec (Versionen 3 bis 6) wird kaum noch weiterentwickelt, das liegt wohl daran, dass DivX seit Version 7.0 auch das H.264 Format unterstützt sowie den Matroska-Container, … jedoch ausschließlich über ein sehr einfach gestricktes Konvertierungsprogramm namens DivX Converter.

Xvid ist eine freie Implementierung des MPEG-4-Video-Codec, der ursprünglich auf dem OpenDivX-Quelltext basierte. Der zugrunde liegende Quellcode von OpenDivX stammte wiederum aus der MPEG-4-Referenzimplementierung des EU-Projekts MoMuSys. Das Xvid-Projekt wurde von mehreren freiwilligen Programmierern gestartet, nachdem der Quellcode von OpenDivX geschlossen wurde. Der Name des Projekts ist ein Anagramm des Namens DivX. Durch den unverschlüsselt veröffentlichten Quelltext von OpenDivX erhielten die Programmierer die Möglichkeit, den Codec in den grundlegenden Eigenschaften zu verändern und zu optimieren. Zusammen mit DivX und Nero Digital ist Xvid der bekannteste MPEG-4-Codec.

Wegen patentrechtlicher Schwierigkeiten werden keine offiziellen kompilierten Versionen des Quelltextes vom Xvid-Team bereitgestellt. Ein kommerzieller Vertrieb von Xvid ist möglich, solange man sich an die GPL-Bedingungen hält. In einigen Staaten wie USA oder Japan fallen zusätzlich Gebühren für die oben angeführten Patente an.

Seit der Version 1.1.3 vom 29. Juni 2007 wird das MPEG-4 Visual Advanced Simple Profile unterstützt. Das heißt, Xvid unterstützt Advanced-Simple-Profile-Features wie B-Frames, Quarter Pixel Motion Compensation (QPel), Global Motion Compensation (GMC) und Custom Quantizer-Matrizen. Seit Dezember 2005 soll der Beta-Code von Xvid AVC veröffentlicht werden. Der neue Codec unterstützt den effizienteren H.264/AVC-Standard.

Ich verwende das ASP-Format in folgender Zusammenstellung:

• Video-Codec: Xvid
• Audio-Codec: AC3 (unverändert von der DVD), MP3 (resampled)
• Container-Format: AVI

Dieses Format wird von den DVD-Playern von Philips abgespielt. Da DivX kaum noch weiterentwickelt wird, kann man mit Xvid mittlerweile bessere Ergebnisse erziehlen.

Mit ffmpeg in einem Durchgang:

# ffmpeg -b 2560k -vcodec libxvid -s 720x432 -padtop 72 -padbottom 72 -aspect 4:3 -acodec libmp3lame -ab 256k -ac 2 -async 48000 -i Film.vob -y Film.avi

oder mit mencoder in zwei Durchläufen:

# mencoder -forceidx -mc 0 -oac mp3lame -lameopts q=0:aq=0:br=256 -af resample=48000:0:0,channels=2 -ovc xvid -vf pp=tn:2/ci/hb/vb/dr/al,scale=720:404,harddup -xvidencopts bitrate=2560:me_quality=6:trellis:chroma_me:chroma_opt:hq_ac:vhq=4:autoaspect:pass=1 -passlogfile Film.log -of rawvideo -o /dev/null Film.vob
# mencoder -forceidx -mc 0 -oac mp3lame -lameopts q=0:aq=0:br=256 -af resample=48000:0:0,channels=2 -ovc xvid -vf pp=tn:2/ci/hb/vb/dr/al,scale=720:404,harddup -xvidencopts bitrate=2560:me_quality=6:trellis:chroma_me:chroma_opt:hq_ac:vhq=4:autoaspect:pass=2 -passlogfile Film.log -of avi -o Film.avi Film.vob

Der Videostandard MPEG-4 Part 10 erhielt die Bezeichnung Advanced Video Coding - (AVC), der bekannteste Codec, der in diesem Standard mit einfloss ist, ist der H.264-Codec. DivX ab der Version 7 (DivX Plus) unterstützt ebenfalls den H.264-Video-Codec, den AAC-Audio-Codec sowie das Matroska-Container-Format MKV.

H.264/MPEG-4 AVC ist ein Standard zur hocheffizienten Videokompression. Er wurde zunächst von der ITU (Study Group 16, Video Coding Experts Group) unter dem Namen H.26L entwickelt. Im Jahre 2001 schloss sich die ITU-Gruppe mit MPEG-Visual zusammen und führte die Entwicklung gemeinschaftlich im Joint Video Team (JVT) fort. Ziel des Projektes war es, ein Kompressionsverfahren zu entwerfen, das im Vergleich zu bisherigen Standards sowohl für mobile Anwendungen als auch im TV- und HD-Bereich die benötigte Datenrate bei gleicher Qualität mindestens um die Hälfte reduziert. Im Jahr 2003 wurde der Standard von beiden Organisationen mit identischem Wortlaut verabschiedet. Die ITU-Bezeichnung lautet dabei H.264. Bei ISO/IEC MPEG läuft der Standard unter der Bezeichnung MPEG-4/AVC (Advanced Video Coding) und ist der zehnte Teil des MPEG-4-Standards (MPEG-4/Part 10, ISO/IEC 14496-10).

MPEG-4/AVC unterscheidet sich deutlich von MPEG-4/ASP. H.264 erreicht typischerweise eine etwa dreimal so hohe Codiereffizienz wie H.262 (MPEG-2) und ist auch für hoch aufgelöste Bilddaten (z.B. HDTV) ausgelegt. Das heißt, vergleichbare Qualität ist etwa bei einem Drittel der MPEG-2-Datenmenge zu erreichen. Allerdings ist der Rechenaufwand auch um den Faktor 2 bis 3 höher.

H.264 baut weitestgehend auf seinen Vorgängern MPEG-1, MPEG-2, MPEG-4 und der H.261-Familie auf, weist jedoch deutliche Veränderungen und Erweiterungen auf.

Da H.264 nicht an ein bestimmtes Containerformat gebunden ist, können die Videos als MP4-, aber auch als AVI-, Matroska- oder Ogg Media-Datei vorliegen. Es ist sogar möglich, H.264-Videos als Roh-Daten zu speichern (.264). Solche Rohdaten können dann z.B. mit MP4Box (GPAC) oder mkvmerge in einen geeigneten Container gemultiplext werden. Benötigt werden neben einem Decoder also auch ein Splitter (Demuxer), der das jeweils benutzte Containerformat unterstützt.

Verwendet wird AVC unter anderem bei HDTV und DVB-T2. AVC soll ca. 2,5 mal soviele Sender bei gleicher Bandbreite ermöglichen, wie man es mit MPEG-2 erreichen kann.

• Die Tücken von H.264/x264: Weichzeichnungseffekt und fehlende Schärfe

Die nötigen Werkzeuge installiert man unter Ubuntu so:

aptitude install mplayer mencoder ffmpeg vorbis-tools mkvtoolnix gpac x264 faac normalize-audio

Blu-ray erlaubt nur ein paar Auflösungs&Frameraten Kombinationen. Die MPEG-4 AVC Spezifikation erlaubt da wesentlich mehr.

• MaxFS - Max frame size (MBs)
• mbpf - Makroblöcke pro Frame

Als Einheit ist bei MaxFS 'MBs' angegeben was für Makroblöcke steht. Das hilft einen dann mit dem Wissen das Makroblöcke in den Tabellen immer mit 16x16 Pixeln angenommen werden weiter. Die Anzahl der Makroblöcke pro Frame (mbpf) sind also je Level wie folgt eingeschränkt:

Die Makroblöcke werden als 16x16 Pixel groß angenommen, was dazu führt, dass sich die Anzahl an Makroblöcken für ein Frame also wie folgt berechnet: mbpf = aufgerundet(Breite/16) * aufgerundet(Höhe/16)

Eine Auflösung von 720*576 würde also aus 45*36 = 1620 Makroblöcken pro Frame bestehen, was uns Anhand der Tabelle sagt, dass man mindestens Level 2.2 verwenden muss wenn man etwas mit AVC Standardkonfrom mit einer Auflösung von 720x576 encoden will.

• http://forum.doom9.org/showthread.php?p=730001#post730001

Generell gelten folgende Einschränkungen für einen AVC Stream der zu einem bestimmten Profile&Level kompativel sein will:

MaxMBPS >= width*height*fps. (w&h measured in macroblocks, i.e. pixels/16 round up in each dimension)
MaxFS >= width*height
sqrt(MaxFS*8) >= width
sqrt(MaxFS*8) >= height
MaxDPB >= (bytes in a frame) * number of reference frames (for x264 number of reference frames = min(16, ref + (pyramid ? 2 : bframes ? 1 : 0)) =
MaxBR >= vbv_maxrate.
MaxCPB >= vbv_bufsize.
MaxVmvR >= max_mv_range.
MaxMvsPer2Mb, MinLumaBiPredSize, direct_8x8_inference_flag : are not enforced by x264. The only way to ensure compliance is to disable p4x4 at level>=3.1, or at level>=3 w/ B-frames.
MinCR : is not enforced by x264. Won't ever be an issue unless you use lossless.
SliceRate : I don't know what this limits.
with:
MaxDPB = max decoded picture buffer
MaxMBPS = max macroblocks per second
MaxFS = max frame size
MaxBR = max bitrate
MaxCPB = max vbv buffer
MaxVmvR = max motion vetor range

Für Blu-ray Disk bzw. AVCHD kommen dann noch weitere Beschränkungen dazu.

Am 2006-05-11 wurde das von Panasonic und Sony gemeinsam entwickelte AVCHD als Nachfolger von HDV für Videokameras, in der Version 1.0 vorgestellt.

Progressive - noninterlaced scanning (Vollbilder):

Der Standard 1920×1080p50 ist noch nicht verabschiedet und keiner weiß wann er kommen wird. Das ist im Moment aber auch nicht wichtig, da die Blu-ray Disk's in der Praxis ohnehin nur mit den beiden Bildwiederholraten 23.976 Hz und 24 Hz (ohne Zeilensprungverfahren) veröffentlicht werden und diese beiden Bildwiederholraten werden auch garantiert von jedem Blu-ray-Disk-Player unterstützt.

Allerdings muss man beachten, das die Bildpunkte bei PAL und NTSC nicht quadratisch sind, sondern rechteckig (PAL: 9% bis 42,22% in die Breite gezogen). Der Blu-ray Disk-Standard schreibt aber quadratische Bildpunkte vor. Wie es mit den PAL- und NTSC-Varianten der Blu-ray Disk-Bildformate aussieht, das weiß ich leider nicht. Ich gehe erstmal davon aus, das hier die rechteckigen Bildpunkte zur Anzeige in quadratisch Bildpunkte umgerechnet werden. Ein 720x576-PAL-Bild würde dann als 768x576-Bild angezeigt werden und ein 720x480-NTSC-Bild würde dann als 720x540-Bild angezeigt werden.

Will man aus seinen archivierten Videos, BD-kompatible Videos machen, sollte man sich an den AVCHD-Standard halten. Der AVCHD-Standard übernimmt die Definition des Video-Inhaltes und ist somit BD-kompatibel, aber an Stelle des BD-Verzeichnis-Formates, wird hier ein Datei-Format beschrieben.

Will man also nicht eine physikalische DVD in eine BD überführen, sondern eine PAL-Video-Datei in eine BD-kompatible Video-Datei, dann wird alles, woran man sich orientieren muss, im AVCHD-Standard beschrieben.

AVCHD-Beispiele:

Muss man die Tonspur transcodieren, würde ich mich entweder für MP3 (ASP) oder für AAC (AVC) entscheiden. Denn OGG/Vorbis hat hier (meinen Erfahrungen nach) einige Nachhaltigkeitsprobleme.

DivX7-Beispiele:

Man muss auch darauf achten, das der Blu-ray Disk - Standard "CRF" (gleichbleibende Qualität aber variable Bit-Rate) vorschreibt, damit fällt ein Multi-Pass-Encoding schon mal flach. Denn Multi-Pass-Encoding geht nur mit fester Bit-Rate.

Hinweis: Zum encoden wurde anfangs crf=16 verwendet, jetzt soll crf=20 Standard sein.

Der AVCHD-Lite-Standard macht nur zwei Einschränkungen gegenüber dem vollen AVCHD-Standard. Eine in der Video-Auflösung, es wird in diesem speziellen Standard nur 1280x720p unterstützt, und eine in der Videokompression, hier wird eine schwächere Kompressionsrate verwendet um es auch auf schwächerer Hardware einsetzen zu können!

Der volle AVCHD-Standard macht hier keine Einschränkungen gegenüber dem BD-Standard.

Allerdings werden hier ein paar Formate bevorzugt eingesetzt:

Aus diesem Grund ist der AVCHD-Standard sehr gut als Austausch-Standard geeignet.

Blu-ray Disk und AVCHD sehen in den Auflösungen 720p und 1080p folgende Eckdaten vor:

1. nur 8-Bit-Farbraum (4:2:0 ~ YV12) erlaubt
2. "Main"- und "High"-Profile erlaubt
3. max. 3 B-Frames sind erlaubt
4. "Group of Pictures" max. 15 Bildern (Frames)
5. 24 Bilder je Sekunde (Film)
6. Level 4.1
7. vbv-maxrate: 40000
8. vbv-bufsize: 30000
9. nur SAR 1/1
10. nur 16/9

Etwas verwirrend kann die Endung .m2ts der Dateien auf einer BD sein. Es sugeriert MPEG-2-Daten, dem ist aber nicht so!

Die Videosignale werden im MPEG-4-Datenkompressionsstandard (MPEG-4 AVC) aufgezeichnet, und dann in einen MPEG-2-Transport-Datenstrom zu übertragen.

Somit liegen MPEG-4-Daten in einem (erweiterten) MPEG-2-Container auf der BD.

• Video-Codec: H.264, x264
• Audio-Codec: AC-3
• Container-Format: MPEG-TS
• Dateiendung: .mts / .m2ts

Das AVC-Format, wie es auch von DivX-7 verwendet wird:

• Video-Codec: x264 (BD-kompatibel)
• Audio-Codec: AAC, Vorbis, AC-3 (DVD-Ton unverändert übernehmen)
• Container-Format: MKV

Damit die erstellten Videos auch auf einem BD-Player abgespielt werden können, darf auf keinen Fall die x264-Option "wpredp=2" gesetzt sein! Mit "wpredp=1" funktioniert es dagegen problemlos.

Panasonic präsentiert mit AVCCAM eine neue Camcorder-Generation: AVCHD-Camcorder

Panasonic & Sony erweitern Spezifikationen für HDTV-Camcorder-Format AVCHD

13.07.2006 (ks)

Panasonic und Sony haben die Spezifikationen für das neue HDTV-Camcorder-Format AVCHD in der Version 1.0 vorgestellt. War ursprünglich nur Aufnahme auf Mini-DVDs vorgesehen, so sollen AVCHD-Aufnahmen jetzt auch auf SD Cards, Memory Sticks und Festplatten möglich sein, was eine Austauschbarkeit und die Bearbeitung von Aufnahmen erleichtert. Die verwendeten Codecs sind MPEG-4 AVC/H.264 für Video und Dolby Digital für den Ton bei HDTV-Aufnahmen. Erste Geräte sind bislang noch nicht angekündigt worden. Nach Angaben von Panasonic sollen inzwischen auch Canon, Pioneer, Samsung und Sharp eine Unterstützung für AVCHD angekündigt haben.

AVCHD-Spezifikationen 1.0

AVCHD Information Web Seite

http://www.hennek-homepage.de/video/Neues-vom-Video-und-Bild-2007.htm

• HTML5
• U-Boot-Patentfrei (Open Source Videocodec)

Theora 1.0 hat sich in der Linux-Gemeinde schnell verbreitet, da es frei von U-Boot-Patenten ist. Leider kommt es gerade so nur an die Qualität des ASP-Formates ran und ist deshalb kein echter Konkurrent von H.264. Theora 1.1 bekam die Bezeichnung Thusnelda und ist schon deutlich besser als Theora 1.0. Theora ist Bestandteil des HTML5-Standard und wird von Firefox (ab Version 3.5) und anderen Internet-Browsern direkt abgespielt, leider aber (noch) nicht von Media-Playern fürs Wohnzimmer.

Ursprünglich gab es für Audio's und Video's nur das Container-Format OGG, leider fehlten ihm wichtige Funktionen, die dann jemand anders rein-gehackt hat. Dieses neue Container-Format wurde OGM genannt. Mit diesem Hack war die Xiph.Org Foundation nicht besonders glücklich und so haben sie zwei neue Container-Formate geschaffen. Jetzt wird für Audio das Container-Format OGA und für Video das Container-Format OGV verwendet. OGM soll nicht mehr verwendet werden und gilt als überholt, leider verwendet der Software-Video-Player VLC noch dieses Container-Format.

Die OGG-Endung ist leider so populär, das (bis jetzt) niemand von den neuen Dateiendungen Gebrauch macht.

Eine Analyse eines FFmpeg-Entwicklers schätzt die Qualitäten von OGG als Containerformat kritisch ein. Unter anderem wird angeführt, dass der Dateigrößen-Overhead mit 1% im Vergleich zum ISO-MP4-Format mindestens achtmal größer ist und auch dass OGG nicht geeignet ist für Anwendungen, die kurze Latenzen („low latency“) benötigen. Als Alternative mit diesbezüglich besseren Eigenschaften wird das Matroska-Containerformat empfohlen.

# ffmpeg2theora -p pro --sync --pp ci,tn:2,ac --optimize --speedlevel 0 -o Film.ogg Film.vob

Meine Persönlichen Erfahrungen haben allerdings gezeigt, dass mein schwacher Rechner ein Video aus einem OGG-Container ruckelfrei abspielen konnte aber genau das selbe Video aus einem MKV-Container stark geruckelt hat. Keine Ahnung warum, damals hatte ich noch nicht das nötige Hintergrundwissen um dem Problem nachgehen zu können.

• fortschrittliche Technik: Wavelet-Kompression
• U-Boot-Patentfrei

Dieser Codec benötigt wirklich viel Rechenleistung, hat aber auch das Potential den H.264 in die Tasche zu stecken, denn dieser Codec arbeitet endlich mal (genau wie Tarkin oder Snow) nach einer neuen und besseren Technik (Wavelet-Kompression).

Leider wird er von vielen Software-Video-Playern noch nicht unterstützt und ist deshalb auch nicht sehr verbreitet.

• http://de.wikipedia.org/wiki/Dirac_%28Codec%29

Dirac ist ein im Mai 2004 von der BBC veröffentlichter Video-Codec, der eine freie Alternative zu Codecs wie MPEG-2, Windows Media 9 oder MPEG-4 darstellen soll. Insbesondere wird darauf geachtet, dass keine von Dritten patentierten Technologien eingesetzt werden.

Dirac wurde am 21. Januar 2008 fertiggestellt. Die Referenz-Implementation ist in der Programmiersprache C++ geschrieben. Außerdem wurde unter dem Namen Schrödinger ein Projekt gestartet, das eine optimierte und portable Implementierung der Dirac-Spezifikationen zum Ziel hat.

Diese erste Implementierung wurde am 11. März 2008 fertiggestellt und liegt in Version 1.0 vor.

Der unter der Mozilla Public License 1.1 (MPL) veröffentlichte quelloffene Codec erlaubt die Relizenzierung des Codes unter der GNU General Public License 2.0 (GPL) und unter der GNU Lesser General Public License 2.1 (LGPL).

Um möglichst hohe Kompressionsraten ohne Artefaktbildung zu erreichen, nutzt Dirac eine Wavelet-Kompression sowie Techniken wie Motion Compensation und Arithmetisches Kodieren, die den Videocodec neben dem niedrigen Speicherverbrauch bei hohen Auflösungen auch für Internetstreaming-Anwendungen geeignet scheinen lassen. Die Bandbreite der Auflösungen reicht von QCIF (176×144 Pixel) bis hin zu HDTV (1920×1080 Pixel). Beim Release war in einer Auflösung von 1920×1080 Bildpunkten von einer Halbierung der Datenrate gegenüber dem MPEG-2 Standard die Rede. Damit wäre seine Kompressionsrate mit der von H.264 vergleichbar; durch die Waveletkompression dürfte Dirac diesem Codec, der noch auf diskreter Kosinustransformation basiert, jedoch bei der Bildqualität überlegen sein, insbesondere bei niedrigen Bitraten (zum Beispiel Internetstreaming). Dort wäre – bei gleicher Qualität – eine noch stärkere Datenreduktion möglich.

Neben der Freie-Software-Gemeinde entwickeln auch verschiedene Universitäten den Codec weiter.

• http://www.heise.de/newsticker/meldung/Mozilla-bringt-HD-Streaming-ORBX-in-den-Browser-1856595.html - 04. Mai 2013

Vor zwei Jahren ging der Rendering-Spezialist Otoy erstmals mit ORBX an die Öffentlichkeit. Der Streaming-Codec war zusammen mit dem Grafikunternehmen Autodesk entwickelt worden und soll nicht nur für Videoströme taugen, sondern auch für 3D-Objekte und Videos mit höherem Farbraum (bis zu 24 Bit pro Kanal).

Jetzt hat Otoy den Codec zusammen mit Mozilla zur JavaScript-Bibliothek ORBX.js weiterentwickelt. So soll jeder zu HTML5 kompatible Web-Browser grundsätzlich imstande sein, Videos mit bis zu einer Auflösung von 1080p bei 60 Hz wiederzugeben – ganz ohne zusätzliche Plug-ins.

Als Voraussetzung nennen Mozilla und Otoy einen Browser mit schneller JavaScript-Implementierung, der WebGL unterstützt. Mozilla will ORBX.js offenbar gegen den derzeit am meisten verbreiteten Standard H.264 positionieren, ähnlich wie es Google derzeit mit VP8/WebM versucht. Bei der fortgesetzten Nutzung von H.264 befürchtet Mozilla, ab 2016 hohe Lizenzkosten zahlen zu müssen.

ORBX.js bietet zusätzlich die Möglichkeit zur Virtualisierung von Anwendungen. Dank des effizienten Codec sollen sich auf Web-Servern gehostete Desktop-Anwendungen flüssig auf Smartphones und Tablets bedienen lassen. Die Ergebnisse der Benutzereingaben werden direkt in den Browser zurückgestreamt.

Über ORBX.js soll sich auch qualitativ hochwertiges Video-Streaming umsetzen lassen – ganz ohne proprietäre Plug-ins wie Adobe Flash oder Microsoft Silverlight. Zum Schutz von Bezahlinhalten will ORBX.js auf Wasserzeichen setzen, statt die Nutzung über DRM-Techniken einzuschränken. (ghi)

• Mozilla stellt HD-Codec ORBX in JavaScript vor - 04. Mai 2013

… Der verwendete Media-Codec heißt ORBX und wurde laut Otoy unabhängig von anderen Codecs entwickelt. Das Kodieren der Videos, die im Format 1080p60 gestreamt werden, wird von der Server-CPU unter Zuhilfenahme der Grafikprozessoren erledigt. Auf der Client-Seite werden so Lizenz- und Patentprobleme vermieden, und auf der Server-Seite können Wasserzeichen in die Streams eingebaut werden, was es Anbietern möglich macht, auf DRM zu verzichten. Der neue Codec kann es nach Angaben von Mozilla bei der Qualität und der Geschwindigkeit des Dekodierens mit H.264 aufnehmen. Dabei sind die Videos um 25% kleiner als bei H.264, die Farbtreue ist besser, und es ist mehr Parallelisierung möglich.

Wie Brendan Eich, CTO bei Mozilla und einer der Väter von JavaScript, ausführt, sei dies ein wichtiger Meilenstein auf dem Weg zu einem offenen Web. Die Geschwindigkeit von JavaScript sei inzwischen nicht mehr weit weg von sicherem nativen Code. Und die Möglichkeit, auf DRM zu verzichten, sei potentiell umwälzend.

• http://www.golem.de/news/orbx-videocodecs-der-zukunft-1305-99098.html - 06. Mai 2013

Otoy hat zusammen mit Mozilla einen bemerkenswerten Videocodec vorgestellt, der das Potenzial hat, die Codec-Landschaft nachhaltig zu verändern. Und das liegt nicht daran, dass der ORBX genannte Codec laut Entwickler bei gleicher Qualität etwa 25 Prozent kleinere Dateien erzeugt als H.264.

… ORBC.js ist in Javascript und WebGL umgesetzt.

ORBX.js läuft so auf vielen modernen Browsern, ohne dass diese ihn explizit unterstützen müssen. Websites, die ORBX.js nutzen wollen, können den entsprechenden Code einfach in die Website integrieren, so dass Nutzer den Codec herunterladen, aber nicht installieren müssen. Das funktioniert auch auf Smartphones und Tablets.

siehe auch: YouTube Video Codecs Comparison (AV1 vs h264 vs VP9)

Hier stelle ich meine persönliche Meinung dar, ich erhebe also keinen Anspruch auf Absolutismus…

Mein DVD-Recorder von Philips generiert mir DVDs mit dem Video-Codec MPEG-2, dem Audio-Codec AC3 und dem Container-Format PS mit der Dateiendung VOB, also im DVD-Standardformat.

MPEG-PS file format detected.
VIDEO:  MPEG2  720x576  (aspect 2)  25.000 fps  4380.0 kbps (547.5 kbyte/s)
AUDIO: 48000 Hz, 2 ch, s16le, 256.0 kbit/16.67% (ratio: 32000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)

Was mich daran stört ist die Tatsache, das 2 Stunden Filmmaterial im DVD-Standardformat, ca. 4,3 GB an Plattenplatz benötigen. Das ist mir entschieden zu viel!

Als Alternativ-Formate kommen für mich nur freie Formate in Frage. Leider gibt es im Moment nur zwei wirklich freie Formate

1. Theora/Thusnelda
2. Dirac/Schroedinger

die beide (zu meinem Bedauern) von keinem Hardware-Media-Player fürs Wohnzimmer abgespielt werden können.

Da ich aber meine Filme nicht nur am PC sehen möchte, sondern über eine Multimedia-Box, musste ich die in Frage kommenden Codecs um diejenigen erweitern, die unter der GPL stehen aber möglicherweise sogenannte U-Boot-Patente enthalten können.

Auf Grund der Angst vor diesen U-Boot-Patenten liefert kein großer Betriebssystemhersteller diese Codecs in seinen Produkten mit, nichteinmal die großen Linux-Distributionen (Ubuntu, Fedora, openSUSE, Mandriva, …) haben diese Codecs in ihrer Grundausstattung.

Grundsätzlich muss man sagen, es gibt keinen perfekten Codec. Codecs die wenig Rechenleistung brauchen, komprimieren schlecht und Codecs die besser komprimieren, brauchen ein vielfaches an Rechenleistung. Hier ist also auch (wie überall im Leben) der goldene Mittelweg gefragt.

Den VCD-Standard sehe ich als völlig veraltet an.

In diesem Format liegen meine Filme ja schon vor, der in meinen Augen aber auch nicht mehr Zeitgemäß.

Der Xvid-Codec aus diesem Standard ist der im Moment vielseitigste, da er fast überall abgespielt werden kann. Mit ihm kann ich gegenüber MPEG-2 bis zu 40% Plattenplatz einsparen und die Filme werden auch in meinem DVD-Player von Philips abgespielt.

Der x264-Codec kann mehr Platz einsparen als Xvid-Codec und wird aber nur von neueren Playern (Blu-ray Disk & Co.) abgespielt, sowie von Multimedia-Boxen. Allerdings dauert das encoden auch deutlich länger.

Thusnelda ist ungefähr so gut wie der Xvid aber absolut frei und wird mittlerweile von fast jeder PC-Software abgespielt. Leider wird er (bis jetzt) nur auf dem PC abgespielt!

Auf diesen Codec halte ich schon lange ein Auge. Er ist absolut frei und basiert auf fortschrittliche Techniken, er ist quasi der Codec der nächsten Generation. Leider wird er nur von ein paar PC-Software-Playern und garkeinen Hardware-player unterstützt.

Wie wir gesehen haben gibt es mehr Einschränkungen als Möglichkeiten. Unter dem Gesichtspunkt, dass ich auf jeden Fall Plattenplatz einsparen möchte und nur einen Codec mit einer gewissen Unterstützung von Seiten der Heimelektronik in Frage kommt, kommen nur noch der recht weit entwickelte Xvid und der recht gut komprimierende x264 in Frage.

Der Xvid läuft auch auf meinem DVD-Player sowie auf einem Pentium-III prima (hat aber recht blasse Farben) und der x264 wird in Zukunft besser unterstützt werden, in erster Linie durch die BD-Player.

Allerdings ist es mit dem Video-Codec alleine nicht getan, aus kompatibilitätsgründen kommt für mich auch nur ein einziger Audio-Codec sowie ein einziges Container-Format in Frage. Denn die beste Unterstützung wird der AVCHD-Standard (x264 + AC-3 + .mts) erfahren, da dieses Format von allen BD-Playern gelesen werden kann und es auch eine Untermenge des HDTV-Standards ist. Der AC-3-Audio-Codec ist ja auf den Videos vom DVD-Recorder schon drauf, den könnte man einfach durch kopieren direkt übernehmen.

Ich werde bei den Bildformaten aus zwei Gründen nicht auf Kompatibilität achten:

1. es gibt bereits jetzt eine unüberschaubare Vielzahl an verschiedenen Bildformaten und das wir sicher in Zukunft bestimmt nicht besser, deshalb glaube ich nicht, dass deswegen in Zukunft Kompatibilitätsprobleme zu befürchten sein werden;
2. wenn man eine PAL-Aufnahme in ein "720p"-AVCHD-Lite-Format umwandelt, dann sind das Ergebnis und die Quelle ungefähr genausogroß;

das würde dann also garkeinen Sinn machen.

Alternativ käme noch das DivX-Format ab der Version 7 in Frage. Hier wird der selbe Video-Codec eingesetzt (H.264), allerdings kann man ihn mit dem Audio-Codec OGG/Vorbis oder AAC kombinieren. Verpackt wird dann alles in das freie Container-Format MKV. Das ist eigentlich genau das was ich will, leider ist es aber zu allen anderen Standard's inkompatibel.

Meine Multimedia-Box kann beides abspielen und ob zukünftige BD-Player das auch können werden, wird sich zeigen.

Immerhin ist AVCHD ein sehr genau definierter Standard und sollte somit auch überall funktionieren wo AVCHD drauf steht (aber sicherlich meistens nur mit dem MP4-Container) und vielleicht noch überall dort wo Blu-ray Disk drauf steht. Denn beides ist ja pracktisch der gleiche Inhalt (Codec's und Container), nur das AVCHD in der Regel eine einzige Datei ist und Blu-ray Disk Verzeichnisse mit mehreren Dateien sind.

Mit dem HDTV-Format (x264 + AAC + .mp4) kann ich mich jedenfalls nicht anfreunden, da es praktisch keine Einschränkungen hat (besonders hinsichtlich der Bildwiederholrate) und deshalb wohl wieder ein Glücksspiel sein wird, ob es einer abspielen kann oder nicht.

Das kompatibelste Container-Format wird mit Sicherheit der MP4-Container sein, allerdings werde ich den nicht einetzen, da er nicht frei ist und für das freie Container-Format MKV deutlich bessere Werkzeuge zur Verfühgung stehen.

Und wenn die Heimelektronik auch in Zukunft weiterhin DivX unterstützen wird, wird sie auch dieses Container-Format unterstützen.

AV1

siehe auch:

• https://www.computerbase.de/2018-03/av1-aomedia-vp9-nachfolger/ - 2018-03-29, 9:09 Uhr

Quelle: Freier Videocodec AV1 - 2016-12-19, 9:00 Uhr

Der freie Videocodec AV1 gilt als Nachfolger von Googles VP9 und wird mit großer Unterstützung der Industrie erstellt. Er ist zwar noch nicht fertig, trotzdem zeigt sich bereits, dass er großes Potenzial hat, die MPEG-Codecs H.264 und H.265 langfristig zu verdrängen.

In den vergangenen Jahrzehnten unterlag der Einsatz von Videocodec-Technik einer gewissen Hybris. Einerseits sind die Codecs der Moving Picture Experts Group (MPEG), wie etwa H.264 alias AVC und dessen Nachfolger H.265 alias HEVC, durch Patente geschützt. Andererseits sind die wohl besten Software-Encoder und Decoder meist freie Software. Die für die Patente nötigen Lizenzzahlungen widersprechen aber oft einer freien Weiterverteilung und sind vor allem für H.265 extrem hoch. Der neue und freie Videocodec AV1 soll diese Probleme überwinden und dabei noch besser sein als H.265, was beides schon in wenigen Monaten erreicht werden könnte.

Der Codec AV1 entsteht beim Konsortium Alliance for Open Media (Aomedia). In der Aomedia organisieren sich verschiedene Unternehmen, die wohl sämtliche Bereiche der Industrie abdecken, die Interesse an einem Videocodec haben. Dazu gehören neben Hardwareproduzenten wie Intel, AMD oder Nvidia ebenso jene, die die Logik für En- und Decoding in Hardware lizenzieren, wie Verisilicon, Allegro und ARM.

Wichtig ist die Aomedia für Inhalteanbieter wie Netflix und Amazon, aber auch für die BBC sowie weitere Anbieter von Streaming-Lösungen etwa für Videokonferenzen. Wohl am wichtigsten sind aber die Wegbereiter beim Erstellen eines neuen Videcodecs: Google, Mozilla und Cisco.

Denn AV1 geht aus der Zusammenarbeit der eben genannten Firmen hervor und liefert dabei beeindruckende Ergebnisse. Doch obwohl eben diese Zusammenarbeit an einem gemeinsamen Ziel folgerichtig erscheint, war es bis dahin ein langer Weg. Vorgelegt hat die hauptsächlich von Mozilla unterstützte Xiph Foundation mit der Ankündigung des Codecs Daala im Sommer 2013. Hauptziel war es, die in H.264 und H.265 genutzten theoretischen Grundlagen durch völlig neue Ansätze zu ersetzen, was deutlich bessere Ergebnisse liefern sollte.

Kurz zuvor hatte Google den freien Code VP9 veröffentlicht, dessen Nachfolger VP10 Google eigentlich in diesem Jahr hätte veröffentlichen wollen. Doch die für VP10 geplanten Verbesserungen werden mit Details aus Daala kombiniert. Hinzu kommen Bestandteile von Ciscos Codec Thor. Diese Kooperation deutete sich bereits im Herbst 2015 an. In diesem Jahr ist aus diesen Einzelteilen langsam der Open-Source-Codec AV1 der Aomedia erstellt worden.

Doch dass sich Open Source allein nicht zwingend durchsetzt, zeigt sich an VP9. Dieser Codec wird zwar von vielen Browsern unterstützt und etwa von Youtube standardmäßig verwendet, eine breite Marktdurchdringung hat er aber immer noch nicht erreicht. Der Grund dafür liegt wahrscheinlich an der über Jahrzehnte gewachsenen Bindung der Industrie an H.264.

Ein Wechsel hin zu VP9 ist für viele Beteiligte vermutlich einfach zu aufwendig, zudem gibt es technisch nur wenige Gründe, VP9 zu verwenden. So ist etwa die Hardwareunterstützung für H.264 in nahezu jedem aktuellen Gerät verfügbar, für VP9 gilt das nicht.

Vermutlich wird sich AV1 dennoch deutlich schneller verbreiten als VP9, was wiederum auf einen Technikwandel zurückzuführen ist, der momentan stattfindet. Denn mit der Einführung von 4K-Auflösungen und Techniken wie HDR und einem größeren Farbraum ist der Wechsel auf eine neue Codec-Generation gekommen.

Allerdings kostet der Einsatz von H.265 deutlich mehr als H.264. Das liegt auch daran, dass mit der MPEG LA und der HEVC Advance gleich zwei Patentkonsortien existieren, die entsprechende Lizenzzahlungen verlangen. AV1 hingegen ist nicht nur Open Source, sondern die Aomedia verteilt den Codec auch mit einer Patentlizenz, die einen kostenfreien Einsatz ermöglicht.

Diese juristischen Details sind für die Beteiligten aber nur einer von zwei Gründen für AV1. Wohl noch wichtiger ist die Qualität des Videocodecs selbst. Und auch hier liefert AV1 überzeugende Ergebnisse.

Die Hauptaufgabe eines Videocodecs ist es, die Originalaufnahmen möglichst stark zu komprimieren. Dabei gehen zwangsläufig Bildinformationen verloren, so dass der Videocodec mit Hilfe von Erkenntnissen über die menschliche Wahrnehmung und einigen mathematischen Tricks dennoch ein akzeptables Bild liefern muss. Welche Qualität von Nutzern und Produzenten letztlich akzeptiert wird, hängt sehr von der Technikevolution ab.

Das zeigt sich im direkten Vergleich der drei Videcodecs AV1, H.265 und H.264. Besonders gut sichtbar werden die Unterschiede bei vergleichsweise kleinen Bitraten. In einem zugegeben nicht repräsentativen Kurztest haben wir dazu den Trailer von Sintel in einer 1080p-Auflösung auf eine durchschnittliche Datenrate von 300 KBit/s komprimiert. Dazu haben wir die Standardeinstellungen der Encoder x264, x265 und Aomenc genutzt.

Wenig überraschend ist die optische Qualität von H.264 im Verhältnis zu den neueren Codecs. Denn H.264 zeigt bei derart starker Kompression die typischen und bekannten Blockartefakte, die bestimmte Szenen schlicht zu einer Schachbrettoptik verkommen lassen, so dass der tatsächliche Bildinhalt kaum noch zu erkennen ist. AV1 und H.265 liefern dagegen deutlich besser sichtbare Details.

Unterschiede zwischen den beiden jüngeren Codecs, also AV1 und H.265, sind auf den ersten Blick nur schwer zu erkennen. Bei näherer Betrachtung insbesondere von Einzelbildern, schneidet AV1 besser ab als H.265, was vor allem bei kleinteiligen Bildbestandteilen auffällt.

Dieses Ergebnis ist wenig verwunderlich, immerhin ist AV1 jünger als H.265 und entspricht damit dem typischen Fortschritt der Codec-Evolution. Außerdem nutzt AV1 wie erwähnt einige neue Konzepte zum Aufbau eines Videocodecs. Der an der Entwicklung von Daala beteiligte Entwickler Jean-Marc Valin berichtete in diesem Jahr über eben diese Fortschritte.

Die verbesserte Bildqualität auch im Vergleich zu H.265 ist erklärtes Ziel der Entwickler. Laut den Plänen der parallel zu den Arbeiten an AV1 stattfindenden Standardisierung der IETF für einen Internet-Videocodec (Netvc) soll der neue Standardcodec sogar bis zu 25 Prozent besser werden als H.265. AV1 gilt zurzeit als einziger möglicher Kandidat für den Netvc-Standard.

Mit den besseren Bildern von AV1 einher geht derzeit aber noch ein deutlicher Geschwindigkeitsnachteil beim Encoding der Inhalte. Während x264 und x265 über Jahre hinweg auf die Verwendung mehrerer CPU-Kerne und bestimmter CPU-Befehlssatzerweiterungen hin optimiert worden sind, läuft AV1 derzeit nur gut mit einem Thread und ist damit auch extrem langsam.

Verständlicherweise liegt das Hauptaugenmerk der Entwickler von AV1 derzeit noch auf dem Codec selbst und nicht zwangsläufig auf der Optimierung der dafür benötigten Werkzeuge. Gemäß den Arbeiten im Netvc-Gremium ist die größere Komplexität beim Encoding aber durchaus tolerierbar.

Da AV1 mit fast dem gleichen Funktionsumfang wie H.265 schon vor dem Abschluss der Arbeiten bereits teils deutlich bessere Ergebnisse liefert, ist es wahrscheinlich, dass AV1 vielleicht schon im kommenden Jahr von ersten Anbietern versuchsweise eingesetzt wird. Vermutlich wird AV1, dank der breiten Unterstützung der Hardware-Hersteller der Aomedia-Organisation, schnell umgesetzt.

• https://trac.ffmpeg.org/wiki/Encode/AV1

hier wird ein Film mit Dolby-Digital-Sound übersetzt (ohne Untertitel):

> ffmpeg -i Originaler_Film_als_Quelle.mpg  -c:v libaom-av1 -b:v 0 -crf 30 -c:a libopus -b:a 224k -af channelmap=channel_layout=5.1 -f matroska -y Film.mkv

hier wird ein Film übersetzt, der 1x Video-, 2x Audio- und 6x Untertitelspuren hat:

> ffmpeg -probesize 9223372036G -analyzeduration 9223372036G -fflags +genpts -i Originaler_Film_als_Quelle.mpg  -map 0:v -c:v libaom-av1 -b:v 0 -crf 30 -vf pad='max(iw\,ih*(16/9)):ow/(16/9):(ow-iw)/2:(oh-ih)/2' -keyint_min 2-8 -map 0:a:0 -c:a libopus -b:a 224k -af channelmap=channel_layout=7.1 -map 0:a:1 -c:a libopus -b:a 224k -af channelmap=channel_layout=5.1 -map 0:s:0 -c:s copy  -map 0:s:1 -c:s copy  -map 0:s:2 -c:s copy  -map 0:s:3 -c:s copy  -map 0:s:4 -c:s copy  -map 0:s:5 -c:s copy  -disposition:s:0 default -f matroska -y Film.mkv

Diesen Optionen haben folgende Bedeutungen:

• -map 0:v:0 -c:v ⇒ die erste 0:v:0 - Video-Spur 0:v:0 - aus der ersten Datei 0:v:0
• -map 0:a:1 -c:a ⇒ die zweite 0:a:1 - Audeo-Spur 0:a:0 - aus der ersten Datei 0:a:0
• -map 0:s:3 -c:s ⇒ die vierte 0:s:3 - Untertitel-Spur 0:s:0 - aus der ersten Datei 0:s:0
• pad='max(iw\,ih*(16/9)):ow/(16/9):(ow-iw)/2:(oh-ih)/2' ⇒ hier werde in geeigneter Weise schwarze Balken in das Bild eingefügt, um am Ende ein perfektes Bild im Format 16/9 zu bekommen

Eine 10-Sekunden-Sequenz von einer DVD (720x576i) hat auf der CPU AMD Athlon II X4 605e 2,3GHz (CPU Benchmark: 2734) folgende Übersetzungszeiten benötigt:

• -crf 32 ⇒ ca. 86 Minuten → Datei war ca. 1,5 MB groß; gute Qualität
• -crf 63 ⇒ ca. 52 Minuten → Datei war ca. 0,3 MB groß; schlechte Qualität bei Bewegung, wenn keine Bewegung im Bild ist, dann akzeptable Qualität
  • zum Vergleich: Der Codec VP9 hat mit -crf 63 ⇒ ca. 8 Minuten
    • Datei war ca. 1,4 MB groß; in allen Punkten eine bessere Qualität als AV1 mit -crf 63
    • VP9 ist also ca. 7 mal schneller als AV1 und produziert ca. 4,6 mal so große Dateien.

HDR (High Dynamic Range / Dolby Vision)