Verständnisfrage 24p Bug - Erklärung

Ja das liest du richtig, es ist zwar besser geworden, aber immer noch nicht perfekt
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
nuts schrieb:
23,976 => 23hz einstellen.
Ansonsten hast du wieder den klassichen 24p Bug (23,976 Quelle & 24,000 Ausgabe) mit den periodischen Rucklern alle ~42sek.
Zum Vergrößern anklicken....

Danke für die Erklärung. Auf diesem Wege habe ich 23,996fps, mit einem H77 Board von ASRock und einem Celeron G530 (Sandy).

-

Auch wenn die Frage jetzt Off-Topic ist (Antwort auch gerne per PN), würde ich sie gern einfach mal in den Raum werfen, da hier ja einige Experten mitlesen:

Ich habe seit 2 Woche ein merkwürdiges Problem (an 2 von 3 Rechnern), das ich mir beim besten Willen nicht erklären kann:

Problem: Egal mit welchem Renderer (Haali, EVR oder madVR) und egal mit welchen External Filter/Video Decoder (CoreAVC, ffdshow, LAV, madVR) und Player (MPC-HC oder VLC) sehe ich bei schnellen Bewegungen, und wirklich nur dann, seit 2-3 Wochen immer deutliche Würfel/Blöcke (so als wäre die Bitrate viel zu niedrig bzw. das Bild sehr sehr stark komprimiert worden, also wie bei einem hässlichen und starken JPEG Komprimierung).

- Die Encodes sind aber okay und liefen noch vor 2-3 Wochen (und 6 Monate davor) prima.
- Problem tritt am Desktop Rechner und am HTPC auf, aber erst seit 2-3 Wochen. Habe sowohl Hardwaretechnisch als auch Softwaretechnisch eigentlich nichts verändert. Der Office Rechner hat das Problem nicht, mit ähnlicher Hardware und selbigen Einstellungen
- Windows7 x64 neu zu installieren hat nichts gebraucht, genau das selbe Problem wie vorher

Ich bin total ratlos... zumal die MPC-HC und EVR Einstellungen usw ja auch 6 Monate perfekt liefen, also auch nicht falsch sind.

Schon mal von so einem Problem gehört? Hat jemand vllt. einen Rat?
 
Zuletzt bearbeitet:
Ihr lasst alle unter den Tisch fallen, dass die angezeigten Werte auch wieder relativ zum Taktgeber des Systems ist. Die absolute Anzeige sagt also mangels Eichung überhaupt nichts aus.
Weiterhin will man beim Video gucken nicht genau mit 23,9760000 gucken sondern so dass es nicht ruckelt und dafür muss es synchron zum Takt der Soundausgabe laufen und nicht genau den nominellen Wert treffen.
100%ig geht das nur mit einem gemeinsamen Taktgeber für Ton und Bild, wie das Standalonegeräten üblich ist. Beim PC geht das relativ einfach nur per HDMI Ausgabe. Für Studios gibt es spezielle Hardware.

Eine weitere Methode ist es die Bildausgabe anzupassen. Dafür schraubt man bspw. mit Powerstrip an den Timings rum. Mit ein bisschen Glück findet man da eine Einstellung die sehr genau zum Soundteil passen und vom Wiedergabegerät noch angenommen werden.

Man kann das sehr einfach mit den Graphen unten rechts im MPC HC nachvollziehen. Die müssen dauerhaft parallel bleiben. Oder mit den Stats von madVR.

Mit einer Soundkarte oder onboard Sound hat man praktisch immer ein Microruckeln, da Bild und Ton synchronisiert werden müssen und das machen die PC Player per Bildwiederholung oder auslassen. Alternativ kann man am Sound rumrechnen per Reclock. XMBC hat sowas direkt eingebaut. Damit verliert man dann aber das direkte Durchschleifen von vorcodierten Sound von Dolby und dts.
 
Zuletzt bearbeitet:
Nichts anderes habe ich schon mehrfach versucht zu erklären.
Aber da auch diverse Testseiten die Ruckelperioden hochrechnen muss man bei diesen Themen wohl etwas nachsichtig sein.
 
