Also ich bin jetzt soweit glücklich. Kaum bis gar keine gedoppelten oder gedroppten Frames mehr. (Nur noch der letzte Patch)
[softhddevice] Dropping frame/Duping frame - Lösung bzw. Bug entdeckt
-
Mit einer G210 hatte ich mit dem letzten Patch immer wieder drops und dups im Log. Nach Austausch gegen eine G610 war Ruhe. Es scheint also grundsätzlich auch eine Frage der Hardware zu sein.
Gruß
iNOB -
Anbei ein aktualisierter Patch, er loggt nur noch Sprünge > 10ms und vergrößert den Syncbereich von -15 - 45 auf -25 - 55.
Dadurch sollte es weniger kombinierte drop/dup kommen.Kann es sein, daß da eine Klammer fehlt:
Code
Alles anzeigen- if (abs(video_clock - audio_clock + VideoAudioDelay) > 5000 * 90) { // <-------------------------------------- + diff = video_clock - audio_clock + VideoAudioDelay; // <-------------------------------------- +#if defined(DEBUG) || defined(AV_INFO) + // Debug code for dup/drop bug + if ( abs(diff - decoder->LastAVDiff) > 90 && decoder->StartCounter > 1000) { + Info("video: %s%+5" PRId64 " %4" PRId64 " %3d/\\ms %3d%+d v+buf\n", + Timestamp2String(video_clock), + abs((video_clock - audio_clock) / 90) < + 8888 ? ((video_clock - audio_clock) / 90) : 8888, + AudioGetDelay() / 90, (int)VideoDeltaPTS / 90, + VideoGetBuffers(decoder->Stream), + (1 + decoder->Interlaced) * atomic_read(&decoder->SurfacesFilled) + - decoder->SurfaceField); + } + decoder->LastAVDiff = diff; +#endif + + if (abs(diff) > 5000 * 90) { // more than 5s err = VdpauMessage(2, "video: audio/video difference too big\n"); } else if (video_clock > audio_clock + VideoAudioDelay + 100 * 90) { // <------- hier ist 'audio_clock + VideoAudioDelay' rechts von '>'
diff = video_clock - (audio_clock + VideoAudioDelay);Eigentlich fehlt auch in den Debug-Messages der Offset durch VideoAudioDelay.
Gruß
e9hack -
Schaue ich mir nochmal an. Ist aber wurscht da diff nur für die 5s genommen wird.
Den Delay habe ich im Debug bzw. Info extra weggelassen, so sieht man ihn.
Johns
-
Es scheint auch am Filmmaterial zu liegen.
Bei der ersten Aufnahme schaut es ganz gut aus, 6 slow in 1 Stunde:Aber bei der nächsten Aufnahme kommen in 25 Minuten mehr Meldungen, und auch slow/speed Paare:
Bei der dritten Aufnahme sind es in wenigen Minuten viele Meldungen und sogar missed frames:
Das ganze mit einer GT520.
Es hängt also stark vom Material ab.
1. warBR HDDas Erste HD von 2011
2. war 3sat HD
3. war ZDF HD (wie auch schon von e9hack bemerkt)
Die Datenrate war bei Aufnahme_1 8, bei Aufnahme_2 12 und bei Aufnahme_3 13 Mbps. -
Hast den Patch drin?
Du hast nicht zufällig einen Deinterlacer für 720p aktiviert?
Von der Rechenleistung ist ja 720p weniger anspruchsvoll wie 1080i.BR3 HD ist bei mir auch sehr unruhig.
Johns
-
Der Patch ist drin.
Allerdings habe ich vermutlich auch den Deinterlacer an, was ja unnötig ist bei 720p, ich guck nach, wenn ich zuhause bin, bin mir aber fast sicher.
Ich werde es noch mal ohne testen. -
Ich warte auf Testergebnisse.
Habe noch eine andere Version, die die den Mittelwert der letzten Diffs nimmt.
Code+ diff = (decoder->LastAVDiff + diff) / 2;
Entfernen dann ist es wieder die letzte Version mit dem Delay fix.
Eine merkbare Verbesserung hat sich bei mir nicht ergeben.Code+ diff = (decoder->LastAVDiff * 2 + diff) / 3;
Könnte man auch noch testen. Dadurch wird die Regelung noch etwas mehr geglättet.Ein Nebeneffekt ist das sich der Ton mehr gegen die 0 regelt.
Edit: Und ich gehe mal davon aus, daß die Uhr stellen doch keinerlei Effekt hat?
Johns
Edit: Anhang gelöscht: akutelle Version hier: [softhddevice] Dropping frame/Duping frame - Lösung bzw. Bug entdeckt
-
Fehlt im diff vor dem letzten 25 * 90 ein Minus?
-
Ja. Ich mache Morgen einen neuen Patch.
Johns
-
Und hier?
Code- if (abs(video_clock - audio_clock + VideoAudioDelay) > 5000 * 90) { + diff = video_clock - audio_clock - VideoAudioDelay; .. + if (abs(diff) > 5000 * 90) { // more than 5sWar die Vorzeichenänderung bei VideoAudioDelay hier beabsichtigt?
Code- } else if (video_clock > audio_clock + VideoAudioDelay + 45 * 90) { + } else if (diff > 55 * 90) {Hier passt das Vorzeichen.
Tschüß Frank
-
Das mit dem Audiodelay stimmt schon, das war vorher falsch. Steht weiter vorne im Thread.
Anbei die aktuelle Version 4.
Johns
-
Ich habe den Deinterlacer auf Weave/None gesetzt und noch mal getestet (mit av2.diff).
Bei allen drei Aufnahmen gibt es dadurch weniger Einträge.
Aufnahme 1 bis 3 wie in Post # 85, Aufnahme 4 ist BR HD mit 13 Mbps.
Zum Vergleich dasselbe mit xine (anbei ein Patch der die weg geworfenen Bilder ins syslog schreibt). Bei Aufnahme 1, 2 und 4 nimmt sich das nicht so sehr viel.
Merkwürdig, dass es mit softhddevice bei ZDF HD so heftig ist (Aufnahme 3), 228 Einträge und viele missed frames bei softhddevice im Gegensatz zu 10 Einträgen bei xine.
Von da her wären Tests bzw. Analysen auf ZDF HD besonders interessant. Vielleicht müsste man mal mit einem Stream Analyser gucken, was bei ZDF HD so anders ist und von softhddevice nicht abgefangen wird, da gab es mal was hier im Forum zur Stream Analyse.
Manchmal hat xine einen 7 Minuten Takt.
Manchmal hat softhddevice einen 14 Minuten Takt.
Wobei sich der Takt erst nach längerem einpendelt, anfangs hat softhddevice mehr und xine weniger Einträge.
[OT Die xine Einträge mit diff < 1800 bei Aufnahme 2 darf es eigentlich gar nicht geben, weil xine erst über 1800 weg schmeisst (bei 720p50), dem müßte man auch mal nach gehen.]Aufnahme 1 mit softhddevice:
Aufnahme 1 mit xine:
Aufnahme 2 mit softhddevice:
Aufnahme 2 mit xine:
Aufnahme 3 mit softhddevice (228 Einträge!):
Aufnahme 3 mit xine:
Aufnahme 4 mit softhddevice:
Aufnahme 4 mit xine:
-
Danke jrie, das sollte weiterhelfen.
Wenn nur "dups" oder "drops" kommen, dann ist es in Ordnung.
Wenn es viele drop+dup Paare gibt, dann bringt es den Hardware Dekoder durcheinander, dadurch erklären sich die "missed" Frames.VideoSetPts in video.c behandelt die Video Zeitstempel vom Sender. Die " Debug(4," in "Debug(3" ändern, dann sieht man was hier passiert.
Wobei ich negative Sprüinge im Breich von 600ms bis 40ms herausfiltere, die sieht man im Normalen Log dann als "/\" Wert.Johns
-
Mit av4.diff ist Aufnahme 3 viel besser!
Es gibt aber immer noch missed frames, auch ohne direkt vorausgehende drop+dup Paare.
Mit (decoder->LastAVDiff * 2 + diff) / 3 wird es etwas schlechter.Aufnahme 3 mit av4.diff:
Aufnahme 3 mit av4.diff und (decoder->LastAVDiff * 2 + diff) / 3:
und nochmal zum einfacherem Vergleich Aufnahme 3 mit xine:
-
Was mir aufgefallen ist, bei ZDF HD gibt es kurz nach dem Start einen Sprung von 1800 TS = 20ms.
Dadurch werden die Puffer um 20ms kleiner. Die sollten aber bei Aufnahmen keine Rolle spielen.
Ansonsten sind die TS vom Sender absolut synchron.Ansonsten welche ffmpeg bzw. libav Version wird verwendet?
Und ist das Verhalten bei Aufnahmen und LiveTV gleich?
Ich teste im Moment immer LiveTV (ist einfacher).Johns
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!