Posts by rnissl

  • nOpacity 1.1.2: Tabbed EPG View

    Hi,


    Quote from louis


    Aber zu deiner Frage: das Problem ist, dass bei Xine als Ausgabeplugin das True Color OSD noch nicht verfügbar ist und deshalb der Pointer auf das OSD Objekt NULL ist. Das müsste man aber an einigen Stellen abfangen, und da ich keinen Bock habe, mir eine Testumgebung mit dem Xine Plugin aufzubauen, um das zu testen, habe ich es mir einfach gemacht und unterdrücke den ersten Aufruf einfach.


    Was braucht es alles (außer der Xine-Testumgebung ;-)), um das Problem nachzustellen?


    Bye.

  • Frage an Spezialisten zu PES-Paketen w/ Tonstörungen ZDF (SDTV)

    Hi,


    die stuffing bytes sind Bestandteil des PES-Headers und auch in der Header Data Length enthalten. Wenn die PES "austütel"-Routine richtig funktioniert, dann bekommt der Audiodekoder auch nur die Audiodaten übermittelt.


    Man müsste wohl die Audioframes selber mal untersuchen, ob da sowas wie anxillary data o. ä. enthalten ist, was den Dekoder stört.


    Bye.

  • ZDF HD schlechtes Bild

    Hi,


    ich war gestern auch erstaunt, dass meine vdr-xine-Lösung mit VDPAU diese Bildfehler produzierte, die von der Art her auf den Dekoder zurückzuführen sind.


    Dann erinnerte ich mich, dass xine-lib-1.2 ja zwei VDPAU H.264 Dekoder anbietet: vdpau_h264 und vdpau_h264_alter.


    Als vdpau_h264_alter eingeführt wurde, hatte ich ihm eine niedrigere Priorität gegeben, da er mich damals noch nicht überzeugt hatte. Also kurzum dem Dekoder eine höhere Priorität gegeben, und siehe da, die Probleme waren weg.


    Hier ein Auszug aus ~/.xine/config:

    Code
    # priority for vdpau_h264 decoder
# numeric, default: 0
#engine.decoder_priorities.vdpau_h264:0


# priority for vdpau_h264_alter decoder
# numeric, default: 0
engine.decoder_priorities.vdpau_h264_alter:1


    Bye.

  • vdr-plugin-xine 4:3 auf 16:9 strecken

    Hi,


    Quote from herrlado

    Meine Frage war, warum beim umschalten, also z.B. Sky Film auf Sky Film+1 16:9 -> 4:3 -> 16:9 passiert?


    laut INSTALL von vdr-xine-0.9.4:

    Code
    BTW: the ...4x3... or ...16x9... indicate which aspect ratio should be assumed
     for the files. vdr-xine tries to load both specific files and falls back
     to the file name "noSignal.mpg" when a specific file does not exist.
     vdr-xine will then choose the file to display depending on VDR's DVB setup
     option video format.


    Bitte prüf' doch mal in VDRs DVB Menü, ob dort 16:9 als Videoformat eingestellt ist. Damit sollte es funktionieren.


    Bye.

  • [ANNOUNCE] vdr-xine-0.9.4 plugin

    Hi,



    Tja, leider darf sich im Verlauf des Streams der Versatz von Audio und Video im Input (also auf Senderseite) ändern. Erwischt man in der Pufferphase z. B. das Audio vorausläuft und fällt es später zurück, dann kommt es mitunter zum buffer underrun bei der Ausgabe und der Ton stockt.


    Vermutlich ist xine.modeLiveTV.prebufferFramesVideoHD = 8 etwas zu optimistisch. Mit 16 könnte es ggf. klappen. Evtl. auch noch xine.modeLiveTV.monitoringDuration auf z. B. 30 oder höher setzen, um den A/V-Versatz über einen längeren Zeitraum zu beobachten, und hoffentlich die Extremstellen zu erwischen. Dies gilt für xine.modeLiveTV.monitoringMode = monitoringOnce. Andernfalls läuft die A/V-Versatz Beobachtung ständig mit und versacht eine etwas höhere CPU-Last.


    Bye.

  • [ANNOUNCE] vdr-xine-0.9.4 plugin

    Hi,


    Quote

    Original von Morone
    ABER ich bin dann kurz vor dem Bildschirm eingepennt ;) und so nach ca.
    2 Stunden war das Dilemma da.
    Kein Audio..

    Code
    vi: (5000,  257, 4742), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  308, 4691), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  280, 4719), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  254, 4745), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  252, 4747), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)
