You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Friday, September 26th 2008, 6:53pm

[patch] SDTV/HDTV video mode switching für das vdr-xinliboutput-plugin

Dieser Patch für das vdr-xineliboutput-Plugin ist als Ergänzung zu folgenden Thema gedacht:
[patches} Korrekte interlaced und framesynchrone Ausgabe für SDTV/HDTV auf VGA/DVI/HDMI

Der Patch erweitert (vorerst nur) den vdr-sxfe Player mit der Funktion den video mode "on the fly" passend zum Format des video stream umzuschalten.
Das heisst das passend zum SDTV bzw. HDTV-Stream der video mode zwischen 576i, 720p und 1080i umgeschaltet wird.
Dazu nutzt es die XRANDR-Erweiterung des X-Server die natürlich von dem entsprechenden xorg Treiber unterstützt werden muss.
Zur Zeit gibt es nur eine feste Zuordnung zwischen stream format und video mode:

Source code

1
2
3
4
video stream height                  video mode
< 720                                2880|2160|1440|720x576@50i
< 1080                              1280x720p
> = 1080                           1920x1080@50i

Bei < 720 haben die Modes mit grösserer horizontalen Auflösung vorang.
Die 1440x576@50i werden insbesondere bei DVI/HDMI Verbindungen benötigt.

Der Patch fügt weiterhin eine neue Option hinzu mit der man den Regelbereich des "live sync mode" bestimmen kann.
Die derzeitigen tuning Schritte von 0.5% und 1.0% sind viel zu gross für den frame rate control patch.
Praktikabel sind Werte von 0.02% - 0.03%. Das entspricht dann input.xvdr.scr_tuning_step = 200 ... 300

Deweiteren gibt es eine neue command line Option mit der man die Anzahl der PES buffer setzen kann. Diese sind im vdr-sxfe bisher fix auf 250 eingestellt. Mit dem Wert 1000 läuft HDTV bei mir besser.

Der Patch basiert auf dem aktuellen cvs Stand des Plugin (v1.0.2).
Alle Optionen sind in der README-Datei beschrieben.

Viel Spass beim ausprobieren.
durchflieger has attached the following file:
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

This post has been edited 2 times, last edit by "durchflieger" (Sep 26th 2008, 7:05pm)


2

Friday, September 26th 2008, 8:59pm

RE: [patch] SDTV/HDTV video mode switching für das vdr-xinliboutput-plugin

Hallo,

was passiert mit dem OSD dabei?

Gruß,
Hendrik
yavdr 0.5 auf M3N78-EM, Cine S2

3

Friday, September 26th 2008, 9:38pm

RE: [patch] SDTV/HDTV video mode switching für das vdr-xinliboutput-plugin

Quoted

Original von henfri
Hallo,

was passiert mit dem OSD dabei?

Gruß,
Hendrik


Passt sich entsprechend an. Das HUD OSD ist aber noch nicht berücksichtigt.
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


4

Friday, September 26th 2008, 9:43pm

RE: [patch] SDTV/HDTV video mode switching für das vdr-xinliboutput-plugin

Hallo,

was bedeutet das? Das OSD hat dann weiter eine Auflösung von 720x560 (oder etwas drunter) und wird einfach "aufgepumpt"?

Wäre das beim HUD OSD anders?

Gruß,
Hendrik
yavdr 0.5 auf M3N78-EM, Cine S2

5

Friday, September 26th 2008, 9:53pm

RE: [patch] SDTV/HDTV video mode switching für das vdr-xinliboutput-plugin

Quoted

Original von henfri
Hallo,

was bedeutet das? Das OSD hat dann weiter eine Auflösung von 720x560 (oder etwas drunter) und wird einfach "aufgepumpt"?

Wäre das beim HUD OSD anders?

Gruß,
Hendrik


Also das OSD sollte sich weiterhin so wie gewohnt verhalten wie als ob man das Plugin bereits mit der jeweiligen video Auflösung starten würde. Änderungen der window size werden also an die bisherige OSD-Logig weitergereicht.
Dementsprechend skaliert das OSD dann.
Zum HUD OSD kann ich noch nichts sagen da ich es bisher links liegen gelassen habe. Am besten du probierst es einfach mal aus.
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


6

Friday, September 26th 2008, 10:20pm

RE: [patch] SDTV/HDTV video mode switching für das vdr-xinliboutput-plugin

genau die idee kam mir gestern beim tv schauen ...

genial .. werd ich mal testen .. danke aber schon mal ..

