Videoformate verlustfrei konvertieren?

[cuco]

Gibt es die denn überhaupt öffentlich? Zu meinen Dokumentationen über H.264 hat man mir erzählt, dass es rechtlich sehr kritisch wäre, wenn ich sie weiter verbreite. Schätze, das ist bei H.265 nicht anders. Da werden ja schließlich auch Patente drauf angemeldet usw,

 

[Helios]

Wen interessiert die Mathematik, wenn man etwas hören will? Ich komme noch aus der Hifi-Ära und halte komprimierte Musik generell für "Teufelszeug"!

Na mich, und wie... ist ja unter anderem schliesslich auch mein Beruf ... und zugleich mein Hobby .

Gibt es die denn überhaupt öffentlich? Zu meinen Dokumentationen über H.264 hat man mir erzählt, dass es rechtlich sehr kritisch wäre, wenn ich sie weiter verbreite. Schätze, das ist bei H.265 nicht anders. Da werden ja schließlich auch Patente drauf angemeldet usw,

Weiss es eben nicht. Ist jedoch gut möglich. Habe jetzt zwar explizit etwas über H.265 gesucht. Wie es mit H.264 aussieht, kann ich nicht sagen.

Nachtrag: Glaube, der H.264 ist eine DCT. Habe mich bis dato mit diesem Thema nie befasst.

 

[cuco]

Wen interessiert die Mathematik, wenn man etwas hören will? Ich komme noch aus der Hifi-Ära und halte komprimierte Musik generell für "Teufelszeug"!

Kann ich verstehen, meine Musik ist nach Möglichkeit auch FLAC. Aber unkomprimiertes Videomaterial hat in FullHD bei 30 fps und 16bit Farbtiefe unkomprimiert 1 Gbit/s nötig. Mit einem typischen verlustfreien Codec wie HuffYUV bleiben ca. 400Mbit/s übrig. Ein typischer Spielfilm mit 120 min. Länge ist dann über 350 GB groß. Das nimmt keiner in Kauf. Vor allen Dingen hören unsere Ohren Unterschiede viel eher als unsere Augen Unterschiede sehen.

//EDIT: Zuzüglich Tonspur!

 

[toby]

Na mich, und wie... ist ja unter anderem schliesslich auch mein Beruf ... und zugleich mein Hobby .

http://www.reddit.com/r/technology/comments/17abtp/h265_is_approved_potential_to_cut_bandwidth/

 

[toby]

Vor allen Dingen hören unsere Ohren Unterschiede viel eher als unsere Augen Unterschiede sehen.

Das ist sehr gewagt behauptet: Nur die wenigsten Menschen haben ein absolutes Gehör und leiden unter Dissonanzen. Die Wahrheit ist, dass man die Augen schließen kann, die Ohren aber nicht.

 

[Helios]

http://www.reddit.com/r/technology/comments/17abtp/h265_is_approved_potential_to_cut_bandwidth/

Danke für den Link.

Which brings us to the final point: the compression into h265 is vastly more complex than h264.

Scheint so, als würde das mathematische Verfahren jedoch nicht zugänglich sein... aus Gründen, wie sie cuco bereits erwähnte.

Das ist sehr gewagt behauptet: Nur die wenigsten Menschen haben ein absolutes Gehör und leiden unter Dissonanzen. Die Wahrheit ist, dass man die Augen schließen kann, die Ohren aber nicht.

Ist korrekt.

 

[schoerg]

Erzähl' das mal einem unkomprimierten AVI oder einem DV-File von der Kamera: Die lachen sich scheckig...

http://pwnhofer.at/screenshots/2013-03-11_14-45-05.png

Ich habs gerade versucht. Unkomprimiertes per Fraps aufgenommenes Video, 1920*1200 60 FPS für 4 Sekunden. WinRar hat aus der Datei nichts komprimieren können.

Hier nochmal ein neuer Versuch, diesmal mit bzip2.

http://pwnhofer.at/screenshots/CWindowssystem32cmd.exe_2013-03-11_14-51-58.png

 

[cuco]

http://pwnhofer.at/screenshots/2013-03-11_14-45-05.png

