Verständnisfrage 24p Bug - Erklärung

Ich möchte ein Notebook kaufen mit einem Pentium 987/997 als CPU.

Habe ich damit auch den 24p Bug?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ja, weil es Sandy Bridge CPUs sind.

Mal ne Frage von mir zum 24P-Bug:
Macht dieser sich auch beim Abspielen von 24P-Material in XBMC bemerkbar oder nur im MediaPlayer Classic?
Oder hängt es mit den Settings in XBMC zusammen?

- - - Updated - - -

Wäre vielleicht nicht schlecht, wenn der Startpost mal aktualisiert wird.
 
Am Anfang die Punkte 10. und 11.:

10. Der Bug ist nicht in der CPU oder GPU, sondern im Series5, Series6 und Series7 Chip auf dem MoBo (B, P, H, oder Z, egal ob 51, 55, 57, 65, 67, 68, 75, 77)
11. Behoben wird das ganze FRÜHESTENS mit Serie 7 Chipsätzen (IVY Bridge) wurde das Ganze mit Serie 8 Chipsätzen (Haswell)

Und weiter unten müsste noch die CPU \ Chipsatz-Tabelle aktualisiert werden (die "???" können durch "vorhanden" ersetzt werden und Haswell müsste hinzugefügt werden).
 
Zuletzt bearbeitet:
Verstehe nur nicht auf welche Informationen sich diese Änderungen stützen.
Im Ergebnis ist ja auch egal also naja ...
 
Soweit ich weiss ist alles ab Haswell Sockel 1150 und ich wüsste nicht wie man jetzt beweisen soll in welcher Komponente die Änderung erfolgt ist.
 
Ja, durch den Sockel-Wechsel lässt sich nicht mehr nachweisen, ob der Bug jetzt am Chipsatz vom Board oder an der CPU lag.
Spielt aber auch keine Rolle mehr, denn Fakt ist: Vor Haswell war der Bug da, ab Haswell nicht mehr ^^
 
Sag ich doch. ;)
Es macht aber Punkt 10 und 11 zu einer ungewissen Behauptung mit wenig Relevanz.
 
Achsooo!
Ja dann eben bei Punkt 10 ein "vermutlich" zwischen "ist" und "nicht" reinsetzen und bei Punkt 11 einfach hinter "Behoben wurde das Ganze mit" -> "Haswell" reinpacken und was dahinter steht einfach löschen :d
 
Es macht aber Punkt 10 und 11 zu einer ungewissen Behauptung mit wenig Relevanz.
...
Ja dann eben bei Punkt 10 ein "vermutlich" zwischen "ist" und "nicht" reinsetzen und bei Punkt 11 einfach hinter "Behoben wurde das Ganze mit" -> "Haswell" reinpacken und was dahinter steht einfach löschen
Zum Vergrößern anklicken....
Freunde, jetzt weiß ich auch, warum IHR den 24p Bug seht und ich nicht... Pedanten :-)

Und nachweisen kann man es prinzipiell. Denn der neue Intel NUC läuft noch mit dem Q77 Chipsatz, aber mit Haswell CPU. Wenn da der 24p Bug noch ist, ist es der Chipsatz, wenn nicht, ist es die CPU...

Bitte mal jemand mit dem NUC Haswell testen.
 
Zuletzt bearbeitet:
sandreas schrieb:
der neue Intel NUC läuft noch mit dem Q77 Chipsatz
Zum Vergrößern anklicken....
nein
Bitte mal jemand mit dem NUC Haswell testen.
Zum Vergrößern anklicken....
vergiss es, das Thema ist erledigt!

--
erbsenzaehlerlpfq.jpg
 
Zuletzt bearbeitet:
Interessante Informationen. Danke!

Bezüglich "24p-Bug, "Ruckeln" und einer extra Soundkarte (Danke an PatkIllA):"

Wenn ich nun ein Mini-ITX-System zusammenstelle mit
"ASRock H87M-ITX" und "i3-4130T"
und den Sound dann in OpenELEC/Linux-XBMC über OnBoard-SPDIF als DD/DTS-Passtrough ausgebe, kann ich bei typischem 23.976-Material von kleinen Rucklern ausgehen?
 
Zuletzt bearbeitet:
Abgesehen davon dass die T CPU selten Sinn macht, solte dein System ein Haswell sein und somit kein typisches 24p Ruckeln haben.
 