gruesse mentox
VDR Server: 1,8 core2 Duo, 3x TT-S3200, Gentoo, VDR 1.7.22
VDR Client 1: Zotac ION, Gentoo, streamdev, VDR 1.7.22
VDR Client 2: Nvidia 9500GT, Gentoo aktuell yavdr (zum Testen), streamdev, VDR 1.7.22
VDR Client 3: Nvidia GT220 passiv, Gentoo, streamdev, VDR 1.7.28

7

Friday, September 26th 2008, 11:32pm

xineliboutput configuration

Hier mal die wichtigen xineliboutput Einstellungen aus der setup.conf des VDR:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
xineliboutput.Advanced.LiveModeSync = 1
xineliboutput.Decoder.PesBuffers = 1000
xineliboutput.DisplayAspect = automatic
xineliboutput.Frontend = sxfe
xineliboutput.Fullscreen = 1
xineliboutput.OSD.AlphaCorrection = 0
xineliboutput.OSD.AlphaCorrectionAbs = 0
xineliboutput.OSD.Blending = 0
xineliboutput.OSD.BlendingLowRes = 0
xineliboutput.OSD.DvbSubtitles = 0
xineliboutput.OSD.ExtSubSize = -1
xineliboutput.OSD.LayersVisible = 4
xineliboutput.OSD.Scaling = 2
xineliboutput.Post.denoise3d.Enable = 0
xineliboutput.Post.pp.Enable = 0
xineliboutput.Post.unsharp.Enable = 0
xineliboutput.Video.AspectRatio = 0
xineliboutput.Video.AutoCrop = 0
xineliboutput.Video.Decoder.H264 = automatic
xineliboutput.Video.Decoder.H264.SkipLoopFilter = all
xineliboutput.Video.Decoder.H264.SpeedOverAccuracy = yes
xineliboutput.Video.Decoder.MPEG2 = libmpeg2
xineliboutput.Video.Deinterlace = none
xineliboutput.Video.Driver = xv
xineliboutput.Video.FieldOrder = 0
xineliboutput.Video.Overscan = 0
xineliboutput.Video.Scale = 0
xineliboutput.Video.SwScale = 0


und hier einige wichtige Einstellungen in der Datei config_xineliboutput:

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# Use unscaled OSD
# bool, default: 0
#gui.osd_use_unscaled:0


# video display method preference
# { Any  Overlay  Textured Video }, default: 0
#video.device.xv_preferred_method:Any

# disable exact alpha blending of overlays
# bool, default: 0
#video.output.disable_exact_alphablend:0

# disable all video scaling
# bool, default: 0
#video.output.disable_scaling:0

# Choose speed over specification compliance
# bool, default: 0
video.processing.ffmpeg_choose_speed_over_accuracy:1

# MPEG-4 postprocessing quality
# [0..6], default: 3
video.processing.ffmpeg_pp_quality:0

# Skip loop filter
# { default  none  nonref  bidir  nonkey  all }, default: 0
video.processing.ffmpeg_skip_loop_filter:all

# FFmpeg video decoding thread count
# numeric, default: 1
video.processing.ffmpeg_thread_count:2

# Fast (low-quality) OSD scaling
# bool, default: 0
#input.xvdr.fast_osd_scaling:0

# SRC tuning step
# numeric, default: 5000
input.xvdr.scr_tuning_step:300


# number of audio buffers
# numeric, default: 230
engine.buffers.audio_num_buffers:8

# number of video buffers
# numeric, default: 500
engine.buffers.video_num_buffers:1000

# default number of video frames
# numeric, default: 15
#engine.buffers.video_num_frames:15

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

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

# memcopy method used by xine
# { probe  libc  kernel  mmx  mmxext  sse }, default: 0
engine.performance.memcpy_method:sse


Start des vdr-sxfe mit folgenden Optionen:

Source code

1
vdr-sxfe --buffers=1000 --fullscreen --modeswitching --aspect=default
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV

This post has been edited 1 times, last edit by "durchflieger" (Sep 27th 2008, 10:29am)


Posts: 3,006

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

8

Saturday, September 27th 2008, 7:47am

Super Idee! :tup

Das sollte Petri gleich upstream integrieren. Ich glaube demnaechst ist bei mir eine neues Display faellig, sonst kann ich's nicht testen:)

9

Tuesday, September 30th 2008, 10:14am

:moin,

...klasse Idee, ich hatte mich schon gefragt wie man das Dilemma um die Bildschirmauflösung bei SDTV & HDTV lösen soll ohne skalieren zu müssen :applaus

