LAV Untertitel + LAV Async

[dacula]

Hallo zusammen,

 

nachdem mein HTPc immerwieder Microruckler und andere Kinderkrankheiten hatte, habe ich es mit LAV tatsächlich geschafft alles 100% ruckelfrei zu bekommen. LAV ist wirklich ein super Projekt und ich kann garnicht beschreiben wie glücklich ich bin.

 

Nun habe ich jedoch noch 2 Punkte wo ich nicht direkt weiterkomme.

1) Wie kann ich aus MKVs wenn ich lediglich LAV Splitter/Audio/Video installiert habe, untertitel selektieren. Geht das zur Zeit?

2) Wenn ich zwischen Filmen und Fernseh wechsel oder Film und Film kann es passieren das Video und Audio Async sind. Die einzige Möglichkeit diese wieder korrekt zu bekommen ist ein Neustart von DVBViewer.

 

Benutzt wird

- aktuellste DVBViewer Version

- Radeon HD 5650 mit Catalyst 12.1

- LAV 0.50.5

- EVR Custom Renderer

 

Da ich gerade auf der Arbeit bin kann ich keine Support.Zip anfügen. Würde ich aber noch ggbfs. nachreichen.

 

Vielen Dank vorab für die Hilfe.

 

Gruß dacula

[SnoopyDog]

Für TV verwende ich LAV-Video-Decoder (egal ob ATI oder nVidia) und den AC3Decoder 1.63. Diese Kombination ist bei mir immer 100% lippensynchron (hab allerdings das Audiodelay im AC-Filter angepaßt).

 

Für mkv verwende ich LAV-Splitter, LAV-Audio (auto AV Sync ein) und ffdshow DXVA. Wenn Du Untertitel sehen möchtest, geht das derzeit nur mit ffdshow. Besser wäre eine Art extra Input Pin beim Video-Renderer, aber mit ffdshow geht es ganz passabel. Diese Kombination läuft bei mir auch synchron (ebenfalls Audiodelay im LAV-Audiodecoder angepaßt), außer man spult und/oder springt während des Films. Synchron bekomme ich es dann immer, wenn ich den DVBViewer von Vollbild auf Fenster und zurück schalte.

[CiNcH]

Für TV verwende ich LAV-Video-Decoder (egal ob ATI oder nVidia) und den AC3Decoder 1.63. Diese Kombination ist bei mir immer 100% lippensynchron (hab allerdings das Audiodelay im AC-Filter angepaßt).

Ist der Versatz bei dir konstant? Ich habe das Gefühl, der variiert.

 

 

Mikroruckeln resultiert übrigens oft aus (re-)synchronisation. Hat man kein Ruckeln, laufen Audio und Video oft auseinander .

[dbraner]

Ich verwende den LAV Audio und Video Codec für TV (seit dem Codec-Gate von ARD/ZDF HD). Version 0.52

 

Der AV-Versatz variiert je nach Sender bei mir. Bei ARD habe ich immer einen minimalen Versatz während z.B. PRO7 perfekt synchron ist (zumindest kann ich hier keinen Versatz feststellen).

 

Manchmal ist der Versatz weg, wenn ich auf einen anderen Sender und wieder zurück schalte.

 

Früher hatte ich die Kombi AC3Filter/PowerDVD-Codecs. Das war zwar besser, aber auch nicht immer 100% synchron.

[mague]

Ich hab (heftigen) Versatz bei Custom EVR. Bei normalem EVR ist alles gut mit LAV/AC3 Filter

[nuts]

Was heisst heftiger Versatz? Konstant oder läuft A/V langsam auseinander?

Mit einem konstanten Versatz kann man ja gut umgehen.

 

Problematischer sind Resync-Ruckler bzw. ein A/V-Drift.

Edited June 5, 2012 by nuts

[CiNcH]

Ich hab (heftigen) Versatz bei Custom EVR. Bei normalem EVR ist alles gut mit LAV/AC3 Filter

Interessant. Das muss ich mir auch mal anschauen. Der Custom EVR macht auch nichts anders, als anhand der Frame-Timestamps zu rendern...

