Diskussion:H.264
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit
oder --~~~~.
| Archiv |
| Wie wird ein Archiv angelegt? |
html5 Format
Auch für html5 Webseiten gilt der H264 als Video standart. Anders als bei Flash Video lassen sich H264 Videos mit ein paar Zeilen html5 Code in eine Webseite einbinden.(nicht signierter Beitrag von 79.220.139.4 (Diskussion) )
Subjektive Tests?
Was sind "subjektive Tests"? (Von der MPEG Group durchgeführt).. --Retoreto 22:58, 9. Jun 2005 (CEST)
- Das sind Tests denen er Autor des Artikels nicht zustimmt ;-) 84.169.176.249
- (Der vorstehende Beitrag stammt von 84.169.176.249 – 23:40, 25. Sep. 2005 (MESZ) – und wurde nachträglich vollständig signiert.)
Ich vermute, das sind Tests bei denen einer Gruppe von Testpersonen dieselben Videos mit verschiedenen Verfahren Codiert gezeigt werden und die Testpersonen angeben müssen, welcher für sie (subjektiv) der beste Codec ist.
Solche Tests werden auch bei der Entwicklung von Musik-Codecs eingesetzt, um herauszufinden, wieviel Information man "weglassen" kann, ohne dass es allzu störend wird.
-- 84.158.238.57 12:01, 29. Sep 2005 (CEST)
- Eine Tabelle mit den doch recht hohen technischen Mindestanforderungen zum Abspielen bei verschiedenen Auflösungen wäre nicht schlecht- ansatzweise gibt es sowas in diesem Artikel bei Computerbase: [1]
- Vielleicht mag die Infos mal jemand in den Artikel einarbeiten, ich kenn mich mit der Materie nicht so besonders gut aus. --Bassaar 11:03, 5. Aug 2006 (CEST)
Codec durch Standard ersetzt
Ich habe Codec an den nötigen Stellen durch Standard ersetzt. Ein Codec wandelt ein Signal in ein anderes um. Ein Standard, wie er hier gegeben ist, beschreibt den (genauen) Weg dazu. H.264 tut "nur" letzteres.
(Der vorstehende Beitrag stammt von 85.74.51.34 – 20:03, 9. Dez. 2005 (MEZ) – und wurde nachträglich signiert.)
Hyperlink „sklmp4 – Ein freier H.264 En- und Decoder“
Der Link lässt sich bei mir weder per FF noch per IE aufrufen. FF meckert über abgeschaltete Cookies (Fehler: Umleitungsfehler) und der IE wartet etwa eine Minute, um dann gar keine Reaktion zu zeigen.
(Verzeihung, sollte ich die Wikipedia-Discussion-Regeln nicht ganz einhalten. Darin bin ich noch nicht ganz firm.) mono
(Der vorstehende Beitrag stammt von 84.191.192.169 – 02:08, 26. Aug. 2006 (MESZ) – und wurde nachträglich signiert.)
MPEG-4/ASP
Was ist denn das genau?
Im Artikel steht nur, dass sich H.264 bzw. MPEG-4/AVC deutlich davon unterscheidet.
Gibt es da was genaueres?
80.139.164.161 21:56, 28. Jan. 2007 (CET)
Deblocking-Filter bei H.263?
Im Artikel steht: ".Während sich die bisherigen MPEG-Codecs ausschließlich auf eine optionale, externe Nachbearbeitung/Filterung (engl. "postprocessing") verlassen, ist ein Deblocking-Filter integraler Bestandteil von H.264 (wie auch schon bei H.263)." Stimmt das bzgl. H.263? Meiner Ansicht nicht, denn wenn Deblocking schon drin wäre, bräuchte man ja keine Nachbearbeitung merh, oder? Insofern widerspricht sich der Satz selbst.... weiß dazu jemand mehr? Danke & MFG -- Mons Maenalus 01:36, 12. Apr. 2007 (CEST)
- Sorry, das ist keine Meinungsfrage.
- Der H.263 Loopfilter ist in Annex J "Deblocking Filter Mode" beschrieben.
- Ein Widerspruch ist da nicht, Annex J ist EINE Möglichkeit, Blockartefakte zu vermindern. (Der Unterschied is übrigens sehr deutlch sichtbar.) Es könnte jedoch andere/zusätzliche Algortithmen geben, die das Bild noch weiter verbessern. So etwas zu implementieren ist natürlch keinem Hersteller "verboten. Außerdem ist dieser Filter speziell für Deblocking. Ein Encoder verursacht aber auch andere Artefakte (Moskito-Artefakte z.B.), die mit Postprocessing möglicherweise vermindert werden können.
- 25. Jun. 2007
- (Der vorstehende Beitrag stammt von Pelikan3857 (Beiträge) – 12:13, 25. Jun. 2007 (MESZ) – und wurde nachträglich vollständig signiert.)
Erweiterung
Welche Erweiterung hat so ne Datei? Ich mein nicht die möglichen Container wie MKV oder MP4. -- 91.43.60.21 23:14, 5. Apr. 2009 (CEST)
- Was meinst du denn dann? Wenn du ein H.264 kodiertes Video am PC anschauen willst, benötigen wohl fast alle Player ein Containerformat, in das der rohe Videodatenstrom verpackt wird. Ansonsten kannst du deinen Rohdatenstrom nennen, wie du willst. Ich hab meistens mit .264-Dateien gearbeitet (ohne Container). HerrPi 12:47, 18. Aug. 2009 (CEST)
Interpolation bei 1/4-Pixel Genauigkeit
Im deutschen Artikel steht, dass zur Generierung der Zwischenpixel bei Quarter-pixel Genauigkeit ein FIR-Filter zum Einsatz kommt. In der englischen Version steht allerdings, dass die Zwischenpixel bei Quarter-pixel aus den linear Interpolierten Half-pel erzeugt werden. Und diese sind wiederum mit Hilfe eines six-tap Filters errechnet. Ist im Deutschen also entweder missverständlich geschrieben oder falsch. HerrPi 12:47, 18. Aug. 2009 (CEST)
Verlustbehaftete Komprimierung
Zu erwähnen wäre ob (dass?) die Komprimierung verlustbehaftet ist --Itu 03:09, 25. Aug. 2009 (CEST)
- H.264 erlaubt auch verlustfreie Komprimierung (sowohl von x264 als auch von libavcodec unterstützt). --Regression Tester 18:57, 29. Okt. 2010 (CEST)
Patente in Europa?
Ist H.264 auch in Europa durch Patente geschützt? Auf der englischen Wikipedia steht, dass sei nur in Ländern mit Softwarepatenten der Fall und da gibt es ja Unterschiede zwischen USA und Europa. Der fisch 19:00, 27. Jan. 2010 (CET)
- Und wenn ja, bis wann gilt dieser Patentschutz? (nicht signierter Beitrag von 78.35.207.66 (Diskussion) 15:46, 15. Sep. 2010 (CEST))
- Es liegt im Wesen dieser Patente, daß beide Fragen insofern nicht glaubwürdig beantwortet werden können, als es unmöglich ist, alle möglichen Patente aufzuzählen (es können natürlich Beispiele angegeben werden). Zu erwähnen ist, daß die ITU davon ausgeht, es sei nicht möglich, die Spezifikation ohne Verletzung von Patenten zu implementieren (http://ffmpeg.org/legal.html ).--Regression Tester 17:21, 15. Sep. 2010 (CEST)
Hardwarebeschleunigung
Hardwarebeschleunigung kann die CPU vollständig entlasten. Das ist immer gut, auch wenn man eine CPU hat die H.264 Full HD per Software dekodieren kann. Denn wenn die CPU entlastet wird kann sie andere Aufgaben während dem Fernsehen oder Videoschauen verrichten. Ich verstehe daher nicht wie man gegen den letzen Absatz in "Wiedergabe am PC" sein kann, denn nicht zuletzt die CPU-Lobby will glauben machen man soll sich eine schnellere CPU zulegen. Bei aktuellen Full-HD-Camcordern stehen solche Fehlempfehlungen in der Bedienungsanleitung........ Ich bin daher dafür, dass die Hardware-Dekoder in der Wikipedia beschrieben werden. Dass es unglaublich effiziente und energiesparende Hardware-Dekoder gibt sieht man doch an den ganzen Stand Allone-Geräten inkl. der Kameras die nur sehr kleine CPUs haben die absolut nicht in der Lage sind Softwaredekodierung von HD-Material durchzuführen. Ich gebe zu, dass die erste Version meines Absatzes schlecht war, aber ich verstehe definitiv nicht wie man generell gegen einen solchen Absatz sein kann.[2]--Matze6587 12:42, 17. Jun. 2011 (CEST)
- Der Absatz ist doch noch da, oder? Zu immer gut: Meine GPU - 40nm - läuft heiß, wenn sie H.264 decoden soll (und zwar bis zum Abschalten der Graphikkarte), beim Decoden desselben Streams mit der CPU bleibt die Temperatur an der unteren Anzeigeschranke. Ich bin sicher nicht gegen Hardwaredecoder (ich habe intensiv an der erfolgreichen Implementierung von Hardwaredecodierung für einen Player mitgearbeitet), aber der Absatz hat vor meiner letzten Änderung in meinen Augen den Eindruck erweckt, Hardwaredecodieren hätte den Sinn, Streams in Echtzeit zu decodieren, für die das die CPU nicht zusammenbringt: Das mag für Intel Atom in Verbindung mit GMA 500 oder Nvidia ION stimmen (und neuerdings auch für die GT 520 - lustig, das steht nicht im Geforce 500-Artikel - und einer älteren CPU), generell ist das Decoden mit der CPU (ich habe einen E8400, also definitiv nicht die letzte Generation) wesentlich "schneller", es können also mit einer (billigen) Desktop-CPU Streams mit einer höheren Bitrate in Echtzeit decodiert werden als mit der GPU.--Regression Tester 14:21, 17. Jun. 2011 (CEST)
- Ich habe schon gesehen dass noch etwas da steht... :) Aber auch die Begründung gelesen. Ob die GPU selbst das richtige Mittel ist wage ich auch zu bezweifeln. Die ATI HD-Karten haben meines Wissens H.264 Chips auf der Platine. Wenn deine GPU zu heiß wird, dann liegt das an der Kühlung. Und möglicherweise wird sie bei Software-Dekodierung genauso heiß wegen den Unmengen an unkomprimierten Pixeln die sie auf den Bildschrim zaubern muss. Dass du an Wiedergabesoftware mitgearbeitet hast ist interessant. Die VLC-Hardware-Unterstützung zum Beispiel funktioniert bei mir nicht. Die Adobe Flash Player Hardware-Unterstützung funktioniert bei nur vielleicht - jedenfalls brauche ich dann immernoch extrem viel CPU und ruckeln tuts auch...... Die Cyberlink Hardwareunterstützung bringt meine CPU auf Null Prozent (100 Prozent Leerlaufprozess) /DVB Viewer verbraucht nur Null Prozent CPU und das bei Full HD 50p. Hardwareunterstützung ist definitiv nicht gleich Haredwareunterstützung..... OT: Es ist auch bemerkenswert, dass so gut wie keine mpeg2 Chips für den PC mehr verfügbar sind.... --Matze6587 12:44, 18. Jun. 2011 (CEST)
- Nachtrag: H.264 Hardware kann wesentlich schneller encodieren und decodieren als die schnellste auf dem Markt befindliche CPU. Das geht sogar über die Schnittstelle USB2.0 durch die nur komrimiertes Material an eine HD-Videokamera zur dekodierung-encodierung geschickt wird in einer rasenden Geschwindigkeit um ein Vielfaches schneller als Echtzeitwiedergabe. H.264 Chips verfügen über eine Architektur, die es erlaubt, das H.264 Material vollkommen ohne Software zu dekomrimieren. Das geht so ähnlich wie bei portablen MP3 Playern. Die CPU in den Playern ist nicht in der Lage MP3 wiederzugeben, aber die Architektur des Mp3 Chips machts möglich - und das fast ohne Strom......--Matze6587 12:54, 18. Jun. 2011 (CEST)
- Encoden: x264 ultrafast ist schneller als Echtzeit (für 1080 und einen modernen Prozessor), x264 mit einem "normalen" preset mag langsamer sein als ein Hardware-Encoder, dafür ist die Qualität um Welten besser, die Qualität läßt sich für den Hardware-Encoder nicht auf ein vernünftiges Maß erhöhen (aber das hat nichts mit der Debatte zu tun.) Decoden: Nvidia-Hardware schafft (abgesehen von der GT520, siehe oben) ziemlich genau 1080@60 (je nach Software etwas weniger), das wird von jeder neuen CPU (außer Atom, siehe oben) überboten. Ich habe noch nirgends gelesen, daß die ATI Hardware schneller wäre - nur, das sie nicht funktiniert;-) Die vlc-Implementierung sollte unter Windows gute Ergebnisse zeigen (ich habe es nicht ausprobiert), unter Linux haben sich die Entwickler für die albernste Variante entschieden.--Regression Tester 13:08, 18. Jun. 2011 (CEST)
Patentdauer
Wann müssen die die relevanten Patente angemeldet worden sein um nicht als prior art zu gelten? Wenn der Standart 2001 verabschiedet wurde wohl spätestens 2001 - eher deutlich früher, bei einer Schutzdauer von 25 Jahren müsste diese also spätestens 2026 auslaufen, also könnten maximal 11 Jahre lang, von 2015 bis 2026 Kosten für gratis-Streaming anfallen, sehen ich das richtig? --80.144.75.134 12:48, 1. Okt. 2011 (CEST)
Level Angaben nicht eindeutig
Es fehlt die Bemerkung dass die Levelangaben die Obergrenzen darstellen. (nicht signierter Beitrag von 193.158.71.20 (Diskussion) 12:21, 13. Jan. 2017 (CET))
YUV und YUVJ
Ich finde es äußerst interessant, dass nirgendwo auf YUV und YUVJ eingegangen wird. Ich konvertiere sehr viele Videos mit h.264 und bemerke immer wieder sehr krasse Einbußen bei den Farben. Es scheint tatsächlich daran zu liegen, dass so gut wie alle Programme standardmäßig mit dem Pixel-Format YUV420p enkodieren (inklusive etwa Handbrake/Vidcoder), das eine Color Range 16-235 hat. YUVJ420p hat die volle Range 0-255. Bei MyFFMpeg kann man das zumindest umstellen. MPC und VLC geben aus meiner Sicht die volle Range wieder, aber wenn man mit YUVJ420p enkodierte Videos mit Chrome öffnet, scheint das Video wieder nur mit der 16-235 Range wiedergegeben zu werden. Chrome hat auch YUVJ zu Beginn überhaupt nicht supportet, das heißt es wurde ein Fehler ausgespuckt. Youtube arbeitet ebenfalls anscheinend nur mit YUV, also 16-235. Es muss doch irgendeinen sehr gewichtigen Grund geben, wieso das so ist und die ganze Welt verwaschene Videos ansehen muss? --Haxtibel (Diskussion) 03:29, 12. Jun. 2018 (CEST)
Status patente MPEGLA
H.264 http://www.mpegla.com/main/programs/AVC/Documents/avc-att1.pdf
Essentials:
http://www.mpegla.com/main/programs/avc/Documents/avcCrossRefChart.pdf
Nokia
Im Artikel über H.264 wird nirgends Nokia erwähnt. In Berichten entsteht der Eindruck das H.264 Nokia gehört. Auf Jeden Fall geht es da um H.264 Sollte man dazu nicht was in den Artikel schreiben bzw. was klärendes? --Calle Cool (Diskussion) 12:06, 5. Nov. 2020 (CET)