Allerdings habe ich (noch!) keinen HD-TV und keines meiner Displays unterstützt @50i Auflösungen am VGA oder DVI. Wie wäre es, wenn man die Display modes (beinahe) beliebig zuordnen könnte?! Dann wäre man eben nicht nur auf TVs beschränkt.

Danke & Gruß, ollo

10

Tuesday, September 30th 2008, 10:40am

Quoted

Original von ollo
:moin,

...klasse Idee, ich hatte mich schon gefragt wie man das Dilemma um die Bildschirmauflösung bei SDTV & HDTV lösen soll ohne skalieren zu müssen :applaus

Allerdings habe ich (noch!) keinen HD-TV und keines meiner Displays unterstützt @50i Auflösungen am VGA oder DVI. Wie wäre es, wenn man die Display modes (beinahe) beliebig zuordnen könnte?! Dann wäre man eben nicht nur auf TVs beschränkt.

Danke & Gruß, ollo


Die Frage ist hier was es einem dann noch bringt. Das reine skalieren geht ja bereits per Hardware in der Graphikkarte und der Qualitätsunterschied zum TV ist wahrscheinlich nur marginal.

Gruss durchflieger
Server: Asus M3N-H/HDMI, AMD X2 5600+, 4GB RAM, 500GB+1,5TB Samsung HD, 2xTevii S470, 1xTT-S3200, Ubuntu/V12.04, vdr 1.7.27
Client1: ZOTAC ION-ITX B, 2GB RAM, Diskless/Netboot per PXE, Xubuntu/V12.04, vdr 1.7.27+softhddevice, XBMC V12.1, LG42LC2R LCD-TV
Client2: Wie 1 aber ZOTAC ION-ITX E , DFAtmo, 2xDF10CH 19 Kanal Atmolight, LG37LC2R LCD-TV


Posts: 3,006

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

11

Tuesday, September 30th 2008, 10:44am

Quoted

Originally posted by ollo
Allerdings habe ich (noch!) keinen HD-TV und keines meiner Displays unterstützt @50i Auflösungen am VGA oder DVI.


wie gesagt, die Idee ist super.

Ich wuerde mir deswegen und natuerlich wegen [patches} Korrekte interlaced und framesynchrone Ausgabe für SDTV/HDTV auf VGA/DVI/HDMI/RGB/SCART sogar ein neues DIsplay zulegen.

Aber welche der aktuell verfuegbaren Displays (!= TV-Roehren) unterstuetzen ueberhaupt @50 nativ (bzw. zumindest mit akzeptabler Qualitaet) am VGA/ DVI/ HDMI?

Diese grundsaetzliche Frage muesste sich doch allen Anwendern dieser Schnittstellen stellen.

Der sinnvolle Einsatz des Mod aus DVI/HDMI-Ausgänge für FF-Karten und T-Online S100 haengt schliesslich ebenfalls davon ab.

Gibt es irgendwo eine halbwegs aktuelle Liste von entsprechenden Geraeten?

Es kommt nicht so sehr darauf an *ob* @50i und 50@p Timings ueberhaupt unterstuetzt werden. Sondern in welcher Qualitaet.

Mein Sharp LCD LC-26GA3E unterstuetzt durchaus manche @50i und 50@p Timings. Auch wenn sie nicht ausdruecklich genannt sind. Das Geraet arbeitet jedoch intern mit 60Hz (synchronisiert natuerlich nicht mit 50Hz) und die Wiedergabequalitaet (Bildschaerfe) ist dabei obendrein unter ferner liefen.

12

Tuesday, September 30th 2008, 11:16am

Hi,

@sparkie:

...also mein Samsung 42S5H zeigt über HDMI 1080i@50Hz ein super Bild und die Laufschriften bei n-tv und Konsorten sind scharf und ohne Ruckler.
(das allerdings mit einem kommerziellen HD-Receiver - habe eure Entwicklungen über Graka noch nicht getestet)

Grüße
Funzt

Posts: 3,006

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

13

Tuesday, September 30th 2008, 11:37am

Hi Funzt

Quoted

zeigt über HDMI 1080i@50Hz ein super Bild und die Laufschriften bei n-tv und Konsorten sind scharf und ohne Ruckler.


danke fuer die Info! Schon mal gut zu wissen, dass es jetzt solche Geraete gibt. Dann hat sich in diesem Bereich in der Zwischenzeit wohl doch was getan.
Mit diesem Thema muss ich mich demnaechst etwas genauer auseinandersetzen:)

- sparkie

14

