Jump to content

Tonversatz / doch kein altes Problem


alex.ba

Recommended Posts

Ok nur zur Klarstellung für experimentierfreudige ,weil das muss in Reclock nicht zwingend so sein.

Edited by nuts
Link to post
  • Replies 155
  • Created
  • Last Reply

Top Posters In This Topic

  • CiNcH

    38

  • nuts

    37

  • alex.ba

    15

  • Derrick

    14

Top Posters In This Topic

Popular Posts

Es scheint wichtiger zu sein sinnfreie Apps zu entwickeln als sich um wirkliche Probleme zu kümmern die hier im Forum schon fast bei jedem user aufgetreten sind, ich kann das auch nicht nachvollziehen

Möchte auch mal meine 2-Cent-Meinung zum Besten geben:   Jeder der hier geantwortet hat, schreibt zwar brav hin, welche Codecs er nutzt und ob es einen Tonversatz gibt...das entscheidendere ist jedo

Hmm wenn der Custom EVR bei Video nicht mehr hinterherkommt, Audio aber per bitstream ausgegeben wird, läuft doch Audio normal weiter und die Videodaten stauen sich... irgendwie... irgendwo... (Man si

Posted Images

Kriegst du mit reclock eine synchrone Woedehabe hin cinch?

Ich muss dafür denn PTS Wert im DVBVSourcefilter anpassen (bei mir auf ca. 1000 ms), sonst ist das gleich vom Start ab völlig asynchron.

 

Wie kommt das? Mit dem Default Renderer ist das nicht nötig.

Edited by nuts
Link to post

Ich habe es direkt im DVBViewer mit einer Live-Quelle probiert. Sync-Probleme hatte ich dabei nicht. Quelle war Stereo. Mittels LAV Audio Dekoder und integriertem Mixer habe ich einen 5.1 Upmix gemacht. ReClock hat das dann neu zu DD 5.1 kodiert. Und das war dann auch tatsächlich das, was beim externen Verstärker ankam. Die Kette hat also nachweislich das gemacht, wofür sie vorgesehen war.

 

 

Ich muss dafür denn PTS Wert im DVBVSourcefilter anpassen (bei mir auf ca. 1000 ms), sonst ist das gleich vom Start ab völlig asynchron.

 

Du meinst den Latency Wert? D.h. du musst die Puffer füllen. Da gehen ReClock wohl die Daten aus?

Link to post

Ich habs grad nochmal auf TNT Serie HD (Sky) mit der originalen englischen Tonspur probiert. Perfekt lippensynchron.

 

PTS Latenz im DVBSource ist bei mir für H.264 sogar auf 300ms herabgesetzt, siehe meine DVBSource.ini:

 

[Params]
udMaxTVRadioMS=500
udMaxFileMS=500
udLatency=200
udH264Latency=300
CheckTimeStamps=1
UseDVBClock=0
PCRDelta=10
H264Aspect=0
MPEG2InDepth=0

Link to post

Ja die PTS Latenz meine ich, bei 300ms ist das sofort Asynchron mit reclock (Ton kommt zu spät).

Bei 1000ms ist es genau synchron ( zwischenwerte jetzt nicht ausprobiert ...)

 

Habe das jetzt mal mit ZDF HD 2,5h laufen lassen (AC3 Filter, Reclock Encoder, DD Lampe im AVR leuchtet) und es ist immernoch perfekt synchron.

Wäre jetzt mal interessant ob das bei den Benutzern mit Problemen auch hilft.

 

 

P.S. Wie du siehst kein A/V Drift durch einen anderen Taktgeber im externen Verstärker. Denke an der Stelle ist die Ursache nicht zu suchen, auch wenn wir nicht alle Details kennen. Mit dem HDMI Zeugs haben wir auf Anwendungsebene eh nichts zu tun.

Edited by nuts
Link to post

Hast du mal den LAV Audio Dekoder probiert?

 

[EDIT]

Hier auch keine Probleme auf ZDF HD (sowohl MP2 als auch AC3 Tonspur als Quelle).

Link to post

LAV kommt dann morgen.

Für den A/V Sync Test sollte man immer bissle laufen lassen, daher war nur ein Decoder möglich heute (AC3 Filter ist immernoch mein Fav. für Ac3).

Link to post

Ich verwende hier übrigens den S/P-DIF vom Mainboard. Mainboard ist ein MSI Z77A-GD65 mit Realtek ALC898 Audio Chip. Treiber habe ich den aktuellen R2.75 installiert.

Link to post

Test mit Audio LAV-Filter: Nach 1,5h keine Probleme zu sehen.

A/V ist synchron und auch der Sourcefilter zeigt keine Auffälligkeiten (Pufferüberläufe oder sowas).

 

Ich lasse das mal noch etwas laufen.

Wer das auch probieren will:

 

Konfig:

Sender: ZDF HD (H.264, AC3 Tonspur)

Win8 64bit

GPU: Intel Ivybridge (durchgehend hdmi Verbindungen)

LAV Audio Decoder (bitstream/passthrough deaktiviert)

LAV Video Decoder (dxva2 aktiviert)

EVR Custom (VSync Aero aus)

Reclock Audio Renderer (WASAPI, AC3 Encoder, alle Settings abzutippen ist mir jetzt zu aufwendig)

DVBSource: PTS Latency: 1000, DVBClock aus, MaxQueued Audio TV/Radio 700

AV Reciever: Marantz AV 7701 (DD Lämpchen leuchtet, HDMI Auto A/V Sync aus)

TV: Samung (keine besonderen Einstellungen)

Edited by nuts
Link to post

Ja.

Allerdings lässt sich in Reclock auch ein Puffer einstellen (500ms default, bei mir nicht geändert).

Hast du den auch so gelassen?

Edited by nuts
Link to post

Ich habe mal getestet, ob der LAV Videodecoder die Zeitstempel kontinuierlich berücksichtigt, indem ich im DVBSource bei den DirectShow-Video-PTS (die nach einem Stop -> Run immer mit 0 beginnen) jeweils 1% aufgeschlagen habe, also

 

PTS := PTS + PTS div 100;

 

was die Video-Wiedergabe allmählich in Richtung Zukunft verschiebt. Mit zunehmender Wiedergabedauer hinkte Video erwartungsgemäß immer mehr hinterher (theoretisch 0,6 Sekunden nach einer Minute, aber das konnte ich nicht messen). Die Zeitstempel werden also berücksichtigt. Die Theorie, dass der LAV Videodecoder vielleicht ausgehend von einem PTS-Startwert nachfolgend nur die Framedauer aufaddiert und die daraus resultierenden Zeitstempel an den Videorenderer weiterreicht, hat sich zumindest in diesem Experiment nicht bewahrheitet.

 

Woher hier der mehrfach beobachtete Versatz nach Diskontinuitäten im Datenstrom kommt, bleibt damit ungeklärt. Den Audiodecoder muss ich mir noch mal auf gleiche Weise vornehmen...

Link to post

 

Allerdings lässt sich in Reclock auch ein Puffer einstellen (500ms default, bei mir nicht geändert).

Hast du den auch so gelassen?

 

Mit den Standardeinstellungen hatte ich in ReClock auch schon Sync-Probleme. Bei mir sind die folgendermaßen gesetzt:

 

Sound pre-buffer: 200ms

Max. latency PCM: 15%

Max. latency Bitstream: 5%

 

Experimente damit gehen aber schon Jahre zurück.

Link to post

Sound pre-buffer: 200ms

Max. latency PCM: 15%

Max. latency Bitstream: 5%

 

Experimente damit gehen aber schon Jahre zurück.

Ja daran wird es wohl liegen.

Bei mir ist da noch nichts optimiert und ich habe die PTS Latenz auch nicht in kleinen Schritten verschoben (nur 0, 300, 1000).

 

Man muss die PTS Latenz auch nicht dazu verwenden den A/V Sync einzustellen, imho genügt es einen ausreichend großen Wert zu wählen (Reclock prepuffer + X?).

 

Test mit dem LAV Audio Decoder und Reclock ist jetzt nach 2,5h ohne Befund abgebrochen worden.

Auch die befürchteten Pufferüberläufe sind zumindest in dem Zeitraum ausgeblieben. Scheint also alles ganz gut zusammenzupassen bei mir. ;)

 

