Verständnisfrage 24p Bug - Erklärung

Basian schrieb:
Das hat beim Anschluss direkt an den TV auch super geklappt. Nur jetzt halt nicht mehr.
Zum Vergrößern anklicken....
Kannst das ja mit dem TV nochmal gegenchecken.
Damit wäre dann sichergestellt, dass es kein Einstellungsfehler ist.

Ich kann mir nur vorstellen, dass madVR die benötigten Display-Modi für nicht verfügbar hält und deshalb die Umschaltung nicht funktioniert.
Das die manuelle Umschaltung funktioniert spricht allerdings nicht dafür.

P.S: MPC-HC kann auch die Frequenz automatisch ändern. Funktioniert das mit dem AVR in Kette?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Die automatische Umstellung übernimmt ja eigentlich madVR. Und wenn ich das in den Intel Grafikeinstellungen mache klappt das auch alles wunderbar. Den gegencheck habe ich schon hinter mir. Mir fiel das nämlich sofort auf.
 
htpcdude schrieb:
Tja, deshalb warne ich ja schon die ganze Zeit vor der Kombination: HTPC per HDMI in AVR, AVR per HDMI zum TV.
Einige finden dass ja so toll fortschrittlich.
Ich sage schon die ganze Zeit, dass bei dieser Methode eine Menge negativer "Sideeffects" entstehen können und es sieht so aus, als ob du einem dieser Sideeffects gerade zum Opfer fallen würdest.
Einen optischen Ausgang braucht man natürlich nicht dank HDMI, schon klar.
Zum Vergrößern anklicken....
HDMI-Audio ist aber die einzig praktisch Möglichkeit die Ruckelproblematik zu lösen ohne an Bild oder Ton rumzurechnen.
Wobei es technisch sicher auch nicht wirklich unmöglich wäre alles von einem Masterclock abzuleiten oder einen normalen SPDIF an der Grafikkarte anzubieten.

Das EDID gefummel und evtl sonstige ungewollte und auch nicht immer nachvollziehbare Manipulationen können aber schon nerven.
 
HDMI-Audio ist aber die einzig praktisch Möglichkeit die Ruckelproblematik zu lösen ohne an Bild oder Ton rumzurechnen.
Zum Vergrößern anklicken....

Welche Ruckelproblematik?

Wenn man die neuen HD-Audioformate nicht braucht, besteht eigentlich überhaupt kein Grund mehr, den HTPC über den AVR an den TV durchzuschleifen.
Ich kann darin dann zumindest keinen Mehrwert erkennen.
Muss aber wohl jeder selbst wissen und ist ja auch nicht Threadgegenstand.

Gruß
hd
 
htpcdude schrieb:
Welche Ruckelproblematik?

Wenn man die neuen HD-Audioformate nicht braucht, besteht eigentlich überhaupt kein Grund mehr, den HTPC über den AVR an den TV durchzuschleifen.
Ich kann darin dann zumindest keinen Mehrwert erkennen.
Muss aber wohl jeder selbst wissen und ist ja auch nicht Threadgegenstand.
Zum Vergrößern anklicken....
Um genau das geht es hier.
Mit onboard oder Soundkarte hast du einen weiteren Taktgeber und damit gelegentliches Bildruckeln, um die Taktunterschiede auszugleichen.
 
Mit onboard oder Soundkarte hast du einen weiteren Taktgeber und damit gelegentliches Bildruckeln, um die Taktunterschiede auszugleichen.
Zum Vergrößern anklicken....

Ich verwende eigentlich nur onboard-sound, aber von diesem Problem war ich bisher weder betroffen, noch habe ich davon gehört!

Gruß
hd
 
htpcdude schrieb:
Ich verwende eigentlich nur onboard-sound, aber von diesem Problem war ich bisher weder betroffen, noch habe ich davon gehört!
Zum Vergrößern anklicken....
Du bist betroffen.
In der Reclock-Readme war das halbwegs ausführlich beschrieben und das war genau der Grund für Reclock. Es halt allerdings das Problem auf den Ton verlagert. Aus den Logs konnte man mit etwas Glück und viel Powerstrip-Gefummel auch ein Timing suchen, dass besser zum Taktgeber der Soundkarte passte.
Mit HDMI gibt es jetzt einen gemeinsamen Taktgeber für Video und Audio.
Im Studiobereich gibt es Hardware mit der man einen gemeinsamen Takt von außen vor gibt (genlock).

Das gehört aber wohl zu den am meisten falsch oder unvollständig verstanden Problemen.

Da muss man sich halt relativ tief reindenken, was alles gegeben sein muss, damit alle Bilder gleichlang angezeigt werden, während der Ton ohne Unterbrechung weiterläuft und dabei synchron bleibt. Und das ganze noch von einem weiteren Timer per CPU gesteuert werden muss, die auf einem Multitasking OS auch noch dauernd unterbrochen werden kann.
Auf einem Standalone hat man einen Taktgeber, von dem sich alles ableitet und ein viel einfacheres Betriebssystem.
 
Zuletzt bearbeitet:
Und doch ist es vorhanden ...
Zum Vergrößern anklicken....