[Benno66]

Egal welche Version oder Kombi, bei mir ist es über kurz oder lang auch async.

Hatte noch nicht die Möglichkeit den normalen EVR zu probieren.

@Cinch

bist du da schon weiter?

 

Gruß Benno

[CiNcH]

Es sieht schon so aus, dass die hier gemacht Beobachtungen korrekt sind. Renderer und auch die Quelle (Kanal) scheinen eine Rolle zu spielen, wie ausgeprägt das Problem ist. Ich muss das noch über einen längeren Zeitraum beobachten.

[rmo]

Ich habe außerdem festgestellt, dass Jitter beim EVR-Renderer bei 0 ist und die mittlere Bildfrequenz sehr stabil ist. Beim Customer EVR habe ich ein Jitter von 1 oder 2 und die Bildfrequenz schwankt um 50 Hz. Zur Synchronität kann ich noch nichts sagen. Teilweise ist auch mit Customer Render und LAV der Ton über lange Zeit synchron. Ich glaube die Probleme gibt es immer dann, wenn Audio im DVBSource vorauseilt. Bei Arcsoft ruckelt es dann! Bei LAV wird es asynchron.

[Diwo]

Die geschmähte LAV-Version 0.50.5 läuft bei mir ebenfalls sauber ohne Tonversatz (getestet mit ZDF HD und ARD HD).

 

- Windows XP

- SkyStar USB HD

- DVBViewer V4.9.6.20

- Radeon HD 6570 mit Catalyst 1211

- EVR Enhanced Video Renderer

- Audio LAV Audio Decoder

- LAV: DXVA2 (copy-back)

 

Aber erst, nach dem ich den NDIS-Treiber durch den BDA-Treiber ersetzt habe.

Mit NDIS-Treiber war Bild und Ton bei gleicher Einstellung nach wenigen Minuten absolut asynchron (Ton hinkt hinterher).

[CiNcH]

Die geschmähte LAV-Version 0.50.5 läuft bei mir ebenfalls sauber ohne Tonversatz (getestet mit ZDF HD und ARD HD).

Die Deutschen ÖR's laufen hier ebenfalls synchron mit LAV. Wie gesagt hängt das auch stark vom Kanal ab.

[Diwo]

Wie gesagt hängt das auch stark vom Kanal ab.

Ich bin natürlich weit davon entfernt, alle Kanäle ausprobiert zu haben

 

Zumindest hat mich noch ServusTV HD interessiert - und dort blieb mit der obigen Einstellung der Ton auch über mehrere Stunden synchron.

[SnoopyDog]

Ist der Versatz bei dir konstant? Ich habe das Gefühl, der variiert.

Ist bei mir (langzeit) konstant! Wenn ich zwischen ARD HD, ZDF HD, RTL etc umschalte, ist und bleibt es lippensynchron.

[Diwo]

Zumindest mit dem LAV 0.50.05 stören die Einstellungen "Check Timestamp Continuity" und "Use DVB Clock" im DVB Source eher, als sie helfen. Ich habe momentan beim EM Eröffnungsspiel keinen fortschreitenden Ton- Bildversatz mehr.

Edited June 8, 2012 by Diwo

[Diwo]

(So - ich bin bei meinem SkyStar USB HD wieder zurück zum WDM-/NDIS-Treiber zurückgekehrt, der BDA-Treiber arbeitet nicht zuverlässig genug.)

 

Bei mir ist bei HD das Problem, dass der Ton mehr oder wenig hinterher hinkt.

 

Wenn ich mich entspannt zurück lehne und darüber nachdenke, passt hier logisch einiges nicht zusammen:

 

HD-Video ist rechenaufwendig. Wenn es hier zu fortschreitenden Verzögerungen kommen sollte, wäre dies zumindest logisch erklärbar. Jedoch sollte jede CPU Audio locker und entspannt abarbeiten können. Also kein Grund für irgendwelche Verzögerungen.

 

Und wenn Video und Audio doch mal auseinander laufen, warum wird denn Video auf Audio synchronisiert? So eine Synchronisation kann doch nicht ohne unschöne Bildstörungen erfolgen.

 

