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

Oh man, wieder falsch geklickt, Sorry

Zitat

Original von gda

Das ist auch nicht ganz richtig, das wird, zumindest im ungepatchten vdr-sxfe, im code gleich wieder,
nach dem Setzen des Defaults von 500, fest mit 250 über gebügelt.

Gerald

Hmmm... jetzt, wo du es sagst: Du hattest ja schon mal sowas geschrieben. Jetzt erinnere ich mich. Ich war tatsächlich immer davon ausgegangen dass das, was in der "config_xineliboutput" steht, auch anwendung findet. :schiel. Woran sieht man, dass das nicht so ist? Verboselevel bei Konsolenaufruf erhöhen?

Ich verwende jetzt den Patch aus diesem Thread, übergebe aber nicht den "--buffers" Parameter. Wie viele Buffer verwende ich denn nun wirklich?

Gruß
Holger

Zitat

Original von HolgerR
Hmmm... jetzt, wo du es sagst: Du hattest ja schon mal sowas geschrieben. Jetzt erinnere ich mich. Ich war tatsächlich immer davon ausgegangen dass das, was in der "config_xineliboutput" steht, auch anwendung findet. :schiel. Woran sieht man, dass das nicht so ist? Verboselevel bei Konsolenaufruf erhöhen?

Ich habe mir den Code angesehen, ich glaube nicht, dass das irgendwo ausgegeben wird.

Zitat

Original von HolgerR
Ich verwende jetzt den Patch aus diesem Thread, übergebe aber nicht den "--buffers" Parameter. Wie viele Buffer verwende ich denn nun wirklich?

Der Default ist auch mit dem neuen Code 250.

Gerald

Zitat

Original von HolgerR
Hmmm... jetzt, wo du es sagst: Du hattest ja schon mal sowas geschrieben. Jetzt erinnere ich mich. Ich war tatsächlich immer davon ausgegangen dass das, was in der "config_xineliboutput" steht, auch anwendung findet. schiel . Woran sieht man, dass das nicht so ist? Verboselevel bei Konsolenaufruf erhöhen?

Die aktiven Einstellungen sollten beim regulären Beenden von vdr-sxfe eigentlich nach config_xineliboutput zurückgeschrieben werden. Ist vielleicht eine Methode, das zu überprüfen.

Matthias

Zitat

Original von Rincewind99

Die aktiven Einstellungen sollten beim regulären Beenden von vdr-sxfe eigentlich nach config_xineliboutput zurückgeschrieben werden. Ist vielleicht eine Methode, das zu überprüfen.

Matthias

Hmmm... da steht ja aber immer das drin, was man per --buffers übergibt, bzw. es bleibt der Wert drin stehen, denn man bei gestopptem vdr-sxfe selbst eingetragen hat. Daran kann ich also leider nicht ablesen, was offenbar tatsächlich verwendet wird.

gerald
Mal 'ne blöde Frage: Wenn's nirgends ausgegeben wird: Woher hast du denn dann die Info mit den 250 Videopuffern?

Gruß
Holger

Zitat

Original von HolgerR

Mal 'ne blöde Frage: Wenn's nirgends ausgegeben wird: Woher hast du denn dann die Info mit den 250 Videopuffern?

Na weil es einfach im Code drin stand. Die Code-Zeile hatte ich doch auch gepostet, ich weiß aber nicht mehr in welchem Thread.

Gerald

Zitat

Original von HolgerR
Hmmm... da steht ja aber immer das drin, was man per --buffers übergibt, bzw. es bleibt der Wert drin stehen, denn man bei gestopptem vdr-sxfe selbst eingetragen hat. Daran kann ich also leider nicht ablesen, was offenbar tatsächlich verwendet wird.

Doch kannst du - weil config_xineliboutput nicht von vdr-sxfe sondern von xine-lib geschrieben wird. Wenn der Wert von --buffers in config_xineliboutput landet, hat vdr-sxfe den garantiert an xine-lib übergeben.

Zitat

Original von Rincewind99
Doch kannst du - weil config_xineliboutput nicht von vdr-sxfe sondern von xine-lib geschrieben wird. Wenn der Wert von --buffers in config_xineliboutput landet, hat vdr-sxfe den garantiert an xine-lib übergeben.

Das sehe ich genauso, deshalb hatte ich ja mit der alten Version immer wieder 250 drin stehen, egal was ich vorher rein geschrieben habe.

Gerald

Zitat

Original von gda

Das sehe ich genauso, deshalb hatte ich ja mit der alten Version immer wieder 250 drin stehen, egal was ich vorher rein geschrieben habe.

Gerald

... und genau an der Stelle kann ich dem ganzen eben auch nicht wirklich folgen. Kann es sein, dass das ganze was mit zu tun hat, dass du die xine-lib 1.2 und den separaten Patch verwendest? Bei mir (mit xine-vdpau) war es schon immer so, dass das, was ich in die config eingetragen habe, auch dort stehen blieb?!?

Gruß
Holger

Zitat

Original von HolgerR