Nun wären Tests von Leuten mit A/V Sync Problemen interessant.

Sollte Reclock das Problem lösen müsste man sich imho die Videokette anschauen.

Nach meinem Verständis driftet dann Video weg und das sollte eigentlich durch verwerfen oder wiederholen von Frames (erzeugt Ruckler, aber eins nach dem anderen) ausgeglichen werden.

Edited by nuts
Link to post
Man muss die PTS Latenz auch nicht dazu verwenden den A/V Sync einzustellen..

 

..man muss nicht nur nicht, sondern man kann imho auch gar nicht. Das verschieben der time stamps in die zukunft verzögert die wiedergabe durch zusätzliches puffern, ändert aber am sync zwischen video und audio nichts, denn es sind davon alle streams gleichermassen betroffen.

 

Bei mir ist im source filter alles auf 0. Damit sabotiere ich @Grigas ausgeklügelten mechanismen und bin dabei eigentlich immer gut gefahren (ausnahmen bestätigen die regel ;) ).

Allerdings habe ich mich auch nie aufs gebiet der HCPCler verirrt. Alles lokal und wenn nicht, sind es streaming clients, die natürlich wiederum ihre eigen probleme haben, aber keine mit directshow einschliesslich source filter vom lokalen DVBViewer client :D

Link to post