Warum wird nicht Audio auf Video synchronisiert? Sollte doch die einfachere Übung sein.

 

Oder kann man dieses Synchronisationsverhalten irgendwo beeinflussen (wenn ja wie)?

 

Viele Grüße

Dieter

[scotch]

(So - ich bin bei meinem SkyStar USB HD wieder zurück zum WDM-/NDIS-Treiber zurückgekehrt, der BDA-Treiber arbeitet nicht zuverlässig genug.)

 

Bei mir ist bei HD das Problem, dass der Ton mehr oder wenig hinterher hinkt.

 

Wenn ich mich entspannt zurück lehne und darüber nachdenke, passt hier logisch einiges nicht zusammen:

 

HD-Video ist rechenaufwendig. Wenn es hier zu fortschreitenden Verzögerungen kommen sollte, wäre dies zumindest logisch erklärbar. Jedoch sollte jede CPU Audio locker und entspannt abarbeiten können. Also kein Grund für irgendwelche Verzögerungen.

 

Und wenn Video und Audio doch mal auseinander laufen, warum wird denn Video auf Audio synchronisiert? So eine Synchronisation kann doch nicht ohne unschöne Bildstörungen erfolgen.

 

Warum wird nicht Audio auf Video synchronisiert? Sollte doch die einfachere Übung sein.

 

Oder kann man dieses Synchronisationsverhalten irgendwo beeinflussen (wenn ja wie)?

 

Viele Grüße

Dieter

 

 

Falls das gestern beim ZDF aufgetreten ist, das lag am Sender! ;-)

[Diwo]

Nein - die gestrige ZDF-Panne ist nicht der Anlass

 

Außerdem nahm der Bild-/Tonversatz nicht zu.

 

Abgesehen davon habe ich bei meinem Topfield auch zuweilen einen Versatz. Entweder wird dieser automatisch abgebaut, oder ein Kanalwechsel bereinigt die Situation. Der Versatz ist aber in keinem Fall fortschreitend.

[SnoopyDog]

Wie genau gibst Du denn Audio aus? Wenn ich das über mein TV per HDMI tun würde, hätte ich hier auch eine extrem unschöne Verzögerung bei Audio durch die Hardware meines Fernsehers.

 

Weshalb Du beim Wechsel von BDA nach NDIS derartige Probleme bekommst, kann ich allerdings nicht beantworten.

Edited June 11, 2012 by SnoopyDog

[Diwo]

Audio geht einfach über das Audiodevice des Motherboards an ein Lautsprechersystem.

Bei Ausgabe über TV kann ich mir vorstellen, dass Audio gezielt verzögert wird.

Aber auch in diesem Fall würde die Verzögerung konstant bleiben, und nicht zunehmen.

 

Wenn ich DVBSource und Decoder so einstelle, dass keine Bildstörungen zu sehen sind, hinkt der Ton nach ca. 20 Minuten soweit hinterher, dass in einer Diskussionsrunde immer die Falsche Person antwortet

Deshalb meine grundsätzliche Fragestellung oben.

 

(Habe gerade per Suche noch einige Hinweise auf den Direct3D Exclusivmodus gefunden - muss ich heute abend mal ausprobieren).

[getilus]

(So - ich bin bei meinem SkyStar USB HD wieder zurück zum WDM-/NDIS-Treiber zurückgekehrt, der BDA-Treiber arbeitet nicht zuverlässig genug.)

 

Bei mir ist bei HD das Problem, dass der Ton mehr oder wenig hinterher hinkt.

 

Wenn ich mich entspannt zurück lehne und darüber nachdenke, passt hier logisch einiges nicht zusammen:

 

HD-Video ist rechenaufwendig. Wenn es hier zu fortschreitenden Verzögerungen kommen sollte, wäre dies zumindest logisch erklärbar. Jedoch sollte jede CPU Audio locker und entspannt abarbeiten können. Also kein Grund für irgendwelche Verzögerungen.

 