nuts schrieb:
Nichts anderes habe ich schon mehrfach versucht zu erklären.
Aber da auch diverse Testseiten die Ruckelperioden hochrechnen muss man bei diesen Themen wohl etwas nachsichtig sein.
Zum Vergrößern anklicken....
Die meisten Tests in Sachen HTPC Tauglichkeit schauen sich an, dass die Beschleunigung funktioniert und dass die CPU Auslastung schön niedrig ist. Da wird wahrscheinlich einfach 60 Hz gefahren.
Ich habe noch keinen einzigen Test gefunden, der das Problem verstanden hat.
 
Gut das dies nochmal erwähnt wurde...
Es ist immer noch ne sache wie der Mediaspeed/directshow graph clock der meist vom Audioclock abgeleitet wird zur refresh rate passt. die eigentliche nominelle Bildrate des Video ist nebensächlich! so lange
der tatsächliche Mediaspeed zur tatsächlichen Refreshrate passt..

insofern möchte ich hier nochmal dies posten
http://www.hardwareluxx.de/communit...4p-bug-erklaerung-797983-10.html#post18789180

Ich weiß jetzt nicht ob hier speziell irgendwelche filter zum einsatz kamen welche dem grundproblem der verschiedenen clocks irgendwie rechnung trägt????.

aber zumindest seine tests die er mit 23p/23hz zeigt, laufen wohl 1A laut seinen stats. der Mediaspeed liegt zwar bei 23.973 aber die refresh rate ebenso, clock ist bei 0ppm,
linien laufen parallel.. da soll doch noch wer sagen intel kann keine 23.976fps abspielen, zumindest in dem bsp wird es wohl passen... Auch wenn nun nominell der mediaspeed bei 23.976 liegt ist dies völlig irrelevant, wenn
der reale mediaspeed zur Refresrate passt wie in dem bsp... Seine 24hz ausgabe versuche mit dem nominell 23.976 Material zeigen dagegen drifts allerdings bei weitem nicht so wie man erwarten würde
(normal wären ~1000ppm drift zu erwarten bei nominell 23.976fps Mediaspeed und 24hz refreshrate, es sind aber nur umme 50ppm, was die zeitspanne doppelter oder weggelassener
bilder für den sync deutlich verlängert, hier sicher nicht alle 41,66s sondern müsste gut das 20zig fache betrage, zumindest wenn wir davon ausgehen das ein bild
ausgelassen/wiederholt wird, wenn audio und video um +-1 bild auseinanderlaufen)...
Ich selbst nutze einfach reclock um den Mediaspeed von der refreshrate abzuleiten, sound wird natürlich nachprocessiert/ oder einfach gepitcht aber damit kann ich aktuell gut leben...
ansonsten ist es schon schwer von vorteil wenn man nur einen taktgeber für Audio und video hat, wobei auch hier grenzen sind. für Live TV zum bsp ist ein gemeinsamer Audio Video
Clock natürlich genauso von vorteil aber im idealfall müsste dieser (z.b perr PLL) sich auch noch auf den Provider Clock vom DVB Stream syncen wofür der PC aber im grunde
auch nicht gemacht ist...
 
Zuletzt bearbeitet:
Hi,

der verlinkte Test zeigt die Daten aus dem EVR Sync Renderer, da wird der Mediaspeed an die Refreshrate angepasst - ähnlich wie reclock.

Solange man Audio nicht an einen AV-Receiver bitstreamt kann man sich ja über diverse Methoden (XMBC "Sync Optionen", MPC-HC "EVR Sync" Renderer, Reclock etc.) behelfen um auch auf Intel Systemen eine ruckelfreie Wiedergabe zu ermöglichen, aber wenn ein AV Receiver zum Einsatz kommt und auch die HD Audio Formate genutzt werden sollen disqualifiziert sich die Intel Grafik aufgrund des 24p Bugs.
 
