softhddevice: unnötiges dropping / duping frames – die Ursache?!

    Für die Sender, die große AudioBufferTime brauchen, kann ich mir zwei Lösungen vorstellen.


    Lösung A: Über status.h die Kanalnummer, auf die umgeschaltet wird, ins Plugin holen, und in AudioSetBufferTime() ein entsprechendes delay einstellen.


    Lösung B: Eine heiße Spur ist, dass beim Umschalten auf gute Sender ich von ffmpeg immer bestimmte Meldungen bekomme, von den beiden Problem-Sendern jedoch nicht. Auf den guten Sendern gibt es nach den Meldungen eine kleine Pause, bevor die Wiedergabe anläuft, auf den Schlechten läuft es ohne Pause früher an. Dem könnte man mal auf den Grund gehen.

    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?

    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.


    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.


    Der korrekte Syncbereich bringt halt die Fehler ans Licht. Und am besten werden die an der Ursache behoben.
    Solange das nicht geschehen ist, muss man eben wählen, was einem wichtiger ist. Schnelles zappen auch auf den „schlechten“ Sendern, oder gut funktionierendes Pause, Play, Sprünge etc.

    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

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    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

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    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

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    Es ist aber nicht so, wie es soll ;) .


    Und mit dem Patch tut es, wie es soll.


    Dass die Probleme wo anders liegen, glaube ich nicht. Hast du konkrete Anhaltspunkte dafür?

    Zitat von johns

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


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


    Zitat

    the range that is considered acceptable for film is +/- 22 ms. The range for video, according to the ATSC, is up to 15 ms lead time and about 45 ms lag time


    Aha, da kam das ursprüngliche -15 ... 45 her.


    Nun ja, wollen wir „ acceptable“ und „up to“ oder möglichst gut?


    Es gab auch mal eine Studie von ARD und ZDF, die besagte, dass 720p besser als 1080i wäre.
    Auf den Geräten, auf denen die Studie erstellt wurde, stimmte das sogar, aber auf den Geräten, die es zum Zeitpunkt der Veröffentlichung gab, schon nicht mehr.


    Solchen Aussagen ist IMHO mit einer gesunden Portion Skepsis zu begegnen.


    Edit: Ich habe mir das Dokument "ATSC Implementation Subcommittee Finding: Relative Timing of Sound and Vision for Broadcast Operations" jetzt mal durch gelesen.


    Es geht dabei um das Encodieren in den Fernsehsendern. Ist also gar nicht relevant für softhddevice.


    Und noch der link: http://www.webcitation.org/60UbU5Ziv


    Edit3: Und hier noch ein Zitat der EBU Recommendation R37-200:

    Zitat

    The accuracy of A/V synchronisation at each stage should lie within the range of Audio 5 ms early (sound before picture) to 15 ms late (sound after picture).

    Das bezieht sich zwar auch wieder nur auf Fernseh-Sender, spricht aber dafür statt -13 … 10 lieber -8 … 15 zu nehmen.

    Man muss auch bedenken, dass wir nicht wissen, mit welchem A/V-Versatz der Stream bei uns ankommt. Je nach dem, wie gut der Sender den A/V-Versatz hin bekommen hat, kann das größer oder kleiner sein.
    Alles was vom Abspiel-Plugin hinzu gefügt wird, kann den Bereich von nicht wahrnehmbar zu wahrnehmbar vergrößern. Deswegen geben sich Plugins mit xine da auch so große Mühe.
    Auf jeden Fall sollte so wenig wie möglich hinzu gefügt werden, und wenn man Audio als Master hat und über Video synct, ist das eben ein wenig größer als 20ms.

    Ich habe heraus bekommen, dass es am Interlaced liegt.
    Auf progressive Sendern funktioniert -8 … 15 tadellos.
    Auf interlaced Sendern braucht es mehr.


    Daher neue Patche. mutex16.diff ist bis auf den herausgenommenen Syncbereich gleich wie mutex15.diff. Für den Syncbereich gibt es jetzt sync_range_depends_on_interlaced.diff.


    Ich könnte sein, dass in der Interlaced Verarbeitung ein Fehler ist. Bin noch am Suchen.

    Der beigefügte Patch läßt das Sync-Fenster für Interlaced TV so wie es war, für Progressive TV und Wiedergabe wird -8 … 15 eingestellt. Vorteil: schnelles Zappen wie zuvor, sauberer Sync bei progressive TV und Wiedergabe.


    Code
    +	// FIXME: for Rai SD on Hotbird we need 110