Und wenn Video und Audio doch mal auseinander laufen, warum wird denn Video auf Audio synchronisiert? So eine Synchronisation kann doch nicht ohne unschöne Bildstörungen erfolgen.

 

Warum wird nicht Audio auf Video synchronisiert? Sollte doch die einfachere Übung sein.

 

Oder kann man dieses Synchronisationsverhalten irgendwo beeinflussen (wenn ja wie)?

 

Viele Grüße

Dieter

 

 

Das Problem mit der Video/Audio Syncronisation kann im DVBV-Wiki nachgelesen werden: Hier

 

Das erklärt vieles....

 

 

Gruß

[CiNcH]

Ich habe mir das nun über einen längeren Zeitraum angesehen. Massive Probleme habe ich scheinbar nur auf 'Sport 1 HD'. Auch der Standard EVR liegt hier ein wenig daneben. Wahrscheinlich schaukeln sich da die Ungenauigkeiten von Filter zu Filter immer weiter hoch. Ich muss mir das auf Renderer-Seite nochmal genau ansehen. Nach einer längeren Auszeit werde ich mich nun wieder verstärkt mit dem EVR Custom beschäftigen. Auch auf einem Receiver (Venton UNiBOX HD1) werde ich mir mal ansehen, wie es mit der Synchronität auf 'Sport 1 HD' aussieht.

[Diwo]

Das Problem mit der Video/Audio Syncronisation kann im DVBV-Wiki nachgelesen werden: Hier

 

Das erklärt vieles....

Stimmt - ist sehr informativ.

 

Hier ist auch die Rede davon, dass bei Laufzeitdifferenzen der Ton beeinflusst wird, und nicht das Video. Die von mir und anderen beobachteten Bildruckler und Microruckler zum Synchronisieren, können hiermit nicht erklärt werden; wie ein Ton dem Video in zunehmenden Maß hinterher hinken kann, kann auch nicht erkannt werden.

 

Im Wiki kann man nur zwei Gründe für Bildstörungen ausmachen - Bufferunderrun und Bufferoverflow. Beide können im vorliegenden Fall ausgeschlossen werden.

 

Mit dem LVA 0.48 wurde mir unter DXVA2 noch "not available" angezeigt (Windows XP; Radeon HD6570). Mit der 50.5 wurde mir ertsmalig "available" angezeigt.

 

Ein Blick in die CPU-Auslastung (ca. 50%) zeigt mir, dass die Hardwarebeschleunigung der GPU scheinbar doch nicht verwendet wird (damit eine seht unglückliche und missverständliche Wortwahl).

 

Nachdem ich diese Auswahl wieder entfernt habe, habe ich keinen zunehmenden Versatz mehr, und die Bildstörungen sind dezimiert. Irgedenwie war die DXVA-Wahl suboptimal

 

Irgendwie verhält sich hier einiges jedoch gegen die allgemein gültige Theorie

[Diwo]

Irgendwie verhält sich hier einiges jedoch gegen die allgemein gültige Theorie

Vielleicht ja doch nicht ...

 

Nachdem ich im LAV die DXVA-Unterstützung wieder abgewählt habe, habe ich auch keinen asynchronen Ton mehr, und habe auch nur noch vereinzelt Bildstörungen.

 

Ich habe mich nun vor der Statusanzeige des DVB Source bei laufender ARD HD-Wiedergabe auf die Lauer gelegt. Erhöht sich der Discontinuities-Zähler um 1, so ist kurz danach eine Bildstörung wahrnehmbar (die Verzögerung kommt offenbar vom Bufferdurchlauf). Manchmal erhöht sich die Zahl auch um 2, max. 3. In 1,5 Stunden bin ich auf ca. 450 Discontinuities gekommen.

 

Mhm - es ist sehr wahrscheinlich eine Baustelle, die Discontinuities auf 0 zu bekommen.

 

Aber / trotzdem:

 

Auf ARD SD habe ich auch diese Discontinuities, der ffdshow Decoder steckt diese Discontinuities jedoch ganz locker weg. Sollte dies der LAV nicht auch tun?

Zumindest bei mir kann der PowerDVD-Decoder V12 die nicht besser (eher schlechter).

 