... und genau an der Stelle kann ich dem ganzen eben auch nicht wirklich folgen. Kann es sein, dass das ganze was mit zu tun hat, dass du die xine-lib 1.2 und den separaten Patch verwendest? Bei mir (mit xine-vdpau) war es schon immer so, dass das, was ich in die config eingetragen habe, auch dort stehen blieb?!?

Die entsprechende Code-Zeile steht aber in xineliboutput und nicht in der xine-lib

Übrigens gilt das nur für vdr-sxfe, das gilt nicht für --local=sxfe

Gerald

Zitat

Original von gda

Die entsprechende Code-Zeile steht aber in xineliboutput und nicht in der xine-lib

Übrigens gilt das nur für vdr-sxfe, das gilt nicht für --local=sxfe

Gerald

Alles anzeigen

Du machst mich ganz wuschig.

Ist ja eigentlich auch wurscht. Positive Effekte mit erhöhtem Buffer kann ich ebenso wie Durchflieger eh' nicht erkennen... scheinbar reichen die 250 locker aus.

Gruß
Holger

ich benutze xinelib 1.2 aus dem gentoo berkano overlay mit vdpau.

wenn ich versuche xineliboutput1.0.4 mit xineliboutput-1.0.4-vdpau-support-v3.diff

zu kompillieren kriege ich folgendes:

gcc -g xine_sxfe_frontend_standalone.o xine/post.o tools/vdrdiscovery_standalone.o -L/usr/X11R6/lib -lX11 -lXv -lXext -lXrender -lm -ljpeg -lxine   -o vdr-sxfe
xine_sxfe_frontend_standalone.o: In function `init_dummy_ports':
/vdr177/PLUGINS/src/xineliboutput-1.0.4/xine_frontend.c:797: undefined reference to `_x_ao_new_port'
xine_sxfe_frontend_standalone.o: In function `fe_xine_init':
/vdr177/PLUGINS/src/xineliboutput-1.0.4/xine_frontend.c:623: undefined reference to `_x_ao_new_port'
collect2: ld returned 1 exit status
make: *** [vdr-sxfe] Error 1

woran liegts?

Zitat

Original von nemster
ich benutze xinelib 1.2 aus dem gentoo berkano overlay mit vdpau.

wenn ich versuche xineliboutput1.0.4 mit xineliboutput-1.0.4-vdpau-support-v3.diff

zu kompillieren kriege ich folgendes:

Code

gcc -g xine_sxfe_frontend_standalone.o xine/post.o tools/vdrdiscovery_standalone.o -L/usr/X11R6/lib -lX11 -lXv -lXext -lXrender -lm -ljpeg -lxine   -o vdr-sxfe
xine_sxfe_frontend_standalone.o: In function `init_dummy_ports':
/vdr177/PLUGINS/src/xineliboutput-1.0.4/xine_frontend.c:797: undefined reference to `_x_ao_new_port'
xine_sxfe_frontend_standalone.o: In function `fe_xine_init':
/vdr177/PLUGINS/src/xineliboutput-1.0.4/xine_frontend.c:623: undefined reference to `_x_ao_new_port'
collect2: ld returned 1 exit status
make: *** [vdr-sxfe] Error 1

woran liegts?

Alles anzeigen

Hallo,

hast Du die xine-lib auch mit dem Patch aus dem Thread hier gepatched?

Gruss Marcus

patch klappt super mit xineliboutput 1.0.4 (det) und r261 von xinelib!

vielen vielen dank für deine mühen!

hi markus,

ja, ich habe das ebuild editiert und den patch hinzugefuegt.
(als media-libs/xine-lib-1.2.9999_p262 )
lustigerweise ist in den installierten header files nachher:

version.h:#define XINE_MAJOR_VERSION 1
version.h:#define XINE_MINOR_VERSION 1
version.h:#define XINE_SUB_VERSION   90
version.h:#define XINE_VERSION       "1.1.90hg"

wenn ich die sourcen von
http://hg.debian.org/hg/xine-lib/xine-lib-1.2
mit xine-vdpau-xine-lib-1.2-r262-crop-v2.diff patch verwende gibts das hier:

ake[1]: Entering directory `/appz/xine-lib-1.2/misc'
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I.. -I../include -I../include -I../src -I../src/xine-engine -I../src/xine-engine -I../src/xine-utils  -I../src/input -I../src/input  -I../lib -I../lib  -DNDEBUG -D_REENTRANT -DXINE_COMPILE      -pipe  -Wall -Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute -Werror-implicit-function-declaration -Wstrict-aliasing=2 -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wpointer-arith -g  -Wall -Wchar-subscripts -Wnested-externs -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wmissing-format-attribute -Wno-pointer-sign -Wformat=2 -Wno-format-zero-length -Wstrict-aliasing=2 -Werror=implicit-function-declaration -MT xine-list.o -MD -MP -MF ".deps/xine-list.Tpo" -c -o xine-list.o xine-list.c; \
	then mv -f ".deps/xine-list.Tpo" ".deps/xine-list.Po"; else rm -f ".deps/xine-list.Tpo"; exit 1; fi
cc1: error: unrecognized command line option "-Werror=implicit-function-declaration"
make[1]: *** [xine-list.o] Error 1
make[1]: Leaving directory `/appz/xine-lib-1.2/misc'
make: *** [all-recursive] Error 1