Will ich ja auch nicht ausschließen. Nur da ich weder jemals davon betroffen war, noch jemanden kenne der davon betroffen war und auch nichts davon gelesen habe, ist dieses Problem für mich nicht wirklich existent.
Ich weiss von allen möglichen Leute, die alle möglichen Probleme haben und dass sich viele dieser Probleme auf Eigenverschulden zurückführen lassen, also falsche Settings und so einen Kram.
Ich möchte jetzt auch nicht sagen, dass dieses mir bis jetzt unbekannte Problem, auch auf diese Ursachen zurückzuführen ist.
So etwas als Begründung einen AVR per HMDI in den Kreislauf einzubinden, habe ich jedenfalls auch noch nicht gehört.
Mal ganz davon abgesehen präsentiert sich HDMI im Gerätemanager ebenfalls als Audiodevice und damit hat es sehr wahrscheinlich auch einen Taktgeber.
Ohne jemandem zu nahe treten zu wollen, ich bleibe bei diesem Problem weiterhin skeptisch.


Gruß
hd

Nachtrag:

In der Reclock-Readme war das halbwegs ausführlich beschrieben und das war genau der Grund für Reclock.
Zum Vergrößern anklicken....

Reclock war für mich bisher irrelevant, da es keinen Bitstream sondern nur pcm ausgeben kann. Ich brauche einen sauberen Bitstream und den Rest macht der AVR.
Deshalb kann ich zu Reclock auch nicht viel sagen.
 
Zuletzt bearbeitet:
htpcdude schrieb:
Mal ganz davon abgesehen präsentiert sich HDMI im Gerätemanager ebenfalls als Audiodevice und damit hat es sehr wahrscheinlich auch einen Taktgeber.
Zum Vergrößern anklicken....
Einen (oder gleich mehrere) Taktgeber hat alles im Rechner.
Ist nur die Frage wo der ursprünglich herkommt.

Die madVR statistics sind ganz gut. Da mal (ohne Smootvision) auf die "1 frame drop/repeat in x" und dropped/delayed frames schauen. Jeder drop/delayed Frame ist ein Ruckeln.
 
Ich habe gelegentlich auch den ein oder anderen Ruckler, was ich aber für ganz normal halte. Die HDD im Spindown läuft z.b öfter an, oder ein geplanter Task wird im Hintergrund ausgeführt. Da kann es ja schon mal zu dem ein oder anderen Ruckler kommen. Dass da die Soundkarte bei mir verantwortlich ist, denke ich jetzt jedoch eher nicht.

Gruß
hd
 
htpcdude schrieb:
Ich habe gelegentlich auch den ein oder anderen Ruckler, was ich aber für ganz normal halte. Die HDD im Spindown läuft z.b öfter an, oder ein geplanter Task wird im Hintergrund ausgeführt. Da kann es ja schon mal zu dem ein oder anderen Ruckler kommen. Dass da die Soundkarte bei mir verantwortlich ist, denke ich jetzt jedoch eher nicht.
Zum Vergrößern anklicken....
Das kommt alles noch als Problem dazu.
Es ist ja auch nur in mehr oder wenigen großen Abständen mal ein Bild, dass kurzer oder länger angezeigt wird. In vielen Situationen kann man das auch nicht wirklich sehen. Bei Schwenks stört es aber definitiv.
 
Zuletzt bearbeitet:
Dann halte ich den Zustand, nennen wir ihn einfach mal "100%ruckelfree";) für äußerst schwer erreichbar. Es spielen dann einfach zu viele Variablen eine Rolle.

Gruß
hd
 
Kleines Update:
Nachdem ich die Umstellung in madVR abgeschaltet habe und dafür die im MPC-HC angeschaltet habe geht das ganze wieder.
 
Tach,
gibt es mittlerweile was neues?
Möchte gerne mal auf HDMI 1.4 umsteigen um Full-3D zu testen. Habe jedoch zwecks 24p-bug nur eine ATI 5450 oder so ähnlich drin...
Gibt es schon eine Bugfreie Variante? Oder eine Empfehlung für eine sparsame Graka...

mfg
 
Haswell kaufen, dann hastes nicht mehr. Oder GT610 / GT640
 
Hallo Freundä, wollte mal mein Ergebnis melden. Bin nach der Anleitung im ersten Post vorgegangen. Bis auf MPC-HC einrichten 'Step Three: Confirmation' hat alles geklappt: Die OSD Zeile h264... sieht bei mir anders aus.

Zur Hardware (Haswell):
ASRock B85M Pro4
Intel Pentium G3220, boxed
1x 2GB DDR3 RAM
64GB Samsung 830 SSD
Seasonic SS-300SFD
Windows 7 32Bit
Idle ~22 Watt

Das Mainboard kam mit BIOS Version 1.50 Im BIOS Menü wird C2 angezeigt. Das neue Stepping scheint also still schweigend eingeführt worden zu sein. Bestellt bei computerunivers(dot)net am Montag.

Beim abspielen des Testvideos zeigt das OSD/ Zeile Display 23.97650 :love: und bleibt stabil. Die letzten beiden Stellen zappeln etwas.