Zuletzt bearbeitet:
Okay, nur warum nutzt man hier nun einen EVR Sync Renderer (kenne ich persönlich nicht, aktuell hab ich nur XP Rechner mit VMR9 und nutze ggf. reclock zum clock syncen) welcher wohl gegen die clockdrift arbeitet
und möchte damit auf irgendeinen bug(bug ist blödes wort, ich bekomme auch bei meinen ATI/NV systemen wenn ich onboard Audio nutze keine gleichen Refresrate/mediaspeed basis
ohne nachzuhelfen) zurückführen???
nutze ich nen clock syncer wie will ich damit dann eigentlich auf das eigentliche problem eingehen, bzw. im "vollen umfang" kenntliche machen???...
Okay der Sync rendere erklärt dann wohl aber warum es bei timmey im prinzip recht ordentlich läuft zumindest bie seinem so gennanten 23p/23hz test im grunde nahe perfektion (<0.5ppm, aufgrund der auflösung bliebe
noch mindetsens dieser mögliche drift).... es müsste hier schon ein imenser zufall herschen, sollten zwei separate clocks so gut zusammenligen, da hätte ich mir eigentlich
gleich denken können/müssen das hier ein syncer im spiel war
 
Zuletzt bearbeitet:
Bei onboard Audio oder extra Soundkarte ist man sowieso weitesgehend raus. Die Abweichung der üblichen Quarze ist größer als das eine Promille Unterschied von 24 zu 23,976. Wie gut das passt ist da schon Glückssache.

Gibt es eigentlich einen Videorenderer, der das Bild analysiert und bei wenig Bewegung oder nochbesser bei einem Schwarzbild bei einem Schnitt die Clockdifferenzen ausgleicht ohne das man es sieht? In den meisten Fällen sollte das reichen wie den 24p Bug oder unterschiedliche Frequenzen von Video und Audiohardware auszugleichen ohne das man es sieht oder am Ton rumrechnen muss.
 
PatkIllA schrieb:
Gibt es eigentlich einen Videorenderer, der das Bild analysiert und bei wenig Bewegung oder nochbesser bei einem Schwarzbild bei einem Schnitt die Clockdifferenzen ausgleicht ohne das man es sieht? In den meisten Fällen sollte das reichen wie den 24p Bug oder unterschiedliche Frequenzen von Video und Audiohardware auszugleichen ohne das man es sieht oder am Ton rumrechnen muss.
Zum Vergrößern anklicken....
Nein - nicht das ich wüsste.
Grund: Quasi unmöglich.

Es gibt diverse Ansätze wie z.B. den EVR Sync und diese sind wesentlich erfolgsversprechender.
 
cehlscheid schrieb:
Hallo,

gute Fragen :)

-> http://www.hardwareluxx.de/community/f89/verstaendnisfrage-24p-bug-erklaerung-797983-11.html#post18821571
Zum Vergrößern anklicken....

Okay :) dein schon zuvor erwähnter einwand zum EVR Sync renderer und der testmethodik um den 24p bug "vollumfänglich" sichtbar zu machen ist mir beim überlesen wohl entgangen, und
wenn die messungen seitens des Sync renderes so wie du sagts wohl noch etwas jumpy sind, dann ist dies natürlich auch etwas problematisch, selbst kann ich es aktuell mangels EVR fähigen
pc (und neun XP zähle ich nun nicht dazu auch wenn es mit aktuellen dot net SW mäßig wohl geht) nicht nachvollziehen, auf den screenis sieht man nur die momentaufnahme...
Nen GetTickCount() oder ähnliches wird man wohl sicher nicht verwenden ??, wäre zumindest mit einer auflösung umme 17ms etwas schwabbelig....