Wie der Zufall so will: Bei dem hier bereitgestellten Sample (siehe auch FTP bzw. interner DVBViewer Pro Thread) hängt bei mir nach kurzer Zeit Video deutlich zurück. Ein paar Fakten:

 

- H.264, 1080i, 29,97 fps

- LAV Video Decoder: AV-Versatz mit DXVA2, ohne ok, unabhängig vom Sourcefilter (DVBSource & LAV getestet)

- MS Video Decoder: Kein AV-Versatz mit DXVA2, aber gelegentlich Blockartefakte

- ffdshow Video Decoder: Kein AV-Versatz, mit LAV Source & DXVA Decoder bleibt die Wiedergabe nach kurzer Zeit hängen

- Graka ATI Radeon 4300/4500 HD

 

Bei brasilianischen Samples mit gleichen Video-Parametern zeigen sich ähnliche Effekte. Sieht so aus, als ob die Graka Probleme mit der Dekodierung des Formats hat, was auch die Flüssigkeit / Qualität der Bildwiedergabe beeinträchtigt und speziell mit dem LAV Video Decoder zu AV Sync-Problemen führt. Denkbar ist, dass Diskontinuitäten im Datenstrom eine ähnliche Wirkung haben.

 

Nach der Erfahrungen würde ich Leuten, bei denen der AV-Versatz mit der Zeit zunimmt, empfehlen, probeweise DXVA2 auf der Eigenschaftsseite des LAV Videodecoders zu deaktivieren oder einen Decoder ohne HW-Beschleunigung wie ffdshow zu verwenden. Womöglich liegt da der Hase im Pfeffer ;)

Link to post

 

..hängt bei mir nach kurzer Zeit Video deutlich zurück.

Bei mir nicht. Habe es aber nur mit LAV 0.61.2 nachgestellt..

Link to post

Frühere(?) UVD Versionen hatten grobe Probleme bei Streamfehlern, siehe auch hier. Kann auch sein, dass da ein Feature aus der H.264 Toolbox verwendet wird, das der UVD in der alten 4300/4500 Serie nicht optimal unterstützt. Ich schaue mir das Sample bei Gelegenheit mal mit einer aktuellen Intel und AMD Grafik an. Eine alte Radeon HD 3650 hab ich auch noch rumliegen...

Link to post

Die Probleme kenne ich auch noch zu gut.

Es ist nur so, dass egal wieso und weshalb es zu keinem A/V Drift kommen darf.

Das ist imho immer ein Bug im Treiber, Decoder, Renderer, ...

Was man dagegen tuen kann ist ein anderes Thema.

 