OK - der Stream, der am DVB Source ankommt hat einzelne Lücken.

An meiner anfänglichen Beobachtung, dass der BDA-Treiber meiner SkyStar USB HD besser läuft, könnte also doch etwas dran sein. Vielleicht liefert er einen kontinuierlicheren Stream?

(Bei angezeigter Signalstärke von 93-94% habe ich den LNB, bzw. die Ausrichtung der Schüssel nicht in Verdacht).

 

Habt ihr keine Discontinuities, und trotzdem Bildstörungen?

support.zip

[CiNcH]

Erkennt der DVBSource eine Discontinuität im Video-TS-Datenstrom, signalisiert er das über einen entsprechenden DirectShow-Mechanismus dem Video-Dekoder. Ob und wie dieser darauf reagiert, kann nicht pauschal gesagt werden. Der CyberLink verwirft m.E. die komplette GOP, sprich alles bis zum nächsten I-Frame. Mit LAV wirkt sich so eine Discontinuität nicht so gravierend aus.

[Diwo]

Der CyberLink verwirft m.E. die komplette GOP, sprich alles bis zum nächsten I-Frame. Mit LAV wirkt sich so eine Discontinuität nicht so gravierend aus.

Mhm - sieht so aus. Ich habe es mir gerade noch einmal angesehen.

Beim Cyberlink friert bei Discontinuities das Bild kurz ein und setzt mit einem Ruck wieder neu auf.

Beim LAV läuft das Bild meist weiter, hat aber leichte Störungen (Verpixelung oder verwischte Bereiche).

 

Ich habe den NDIS-Treiber nochmal entfernt und den BDA-Treiber installiert. Ergebnis 6 Discontinuities auf 90 Minuten.

Mit dem NDIS-Treiber waren Und sind es) es in der gleichen Zeitspanne ca. 450

 

Welche Treiber laufen bei euch?

[Diwo]

In der DVB Source Anleitung steht:

Discontinuities (nur TV/Radio und TS-Dateien): Zählt die Anzahl der Lücken im Transportstream seit dem letzten Stop-Run-Übergang durch Überwachung des Continuity Counters im TS-Header. Eine ständig anwachsende Anzahl Diskontinuitäten ist ein Zeichen für Empfangs- / Hardware- / Treiberprobleme und führt zu Wiedergabestörungen.

Aufgrund der Beschreibung der Fehlerursache, werden die Discontinuities am Eingang der Splitters gemessen.

 

Beobachtungen (wie meine obige) bestätigen die Aussage. Wird der Zähler inkrmenetiert, kann man nach der Bufferverzögerung eine mehr oder weniger starke Bildstörung beobachten.

 

Nach dem ich solche Störungen (in der Standardeinstellung des DVB Source) sehe, habe ich natürlich in Richtung "Empfangs / Hardware / Treiber" gesucht - erfolglos....

 

Aber ... dekativiert man "Check Timestamp Continuity" und "Use DVB Clock" werden zwar die Discontinuities inkrementiert (auch kommt es zu einem Bild-/Tonversatz), aber beim erhöhen der Discontinuities kommt es zu keinen Bildstörungen.

Wären es wirkliche Lücken im TS-Stream, müssten sich diese jedoch als Bildstörungen zeigen.

 

An welcher Stelle in der Filterkette werden die Discontinuities wirklich gezählt?

[CiNcH]

An welcher Stelle in der Filterkette werden die Discontinuities wirklich gezählt?

Im DVBSource anhand des TS-Continuity-Counters. Eine Lücke bzw. eine Diskontinuität von 1 kann in einem Stream beliebig viele Pakete aufspannen.

 

Aber ... dekativiert man "Check Timestamp Continuity" und "Use DVB Clock" werden zwar die Discontinuities inkrementiert (auch kommt es zu einem Bild-/Tonversatz), aber beim erhöhen der Discontinuities kommt es zu keinen Bildstörungen.

Aus dem DVBSource Manual:

