Frage von Stephan Gerlach:Der Videorecorder ist aktuell kaputt, weswegen ich mal zu
Versuchszwecken versucht habe, mit dem Programm K!TV - bzw. genauer
mittels dessen integrierten Plugins Zoomout - über die analoge TV-Karte
unter Win98SE Fernsehsendungen aufzunehmen. Das klappte auch ganz gut, aber:
10 Sekunden(;!) Aufnahme im Format 768*576 ergeben unkomprimiert eine
Dateigröße von immerhin 200-300MB.
Dann habe ich mal den Video-Codec XviD MPEG-4 heruntergeladen und diesen
innerhalb des erwähnten Plugins Zoomout ausgewählt. Wobei sich
"ausgewählt" einfacher aushört, als es ist; es war relativ tricky, dem
Zoomout beizubringen, doch bitteschön diesen Codec zu verwenden statt
"non compression". Nun zu den eigentlichen Fragen:
1.) Ist dieser XviD Codec generell für den genannten Zweck
empfehlenswert, oder ist ein anderer Codec unbedingt vorzuziehen? Eine
10-Sekunden Aufnahme im Format 768*576 kommt mit diesem Codec immerhin
auf nur noch ca. 5MB. Allerdings sind in der entstandenen *.avi-Datei
nun Interlacing-Streifen zu sehen(;*); ebenso erscheint das Video nicht
"flüssig" wie das unkomprimierte, riesige Video.
2.) Falls auf 1.) durchaus ein "ja" als Antwort angebracht ist: Welche
Einstellungen sollte man in XviD unbedingt anpassen/beachten; welche
hingegen sind eher unwichtig? Es gibt eine Fülle von
Wiedergabe-Einstellungen. Wahrscheinlich ängen die optimalen
Einstellungen auch von der Ausgabe-Auflösung ab; vielleicht ist 768*576
etwas zu optimistisch, und ich sollte hier halbieren.
(;*) Während des "Live-Fernsehens" sieht man keine Interlacing-Streifen,
da dann das Plugin von K!TV greift. Wahrscheinlich wird es während der
Aufnahme abgeschaltet.
--
> Eigentlich sollte Brain 1.0 laufen.
gut, dann werde ich mir das morgen mal besorgen...
(;...Dialog aus m.p.d.g.w.a.)
Antwort von Wolfgang Hauser:
Stephan Gerlach schrieb:
>Der Videorecorder ist aktuell kaputt, weswegen ich mal zu
>Versuchszwecken versucht habe, mit dem Programm K!TV - bzw. genauer
>mittels dessen integrierten Plugins Zoomout - über die analoge =
TV-Karte
>unter Win98SE Fernsehsendungen aufzunehmen. Das klappte auch ganz gut, =
aber:
>10 Sekunden(;!) Aufnahme im Format 768*576 ergeben unkomprimiert eine
>Dateigröße von immerhin 200-300MB.
>Dann habe ich mal den Video-Codec XviD MPEG-4 heruntergeladen und diesen=
>innerhalb des erwähnten Plugins Zoomout ausgewählt. Wobei sich
>"ausgewählt" einfacher aushört, als es ist; es war relativ tricky, =
dem
>Zoomout beizubringen, doch bitteschön diesen Codec zu verwenden statt
>"non compression". Nun zu den eigentlichen Fragen:
>
>1.) Ist dieser XviD Codec generell für den genannten Zweck
>empfehlenswert, oder ist ein anderer Codec unbedingt vorzuziehen? Eine
Finde Dich damit ab, daß Echtzeit-Encoding in ein anspruchsvolles
Format nicht allzuviel Sinn ergibt. Klassisch macht man das
zweistufig: Aufnahme gering komprimiert (;neben "unkomprimiert" kommt
noch der verlustlose HUFFYUV in Frage oder M-JPEG - falls Du Dich mit
weiteren Codecs herumschlagen möchtest) und später ins gewünschte
Zielformat konvertieren.
Wenn das klappen sollte, kommt die nächste Hürde: Der Ton wird gerne
asynchron, weil über die timingmäßig getrennte Soundkarte
digitalisiert wird.
Und dann kommt bei Win98 noch das FAT-Dateigrößenlimit von 4 GB =
hinzu.
Kurz: Vergiß es, der Weg über die einfache Soundkarte ist einfach zu
steinig.
Falls das eine Option sein sollte: Digitalfernsehen (;DVB) ist
erheblich entspannter zu handhaben. Win98-taugliche Hardware gibt es
allerdings m.W. nur noch gebraucht und teilweise nicht mehr kompatibel
zu aktuellen Betriebssystemen.
Alternative: DVD-Recorder. Bastelfrei (;Timerprogrammierung wäre beim
PC noch eine weitere Baustelle), wohnzimmertauglich, preiswert.
Antwort von Shinji Ikari:
Guten Tag
Stephan Gerlach
schrieb
>Das klappte auch ganz gut, aber:
>10 Sekunden(;!) Aufnahme im Format 768*576 ergeben unkomprimiert eine
>Dateigröße von immerhin 200-300MB.
Das ist bei absolut unkomprimierter Aufzeichnung auch richtig so.
768*576*3Farben*25Vollbilder/s*10 Sekunden = 331.776.000 Byte fuer 10
Sekunden Video. Audio ist dabei noch gar nicht beruecksichtigt.
Da Win98(;se) auch aufgrund des FAT32-Dateisystemes bei 2GB oder
spaetestens 4 GB grossen Dateien Probleme bekommt sollten die Dateien
in der Gesamtgroesse nicht zu gross werden. Diverse Software kann auch
geeignet Splitten.
Aber um eben gar nicht auf das Groessenproblem zu stossen macht es
Sinn hier einen (;hoeher) komprimierenden Codec zu verwenden.
>1.) Ist dieser XviD Codec generell für den genannten Zweck
>empfehlenswert, oder ist ein anderer Codec unbedingt vorzuziehen?
Wenn die CPU dafuer leistungsfaehig genug ist und die moeglichen
Parameter des xvid optimal eingestellt sind eignet er sich auch fuer
solche Aufgaben.
Wenn Dein System grosse Dateien (;mehrere GB) verwalten koennte, waere
es auch moeglich erst einmal un-(;oder sehr schwach) komprimeirt
aufzuzeichen und dies dann nachtraeglich zu filtern und in 2-pass oder
so zeitaufwaendig zu komprimieren. Wenn der PC nicht so unter
Zeitdruck steht, kann er ggf. bessere Ergebnisse erzielen.
>Eine
>10-Sekunden Aufnahme im Format 768*576 kommt mit diesem Codec immerhin
>auf nur noch ca. 5MB. Allerdings sind in der entstandenen *.avi-Datei
>nun Interlacing-Streifen zu sehen(;*);
Ich kenne Deine Aufzeichnungssoftware nicht. Als ich damals mit
Virtualdub von der Hauppauge aufgezeichnet hatte, konnte ich einen
Deinterlacer konfigurieren, der sich grundlegend dieses Problemes
angenommen hat.
>ebenso erscheint das Video nicht
>"flüssig" wie das unkomprimierte, riesige Video.
Dann musst Du ggf. noch mit den Einstellungen herum experimentieren
oder eben nachtraeglich filtern/komprimieren.
>2.) Falls auf 1.) durchaus ein "ja" als Antwort angebracht ist: Welche
>Einstellungen sollte man in XviD unbedingt anpassen/beachten; welche
>hingegen sind eher unwichtig? Es gibt eine Fülle von
>Wiedergabe-Einstellungen. Wahrscheinlich ängen die optimalen
>Einstellungen auch von der Ausgabe-Auflösung ab; vielleicht ist 768*576
>etwas zu optimistisch, und ich sollte hier halbieren.
Wenn Du die Bildschirmaufloesung viertelst (;also in Hoehe und Breite
halbierst) wird die Datei (;unkomprimiert) auch nur 1/4 so gross.
Je nach Anwendungszeck und Wiedergabegeraet reicht das evtl. auch aus.
Antwort von Stephan Gerlach:
Shinji Ikari schrieb:
> Stephan Gerlach schrieb
[...]
> Diverse Software kann auch
> geeignet Splitten.
Das geht mit der Software hier automatisch während der Aufnahme
Hmm... grade probiert; es wird mit XviD doch nur eine Datei. Vielleicht
funktioniert das automatische Splitten nicht mit XviD, oder ich habe
anderweitig falsche Einstellungen vorgenommen.
> Aber um eben gar nicht auf das Groessenproblem zu stossen macht es
> Sinn hier einen (;hoeher) komprimierenden Codec zu verwenden.
Ist hier einer der Codecs Mjpeg, Divx, Xvid generell "besser" als die
anderen beiden?
>> 1.) Ist dieser XviD Codec generell für den genannten Zweck
>> empfehlenswert, oder ist ein anderer Codec unbedingt vorzuziehen?
>
> Wenn die CPU dafuer leistungsfaehig genug ist
AMD Athlons XP T-Bred-B mit 2,08 Ghz.
Am RAM - sofern der bei Echtzeit-Encoding überhaupt eine entscheidende
Rolle spielt - könnte es evtl. hapern; sind nur 512MB.
> und die moeglichen
> Parameter des xvid optimal eingestellt sind eignet er sich auch fuer
> solche Aufgaben.
Z.B. besteht ja hier die "Besonderheit"(;?), daß es sich um analoges PAL
Fernseh-Material handelt, daß direkt von der Antenne kommt.
Xvid ist sicher in seinen Grundeinstellungen für andere Aufgaben optimiert?!
> Wenn Dein System grosse Dateien (;mehrere GB) verwalten koennte,
Ich hab' auch noch WinXP, aber damit machte(;n) IIRC entweder die
(;ziemlich alte) TV-Karte selber oder das "Fernseh-Programm" leichte
Probleme, weswegen ich das AFAIR nur unter Win98SE installiert habe.
> Wenn der PC nicht so unter
> Zeitdruck steht, kann er ggf. bessere Ergebnisse erzielen.
Mein Aufnahme-Programm zeigt mir immerhin sogenannte "Lost Frames"
während der Aufnahme an; das sind nicht gerade wenig.
>> Eine
>> 10-Sekunden Aufnahme im Format 768*576 kommt mit diesem Codec immerhin
>> auf nur noch ca. 5MB. Allerdings sind in der entstandenen *.avi-Datei
>> nun Interlacing-Streifen zu sehen(;*);
>
> Ich kenne Deine Aufzeichnungssoftware nicht.
Das eigentliche Fernseh-Programm ist K!TV, das wohl einige Komponenten
von DScaler verwendet. Integriert in K!TV als Aufzeichnungssoftware ist
Zoomout.
> Als ich damals mit
> Virtualdub von der Hauppauge aufgezeichnet hatte, konnte ich einen
> Deinterlacer konfigurieren, der sich grundlegend dieses Problemes
> angenommen hat.
Wenn ich die Hilfe-Datei von Zoomout richtig interpretiere, hängt dieses
Zoomout wohl auch irgendwie mit Virualdub zusammen.
>> 2.) Falls auf 1.) durchaus ein "ja" als Antwort angebracht ist: Welche
>> Einstellungen sollte man in XviD unbedingt anpassen/beachten; welche
>> hingegen sind eher unwichtig? Es gibt eine Fülle von
>> Wiedergabe-Einstellungen. Wahrscheinlich ängen die optimalen
>> Einstellungen auch von der Ausgabe-Auflösung ab; vielleicht ist 768*576
>> etwas zu optimistisch, und ich sollte hier halbieren.
>
> Wenn Du die Bildschirmaufloesung viertelst (;also in Hoehe und Breite
> halbierst) wird die Datei (;unkomprimiert) auch nur 1/4 so gross.
> Je nach Anwendungszeck und Wiedergabegeraet reicht das evtl. auch aus.
Am besten wohl dann gleich eine Auflösung nehmen, die der CRT-Monitor
"nativ" darstellen kann.
--
> Eigentlich sollte Brain 1.0 laufen.
gut, dann werde ich mir das morgen mal besorgen...
(;...Dialog aus m.p.d.g.w.a.)
Antwort von Heiko Nocon:
Stephan Gerlach wrote:
>1.) Ist dieser XviD Codec generell für den genannten Zweck
>empfehlenswert, oder ist ein anderer Codec unbedingt vorzuziehen?
Das kommt darauf an, ob du planst, die Aufnahme noch nachzubearbeiten
oder nicht. Wenn du sie noch nachbearbeiten möchtest, ist der Codec (;wie
alle hochkomprimierenden Codecs) sehr ungeeignet, ansonsten zumindest
akzeptabel.
Nur "akzeptabel" deshalb, weil XviD (;im Gegensatz zur Konkurrenz DivX)
kein qualitätsbasiertes Encoding beherrscht. Er kann nur CBR oder VBR im
Mehrpass-Verfahren. Mehrpass ist für Live-Aufnahmen naturgemäß
unbrauchbar. CBR hingegen verschwendet Bitrate und damit Plattenplatz
und/oder macht die Qualitat schlechter, als sie bei Verwendung von VBR
sein könnte.
>Eine
>10-Sekunden Aufnahme im Format 768*576 kommt mit diesem Codec immerhin
>auf nur noch ca. 5MB.
Wie groß eine Aufnahme wird, hängt davon ab, welche Bitrate du
einstellst. Du kannst also selbst einen Kompromiß zwischen
Platzverbrauch und Qualität finden, der deinen Ansprüchen genügt.
>ebenso erscheint das Video nicht
>"flüssig" wie das unkomprimierte, riesige Video.
Vermutlich ist der verwendete Rechner schlicht zu langsam für
XviD-Encoding in voller PAL-Auflösung. Was den Interlace-Kram betrifft,
solltest du vor dem Encodieren einfach Deinterlacen. Ich weiß allerdings
nicht, ob man K!TV bzw. das verwendete Plugin überhaupt so einstellen
kann. Deswegen empfehle ich für Capturezwecke VirtualDub (;bzw. eins
seiner Derivate). Da kann man sowas einstellen.
Hochwertiges Deinterlacing erfordert allerdings nochmal einiges an
zusätzlicher Rechenzeit. Wenn's schon beim Encodieren klemmt, wirst du
nicht darum herumkommen, die Auflösung der Aufnahme zu senken. Leider
ist das bei Interlaced-Material und AVI als Zielformat alles garnicht so
einfach.
Das Problem ist, daß praktisch kein Player die bei OpenDML-Avi
prinzipiell mögliche Angabe eines von 1:1 verschiedenen PixelAspectRatio
korrekt unterstützt. Das führt letztlich dazu, daß du die Wahl zwischen
zwei Optionen hast, wenn du nicht jedesmal beim Abspielen an den
Zoom-Einstellungen des Player (;sofern überhaupt verfügbar) herumfummeln
willst:
1) Die Capture-Auflösung auf QPAL (;384x288) festlegen. Damit fällt die
Notwendigkeit zum Deinterlacen komplett weg (;weil überhaupt nur ein
Halbbild benutzt wird) und der Rechenaufwand für's Encoding sinkt auf
ein Viertel. Leider sieht das Ergebnis wegen der extrem geringen
Auflösung auch entsprechend Scheiße aus, wenn man es bildschirmfüllend
wiedergibt. Sehr unscharf.
2) Die Captureauflösung lassen, wie sie ist. Dann Deinterlacen. Dann
Resize mit korrektem AspectRatio auf eine Auflösung, bei der der Encoder
noch in der Lage ist, mit der verfügbaren Restrechenzeit in Echtzeit
hinterherzukommen, z.B. 640x480 oder 576x432 oder 432x324. Das muß man
dann einfach ausprobieren.
Die einfachste Lösung ist allerdings, den steinzeitlichen Rechner, der
solche Kunstgriffe nötig macht, schleunigst zu beerdigen und für 299 ¤
oder so einen Billichstrechner von heute zu kaufen, der das Ganze in
voller PAL-Auflösung problemlos erledigen kann (;und gleichzeitig noch
viele andere Sachen).
Antwort von Heiko Nocon:
Wolfgang Hauser wrote:
>Kurz: Vergiß es, der Weg über die einfache Soundkarte ist einfach zu
>steinig.
Nicht mit VirtualDub. Das hat sehr ausgefeilte (;und tatsächlich
funktionierende) Mechanismen, um die AV-Synchronität beim Capturen auch
dann sicherzustellen, wenn die Daten aus Capturequellen mit
unterschiedlicher Zeitbasis rieseln. Man muß sie einfach nur
aktivieren...
Antwort von Heiko Nocon:
Shinji Ikari wrote:
>Das ist bei absolut unkomprimierter Aufzeichnung auch richtig so.
Nicht wirklich.
>768*576*3Farben*25Vollbilder/s*10 Sekunden = 331.776.000 Byte fuer 10
>Sekunden Video.
Das wäre RGB24. Es ist aber Unsinn, in RGB24 aufzunehmen. Praktisch alle
analogen Capturekarten sind auch in der Lage, das viel besser zum
TV-Signal passende YUY2-Pixelformat zu liefern. Das braucht pro Pixel
nicht drei, sondern nur zwei Bytes und reduziert den Platzverbrauch
somit um ein Drittel.
Antwort von Christian Stubbs:
Heiko Nocon writes:
> Nur "akzeptabel" deshalb, weil XviD (;im Gegensatz zur Konkurrenz DivX)
> kein qualitätsbasiertes Encoding beherrscht. Er kann nur CBR oder VBR im
> Mehrpass-Verfahren. Mehrpass ist für Live-Aufnahmen naturgemäß
> unbrauchbar. CBR hingegen verschwendet Bitrate und damit Plattenplatz
> und/oder macht die Qualitat schlechter, als sie bei Verwendung von VBR
> sein könnte.
XviD unterstützt noch einen festen Quantizer, was wohl als eine Art
qualitätsbasiertes Encoding durchgehen kann.
Wenn man den Capture nur als Zwischenstation benutzt und nachher nochmal
mit 2-Pass und deinterlacing richtig encoden will, kann man auch die
"motions search precision" auf "0 - None" stellen (;ist bei dem config
dialog unten bei "Quality Preset --> more" zu finden). Es wird dann
tatsächlich keinerlei Bewegungskompensation gemacht (;es sind auch alles
Keyframes), was richtig Rechenzeit spart. Das dürfte dann so ne Art
mjpeg sein. XviD kann sogar Interlaced beim Encoding berücksichtigen.
Ich hab so schon vor Ewigkeiten mit festem Quantizer von 4 und motion
search von 0 full-PAL mit Virtualdub gecaptured.
Antwort von Shinji Ikari:
Guten Tag
Stephan Gerlach schrieb
>> Aber um eben gar nicht auf das Groessenproblem zu stossen macht es
>> Sinn hier einen (;hoeher) komprimierenden Codec zu verwenden.
>Ist hier einer der Codecs Mjpeg, Divx, Xvid generell "besser" als die
>anderen beiden?
Divx und xvid tun sich nicht viel. MJpeg komprimiert in der regel
etwas weniger.
>>> 1.) Ist dieser XviD Codec generell für den genannten Zweck
>>> empfehlenswert, oder ist ein anderer Codec unbedingt vorzuziehen?
>> Wenn die CPU dafuer leistungsfaehig genug ist
>AMD Athlons XP T-Bred-B mit 2,08 Ghz.
>Am RAM - sofern der bei Echtzeit-Encoding überhaupt eine entscheidende
>Rolle spielt - könnte es evtl. hapern; sind nur 512MB.
Tja, das musst du durch experimentieren herausfinden.
je nach Einstellungen und Bildgroesse kann es mit neidriger
Kompression klappen.
>> und die moeglichen
>> Parameter des xvid optimal eingestellt sind eignet er sich auch fuer
>> solche Aufgaben.
>Z.B. besteht ja hier die "Besonderheit"(;?), daß es sich um analoges PAL
>Fernseh-Material handelt, daß direkt von der Antenne kommt.
Analoges PAL von Antenne? Wo lebst du?
Fast ueberall in Deutschland soll doch analoges Antennen-TV schon
gegen DVB-T getauscht worden sein.
Oder meinst du Kabelanschluss an Antenneneingang der TV-Karte? So
hatte ich das damals auch gemacht. Leider ist bei mir der Rauschanteil
recht hoch gewesen, so dass die Kompression erst nach ein paar Filtern
halbwegs effektiv war.
>Xvid ist sicher in seinen Grundeinstellungen für andere Aufgaben optimiert?!
Soweit ich mich entsinne wird xvid von diversen Leuten kompiliert.
Welche Grundeinstellungen dadurch voreingestellt sind mag deshalb
unterschiedlich sein.
Im Prinzip sind solche Codecs aber fuer saubere Bildsignale
vorgesehen. Je hoeher der Rauschanteil ist, desto aufwaendiger wird
die komprimierungsarbeit und uneffektiver sind die Codecs (;wenn man
nicht vorher versucht das Rauschen wieder rauszufiltern).
>> Wenn der PC nicht so unter
>> Zeitdruck steht, kann er ggf. bessere Ergebnisse erzielen.
>Mein Aufnahme-Programm zeigt mir immerhin sogenannte "Lost Frames"
>während der Aufnahme an; das sind nicht gerade wenig.
Ich hatte damals bei >10 Lost Frages pro Minute den Eindruck, dass mir
die Ergebnisse nicht gefielen. Deshalb habe ich die Kompression dann
damals entsprechend reduziert bis der xvid da mitkam und die Lost
Frames ins ertraegliche Mass absanken.
>> Ich kenne Deine Aufzeichnungssoftware nicht.
>Das eigentliche Fernseh-Programm ist K!TV, das wohl einige Komponenten
>von DScaler verwendet. Integriert in K!TV als Aufzeichnungssoftware ist
>Zoomout.
Da ich keines dieser Programme verwende/kenne, kann ich dazu nichts
sagen. Ich habe damals mit VirtualDub experimentiert.
>> Wenn Du die Bildschirmaufloesung viertelst (;also in Hoehe und Breite
>> halbierst) wird die Datei (;unkomprimiert) auch nur 1/4 so gross.
>> Je nach Anwendungszeck und Wiedergabegeraet reicht das evtl. auch aus.
>Am besten wohl dann gleich eine Auflösung nehmen, die der CRT-Monitor
>"nativ" darstellen kann.
*hust*
Ich weiss nicht, welchen CRT-Monitor Du da hast, aber ein 19" CRT
beherrschte damals schon Aufloesungen >1000. das waere weitaus mehr
als das normale PAL standard-TV liefert.
Probiere einfach etwas mit verschiudenen Aufloesungen und
Codec-Einstellungen herum und finde den fuer Dich passenden
Kompromiss.
Nebenbei: ich bin von der analog-TV-Aufzeichnung auf PC abgekommen.
Ich habe in der Wohnung einfach ein paar DVB-Empfaenger verteilt, die
alle direkt ihre digitalen DVB Aufnahmen im Keller zentral auf einen
PC abspeichern. Somit kann jeder vernetzte PC im Haushalt und auch
alle netzwerkfaehigen Player, TV-geraete, etc... das Videomaterial
finden und wiedergeben.
Erst wenn ich das Videomaterial dann umkodieren will, muss ich mir
nich Gedanken wegend er Codecs und Einstellungen machen. Da das aber
nachtraeglich geschieht, habe ich genug Zeit das jeweils
gewuenschte/passende Ergebniss zu erzielen.
Antwort von Thomas Beyer:
Shinji Ikari schrieb:
> >1.) Ist dieser XviD Codec generell für den genannten Zweck
> >empfehlenswert, oder ist ein anderer Codec unbedingt vorzuziehen?
>
> Wenn die CPU dafuer leistungsfaehig genug ist und die moeglichen
> Parameter des xvid optimal eingestellt sind eignet er sich auch fuer
> solche Aufgaben.
Dieses ganze MPEG4-ASP Geraffel (;Xvid, DivX) ist für interlacten Content
ungeeignet. Das Zeug ist für progressives Videomaterial ausgelegt, und
selbst wenn das Gegenteil behauptet wird: bei meinen letzten Tests kippt
immer noch azyklisch die Fieldorder um, ganz davon ab, das Joe User die
tendenz aufzeigt, auch bei interlactem video fröhlich vor sich
hinzuskalieren.
Wer, wie der OP, analoges SDTV in Echtzeit komprinmieren will, sollte
sich ganz schnell auf einen niedrig komprimierenden, tauglichen Codec
besinnen, bspw. DV oder MJPG. Das drückt den benötigten festplattenplatz
pro Stunde Video schon auf <4GB, und danach kann man immer noch, wie Du
erwähntest, offline rübergehen.
Noch eine Randbemerkung: *Audio*komprimierung hat in diesem Szenario on
the fly auch nichts verloren. PCM und später offline komprimieren.
> Ich kenne Deine Aufzeichnungssoftware nicht. Als ich damals mit
> Virtualdub von der Hauppauge aufgezeichnet hatte, konnte ich einen
> Deinterlacer konfigurieren, der sich grundlegend dieses Problemes
> angenommen hat.
Interlacten Source kann man zwar beim Reenkodieren deinterlacen, also
progressiv machen, das ist aber IMMER mit einem Schärfeverlust
verbunden. Wenn man den Kram über einen CRT wiedergeben will, einfach
interlaced lassen. Ist das Ausgabedisplay progressiv, das Deinterlacing
der Hardware überlassen.
Wie nichttrivial die Materie ist, zeigt folgendes Beispiel:
Irgendwie müssen in den letzten Monaten in den Studios der TV-Anstalten
die Kontrollmonitore alle auf progressiv (;LCD, Plasma, whatever)
umgestellt worden sein. Seitdem sieht man, gerade bei Nachrichten und
Boulevard, immer wieder Einspielungen mit falscher Fieldorder. Auf
"alten" CRT sieht das grausam aus, auf progressiven Bildschirmen ist es
dann "nur" sehr unscharf" und keine Wackelshow. Bei RTL und NDR bekomme
ich solchen Unsinn mittlerweile mehrmals wöchentlich zu Gesicht,
entweder die sind ignorant oder merkbefreit.
Lange Rede, kurzer Sinn. Die Unfähigkeit dieser Praktikantenstadl ist
noch lange kein Grund, das es der geneigte Homeuser genauso falsch
machen muss. Interlaced bleibt interlaced, progressiv progressiv. Alle
unnötigen Zwischenschritte in der Bearbeitung provozieren nur Denk- und
Konfigurationsfehler.
Grüsse,
Thomas
Antwort von Alexander Marquardt:
Stephan Gerlach schrieb:
> Der Videorecorder ist aktuell kaputt,
Wäre save.tv eine Alternative für Dich? Da bekommst Du ruckelfreies Xvid
raus.
Antwort von Stephan Gerlach:
Shinji Ikari schrieb:
> Stephan Gerlach schrieb
>>
>> Z.B. besteht ja hier die "Besonderheit"(;?), daß es sich um analoges PAL
>> Fernseh-Material handelt, daß direkt von der Antenne kommt.
>
> Analoges PAL von Antenne? Wo lebst du?
Keine Ahnung, ob es "von Antenne" ist.
Eben aus der üblichen Dose aus der Wand entnommenes Fernsehen :-) .
> Fast ueberall in Deutschland soll doch analoges Antennen-TV schon
> gegen DVB-T getauscht worden sein.
> Oder meinst du Kabelanschluss an Antenneneingang der TV-Karte?
"Richtiges" Kabelfernsehen scheint es nicht zu sein, da hier ein paar
Sender fehlen, die im ortsüblichen Kabel-Netz vorhanden sein müßten;
zudem ist die Empfangs-Qualität bei manchen Sendern wetterabhängig.
>> Am besten wohl dann gleich eine Auflösung nehmen, die der CRT-Monitor
>> "nativ" darstellen kann.
>
> *hust*
> Ich weiss nicht, welchen CRT-Monitor Du da hast, aber ein 19" CRT
> beherrschte damals schon Aufloesungen >1000.
Es geht nicht darum, was der Monitor *maximal* kann, sondern daß er
überhaupt Auflösungen wie z.B. 640*480 oder 320*240 nativ darstellen kann.
> das waere weitaus mehr
> als das normale PAL standard-TV liefert.
768*576 ist eben schon ziemlich groß; zudem funktioniert DirectX (;und
damit das Aufnahme-Programm) bei dieser krummen Auflösung hier nicht
richtig.
> Nebenbei: ich bin von der analog-TV-Aufzeichnung auf PC abgekommen.
> Ich habe in der Wohnung einfach ein paar DVB-Empfaenger verteilt,
[...]
JFTR: DVB-T, DVB-S oder DVB-C?
--
> Eigentlich sollte Brain 1.0 laufen.
gut, dann werde ich mir das morgen mal besorgen...
(;...Dialog aus m.p.d.g.w.a.)
Antwort von Shinji Ikari:
Guten Tag
Stephan Gerlach schrieb
>>>Am besten wohl dann gleich eine Auflösung nehmen, die der CRT-Monitor
>>>"nativ" darstellen kann.
>> Ich weiss nicht, welchen CRT-Monitor Du da hast, aber ein 19" CRT
>> beherrschte damals schon Aufloesungen >1000.
>Es geht nicht darum, was der Monitor *maximal* kann, sondern daß er
>überhaupt Auflösungen wie z.B. 640*480 oder 320*240 nativ darstellen kann.
Also nicht die Aufloesung, die der CRT native beherrscht, sondern die
Du ihm vorwerfen willst. Ok.
Das sollte jeder halbwegs aktuelle CRT beherrschen.
>> das waere weitaus mehr
>> als das normale PAL standard-TV liefert.
>768*576 ist eben schon ziemlich groß;
Auf meinem alten 22" CRT war das eher klein.
>zudem funktioniert DirectX (;und
>damit das Aufnahme-Programm) bei dieser krummen Auflösung hier nicht
>richtig.
Wenn ich mich recht entsinne benoetigt Viortualdub kein DirectX.
ist aber schon laenger her, dass ich mit VD experimentiert habe.
>> Nebenbei: ich bin von der analog-TV-Aufzeichnung auf PC abgekommen.
>> Ich habe in der Wohnung einfach ein paar DVB-Empfaenger verteilt,
>JFTR: DVB-T, DVB-S oder DVB-C?
Meist DVB-T
Siemens M740AV sind dafuer recht brauchbar.