Quarze und Oszilatoren gibt es auch schon genauer als das man meherer 1000ppm dazwischen hat(solche sind mir nichtmal bekannt)... die frage bleibt ja nur mit all den weiteren Clockbauteilen(Teiler, Multis, PLLs) wie
genau bekommt man den gewünschten clock.. Standard Quarze/OSC`s haben ne toleranz von besser 100ppm, dann mkommt noch aging und Tempdrift dazu... Man wird nur nicht von jedem seperaten Quarz/OSC Clock
als basis mit der gegebenen nachgeschalteten taktbeinflussungsmöglichkeiten HW(die in den zweigen nicht gleich sein muss) den clock so fein zu einstellen zu können.. macht auch kein sinn, in dem fall nimm man einen
clock oder synct zueinander....
Mir sind jetzt keine Quarze oder OSC`s bekannt die hier mit toleranzen über 1000ppm daherkommen, gut nach sowas such ich erst gar nicht.... Schaue z.b mal bei Farnell der überwigende anteil
der Quarze im Angebot liegen bei 30ppm toleranz, gefolgt von 50ppm typen, bei den OSC`s kann man dann ja selbst mal schauen.. Der punkt ist halt auch aus u.u. zwei völlig verschiedenen grundtakten
die noch geteilt, multipliziert und was auch immer gemacht wird, zweimal einen identischen clock rauszubekommen ist usus... Nimm auf der einen seite nen quarz mit rund 1Mhz und auf der anderen seite
einen mit 1,024Mhz, beide haben toleranzen umme 30ppm.. und versuche damit bei beiden auf exact 25hz zu kommen, dabei berücksichtigen, das man reel hier ggf. nicht belibig teilen kann je nachdem wie die HW aussieht..
Bei abweichungen mehrere 100ppm ist das imo weniger die absoltue toleranz der taktgeber, sondern weitere abweichung aufgrund der beschränkungen wie man den clock beeinflussen kann...
Mal von den drifts einzelner Taktgeber zu schweigen, aber auch diese liegen über einen weiten Tempbereich weit unter 1000ppm
 
Zuletzt bearbeitet:
PatkIllA schrieb:
Warum ist das quasi unmöglich? Zwei Bilder zu vergleichen ist nun nicht die Kunst.
Was genau macht das EVR Sync eigentlich?
Zum Vergrößern anklicken....
Schau hier mal rein: vertical sync

P.S. Einfach zwei Bilder vergleichen und davon abhängig machen wann ein Frame verworfen oder wiederholt wird?
Bewegungsanalyse ist äußerst kompliziert.
Es gibt sowohl statische alsauch dynamische Bildanteile.
Was macht man wenn keine geeignete Szene erkannt wurde?
Was wenn zahlreiche Szenen vorhanden wären? Ständig verwerfen/wiederholen obwohl gar nicht nötig?
 
nuts schrieb:
Schau hier mal rein: vertical sync

P.S. Einfach zwei Bilder vergleichen und davon abhängig machen wann ein Frame verworfen oder wiederholt wird?
Bewegungsanalyse ist äußerst kompliziert.
Es gibt sowohl statische alsauch dynamische Bildanteile.
Was macht man wenn keine geeignete Szene erkannt wurde?
Was wenn zahlreiche Szenen vorhanden wären? Ständig verwerfen/wiederholen obwohl gar nicht nötig?
Zum Vergrößern anklicken....

Ich denke PatKilla ging es darum das nötige auslassen oder wiederholen eines bildes für einhaltung des AV Sync nicht einfach strikt
zumachen, z.b wenn Audio/Video Sync genau eine Bildzeit auseinander liegt, sondern an stellen das Bild droppen/wiederholen, wenn es schwarz
ist oder sich nicht kaum bewegt. Die Idee dabei ist für einen alltagsnutzen nicht so verkehrt.
Aber mal ne andere frage, weil hier ja auch geren berechnet wird wann ein Bild gedroppt/wiederholt wird.. Wann wird das eigentlich vom renderer gemacht??
immer dann Wenn Audio Video +- 1Bild, ein halbes oder wann auch immer auseinander liegen?? oder bei überschreitung fester Audio/video Sync verzug thresholds.
Die berechnungen die gerne gemacht werden, würden dafür gelten wenn Audio/Video eine Bildzeit auseinander liegen...
 
Es gibt verschiedene "Größen", die ein Renderer berücksichtigen kann.

1. VSync (abhängig von der eingestellten Ausgabefrequenz und der Treiberumsetzung)
2. Audiotaktgeber
3. abgeleitete Taktgeber

Je nachdem wie der Renderer arbeitet gibt es unterschiedliche Ergebnisse.
A/V drift, verworfene oder wiederholte Frames, alles perfekt synchron usw.
Was genau passiert ist auch abhängig vom Programmierer (s. EVR Sync renderer)

Bei reclock wird der Audiotaktgeber angepasst. (drops/repeats bei der bitstreams Ausgabe => teilweise hörbar).
Das ist der Ansatz auf Audioseite.
 
Zuletzt bearbeitet:
Schon klar, nur mit dem wann wird ein bild gedroppt oder repeatet (dabei geht man als refclock vom Audioclock aus), bei wieviel AV Sync verzug.
Mich hat es eben nur mal kurz interessiert, weil halt gerne immer berechnet wann alle x,x sekunden/minuten usw. es zu einem ruckler kommen soll.
ohne zu wissen wie und wann dedropt oder repeatet wird ist diese rechnung eh usus, zumindest wenn diese berechnung der annahme entspricht, das sobald eine Bildzeit
AVSync verzug besteht gedroppt/repeatet wird und es tatsächlich aber anders ist...

Naja bei reclock ist sogesehen der Video Clock auschlaggebend, wenn hier der Audioclock nicht daraufhin nachgeführt wird/werden kann, ist es klar
das hier zu aussetzern/repeatern im Ton kommt...

Deweiteren, weil ja gerne mom INTEL 24P BUG, gesprochen wird, man kann doch nun auch offiziell 23hz auswählen, und iegt dann in der näher der nominellen 23.976fps des Medium,
bisher ist mir nur bei ATI mit HDMI und ATI Sound bekannt, das man den reelen MediaSpeed und Refreshrate passend hat.. Bei meiner NV GT240 ist dem nicht so, erst mit der
GT430 schien es syncron zu sein..(oder ich hab mist gebaut beim testen, glück gehabt bzw. nicht genau geachut) ging das bei ati schon immer seit HDMI Audio on board mit den frühen HD`s???..
So gesehen hat meine GT240 dann den NVidia 24P BUG, denn ich treffe damit auch mit A/V über HDMI (mit NV HDMI Sound ausgewählt) nicht exact ins schwarze zwischen MediaSpeed und Refreshrate...
 