Check Timestamp Continuity (nur TV/Radio). Diese Option sorgt dafür, dass der DVBViewer Filter bei Zeitstempel-Diskontinuitäten von mehr als 5 Sekunden (die üblicherweise die Wiedergabe lahmlegen) eine Fehlermeldung an den DVBViewer sendet, der als Reaktion die Wiedergabe stoppt und sofort wieder startet, um das Filtergraph-Timing zurückzusetzen.

Wenn da wirklich solche Löcher drin wären, würde man das schon durch Bildstöhrungen mitbekommen. Ich habe keine Ahnung, wie deine Beobachtungen zu erklären sind. Evtl. triggern Mülldaten diesen Mechanismus ab und zu. Griga könnte da wohl mehr zu sagen.

 

Schau dir bei aktivierter 'DVB Clock' mal den Clock Drift an. Spielt diese Zahl irgendwie verrückt, wenn es zu Stöhrungen kommt?

 

Gesund sind diese Streamfehler sicher nicht.

[Griga]

Aber ... dekativiert man "Check Timestamp Continuity" und "Use DVB Clock" werden zwar die Discontinuities inkrementiert (auch kommt es zu einem Bild-/Tonversatz), aber beim erhöhen der Discontinuities kommt es zu keinen Bildstörungen.

Die Beobachtung ist nicht unbedingt stichhaltig, da bei Live-Streams keine Reproduzierbarkeit gegeben ist:

 

- Diskontinuitäten können auch Audio oder irrelevante Daten treffen, obwohl die Wahrscheinlichkeit, dass es Video trifft, aufgrund des Anteils an der Gesamt-Datenmenge am höchsten ist.

 

- Ob und wie sich Diskontinuitäten auf Video auswirken, kann variieren. "Bildstörung" ist eine subjektive Beobachtung.

 

Bei Wiedergabe ein und der selben Datei ist Reproduzierbarkeit gegeben, aber die genannten Optionen haben in dem Fall keine Wirkung.

[Diwo]

Die Beobachtung ist nicht unbedingt stichhaltig, da bei Live-Streams keine Reproduzierbarkeit gegeben ist:

Der Zeitpunkt und die Anzahl der hochgezählten Kontinuitätsfehler ist natürlich nicht reproduzierbar. Die Auswirkung (wenn beide Optionen aktiviert sind) ist jedoch reproduzierbar beobachtbar. Kurze Zeit nach dem der Zähler erhöht wird, ist eine Bildstörung beobachtbar. Entweder Klötzchenbildung, oder Zeilenwiederholungen (beim LAV).

Ich habe dies über längere Zeit und mehrmalig beobachtet.

 

Wie bereits beschrieben geht das Bild bei Deaktivierung beider Optionen ohne (oben beschriebene Störung) durch, auch wenn der Zähler hochgezählt wird (auch mehrmalig betrachtet).

 

An welcher Stelle der Kette wird der Zähler erhöht?

[Ergänzung]

Ich füge noch Screenshots vom DVB Source Status und des Filtergraphen nach 67 Minuten ARD HD Betrieb hinzu.

Edited June 14, 2012 by Diwo

[Diwo]

Nachdem ich mir den Transedit vorgenommen habe, bin ich etwas schlauer

 

Da dieser vollkommen ohne Filter und Decoder auskommt, und dort missing packets zu sehen sind, ist die Ursache für die Bildstörungen am Stream zu suchen.

 

Die Anzahl der missing packets (Transponder 11362/ZDF HD / H.264 Video) hängt stark von der data rate (also vom der momentan gesendeten Sendung ab); dies habe ich bei meiner visuellen Beobachtung außer acht gelassen.

 

Außerdem - mit dem BDA-Treiber habe ich nahezu die gleiche Anzahl missing packets wie mit dem NDIS-Treiber.

(bei H.264 Video ca. 70 missing packets bei 4000 Pats bei einer data rate von ca. 12 Mbps)

 

Rätselhaft bleibt es trotzdem:

+ Die CPU ist mit laufendem Tranedit nur mit 4-8% ausgelastet.

+ Der Latency Checker zeigt auch grün an

+ Transedit zeigt eine Quality von 94% an

+ Mein Topfield zeigt Signal=77% und Quality=99%

 

