na die Frage ist ja nicht ob die DD Tonspur da ist sondern ob du sie auch benutzt.
Ich nehm die DD als default und der vdr fällt nur auf Stereo zurück wenn wirklich keine da ist, und das sind hat meist nur SD Sender...
Christian
na die Frage ist ja nicht ob die DD Tonspur da ist sondern ob du sie auch benutzt.
Ich nehm die DD als default und der vdr fällt nur auf Stereo zurück wenn wirklich keine da ist, und das sind hat meist nur SD Sender...
Christian
Ich probiere das dieses WE auch gerne noch mal alles durch, auf die Tonspuren habe ich nicht geachtet, aber das meiste was wir in SD sehen hat auch eine DD-Tonspur.
Aber noch mal meine Frage: Kann man den Versatz, den der Decoder produziert mit entsprechendem Debug-Code nicht exakt ermitteln?
(siehe auch meinen letzten Beitrag)
Mit entsprechenden Testclips könnte man es testen, aber man kann nicht groß rechnen oder sonst wie ermitteln.
Ansonsten sieht man nur den Zeitstempelbereich vom Sender "xxx/\ms" bei dem AV_INFO Debug im Log.
Stereo / Dolby sollte keinerlei Unterschiede machen, außer man benutzt Passthrough.
Bei Passthrough kann der Fernseher/Receiver ein anderes Delay brauchen, deshalb hat xine noch ein Delay nur für Passthrough.
Johns
Stereo / Dolby sollte keinerlei Unterschiede machen, außer man benutzt Passthrough.
Bei Passthrough kann der Fernseher/Receiver ein anderes Delay brauchen, deshalb hat xine noch ein Delay nur für Passthrough.
joo, dann hätten wir mein Problem schon mal plausibel erklärt.
Christian
Also kommen deine Probleme durch Passthrough und nicht Passthrough.
Das sollte man bei den Offentlich Rechtlichen leicht testen können, die senden ja beides.
diff --git a/audio.c b/audio.c
index 24afabe..bfc6b59 100644
--- a/audio.c
+++ b/audio.c
@@ -3947,7 +3947,10 @@ int64_t AudioGetClock(void)
// delay zero, if no valid time stamp
if ((delay = AudioGetDelay())) {
- return AudioRing[AudioRingRead].PTS - delay;
+ if (AudioRing[AudioRingRead].UseAc3) {
+ return AudioRing[AudioRingRead].PTS + 0 - delay;
+ }
+ return AudioRing[AudioRingRead].PTS + 0 - delay;
}
}
return INT64_C(0x8000000000000000);
Alles anzeigen
Bei den "0" den gefundenen guten AudioVideoDelay eintragen.
Erste "0" ist für Passthrough (UseAc3), die zweite für PCM Ausgang.
Danach Audio Video Delay im Setup wieder auf 0, der kommt noch dazu.
Sollte es dies gewesen sein, dann mache ich es im Setup konfigurierbar.
Johns
na die Frage ist ja nicht ob die DD Tonspur da ist sondern ob du sie auch benutzt.
Ich dachte, dass wäre klar.
Ich hätte es nicht erwähnt, wenn ich es nicht nutzen würde.
Mit entsprechenden Testclips könnte man es testen, aber man kann nicht groß rechnen oder sonst wie ermitteln.
Ansonsten sieht man nur den Zeitstempelbereich vom Sender "xxx/\ms" bei dem AV_INFO Debug im Log.
Stereo / Dolby sollte keinerlei Unterschiede machen, außer man benutzt Passthrough.
Bei Passthrough kann der Fernseher/Receiver ein anderes Delay brauchen, deshalb hat xine noch ein Delay nur für Passthrough.
Ich nutze ebenfalls Passthrough und kann nicht ausschließen, dass der Unterschied bei mir nicht auch zufällig mit PCM und AC3 beim Testen zusammengefallen ist.
Ich werde das noch mal mit dem Patch testen, ansonsten bilde ich mal eine "Expertenrunde", die den Versatz mit Augen- und Ohrenmaß genau bestimmt.
CafeDelMar
Mit Xine in der gleichen Konfiguration zuvor musste ich kein besonderes Delay einstellen. Zumindest ist mir ein so großer Versatz nie aufgefallen.
Hat Xine da bereits eine Voreinstellung oder hat Dein Plugin da so eine andere Herangehensweise, dass man das nicht vergleichen kann?
habs auf 50ms eingestellt und geht so einigermaßen - ehrlich gesagt geht die Lösung mit dem Patch von der ersten Seite (ich verwende dazu immer noch nostalgischen Code vom 6.4.2012) aber noch besser. - Auch das Umschaltverhalten gefällt mir da viel besser als an den aktuellen Versionen, das reagiert viel spontaner (egal ob Softstart Audiosync aktiv oder nicht), ist aber ein anderes Thema.
Christian
Deshalb gibts ja noch keine 0.5.1.
Da falle ich immer wieder darauf herein, es sind Zeitstempel und keine ms: "+ 50 * 90"
diff --git a/audio.c b/audio.c
index 24afabe..2179604 100644
--- a/audio.c
+++ b/audio.c
@@ -3947,7 +3947,10 @@ int64_t AudioGetClock(void)
// delay zero, if no valid time stamp
if ((delay = AudioGetDelay())) {
- return AudioRing[AudioRingRead].PTS - delay;
+ if (AudioRing[AudioRingRead].UseAc3) {
+ return AudioRing[AudioRingRead].PTS + 0 * 90 - delay;
+ }
+ return AudioRing[AudioRingRead].PTS + 50 * 90 - delay;
}
}
return INT64_C(0x8000000000000000);
Alles anzeigen
Das liegt warscheinlich daran, das xine normalerweise richtiger liegt.
Wenn softhddevice schon etwas daneben liegt, dann merkt man die Passthrough Verschiebung besonders.
Johns
also wenn du so eine Änderung noch für älteren Code hättest wäre das ganz ausgezeichnet:
// (cast) needed for the evil gcc
if (AudioPTS != (int64_t) INT64_C(0x8000000000000000)) {
int64_t delay;
if ((delay = AudioGetDelay())) {
return AudioPTS - delay;
}
}
return INT64_C(0x8000000000000000);
Christian
Die Alte Version hat an dieser Stelle die Information ob Passthrough oder nicht, nicht mehr.
Ansonsten würde ich empfehlen die neue zuverwenden, da die Alte nach dem nächsten Release gelöscht wird.
Johns
// (cast) needed for the evil gcc
if (AudioPTS != (int64_t) INT64_C(0x8000000000000000)) {
int64_t delay;
if ((delay = AudioGetDelay())) {
return AudioPTS - delay;
}
}
return INT64_C(0x8000000000000000);
Sorry für die späte Rückmeldung, komm nur sporadisch zum Testen.
Habs jetzt in ner aktuellen Version mit 60ms egtl sehr gut am laufen, seh ich jetzt in Bezuf auf audio delay im Vergleich zu der Version aus Anfang April mit dem alten Patch keinen wirklichen Unterschied - Aus meiner Sicht wär es also schon ein Mehrwert es im Setup einstellbar zu haben.
Christian
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!