Zuletzt bearbeitet:
Was da wie berechnet wird kann ich dir nicht sagen (interessiert mich auch nicht).
Ich halte es für wesentlich sinnvoller die Kurven anzusehen (VSync und wie sich der Renderer dazu verhält).

Und wenn das passt und keine Probleme mit dem Ton auftreten ist alles okay. :cool:
 
Zuletzt bearbeitet:
sehe ich auch so... ich wollte nur nochmal drauf eingehen, du hattest es ja auch schon angemerkt, das diese berechnungen hmmm zweifelhafter natur sind
und eigentlich auch recht wurscht...
 
nuts schrieb:
Schau hier mal rein: vertical sync
Zum Vergrößern anklicken....
Die Methode mit dem Anpassen des Blankings kannte ich schon. IMO nicht wirklich praxistauglich weil anscheinend keine feste API unter Windows und ich kenne das noch aus meinen Powerstrip zeiten, dass manche Geräte sehr zickig sind was die Timings angeht und entweder beim Wechsel kurz das Bild verlieren oder es mit nicht standardkonformen Timings nicht sauber halten können

nuts schrieb:
P.S. Einfach zwei Bilder vergleichen und davon abhängig machen wann ein Frame verworfen oder wiederholt wird?
Zum Vergrößern anklicken....
Jup natürlich erst wenn Bild und Ton schon etwas auseinander gedriftet sind. Und falls die Abdrift zu groß wird notfalls auch einen Ruckler hinzunehmen.
nuts schrieb:
Bewegungsanalyse ist äußerst kompliziert.
Zum Vergrößern anklicken....
Die muss man ja gar nicht komplett machen. Man muss ja nur erkennen das sich was ändert. Da reicht es die Bilder von einander zu subtrahieren.
 