Tuesday, September 30th 2008, 1:08pm

Hi sparkie,

... ist schon klar das es hier um den Anschluß an einen TV geht der dann die Bildaufbereitung übernimmt. Zum Probieren solange man keinen TV mit DVI oder HDMI hat, wäre es halt schön.

@Funzt - Dein 42S5H ist doch ein Plasma-TV, der sollte das natürlich können, oder?

Testet die c't nicht manchmal Displays mit TV timings?

[Edit] Impliziert HDMI eigentlich 576i, 720p & 1080i Support?[/Edit]

Gruß, ollo

This post has been edited 1 times, last edit by "ollo" (Sep 30th 2008, 4:23pm)


15

Tuesday, September 30th 2008, 6:02pm

Hi,

@ollo:

...na ja - intern arbeitet der wohl auch mit 60Hz, aber das deinterlacing ist gut und wir wollen doch das Display (TV) deinterlacen lassen, oder habe ich da was falsch verstanden?

Grüße
Funzt

Posts: 3,006

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

16

Wednesday, October 1st 2008, 11:27am

Hi ollo,

Quoted

Originally posted by ollo

[Edit] Impliziert HDMI eigentlich 576i, 720p & 1080i Support?[/Edit]

wie ich gerade sehe hat TEN sich hier schon mal mit der Sache beschaeftigt.

siehe auch:

Quoted

Originally posted by real_schorsch
...Allerdings schlucken nicht wirklich viele Displays 576i über HDMI. Die meisten Samsungs können es zum Beispiel schon mal nicht...


- sparkie

This post has been edited 2 times, last edit by "sparkie" (Oct 1st 2008, 11:34am)


17

Wednesday, October 1st 2008, 12:47pm

vielen Dank durchflieger + sparkie!

Der Patch läuft prima - damit ist der OSD auch bei 720p wieder in passender Grösse. Bitte an Petri weiterleiten!
MSI P6NGM-FD | ASROCK A785GXH | Grafik: GeForce 9400GT| DVB-S2 Karten: Twinhan VP 1041 & Skystar HD

Posts: 3,006

Location: a child of the universe

Occupation: duct tape programmer

  • Send private message

18

Wednesday, October 1st 2008, 12:50pm

Quoted

Originally posted by Lou
vielen Dank durchflieger + sparkie!

Der Patch läuft prima - damit ist der OSD auch bei 720p wieder in passender Grösse. Bitte an Petri weiterleiten!


das freut mich Lou! :tup

der 'video mode switching' Patch ist aber alleine die Idee und Realisierung von 'durchflieger'.

Da bin ich nur dankbarer Tester:)

dortje

Intermediate

Posts: 195

Location: /dev/random

  • Send private message

19

Wednesday, October 1st 2008, 1:25pm

Zu der Formatfrage: meiner Meinung nach ist 576i und 576p über HDMI durchaus im Standart festgelegt, das sind ja auch die Auflösungen, in denen die meisten billig Receiver mit HDMI asugeben. Und zwar mit 50Hz. Wer einen sehr guten LCD-TV sucht, dem kann ich den Panasonic LZD85F empfehlen. Der macht ein hervorragendes Upscaling von PAL Auflösung und ein sehr gutes Deinterlacing. (Full-)HD Auflösungen sind natürlich auch kein Thema. Was das ruckeln von Schrift betrifft kann ich hier nur sagen, die 100Hz Technik geift hier optimal.

