Beiträge von CiNcH

    Soweit ich weiß ist da mit Scaling das Chroma Upsampling gemeint. Bei DVB hat man es meist mit 4:2:0 zu tun. D.h. Chroma hat nur die halbe vertikale und horizontale Auflösung. Das muss natürlich auch hochgerechnet werden, wenn sich die Luma-Auflösung nicht ändert (wie in deinem Fall 1080i -> 1080p).
    Chroma Subsampling ist eine Art Kompression. Das menschliche Auge ist für Farbinformation nicht sehr empfänglich. Deshalb spielt hier der Skalieralgorithmus auch keine so große Rolle. Mit SD-Material auf HD-Ausgabegerät könnte der Qualitätsunterschied größer ausfallen.

    Zitat

    * Ab 3 HD Aufnahmen gibt es häufige Aussetzer. Ich denke ich stoße an die grenzen des USB Ports

    Versteh ich nicht. 3 Aufnahmen mit unterschiedlichen USB-Geräten am selben USB Root Hub oder mit einer einzigen anysee auf einem Transponder?


    Die anysee hat keine Hardware-Filter, d.h. es wird immer der komplette Transponder übertragen. Es ist also egal wieviele Aufnahmen darauf laufen. Ich habe mit der anysee problemlos 70 mbps Transponder gestreamt.

    TS-Pakete gehen bei der anysee Lösung direkt vom Demod ins CI. Von außen bekommt man da nix rein. DD hat da mit dem verbauten nGene und FPGA (und PCIe) etwas mehr Möglichkeiten (und mal eben hat man sowas auch nicht implementiert, die Remuxingvorgänge im Treiber dürften recht komplex sein). Was bei USB und bidirektionalem Verkehr mit gewissen Real-Time Anforderungen heraus kommt hat man ja beim Hauppauge CI bereits gesehen.


    Die gute CAM kompatibilität ist übrigens dem Hardware CI-Stack (läuft in einem CPLD auf der Karte bzw. in der Box) zu verdanken.

    Zitat

    Ob andere Programme eine Treiberunterstüzung planen, müsste man dann in den entsprechenden Foren nachfragen.


    Unter Windows ist es zum einen über BDA gelöst, zum anderen gibt es kleine Erweiterungen, um der Karte die zu dekodierenden PID's mitzuteilen. Schon hat man auch die Ausgabe über die Karte. Über einen Capture-Filter kann man sich den dekodierten Stream auch ins System holen.

    Zitat

    Ich habe hier auch 3x VDPAU laufen und bin davon ziemlich begeistert. Aber rein vom Konzept her empfinde ich es etwas als Overkill, dazu Milliarden von Transistioren einer GPU zu beheizen, die für völlig andere Zwecke entwickelt wurde (3D Games).


    Genau diese Transistoren werden für hochwertiges Deinterlacing und Scaling verwendet. Natürlich heizen die aber mehr wie eine dedizierte Hardware.. Nur die Dekodierung wird in einem dedizierten Co-Prozessor ausgeführt, nicht aber das PostProcessing, das wird in den "General Purpose ALU's" der GPU berechnet.


    Zitat

    Mit einen Hardwaredecoder, der nur 1080i kann, hat man aber m.E. deutlich zu kleine Brötchen gebacken, um davon satt zu werden.


    Problem ist halt, dass die Hardware schon vor Jahren geplant wurde und auf den Markt sollte. Die Welt hat sich in der Zwischenzeit weitergedreht. TT ist stehen geblieben.

    Zitat

    Wie lauten denn die API Namen von ATI, Intel und S3, die die gleiche Funktionalität bereitstellen wie VDPAU? Dann editiere ich die Umfrage entsprechend


    Ich fand den Namen 'VDPAU' für die Abstimmung hier auch etwas unglücklich gewählt, habe dennoch dafür gestimmt, obwohl ich keine nVIDIA habe. Ich sehe generell die Zukunft in der Ausgabe über die Grafikkarte. Ich persönlich hätte das folgendermaßen benannt:

    Code
    VA-API + Backends (VDPAU, XvMC/XvBA,...)


    Oder ganz schlicht:

    Code
    Dekodierung und Ausgabe über Grafikkarte (VA-API/VDPAU/XvBA)


    Soweit ich weiß basiert S3 direkt auf VA-API.

    Zitat

    Ich hoffe doch, dass 1080p auch ausgegeben werden kann, denn sonst ist das Ding schon veraltet gewesen als man es angefangen hat zu entwickeln


    Nein, das kann der verbaute STi7109 einfach nicht. Meine Bedenken habe ich auch hier bereits zum Ausdruck gebracht.


    Noch problematischer ist schon von der Theorie her 576i. Aus dem Video Editing Bereich weiß man, dass man immer erst deinterlact und anschließend skaliert. In diesem Fall wird 576i auf 1080i gepumpt und im Ausgabegerät anschließend deinterlact.


    Bei Ausgabe 1080p kann die Video Processing Pipeline für jede Quelle optimal eingehalten werden. Ob die entsprechenden Algorithmen dann gut genug sind, ist die andere Frage.


    Im Receiver-Bereich geht es jedenfalls bereits mit großen Schritten in Richtung 1080p und der STi7109 ist eben nichts als ein bereits veralteter Low-Cost Prozessor.

    Ich habe einen Vantage HD-7100S hier, welcher ebenfalls über den STi7109 verfügt. Man mag durchaus enthusiastisch der kommenden S2-6400 gegenüberstehen und die Ausgabequalität in den Himmel loben, aber der STi ist halt doch nur ein Low-Cost 1080i Prozessor, von welchem man keine Wunder erwarten darf (576i wird auf 1080i skaliert und anschließend im TV-Gerät auf 1080p deinterlact, aus 720p wird auch erstmal 1080i gemacht). Die 1080p Ausgabe über Grafikkarte mit hochwertigem Deinterlacing und Scaling ist da doch eine Ecke besser. Der Weg über VDPAU/XvMC ist meiner Meinung nach der richtige.

    Tolle Bilder cycon, man sieht richtig schön, wie abgenutzt die wohlgemerkt ausgestellte Karte ist...


    Mich würde interessieren, was in dem FPGA am CI-Anschluss gemacht wird. Hängt wohl zwischen Demodulator und DSP. Evtl. eine Crossbar-Logik, wo man Tuner mit CI verknüpfen kann? Oder vielleicht wird darin der CI-Stack abgearbeitet?

    Silicon oder CAN ist weniger die kritische Frage als mehr welche Tunerteile verbaut sind.


    Bei der S650 ist der Demodulator ein Conexant, der extrem heiß wird. Durch die kompakte Bauform sind thermische Probleme IMHO nicht ganz auszuschließen.
    Bei der S660 stammen RF und Demodulator von Montage. Dieser wird gerade mal handwarm und unterstützt im Gegensatz zu Conexant auch Auto-FEC für DVB-S2.

    Zitat

    PCI 2.3 - 32 Bit - 66 MHz - 266 MB/s --> dies ist aber noch kein PCI-X


    Findet das tatsächlich Verwendung? Also ich takte PCI im BIOS immer noch asynchron zum Systemtakt auf 33 MHz. Oder hat das was mit DDR und steigender/fallender Flanke zu tun und das sind nur pseude 66 MHz, also 33 MHz DDR?



    Hier noch eine kleine Rechnung für YV12 (YCbCr 4:2:0) (12 Bit/Pixel):


    1920 x 1080 x 25 x 12 = ~ 74 MByte/s


    Ich gehe zumindest von ca. dieser Datenmenge aus. Was wirklich aus der Karte kommt, weiß ich aber nicht so genau. Das ist jedenfalls das Minimum. Je nach Farbraum und Deinterlacer kann das auch bedeutend mehr sein.


    Auch wenn die 74 MByte/s schön innerhalb der 133 MByte/s liegen, sollte man die speziellen Echtzeitanforderungen beachten. Wenn man bedenkt dass da andere Geräte auch noch Bandbreite schlucken... Da wäre mir mit Point-to-Point und garantierter Bandbreite auch wohler.

    Zitat

    Mal abgesehen davon das es bereits PCI DVB-S2 Karten gibt und die funktionieren auch ohne Probleme mit HD Material.


    Welche mit Dekoder, die tonnenweise unkomprimiertes Material liefern?


    Dass die 10-20 Mbit/s komprimiertes Material kein Problem darstellen, ist auch klar, bzw. liefern die "Budget-Karten" ja eigentlich immer den kompletten TS (bis ca. 70 Mbit/s also), ist also egal ob SD oder HD, bei DVB-S2 ist der Stream natürlich in der Regel dicker. Nachdem das komprimierte Video den Dekoder durchlaufen hat sieht es mit den Datenmengen aber ganz anders aus. Im VDR-Fall spielt das keine Rolle, weil da sowieso die Interfaces der Karte verwendet werden (HDMI bzw. YUV). Diese Daten gelangen da also nicht in den PC, sondern lediglich die komprimierten A/V Daten im TS-Container zur Archivierung.


    Zitat

    Da das Signal bei einer FF-Karte eigentlich nur zum Aufzeichnen die Karte verlassen muss sollte es da kein Problem sein.


    Wenn man von einem VDR ausgeht stimmt das. Ist deine Sichtweise so eingeschränkt?


    Aber du hast schon recht, unter Windows wird man mit der Karte keinen allzu großen Absatz erreichen können und wie groß der Sinn dieses Features dann noch ist, ist halt die Frage. Dennoch wird es möglich sein, sie da zu betreiben und HD-Video über die Grafikkarte zu blasen (und die S2-6400 wird die Rolle des Dekoders übernehmen, nicht die Grafikkarte) und das schließt dann PCI als Bus aus. Fakt!


    Allzu viel Entwicklung wird man da auch nicht mehr hineinstecken, da die Karte ohnehin Jahre zu spät kommt. Aber TT hat die Entwicklung bereits gemacht und Kathrein kann nicht mehr wirklich was verlieren.


    Ich kann mir also nicht vorstellen, dass es die Karte mal mit der guten alten SAA7146 PCI-Bridge geben wird ;) . (wann wird die eigentlich mal abgekündigt? +g+)

    Zitat

    Ich wäre der Meinung gewesen, dass die Daten erst beim Ausgabegerät dekodiert werden.


    Was meinst du mit Ausgabegerät? Die Grafikkarte?


    Der TT-Treiber für Windows erhält von der S2-6400 unkomprimiertes YUV und stellt es über einen KS-Filter im DirectShow-Graph zur Verfügung, wie beim letzten Windows Treiber für die TT-premium.


    Zitat

    Sonst müssten ja mehrere GBit/s an Daten von der TV-Karte zur Graka geleitet werden.


    Wenn du nicht in der Grafikkarte dekodierst, ist das zwangsläufig der Fall, ja. Aber auch im Software-Fall müssen die dekodierten Daten von der CPU in die Grafikkarte. Wo ist das Problem, wenn der Flaschenhals nicht gerade PCI heißt/heißen würde (im Fall der S2-6400)?


    Zitat

    (wahrscheinlich ist es die einzige Karte die je gebaut wurde und wurde schon seit 5 Jahren rumgereicht, ... oder so ....)


    Es gibt mehr als 1 Muster, aber viele sind es in der Tat nicht ;) . Demnach sind noch keine vom Band gerollt, sprich noch keine Massenproduktion.

    Zitat

    Eine PCI-Version wäre nett, aber wenn immerhin die PCIe-Version allgemein verfügbar würde, dann wäre das schon ein guter Start. Ist eh fraglich, ob ein "alter" PC mit HDTV fertig werden kann. Beim Abspielen, dank FF-Karte, dann wohl schon, aber beim Schneiden dürfte sich ein alter PC ziemlich lange aufhalten.


    Problem ist, dass du unkomprimiertes HD nicht in Echtzeit über den PCI-Bus in die Grafikkarte bekommst (für einen VDR natürlich nicht weiter schlimm, aber..), bzw. dürfte man sich da knallhart an der Grenze bewegen (ich habs schon mal ausgerechnet..) und man weiß ja, dass PCI keine Point-to-Point Verbindung ist und sich alle Geräte am Bus die Bandbreite teilen müssen...