Eigentlich wollte ich 'OpenELEC 3.2.0 Intel' verwenden aber irgendetwas passt mit der Helligkeit nicht. Schwarz ist nicht schwarz sondern eher grau. Und wenn ich den Befehl 'xrandr --output HDMI2 --set "Broadcast RGB" "Full"' anwende säuft schwarz ab. Grau 17-24 im Testbild blinkt nicht mehr. Mein Panasonic Plasma ist kalibriert. Kennt sich da jemand aus?
Des weiteren kommt über HDMI kein DTS-HD am AV Receiver an. Unter Win7 ebenfalls kein HD Ton. Intel Grafik Treiber 4. Generation -> 15.31.17.3257
Ansonsten kommt der Pentium gut mit 1080p h264 Dateien klar. Beide Kerne sind zu 6-8% ausgelastet.
 

Anhänge

  • 24p_Test.png
    24p_Test.png
    17,2 KB · Aufrufe: 112
Zuletzt bearbeitet:
Das die 22W kein Rekord aufstellen ist mit klar. Nur als Anhaltspunkt. Immerhin ein 9 Jahre altes Netzteil ohne Haswell Support.
Nur zum Vergleich: H55 + I3 540 + G210 ~38W Idle am gleichen NT
 
Ist der errechnete Framesverlust (55min im Screenshot) konstant oder schwankt dieser?
Ansonsten sieht es gut aus.

Mit der Full RGB (0-255) Ausgabe hat Intel, zumindest unter Windows, noch so seine Schwierigkeiten.
Und wenn ich den Befehl 'xrandr --output HDMI2 --set "Broadcast RGB" "Full"' anwende säuft schwarz ab
Zum Vergrößern anklicken....
Diesen Test würde ich so deuten, dass es unter Linux richtig funktioniert.
Leider lassen sich die meisten Panasonic nicht auf 0-255 einstellen (bzw. nur bei DVI (PC) => Hdmi (TV) Verkabelung).
Welchen hast du denn?
 
errechnete Framesverlust: Da schaue ich heute Abend mal nach.

Pana 42GW20 via HDMI, dazwischen hängt noch ein Yamaha 767 AVR im pass through
Unter Win7 sieht das schwarz gut aus. Treiber ist auf Limit 16-235 eingestellt.
 
JOE_80 schrieb:
Treiber ist auf Limit 16-235 eingestellt.
Zum Vergrößern anklicken....
Das ist für deinen TV auch richtig.
Bei Linux bin ich jetzt überfragt. Auch dort wäre 16-235 die richtige Einstellung.

Bei 0-255 Ausgabe schneidet dein TV Tonwertanteile ab.
Die Schwarztöne 0-15 werden alle als 100% schwarz dargestellt und deshalb saufen alle Details im schwarz ab.
Daher auch meine Vermutung, dass sich unter Linux die Intel-GPU zur 0-255 Ausgabe überreden lässt.
Ist eigentlich erfreulich, aber für deinen TV unbrauchbar.
 
Der Meinung bin ich auch. Nun wird mit dem Befehl 'xrandr --output HDMI2 --set "Broadcast RGB" "Limited 16:235"' das schwarz zu grau. Ich vermute Treiberprobleme im OpenELEC Build. Wenn ich eine Nvidia G210 einbaue passt alles mit OpenELEC. Aber das war nicht Ziel der Übung...möchte die iGPU nutzen.

Gibt es überhaupt Filme mit erweitertem Farbraum?
 
So hab das Käsescheibchen Test Video mal 3 Minuten laufen lassen. Danach hat sich der Wert nicht weiter verbessert. Der errechnete Framesverlust geht bis auf ~3 Stunden hoch. Das sollte für die meisten Filme ausreichen ;)
 

Anhänge

  • 24p_Test_2.png
    24p_Test_2.png
    16,4 KB · Aufrufe: 112
Das sieht soweit gut aus.
Danke für den Test.

Zu deinem Farbproblem kann ich dir mangels Linuxkenntnissen nicht wirklich weiterhelfen.
Mit dem erweiterten Farbraum hat das eigentlich nichts zu tun.
Du könntest 16-235 ausgeben und versuchen am PC mit den Helligkeit (Schwarztreppe)- und Kontrastreglern zu spielen.
 
Wollte noch ergänzen das DTS-HD funktioniert wenn man in XBMC (Win7) den Sound via WASAPI ausgibt und echtes Vollbild statt Fenstervollbild wählt.
 
Wollte noch ergänzen das DTS-HD funktioniert wenn man in XBMC (Win7) den Sound via WASAPI ausgibt und echtes Vollbild statt Fenstervollbild wählt.
Zum Vergrößern anklicken....
Sicher das es nur mit aktiviertem Setting "Benutze Vollbildfenster anstatt echtes Vollbild" funktioniert ? Eigentlich sollte das darauf keinen wirklichen Einfluss haben.
 
OK, scheint doch egal zu sein. Nur manchmal startet der Film mit heftigem Ruckeln. Das allerdings nur bei Filme mit 24.000384 fps
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh