h264 / xine-lib und "Klötzchenbildung"

    danke hotzenplotz
    stable oder testing? oder egal?
    hab naemlich beide probiert. und problem ist noch da. da muss dann wohl was anderes schuld sein. playback von mkv 1080p ueber xinelibplayer geht 1a, aber live bild laeuft nur 5s, dann ist es ein kloetzchenhaufen und ton ist weg mit jeder menge


    Code
    cXinelibServer::Play Buffer overflow (TCP/PIPE)


    aber das ist dann wohl ein anderes problem.


    Code
    ii  libxine1-xvdr                   1.0.6+cvs20100602.1715-2yavdr1                  Xine input plugin for vdr-plugin-xineliboutp
ii  libxine2                        1.2.0~hg20100615-0yavdr1                        the xine video/media player library, binary
ii  libxinerama1                    2:1.1-2                                         X11 Xinerama extension library
ii  vdr-plugin-xine                 0.9.3-8yavdr1                                   Plugin for "software only" playback using xi
ii  vdr-plugin-xineliboutput        1.0.6+cvs20100602.1715-2yavdr1                  VDR plugin for Xine based sofdevice frontend
ii  xine-ui                         0.99.6~cvs-20090930ubuntu1                      the xine video player, user interface
ii  xineliboutput-sxfe              1.0.6+cvs20100602.1715-2yavdr1                  Remote X-Server frontend for vdr-plugin-xine

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300

    2 Mal editiert, zuletzt von izeman ()

    doppelpost

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300

    Einmal editiert, zuletzt von izeman ()

    Zitat

    Originally posted by hotzenplotz5
    entferne mal testing aus der sources.list und mach bei den paketen
    ein aptitude --reinstall


    wenn dann was nicht geht, am besten einen thread im yavdr unterforum


    nur zur info, hab ALLE pakete neu installiert. hat aber nix gebracht. muss wohl wo anders suchen. danke trotzdem

    produktiv: intel dh67bl, sat>ip, octopusnet, 16gig boot-ssd, yavdr 0.6.1, cir lirc
    testing: zotac ion-f itx, 1x tt s2-3600 usb, 8gig boot-ssd, yavdr 0.5 testing
    tv: samsung 75" amp:denon avr-x1300

    Hallo,


    hab jetzt nochmal etwas detaillierter getestet.


    xine-lib (inzwischen aktuellster Stand) mit stream-start-patch


    vdr-xine:


    • auch mit der ältesten 720p-Aufnahme, die ich hier habe (vom Januar 2010), wird beim Verschieben der Schnittmarken das Bild aktualisiert
    • bei 1080i-Aufnahmen habe ich allerdings - wie grappi - auch keine Aktualisierung des Bildes beim Verschieben der Schnittmarken


    xineliboutput (von heute):

    • Aktualisierung des Bildes beim Verschieben der Schnittmarken funzt in allen Aufnahmen, allerdings habe ich mit xineliboutput das Problem des *Nachlaufs* nach Beenden des schnellen Vorlaufs...


    Gruß
    Tomas

    Zitat

    Original von tomas

    • auch mit der ältesten 720p-Aufnahme, die ich hier habe (vom Januar 2010), wird beim Verschieben der Schnittmarken das Bild aktualisiert


    Hi,


    habe jetzt mal bei den paar alten 720p Aufnahmen mit vdr jeweils eine neue index Datei erstellt. Jetzt funktioniert das Aktualisieren des Bildes auch bei diesen Aufnahmen.


    Für die 1080i Aufnahmen habe ich leider noch keine Lösung gefunden.
    Bin aber auch nicht der Experte, um in den Quellcodes irgendwelche Veränderungen vorzunehmen. Das überlasse ich lieber den Profis, die hier dankenswerterweise ihre Vorschläge und Lösungen mit uns teilen.


    grappi

    Wohnzimmer-VDR: Hardware: ASRock Mainboard M3N78D; AMD 240e CPU; Zotac GeForce GT220 passiv; Mystique Dual SaTiX-S2; TT-DVB-S2 3200 Software: VDR-2.0.0; softhddevice (aktuelle git) ; NVIDIA-Treiber 313.26

    Ich habe festgestellt, dass nun zwar das Ruckeln und Kötzchenbildung bei HD erheblich besser geworden ist, bzw. fast gar nicht mehr zu bemerken ist, dafür aber ruckeln nun Bild und Ton bei den "very-low Quality" Kanälen ganz erheblich. (mpeg2 Sender)


    Hier mal ein Log dazu wenn auf einen o.g. Sender geschaltet wird:


    Ich habe mich jetzt nicht durch die ganzen sourcen gewühlt aber bist du dir sicher das es am Patch liegt? Frag nur da der Patch zwei Dateien ändert.
    h264_parser.c und vdpau_h264.c
    Denke nicht dass das Einfluss auf mpeg2 Sender hat.

    HD-VDR:
    HW: ZOTAC D2550-ITX | Mystique SaTiX-S2 Sky Xpress DUAL
    SW: Debian Stretch | vdr-2.3.8

    Hallo,


    Zitat

    [...]
    fixing sound card drift by 3200 pts
    [...]



    hast du in deiner ~/.xine/config



    Gruß
    Tomas

    Zitat

    Original von oberlon
    Ich habe mich jetzt nicht durch die ganzen sourcen gewühlt aber bist du dir sicher das es am Patch liegt? Frag nur da der Patch zwei Dateien ändert.
    h264_parser.c und vdpau_h264.c
    Denke nicht dass das Einfluss auf mpeg2 Sender hat.


    Nein, muss nicht mit dem Patch zusammenhängen.


    @ tomas


    Meine Configs sehen so aus:


    Für das xine Plugin:



    Für xineliboutput:


    dann nimm auf jeden Fall für vdr-xine in der /root/.xine/config


    das *audio.synchronization.av_sync_method:resample*


    rein, mit *metronom* (default) hab ich auch teilweise die *fixing sound sound card drifts*, mit resample gibts bei mir keine Probs

    Hallo,


    Zitat

    Original von C-3PO
    dafür aber ruckeln nun Bild und Ton bei den "very-low Quality" Kanälen ganz erheblich. (mpeg2 Sender)


    Wie hier schon erwähnt ist das sehr unwahrscheinlich (eigentlich unmöglich) dass das allein mit dem Patch zusammenhängt. Ich denke das war auch vorher so, und ähnliches hab ich auch schon festgestellt.
    Ich hab hier in xineliboutput (demux_xvdr.c) vor einiger Zeit wegen ähnlichem was eingebaut und folgenden Kommentar dazu gemacht

    Code
    static char last_wrap = 0;	// some streams have permanently a big diff A/V-PTS, or A-PTS > 0x40400000
									// (e.g. TV-Channels "TAQUILLA", "PORTADA"...)


    Das betrifft zwar jetzt nicht Deinen Fall, aber falls mal jemand auf diesen Kanälen testen mag - auf dem ersten sollte ein Standbild (mit Ton!) sein, auf dem so ein durchlaufender Streifen ist. Sorry, bessere Beschreibung fällt mir grad nicht ein, aber Ton und ein bewegtes Bild muss vorhanden sein, im syslog sollte das glaube ich auch zu sehen sein wenn nicht.
    Bei manchen "billig-Sendern" lag das aber noch an etwas anderem, ging glaube ich aber in die selbe Richtung (unterschieldliche video/audio-pts). Sag mal welche Sender das sind.


    Der Thread hier ist ja nicht der richtige dafür, aber welcher? Wie ich das festgetsellt habe, sind die Probleme bei diesen Kanälen schon recht speziell, also Fehler, die zwar ungefähr gleiche Auswirkungen wie andere Bild/Ton-Probleme haben, aber halt die Ursachen grundsätzlich doch etwas unterschiedlich...


    Gruss
    Thomas

    Thx @ tbshl-vdr,


    Natülich liegt es nicht an Deinem Patch. :) Ich will auch nicht unbedingt diesen Thread "hijacken".


    Aber wie Du schon selbst gesagt hast:


    Zitat

    Der Thread hier ist ja nicht der richtige dafür, aber welcher? ...


    Aufgefallen ist es mir z.B. die Theme-X auf Hotbird.


    Es gab da auch mal in der Mailinglist etwas dazu:


    http://www.mail-archive.com/vdr@linuxtv.org/msg11983.html


    Allerdings verstehe ich zu wenig davon. :(

    tbshl-vdr


    wie es ausieht, wird mit deinem Patch die aktuelle progressive frame Erkennung bei Nutzung von vdpau ausgehebelt. Lt. Konsolenausgabe wird auch für die "720p Sender" wie "Das Erste HD" und "ZDF HD" der für HD eingestellte Deinterlacer verwendet, was natürlich nicht sein muss. Ohne Patch funktioniert die Erkennung und es wird bei diesen Sendern kein Deinterlacer verwendet.


    Kannst du daran noch was drehen?


    Gruß
    Holger

    Hi,


    Zitat

    Original von tbshl-vdr
    Mit welcher xine-lib denn, oder schon immer (hab auf dem Test-Rechner momentan nur ohne den Patch)?


    ob "schon immer" kann ich leider nicht sagen. Vermutlich erst, seitdem die Erkennung in der xine-lib überarbeitet wurde. Ich kann's hier mit unserer Version "1.2.0~hg20100615" reproduzieren.


    Gruß
    Holger

    Ich glaub, das muss ich morgen nochmal näher untersuchen.
    Kann sein dass hier noch anderes nicht passt, aber ich habe ohne den Patch mit der Version vom 13.06. das auch, und dazu noch


    vo_vdpau: enable noise reduction.
    vo_vdpau: enable sharpness.


    bei HD, das sollte ja nun auch nicht sein. Deswegen war hier auch schonmal was, kann ich mich dunkel erinnern...
    Ist das mit 'noise reduction' und 'sharpness' bei Dir auch so?


    Ach ja, meinst Du mit Erkennung, dass auf Konsole keine "progressive: x" Ausgabe erfolgt? Die hab ich nur auskommentiert da das bei jedem Frame ausgegeben wird und etwas störte.

    Hi,


    hmmm... evtl. habe ich mich wirklich von der Konsolenausgabe in die Irre führen lassen. In erster Linie das hier beim Beenden auf einem 720p Sender:


    Das ist aber bei den 1080i Sender genau so und in der Tat kommt beim Umschalten auf einen 720p Sender folgendes:



    ... und das ist ohne Patch. Scheint also so-oder-so nicht zu funktionieren. Sorry für die Verwirrung!


    Ansonsten:

    Code
    vo_vdpau: disable noise reduction.
vo_vdpau: disable sharpness.


    das kann ich also vorerst nicht bestätigen. Ich habe allerdings auch die "sd_only_properties" nicht explizit gesetzt.


    Gruß
    Holger

    Zitat

    Original von HolgerRIn erster Linie das hier beim Beenden auf einem 720p Sender:


    Code
    progressive: 1
vdpau_set_property: property=0, value=0
vo_vdpau: deinterlace: none


    Da wird dann von ausserhalb gesetzt (vdpau_set_property), woher/warum weiss ich jetzt nicht (neuer Stream...).


    Zitat

    Original von HolgerR
    Das ist aber bei den 1080i Sender genau so und in der Tat kommt beim Umschalten auf einen 720p Sender folgendes:



    Hmm, also eigentlich müsste "vo_vdpau: deinterlace:" auch ohne vorheriges "vdpau_set_property" kommen (sozusagen von intern, wenn sich beim Anzeigen das Frame-Format geändert hat), tut es bei mir zwar auch, allerdings auch mit deinterlacer != none.


    Zitat

    Original von HolgerR
    Sorry für die Verwirrung!


    Naja, das ist ja auch verwirrend ;)


    Zitat

    Original von HolgerR
    Ich habe allerdings auch die "sd_only_properties" nicht explizit gesetzt.


    Das sollte eigentlich auch obsolete sein, wie erwähnt meine ich es ging hier auch schon mal darum und war mit einer neueren xine-lib erledigt, aber genau weiss ich es momentan nicht...

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden