Posts by johns

    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

    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

    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

    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

    Testet du mit deinem Patche? Oder Vanilla SoftHdDevice GIT?


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



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



    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

    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

    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

    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

    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