Zitat

Original von wbreu
Aber ich habe da immer wieder einen segfault:

Der kommt immer häufig dann wenn gecroppt wurde und man dann auf einen anderen Sender schaltet.

Habe auch einen Segfault bei obiger Vorgehensweise mit den crop-Patches beim Umschalten, allerdings folgendes BT:

#0  0xb64c2d36 in autocrop_overlay_add_event (this_gen=0x8651c08, event_gen=0xb219dbf8) at xine_post_autocrop.c:1571
1571                caps = port->stream->video_out->get_capabilities (port->stream->video_out);
(gdb) bt
#0  0xb64c2d36 in autocrop_overlay_add_event (this_gen=0x8651c08, event_gen=0xb219dbf8) at xine_post_autocrop.c:1571
#1  0xb29ff062 in exec_osd_command (this=0x864d350, cmd=0xb21b3312) at xine_input_vdr.c:2257
#2  0xb29ff6e5 in vdr_plugin_exec_osd_command (this_gen=0x864d350, cmd=0xb21b3312) at xine_input_vdr.c:2344
#3  0xb2a03a30 in vdr_plugin_parse_control (this_gen=0x864d350, cmd=0xb21b33fc "OSDCMD") at xine_input_vdr.c:3252
#4  0xb2a0c00b in vdr_control_thread (this_gen=0x864d350) at xine_input_vdr.c:3995
#5  0xb7d404c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#6  0xb7e346de in clone () from /lib/i686/cmov/libc.so.6

Treiber: NVidia 185.18.14
Config:

xineliboutput.Video.AutoCrop = 1
xineliboutput.Video.AutoCrop.AnalysisRate = 10
xineliboutput.Video.AutoCrop.AutoDetect = 1
xineliboutput.Video.AutoCrop.BarToneTolerance = 8
xineliboutput.Video.AutoCrop.DetectSubs = 1
xineliboutput.Video.AutoCrop.DetectSubsLifetime = 1500
xineliboutput.Video.AutoCrop.FixedSize = 1
xineliboutput.Video.AutoCrop.LogoWidth = 20
xineliboutput.Video.AutoCrop.Overscan = 3
xineliboutput.Video.AutoCrop.SoftStart = 1
xineliboutput.Video.AutoCrop.SoftStartStep = 4
xineliboutput.Video.AutoCrop.StabilizeTime = 125

Gruss
Marcus

Zitat

Original von nemster
hi markus,

ja, ich habe das ebuild editiert und den patch hinzugefuegt.
(als media-libs/xine-lib-1.2.9999_p262 )
lustigerweise ist in den installierten header files nachher:

Code

version.h:#define XINE_MAJOR_VERSION 1
version.h:#define XINE_MINOR_VERSION 1
version.h:#define XINE_SUB_VERSION   90
version.h:#define XINE_VERSION       "1.1.90hg"

wenn ich die sourcen von
http://hg.debian.org/hg/xine-lib/xine-lib-1.2
mit xine-vdpau-xine-lib-1.2-r262-crop-v2.diff patch verwende gibts das hier:

Code

ake[1]: Entering directory `/appz/xine-lib-1.2/misc'
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -I.. -I../include -I../include -I../src -I../src/xine-engine -I../src/xine-engine -I../src/xine-utils  -I../src/input -I../src/input  -I../lib -I../lib  -DNDEBUG -D_REENTRANT -DXINE_COMPILE      -pipe  -Wall -Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute -Werror-implicit-function-declaration -Wstrict-aliasing=2 -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wpointer-arith -g  -Wall -Wchar-subscripts -Wnested-externs -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wmissing-format-attribute -Wno-pointer-sign -Wformat=2 -Wno-format-zero-length -Wstrict-aliasing=2 -Werror=implicit-function-declaration -MT xine-list.o -MD -MP -MF ".deps/xine-list.Tpo" -c -o xine-list.o xine-list.c; \
	then mv -f ".deps/xine-list.Tpo" ".deps/xine-list.Po"; else rm -f ".deps/xine-list.Tpo"; exit 1; fi
cc1: error: unrecognized command line option "-Werror=implicit-function-declaration"
make[1]: *** [xine-list.o] Error 1
make[1]: Leaving directory `/appz/xine-lib-1.2/misc'
make: *** [all-recursive] Error 1

Alles anzeigen

welche gcc version hast du installiert?
ich meine bei mir auch probleme gehabt zu haben, nachdem ich aber auf gcc 4.3 umgestiegen bin, hatte ich keine Probleme mehr.

das wars, danke marcus.

jetzt ist nur noch das osd zu klein, die bilder voellig verpixeld (blöcke) und hd kanaele gehen gar nicht.

irgendwie lief das schon mal besser vorgestern

never touch a running system