Berücksichtigen lg oled tvs hdr Metadaten auch bei Nutzung interner Apps?

Gut, dass du dafür einen eigenen Thread aufgemacht hast.

Wie ich schon hier beschrieben habe:
Ja, es gilt für alle webOS Apps, da sie letztlich alle dieselbe Video-Engine/-Decoder von webOS nutzen.
Inklusive des webOS Browsers und Videos, die darüber abgespielt werden.

Eher theoretische Ausnahmen wären Player, die eine eigene Video-Decodierung nutzen wie bspw. VLC oder Kodi. Solche nativen Apps lassen sich aber nur auf gerooteten TVs installieren.

Wie hast du denn das Video heruntergeladen?

https://youtube4kdownloader.com/en105/

YouTube nutzt nämlich keine MKV Container, deshalb ist das was du analysierst hast auf jeden Fall nachverarbeitet und nicht exakt das 1:1 was auf den YouTube Servern beim Streaming ausgespielt wird.

Ok, allerdings würde es mich verwundern, wenn hierdurch der max mdl verändert worden wäre.

Als Stichprobe habe ich mal ein HDR10 Video auf YouTube abgespielt und beobachtet was beim Video-Decoder auf dem TV ankam:

Wie denn?
Was ergibt die Analyse des streams des von mir genannten Videos?
(https://youtu.be/UnmtvkpD-ME)

Mit welchen Parametern das Video aus meinem Test bei YT hochgeladen wurde kann ich natürlich nicht sagen. D.h. ich kann auch nicht bestätigen, dass mit der YouTube App und HDR10 Inhalten die Anpassung der Tonwertkurve an die MaxDML / MaxCLL Werte generell nicht funktionieren würde. In meinem Test war alles einwandfrei.

Also das individuelle Tonemapping für max MDL =1000 ist wirksam und nicht fälschlicherweise jenes für max MDL=4000?

ehl (Beitrag #3) schrieb:

Wie denn?

Das geht regulär nur mit speziellen (nicht öffentlich verfügbaren) Werkzeugen und indem du den TV in den Debug-Modus versetzt.

ehl (Beitrag #3) schrieb:

Was ergibt die Analyse des streams des von mir genannten Videos? (https://youtu.be/UnmtvkpD-ME)


{
    "displayPrimariesX0": 13248,
    "displayPrimariesX1": 7500,
    "displayPrimariesX2": 34000,
    "displayPrimariesY0": 34500,
    "displayPrimariesY1": 3000,
    "displayPrimariesY2": 16000,
    "whitePointX": 15635,
    "whitePointY": 16450,
    "minDisplayMasteringLuminance": 0,
    "maxDisplayMasteringLuminance": 1000,
    "maxContentLightLevel": 0,
    "maxPicAverageLightLevel": 0
}

Was auffällt ist, dass das Video zwar einen D65 Weißpunkt hat, aber nicht die Rec.2020 Farbraum Primärfarben nutzt, sondern den P3 Farbraum.
Siehe mein anderer Post, die Werte dort aus dem Video sind die Rec.2020 Farbraum Primärfarben Werte.
Vermutlich wurde das Video speziell für Samsung QLEDs abgestimmt.

ehl (Beitrag #3) schrieb:

Also das individuelle Tonemapping für max MDL =1000 ist wirksam und nicht fälschlicherweise jenes für max MDL=4000?

Korrekt.
Ich kann aktuell nichts entdecken, das darauf hindeuten würde, dass ein falsches Tonemapping angewandt werden würde.

Danke erstmal für die Mühe

displayPrimariesX0": 13248,     "displayPrimariesX1": 7500,     "displayPrimariesX2": 34000,     "displayPrimariesY0": 34500,     "displayPrimariesY1": 3000,     "displayPrimariesY2": 16000,     "whitePointX": 15635,     "whitePointY": 16450,     "minDisplayMasteringLuminance": 0,   "maxDisplayMasteringLuminance": 1000,     "maxContentLightLevel": 0,     "maxPicAverageLightLevel": 0

Ich kann aktuell nichts entdecken, das darauf hindeuten würde, dass ein falsches Tonemapping angewandt werden würde.

Nun, im video von "tech with kg" ist def. zu sehen wie die Tonemappingeinstellung für MDL= 4000 nits wirksam ist, was sie bei einem hdr Video wie diesem mit MDL=1000 cd/m2 eben nicht sein sollte.



Oder verhält es sich bei dir anders?
(Die tonemapping templates müssen bei lg TVs älter 2024 manuell über calman geladen werden, aber das weißt du ja)

Falls ja, liegt der Fehler wohl beim g4 und nicht lg's youtube app i.A.

Zumindest die folgende Aussage von ihm im Video ist nachweislich falsch:

there's not individual metadata for YouTube videos, so it's all gonna use that 4000 curve

ehl (Beitrag #5) schrieb:

Nun, im video von "tech with kg" ist def. zu sehen wie die Tonemappingeinstellung für MDL= 4000 nits wirksam ist, was sie bei einem hdr Video wie diesem mit MDL=1000 cd/m2 eben nicht sein sollte.

Im Video sieht man nur, wie er mit der neuen "Professional" Option herumspielt, aber nicht, wie er die Tonwertkurven-Parameter per Kalibrierungs-API setzt.
Die beiden Funktionen sind nicht identisch, auch wenn sie natürlich eigentlich identisch funktionieren sollten.

Ich habe gerade keinen C4 zur Hand um es mit derselben Hardware wie er zu prüfen, aber es könnte schlicht ein Firmware-Bug der neuen "Professional" Option im "Dynamic Tone Mapping" Menü der 2024er Modelle sein.
Es ist übrigens unglücklich, dass LG das mal wieder in ein Menü gepackt hat, wo es nur so halb richtig aufgehoben ist, weil es keine Option für "dynamisches Tonemapping" ist.

ehl (Beitrag #5) schrieb:

Oder verhält es sich bei dir anders?

Wie im anderen Thread beschrieben: nach meinen Tests werden die Rolloff-Parameter für die 1000er Kurve verwendet.
Aber wir vergleichen auch Äpfel mit Birnen, die 2024er Modelle verhalten sich beim Tonemapping generell etwas anders als die älteren Modelle.

ehl (Beitrag #5) schrieb:

(Die tonemapping templates müssen bei lg TVs älter 2024 manuell über calman geladen werden, aber das weißt du ja)

Anmerkung am Rande: CalMAN ist nur eines von mehreren Werkzeugen, das die Kalibrierungs-API von LG nutzt und das ermöglicht - und leider ist es nicht das Beste in dieser Hinsicht.

ehl (Beitrag #5) schrieb:

Falls ja, liegt der Fehler wohl beim g4 und nicht lg's youtube app i.A.

Siehe oben.
Sollte es tatsächlich so sein wie KG es im Video gezeigt hat, so halte ich einen Firmware-Bug im Zusammenhang mit der neuen "Professional" Option beim Tonemapping für wahrscheinlich.

Möglich wäre aber auch, dass er durch Kalibrierungen oder andere Einstellungen am TV Seiteneffekte ausgelöst hat, die das gezeigte Verhalten verursachen.
Egal was es am Ende ist, wie zuvor erklärt, ist es äußerst unwahrscheinlich, dass es diesbezüglich ein generelles Problem mit HDR Videos auf YouTube und dem Tonemapping aller LG TVs der letzten Jahre gibt.
MaxDML Werte kommen ganz offensichtlich bei der Video-Engine des TVs an, so dass dieser die richtigen Parameter für die Tonwertkurve verwenden kann.

Konkretere Aussagen könnte ich nur treffen, wenn ich das Verhalten aus dem Video nachstellen könnte.

Zumindest die folgende Aussage von ihm im Video ist nachweislich falsch: "there's not individual metadata for YouTube videos, so it's all gonna use that 4000 curve"

Ja, habe ich bereits drauf hingewiesen.
Zu der Annahme gelangte er wohl, weil bisher jeglicher von ihm über youtube wiedergegebene hdr Content auf das individuell eingestellte 4000 nits Tonemapping reagierte, statt auf die mdl= 1000 nits Kurve.

Im Video sieht man nur, wie er mit der neuen "Professional" Option herumspielt, aber nicht, wie er die Tonwertkurven-Parameter per Kalibrierungs-API setzt.

Er tut es auch nicht mittels Kalibrierung, das neue "professional" Setting erlaubt den Rolloff-Punkt ohne eine solche zu verändern.

Möglich wäre aber auch, dass er durch Kalibrierungen oder andere Einstellungen am TV Seiteneffekte ausgelöst hat, die das gezeigte Verhalten verursachen.

Unwahrscheinlich, da es sich mit seinem lg g4 ebenso verhält, allerdings sieht man wie durch youtube auf allen tv zeitgleich navigiert wird, daher wird wohl kaum die interne App genutzt werden.
Nun ist natürlich die Frage, warum die Metadaten offenbar über das externe Wiedergabegerät nicht übertragen werden, weshalb das mdl=4000 cd/m2 Tonemapping wahrscheinlich aktiv wird.
Aber das ist ein anderes Thema

Was auffällt ist, dass das Video zwar einen D65 Weißpunkt hat, aber nicht die Rec.2020 Farbraum Primärfarben nutzt, sondern den P3 Farbraum.

Als "color primaries" wird mir aber "bt.2020" angezeigt.

ehl (Beitrag #7) schrieb:

Er tut es auch nicht mittels Kalibrierung, das neue "professional" Setting erlaubt den Rolloff-Punkt ohne eine solche zu verändern.

Der Upload der HDR10 Tonwertkurven-Parameter über die Kalibrierungs-API ist ein separater Schritt und Aufruf, der sich unabhängig von allen anderen Kalibrierungs-Schritten durchführen lässt. Er erfordert zudem den TV kurzzeitig in den Kalibrierungs-Modus zu versetzen.

Wie erwähnt ist das technisch gesehen nicht dieselbe Funktion, wie die Einstellung im Nutzermenü.
Die Einstellung über das Nutzermenü wird anders gespeichert und anders gesetzt. D.h. die "Professional" Option setzt die Kalibrierungsdaten außer Kraft, löscht diese aber nicht.

Die eine Einstellung könnte also einen Bug haben, den die andere nicht hat.

ehl (Beitrag #7) schrieb:

Als "color primaries" wird mir aber "bt.2020" angezeigt.

Ich glaube nicht, dass die Standard-Info-Anzeigen des TVs es dir anzeigen, wenn ein Video nur den DCI-P3 Farbraum nutzt.
Der Diagnose-Screen für externe Signale könnte vielleicht mehr anzeigen, er funktioniert aber natürlich nicht für interne Apps.

Leider kann ich nur spekulieren, was KG genau wie gemacht hat und warum es zu bestimmten Effekten kam, was wenig hilfreich ist.
Deine eigentliche Frage im Titel "Berücksichtigen lg oled tvs hdr Metadaten auch bei Nutzung interner Apps?" sollte aber denke ich beantwortet sein.

Ich glaube nicht, dass die Standard-Info-Anzeigen des TVs es dir anzeigen, wenn ein Video nur den DCI-P3 Farbraum nutzt. Der Diagnose-Screen für externe Signale könnte vielleicht mehr anzeigen, er funktioniert aber natürlich nicht für interne Apps.

Was verstehst du unter standard Info-anzeigen des TVs?
Sowohl "stats for nerds" innerhalb youtube als auch Mediainfo zeigen es für das heruntergeladene Video an.

Leider kann ich nur spekulieren, was KG genau wie gemacht hat und warum es zu bestimmten Effekten kam, was wenig hilfreich ist. Deine eigentliche Frage im Titel "Berücksichtigen lg oled tvs hdr Metadaten auch bei Nutzung interner Apps?" sollte aber denke ich beantwortet sein.

Wie gesagt, er wird die interne App wohl gar nicht genutzt haben, da youtube auf allen tvs zeitgleich gesteuert wurde, insofern hat sich die Frage erübrigt, ja.

Ich habe den zugehörigen webOS Dienst debugged und kann jetzt bestätigen, dass es bei der Verwendung der internen webOS YouTube App bei HDR Videos zu einem Fehler bei der Verarbeitung der HDR Metadaten kommt.

Obwohl im von dir verlinkten Video auf YouTube der Decoder korrekterweise ein MaxDML Wert von 1000 liefert, kommt es intern zu einer fehlerhaften Bearbeitung, was dazu führt, dass der Fallback auf die 4000er Kurve wieder greift.

Betroffen ist die YouTube App von webOS 22, 23 und 24. Eventuell auch ältere Versionen.

Dass andere webOS Apps ebenfalls betroffen wären, kann ich aktuell nicht bestätigen.
Nutzt man YouTube über einen externen Zuspieler (bspw. FireTV, ShieldTV etc.) kommt es nicht zu diesem Fehler.

Tatsächlich scheinen alle internen webOS Media Player von dem Problem betroffen zu sein (also auch der Media Player, Plex etc.), allerdings nur bei diesem speziellen Video.
Mein Verdacht ist, dass es am Codec (VP9) oder an den schon erwähnten P3 Primaries im Video liegt, was diesen Fehler auslöst.

??? Du schriebst doch

ITGuy42 (Beitrag #4) schrieb:

ehl (Beitrag #3) schrieb: Also das individuelle Tonemapping für max MDL =1000 ist wirksam und nicht fälschlicherweise jenes für max MDL=4000? Korrekt. Ich kann aktuell nichts entdecken, das darauf hindeuten würde, dass ein falsches Tonemapping angewandt werden würde.

Oder hast du nun mit einem c4/ g4 getestet?

Nutzt man YouTube über einen externen Zuspieler (bspw. FireTV, ShieldTV etc.) kommt es ebenfalls nicht zu diesem Fehler.

Das ergibt wenig Sinn, da der TV ohnehin bei externer Zuspielung nicht nach Anwendung unterschieden kann und es daher einzig eine Frage der übertragenen Metadaten bleibt.
Im "tech with kg" video wurde definitiv ein externer Zuspieler verwendet und dennoch zeigte sich der 4000 nits Regler wirksam.

Und zufällig soll bei Nutzung der internen App nun der gleiche Fehler auftreten?

Ich weiß leider weder, welches Gerät er zur Zuspielung verwendet apple tv?/ hdmi splitter?, noch möchte er mir die Frage beantworten.

Auch classy tech verwendet in diesem Video https://youtu.be/o0cUipF5cAI natürlich ein externes Zuspielgerät (appletv, denke ich) und wenn dort ggfls. nicht die korrekten Metadaten übertragen werden, könnte das einige hdr Helligkeitsvergleiche ad absurdum führen.

ITGuy42 (Beitrag #11) schrieb:

Tatsächlich scheinen alle internen webOS Media Player von dem Problem betroffen zu sein (also auch der Media Player, Plex etc.), allerdings nur bei diesem speziellen Video. Mein Verdacht ist, dass es am Codec (VP9) oder an den schon erwähnten P3 Primaries im Video liegt, was diesen Fehler auslöst.

VP9 codec ist für youtube nicht unüblich und ich verstehe weiterhin nicht, wo du p3 primaries entnehmen kannst.

So wie ich "tech with kg" verstanden habe, war der 4000 nits Regler bei allen von ihm bisher mit dem g4 getesteten hdr youtube Videos wirksam, daher auch seine fälschliche Annahme.
Allerdings konzentriert sich der Einsatz dort eben auf lg/samsung hdr-Demomaterial

ehl (Beitrag #12) schrieb:

Oder hast du nun mit einem c4/ g4 getestet?

Das hat in dem Fall nichts speziell mit einem C4 / G4 zu tun. Wie erwähnt sind alle webOS Versionen seit mindestens webOS 22 betroffen.
Das Problem existiert also schon länger und auch bei älteren Modellen.

Es ist also so wie ich gesagt habe:
Es gibt hier keine generelle Problematik, dass die HDR Metadaten nicht verarbeitet würden und welche alle Player, Geräte oder Videos betreffen würde. Oder ein Problem, das spezifisch für die 2024er Modelle wäre.
Vielmehr tritt es in ganz speziellen Konstellationen auf und es kommt dabei zu einem Fehler bei der Verarbeitung der Metadaten.

ehl (Beitrag #12) schrieb:

Das ergibt wenig Sinn, da der TV ohnehin bei externer Zuspielung nicht nach Anwendung unterschieden kann und es daher einzig eine Frage der übertragenen Metadaten bleibt.

Die Verarbeitung der Video-Daten auf dem TV eines externen Zuspielers unterscheidet sich von der eines internen Players.
Das sollte denke ich ziemlich offensichtlich sein.

ehl (Beitrag #12) schrieb:

Im "tech with kg" video wurde definitiv ein externer Zuspieler verwendet und dennoch zeigte sich der 4000 nits Regler wirksam.

Ich weiß nicht, was er wie genau getestet hat und ich kenne sein Video auch nicht. Ich kann natürlich nicht ausschließen, dass es nicht auch noch in anderen Konstellationen zu einem Problem kommen kann.

Da ich es auch selbst noch einmal mit einem FireTV und diesem speziellen Demo-Video von dir getestet habe, kann ich aber definitiv sagen, dass nicht alle externen Player betroffen sind.

ehl (Beitrag #12) schrieb:

Und zufällig soll bei Nutzung der internen App nun der gleiche Fehler auftreten?

Das hat nichts mit Zufall zu tun. Die Ursache habe ich in meinem vorherigen Post und Oben erklärt.

ehl (Beitrag #12) schrieb:

Auch classy tech verwendet in diesem Video https://youtu.be/o0cUipF5cAI natürlich ein externes Zuspielgerät (appletv, denke ich) und wenn dort ggfls. nicht die korrekten Metadaten übertragen werden, könnte das einige hdr Helligkeitsvergleiche ad absurdum führen.

Noch einmal: es geht nicht um die Übertragung der Metadaten, sondern wie diese verarbeitet werden.

Aber ja, wenn er es mit einem Player und einem Video getestet hat, bei dem es zu beschriebener fehlerhafter Verarbeitung kommt, dann hätte er nur den beschriebenen Bug demonstriert, aber nicht wie es eigentlich sein sollte.
Ich kann aber auch bei ClassyTech nicht sagen, wie er genau was getestet hat.

Ich kann nur wiederholen, was ich auch schon im anderen Thread gesagt habe - man muss vorsichtig sein, wenn man Vergleiche beim Abspielen von Videos machen will. Auf zwei unterschiedlichen TVs unterschiedliche interne Player zu verwenden ist Äpfel mit Birnen zu vergleichen.
Idealerweise macht man so etwas immer über einen HDMI Splitter mit nur einem externen Player, was Classy soweit ich weiß auch immer macht.

ehl (Beitrag #13) schrieb:

VP9 codec ist für youtube nicht unüblich und ich verstehe weiterhin nicht, wo du p3 primaries entnehmen kannst.

Das habe ich dir doch schon in den Post von damals gezeigt und in deinen eigenen Screenshots siehst du:
"Mastering display color pimaries: Display P3"

Nutzt man YouTube über einen externen Zuspieler (bspw. FireTV, ShieldTV etc.) kommt es ebenfalls nicht zu diesem Fehler.

Die Verarbeitung der Video-Daten auf dem TV eines externen Zuspielers unterscheidet sich von der eines internen Players. Das sollte denke ich ziemlich offensichtlich sein

Ist es für mich nicht, nein
Kann so sein, muss es aber nicht grundsätzlich.

Die auf dem Zuspieler ausgeführte Anwendung (hier youtube) ist für den TV irrelevant, er empfängt die Metadaten via hdmi.

Ob bei externer Zuspielung der Fehler auftritt, hängt maßgeblich vom zuspielenden Gerät ab, nicht vom TV.
Ansonsten würde gleichermaßen mit anderen Geräten der Fehler auf dem TV hervorgerufen, was offenbar nicht der Fall ist.

Und mich wundert hier, dass zufällig mit dem von "tech with kg" verwendeten Zuspieler + hdmi Splitter das Problem auftritt, mit der internen youtube app ebenfalls, mit den von dir getesteten externen Geräten jedoch nicht.

Ich kann nur wiederholen, was ich auch schon im anderen Thread gesagt habe - man muss vorsichtig sein, wenn man Vergleiche beim Abspielen von Videos machen will. Auf zwei unterschiedlichen TVs unterschiedliche interne Player zu verwenden ist Äpfel mit Birnen zu vergleichen. Idealerweise macht man so etwas immer über einen HDMI Splitter mit nur einem externen Player, was Classy soweit ich weiß auch immer macht.

Tat tech with kg ebenso, sonst hätte die youtube Anwendung nicht auf mehreren TVs (unterschiedlicher) Hersteller zeitgleich gesteuert werden können.
Und dennoch ist das Problem identisch zur Nutzung der internen youtube app

Ich weiß nicht, was er wie genau getestet hat und ich kenne sein Video auch nicht. Ich kann natürlich nicht ausschließen, dass es nicht auch noch in anderen Konstellationen zu einem Problem kommen kann.

Das video ist inkl. Zeitstempel verlinkt und deine Aussage war nunmal

Nutzt man YouTube über einen externen Zuspieler (bspw. FireTV, ShieldTV etc.) kommt es ebenfalls nicht zu diesem Fehler.

Und dem ist dann wohl zu widersprechen, da tech with kg zwingend einen externen Zuspieler verwendet haben muss.

Das hat nichts mit Zufall zu tun. Die Ursache habe ich in meinem vorherigen Post und Oben erklärt

Du meinst:

Das hat in dem Fall nichts speziell mit einem C4 / G4 zu tun. Wie erwähnt sind alle webOS Versionen seit mindestens webOS 22 betroffen.

?

Steht mit externer Zuspielung aber eben in keinem Zusammenhang

Noch einmal: es geht nicht um die Übertragung der Metadaten, sondern wie diese verarbeitet werden

Ohne korrekte Übertragung können sie aber nicht richtig verarbeitet werden

Das habe ich dir doch schon in den Post von damals gezeigt und in deinen eigenen Screenshots siehst du: "Mastering display color pimaries: Display P3"

Ich rede ja auch von den color primaries, nicht den "mastering display color primaries", letztere sind wie üblich p3, da mastering monitore bisher nur den p3 Farbraum abdeckten, vom neu erschienenen sony hx3110 mal abgesehen.

Und zmdst. Im heruntergeladenen hdr Video wird eben bt 2020 als color primaries ausgewiesen


Und auch in den "stats for nerds" der youtube app



Oder wird in den "stats for nerds" der lg youtube app etwas anderes angezeigt?

ehl (Beitrag #15) schrieb:

Ist es für mich nicht, nein Kann so sein, muss es aber nicht grundsätzlich.

Das ist kein "kann so sein", das ist so.

Es sollte deswegen offensichtlich sein, weil mit externen Playern die Videodaten extern decodiert und als HDMI Videosignal übertragen werden, inklusive der vom Player decodierten und verarbeiteten Metadaten.
Bei einem internen Player findet die gesamte Video-Decodierung des Quellmaterials auf dem TV statt, inklusive der Verarbeitung und Speicherung der Metadaten.

Unabhängig davon rede ich nicht von irgendwelchen theoretischen Dingen, ich sehe mir genau in diesem Moment den Quellcode und die Verarbeitung dazu an. Diesbezüglich gibt es also keine Spekulation meinerseits, ich weiß wie es sich verhält.

ehl (Beitrag #15) schrieb:

Und dem ist dann wohl zu widersprechen, da tech with kg zwingend einen externen Zuspieler verwendet haben muss.

Du kannst so viel widersprechen und rumdiskutieren wie du willst.
Ich sehe direkt was intern auf dem TV passiert, mit Werkzeugen die keiner der von dir genannten Youtuber hat. Deswegen spekulieren diese Leute anhand ihrer Beobachtungen, was wohl gerade passiert ohne es aber genau zu wissen.

Ich kann jeden Schritt einzeln beobachten und weiß auch ganz genau, wie der von mir beschriebene Fehler am Ende zustande kommt. Letztlich kommen die Metadaten vom Decoder bei der relevanten Funktion in einem falschen "Format" an.
Das Einzige was ich noch nicht gemacht habe ist, die Ursachen-Kette bis an den Anfang zu verfolgen.
Meine Vermutung ist ein Problem beim internen VP9 Decoder von webOS im Zusammenhang mit den Metadaten bzw. wie diese Daten an die Verarbeitungskette weitergegeben werden.

ehl (Beitrag #15) schrieb:

Oder wird in den "stats for nerds" der lg youtube app etwas anderes angezeigt?

Was dort dargestellt wird ist vollkommen irrelevant.
Was relevant ist, ist was am Ende der Verarbeitungs-Pipeline durch die verschiedenen Schritte hindurch bei der relevanten Funktion auf dem TV ankommt und wie der TV diese verarbeitet.

Ich sehe ehrlich gesagt auch keinen Sinn mehr darin noch mit dir rumzudiskutieren, dafür ist mir meine Zeit zu schade.
Ich habe zu dem Thema bereits alles gesagt, was zu sagen ist.

Am Ende ist es wie beschrieben ein Bug, der nur in ganz spezifischen Konstellationen auftritt und der auch nur von LGE behoben werden kann.
Es ist nicht so, dass LG's webOS TVs die MaxCLL / MaxDML Metadaten nicht oder generell falsch verarbeiten würden, es kommt nur aktuell zu einem Fehler bei ganz bestimmten Umständen.
Deswegen habe ich das Verhalten ursprünglich auch nicht nachstellen können.

Das ist auch kein neuer Bug der LG TVs und hat auch nichts mit dem neuen Feature von webOS 24 zu tun, dass man jetzt die HDR10 Kurvenparameter über das Benutzermenü ändern kann. Dadurch ist es jetzt scheinbar nur öfter aufgefallen, weil Leute auf einmal keine speziellen Werkzeuge mehr brauchen, diese zu setzen und mit den Kurvenverläufen rumzuspielen.

Du kannst den Bug jetzt LGE melden oder es sein lassen, mir ist das einerlei.

Für alle anderen nur noch einmal zur Klarstellung:
Die Netflix, Prime Video, ATV+ webOS Apps etc. sind alle nicht von dem von mir beschriebenen Problem betroffen. Es trifft aktuell primär die Youtube App und die Media Player App, sofern man VP9 codierte Videos abspielt.
Mit anderen Codecs konnte ich das Problem bisher nicht beobachten und auch nicht mit externen Zuspielern, die korrekte Metadaten übertragen.

Danke für die Infos und der Klarstellung!

Itguy42

Du kannst so viel widersprechen und rumdiskutieren wie du willst.

Nur will ich das gar nicht, sondern du machst es wieder und wieder notwendig, weil du dauernd auf das Verhalten bei Nutzung der internen App verweist, welche hier gar nicht mehr das Thema ist.

Weiß auch nicht, was für dich so schwer daran zu verstehen ist, dass tech with kg einen externen Zuspieler verwendet hat.
Du sagtest selbst, dass du bisher mit keinem solchen das Verhalten reproduzieren konntest.

Ich sehe direkt was intern auf dem TV passiert, mit Werkzeugen die keiner der von dir genannten Youtuber hat.

Du siehst eben nicht, was mit der von tech with kg genutzten Gerätekombination übertragen und verarbeitet wird, da du sie nicht mal kennst.

Nochmal: interne app ist nicht mehr das Thema, da geklärt

Ich sehe ehrlich gesagt auch keinen Sinn mehr darin noch mit dir rumzudiskutieren, dafür ist mir meine Zeit zu schade.

Dito

Es ist nicht so, dass LG's webOS TVs die MaxCLL / MaxDML Metadaten nicht oder generell falsch verarbeiten würden, es kommt nur aktuell zu einem Fehler bei ganz bestimmten Umständen. Deswegen habe ich das Verhalten ursprünglich auch nicht nachstellen können.

Nochmal: ich habe von Beginn an auf dieses eine Video hingewiesen und verlinkt

Mein Frage lautete

Was ergibt die Analyse des streams des von mir genannten Videos? (https://youtu.be/UnmtvkpD-ME)

Antwort:

Was auffällt ist, dass das Video zwar einen D65 Weißpunkt hat, aber nicht die Rec.2020 Farbraum Primärfarben nutzt, sondern den P3 Farbraum. Siehe mein anderer Post, die Werte dort aus dem Video sind die Rec.2020 Farbraum Primärfarben Werte.

Meine Frage dazu war EXPLIZIT

Also das individuelle Tonemapping für max MDL =1000 ist wirksam und nicht fälschlicherweise jenes für max MDL=4000?

und zwar bezogen auf genau dieses eine Video und nicht irgendeines

Und deine Antwort darauf:

Korrekt. Ich kann aktuell nichts entdecken, das darauf hindeuten würde, dass ein falsches Tonemapping angewandt werden würde.

Also lass gut sein

Ohne tech with kg's Gerätekombination zu kennen, lässt sich die Ursache in dem Fall nicht genau klären und der möchte ja nicht antworten.