Ich habe mich damit ausschließlich auf folgenden Abschnitt/Post bezogen, bei dem es nicht um den eigentlichen Pre-Haswell 24p Bug geht:

http://www.hardwareluxx.de/communit...4p-bug-erklaerung-797983-11.html#post18895547

Dort wird dargelegt, dass ein Microruckeln quasi sicher ist, sobald man etwas anderes nutzt als kombiniertes HDMI Bild+Ton am selben (HDMI-)Port mit gemeinsamen Taktgeber.

Sprich: Egal wie schlank und gut optimiert das System (ggf. Linux/OpenELEC), sobald HDMI Bild (Grafikkarte) + SPDIF optischer Ton (OnBoard-Sound) kombiniert wird = Miroruckeln, da Bild+Ton keinen gemeinsamen Taktgeber nutzen.
 
Zuletzt bearbeitet:
Es gibt nicht zwangsläufig Mikroruckler, aber es hat Auswirkungen (A/V Drift, Mikroruckler oder Tonaussetzer je nach Sync. Ansatz).
Ebenso ist je nach Software der Umgang mit dem Problem verschieden.
z.B. könnte man wenn der Drift nicht zu groß ist über einen langen Zeitraum (> normale Filmdauer?) genau 1 Frame weglassen oder wiederholen.
Das führt dann zu einem Mikroruckler pro Wiedergabe und wäre nicht wirklich dramatisch.

Damals (Reclock Zeiten) hat man das auf die Spitze getrieben und den VSync verschoben (Powerstrip) und hat dann einen verworfenes/wiederholtes Audiopaket alle XX Stunden erhalten.
War aber nicht ganz einfach einzustellen und würde ich grundlos auch nicht empfehlen.
Erstmal ausprobieren ob es nicht halbwegs passt.
 
@nuts

Klingt gut. Also gebe ich der Kombi aus Haswell-HDMI-Bild + OnBoard-Sound SPDIF-Ton (DD/DTS) mal eine Chance unter OpenELEC :-)

Danke!
 
got no name schrieb:
Ich habe mich damit ausschließlich auf folgenden Abschnitt/Post bezogen, bei dem es nicht um den eigentlichen Pre-Haswell 24p Bug geht:

http://www.hardwareluxx.de/communit...4p-bug-erklaerung-797983-11.html#post18895547

Dort wird dargelegt, dass ein Microruckeln quasi sicher ist, sobald man etwas anderes nutzt als kombiniertes HDMI Bild+Ton am selben (HDMI-)Port mit gemeinsamen Taktgeber.

Sprich: Egal wie schlank und gut optimiert das System (ggf. Linux/OpenELEC), sobald HDMI Bild (Grafikkarte) + SPDIF optischer Ton (OnBoard-Sound) kombiniert wird = Miroruckeln, da Bild+Ton keinen gemeinsamen Taktgeber nutzen.
Zum Vergrößern anklicken....

Kollege von mir hat das so laufen (sound über toslink an AVR mit B75M Board) seit nem Jahr und hat sich bisher nicht beschwert, aber wenn das so schwer zu sehen ist wie der 24p Bug, dann sehen ihn evtl. auch nicht alle oder die Software kann das gut verstecken.
 
Wie sollte man eigentlich bei XMBC die Video Settings einstellen, damit man kein 3:2 Pulldown und 24p-Ruckeln hat?
24p-fähiger TV und Haswell vorhanden.
Sound geht über HDMI.
 
Wie hast du Sie denn eingestellt dass du ein 24p Ruckeln hast?
 
Wie sieht es bei Bay Trail aus? Hat die Platform den Bug ggf. noch?
Ich interessiere mich für dieses Board.

Edit:
Die Recherche hat ergeben, dass die Intel HD Grafik auf Ivy Bridge basiert. Somit müsste der Bug ebenfalls enthalten sein.
 
Zuletzt bearbeitet:
Eine Frage: Ich sehe mich gerade nach einem gebrauchten Notebook um, für mich attraktiv ist eines aus der Ivy Bridge-Generation - klar, mit HD 4000-Grafik gibt es den Bug, zusätzlich hat es allerdings eine GeForce GT 650M - wäre man damit von dem Bug verschont (mir geht es um den HDMI-Ausgang)? Bin etwas skeptisch, da sich die CPU- und die dedizierte Grafik ja den Ausgang "teilen".
Danke für die Info!
 
Zuletzt bearbeitet:
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