Beiträge von jrie

  • femon mit STR in dBm und SNR in dB bei TT S2-1600, Cine S2 u.a mit stv090x - Jetzt auch ohne Treiber Patch!

    Deswegen der Patch für femon.
    Ist natürlich nur sinnvoll, wenn man nur Karten mit stv090x hat, und nur für femon (bzw. andere Anzeigen müssten entsprechend angepasst werden).
    Du schreibst "linear", linear in Bezug auf was? Gleiche Schritte sind eher bei dB Werten als bei Register Werten gegeben. Die sind ja gerade nicht linear. Insbesondere wenn man DVB-S und DVB-S2 vergleicht.
    Die Patche sollen auch nirgends offiziell einziehen, denn das macht nur Sinn für Karten bei denen die Zuordnung bekannt ist (stv090x, stb0899, ...).
    Dann aber lohnt es sich.

  • femon mit STR in dBm und SNR in dB bei TT S2-1600, Cine S2 u.a mit stv090x - Jetzt auch ohne Treiber Patch!

    Die Tabelle für DVB-S2 ist gar nicht linear:

    Der Treiber nimmt den ersten und den letzten Wert der Kurve, verbindet sie mit einer Geraden und benutzt diese, um die Registerwerte in Signal/Rausch-Verhältnis Werte umzuwandeln. Kein Wunder, dass die Werte für DVB-S und DVB-S2 weit auseinander liegen und nur besser/schlechter Aussagen möglich sind.
    Durch das Benutzen der Tabelle werden die Werte tatsächlich auf der Kurve (laut Datenblatt vom Hersteller) abgelesen. Jetzt passen auch DVB-S und DVB-S2 wieder zueinander, und der VDR hat sich in ein Messgerät verwandelt, mit dem man genaue Carrier/Noise Werte bekommt.
    Wenn man seine Empfangsanlage optimieren will, weiss man jetzt statt besser/schlechter genau, wieviel dB eine Änderung gebracht hat.

  • femon mit STR in dBm und SNR in dB bei TT S2-1600, Cine S2 u.a mit stv090x - Jetzt auch ohne Treiber Patch!

    Mit den beiden Patchen für den Treiber und für femon gibt der Treiber STR in dBm und SNR in dB aus, und femon zeigt sie auch so an. Dabei werden die Tabellen im Treiber benutzt (stv090x_s1cn_tab[], stv090x_s2cn_tab[] und stv090x_rf_tab[]).


    Edit: femon Patch nun mit Balken und Prozent

  • Rezept gegen Mikroruckler bei vdpau h264 mit xine *

    Es wäre nützlich, wenn wir für jede Distribution wüssten, ab welcher Version die fehlerfreien libs enthalten sind. Ich schlage vor, dass ihr dies hier für eure Distribution dokumentiert. Ebenso falls es noch keine Version mit fehlerfreien libs gibt.
    Also z.B.: openSuse ab 12.3 (libxcb 1.9, libX11 1.5.0)
    Das aktuelle yavdr 0.5 (Ubuntu 12.04) z.B. hat (soweit ich weiss) noch libxcb 1.8.x, selbst mit xorg-edgers.

  • extrecmenu Verhalten nach changeset vom 3.5.2013

    Ich habe kürzlich extrecmenu upgedated.
    Seitdem hat sich etwas am „Verhalten“ geändert, und vorher fand ich es besser.
    Ich habe
    extrecmenu.GoLastReplayed = 0
    extrecmenu.ReturnToPlugin = 1
    Vorher bin ich nach dem Abspielen einer Aufnahme im Aufzeichnungen-Menu auf der Aufnahme gelandet, nach dem Verlassen des Aufzeichnungen-Menus und neu betreten aber nur im video Verzeichnis.
    So wollte ich es auch haben.


    Jetzt lande ich nach dem Abspielen einer Aufnahme nicht mehr auf der Aufnahme.
    Falls ich aber
    extrecmenu.GoLastReplayed = 1
    setze, lande ich zwar nach dem Abspielen einer Aufnahme auf der Aufnahme, aber auch beim erneutem Betreten des Menus auf der letzten Aufnahme, statt im video Verzeichnis.


    Ich kann das alte erwünschte Verhalten nicht mehr konfigurieren.
    Das kommt durch das changeset vom 3.5.2013.


    Ich fände es schön, wenn das alte Verhalten wieder einstellbar wäre.

  • [softhddevice] Dropping frame/Duping frame - Lösung bzw. Bug entdeckt

    Bei mir läuft ffmpeg-1.0.6
    Ich habe bisher nur mit Aufnahmen getestet, weil ich ja vergleichen will.
    Unten mal 10 Minuten ZDF HD live.
    Hier noch die Tests der anderen Aufnahmen mit av4.
    Aufnahme 1 ist gleich, 2 ist besser und 4 ist gleich.
    [OT die diff < 1800 bei xine lagen an pts-wraps, das steckt softhddevice besser weg als xine]
    Ich denke, av4 ist reif für´s git.
    Ich habe gerade eine neue Aufnahme von ZDF HD aufgenommen und getestet (1 Stunde was gerade läuft), die hat nur wenige slows nach dem ersten speed. Meine problematische Aufnahme 3 ist von Ende März und offensichtlich für softhddevice eine härtere Nuss als die neue Aufnahme und live TV. Laut checkts und TSDoctor ist sie aber fehlerlos und wird ja auch von xine einwandfrei wiedergegeben.


    Aufnahme 1 mit av4:

    Aufnahme 2 mit av4:

    Aufnahme 4 mit av4:

    10 Minuten ZDF HD live:

    aktuelle ZDF HD Aufnahme:

  • [softhddevice] Dropping frame/Duping frame - Lösung bzw. Bug entdeckt

    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:

  • [softhddevice] Dropping frame/Duping frame - Lösung bzw. Bug entdeckt

    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:

  • VDR stüzt einfach ab

    OpenSuse ist bei 12.3 angekommen. 11.2 ist stark veraltet. Ich empfehle ein Update.
    Auch weil mit neuerer Software bestimmte Probleme entfallen.
    Dann hast du auch automatisch neuere Treiber.
    Ansonsten ist es denkbar, dass deine neuere Karte eine geringere Empfindlichkeit hat als die alte. Das könnte Probleme verursachen. Das würde ich mal überprüfen.

  • [softhddevice] Dropping frame/Duping frame - Lösung bzw. Bug entdeckt

    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. war BR HD Das 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.

  • [softhddevice] Dropping frame/Duping frame - Lösung bzw. Bug entdeckt

    Soweit ich weiss, sind die pts im A/V Stream, also auch in einer Aufzeichnung.
    Das Problem tritt bei der Wiedergabe auf, wenn die pts auf die real vergehenden Zeit abgestimmt werden müssen.


    Copperhead, hattest du bei deinem Test das vergrösserte Zeitfenster für die Synchronisation drin (gab da mal einen Patch)?


    Edit: Johns war schneller.


    Eddit2: xine ist da weitaus komplexer und hat ein eigenes Metronom (Zeitticker). Deshalb treten manche Probleme, die softhddevice hat, in xine nicht auf, aber es ist auch komplizierter und verbraucht mehr Resourcen.