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

Ich hab nun einfach auf xine umgestellt. Scheint auch meine Probleme beim Wechseln der Audiospuren zu beseitigen. Hab zwar keinen Medienplayer mehr, aber
mplayer und XBMC tuns erstmal. Wenn es wieder Entwicklungen bei der xineliboutput gibt, wechsel ich auch gerne zurück. Momentan scheint der Wechsel zu xine
erstmal mehr Probleme zu lösen, als die Anzahl der Features, die ich dann vermisse.

Ich hab den Changeset gefunden, nur leider bringt uns der nicht wirklich weiter.
Aber davon mal ab, ich hab es gerade mit SD getestet da funktioniert es auch nicht. Der "alter" wird ja aber nur bei h264 genutzt.

Man konnte doch irgendwo die Priorität ändern um ohne großen Aufwand den normalen Decoder anstatt den "alter" zu nutzen. Kann mir jemand auf die Sprünge helfen wo das war?

Edit: Habs gefunden, decoder Prio in der config_xineliboutput. Bei HD gehts auch mit dem normalen, bei SD nicht.

Edit 2: Fix für SD
In xine_input_vdr.c Zeile 4783 die Kommentarzeichen um die Zeile entfernen.

buf->content[12] = (uint8_t)((10*90) >> 7);

Bei HD wird das Bild aber gar nicht erst angezeigt, tippe da jetzt wieder auf den "alter" Decoder.

Hi,

Zitat von TheChief

Außerdem gibts beim mplayer-Plugin kein OSD

Ich habe mit xine-plugin ein OSD vom mplayer, das reicht doch aus.

Wobei ich auch wieder zu xineliboutput gewechselt habe, wegen der Audio Probleme die das xine-plugin bei mir hat, trotz drehen an den Einstellungen.
Mit den aktuellen Änderungen läuft xineliboutput "problemloser" , vor allem auch deshalb weil ich auf Schneiden und Spulen weniger Wert lege.

Zitat von Maniac

Man konnte doch irgendwo die Priorität ändern um ohne großen Aufwand den normalen Decoder anstatt den "alter" zu nutzen. Kann mir jemand auf die Sprünge helfen wo das war?

Diese Frage habe ich mir auch schon gestellt, in der config des xine-plugins gibt es , wie du schon sagst die decoder Prio Einstellungen , leider wirken sich Änderungen die ich mache bei mir nicht aus.
Ich nehme nicht an, das man diese Einstellungen in den Sourcen "Hardcoden" muss.

mfg

Zumindest einen teilweise Erfolg konnte ich bei HD Still Picture verbuchen. Es funktioniert meistens, aber noch ohne Deinterlacing.

Dazu in der alterh264_decoder.c bei Zeile 1417 diesen Block auskommentieren

/*if ( wrong_field ) {
fprintf(stderr, "vdpau_h264_alter : Wrong field, skipping.\n");
memset( cur_pic, 0 , sizeof(dpb_frame_t ) );
dpb_reset( &decoder->sequence );
cur_pic->missing_header = 1;
decoder->sequence.startup_frame = 0;
return;
}*/

thomasd, maniac:

Die beiden Fixes für "FastForward" und "SD Stillpicture" sind ja sehr nett, funktionieren hier gut. Danke dafür!

Der HD-Fix verbessert das Schneiden von HD-Aufnahmen (ÖR) bei mir etwas (bei %30 Prozent der Framesprünge gibts aber immer noch keinen Bildwechsel)

Grüße, Peter

Im Xineliboutpt-Repository hat sich ja in den letzten Tagen wieder einiges getan, hat dies evtl. eine positive Auswirkung auf die zuletzt noch vorhandenen Probleme, hat das mal jemand ausprobiert?

Ich kann leider erst in ca. 2 Wochen anfangen zu testen, da ich die entsprechende Hardware noch nicht habe.

CafeDelMar

Ich hab auf der ML gerade das hier entdeckt. Ist ein Fix für den Absturz wenn PTS zurückgesetzt wird beim vdpau_alter http://sourceforge.net/mailarc…ssage.php?msg_id=27671171

Ich kann beim besten Willen keinen Unterschied zur ungepatchten Variante feststellen. Die sporadisch auftretenden, kurzen Bildhänger (Ton läuft dabei weiter) verschwinden bei mir damit nicht...

Gruß
iNOB

Das dürfte auch nur recht selten mal aufgetreten sein. Das "Problem" ist wohl wenn sich der PTS (Presentation Timestamp) zurücksetzt. Das tritt eigentlich nur bei DVB-Streams (evtl. auch Aufnahmen auf).
Anhand des PTS bekommt der Decoder gesagt wann er welchen Frame darstellen soll. Prinzipbedingt muss er bei DVB-Streams irgendwann zurückgesetzt werden. Da hats dann den vdpau_alter ohne Patch wohl rausgehauen. Durch den Patch gibt es jetzt einen Workaround damit das nicht mehr passiert.

hallo,

Zitat von iNOB

Ich kann beim besten Willen keinen Unterschied zur ungepatchten Variante feststellen. Die sporadisch auftretenden, kurzen Bildhänger (Ton läuft dabei weiter) verschwinden bei mir damit nicht...

das kann ich so direkt bestätigen .. allerdings nur bei HD :o/

gruß, ciax

Nochmal kurz die frage, was nimmt man denn derzeit für nen Zweig?

df-xine-lib-extensions+alter-vdpau-h264-decoder
df-osd-handling+alter-vdpau-h264-decoder

Was ist der Unterschied?

Funktioniert eigentlich derzeit das aktualisieren des Mirrors der xine-lib auf vdr-developer.org? Im hg bei Debian hat sich da ja irgendwas geändert und das letzte Update der xine-lib auf vdr-developer war am 17.05.

Zitat von durchflieger

df-osd-handling+alter-vdpau-h264-decoder hat zusätzlich ein überarbeitetes osd handling im vdpau treiber.

Danke für die Info.

Rein aus Interesse: Woher kommen eigentlich die vielen Warnungen beim Kompilieren? Ist die xine-lib nicht sauber programmiert?

Hi *,

ich habe grade (unabhängig von dem letzten patch, Danke fürs Übernehmen durchflieger!) eine interessante Entdeckung gemacht: Bei mir ändert sich das Systemverhalten (speziell bezüglich des unbefriedigenden Verhaltens beim Verschieben von HD-cutmarks) deutlich, wenn ich die Verbindung von vdr-sxfe (lokal) über udp (/usr/bin/vdr-sxfe --display=:0 "xvdr+udp://127.0.0.1:37890 ...) statt über tcp herstelle.

Mit udp funktioniert das Verschieben der HD-cutmarks (ÖR) bei mir gefühlt bei jedem möglichen frame. Bei tcp geschätzt nur ca. alle 2 -3 Sekunden. Leider ergeben sich mit udp andere Probleme, so gibts dann bei HD beim Zurückschalten von fastforward starke Pixelfragmente, ausserdem dauert das Starten von HD-Aufnahmen deutlich länger.

Ist also nicht die Lösung, aber mich wundert dass das Netzwerkprotokoll überhaupt eine Auswirkung an diesen Stellen hat.

durchflieger: Was mich bei Dir als "Wissendem", der laut Sig auch xineliboutput verwendet interessieren würde: Hast Du eigentlich auch die allseits bekannten noch vorhandenen Probleme mit xineliboutput?

Grüße, Peter

Zitat

df-osd-handling+alter-vdpau-h264-decoder hat zusätzlich ein überarbeitetes osd handling im vdpau treiber.

Nur noch mal für mich zum Verständnis: Zusätzlich heisst genau genommen, dass hinter dem df-osd-handling-alter-vdpau-h264-decoder dem Grunde nach folgendes steckt?!:

df-xine-lib-extensions+osd-handling+alter-vdpau-h264-decoder

Gruss
Marcus