[ANNOUNCE] Xine Plugin 0.7.3

Tach,

auch beim Reinhard hat sich wieder was getan. Es gibt nämlich ne neue Version des Xine-Plugins.

Die Änderung im einzelnen lt. Changelog:

Zitat

Hi,

I'm pleased to announce release 0.7.3:

http://home.vr-web.de/~rnissl/vdr-xine-0.7.3.tgz

2005-04-11: Version 0.7.3

- Started detection of AFD header in xine to automatically crop out the
interesting part of the image later.
- Adopted implementation of cXineDevice::SetDigitialAudioDevice() to
different calling order in VDR 1.3.23.
- Improved cXineDevice::SetDigitalAudioDevice() when replaying
recordings.
- Added setup option to automatically make vdr-xine the primary device
while xine is connected to vdr-xine (requested by Der_Olli at
vdr-portal).
- Added setup option to consider all semi transparent colors as opaque
to make the menu more readable.
- Added commandline option '-s' to switch to skin 'curses' while xine is
not connected to vdr-xine (requested by Rantanen Teemu).
- Added commandline option '-q' to suppress debug messages (useful in
combination with option '-s').
- Moved disconnect to cXineDevice::Stop() to get the new options to
work.
- Fixed all (?) deadlock situations in RPC command processing (e. g.
stopping replay while switching a channel).
- Fixed deadlocks in vdr-xine's xread(). A possible drawback is that now
a disconnect might happen in such a case.
- Fixed VDR's I-frame processing which caused disconnects e. g. while
moving cut marks in HDTV recordings. vdr-1.2.23-dvbplayer3.patch is
highly recommended for proper operation of vdr-xine.
- Improved cXineDevice::StillImage() implementation to immediate display
the frame (improves moving cut marks).
- Fixed cXineDevice::StillImage() to work properly in combination with
the plugin vdr-radio.
BUG: xine's driver xxmc shows just a black screen on my EPIA
MII-6000E.
- Reintroduced usleeps() in input_vdr.c for flush, OSD flush and reset
audio. sched_yield() simply caused to much CPU load while waiting
about 40 ms to reach the expected state. Improves number of dropped
frames when switching channels.
- Optimized OSD display: VDR's channel display repeatedly sends a dirty
OSD which doesn't differ from the previous one. Improves number of
dropped frames while switching channel.
BUG: it's still unclear whether this causes some OSD artefacts.
- Fixed demux_mpeg_pes' discontinuity detection. Previously, when a PTS
wrap happend, xine stopped replay for about 26.5 hours.
- vdr-xine now nolonger set's xine's metronom directly but tells it's
demuxer to do the job. Improves switching channels.
- Optimized implementation of cXineDevice::Clear() in input_vdr.c.
BUG: it may happen that xine's audio driver ALSA might get into a
state of "silence" where it doesn't recover from until you stop
replaying the recording. I still didn't find a way to reproduce this
but it has to do with trickspeed, pause, play, and probably cut marks.
- Fixed post_vdr.c to detect MRL changes for discovering streams sent
from VDR, e. g. when xine is not started with the MRL specified on
it's command line.
BUG: It's possible that xine crashes due to this detection. xine
doesn't allocate a different stream for a different MRL, but maybe
other players do. I'm not sure whether I managed to increase the
streams usage counter properly (by allocating an event queue) until I
detect the new stream respectively MRL.
BUG: post_vdr doesn't operate when xine's driver xxmc is used due to
some limitation/incomplete implementation in xine's plugin interface.
- Fixed xine's deinterlacer interface to take care of cropping.
Previously the OSD was resizing like mad e. g. between 1920x1080 and
1920x1088.
- Added support for VDR's new AUDIO key in xine (thanks to Darren Salt
for reporting this issue).

For this release I suggest the following xine sources:

http://home.vr-web.de/~rnissl/…vs-20050411203000.tar.bz2
http://home.vr-web.de/~rnissl/…vs-20050411203000.tar.bz2

Highly recommended is the following patch:

http://home.vr-web.de/~rnissl/vdr-1.3.23-dvbplayer3.patch
http://home.vr-web.de/~rnissl/vdr-1.2.6-dvbplayer3.patch (soon)

Alles anzeigen

Ahja, dann hammer ja wieder was zu installieren

Aber erst morgen und damit...

Gut's Nächtle !

Olaf

Tach,

sonst hat es immer einwandfrei geklappt, aber nach langer Zeit erhalte ich beim Durchjagen durch den gcc einen Fehler...

Zitat