Nachdem hier jeder seine Empörung zum Ausdruck gebracht hat wird es leider wie immer ziemlich still.

Hat niemand Lust mit A/V Sync Problemen mal den von cinch vorgeschlagenen Weg über reclock auszuprobieren?

Edited by nuts
Link to post

 

Nachdem hier jeder seine Empörung zum Ausdruck gebracht hat wird es leider wie immer ziemlich still.

Hat niemand Lust mit A/V Sync Problemen mal den von cinch vorgeschlagenenWeg über reclock auszuprobieren?

 

Das finde ich auch etwas traurig. Jammern und fordern führt hier nicht zum Ziel. Wer nicht selber aktiv wird, kann das Problem nicht lösen.

Link to post

Jetzt habe ich auch einen mysteriösen fall. Habe heute abend den (alten) tatort vom ersten in HD aufgenommen. Halberwege habe ich die wiedergabe während der aufnahme im DVBViewer gestartet, also quasi time shift. Irgendwann gegen ende (aufnahme war bereits beendet) fing es an zu stottern und liefen ton und bild erheblich auseinander. In der source filter ansicht gab es zwar keine fehler aber verdächtig hohe pufferzahlen. Der log von der aufnahme weist übrigens keine fehler auf und auch ein durchlauf durch transedit ergab keinen befund. Neustart vom dvbv half auch nicht.

 

Danach habe ich den DVBViewer filter auf default einstellungen zurückgesetzt und andere filter als LAV probiert. Hat aber auch nicht wirklich geholfen. Live tv lief übrigens ok.

 

Dann fiel mir ein, dass ich im zuge des tests mit dem chilenischen file von @Griga noch andere dinge verstellt hatte. Und bingo: schuld war der haken bei Use Custom Renderer. Als ich den wieder raus nahm, war der spuk vorbei. Kann ich jetzt auch jederzeit reproduzieren.

 

 

Link to post
Und bingo: schuld war der haken bei Use Custom Renderer. Als ich den wieder raus nahm, war der spuk vorbei. Kann ich jetzt auch jederzeit reproduzieren.

 

Bingo. Ich hatte das chilenische Sample ebenfalls mit dem Custom EVR im DVBViewer GE getestet. Eine erneute Überprüfung der Testresultate ergab:

 

- Mit Custom EVR, LAV oder MS Video Decoder treten die geschilderten Probleme vor allem im Vollbild auf. Die Videowiedergabe ist dabei deutlich unrund. In einem Fenster mit ca. 1/4 Bildschirmgröße ist die Wiedergabe dagegen weitgehend normal.

 

- Mit Standard EVR, LAV oder MS Videodecoder keine Probleme im Vollbild. Auch nicht mit dem Custom EVR in CiNcH's D3DTechDemo 2014_07_10.

 

CiNcH erklärt uns jetzt mal, wie das kommt :)

Link to post

Puuuh, im Moment um die Uhrzeit habe ich keine Erklärung parat. Mein Custom EVR ist mehr oder weniger ein Rewrite der wesentlichen Teile... Evtl. schau ich bei Gelegenheit mal drauf.

Link to post

Ich habe das chilenische Sample jetzt mal ohne und mit Aero getestet (vorher alle Tests ohne) und mir mit GPU-Z die GPU-Last angeschaut. Das liefert eventuell eine Erklärung. Alle Tests mit LAV Decoder, 1280 x 960-Bildschirm, also auf jeden Fall ein Downscaling:

- Aero aus, GE Custom EVR,Vollbild, 75% -> Ruckeln, Sync-Probleme
- Aero aus, D3DTechDemo Custom EVR, Vollbild, 75%, Ruckeln, keine Sync-Probleme (!)
- Aero aus, Standard EVR. Vollbild, 50% -> keine Probleme

- Aero an, GE Custom EVR, Vollbild, 65% -> anfällig für Ruckeln & Sync-Probleme, insbesondere wenn ich ein anderes Fenster in den Vordergrund hole.
- Aero an, D3DTechDemo-Custom EVR, Vollbild, 65%-> anfällig für Ruckeln, aber keine Sync-Probleme.
- Aero an, Standard EVR, Vollbild, 65% -> anfällig für Ruckeln, aber keine Sync-Probleme.