vi: (5000,  250, 4749), ai: (2300,    0, 2300), vo: (30, 13,  0), ao: (32,  0, 32)


    Traxanos hat im Vorfeld vergleichbares berichtet. Er konnte es aber nicht nachvollziehen, und ich selbst habe es noch nie beobachtet. Kannst du ermitteln, was in den 2 Stunden passiert ist?


    Bye.

  • [ANNOUNCE] vdr-xine-0.9.4 plugin

    Hi,


    Quote

    Original von Morone
    So nebenbei seh ich auch nichts vom osddemo


    Vermutlich auf andere OSD-Anzeigeart in vdr-xine's Setup-Menü wechseln. Auch wenn "Überlagern (X11)" das suggeriert ist es derzeit nicht ARGB fähig. Jede andere Einstellung passt.


    Quote

    Original von Morone
    Und: erster mit Tonaussetzern ;)


    Leider hat es der neue Buffer-Algorithmus nicht mehr in 0.9.4 geschafft, da VDR-1.7.17 etwas zu früh kam. Bis jetzt waren die Tonaussetzer immer darin begründet, dass zu kleine Input-Buffer auf Seiten von .xine/config und/oder vdr-xine eingestellt waren.


    Bitte mal beiliegenden Patch einbauen. Die Ausgabe sieht dann z. B. so aus:


    Die Angaben bedeuten:
    vi: video input (zu dekodierende Daten)
    ai: audio input (zu dekodierende Daten)
    vo: video output (anzuzeigende Bilder)
    ao: audio output (auszugebende Audioframes)


    Und in Klammen:
    1.) konfigurierte bzw. mögliche Bufferanzahl
    2.) Anzahl gefüllte Buffer (warten auf Dekodierung bzw. Anzeige)
    3.) Freie Buffer (könnten noch mit Daten gefüllt werden, um noch größere Latenzen zu überbrücken)


    Zu Audioaussetzern kommt es, wenn von ao der mittlere Wert "über längere Zeit" 0 ist. Bildruckler gibt es, wenn gleiches bei vo auftritt.


    Die vi/ai Puffer müssen in .xine/config so erhöht werden, dass es noch freie Buffer gibt (rechter Wert > 0). Dann müssen in vdr-xine die Video- und Audio-Puffer so eingestellt werden, dass bei vo und ao der mittlere Wert > 0 bleibt.


    Aus einem außergewöhnlichen Fall kann ich sagen, dass Audio-Puffer in vdr-xine auf 16 bis 24 erhöht werden mussten, um obige Anforderung zu erfüllen. Danach kam es zu keinen Tonaussetzern mehr.


    Der neue Algorithmus soll sich zukünftig über zu kleine Input-Buffer beschweren und solange Puffern, bis die mittleren Angaben bei vo/ao stabil über 0 bleiben.


    Bye.

  • [patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

    Hi,


    leider muss ich eingestehen, an der Problematik eine gewisse Mitschuld zu haben, da ich bisher eine commit-Berechtigung im xine-lib Repository abgelehnt habe. Der Weg der Patches über die Mailingliste ist für mich am einfachsten und sollte dazu führen, dass sich die entsprechenden Commiter das nochmals ansehen, bevor es offiziell wird. Leider bindet dieses Vorgehen auch Resourcen der Commiter, und wenn die gerade keine Zeit haben, dann geistert über längere Zeit ein ganzer Schwung Patches rum.


    Die commit-Berechtigung habe ich auch abgelehnt, da ich mich zur Zeit mit mercurial (wie auch mit cvs, svn, git, ...) nicht genügend auskenne, um ein Repository richtig zu führen. Und xine-lib ist mir dafür als Spielwiese zu heikel.


    Aktuell bin ich noch der Meinung, dass ich die wenige Zeit, die mir für dieses Hobby bleibt, besser ins Codieren stecke.


    Bye.

  • [patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

    Hi,


    Quote

    Original von Razorblade


    Könnte die evtl jemand ins git auf vdr-developer.org einpflegen?


    Nur der zweitgenannte Patch ist für VDPAU insofern relevant, weil nur damit beim Spulen automatisch der Deinterlacer abgeschaltet werden kann, wenn der entsprechende input_vdr.c Patch eingebaut ist.


    Erstgenannter Patch fixt das lange bekannte Problem, dass xine-lib's ffmpeg mpeg2 Dekoder nicht mit vdr-xine konnte. Das ganze ist ggf. zukünftig für vaapi Unterstützung über xine-lib via ffmpeg relevant.


    Quote

    Original von Razorblade
    rnissl: Das xine-plugin 0.9.3 ist ja schon etwas in die Jahre gekommen und es schwirren einige Patches durch die Gegend. Wäre es denkbar für das xine-plugin auch ein git (entweder auf vdr-developer.org oder was immer Du präferierst) mit den aktuellen Patches abzulegen?


    Bis auf die kleinen Anpassugen an VDR-1.7.11 und 12 (oder war es 10 und 12) hat sich sonst von mir auch nix getan. Ansonsten ist mir nur ein Patch bekannt, der an den Repackern schraubt, damit auch neuerere Audioformate unterstützt werden. Der soll nun in 0.9.4 einfließen, dass vermutlich nach 1.7.17 veröffentlicht wird.


    Leider geht's mit der vdr-xine Entwicklung nicht so bombig voran, wie ich mir das vorgestellt hatte, da ich anscheinend lieber die Probleme anderer mit der xine-lib fixe.


    Bye.

  • [patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

    Hi,


    Quote

    Original von iNOB
    rnissl
    Du hast eine PM.


    Kann in der Aufnahme auch ohne Reindex nix Böses erkennen, außer dass die I-Frames zu kurz übermittelt werden, weil vermutlich das Ende des I-Frames im PES-Paket enthalten ist, in dem auch der nächste Frame beginnt. Das zeigt sich daran, dass rechts unten Makroblöcke fehlen, an denen dann ein früheres Bild durchscheint. Man sieht sich wieder in die Zeiten vor 1.3.18 und ohne cVideoRepacker zurückversetzt.


    Mit den ganzen Patches für vdr-xine und xine-lib wird der Deinterlacer beim Spulen automatisch deaktiviert. Folglich können bei schnellen Bewegungen im I-Frame extreme Kammartefakte sichtbar werden. Evtl. ist es das was du mir damit sagen wolltest.


    Bye.

  • [patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

    Hi,

    Quote

    Original von iNOB
    Muss gerade feststellen, dass mit den letzten hier genannten Änderungen, sich Aufnahmen auf Nick/Comedy (The IT-Crowd) nicht mit Bildaktualisierung Spulen oder Schneiden (Schnittmarken verschieben) lassen. Eventuell hängt das mit dem von mir schon hier berichteten Problem zusammen, dass allerdings damals hiermit gelöst wurde. Kann das mal jemand gegenchecken?


    Konnte es mit

    Code
    NICK / Comedy Österreich;MTV Networks:12226:HC34M2O0S0:S19.2E:27500:513=2:661=deu@4:577:0:28640:1:1091:0
NICK/COMEDY;MTV Networks Europe:11973:VC34M2O0S0:S19.2E:27500:4101+8190=2:4102=deu@4:4104:0:28680:1:1078:0

    nicht reproduzieren. Allerdings ist der Index nicht perfekt, da die I-Frames nicht vollständig sind. In der letzten Zeile fehlen unten rechts mehrere Makroblöcke.


    Bye.

  • [patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

    Hi,



    Schalte mal das Deinterlacing ab (i in xine-ui), dann wird offensichtlich, dass nur das erste Field der Frames übertragen wird. Das zweite Field bleibt in Hintergrundfrabe, d. h. jede zweite Zeile ist schwarz.


    Ich habe kls informiert, dass mit gepatchtem VDR-1.7.16 dieses Problem in der index-Datei besteht. Er wird wohl versuchen, eine Frameerkennung hinzubekommen, die eine Mischung aus altem und neuem Verhalten ist. Die ohne Patch erzeugte index-Datei zeigt dieses Verhalten nämlich nicht, führt aber zu Klötzchen bei ZDF-HD Aufnahmen.


    Bye.

  • [patches] xine-lib-1.2+xineliboutput+xine-plugin verbesserter vdr support

    Hi,


    Quote

    Original von jrie
    Seitdem ich die ganzen Patche von Reinhard drin hab, wird (nur) manchmal das Bild beim Schnittmarken verschieben nicht mehr aktualisiert.


    Das liegt wohl daran, dass VDR-1.7.x die Framegrenzen von I-Frames nicht sauber erkennt. Mir ist sowas bei einer MTV Germany (SD) Aufnahme aufgefallen -- hab's aber noch nicht weiter untersucht.


    Bye.

  • h264 / xine-lib und "Klötzchenbildung"

    Hi,


    Quote

    Original von rnissl


    Das Problem ist lange bekannt und zecks Lösung bin ich mit julian schon seit einem Jahr auf der Suche nach Zeit. Ich hoffe, dass es in den nächsten 4 Wochen endlich klappt.


    Nachtrag: VDR-1.7.x hat zum Teil noch Probleme, die Framegrenzen richtig zu erkennen. Bei MTV Germany SD-Aufnahmen zeigt nicht jede Markenverschiebung ein Bild -- wollte das später mal analysieren.


    hab' die H.264 StillImage Geschichte nun doch selbst fixen können. xine-lib patches sind auf der xine-devel mailing liste.


    Bye.