+	upper_limit = decoder->Interlaced && !IsReplay ? 55 : 15;
+	lower_limit = decoder->Interlaced && !IsReplay ? -25 : -8; 
+	if (decoder->Interlaced && !IsReplay) {
+	    diff = (decoder->LastAVDiff + diff) / 2;
+	    decoder->LastAVDiff = diff;
+	}


    Angewendet werden:
    0001-soft-start-v3.diff
    mutex16.diff
    pause_play_fix_v4.diff
    debug.3c.diff
    sync_range_depends_on_interlaced_and_replay.diff

    Der Grund für die Aussetzer bei kleinem Sync Fenster insbesondere bei den „schlechten“ Sendern liegt daran, dass dort zu wenig Video gepuffert wird. Das Video kommt auf diesen Sendern abwechselnd eine Zeitlang nicht, und dann wieder viel auf einmal (keine Ahnung, ob das an den Sendern liegt, oder daran wie sie in softHDdevice verarbeitet werden). Wenn nur noch 3 Video Surfaces im Ringbuffer sind, wird im nächsten Schritt gedupt und der Sync entgleist. Auf den meisten interlaced Sendern reichen 120ms zusätzliches Puffern, auf den „schlechten“ müssen es aber 400ms zusätzlich sein.
    Ich vermute, dass die meisten lieber schnelle Umschaltzeiten haben und den schlechteren Sync in Kauf nehmen. Deswegen habe ich meine Arbeiten an einem entsprechendem Patch abgebrochen. 400ms zusätzlich bemerkt man nämlich, und es wären dann alle interlaced Sender betroffen (es sei denn, man verwendet für jeden Sender einen dazugehörigen eigenen Pufferwert).


    Mit VIDEO_SURFACES_MAX auf 16 erhöht erkennt man besser, was passiert:
    In Zeile 17 + 18 werden Surfaces aufgefüllt,
    dann werden sie verbraucht und gehen auf 4 zurück.
    In Zeile 43 und 68 werden sie wieder aufgefüllt.
    In Zeile 93 sind nur noch 3 da, anschließend muss gedupt werden.
    In Zeile 105 wird wieder aufgefüllt, und was zu viel gedupt wurde, wird gleich wieder gedropt.
    Der Puffer war am unteren Rand und daher wurde gedupt und dann gedropt, das ist die Ursache.
    Die saubere Lösung wäre mehr zu puffern (und zu gucken, ob an dem Wechsel von Schüben und Pausen etwas verbessert werden kann).
    Das Sync Fenster zu vergrößern hat den Vorteil, dass schneller los gespielt wird, aber der präzise Sync wird geopfert.


    Nachdem ich mir den Thread nochmal durchgelesen habe, fällt mir #22 wieder ein. Es könnte sich lohnen zu gucken, wie in softHDdevice die „schlechten“ Sender verarbeitet werden.

    Zitat von jrie

    Angewendet werden:
    0001-soft-start-v3.diff
    mutex16.diff
    pause_play_fix_v4.diff
    sync_range_depends_on_interlaced_and_replay.diff


    Wenn ich das patch Set auf die aktuelle git Version anwende, bekomme ich rejects bei "sync_range_depends_on_interlaced_and_replay.diff". Entweder fehlt mir da noch ein Patch, oder du verwendest eine andere Version von softhddevice.


    video.c.rej

    lastAClock und lastTime gibts in meiner Version von video.c nicht.


    Gruß
    iNOB

    Zitat von jrie

    Dann muß debug.3c.diff auch noch rein (eventuell auch debug.4b.diff und optimize_AudioBufferTime_v14b.diff)


    nope... selbst mit den o.g. zusätzlichen patches, gleicher Fehler wie oben. Irgendwas fehlt noch.

    Ich hab's gefunden ;) !
    Das Problem ist der detectradio.diff. Das sieht man an den Ausgaben von debug_IsPlayingVideo_v2.diff (zusätzlich war noch DisplayPts() in codec.c aktiviert). Da kommt nämlich auf Nickelodeon:


    und auf Rai SD:


    Man sieht auch, dass tatsächlich nur alle 480ms eine PTS kommt, aber das stört gar nicht.
    Was stört ist, dass durch den fehlerhaften Trigger aus detectradio.diff Audio zu früh los läuft, und dadurch ist zu wenig Video gepuffert, und das verursacht dupe/drop, wenn der Syncbereich die „richtige“ Größe hat.
    Zum Vergleich, Kabel Eins hat kein Problem:


    Mit auskommentiertem fehlerhaften Trigger funzt mit -8 … 15 alles perfekt!


    Jetzt fehlt nur noch ein korrekter Trigger für das Loslaufen von Radio.
    Das ist aber nicht mehr meine Baustelle.


    Angewendet werden:
    0001-soft-start-v3.diff
    mutex16.diff
    pause_play_fix_v4.diff
    sync_range_v2.diff
    fix_IsPlayingVideo_v2.diff
    und je nach Bedarf
    AudioSetBufferTime.1b.diff
    optimize_AudioBufferTime_v14b.diff
    debug.3c.diff
    debug.4e.diff

    ... und der Rest.

    Ich habe wegen korrektem Trigger für das Loslaufen von Radio noch mal nachgedacht.
    Man müsste die längste Zeitspanne auf den „schlechten“ Sendern bestimmen, während der kein Video kommt (bevor dann wieder viel auf einmal rein kommt).
    Diese Zeitspanne müsste man abwarten, bevor etwas als Radio erkannt wird.
    Der Kommentar vor VideoMpegEnqueue() erklärt möglicherweise das schubweise Hereinkommen in den Packetpuffer.
    Anbei ein erster Versuch, anstatt fix_IsPlayingVideo_v2.diff anzuwenden.
    Erst wenig getestet, und 1000ms kann man eventuell noch verkleinern.

    Irgendwie müssen wir mal die Patch Orgie in geordnete Bahnen bringen.


    Dann bringe ich GIT auf diesen Stand und alle können testen ohne patchen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden