Beiträge von johns

Naja versuch mal mit einer Option, dann können andere es verwenden.

Dann müssen wir noch ein Video machen, wie stelle ich SoftHdDevice ein.

Johns

Zitat von jrie

Z
Wenn Fehler statt an der Ursache durch das Vergrößern des Syncbereichs kompensiert werden, stört das nicht weiter, solange man nur zappt und Aufnahmen durch laufen lässt. Sobald aber wiederholtes Pause Play, wiederholte Sprünge und vermutlich auch Trickspeedmodi ins Spiel kommen, wird der Sync durch ein zu großes Fenster stark gestört.

Wenn zappen funktioniert, dann soll auch Springen funktionieren. Rumspringen auf der Pausetaste soll kein Negativen Effekt haben.

Wenn es hier Probleme gibt, dann liegen die wo anders. z.b. Irgendwelche Puffer falsch gelöscht, Berechnungsfehler...

Wenn nach dem Zappen das A/V Sync gut ist, dann soll es auch beim Springen und bein Anhalten und Stoppen in Aufnahmen.

Johns

Zitat von jrie

Zur Größe des Sync Fensters: Da mit 50p ausgegeben wird, sind die Frames 20ms lang. Da über weglassen oder verdoppeln von Frames gesynct wird, reichen 20ms, man sieht das auch daran, dass von 10 auf -10 gesprungen wird. Da überall in ganzzahligen Millisekunden gerechnet wird, schleichen sich ein paar Rundungsfehler ein, dadurch sind 23ms nötig.

Es gibt eine Norm die festlegt wie genau der Syncbereich sein muß.

https://en.wikipedia.org/wiki/Audio_to_video_synchronization

Johns

Zitat von jrie

Ich habe die Streams mal mit TSPE analysiert. Auf den schlechten kommen nur alle 480ms PTS/PCR, auf den guten alle 40ms. Ich kenne mich mit Stream Analyse nicht aus, aber ich vermute mal, dass es daran liegt. Auch der TSPacketViewer zeigt, dass auf den schlechten die mit Start markierten Audio Pakete sehr spät kommen.

johns, was macht softhddevice, wenn die PTS erst nach bis zu 480ms kommen?

PCR verwende ich nicht. Nur die PTS.

SoftHdDevice wartet bis er die PTS bekommt und da die Videodaten gepuffert werden und so die PTS nicht im Lowlevel ankommt, läuft es erst los wenn die Audiopuffer voll sind.

Ich denke die Startmarkierung wird bei Audiostream bereits ignoriert. Zuviele Sender haben dies falsch oder zu selten gesetzt.
Ich analysiere den Audiostream und wenn ich ein bekanntes Format erkenne, verwende ich den dazugehörigen Dekoder.

Johns

Jetzt geht es erstmal darum die Stelle wo es gemacht wird zu finden.
Und im Zweiten, es dann konfigurierbar zumachen.

Johns

Ich kann nichts zu yaVDR sagen, aber SkyLake und VA-API geht sehr gut.

SoftHdDevice GIT läuft sowohl mit der normalen Ausgabe und OpenGL Ausgabe mit BOB ohne irgendwelche Probleme.

Der VA-API VPP Branch hat diverse Probleme. Im entsprechenden Thread waren die Patche drin.
Kann sein, daß die jetzt schon drin sind. Damit lliefen dann die advanced Deinterlacer und machten ein gutes Bild.

Johns

All die schönen Sachen wollt ihr nicht.

Es wird das erste Bild sofort ausgeben, um einen Feedback zugeben, daß umgeschaltet wurde,
Hilft auch beim Zappen.

Da mußt mal in den Sourcen suchen, sollte einfach zuverhindern sein, da es extra anderes behandelt wird.

Johns

Warum kein ESP8266 oder ähnliches Wifi Modul?

Dann wäre der USB Port weiter benutzbar.

Johns

Kann sein das mein Dekoder irgendwo hängt.
Audio wird direkt dekodiert und ausgeben.
Ich habe einen eigenen Dekoder, damit ich das Ende der Audiopakete früher erkenne.

Mit ::PlayTsAudio geht es los.

Johns

Testet du mit deinem Patche? Oder Vanilla SoftHdDevice GIT?

Es sieht so aus, daß lange Zeit kein Audiopaket mehr kommt.

