Neues von der Technikfront: H.264 mit 10 Bits Farbtiefe pro Kanal
Für alle, die noch nicht davon gehört haben, habe ich mal eine kleine Erklärung darüber zusammengeschrieben, was diese sogenannten High-Bit-Depth-Encodes von den bisherigen 8-Bit-Encodes unterscheidet und was für eine Rolle das für Fansubs spielt.
tl;dr abspielen mit:
Zunächst einmal: Was bedeutet „Farbtiefe“?
Die Farbtiefe gibt an, mit welcher Präzision Farbinformationen abgespeichert werden können. Die bisherigen Encodes haben eine Präzision von 8 Bits (256 Abstufungen) pro Farbkanal, das heißt insgesamt 12 Bits pro Pixel (bzw. nach der Konvertierung zu RGB dann 24 Bits pro Pixel, was der Farbtiefe der meisten Systeme entspricht).
Man könnte auch 9 Bits pro Farbkanal verwenden, aber darauf gehe ich hier nicht näher ein.
Bei Encodes mit 10 Bits pro Farbkanal stehen 1024 Abstufungen und 15 bzw. 30 Bits pro Pixel zur Verfügung, was natürlich wesentlich genauer ist. Aber: Die meisten im Handel erhältlichen Anzeigegeräte und Grafikkarten zeigen nur 24 Bits pro Pixel an.
Was tut man also?
Dazu ein wenig Info nebenbei: Die meisten LCD Displays (TN-Panels, um genau zu sein) können nur eine Farbtiefe von 6 Bits pro Kanal (gerade einmal 64 Abstufungen) darstellen. Das würde natürlich unter normalen Umständen absolut schrecklich aussehen. Daher bedient man sich eines Tricks: Um die Farbtiefe von 8 Bits zu simulieren, kommt Dithering zum Einsatz. Dithering heißt stark vereinfacht ausgedrückt, dass der Controller des Panels mit einem dynamischen Muster schnell zwischen den nächstgelegenen Farbwerten der einzelnen Pixel wechselt.
Genau diesen Trick kann man auch bei der Darstellung von High-Bit-Depth-Encodes anwenden.
Aber kann man denn dann nicht einfach mit 8 Bits encoden und das Dithering gleich einbauen?
Das geht selbstverständlich und wird auch schon so gemacht, um Banding zu vermeiden. Allerdings hat das auch einen gewaltigen Nachteil: Die Bitrate, die erforderlich ist, um dieses Dithering und andere Details beizubehalten, ist sehr hoch.
Und deshalb …
Genau, deshalb ist eine hohe Farbtiefe beim Encode sehr vorteilhaft. Man kann sich das Dithering und somit auch jede Menge Bits sparen.
Aber das ist noch nicht alles: Die höhere Präzision steigert auch die allgemeine Effizienz des Encoders.
Um zu verdeutlichen, wie sehr die Effizienz gesteigert wird, hier ein Beispiel:
Shakugan no Shana Episode 12.
Die Videospur hat etwa 275 MiB bei 8 Bits Farbtiefe.
Dasselbe Material — also immer noch 8 Bits und mit bereits manuell hinzugefügtem Dithering — mit denselben Einstellungen braucht bei 10 Bits pro Kanal gerade mal 152 MiB, und das ohne Qualitätsverluste — im Gegenteil: der Encode sieht sogar besser aus.
Das ist ja schön und gut, aber da muss es doch einen Haken geben!
Den gibt es leider auch, und zwar mangelt es zurzeit an Unterstützung durch Abspielgeräte und Software. Zurzeit gibt es keine für Normalsterbliche erschwinglichen Hardware-Decoder, die diese Formate unterstützen. Das bedeutet, dass DXVA, VDPAU, LAV CUVID und CoreAVC CUDA dieses Zeug ebenfalls nicht unterstützen.
Und was heißt das für meine geliebten Fansubs?
Das heißt, dass es bei neuen Projekten nur noch 10-Bit-Versionen geben wird. Hier gibt es verschiedene Möglichkeiten:
- deutlich kleinere Encodes als bisher, aber gleiche oder leicht bessere Qualität
- etwas kleinere Encodes, aber bessere Qualität
- gleichbleibende Dateigröße, aber dafür deutlich bessere Qualität, teilweise bis hin zur Transparenz
Es kann also nur besser werden! Ich halte euch auf dem Laufenden.
Hinterlasse einen Kommentar
Spenden
Helft uns, den Server am Laufen zu halten!
Projekte
Laufend:
Beendet:
Neueste Kommentare
 | Daniel bei Bleach – Das Höllen… |
 | Schlimmi bei さようなら |
 | Dontas bei さようなら |
 | Hans bei さようなら |
 | el-sahef bei Mahou Tsukai ni Taisetsu na ko… |