LE_OFFSET_BITS=64 -DXINE_COMPILE -Wnested-externs -Wcast-align -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -c video_out_opengl.c -MT video_out_opengl.lo -MD -MP -MF .deps/video_out_opengl.TPlo -o .libs/video_out_opengl.o
video_out_opengl.c:86: error: conflicting types for `glXGetProcAddressARB'
/usr/X11R6/include/GL/glx.h:180: error: previous declaration of `glXGetProcAddressARB'
make[4]: *** [video_out_opengl.lo] Error 1
make[4]: Leaving directory `/usr/local/src/xine-lib/src/video_out'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/usr/local/src/xine-lib/src/video_out'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/src/xine-lib/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/xine-lib'
make: *** [all] Error 2

Alles anzeigen

Was läuft da schief ?

Greets Olaf

Thanks a lot.

This was the precise reason for the failure of the gcc compiler. Later I assumed something with the opengl-driver and glx and probably nvidia was going wrong, but I couldn't definitely assert what exactly was responsible for the error messages above.

So thanks again for your message with the problem-solving hint !

Greets Olaf

P.S.: Das war exakt die Medizin, die der Blechkopf brauchte :-))

Tach,

ich hab zu der neueren CVS-Version von Xine noch eine Frage, okay, die hat jetzt nichts direkt mit dem Plugin an sich zu tun, aber mich würde es schon interessieren.

Egal, was für Einstellungen ich da wie auch immer wo verwende, beim Abspielen von mpegs bspw. habe ich gerade bei schnellen Kameraschwenks rauf/runter oder rechts/links gerade bei Filmsequenzen mit hellem bzw. höherem Lichtanteil ein sichtbares Flackern des Bildes. Wenn man ne statische Kameraeinstellung hat (bspw. den Moderator der Tagesschau) fällt einem da nichts auf.

Die gleiche mpeg-Datei bspw. mit dem MPlayer abgespult fördert keine derartigen Anomalien zutage. Hier bleibt das Bild auch bei heftigsten Kameraschwenks brillant und flicker-flackerfrei. Also am Rechner kanns ja selber schon nicht liegen. An der Graka eigentlich auch nicht (okay, ne FX5200 Nvidia mit NV34 Chipset und knapp 1200 Frames mit glxgears ist nu wirklich nicht der Brüller), aber da Mplayer die gleiche Datei ja augenfreundlich abspult, muss es irgendwas mit Xine selber zu tun haben.

Was kann man da machen ? Mit disable-opengl kompilieren, oder gibbet sonst noch irgendwelche mysteriösen Tricks, die nur Leute kennen, die die READMEs und MANPAGES bei jeder neuen Version auswendig lernen :-)))

Anders gefragt...hat der ein oder andere Mitstreiter hier gleiche Phänomene beobachten können ???

Greets Olaf

Tach,

so, ich hab jetzt mal die XV-Unterstützung reingehauen. Mal beim configure nochmal mitgelesen und festgestellt, dass ich doch blöderweise den Path für die libXv nicht mit angegeben hatte bzw. der nicht automatisch gefunden wurde.

Jetzt läufts eigentlich wieder so flüssig, wie ich es von früher her kenne. Trotzdem kann ich mir diese Meldungen jetzt so gar nicht erklären...

Zitat

xiTK WARNING(xitk_set_widget_tips_and_timeout:1932): widget is NULL
xiTK WARNING(xitk_set_widget_tips_and_timeout:1932): widget is NULL
bad_frame
bad_frame

Auswirkungen auf Bild und Ton gibt's jedoch keiner und es funktioniert alles. Trotzdem muss das ja was bedeuten bzw. heissen. Fehlermeldungen sind ja immer so ne Sache. Manche kann man vergessen, andere wie (Will you really cancel dev/hda: ?) sollte man schon beachten...:-)

Greets Olaf

Tach,

also danke euch beiden für die Antworten.

andihobby Komplimente zu meinen Filmen höre ich ja immer gerne. Ich muss wirklich mal die drei offenen endlich bald bei Gelegenheit irgendwann ins Feld werfen.

@peter_weber69 Na, dann ist ja alles klar, war mir nur net sicher, obs an mir oder an anderer Stelle lag. Dann bin ich ja beruhigt. Vielleicht ist ja dann mit der nächsten CVS wieder alles im Lack

Greets Olaf

Tach,

da diese Netzwerkgeschichte eh irgendwann mit in das Xine-Plugin wohl einfliessen wird und ich immo eh keinen Laptop habe, ist das nicht wirklich so schlimm...

Viel schlimmer ist, dass derjenige, der mal Xine und Muggle gleichzeitig verwenden will, gleich ein furchtbares Krachen auf die Ohren bekommt, weil via Muggle abgenudelte Soundfiles genau diese Geräusche beim Abspielversuch mit Xine erzeugen.

Allerdings nur bis heute, denn ab sofort gibt es auch dafür eine Medizin. Reinhard war Alpha-Programmierer und ich war Beta-Tester und habs für gut befunden und gebe es mit (c) Vermerk Reinhard Nissls und seiner freundlichen Genehmigung frei. Einfach ins Xine-Plugin verzeichnis kopieren und dann "wie immer". Mit Netzwerkversion von Peter allerdings nicht getestet

Wer's braucht... bei mir isser schon drauf !

Greets Olaf