Ich habs gerade versucht. Unkomprimiertes per Fraps aufgenommenes Video, 1920*1200 60 FPS für 4 Sekunden. WinRar hat aus der Datei nichts komprimieren können.

Hier nochmal ein neuer Versuch, diesmal mit bzip2.

http://pwnhofer.at/screenshots/CWindowssystem32cmd.exe_2013-03-11_14-51-58.png

RAR holt immerhin noch 4,5% raus. Viel ist das aber nicht. Und unkomprimiert wird wohl keiner sein Videomaterial speichern, wenn dann verlustfrei komprimiert. Das bringt deutlich mehr als RAR mit seinen 4,5% (HuffYUV ca. 60%). Und wenn man danach nochmal RAR/ZIP anschmeißt wird man wie schon gesagt feststellen, dass das ganze gar nix bringt oder eher sogar größer wird.

 

[schoerg]

Naja, Lagarith bringt auch nichts besseres hin.

In der Standard-Einstellung (RGB, mit Nullframes) wird daraus eine 320 MB große Datei.

Mit YV12 und Nullframes immerhin 207 MB, dafür kommen im VLC Bildfehler. (MPC-HC nicht)


Edit:

Jetzt mal x264 lossless:

C:\Fraps\Movies>x264 -q0 --preset placebo "iw3mp 2013-03-11 14-41-13-26.avi" -o
x264lossless.mkv
ffms [info]: 1920x1200p 0:1 @ 60062/1001 fps (vfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x264 [info]: profile High 4:4:4 Predictive, level 5.1, 4:2:0 8-bit
x264 [info]: frame I:4     Avg QP: 0.00  size:1373036
x264 [info]: frame P:290   Avg QP: 0.00  size:551899
x264 [info]: mb I  I16..4..PCM: 28.4% 13.0% 58.5%  0.0%
x264 [info]: mb P  I16..4..PCM:  4.4%  3.5%  3.9%  0.0%  P16..4: 20.2%  8.0% 13.
4%  5.3%  3.4%    skip:38.0%
x264 [info]: 8x8 transform intra:28.2% inter:47.7%
x264 [info]: coded y,uvDC,uvAC intra: 98.2% 98.5% 98.5% inter: 53.7% 56.2% 56.1%


x264 [info]: i16 v,h,dc,p: 42% 58%  1%  0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 30% 63%  2%  1%  1%  1%  1%  0%  1%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 45%  4%  3%  3%  3%  3%  2%  2%
x264 [info]: i8c dc,h,v,p:  7% 60% 32%  1%
x264 [info]: Weighted P-Frames: Y:0.3% UV:0.0%
x264 [info]: ref P L0: 61.9%  7.2%  8.1%  5.3%  5.5%  2.8%  2.1%  1.9%  1.2%  0.
8%  0.8%  0.6%  0.4%  0.5%  0.4%  0.4%
x264 [info]: kb/s:270283.03


encoded 294 frames, 0.60 fps, 270283.96 kb/s

 Directory of C:\Fraps\Movies


11.03.2013  15:42    <DIR>          .
11.03.2013  15:42    <DIR>          ..
23.08.2000  17:00            33 280 huffyuv.dll
24.08.2000  01:29             1 699 huffyuv.inf
11.03.2013  15:09       274 673 024 iw3mp 2013-03-11 14-41-13-26.avi
10.04.2011  19:47    <DIR>          Lagarith_1327
11.03.2013  15:40        10 538 496 x264.exe
11.03.2013  15:50       165 547 065 x264lossless.mkv
               5 File(s)    450 793 564 bytes
               3 Dir(s)  123 634 089 984 bytes free

Bestes Ergebniss bisjetzt. Dafür 0,60 Frames pro Sekunde auf einem Intel Q9400 beim Encodieren.

Benutzt man die schnelle Option (x264 -q0 --preset ultrafast -I1) ist das Video nach 5 Sekunden fertig, hat dafür aber auch 370 MB.

Damit ist jeder ernsthafte Versuch unkomprimiertes Video zu speichern zum Scheitern verurteilt.

 

[Ede_123]

@ Helios:
Hier steht doch eine ganze Menge zu den Details: http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Coding_tools

Die Codierung selbst erfolgt stets über mehrere Schritte, die wichtigsten dabei (bei allen gängigen Codecs vorhanden) sind:

• Aufteilung des Bilds in Blöcke und Bewegungserkennung (nachfolgende Frames enthalten jeweils Referenzen zum Inhalt der vorhergehenden).
• Der Kern ist, wie du schon richtig erwähnt hast, stets die DCT, die z.B. auch bei JPG und MP3 zum Einsatz kommt. Unterschiedlich starke Kompression wird dann einfach durch Abbrechen der Reihenentwicklung nach mehr oder weniger Gliedern erreicht.
• Am Ende erfolgt stets eine Entropiekodierung ("packen"). Deshalb bringt auch ein erneutes packen mit üblichen Datenkompressionsprogrammen nichts mehr.

 

[cuco]

Das ist aber H.264, nicht H.265. Helios (und mich auch) interessiert, was an H.265 neu ist.
//EDIT: Hier stand Müll.

 

[Helios]

@Ede_123:

Ist mir in sämtlichen Details bewusst. Mich interessiert die mathematische Transformation, sprich, die Mathematik, welche vollzogen wird, also die mathematische Formulierung... kurzum, die Formeln.

 

[lukasbu]

also in der ct 14/2012 war ein relativ tiefgreifender Artikel samt prallem Literaturverzeichnis falls das für eure Hobbybeschäftigung taugt

Ich werd derzeit mal lieber fürs Abitur lernen, anstatt mich damit zu befassen .

Gruss, Lukas

 

[toby]

also in der ct 14/2012 war ein relativ tiefgreifender Artikel samt prallem Literaturverzeichnis falls das für eure Hobbybeschäftigung taugt. Ich werd derzeit mal lieber fürs Abitur lernen, anstatt mich damit zu befassen .
Gruss, Lukas

Vorbildlich! Die Prokastination ist jetzt Dein härtester Feind....

 

[Ede_123]

@cuco: Das war sehr wohl H.265 alias High Efficiency Video Coding (HEVC) was ich beschrieb.

@Helios: Wenn du die ganzen Details kennst, dann kennst du die Mathematik doch auch schon bereits. Wenn man z.B. weiß was eine DCT ist (und davon gehe ich bei dir mal aus) sind der Rest nur noch Implementierungsdetails. An der Mathematik der DCT ändert sich nichts.

Nichtsdestotrotz, wenn du dich mit Implementierungsdetails rumquälen willst gibt's dazu alle Infos beim Fraunhofer HHI.
Dort findet man zum Beispiel den aktuellen "Working Draft" zu HEVC Spezifikation oder aber die Referenzimplementierung in C++. Am Ende der Seite findest du wissenschaftliche Veröffentlichungen zum HEVC Standard.

 

[Helios]

@Helios: Wenn du die ganzen Details kennst, dann kennst du die Mathematik doch auch schon bereits. Wenn man z.B. weiß was eine DCT ist (und davon gehe ich bei dir mal aus) sind der Rest nur noch Implementierungsdetails. An der Mathematik der DCT ändert sich nichts.

Nichtsdestotrotz, wenn du dich mit Implementierungsdetails rumquälen willst gibt's dazu alle Infos beim Fraunhofer HHI.
Dort findet man zum Beispiel den aktuellen "Working Draft" zu HEVC Spezifikation oder aber die Referenzimplementierung in C++. Am Ende der Seite findest du wissenschaftliche Veröffentlichungen zum HEVC Standard.

Danke, schaue ich mir gerne später an. Habe noch zu arbeiten. Ja klar, mit der DCT und so ziemlich allen anderen, zumindest gängigen, Transformationen bin ich so ziemlich mehr als vertraut... sozusagen schon mehr als 20 Jahren per "Du" .

 

[cuco]

@cuco: Das war sehr wohl H.265 alias High Efficiency Video Coding (HEVC) was ich beschrieb.

:facepalm: Ups, sorry. Irgendwie hatte ich gerade in Erinnerung, dass HEVC für H.264 stand...