 Perfektes PAL-Bild mit Softdevice
|
pacemaker
Tripel-Ass
Dabei seit:
07.05.2004
Beiträge: 194
 | |
| Zitat: |
Original von
Wicky
...jetzt bin ich aber verwirrt, da
man bei einem RöhrenTV kein Deinterlacing
benötigt. 
|
Theoretisch
nicht (zumindest bei 50/60 Hz TV's). Aber genau
das ist ja das ursprüngliche Problem von
jarny.
Theoretisch müsste die Wiedergabe
von 50Hz-Material über die Grafikkarte an den TV
perfekt erfolgen, da eigentlich kein Deinterlacing
nötig ist. D.h. es werden immer abwechseln die
beiden Halbbilder ausgegeben. Dadurch sollte es
weder Kammartefakte, noch Ruckeln oder sonstwas
geben.
Wie wir alle wissen, ist es aber
nicht so. Meiner Meinung nach ist die Erklärung
ganz einfach:
Das Problem wird vermutlich
sein, die Zeilen der Halbbilder durch irgendwelche
Skalierungen, oder Ähnliches nicht sauber
voneinander getrennt sind, also irgendwie
miteinander vermischt.
Dazu reicht jas
schon, daß die ausgegebene Auflösung nicht genau
der PAL-Aufläsung entspricht. Sobald auch nur eine
Zeile vom Halbbild 1 und Halbbild 2 rutscht, ist
alles durcheinander. Eigentlich muss man 'nur'
dafür sorgen, daß jedes von MPEG decodierte
Halbbild auch 1:1 an den TV ausgegeben wird, was
aber anscheinend nicht der Fall
ist.
Gruß,
pacemaker
| |
 05.01.2007 06:36 |
    
| |
jarny
Ritter
Dabei seit:
24.09.2003
Beiträge: 1.143
Themenstarter
| |
| Zitat: |
Original von
pacemaker
| Zitat: |
Original von
Wicky
...jetzt bin ich aber verwirrt, da
man bei einem RöhrenTV kein Deinterlacing
benötigt.
|
Theoretisch
nicht (zumindest bei 50/60 Hz TV's). Aber genau
das ist ja das ursprüngliche Problem von
jarny.
Theoretisch müsste die Wiedergabe
von 50Hz-Material über die Grafikkarte an den TV
perfekt erfolgen, da eigentlich kein
Deinterlacing nötig ist. D.h. es werden immer
abwechseln die beiden Halbbilder ausgegeben.
Dadurch sollte es weder Kammartefakte, noch
Ruckeln oder sonstwas geben.
Wie wir alle
wissen, ist es aber nicht so. Meiner Meinung
nach ist die Erklärung ganz einfach:
Das
Problem wird vermutlich sein, die Zeilen der
Halbbilder durch irgendwelche Skalierungen, oder
Ähnliches nicht sauber voneinander getrennt
sind, also irgendwie miteinander
vermischt.
Dazu reicht jas schon, daß die
ausgegebene Auflösung nicht genau der
PAL-Aufläsung entspricht. Sobald auch nur eine
Zeile vom Halbbild 1 und Halbbild 2 rutscht, ist
alles durcheinander. Eigentlich muss man 'nur'
dafür sorgen, daß jedes von MPEG decodierte
Halbbild auch 1:1 an den TV ausgegeben wird, was
aber anscheinend nicht der Fall
ist.
Gruß,
pacemaker |
Ich
hab extra drauf geachtet, dass er nicht skalieren
muss, damit der oben genannte Effekt (Verrutschen
von Zeilen in ein falsches Halbbild) nicht
passiert. Die wichtige Auflösung in Y-Richtung von
576 Zeilen ist definitiv eingestellt. In
X-Richtung muss er sowieso oftmals skalieren weil
er je nach Sender 704, 720 oder sogar 576 Pixel
hat, was aber nicht unbedingt ein Störfaktor sein
sollte.
Komischerweise habe ich beim Abspielen
von VDR-Aufnahmen mittels MPlayer einen kleinen
Erfolg erzielt indem ich MPlayer mit dem Parameter
'-vf tfields=1' starte. Das Scrolling von
Laufschriften ist dann viel ruhiger, eine richtige
Synchronisation fehlt trotzdem
irgendwie.
Insgesamt bin ich zum Schluss
gekommen, dass das ganze ein mächtiges Gefrickel
ist und nicht wohnzimmertauglich zu sein scheint.
Ich meine damit den Vergleich FF-Karte am
Röhrenfernseher und Budgetkarte+Softdevice am
Röhrenfernseher.
Die Frage ist, was macht der
Mpeg-Encoder auf der FF besser, das man mit
Softwaredekoder+TVOut nicht hinbekommen kann? Ich
kann den TVOut meiner Graka mit ner Auflösung von
720x576@50Hz betreiben,trotzdem ruckelt die
Schrift, obwohl ich ausreichend
Rechenleitstungsreserven habe! Das soll mir mal
jemand technisch erklären 
Gruß
Jarny
__________________
LinVDR 0.7 gepanscht
mit Mahlzeit-ISO (Kernel 2.6.15, VDR 1.4.0-1)
Hardware: TT DVB-S Rev1.3, 900Mhz Athlon,
Samsung-HD 160GB
| |
| 05.01.2007 08:48 |
| |
GTB
Jungspund
Dabei seit:
29.07.2005
Beiträge: 22
Berufung:
Oberdepp
| |
Hi,
Vorallem an Wicky,
Ich habe
gestern noch geschaut, tatsächlich, im xine war
scaling enabled. Nachdem ich es ausgeschalten habe
war das Bild zu groß, d.h. die Ränder waren
abgeschnitten.
Seltsam..
Danach auf den
empfohlenen Treiber von Wicky umgestellt, keine
Veränderung bezgl. der Größe.
ABER: nach
einem Reboot ist die Größe OK. (Das OSD nicht :-)
) Welches OSD verwendest Du, Wicky?
Die
Laufschrift war nicht ganz ganz perfekt, aber
schon viiiiiieeeeel besser (ohne
Deinterlacen).
So und nun noch eine
Vermutung:
Wie sieht es mit aufnahmen von
z.B. ntv aus? Ist dann der Effekt weg? (Ich werde
es heute Abend mal probieren)
Weil:
Die
Grafikkarte hat eine bestimmte vert.
Frequenz,
Das Live Bild auch, und die werden
sich sicher nicht decken, daher ab und zu ein
ruckeln, da ein Bild weggelasasen oder verdoppelt
wird. Ich nehme aber an ein ganzes.
Wird
aber ein File abgespielt, so kann das sehr wohl
mit der GraKa synchronisiert werden.
lg
__________________
stolzer Besitzer
eines M2NPV-VM mit Athlon 3500+ 1GB RAM, 160GByte
Platte Kanotix 2006-01-RC4 PVR350
Airstar2
| |
| 05.01.2007 15:21 |
| |
Wicky
Großherzog
Dabei seit:
03.07.2005
Beiträge: 3.883
Herkunft:
NRW
| |
| Zitat: |
Original von
GTB
Hi,
Vorallem an
Wicky,
Ich habe gestern noch geschaut,
tatsächlich, im xine war scaling enabled.
Nachdem ich es ausgeschalten habe war das Bild
zu groß, d.h. die Ränder waren
abgeschnitten.
Seltsam..
Danach auf den
empfohlenen Treiber von Wicky umgestellt, keine
Veränderung bezgl. der Größe.
ABER: nach
einem Reboot ist die Größe OK. (Das OSD nicht
:-) )
|
...du
meinst XvMC bzw. xxmc bei nvidia, gell ??
Ja,
XvMC ist eine feine Sache, solange man kein
Deinterlacing verwenden muss. 
| Zitat: |
Welches OSD
verwendest Du,
Wicky? |
Die von
dir beschriebenen Probleme haben nichts mit dem
OSD zu tun, sondern mit der Kombination von
xine-ui und xine-liboutput.
Hjt4vdr hat im
Kanotix-Thread gpostet, wie man auch das Problem
des über den rechten Rand hinausragenden OSDs in
den Griff bekommt. Bei der Lösung verwendet man
keine xine-ui mehr. Ich habe es aber selber noch
nicht getestet.
Such mal nach "hjt4vdr AND
xine-ui AND xvmc"
Mich wundert aber, dass
du mit xxmc keine Transparenz Probleme hast
Damit die verschwinden muss man bei
xine-liboutput nämlich negative Transparenz Werte
einstellen.
Wie es konkret geht, hatte ich
auch schoneimal gepostet. Aber das scheinst du ja
eh richtig gemacht zu haben
| Zitat: |
Die
Laufschrift war nicht ganz ganz perfekt, aber
schon viiiiiieeeeel besser (ohne
Deinterlacen). |
...ja
ja, irgendwas läuft dort verkehrt mit xine-ui und
xine-liboutput. Denn mit XvMC klappt es
ja...
| Zitat: |
So und nun
noch eine Vermutung:
Wie sieht es mit
aufnahmen von z.B. ntv aus? Ist dann der Effekt
weg? (Ich werde es heute Abend mal
probieren) |
...dann
teste mal
| Zitat: |
Weil:
Die Grafikkarte hat eine
bestimmte vert. Frequenz,
Das Live Bild auch,
und die werden sich sicher nicht decken, daher
ab und zu ein ruckeln, da ein Bild weggelasasen
oder verdoppelt wird. Ich nehme aber an ein
ganzes. |
...die
Frequenzen für den TV-out kannst du in bestimmten
Grenzen in der xorg.conf
einstellen...
Schau dir auch zusätzlich
nochmal nvidia-settings an. Das Programm kannst du
auf der Konsole mit User-Rechten
starten...
Falls du eine alte Version der
nvidia Treiber hast, dann solltest du sie
eventuell auch mal aktualisieren.
Das geht
sehr gut mit dem h2 Skript. (google sidux h2) Das
h2 Skript macht ein "sicheres" Dist-Upgrade und
stellt auf die Sidux Repositorys um. Hierfür
solltest du dir aber viel Zeit nehmen und die
Texte gründlich lesen. Wenn man mit dem h2 Skript
vertraut ist, dann klappt es damit sehr
schön...
Gruß
Wicky
__________________
Hardware: M2NPV-VM,
AthlonXP-64 3500+, Samsung 300GB,
Airstar2
Software: easyVDR 0.4.2
dxr3-Links: dxr3config, dxr3-Howto , dxr3-Modul-Entwicklerseite, dxr3-Plugin-Entwicklerseite
| |
| 05.01.2007 18:39 |
| |
jarny
Ritter
Dabei seit:
24.09.2003
Beiträge: 1.143
Themenstarter
| |
| Zitat: |
Original von
GTB
So und nun noch eine
Vermutung:
Wie sieht es mit aufnahmen von
z.B. ntv aus? Ist dann der Effekt weg? (Ich
werde es heute Abend mal
probieren)
Weil:
Die Grafikkarte hat eine
bestimmte vert. Frequenz,
Das Live Bild auch,
und die werden sich sicher nicht decken, daher
ab und zu ein ruckeln, da ein Bild weggelasasen
oder verdoppelt wird. Ich nehme aber an ein
ganzes.
Wird aber ein File abgespielt, so
kann das sehr wohl mit der GraKa synchronisiert
werden.
lg |
Hmmm,
da ist natürlich was Wahres dran!
Wenn man
durch die Timingeinstellungen nicht ganz 50Hz auf
der Grafikkarte hinbekommt, sagen wir mal ca.
50,004Hz (Ich glaube diesen Wert hab ich im
NVidia-Treiber lesen können unter Windows), dann
müsste nach 250 Halbbildern ein Halbbild
übersprungen werden. 250 Halbbilder entsprechen
ca. 5 Sekunden. Ich meine auch so einen Effekt
gesehen zu haben. Das Bild war ein paar Sekunden
ok und dann wiederum ein paar Sekunden nicht
ok.
Bei Aufnahmen hat man theoretisch die
Möglichkeit den Film zu verlangsamen um ihn an die
leicht abweichende Bildwiederholfrequenz
anzupassen, das hat man aber bei Live-Tv
nicht.
Der Ausgang der FF arbeitet
wahrscheinlich nicht nach dem Prinzip der
Grafikkarten und kann die Bildwiederholfrequenz
erzeugen wie sie es für richtig hält, also
entsprechend bei Interlaced-PAL-Mpegs mit genau 50
Hz. Durch Double- oder TrippelBuffering werden die
Bilder halt entsprechend lange zurückgehalten.
Darauf ist das ganze Hardwarekonzept der FF
ausgelegt. Grafikkarten können die Synchronisation
nicht korrigieren, sondern benutzen starr die
Treibereinstellungen, die Player für die
Videoausgabe 'wissen' davon nix und könnten die
Frequenz im Treiber eh nicht ständig
nachkorrigieren - da liegt der Hund
begraben.
Unter Windows gibts aber das Tool
'reclock'. Damit kann man angeblich die
Bilderzeugung der Video/Audiocodecs auf die Clock
der Grafikkarte synchronisieren. Ton wird dabei
sogar auch gestreckt/gestaucht damits nach einiger
Zeit keinen Versatz gibt. Ich habs selber noch
nicht probiert aber es soll exakt für diesen
Anwendungsfall programmiert worden sein. Damit
kann man freilich nur Aufnahmen und nicht Live-TV
synchen.
Fazit: Mit dem TV-Out von Grakas
kann man im Prinzip nie saubere gleichmäßige
Bewegungen hinbekommen! Irgendwann sieht man
kleine Sprünge weil die Frequenzen nicht synchron
gehalten werden können.
Gibts dazu noch
andere Meinungen, Erklärungsversuche,
Gegenbeispiele oder Lösungen?
Gruß
Jarny
__________________
LinVDR 0.7 gepanscht
mit Mahlzeit-ISO (Kernel 2.6.15, VDR 1.4.0-1)
Hardware: TT DVB-S Rev1.3, 900Mhz Athlon,
Samsung-HD 160GB
| |
| 05.01.2007 19:33 |
| |
zulu
Ritter
Dabei seit:
29.04.2004
Beiträge: 1.299
| |
Hi,
eventuell eine Erklärung:
| Zitat: |
6. Optimal
settings for tvtime on TV output
Some people
are interested in using tvtime even when their
output itself a television. Usually this is in
the context of setting up a home theatre PC
system. Ideally for television output, no
deinterlacing is required; the interlaced signal
is sent to the output such that every top field
in the input is mapped to a top field in the
output.
Unfortunately, there is no standard
TV output API under Linux. The VESA framebuffer
setup for TV output cannot tell us which field
is currently being displayed. Similarily, some
TV output setups under Linux have it as a second
head in X, but again, with no field information.
We cannot know how to supply it with interlaced
content to ensure that fields are shown in the
right order.
That said, I have been told that
when using the NVIDIA TV output drivers,
supplying them with top-field-first frames will
cause it to display the fields correctly. To
experiment, try tvtime using the Progressive:
Top Field First deinterlacer. Please let me know
if this gives good
results. |
gefunden
bei http://tvtime.sourceforge.net/help.html#tvout
Gruss
Marc
__________________
>>>> x-vdr <<<<
Installations-Skript für einen VDR mit Debian als
Basis
| |
| 05.01.2007 20:05 |
| |
jarny
Ritter
Dabei seit:
24.09.2003
Beiträge: 1.143
Themenstarter
| |
| Zitat: |
Original von
zulu
| Zitat: |
6. Optimal
settings for tvtime on TV output
Some people
are interested in using tvtime even when their
output itself a television. Usually this is in
the context of setting up a home theatre PC
system. Ideally for television output, no
deinterlacing is required; the interlaced signal
is sent to the output such that every top field
in the input is mapped to a top field in the
output.
Unfortunately, there is no standard
TV output API under Linux. The VESA framebuffer
setup for TV output cannot tell us which field
is currently being displayed. Similarily, some
TV output setups under Linux have it as a second
head in X, but again, with no field information.
We cannot know how to supply it with interlaced
content to ensure that fields are shown in the
right
order. | |
Ist
das wirklich wahr? Das hiesse ja, dass unter Linux
keine HomeTheatre-Applikation vernüftigen
TV-Genuss bietet.
Bitte sagt mir, dass das
nicht wahr ist!!
Gruß
Jarny
__________________
LinVDR 0.7 gepanscht
mit Mahlzeit-ISO (Kernel 2.6.15, VDR 1.4.0-1)
Hardware: TT DVB-S Rev1.3, 900Mhz Athlon,
Samsung-HD 160GB
| |
| 07.01.2007 20:17 |
| |
GTB
Jungspund
Dabei seit:
29.07.2005
Beiträge: 22
Berufung:
Oberdepp
| |
Hallo,
Vorerst entschuldige ich mich für
das späte melden, aber am Fr. Abend hat mich dann
eine Halsentzündung
dahingerafft.
Inzwischen habe ich versucht
dem ganzen ein wenig näher zu kommen. (Am besten
am ntv mit Laufschrift).
1. Scaling komplett
ausgeschalten (überall dort wos geht :-)
2.
Deinterlace disabled.
Schrift ist trotzdem
ausgefranst, aber horizontal, ganz seltsam, ich
kann dieses Phänomen nicht einordnen.
Alle paar
Sekungen 'springt' das Bild, sogar manchmal
Halbbildweise!!
Das ganze aufgenommen und
abgespielt, meiner Meinung nach ist das
ruckeln/springen alle paar Sekunden
weg.
Aber warum das Live Bild immer noch
nichtig dargestellt wird (ausfransen li und re der
Laufschrift) wüßte ich gerne...
Und ich
glaube auch, dass es an einem Röhren TV nie
vernünftig funktionieren wird mit einem TV-Out
einer Grafikkarte.
Aber was solls, lt. st
fallen die Preise für LCD Fernseher heuer noch
dramatisch (42" Ende des Jahres 700€ oder so :-)
und ich brauch keinen 42"...)
lg
__________________
stolzer Besitzer
eines M2NPV-VM mit Athlon 3500+ 1GB RAM, 160GByte
Platte Kanotix 2006-01-RC4 PVR350
Airstar2
| |
| 10.01.2007 12:24 |
| |
jarny
Ritter
Dabei seit:
24.09.2003
Beiträge: 1.143
Themenstarter
| |
| Zitat: |
Original von
GTB
Hallo,
Vorerst entschuldige
ich mich für das späte melden, aber am Fr. Abend
hat mich dann eine Halsentzündung
dahingerafft.
Inzwischen habe ich
versucht dem ganzen ein wenig näher zu kommen.
(Am besten am ntv mit Laufschrift).
1.
Scaling komplett ausgeschalten (überall dort wos
geht :-)
2. Deinterlace
disabled.
| genau diese
Vorraussetzungen habe ich mir unter Windows auch
geschaffen. Ohne diese dürfte es schonmal gar
nicht vernünftig gehen.
| Zitat: |
Schrift ist
trotzdem ausgefranst, aber horizontal, ganz
seltsam, ich kann dieses Phänomen nicht
einordnen.
Alle paar Sekungen 'springt' das
Bild, sogar manchmal Halbbildweise!!
Das
ganze aufgenommen und abgespielt, meiner Meinung
nach ist das ruckeln/springen alle paar Sekunden
weg.
Aber warum das Live Bild immer noch
nichtig dargestellt wird (ausfransen li und re
der Laufschrift) wüßte ich
gerne... | Das muss
irgendwie damit zusammenhängen, dass er bei
Aufnahmen die Framerate korrigieren (bzw.
synchronisieren) kann und zwar auf die Frequenz
der Grafikkarte. Diese Fraquenz weicht von der
theoretisch exakten Frequenz von 50Hz geringfügig
ab und verursacht nach ein paar Sekunden immer ein
'Sprung' von einem Frame bei LiveTV bzw. bei
Playern die diese Frequenzabweichung nicht
bemerken. Mal ganz abgesehen von dem
Halbbildproblem, d.h. er weiss nicht welches
Halbbild er gerade darstellt. Falsche
Halbbildfolge bedeutet tierische Fransen bei
Bewegungen.
Bei meinem Windowsversuchen konnte
ich im MPlayer die Option" -vf tfields=1"
aktivieren und das Gefransel war nicht mehr zu
sehen. Leider hatte ich immernoch die Sprünge alle
paar Sekunden. Das Programm 'Reclock' sollte das
zumindest bei Playern beheben die über
DirectX-Filterketten gehen. Das ist bei MPlayer
aber glaub ich nicht der Fall (eigene
Codecs).
Ich steig bei dem Gefrickel nicht mehr
durch und als Anwender würd ich mich fragen, warum
das ruckfreie Abspielen von Fernsehaufnahmen so
ein riesen Problem darstellt!
| Zitat: |
Und ich
glaube auch, dass es an einem Röhren TV nie
vernünftig funktionieren wird mit einem TV-Out
einer Grafikkarte.
Aber was solls, lt. st
fallen die Preise für LCD Fernseher heuer noch
dramatisch (42" Ende des Jahres 700€ oder so :-)
und ich brauch keinen
42"...)
lg | Flachbildschirm
kommt für mich erstmal nicht in Frage, weil meine
Röhre es ganz gut tut und ich kein Geld in Plasma,
LCD oder TFT investieren will. LaserTV ist ne
Option in ein paar Jahren.
Fazit für mich:
Ruckfreies Bild auf Röhrenfernseher ist mit
GRaKa-TV-Out technisch nicht lösbar.
Also hilft
nur der Rückschritt auf Ruckel-TV oder
Komplettverzicht.
Gruß
Jarny
PS: Was
passiert eigentlich wenn man Deinterlacing per
Bobbing machen würde? Dann hätte man zumindest
nicht mehr das Problem von vertauschten Fields. Oh
Gott, was für ne Geheimwissenschaft 
PPS: Gute Besserung
__________________
LinVDR 0.7 gepanscht
mit Mahlzeit-ISO (Kernel 2.6.15, VDR 1.4.0-1)
Hardware: TT DVB-S Rev1.3, 900Mhz Athlon,
Samsung-HD 160GB
| |
| 10.01.2007 13:41 |
| |
gundi61
Foren Ass
Dabei seit:
24.07.2004
Beiträge: 97
Herkunft:
NRW
| |
Hi, ich habe nach längerer Zeit auch mal wieder
in's Forum geschaut 
Also, ich schaue mittels tvtime
über DVI auf einem LCD-TV und habe ebenfalls diese
mehr oder weniger regelmäßigen
Ruckler.
Obwohl ich schon etliche Modelines
mit exakt 1280x720@50Hz ausprobiert habe, habe ich
noch nichts gefunden, womit diese Ruckler
wegzubekommen wären.
Das einzige, was sich
je nach Modeline/Pixelclock ändert, ist das
Wiederholungsintervall bzw. die Dauer der
Ruckler.
Mal dauert es länger, bis Ruckler
auftreten, dafür dauert die Ruckelphase auch
länger an. Oder die Ruckler treten häufiger auf,
dauern aber nicht so lange.
MMn sieht's so
aus, als ob die Synchronisation regelmäßig aus dem
Takt gerät und Halbbilder verschluckt werden (Das
Bild ist während der Ruckler gröber
aufgelöst)
Ich glaube daher nicht, daß der
TV-Dekoder das Problem ist (wird bei mir ja nicht
verwendet), sondern die Grafikkarte oder der
Treiber.
Ich vermute, daß der vom Treiber
eingestellte Takt von der Grafikkarte nicht
absolut exakt eingestellt werden kann. Vielleicht
wegen Toleranzen der verbauten Quarze oder
Rundungsfehler der Freuenzteiler oder ...
??
Am LCD-TV liegt's jedenfalls nicht, da
ein Analogmonitor über VGA die gleichen Probleme
zeigte.
/* edit */
Meine aktuelle
Modeline: "1280x720p50" 60.000 1280 1376 1464 1600
720 730 740 750
Die rechnerische
Bildwiederholrate wäre damit exakt 50Hz
(60MHz/1600/750) und der Treiber meldet diesen
Modus auch als eingestellt.
Aber wer kann
schon sagen, ob dies wirklich der Fall ist und der
Treiber/Grafikchip nicht einfach den
nächstliegenden, von Basisfrequenz und möglichen
Teilerverhältnissen abhängigen, Mode wählt ?
/*
end edit */
Gruß
Guido
__________________
HW: SilverStone
LC11, Board AOpen MK79G, Sempron 2600+, 256 MB, 80
GB HDD, DVB-S 2.3, Radeon 9250 DVI
SW: Debian Sarge,
Kernel 2.6.18, VDR 1.4.3, tvtime 1.0.1, xorg
6.9
Dieser Beitrag wurde 1
mal editiert, zum letzten Mal von gundi61:
10.01.2007 18:24. | |
| 10.01.2007 17:12 |
| |
|
Entweder Karten mit entsprechendem
Hardware-Support nehmen (z.B. FF Karten) oder
nvidia Xserver verwenden. Die erlauben mit den
Einstellungen