HDTV-Decoder Karte selber bauen! Der Wahnsinn ist zu Ende!

Hab nach hsteinhaus Posting auch noch mal in ffmpeg (mplayer-1.0pre7) kurz reingeschaut.

Es gibt schon ne Menge double deklarationen.
Und für die cosinus-transformationen (IMDCT, FDCT) werden die z.Tl. auch verwendet. Es gibt aber auch eine integer-implementation für DCT und verschiedene Varianten für ARM/SH4/i386-cpus.
Kann aber auf die schnelle nicht sagen ob was "akiver" code ist,
z.B. für h.264.

Ich kenne die Diskussion um fp oder nicht aus den Portierungen der Media-Player auf ARM-Cpus (simpad, und einige pdas mit xscale, die haben keine FPU). Und da wars immer ein Problem.

Grüsse,
Bitz

hi

zunächst mal - schönes projekt... ich nehm auich eine

ich verfolge diesen thread sehr interessiert und nun gelesen, dass der ursprüngliche Prozi nicht für die gewünschten HDTV Auflösungen reicht. Da habe ich gerade etwas bei Golem gelesen, das evtl Hinweis auf einen Ersatz sein könnte. Es geht um eine Neue Video-Box Lösung Namens "p2pod". In dem Artikel unter http://www.golem.de/0602/43434.html steht:

Zitat

Die nötige Rechenleistung für hochauflösende Videos bringt der im P2POD zum Einsatz kommende STB7109-Prozessor von STMicroelectronics mit sich. Dem Chip stehen 64 MByte DDR2-333-Speicher, 64 MByte Videospeicher und 32 MByte Flash-Speicher zur Verfügung. Zur Videoausgabe gibt es je einen Scart- und HDMI-Ausgang, wobei über letzteren HDTV-Auflösungen bis 1920 x 1080 Pixel angezeigt werden können.

Das könnte doch ein Kandidat sein...

Viel Erfolg weiterhin...

Zitat

Original von majto
hi

zunächst mal - schönes projekt... ich nehm auich eine

ich verfolge diesen thread sehr interessiert und nun gelesen, dass der ursprüngliche Prozi nicht für die gewünschten HDTV Auflösungen reicht. Da habe ich gerade etwas bei Golem gelesen, das evtl Hinweis auf einen Ersatz sein könnte. Es geht um eine Neue Video-Box Lösung Namens "p2pod". In dem Artikel unter http://www.golem.de/0602/43434.html steht:

Das könnte doch ein Kandidat sein...

Viel Erfolg weiterhin...

Alles anzeigen

Hi,
den STB7109 hat pingpong selber schon ins Spiel gebracht.
Es klingt aber so, als wäre der schwer zu bekommen.

Im schlimmsten Fall müsste man alles in einem FPGA implementieren.
Das hat den Vorteil, dass man so viele Videoports sich basteln kann,
wie man haben will und dass es keinen überflüssigen Features geben wird
(siehe LAN-Interface des TIs).

Der Nachteil ist, dass alles implementiert werden muss wie zum Beispiel das
PCI-Interface und vor allem der DSP...

Sehr viel Aufwand für die "Software"fraktion!
Dafür aber diese enorme Anpassbarkeit.

Gruß,
Henning

Hallo,

ich habe noch den folgenden Link zum STB7109 gefunden http://www.industrie-portal.at/ireds-12898.html (ist wirklich ein Alleskönner) .

Pingpong mach weiter so, ist sehr beeindruckend was du bis jetzt schon geleistet hast.

Gruß
Dirk

Hallo,

zum STB 7109:
"... indem er neben den erforderlichen Audio- und Video-Standards auch die jetzige und künftige Kopierschutz-Technologie unterstützt..."

Das heißt für uns wohl zwei Dinge: erstens NDA und zweitens vermutlich auch Lizenzgebühren in astronomischer Höhe, um diese tollen Technologien auch unterstützen zu dürfen...

Insofern denke ich, das er so das Gegenteil von pingpongs ursprünglichem Ansatz, die Codecs durch Open Source zu realisieren, darstellt.

Bitz
Hast Du mal ne Stelle zur Hand? Zumindest alle größreren Daten-Arrays für die DCT scheinen als Felder von "short", also int16 definiert zu sein. Es gibt zwar in der h264.c ein paar double-Deklarationen, allerdings wird da scheinbar nicht besonders viel mit gerechnet, wird wohl eher für so Dinge wie Seitenverhältnisse usw. verwendet.

