Reel Box EXTENSION HD

  • hsteinhaus :


    Das mit HDCP ist so so zu verstehen: Der Chip drauf kann HDCP, es ist aber nicht an. Ich sehe auch keine realistische Anwendung (unter Linux), wo es Sinn machen würde, das einzuschalten, die Files liegen eh auf Platte... Ausnahme: Es gäbe Displays, die es nur noch mit HDCP schlucken. Und das mit dem Binary liegt halt daran, dass der HDMI-Chip-Hersteller nicht will, dass man rausfindet, wofür die paar hundert Register gut sind und dann das bei anderen Geräten abschalten kann. Da gibt's auch ziemlich heftige Vertragsstrafen...


    @TooFast:


    h264/MPEG2 SD/HD laufen mit dem was so über Satellit kommt (AV-Sync-Bugs sind unsere Baustelle und nicht die von Micronas...). Bei anderen Formaten (wmv/vc1, divx) nehmen wir zur Zeit noch eine Playeranwendung von Micronas her, die aber eher als Beispiel/Demo zu sehen ist. Die hat mit einigen Files noch Probleme (falsche Erkennung) bzw. macht etwas viel Overhead rein. Ich habe jedenfalls schon ein paar wmv und divxe auch in HD abgespielt, aber Referenzaussagen dazu will ich noch nicht machen.


    Was man aber sagen kann, ist, dass wohl jede CPU mit >300MHz ausreicht (der 300MHz-Geode ist wesentlich langsamer als ein Uralt-Pentium2 mit 266MHz...). Bei den Epias sollten vom Gefühl her 500MHz auch reichen. Die CPU muss es nur schaffen, die Daten (max. 2-4MByte/s) irgendwoher zu lesen und über PCI rauszuschreiben.


    Dekodierter PCM-Ton kommt über HDMI und recht bald auch der AC3-Ton.


    NetCeiver: Ob einzeln noch dieses Jahr, kann ich nicht sagen. Das lohnt sich nur, wenn es auch Windowstreiber dafür gibt...


    komet :


    Das Problem ist eher die rechtzeitige Umsetzung, vernünftig ist es IMO bislang immer geworden ;) Aber wer sich berufen fühlt: RMM hat noch ein paar Stellen...

  • Quote

    komet :


    Das Problem ist eher die rechtzeitige Umsetzung, vernünftig ist es IMO bislang immer geworden Aber wer sich berufen fühlt: RMM hat noch ein paar Stellen...


    Equator gibt an, dass DivX-3-Dekodierung mit dem BSP-15-Chip möglich ist.


    Eine rechtzeitige Umsetzung war bis Heute nicht möglich.


    Quote

    Nürnberg, 10.01.2005 - Der MPEG-4 aacPlus v2-Codec von Coding Technologies ist ab sofort für den BSP-15 Prozessor von Equator verfügbar.


    Natürlich sind solche Codec auch eine Kostenfage.


    Gut lassen wir das hier geht es um die HD-E.



    Auch hier wurden deutlich Abstriche gemacht.


    Quote

    Aber wer sich berufen fühlt: RMM hat noch ein paar Stellen...


    In der Hoffnung für eure Kunden, das dieser Aufruf im WWW aufhallt. Eine rechtzeitige Umsetzung könnte somit erfolgen.

  • Danke real_Schorsch für deine Antworten:


    Schade,für Endkunden ist dieses Produkt dann derzeit nicht geeignet
    und auf wage Aussagen es "könnte mal gehen",will ich mich nicht
    verlassen.


    Als Bastelobjekt sehr schön,aber dann sind mir 200Eur wieder zuviel...


    Mal gucken, wann die neuen AGP Grakas kommen und dann hat sich das erledigt.
    ---
    Der Netceiver kommt ohne Windows Treiber?Das ist doch nicht euer ernst
    oder kommen die Treiber dann vom OEM?

  • Hallo real_schorsch,


    danke für die Aufklärung zur HDCP-Problematik, so klingts doch gleich viel freundlicher. Eventuell solltet ihr euren Shop auch in der Richtung aktualisieren, wie es dort formuliert ist, dürfte die Bemerkung für viele eine echte Kaufbremse sein.


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

  • Das mit den unterstützten Codecs wird sich sicher bald klären. Solange ich es nicht selber in allen Varianten gesehen habe, gibt's keine offizielle Aussage dazu, was wie in welchen Bitraten unterstützt wird.


    Beim BSP15 hat RMM auch etwas zuviel den Versprechungen von Equator geglaubt. Die haben bis heute nichts, was h.264 mit CABAC-Komprimierung kann und dummerweise ist halt CABAC das, was in Europa jeder benutzt... Ein weiteres Problem des BSP15 war/ist auch, dass die Codecs ziemlich API-inkompatibel sind. Wir haben zB. einen MPEG-Encoder, der braucht aber eine andere SDK-Version, als die, die jetzt (nach mehreren tausend Patchzeilen) halbwegs gut läuft. Es könnt' alles so einfach sein...

  • Naja, ich für meinen Teil freu mich auf weitere Meldungen zu dem Thema. Also real_schorsch bitte poste den aktuellen Status weiter.
    Vielleicht wird dann endlich auch ein VDR mit HDMI und HD ohne dicke CPU problemlos machbar.
    Der Idealzustand wäre natürlich, wenn der VDR die HD Extension als normales Ausgabedevice erkennen würde. Aber das ist ja zumindest im Moment noch nicht der Fall.

  • Quote

    Original von real_schorsch
    Das mit den unterstützten Codecs wird sich sicher bald klären. Solange ich es nicht selber in allen Varianten gesehen habe, gibt's keine offizielle Aussage dazu, was wie in welchen Bitraten unterstützt wird.


    Beim BSP15 hat RMM auch etwas zuviel den Versprechungen von Equator geglaubt. Die haben bis heute nichts, was h.264 mit CABAC-Komprimierung kann und dummerweise ist halt CABAC das, was in Europa jeder benutzt... Ein weiteres Problem des BSP15 war/ist auch, dass die Codecs ziemlich API-inkompatibel sind. Wir haben zB. einen MPEG-Encoder, der braucht aber eine andere SDK-Version, als die, die jetzt (nach mehreren tausend Patchzeilen) halbwegs gut läuft. Es könnt' alles so einfach sein...



    http://www.mediaware.com/links/eng_02codecs.html


    Codecs


    • MJPEG Encoder/Decoder Software
    • H.261/263 Encoder/Decoder Software
    • MPEG4 SH Encoder/Decoder Software
    • General Video Decoder Framework(MPEG2, MP@ML, MPEG4 ASP included DivX, XviD)
    • Mpeg Audio Decoder Software(Layer 1,2,3 with LSF extensions)
    • AC3 Decoder Software – available 2Q2005
    • AAC Decoder Software – available 2Q2005


    DIVX Codec für den BSP15 kann dort in Auftrag gegeben werden.


    Generell ist es zweifelhaft, ob sich das überhaupt noch rechnet.


    Macht es diesmal besser. :lehrer1

  • WOW ! In der Regel poste ich hier nicht und lese auch nur selten, aber nun bin ich doch ein wenig geplättet über die Rotznäsigkeit mit der nun Du Schorsch hier auftrittst. 2 Jahre und 4 Monate war Dir diese Plattform nicht ein Posting wert und nun kommst Du in dieses Forum und schreibst solche Zeilen ? Bisher waren Euch die privaten Entwickler und deren geistiges Eigentum doch gut genug um mit deren SW ein paar Boxen am Markt zu platzieren und ein paar Euro damit zu verdienen. Nun habt Ihr eine HD-Extensionkarte am Markt für die die Entwickler bei REEL mal ein paar SW Zeilen selbst entwickelt habt. Wieviel Arbeit dabei von Eurer freiwilligen und privaten Entwicklertruppe kam, entzieht sich meiner Kenntnis. Mal ne Frage zwischendurch von mir. Wieviele Deiner Studenten haben denn daran mitgearbeitet ? Naja, auch ein blindes Huhn findet mal ein Korn, aber es stolziert nicht am nächsten Tag über den Hof und bildet sich ein ein Hahn zu sein. Auch hier dürften die grundlegenden Codezeilen eben nicht auf Eurem Mist gewachsen sein, sondern Ihr habt nach- und zugearbeitet um eine Funktion ( nennen wir es mal Funktion ) der HD-E in der ReelBox zu gewährleisten.
    Anstatt hier nun mit einem tiefen Diener lieb Danke zu sagen, das REEL den VDR nutzen konnte, kommst Du nun hierher und kackst die Leute an mit :




    Nun kann sich die Firma REEL mal revanchieren und dem VDR Portal etwas zurückgeben und nun kommt das ? Wer meine Hochachtung hat sind die Leute hier das Sie Deine Postings grösstenteils mit Respekt behandelt und eventuell mit einem lachenden Auge zur Kenntnis genommen haben. Schaun ma mal wann REEL es auf die Reihe bekommt die beworbenen Features einer ReelBox auch gänzlich umzusetzen. Auf eine leistungsstärkere Hardware zu wechseln ( Avantgarde ), dürfte schon einmal die erste Entscheidung in die richtige Richtung gewesen sein, nachdem die jetzige ein solcher Flop war und wohl einer der erfolgslosesten Receiver am Markt. Zusätzlich bleibt abzuwarten wann REEL die beworbenen Funktionen der HD-E auch umsetzt, oder welche Dritte wieder einmal in die Verantwortung genommen werden in der Zukunft um die Schuld von REEL abzulenken. So, das soll es erst einmal gewesen sein und mehr gibt es dazu auch nicht zu schreiben. Jetzt darfst Du gerne wieder persönlich werden wie schon einmal bereits geschehen.

  • Hi,


    was meinte Too Fast mit


    Quote

    Mal gucken, wann die neuen AGP Grakas kommen und dann hat sich das erledigt.


    Grüße

    Asus P5N7A-VM, 2GB Ram davon 512MB Videoram, E5200, 1TB WD Green, TT-S2-3200, Netzteil Shuttle-PC30 200W, DVD-LW
    ---
    VDR 1.7.9 Ubuntu 9.04 + NVIDIA 190.32 + VDPAU + diese Anleitung

  • Er meinte wahrscheinlich die ATI/NVIDIA HD graka - welche mit closed source Treibern vielleicht irgendwann auch unterstützend wirken - sicher auch ne Lösung aber ich sehe nicht das da in naher Zukunft was unter Linux passiert, da diese Technik unter windows auf den Codecs basiert und nicht auf den Grafikkartentreibern - sprich unter Linux müsste etwas kommen wie XvMC für HD - kein Plan wann das passieren wird bei ATI ?

  • Unabhängig davon ist die Beschleunigung dieser Karten auch unter Windows recht begrenzt. Sprich, auf HD mit ner 300 MHz CPU wird mit so einer Grafikkarte dann auch nichts.


    Nebenbei halte ich die Grafikkartenvariante für keine Brauchbare Lösung weil:
    Die Grafikkarten sich i.d.R. nicht auf die Bildwiederholrate des Videostream synchronisieren lassen. Gelegentliche Mikroruckler sind die Folge. Bisher (ohne HD) gibts da nur ne Lösung für Nvidia unter X und mit nem CLE266 funktionierts auch noch. Mit allen anderen läuft irgendwann die Zeitbasis der Grafikkarte und den Videostreams auseinander, was durch einen Frameauslasser korrigiert wird >> Ruckeln.


    Deswegen sind spezialisierte Decoderkarten hier immer im Vorteil.


    Übrigens ist das etwas, mit dem man bei Windows-Mediacenterlösungen ständig zu kämpfen hat. Da geht die Ausgabe ja immer für die Grafikkarte.

  • Nein tritt auch bei DVI/HDMI auf.
    Das Problem kommt einfach daher, das die Grafikkarte einen eigenen Taktgeber als Zeitbasis verwendet. Und der ist auch bei DVI/HDMI wirksam.
    Damit es richtig funktioniert muss sich die ausgebende Hardware eigentlich auf den eingehenden Videostream synchronisieren und nach dessen Zeitbasis ausgeben. Geht aber bei Grafikkarten so einfach nicht, weil die sich ihre 50 Hz/60 Hz/was auch immer eingestellt ist selber erzeugen.
    Daran ändert auch DVI/HDMI nichts. Dort wird ja nur das Bild direkt digital ausgegeben und nicht erst nach analog gewandelt. Die Clock greift aber schon vorher.

  • Zumindest für mich wäre die Grafikkarten-/Softdecoderlösung ein absolutes No-Go. Ich lass mir ja viel gefallen, aber keinen 100-200W-PC im Wohnzimmer! Und mit einer GraKa, die schon alleine 50+x W zieht (und die wenns geht auch noch nen aktiven Kühler braucht) wird man nie einen einigermaßen leisen und kompakten VDR hinbekommen. Genausowenig hab ich Lust auf eine DualCore-CPU, um alles in Software zu dekodieren.


    Da scheint mir der Kartenansatz von Reel doch schon erheblich sinnvoller, wenn auch die angegebenen 10W schon ein paar Sorgenfalten bei mir hervorrufen (speziell, wenn ich diese mit der Stromaufnahme eines Blaustrahl-Standalonegerätes o.ä. vergleiche). Aber das wäre m.E. gerade noch im Rahmen für eine Wohnzimmerlösung.


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

    The post was edited 2 times, last by hsteinhaus ().

  • Ich meine mal gehört zu haben das eine FF Karte auch so um die 12W verbraten soll. Von daher ist es ja kein Rückschritt.


    Gruß Oga

    SW: c't VDR mit e-tobi, vdr 1.4.x, Kernel 2.6.18.1 (PowerNow! Patch + HG Treiber), Bootzeit: 45s
    HW: PC-Chips M811, AMD Geode NX 1750+@1.125V, 512MB RAM, 1GB CF, 100MBit LAN, DVD-ROM, TT2.3 modded (4MB + S-Video, IR, S/PDIF über J2), 1 x TT-Budget S1401, 2 x TT-Budget, 256x64 GVFD, WakeUP + 4x40 LCD
    Gehäuse: 8mm Alu, Netzteil: 300W passiv Umbau, Verbrauch|CPU|Gehäuse: @533Mhz(Idle) 59W|37°C|33°C, @1400Mhz(100%) 81W|46°C|41°C

  • Kommt ganz grob geschätzt hin, allerdings hat die FF zusätzlich einen kompletten Sat-Receiver inkl. LNB-Speisung on board...


    Grüße,
    Holger

    VDR 1-3: Zotac ZBox HD-ID42, yavdr-0.5
    VDR 4: AMD5900/Asus M3N-78, yavdr-0.5
    DVB-Empfang: Netceiver
    Storage: via NFS von separatem Fileserver

    [size=10]

  • Stimmt, das was bei der FF (und auch Budget) am meisten braucht, ist der Tuner und die LNB-Versorgung. Von der LNB-Versorgung bleiben so max. 1.5W auf der Karte, der Rest (1-5W) verglüht im LNB/Rotor. Am heftigsten waren und sind immer noch die eigentlichen Tuner. Es ist zwar etwas besser geworden als zu FF-Zeiten, aber ein normaler S-Tuner zieht immer noch gute 2-4W. Und zumindest beim S2 von Connexant steigt der Stromverbrauch stark an, wenn das Signal schlechter wird :schiel


    Achja: Die angebenen 10W der HD-Karte sind worst-case, praktisch sind es eher 5-6W. Solange man keine arg beengten Verhältnisse hat, reicht passive Kühlung.

  • Quote

    Original von real_schorsch
    Und das mit dem Binary liegt halt daran, dass der HDMI-Chip-Hersteller nicht will, dass man rausfindet, wofür die paar hundert Register gut sind und dann das bei anderen Geräten abschalten kann. Da gibt's auch ziemlich heftige Vertragsstrafen...


    Ich bin zwar kein Kernel-Entwickler und kenne mich mit der Technik auch nicht wirklich aus. Aber wäre es nicht auch möglich gewesen einen OpenSource Treiber zu bauen, der den HDMI Chip raus lässt? Und denn auf dieser Basis einen Closed Source Treiber der das entsprechende Modul mit beinhaltet.?!


    Wird der HDMI Chip unbedingt für die Ausgabe benötigt (wenn man nicht über HDMI ausgibt?)

  • @AliEnTxC:


    Den HDMI-Chip braucht man nicht, wenn man kein DVI/HDMI will. Ist zwar sicherlich ein ein idealistisches Ansinnen, ich denke aber, dass die Karte zu 90% per DVI/HDMI genutzt wird... Und sicher kann man die paar Aufrufe dazu im Rest des Codes rausoperieren, sodass man auf den Binary-Code verzichten kann. Man kann ihn nur nicht bei selber Funktion durch irgendwas mit GPL ersetzen.


    Nur ist das mit dem Binary-Ding erstmal ein Scheinproblem, was wenig mit den bekannten Binary-Only-Problemen in der PC-Praxis zu tun hat. Zunächst läuft der Kernel mit dem lästigen Binary auf der HD-Karte und nicht auf dem PC. Der "HD"-Kernel selbst hat sonst auch noch eine ganze Menge Sourcecodepatches und Ergänzungen von Micronas, d.h. "mal eben schnell" einen neuen Kernel auf die Karte zu werfen (wofür auch immer, das Ding ist kein Server), ist zwar wohl machbar, artet aber in ziemliche Arbeit aus. Wenn jemand das schafft, kann er auch noch die paar HDMI-Aufrufe selber rauswerfen...


    Und dann ist es so, dass der zur Zeit von Micronas gelieferte Kernel (2.6.12) sich in den nächsten SDK-Versionen auch ändert. Da wollen wir nur die für uns unbedingt notwendigen Patches reinmachen, sonst muss man da auch noch mehr nachziehen.