- Aero aus, GE Custom EVR, Fenster 1/4 Bildschirm, 70% -> keine Probleme.
- Aero aus, D3DTechDemo Custom EVR, Fenster 1/4 Bildschirm, 50% -> keine Probleme.
- Aero aus, Standard EVR, Fenster 1/4 Bildschirm, 40% -> keine Probleme.

- Aero an, GE Custom EVR, LAV Decoder, Fenster 1/4 Bildschirm, 50% -> keine Probleme.
- Aero an, D3DTechDemo Custom EVR, Fenster 1/4 Bildschirm, 30% -> keine Probleme.
- Aero an, Standard EVR, LAV Decoder, Fenster 1/4 Bildschirm, 30% -> keine Probleme.

Interessanterweise steigt die GPU-Last mit Aero um ca. 10%, wenn das Videofenster teilweise durch ein anderes Fenster verdeckt ist. Ohne Aero passiert das nicht. Dies scheint auch für das Vollbild zu gelten. Insofern ist die ermittelte GPU-Vollbild-Last bei aktivem Aero mit Vorsicht zu genießen, da sich immer das GPU-Z-Fenster über dem Bild befand.

Kurz gesagt scheint hier im Vollbild ab einer GPU-Last von ca. 65% die Wiedergabe nicht mehr rund zu laufen und allgemein anfällig für Ruckler zu werden. Mit dem GE Custom EVR treten dann zusätzlich Sync-Probleme auf. Augenscheinlich führen Verzögerungen nicht zum Überspringen von Bildern, sondern sie addieren sich mit der Zeit und lassen Video hinterherhängen. Der Unterschied ist hier sichtbar: Während z.B. beim D3DTechDemo Custom EVR die Video-Wiedergabe ein kleines Stück weiterspringt, bleibt sie beim GE Custom EVR einen kurzen Moment stehen.

 

Der Custom EVR erzeugt tendenziell eine höhere GPU-Last als der Standard EVR. Bei dem chilenischen Sample reicht offenbar die "amerikanische" Framerate von 29,97 fps, um im Vollbild die kritische Grenze zu überschreiten. Servus TV HD erzeugt z.B. bei gleicher Auflösung und 25 fps deutlich weniger Last.

 

Bitte beachten: Das sind keine allgemeingültigen Fakten. Die Ergebnisse beziehen sich erst mal nur auf ein bestimmtes Sample und mein Setup mit der (relativ schwachen) ATI Radeon HD 4300/4500 GPU. Nichtsdestotrotz deutet sich hier auch aufgrund der Ergebnisse von Derrick an, dass der EVR Custom Renderer im DVBViewer Pro und GE Anteil an Sync-Problemen hat. Mit dem DVBViewer Pro traten sie bei einem kurzen Versuch noch wesentlich drastischer als beim DVBViewer GE in Erscheinung.

Link to post

Hallo Zusammen,

 

vielen Dank für die zahlreichen Informationen. Ich glaube es haben genügend Leute Lust zu testen allerdings kann man den technischen Diskussionen nicht ganz einfach folgen. Wenn es euch hilft (wovon ich mal schwer ausgehe) dann wäre eine kurze Zusammenfassung der kritischen zu testenden Paramtern gut. Ich hab jetzt verstanden dass wohl der Custom EVR Probleme machen könnte. Zudem wirkt sich das unterschiedlich in GE und Pro aus und ist natürlich stark von Decodern abhängig.. Wurde der Custom EVR damals nicht genau gegen die Ruckel Problematik eingesetzt?

 

Viele Grüße und danke nochmals

 

Alex

Link to post

Das geht mir auch so. testen gerne. Muss aber wissen, wie die Testfälle genau aussehen sollen und was ich konfigurieren muss.

Link to post
VinoRosso

Ist ja nicht so das das Zeitaufwändig ist, und man jederzeit einfach mal den Wohnzimmer TV für mehrere Stunden außer Gefecht setzen kann. Mal abgesehen davon, dass das Problem mein Bruder hat und nicht ich selbst, tu ich mir da schwer mit Tests.....

 