void AudioEnqueue(const void *samples, int count)
{
    size_t n;
    int16_t *buffer;


#ifdef noDEBUG
    static uint32_t last_tick;
    uint32_t tick;


    tick = GetMsTicks();
    if (tick - last_tick > 101) {
        Debug(3, "audio: enqueue %4d %dms\n", count, tick - last_tick);
    }
    last_tick = tick;
#endif

Ändere mal den noDEBUG auf DEBUG und die 101 kannst auch rausnehmen.

void AudioEnqueue(const void *samples, int count)
{
    size_t n;
    int16_t *buffer;


#ifdef DEBUG
    static uint32_t last_tick;
    uint32_t tick;


    tick = GetMsTicks();
    Debug(3, "audio: enqueue %4d %dms\n", count, tick - last_tick);
    last_tick = tick;
#endif

Es sollten regelmässig Packete ankommen. Wenn nein. Dann können die irgendwo hängen oder gehen verloren.
Könnte ein Dekodierfehler sein

Andere Tonspur funktioniert? Passthrough ein / aus.

Johns

Zitat von utiltiy

Ich probiere gerne mit aus, aber jetzt werden die ganzen Patche langsam zuviel. Kann man das irgendwie zusammenfassen, deine und die von johns?

0001-soft-start-v3.diff kommt bald ins GIT. Der ist ungefährlich und verbessert nur.

pause_play_fix_v3.diff ich weiß nicht, ich muß mir nochmal die neuste Version anschauen.
Im Prinzip wird nur ein Sonderfall verändert, der bei mir nicht passiert. Müssten halt noch ein paar probieren und dann sehen wir weiter.

mutex15.diff ist schwierig. Es sind mehrere Threads beteiligt. Es sind Threads vom VDR dabei, da weiß ich nicht wie die auf Verzögerungen reagieren. Insgesamt würde ich eine andere A/V Sync Korrektur, die "weicher" reagiert bevorzugen. Die würde dann bei einem Fehler hier nicht sofort reagieren.

Johns

Jetzt brauchen wir noch eine Lockfreie Lösung.

Johns

Wobei laut Standard der A/V Sync von x .. y erlaubt ist. So ein scharfes A/V Sync wird nicht verlangt und ist nicht feststellbar.

Johns

Beim Herausnehmen und Befüllen kann es kurze Sorünge geben.

Bei AudioEnqueue wird erst in den Ringbuffer geschrieben und dann die PTS aktualisiert.
Aber es sind immer nur kleine Packete, iirc 32ms.

Bei AlsaPlayRingbuffer ist ein Packet kurze Zeit im Kernel und im Ringpuffer, es ist wiederum nur kurze Zeit.
Auch irgendwas im Bereich 20 - 30 ms.

Wenn dies die Ursache ist, dann müssten es mehr Leute sehen. Ich kann den Fehler nirgents nach vollziehen.

Edit: Kannst ja mal ein Mutex rumsetzten: AudioRing[AudioRingWrite].PTS ist der Zeitstempel.

Johns

Habe mit ARTE HD Aufnahme getestet. Schnell mehrmals Pause oder langsam. Kein Triggern des Effekts.

Kann an der Version der Alsalib oder Kernel liegen.

Johns

Linux ist nun mal kein Realtime Betriebssystem.

Es wird an Hand des Kernelpuffers und des Ringpuffers berechnet, welcher Audiozeitstempel gerade ist.
Beim experimentellen Audiodrift, habe ich versucht noch die Systemzeit mit einzubeziehen.

Es kommen noch zusätzliche Puffer im Alsa Library dazu, vermutlich auch noch mehrere Threads.

AlsaGetDelay berechnet dies für Alsalib und Kernel.

Ich vermute durch Taskwechsel usw. entstehen die Schwankungen.

Johns

Ja, habe mich schon gewundert was das Problem sein sollte.

Johns

Also ich habe mal ein fprintf an der Stelle eingebaut und bei mir kommt es nie zu dieser Stelle.

Bei mir tritt der Underrun immer in "snd_pcm_wait" auf.

Johns

Danke,

Ich schau es mir an. Es hat hier einen Effekt über mehrere Ebenen.
audio/alsa: writei underrun error
Kann es sein, daß wir das neue Verhalten nur für AudioPaused brauchen?

Johns

Ich denke ich hatte mal einen Beitrag bei DR. Dish gesehen.

Das "Kühlen" reduziert das Rauschen und verbessert so den Empfang.

Einfachmal "lnb kühlen" googeln.

Johns