FaxenDicke schrieb:
Schon klar, nur mit dem wann wird ein bild gedroppt oder repeatet (dabei geht man als refclock vom Audioclock aus), bei wieviel AV Sync verzug.
Mich hat es eben nur mal kurz interessiert, weil halt gerne immer berechnet wann alle x,x sekunden/minuten usw. es zu einem ruckler kommen soll.
Zum Vergrößern anklicken....
Bei den Berechnungen werden eben statisch ausgerechnet wann bei der angezeigten Statistik (Quellen, Ausgabe und was dort alles angezeigt wird) Ruckler auftreten.
Dabei wird immer folgende Annahme getroffen:
Renderer zeichnet seine Bilder mit 23,976 fps (=Quelle)
VSync= ein in MPC-HC angezeigter Wert (23,97X bei den meisten GPU'S)

Nun wird gerechnet. (23,976 fps vs 23,973 fps => überlauf nach X,X min)

Was die Statistiken überhaupt bedeuten müsste auf der von mir vorhin verlinkten Seite nachzulesen sein.
Das die ausgewerteten Zahlen sowieso einer gewissen Abweichung (zu den Quarzen hast du ja schon was gesagt) unterliegen (dritte Nachkommastelle) ist eigentlich auch logisch.

Diese Berechnungen zeigen also nicht das Gesamtbild.
 
Zuletzt bearbeitet:
nuts schrieb:
Bei den Berechnungen werden eben statisch ausgerechnet wann bei der angezeigten Statistik (Quellen, Ausgabe und was dort alles angezeigt wird) Ruckler auftreten.
Dabei wird immer folgende Annahme getroffen:
Renderer zeichnet seine Bilder mit 23,976 fps (=Quelle)
VSync= ein in MPC-HC angezeigter Wert (23,97X bei den meisten GPU'S)

Nun wird gerechnet. (23,976 fps vs 23,973 fps => überlauf nach X,X min)
Zum Vergrößern anklicken....
Jo und neben der problematik des reelen MediaSpeed und abweichung zur reelen Refreshrate, stellt sich
hier nun die frage wie rechnet man weiter. Die berechnungen hier, die z.b anhand der nominellen werte -> 24hz - 23,976fps = delta 0,024 -> 1/0.024 -> 41,7 sec., geht dann davon aus
das immer bei einer Bildzeit(1/framrate) A/V Sync unterschied der renderer mit droppen repeaten eines bildes den AV Sync wieder im rahmen hält..
Ohne zu wissen ob der renderer hier dies genau so macht, (ebenso könnter er doch droppen/repeaten wenn AV Sync abweichungen >+(<-)100ms sind oder was und wann auch immer) passt die rechnung schon "nominell" auch überhaupt nicht, da helfen dann auch die reelen clocks nicht um dies so zu erechnen.
Das war eigentlich worauf ich hinaus wollte...
Aber mal by the Way, auch Settop Boxen, bzw. besser alg. Consumer Audio/Video equipment abseits der ganzen HTPC welt welche eben nicht optimal für AV ist/war, beckleckern sich aber auch nicht immer mit ruhm in solchen sachen. Was in der theorie gehen sollte und ja einfach klingt, der jeweilige empfänger synct sich auf den clock des sender
machts dann praktisch doch auch nicht immer so recht, und noch einige mehr schweinerreien, ist dann im detail halt nicht ganz so unkomplex...
 
Zuletzt bearbeitet:
Hier noch ein interessanter Link zum Thema:
DirectShow und Synchronisation

Das auch andere A/V Elektronik Probleme mit dem Thema hat ist mir auch bekannt.
Ein sehr komplexes Thema.
Eigentlich müsste sich jeder Taktgeber auf die Zeitstempel des Encoders synchronisieren.
 
Zuletzt bearbeitet:
nuts schrieb:
Hier noch ein interessanter Link zum Thema:
DirectShow und Synchronisation

Das auch andere A/V Elektronik Probleme mit dem Thema hat ist mir auch bekannt.
Ein sehr komplexes Thema.
Eigentlich müsste sich jeder Taktgeber auf die Zeitstempel des Encoders synchronisieren.
Zum Vergrößern anklicken....
Das wird auch gemacht....
Zb. Beim encodieren und anschliesenden zusammenpacken in einen TS Streams gibt es einen PCR (Programm clock Referenz, eine Zeitmarke für jedes TS Paket vom encoder, bzw letzten bearbeitenden glied beim sender) für die jeweiligen zusammengehöhrigen TS Pakete in einem multiplex. Annhand des PCR sollte sich der Empfänger darauf syncronisieren, in der regel über eine PLL, sprich der Clock im empfänger wird feingetuned so das er zum Clock des sender syncron läuft. das geht in der regel auch nur in bestimmten rahmen sonst rastet die PLL aus und der sync ist nicht mehr gegeben was dann zu buffer oferflows/underruns führt und sonstigen mätzchen...
 
Zuletzt bearbeitet:
aus der 'ct vom kommenden Montag:

neu im Vergleich zu Sandy Bridge ist die Fähigkeit 24p Filme mit 23,976 Bildern wiedergeben zu können.
 
Wenn man jetzt einen HTPC hat, mit H67 Board und Pentium G620t (core i5-2500K) und dann den Media Player Classic / VLC nutzt, gibt es irgendwelche Probleme mit
DVDs / Blurays, VIDEO_TS oder m2ts Dateien, wenn man sie abspielt?

Das Ruckeln von Sandy Bridge kann man doch damit umgehen, das man die Hardwarebeschleunigung ausschaltet? Warum tut ihr euch das Ruckeln an?

Und wenn der PC am TV angeschlossen ist, und das ein guter TV ist, dann kann auch der TV das Scaling/Deinterlacing übernehmen.

Daher ist das doch kein Problem?!
 
Zuletzt bearbeitet:
neu im Vergleich zu Sandy Bridge ist die Fähigkeit 24p Filme mit 23,976 Bildern wiedergeben zu können.
Zum Vergrößern anklicken....
Wenn jemand die c't hat, kann er die Ergebnisse ja mal kurz posten, würde mich interessieren, welche Hardware und Software verwendet wurde.


Das Ruckeln von Sandy Bridge kann man doch damit umgehen, das man die Hardwarebeschleunigung ausschaltet? Warum tut ihr euch das Ruckeln an?
Zum Vergrößern anklicken....
Kann man? Das wäre mir neu... Und falls doch: Wegen dem Stromverbrauch, der Abwärme und, weil er es einfach können muss, wenn man ihn so verkauft :-)
 
Alt_F4 schrieb:
Wenn man jetzt einen HTPC hat, mit H67 Board und Pentium G620t (core i5-2500K) und dann den Media Player Classic / VLC nutzt, gibt es irgendwelche Probleme mit
DVDs / Blurays, VIDEO_TS oder m2ts Dateien, wenn man sie abspielt?

Das Ruckeln von Sandy Bridge kann man doch damit umgehen, das man die Hardwarebeschleunigung ausschaltet? Warum tut ihr euch das Ruckeln an?

Und wenn der PC am TV angeschlossen ist, und das ein guter TV ist, dann kann auch der TV das Scaling/Deinterlacing übernehmen.

Daher ist das doch kein Problem?!
Zum Vergrößern anklicken....

1.Für BluRay braucht man einen "decoder" á la PowerDVD oder TMT.
2. Nein, das (24p) Ruckeln kann man mit Hardwarebeschleunigung ausschalten nicht umgehen.
3. De-interlacing von 1080i von externer Quelle ist mir von keinem Fernseher bekannt. (aber ich weiß definitiv nicht alles!)
 
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