Ansonsten sollten wir diese Fragestellung wohl so schnell wie möglich klären, bevor wir noch einen Anlauf mit unklaren Anforderungen starten.

Viele Grüße
Holger

zum STB7109:
der ist Ideal, wenn man ein vorhandenes Gerät "umnutzt",
dann hat der Hersteller die MPEG (und was weiss-ich-noch-alles) Lizenzen schon abgedrückt. Beim selbst verteiben kommt man in Teufels Küche wegen der rechtlichen Ansprüche anderer...

hsteinhaus:
Info kommt (bin aber wie immer knapp mit der Zeit, kann heut Abend oder Morgen werden).
Grüsse,
Bitz

Hallo,

ich habe mich gerade mal an der Softwarefront für den besagten DSP (und alle eventuellen Alternativen der C64x-Serie) umgesehen, hier mal ein paar Erkenntnisse:

1. Es gibt tatsächlich einen gcc-Ableger sowie entsprechende binutils (Assembler usw.): http://rtg.informatik.tu-chemn…ng/linuxdsps/gcc-c6x.html
Ich habs mal runtergeladen und ausprobiert - aber bin nicht wirklich begeistert. Fazit: der reine Compiler funkioniert, aber die gcc-lib hinkt noch. Ohne diese bekommt man keine libc übersetzt. Alles also noch sehr grün und m.E. ziemlich aussichtslos.

2. Dann bin ich auf eine Firma namens "Jaluna" gestoßen: http://www.jaluna.com/index.php?id=71
Die Leute behaupten, ein komplettes Linux für den besagten DSP incl. gcc-Entwicklungsumgebung zu haben. Auch wenn wir das Linux auf dem DSP sicher nicht brauchen und wollen, wären die Tools doch enorm interessant. Der Haken: scheinbar rücken sie es nicht freiwillig raus - auch wenn sie nach der GPL das eigentlich müssten. Ich schreibe gleich mal ne nette Mail und frage ganz lieb. Schlimmstenfalls müsste man mal wieder die Leute von der rechtlichen Front (Harald Welte und Kollegen) ansprechen, die haben in der Hinsicht schon einiges erreicht.

3. TIs originale Tools (CCS). Ich hatte schon mal kurz das Vergnügen, damit beruflich zu arbeiten. Wenn ich mich recht erinnere und sich in den letzten 7 Jahren nicht zuviel daran geändert hat ;), waren die recht brauchbar und angenhm, aber teuer (unterer 4-stelliger DM-Bereich pro Entwickler). Allerdings war der C-Compiler syntaktisch etwas seltsam drauf, hier sollten wir als mit viel Spaß rechnen, wenn wir Sourcen übersetzen, die für den gcc geschrieben wurden. Weiterhin mit dabei: viele proprietär lizensierte Sachen, die man schwer los wird -> eventuell drohen hier Lizenzkonflikte (GPL verlangt Offenlegung, TI-Lizenz verbietet das). Meiner Meinung nach kein gangbarer Weg.

Mein vorläufiges Fazit: die Sache steht und fällt Variante 2

Viele Grüße,
Holger

Für floating-point in ffmpeg:
schau mal:

libavcodec/ratecontrol.c
libavcodec/mpegvideo.h
libavcodec/fdctref.c
libavcodec/resample2.c
libavcodec/liba52/imdct.c

grep gibt seitenweise fundstellen, sind aber sicher nicht alle so relevant.
Hab auch für die o.g. Beispiele nicht geprüft ob der code auch tatsächlich in der libavcodec landet.

... na ob sich pingpong nochmal meldet... ?
Wann wäre denn möglicherweise die 1Ghz Version vom c642 verfügbar?

Grüsse,
Bitz

pingpong

habe nochmals gesucht habe folgendes dabei gefunden

http://www.dspengineering.com/articles/jentz_and_rotem/

Titel: Leveraging FPGA coprocessors to optimize high-performance digital video surveillance systems

FPGA kombiniert mit TI DSP

norman

Hoi

mach dir keinen kopf um andere! Das war in erster line dein Projekt und du entscheidest!

es ist zwar schade, aber evtl. wirds ja irgendwann doch noch, wenn evtl. andere Chips auf dem markt sind und bezahlbar besorgt werden können.

es war auf alle fälle Beeindruckend was in diesem Thread geschafft wurde
Ich schließ den Thread, damit er nicht mit "is das schade" & co überschwemmt wird!

wer das machen will -> >> macht das hier <<