Edit: Informationen zu HDMI und Auflösungen

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
1 640x480p @ 60Hz No Repetition
2,3 720x480p @ 59.94/60Hz No Repetition
4 1280x720p @ 59.94/60Hz No Repetition
5 1920x1080i @ 59.94/60Hz No Repetition
6,7 720(1440)x480i @ 59.94/60Hz Pixel sent 2 times
8,9 720(1440)x240p @ 59.94/60Hz Pixel sent 2 times
10,11 2880x480i @ 59.94/60Hz Pixel sent 1 to 10 times
12,13 2880x240p @ 59.94/60Hz Pixel sent 1 to 10 times
14,15 1440x480p @ 59.94/60Hz Pixel sent 1 to 2 times
16 1920x1080p @ 59.94/60Hz No Repetition
17,18 720x576p @ 50Hz No Repetition
19 1280x720p @ 50Hz No Repetition
20 1920x1080i @ 50Hz No Repetition
21,22 720(1440)x576i @ 50Hz Pixel sent 2 times
23,24 720(1440)x288p @ 50Hz Pixel sent 2 times
25,26 2880x576i @ 50Hz Pixel sent 1 to 10 times
27,28 2880x288 @ 50Hz Pixel sent 1 to 10 times
29,30 1440x576p @ 50Hz Pixel sent 1 to 2 times
31 1920x1080p @ 50Hz No Repetition
32 1920x1080p @ 23.97/24Hz No Repetition
33 1920x1080p @ 25Hz No Repetition
34 1920x1080p @ 29.97/30Hz No Repetition
35,36 2880x480p @ 59.94/60Hz Pixel sent 1, 2 or 4 times
37,38 2880x576p @ 50Hz Pixel sent 1, 2 or 4 times
39 1920x1080i (1250 total) @ 50Hz No Repetition
40 1920x1080i @ 100Hz No Repetition
41 1280x720p @ 100Hz No Repetition
42,43 720x576p @ 100Hz No Repetition
44,45 720(1440)x576i @ 100Hz Pixel sent 2 times
46 1920x1080i @ 119.88/120Hz No Repetition
47 1280x720p @ 119.88/120Hz No Repetition
48,49 720x480p @ 119.88/120Hz No Repetition
50,51 720(1440)x480i @ 119.88/120Hz Pixel sent 2 times
52,53 720X576p @ 200Hz No Repetition
54,55 720(1440)x576i @ 200Hz Pixel sent 2 times
56,57 720x480p @ 239.76/240Hz No Repetition
58,59 720(1440)x480i @ 239.76/240Hz Pixel sent 2 times


Quelle: http://www.hdmi.org/pdf/HDMISpecInformationalVersion.pdf
Activy 300 / Sparkle PCI / VDPAU

This post has been edited 1 times, last edit by "dortje" (Oct 1st 2008, 1:33pm)


swer

Professional

Posts: 647

Location: Petershagen

  • Send private message

20

Tuesday, December 30th 2008, 4:45pm

ich versuche gerade den Patch auf xinelibout-1.0.3 anzuwenden, doch habe ich dabei so meine Probleme.

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
patching file Makefile 
Hunk #3 succeeded at 255 with fuzz 2 (offset -2 lines).
Hunk #4 succeeded at 279 (offset -2 lines). 
Hunk #5 succeeded at 321 (offset -2 lines). 
patching file xine_frontend_main.c 
Hunk #1 succeeded at 298 (offset 8 lines). 
Hunk #2 succeeded at 308 (offset 8 lines). 
Hunk #3 succeeded at 339 (offset 8 lines). 
Hunk #4 succeeded at 370 (offset 8 lines). 
Hunk #5 succeeded at 447 (offset 10 lines). 
Hunk #6 succeeded at 474 (offset 10 lines). 
Hunk #7 FAILED at 629. 
Hunk #8 succeeded at 629 (offset 11 lines). 
1 out of 8 hunks FAILED -- saving rejects to file xine_frontend_main.c.rej
 patching file xine_input_vdr.c 
Hunk #1 succeeded at 220 (offset -11 lines).
Hunk #2 succeeded at 627 (offset -13 lines). 
Hunk #3 succeeded at 833 (offset -13 lines).
Hunk #4 succeeded at 847 (offset -13 lines). 
Hunk #5 succeeded at 4222 (offset 83 lines). 
Hunk #6 FAILED at 5125. 
Hunk #7 succeeded at 6389 (offset -160 lines). 
Hunk #8 succeeded at 6601 (offset -144 lines). 
1 out of 8 hunks FAILED -- saving rejects to file xine_input_vdr.c.rej 
patching file xineliboutput.c patching file xine_sxfe_frontend.c 
Hunk #1 succeeded at 45 with fuzz 2 (offset -2 lines). 
Hunk #2 FAILED at 187. 
Hunk #3 succeeded at 216 (offset 14 lines). 
Hunk #4 succeeded at 1146 (offset -199 lines). 
Hunk #5 succeeded at 1239 with fuzz 2 (offset -146 lines). 
Hunk #6 FAILED at 1270. 
Hunk #7 FAILED at 1479. 
Hunk #8 succeeded at 1720 (offset -183 lines). 
3 out of 8 hunks FAILED -- saving rejects to file xine_sxfe_frontend.c.rej


Hat das schon jemand angepasst. Die rejects aus xine_frontend_main.c und xine_input_vdr.c ich wahrscheinlich nachpflegen (ich habe keinen schimmer was ich da mache). Doch bei xine_sxfe_frontend.c finde ich leider keine der Stellen oder sie sehen derart anders aus das ich bezweifle das leicht zu ändern.