Strawhat Subs 
Guter Artikel, wie es den Anschein hat, bist du ein kompetenter Encoder. Wenn es doch noch mehr gute Encoder unter den Fansubbern geben würde…
Dann bin ich mal auf deine zukünftigen Encodes gespannt! :-)
So etwas liest man immer gerne ^^
Hoehere Qualitaet bei geringerer Dateigroeße.
Dann hoffen wir mal, dass sich das Ganze schneller verbreitet als befuerchtet.
Wir werden dazu beitragen! Es wird wohl genauso sich abspielen wie vor vielen Jahren mit H.264. Für die, die es noch nicht abspielen konnten, wurde XVID in einer komfortablen AVI encoded. Tja, und bald wird es wieder was für Qualitätsbewusste geben. Für 2012 habe ich sogar im Auge, einen kompletten Anime ausschließlich für die 10-bit-Nutzer als kleines Geschenk der Tüchtigkeit und Anreiz zum Wechseln zu machen.
Kannst du mal eine Probedatei hochladen? Für die Glücklichen, die einen passenden Player verwenden, damit sie den Qualitätsunterschied sehen, und für die anderen, um zu testen ob ihr Player nicht vielleicht doch funktioniert. Du weißt nicht zufällig, ob Mplayer OSX Extended oder der Mac OSX Build von mplayer2 das kann?
MPlayer OS X Extended bzw. der mitgelieferte MPlayer-Build ist höchstwahrscheinlich viel zu alt dafür (und sowieso nicht ansatzweise so gut für Fansubs gerüstet wie MPlayer2), und MPlayer2 benötigt einen patch, um die Funktionalität hinzuzufügen (sollte aber demnächst auch ohne gehen; ich hab mich schon im Entwicklerchannel eingenistet).
Wenn du also MPlayer2 nicht selbst für OS X kompilieren kannst oder willst, musst du wohl darauf warten.
Eine ernsthafte Probedatei wird es zusammen mit der nächsten von mir encodeten Episode von was-auch-immer geben; bis dahin könnte ich dir vorerst nur eine Folge Lucky Star in absolut mieser Qualität auf 11 MiB runterkomprimiert anbieten. Einige Player werden es zwar abspielen, aber dafür (wie im Artikel beschrieben) lustige Farbflecken über das Bild schmieren.
Auf jeden Fall ein interessanter Schritt in Richtung Zukunft!
Imho ist das Dateigröße/Qualität Verhältnis das Wichtigste bei einem Encode. Natürlich spielen auch andere Faktoren wie die allgemeine Kompatiblität oder die Effizient beim Decoding eine große Rolle – das will ich nicht abstreiten.
Der 11mb Lucky Star Encode zeigt doch schonmal was (und das erst am Anfang) bereits möglich ist. 20 Minuten Video + Audio so komprimiert zu bekommen hat schon was ;)
Habe die Datei mit mehreren Mplayer Builds getestet: Allgemein läuft es ganz gut. „Farbflecken“ oder starkes Schmieren konnte ich beim schnellen Testen nicht finden.
Getestet habe ich die (jeweils aktuellsten) Mplayer Builds:
Lord Mulder (AR Probleme!) |
Kovensky (selbst das alte Build von 1/10 funktioniert gut) |
Mplayer 2 und deine gepatchte Version.
Ich bin auf jeden Fall schonmal gespannt was aus dem Ganzen wird. Kann ja nur besser werden :)
Ja, Lucky Star profitiert nicht sonderlich von 10-Bit (lässt sich auch mit 8-Bit locker unter 190 MiB pro Folge transparent kodieren, selbst mit zwei Audiospuren), daher fallen etwaige Farbverfälschungen da nicht so auf. Spätestens bei Shakugan no Shana sieht man es dann aber sehr deutlich schon ganz am Anfang:
*klick*
Das Lucky Star sich gut encoden lässt war ja schon fast abzusehen: recht große Farbflächen und ruhiges Bildmaterial :’D
Ich warte dann mal auf die „richtige“ Probe.
Bei diesem SnS screen fällt es aber schon in die Kategorie „grausam“. Solche Bildfehler sind natürlich nicht akzeptabel :P
// Irgendwie schaut zumindest der Fehler in der Mitte fast so aus wie wenn beim Spulen das falsche I-Frame genommen wird; nur in klein.
K……., ich mach mal meine eigenen Versuche und werde diese dann Presentieren…werde dafür eine BD 1GB große Folge von HOTD nehmen.
GROßE AUGEN MACH……
Ne nur spaß, ich nehm ein 720p H.264 RAW … (genauere Details Folgen) … großes Opening von irgend einem Anime … drückt mir die Daumen ….
Meine Ziele / mein Ziel:
Weniger BIT / Weniger Größe / Kein Qualiverlust (>_<)
Ja toll, du nimmst ne Quelle, die schon Müll ist, und encodest die NOCH MAL zu Müll?
Das ist unmöglich. Verluste wirst du bei H.264 immer haben, außer du encodest mit CRF 0 (und das auch nur mit 8-bit, weil es bei 10-bit aus verschiedenen Gründen nicht verlustlos ist). Und selbst wenn du dich damit nur auf sichtbare Verluste beziehst, hast du dich durch das Verwenden einer dieser fertigen H.264 Raws schon disqualifiziert.
Allgemein würde ich dir empfehlen, deine bisherigen Spielereien zu lassen und dich mal ernsthaft mit Encoding auseinanderzusetzen, bevor du so was postest. Und damit meine ich nicht nur HURR DURR ICH KANN DOCH MEGUI UND SO. Encoding ist so ein Thema, über das man besser nicht in meiner Nähe spricht, wenn man keine Ahnung hat. Ich bin da ein leicht reizbarer, elitärer Besserwisser und gebe das auch offen zu.
tl;dr get off my lawn you damn kids
Ach ja, mich würde mal das Fractale Opening von der BD interessieren ◔ ◡ ◔
Also mich gleich als Kind zu beschimpfen ist gemein.
Ich kann zwar noch nicht mit den Profis mithalten, die selbst aus einer 480p Version Zaubern können.
Aber ich mach gewiss kein Müll.
Ich setzte mich ja bereits mit Encode mehr und mehr auseinander, hab aber noch nicht wirklich viel lernen können, da Leute wie du einen immer gleich beleidigt anschreien anstatt mir Tipps und tricks geben.
„Try and Error, but i will be faster with Help“
Ich kann ja verstehen wenn du sauer bist, aber ohne was über eine Person zu wissen und dann zu urteilen ist vorreillig und dumm, denn ich bin keiner, der bei Pixelfail und sonstigem denkt: „Ach ist doch egal.“
Ich stell sogar bei jedem Encode meine Einstellungen seperat ein.
—————
P.S: Ich hab vor einem Jahr mit encoden angefangen und kann jetzt schon an die Top Leute heranreichen.
P.S: Das ich mit H.264 immer Qualiverlust habe, wusste ich net, hätte ich aber durch meine Versuche herrausgefunden.
Daher danke, dass du es mir auf deine freudliche Art und Weise klar gemacht hast, dass ich es gleich lassen kann, dass hat mir viel Zeit erspart… Wäre schön mal eine Person zu treffen die einem Hilft….
Sry Strawhat-Team, dass das auch eurer Seite „besprochen“ wurde.
Hab ich doch gar nicht. Würdest du dich ein wenig mit Redewendungen auskennen, wüsstest du, dass „get off my lawn you damn kids“ eine Anspielung an griesgrämige alte Leute ist, die sich immer aufregen, wenn die verdammten Kinder mal wieder auf ihrem sowieso pissgelben Rasen Fußball spielen.
Zaubern können auch die Profis nicht. Was an Qualität oder Detailreichtum nicht da ist, ist eben nicht da.
Du redest aber durchaus solchen.
Willkommen im Internet. Und eigentlich habe ich dir zumindest einen Tipp gegeben: Wenn du Raws suchst, dann nimm solche, die so nah an der Quelle sind wie möglich, nicht irgendwelche MP4 Raws.
Klar hat Encoding auch etwas mit Trial and Error zu tun, aber das heißt nicht, dass du dich auf die Hilfe von anderen verlassen solltest. Niemand wird dir eigene Recherche ersparen, egal wie erfahren und zuvorkommend er ist. Und nur durch Rumprobieren lernt man auch nichts.
Das habe ich auch nicht behauptet. Ich habe behauptet, dass es dir einfach noch an Erfahrung fehlt, um die meisten Fehler überhaupt zu erkennen. Mir ging es auch mal so, deshalb bringt mich das so auf die Palme.
… sag bloß du benutzt jetzt echt MeGUI.
Dafür bist du aber anscheinend noch ziemlich unerfahren.
Vergleiche dich nicht mit anderen, sondern versuche stets dich selbst zu übertreffen, sonst wirst du es nie zu etwas bringen. Deine Selbsteinschätzung ist übrigens Bullshit.
Ich zumindest zähle mich zwar zu den fähigen Encodern, aber nicht zu den besten. Ich kenne andere, deren Niveau ich noch nicht erreicht habe.
Gewöhne dich schon mal an derart harsche und unfreundliche Kritik, wenn du dich weiterhin mit diesem Thema beschäftigen willst. Irgendwann stößt du auf Leute wie mich.
Hier bei Strawhat wimmelts wohl nur so von selbstverliebten Egozentrikern.
HURRR DURRmein Encodeschwanz der GrössteHURR DURR. Dass man diesen nicht jedem bis zum Anschlag hinten reinschieben wollen muss, juckt wohl keinen.
Wäre kein Wunder, wenn eure Releases so selten sind, weil euch reihenweise die Leute abpringen. Bei so einem Umgang…
Ach, so gehe ich nur mit Leuten um, die meinen, hier ihren Senf dazugeben zu müssen, obwohl sie keine Ahnung haben. Mir geht es dabei auch nicht darum, mich zu profilieren. Wäre mir danach, könnte ich mich auch in Foren oder Kommentarsektionen und IRC-Channels irgendwelcher Dönergruppen austoben. Ebenso repräsentiere ich mit meinen Kommentaren hier nicht die ganze Gruppe, und eigentlich geht es unter den Mitgliedern ziemlich human zu.
Außerdem, weshalb mischst du dich hier überhaupt ein? Und überhaupt, was soll dieses Drama hier schon wieder? In Zukunft kommt hier nur noch ein „Fick dich“-Button an jeden Kommentar, dann erledigt sich so etwas viel schneller und ich brauche auch nicht mehr meine Zeit damit zu verschwenden.
die langsamen release resultieren ja gerade aus unserem perfektionswillen. lieber gründlich mit langem verfallsdatum als von anfang an döner
entschuldige, dass du bei uns was anderes gewöhnt bist als bei anderen gruppen
>HURRR DURRmein Encodeschwanz der GrössteHURR DURR
>Ich zumindest zähle mich zwar zu den fähigen Encodern, aber nicht zu den besten. Ich kenne andere, deren Niveau ich noch nicht erreicht habe.
Nice troll.
Und ich glaube „harte“ Kritik wird man in jedem Metier außerhalb des Kindergartens erleben.
Gewöhn dich dran.
Eine Rechtfertigung kann schon einmal ausgeschlossen werden, da du die Fakten wahrscheinlich nicht genau kennst. Aber aus persönlichen Gründen von Subbern und höheren Qualitätsbedingungen werden Releases keines falls schneller released.
Zumal die Krankheit des Fansubber Burnouts – also das plötzliche Abspringen ohne Begründung und nie wieder Online – bei uns erst einmal aufgetreten ist, wäre es zu vermuten, dass dieses Team, welches schon länger besteht als so manch andere Gruppe, eine feste Belegschaft besitzt.
Alle Macht den LQ-Real-Media-Encodes! Nur die sind trve! xD
Ich wollte nur anmerken, dass lachs0r wahrscheinlich länger als geplant zweimal encoden muss. „Ausreichende Verbreitung“ ist immer so schwammig und relativ, das kann von „es gibt mehr als zwei Player für jedes Betriebssystem“ bis „99,999999999% unserer Leecher verwenden so einen Player“ gehen.
Arrr, du kennst noch die richtigen Kronjuwelen alter Zeiten. :3
„Ausreichende Verbreitung“ heißt bei mir, dass es mindestens mit MPC-HC/ffdshow-tryouts möglich sein muss, wenn sich an der Playersituation nichts ändert. VLC wird ja wie erwähnt wahrscheinlich früher dran sein, also hat man allein damit schon einen sehr großen Teil abgedeckt.
@lachs0r, bisher gibt es keine Decoder, welche besagtes 10-Bit-Verfahren vernünftig bis fehlerfrei umsetzen. Selbst CoreAVCs aktuelle Version stellt keine Videos ohne Artefakte dar. MPCs interner Decoder liefert ähnlichen Farbverlauf mit etlichen Artefakten. VLCs interner liefert denselben Matsch aus grünen Bildschirm wie ffdshows Decoder – welcher angeblich dazu imstande sei.
Libav und FFmpeg unterstützen 10-Bit schon lange, somit auch mindestens MPlayer2 und MPlayer. Hättest du den Post gelesen, wüsstest du, dass CoreAVC das erst in Version 3.0 unterstützen wird. MPC-HCs interne Dekoder sind schon sehr lange veraltet, ebenso die des VLC Releases (nur die verlinkten Betaversionen und gegen aktuelle Libav-Versionen gebaute können das). FFdshow-tryouts unterstützt es ausschließlich in CCCP, weil die Autoren sich bisher weigern, die Patches einzupflegen oder überhaupt ihren Code aufzuräumen.
Über diverse Codec-Packs enthalte ich mich des Worts. Weil so was sich Laien installieren, welche sich unkontrolliert Windows Filterdatenbank zumeriten. Als Player nutze ich überwiegend nur MPC-HC mittels CoreAVC, ffdshow tryouts und DivX Plus. Was rätst du?
Aber genau das hast du gemacht, indem du gleich DREI verschiedene H.264-Dekoder installiert hast, die allesamt veraltet und/oder schlecht sind. Hinweis: CCCP ist zwar ein Codec-Pack, aber im Gegensatz zu K-Lite und Konsorten sitzen dahinter keine Vollidioten. CCCP ist dazu gedacht, eine saubere, funktionierende Konfiguration zum Abspielen der gängigsten Formate zu ermöglichen.
Ich würde zu meinen MPlayer2-Builds in Verbindung mit SMPlayer raten. Damit vermeidet man den ganzen DirectShow-Clusterfuck und hat eine funktionierende Lösung zum Abspielen. Alternativ alle bisher nachträglich installierten Codecs durch CCCP ersetzen.
PotPlayer 1.5.29162 kann übrigens auch (mit dem Built in h264/AVC Decoder) Hi10. Schade ist bei der Geschichte nur, dass DXVA (renderless) und CUDA die Grätsche machen. Hi10 Decoding geht nur über Software.
Für Leute, deren CPU Full HD nicht mehr packt und die sich auf die GPU verlassen ist das tödlich.
Das wären vor allem Netbooks und P4/Athlon XP <2400+
Hallo, hier wurde ja lange gestritten. Aber nichts geht über die Praxis!!!
3Punkte:____________
1. Wieso braucht man neue Technik zum abspielen von 10Bit??? Schwachsin!!!
—
2. Ich hab mit Shana mal Test gemacht, ob ich mit 10 Bit weniger Filezise habe und kein Qualiverlust. ___ Jedoch wurde ich enttäuscht!!!___
Shana 480p 10Bit = 190MB mit ca. 1.000k/Bits.
Shana 480p 08Bit = 290MB mit ca. 1.500k/Bits.
Heißt im Klartext, 1/3 Filezise gesparrt durch weniger k/Bits und nicht durch 10Bit, + Qualiverlust.
(100% : 290MB = 0.3% * 190MB = 65% = 1/3 gesparrt)
Wer mir nicht glaubt, bekommt auch Bilder als beweiß, hab beides mit dem selben Player abgespielt und bin auf Vollbild gegangen. Bleibt lieber bei 8Bit, sieht Besser aus!
—
3.
http://img4.picload.org/image/crpdwc/10bitfail.2.png <—Ihr habt sogar Farbflecken bei 10 Bit!
______________
Ich weiß ich bin pingelich, aber wenn ihr schon 10 Bit coden wollt, dann bitte richtig.
Ihr encodet doch super, warum jetzt das????
P.S: das ist mein erster und letzter Beitrag, weil ich sonst was zu hören bekomm.
Weil sich bisher noch niemand um Unterstützung seitens der Decoder gekümmert hat, obwohl es schon seit 2003 in den Spezifikationen des Formats steht.
Das ist doch logisch. Bitrate gibt an, wie viele Bits du pro Sekunde hast. Du kannst niemals mit derselben Bitrate kleinere Dateien bekommen, unabhängig von Dateiformat und -inhalt. Kleinere Dateien bedeuten weniger Bitrate.
Im Übrigen habe ich bei der Shana OVA für 10Bit eine viel höhere Qualitätseinstellung verwendet, weshalb auch „nur“ 1/3 gespart wurde.
Deine Playerkonfiguration ist zu alt und unterstützt daher kein 10-Bit H.264 — bitte lies den kompletten Beitrag inkl. der oben angeführten Edits!
Dieselbe Szene aus der 10-Bit-Version der Shana OVA, mit MPlayer2 abgespielt und ebenfalls auf 1920×1080 hochskaliert.
OK..das ist wirklich gleichgut, bei kleinerer größe….merk man vorallem an der Schrift!!!!
Und ich mach mal Update….und lass euch weiter futcheln, hab ihr gut gemacht ^^
ENTSCHULDIGUNG !!!!!!!!!!
An der Schrift sieht man gar nichts. Das sind Softsubs; vernünftige Player rendern diese unabhängig vom Video, weshalb man sie dann auch mit voller Darstellungsauflösung präsentiert bekommt.
„…bis MPC-HC und FFdshow-tryouts dies unterstützen werden“
Der Player muss die 10bit ja nicht unterstützen, solange ffdshow das Video richtig dekodiert reicht das doch, oder?
MPC-HC im speziellen hat interne Dekoder, die bei CCCP zum Beispiel durch FFdshow ersetzt werden.
Allerdings sieht es wohl so aus als sei das heillose Durcheinander in FFdshow nicht wirklich zu retten (mir wurde gesagt, 10Bit sei auf 64Bit-Systemen kaputt). Es gibt aber auch noch LAV Filters, welche sich zurzeit noch in Entwicklung befinden und wahrscheinlich irgendwann FFdshow ersetzen werden.
Ich hab mal nen kleinen spaßigen Vergleich gemacht… nicht mit Shana, nicht mit Strawhat-Material aber mit zwei spaßigen Files die mir in die Finger gefallen sind…
Hanasaku Iroha, 1080p, einmal in HI10P auf 100 MB (!!!) und einmal normal in 2000 MB (autsch… Bitrate-Overkill… aber sparsam encoden konnte Coalgirls noch nie…)
Anyway, erst mal ’ne ruhige Szene:
http://screenshotcomparison.com/comparison/74436 – nahezu null Unterschied, und das bei 2000% mehr Filesize.
http://screenshotcomparison.com/comparison/74435 – okay, hier sieht’s man deutlich. Aber dafür, dass das eine ein 24-minütiges 1080p Video auf sage und schreibe 100 MB ist, ist’s schon krass…
Nicht schlecht. Ich sehe Hi10P inzwischen aber nicht mehr primär als Möglichkeit, kleinere Dateien zu erzeugen, sondern als Möglichkeit, relativ einfach bessere Qualität hinzubekommen.
Die Platzersparnis ist dabei nur eine angenehme Nebenwirkung.
Zum Guten Glück ist nicht 10Bit auf 64Bit-Systemen kaputt sondern lediglich mit der 64Bit-Version von FFdshow. Und man kann auch auf 64Bit-Windows’en die 32Bit Version von FFdshow und MPC-HC installieren. CCCP installiert nix anderes.
Lediglich Leute wie ich die auf 64Bit-Kisten wenn es irgendwie geht, vorallem bei Rechenintensiven Sachen, auch mit 64Bit Software Arbeiten wollen gibts Durcheinander weil bei mir z.B. ein Doppelklick auf eine .mkv den x64 MPC-HC startet und ich für Hi10P Videos zuerst den 32Bit MPC-HC starten und dann die Datei über Datei-Öffnen laden muss.
Zum Schluß noch eine (schlechte) Nachricht für alle die auf CoreAVC 3 hoffen, selbst wenn Version 3.0 wie unverbindlich angekündigt Ende des Monats erscheinen sollte. Alle 10bit Profile ( also auch H422P und H444P btw. fast genau so uralt wie die 10bit Spezifikation selbst) sollen soweit ich gelesen habe erst *irgendwann* später mal unterstützt werden. Es lebe das Durcheinander!
Gut zu wissen.
Unterdessen bereite ich übrigens gerade Installerbundles für meine Builds von SMPlayer und MPlayer2 vor.
Btw…
http://forums.bakabt.me/index.php?topic=31033.msg4658945#msg4658945
Wenn ich das richtig verstehe, könnten aktuelle Hi10P-Encodes mit zukünftigen Playern unsauber aussehen…
Ist mir bereits bekannt. Allerdings sind diese Farbunterschiede in der Regel vernachlässigbar und fallen auch nur auf, wenn man die Quelle genau kennt. Ich habe das vor einiger Zeit schon getestet: http://screenshots.srsfckn.biz/10bit_hue/
Zwar sieht das Dithering der NVIDIA-Treiber nicht ganz so schön aus wie das von swscale, allerdings scheinen die Farben — zumindest auf meinem Bildschirm — näher ans Original heranzukommen.
Ich betone noch einmal: Im Normalfall bemerkt man die leichte Farbverschiebung nur dann, wenn man die Videos direkt miteinander vergleicht. Die meisten Anzeigegeräte haben sowieso keine genaue Farbwiedergabe, daher richtet diese kleine Ungenauigkeit auch keinen größeren Schaden an.
Nur mal als Anreiz, wenn ffmpeg 10-bit macht, bietet sich XBMC (http://xbmc.org) noch als Player alternativ für Windows/OSX/Linux und mehr an. Ich müsste lügen ob die ffmpeg die er mit bringt es schon packt, sonst kann der Linuxer sich flux dank ./configure –external-ffmpeg ne eigene FFmpeg einbaun (normal für mich, bastel gern). Wollte es nur mal so erwähnen, auch kommt ein XBMC sehr gut mit Softsub klar.
Gruß Death
XBMC hält sich allerdings für besonders schlau und implementiert ein eigenes Caching für Softsubs (obwohl libass selbst schon was hat), was zu lustigen Bugs mit \kf Tags führt: *klick*
Ich weiß aber nicht, ob das inzwischen behoben wurde.
Sehr schöner Artikel. Was mich noch interessieren würde, wäre ob die Fachkenntnis des Autors auf eigenen Recherchen im Internet beruht… Denn falls ja, wäre meine unwürdige Wenigkeit vllt eines Tages auch imstande einen Bruchteil der alt-meisterlichen Encodingtechniken zu meistern…
PS Dieser Artikel hat mich übrigens auch zu der Seite geführt, bisher hab ich zwar nur eine Serie gesehen, aber die Subs waren lobenswert!
Mit unterwürfigen Grüßen!
p01
Ein Großteil meiner Erfahrung als Encoder beruht auf eigenen Recherchen. Wenn man erst einmal den richtigen Einstieg in das Thema gefunden hat (was durchaus seine Zeit dauern kann), kommt der Rest eigentlich von selbst. Wichtig ist dabei, dass man sich nicht zu sehr auf Teilbereiche konzentriert und stets offen für Neues ist.
Es kann auch nicht schaden, sich mit anderen Encodern auszutauschen, die vielleicht schon etwas erfahrener sind als man selbst, allerdings sollte man aufgeschnapptes (Halb-)Wissen immer für sich selbst kontrollieren. Was ich so von mir gebe, entspricht auch nicht immer den Tatsachen: So steht zum Beispiel das High 10 Profile erst seit März 2005 in der H.264-Spezifikation, nicht seit 2003, siehe http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Versions
Phew.
Ich frage mal euch: Ich habe bei diversen 10-bit Anime in verschiedenen Szenen immer mal wieder Blockbildung. Das sind meistens nur ganz wenige Frames. Erst hatte ich die Vermutung, dass die File eventuell fehlerhaft ist, ein CRC-Check ergab da aber nichts.
Nun liegt die Frage, ob es doch irgendwie an 10-bit liegt…
Ich nutze den aktuellen MPC-HC Build (Standalone) in Verbindung mit madVR und LAV Video. Auch ohne LAV Video habe ich diese Blockbildung.
Das Problem habe ich nicht bei jeder 10-bit File!
Wir empfehlen nicht umsonst CCCP für Leute, denen mplayer2 nicht passt. Es ist zwar keine optimale, aber eine funktionierende Lösung.
Nun ja – habe mich vor paar Monaten ja eigentlich nicht grundlos vom CCCP + CoreAVC verabschiedet :/
Werde ich wohl mit Leben müssen, kommt ja ohnehin er selten vor, dass es so rumbockt.
SO – habe mal MPC-HC + madVR & LAV deinstalliert und das CCCP installiert. Fehler tritt auch dort auf. Wird also wohl schon in der RAW so drin gewesen sein – oder was weiß ich.
Danach sieht es bei näherer Betrachtung auch aus. So eine Blockbildung hat man normalerweise nur bei kaputten MPEG2-Streams. Weil NHK-E AFAIK nur terrestrisch in einigen Gebieten empfangen werden kann, kommt es da gelegentlich schon mal zu solchen Störungen.
jetzt hab ich lust auf tetris…
Hi sehr Interessanter Beitrag, mich würde es interessieren wie es möglich ist alte 8bit Endcodes in 10bit umzuwandeln oder sollte man sie lieber so zu lassen. Wenn ja mit welchen Programm würde das gehen?
Danke schon mal für die Antwort
Mfg Hubsi
P.s.: Mit dem K-lite Codec Pack gehen die 10bit auch super
Bestehende Encodes solltest du lieber so lassen. Umwandeln kannst du sie mit x264.
Und K-Lite ist ein Krebsgeschwür.
Wüsste nicht welchen Sinn es hat, einen 10-bit Encode nachträglich „umzuwandeln“. Sinnvoll ist das wohl nur, aus dem Rohmaterial noch einmal einen 8-bit Encode zu machen, aber etwas komprimiertes noch weiter zu komprimieren. ^^
Hier auch noc mal was:
Habe MPC HC + madVr
Der Artikel linkt übrigens auf die englische Fassung meines Beitrags hier. Die ist meiner Meinung nach ein wenig besser geschrieben; ich sollte die deutsche auch mal aktualisieren.
von mir aus können die animes mit Hi10P endcode kommen
denn der alte media player classik hat mit Hi10P abzulut keine propleme leuft super trotz alten K-Lite – Codec Pack.
Und mit dem SMPlayer habe ich auch keine propleme , weiß nicht ob es an der neueste version vom K-Lite – Codec Pack. liegt weiß ich nicht
SMPlayer benutzt zur Wiedergabe MPlayer bzw. MPlayer2. Beide benutzen kein DirectShow (sämtliche Codecs sind bereits integriert). Daher spielt es auch keine Rolle, ob man Codec-Packs installiert hat.