Die Schüssel am Dach brauche ich wohl nicht neu ausrichten - F-Stecker sind geprüft (bei mechanischer Belastung sind keine zusätzlichen missing packets erkennbar).

Eventuelle Störquellen entlang des Kabels (ca. 10m) wurden auch schon alle abgeschaltet.

 

Ich bin ratlos - irgendwie wird die Datarate nicht korrekt durchgereicht.

support.zip

[getilus]

Hallo,

 

dann kommt wohl nur noch ein Hardware-Defekt deines HTPC in Frage.

 

In der Hauptsache würde ich mal die TV-Karte und das Mainboard in Betracht ziehen. Aber auch alle anderen Hardware-Komponenten könnten die Ursache sein.

 

 

Gruß

[Diwo]

In der Hauptsache würde ich mal die TV-Karte und das Mainboard in Betracht ziehen. Aber auch alle anderen Hardware-Komponenten könnten die Ursache sein.

 

Mhm - jetzt wird es schwierig.

 

Die Ausrichtung der Schüssel perfekt (habe ich mit meinem Topfield im entsprechenden Forum abgesichert).

 

Also ist die Fehlerursache auf der Strecke SkyStar USB HD -> PC -> NDIS-Treiber oder störenden/verzögernden Programmen zu suchen.

 

Ich habe schon alle möglichen Programme inkl. VirenScanner lahmgelegt. Es sammeln sich immer wieder missing packets an (ich nehme an, dass die für lange Zeit 0, bzw. gleich bleiben sollten).

 

Ich habe den DVBViewer und Transedit heute auf meinem schwachbrüstigen Atom-Netbook laufen lassen. Auch hier habe ich auf den gleichen Zeitraum in der Tendenz die gleiche Anzahl missing packets (ich betrachte immer den höchsten Wert der H.264 Video missing packets).

 

Eigentlich habe ich erwartet, dass das Netbook deutlich schlechter abschneidet.

 

Ich habe in meinem PC einen Intel Core2 E5400 Prozessor mit 2,7Mhz laufen. Ich gehe davon aus, dass zumindest im Leerlauf alle packets ankommen sollten. Oder befinde ich mich hierzu auf dem Holzweg?

[craig_s]

Ich hab früher selbst auf P4 3,0 GHz (Single Core) über FireDTV S2 nie son Audio-Versatz gehabt. Discontinuities - null.

 

Andere haben später sogar mit P4 1 GHz und niedriger sauberes HD hinbekommen (siehe Signatur). Intel Core2 E5400 dürfte also nicht das Prob sein.

[Diwo]

Andere haben später sogar mit P4 1 GHz und niedriger sauberes HD hinbekommen (siehe Signatur). Intel Core2 E5400 dürfte also nicht das Prob sein.

Ich befürchte doch ....

 

Ich habe jetzt alle Ausgänge meines Quad-LNBs durch, keine Änderung / Verbesserung.

Damit sind Schüssel, LNB und Satkabel außer Verdacht.

Heute habe den neuen Büro-PC meiner Frau ausgeliehen (AMD 3x3,4 GHz) -> in 20 Minuten kein missing packet im TransEdit.

 

Bios und Treiber sind bei meinem PC auf aktuellem Stand ...

Die CPU läuft mit 4-8% nahezu im Leerlauf; alle evtl. störenden Programme wurden beendet.

 

TechniSat nennt für den SkyStar USB HD einen Dual-Core mit 3GHz als HDTV-Voraussetzung.

Möglicherweise bedarf es wirklich 3GHz, um den Stream ohne Lücken vom USB-Port abzuholen.

 

[Ergänzung]

Alles wird gut

Bevor ich neue Hardware kaufe, und Windows neu aufsetze, habe ich mir auf einer weiteren Platte Windows 7 Home Premium 64 Bit Trial installiert. Nach der Windows-Updateschlacht zeigt TransEdit keinerlei missing packets mehr.

 

Ob das Neuaufsetzen von XP genau so geholfen hätte, weiß ich nicht.

Edited June 22, 2012 by Diwo