Wetter war auch noch gut ^^

Link to post

IMHO gibt es einfach zu viele unterschiede, um sinnvolle tests vorzuschlagen.

 

Den Custom EVR hatte ich übrigens schon früher bei mir als übeltäter verbannt. Durch obigen zufall ist das noch mal bestätigt worden. Woher stammt der überhaupt?

Link to post

 

Woher stammt der überhaupt?

 

Zu großen Teilen entspricht er dem MS Sample Code. In einigen Teilen wurde er adaptiert, um das Mixen von OSDs möglich zu machen.

Link to post

Ja aber den brauchen wir ...

Du vielleicht nicht, aber die HTPC' ler sind auf das OSD angewiesen.

 

Wird Zeit für cinchs Verbesserungen. ;)

Link to post

 

Während z.B. beim D3DTechDemo Custom EVR die Video-Wiedergabe ein kleines Stück weiterspringt, bleibt sie beim GE Custom EVR einen kurzen Moment stehen.

 

Das deutet auf das Scheduling hin. Evtl. kommt die GPU nicht mehr nach und der Scheduler wirkt nicht korrekt dagegen. Die D3DTechDemo zeigt verworfene und wiederholte Samples (bzw. übersprungene VSync Zyklen) an. Da fps der Quelle und Hz der Ausgabe aber nicht übereinstimmen, muss da permanent nachsynchronisiert werden...

 

Das NTSC Video Sample ist, soweit ich das sehen kann, 29.97i. Meine Intel Grafik macht daraus jedenfalls 59.94 fps. Der Deinterlacer verdoppelt also die Bilder.

 

 

Wird Zeit für cinchs Verbesserungen.

 

Verbesserungen ist gut. Da ist mittlerweile kein Stein mehr auf dem anderen.

Link to post

Hallo ZUsammen,

 

also ich habe gerade mal auf einem Win 8.1 System it Intel Grafik (Intel 4400) und dem Lav Decoder einen Test angeschmießen. Hab einfach mal den Customer EVR deaktiviert und musste folgendes festellen

 

- Die Bildqualität ist im Vergleich zum Custom EVR deutlich hinterher. Da werden regelrecht Artefakt produziert. Ich weiß nicht ob es euch auch so geht. Vielleicht liegt das auch nur an der Intel Grafik (Getestet habe ich sowohl HW Intel als auch DXVA)

- Teilweise baut sich beim umschalten das Bild nicht auf bleibt einfach schwarz bis man erneut schaltet

- Ich hatte einen Absturz

 

Von daher bin ich mir nicht ganz sicher ob das der richtige Ansatz ist.

 

VG ALex

Link to post

Also wenn bei dir der Standard EVR solche Probleme bereitet, kann man für gar nichts mehr garantieren. Nach dem Ändern der Option solltest du den DVBViewer neu starten...

Link to post

Hallo Chinch,

 

das System ist relativ neu aufgesetzt (kann ich aber gerne nochmals machen). Es läuft bis auf den Tonversatz auch einwandfrei von daher glaube ich nicht dass irgendetwas grundsätzlich schief läuft auf meinem rechner. Ich hatte noch nie ohne den Custom Renderer getestet hat mich selber gerade sehr überrascht. Und ja natürlich hab ich den Viewer neu gestartet :-)

 

VG Alex

Link to post

Ich habe hier seit ein paar Tagen den Standard EVR auf meiner Intel HD 4000 Grafik (mit LAV und aktiviertem DXVA2 Native) am Laufen, um ein Gefühl für dessen Funktionsweise zu bekommen. Qualitativ ist er dem Custom EVR deutlich überlegen, da hier DXVA2 das Scaling macht und nicht der bilineare D3D Textur-Sampler wie beim Custom EVR.

Link to post

Hi Chich,

 

naja schwer vergleichbar wenn wir unter anderen Betriebsystemen arbeiten :-) Lav habe ich den selben. Eingestellt ist ebenfalls DXVA.

 

VG ALex

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...