Hallo Leute, mich interessiert das Abspielen von x264-Videos auf einer embedded-Plattform. Also Mikrocontroller(?), Display, Ram etc. Wie genau läuft das Decodieren ab? Das Video liegt im Flash vor, wird zur Laufzeit in den RAM geschoben, damit der Controller schnell auf die Daten zugreifen kann bzw. Decodieren kann? Welche Minimalanforderungen sind denn an die Hardware, speziell den Controller gestellt? Habe gelesen dass ein STM32 dafür nicht ausreichend wäre. Welche Anforderungen werden an die Displays gestellt? Gehe ich da einfach von der Framerate des Videos aus? Dh. wenn das Display 50-60 komplette Screens in einer Sekunde schafft, dann sollte es passen? Danke für eure Denkanstöße :)
Manfred schrieb: > Welche Minimalanforderungen sind denn an die Hardware, speziell den > Controller gestellt? Kommt auf das Video und dessen Auflösung und Bitrate an. Ein Raspberry Pi kann IMO ausreichen, muss aber nicht. Manfred schrieb: > Habe gelesen dass ein STM32 dafür nicht ausreichend > wäre. Der bräuchte externen RAM und würde dann einige Minuten an einem Frame rechnen. Embedded Controller brauchen extra Hardware für Video Dekodierung, sonst bist Du schnell bei mehreren GHz Rechenleistung. Manfred schrieb: > Dh. wenn das Display 50-60 > komplette Screens in einer Sekunde schafft, dann sollte es passen Dann darf aber die Dekodierung nix zusätzlich kosten, d.h. die müsste parallel stattfinden.
Jim M. schrieb: > Ein Raspberry > Pi kann IMO ausreichen, muss aber nicht. er macht es in Hardware - in Software schafft er nicht.
Moin, > Wie genau läuft das Decodieren ab? Das Video liegt im Flash vor, wird > zur Laufzeit in den RAM geschoben, damit der Controller schnell auf die > Daten zugreifen kann bzw. Decodieren kann? Ueblicherweise haben solche Controller ein Filesystem und/oder Netzwerkstack, wo das Video herkommt. > > Welche Minimalanforderungen sind denn an die Hardware, speziell den > Controller gestellt? Habe gelesen dass ein STM32 dafür nicht ausreichend > wäre. Kommt auf die Aufloesung, Framerate und Bitrate des Videos an. Ueblicherweise wird die Decodierung aber eh' nicht von der CPU gemacht, sondern von einer spezialisierten Hardware, von der du als Normalsterblicher niemals irgendwelche Datenblaetter kriegst. Die laeuft aber ueblicherweise so, dass die CPU dem h264decoder sagt: Lieber Decoder, ich hab dir mal in dein Eingangpufferregister eine Adresse geschrieben, ab da stehen dann soviele Bytes Video im Speicher rum, wie ich dir in dein Eingangslaengenregister geschrieben hab. Decodiers, und schreib die Videoframes an die Adressen, die ich dir in deine entsprechenden Register programmiert hab', wennste fertig bist, mach' nen Interrupt (oder mit dem naechsten Brocken Video weiter, den ich dir dann auch wieder irgendwo hingeschrieben hab'). Das wars dann fuer die CPU mit x264 decodieren...Die muss dann hoechstens noch dem Videoscaler sagen, dass sie die Aufloesung von dem Zeugs, was die x264-HW-Decodiereinheit geschrieben hat, noch geaendert werden soll... > Welche Anforderungen werden an die Displays gestellt? Gehe ich da > einfach von der Framerate des Videos aus? Dh. wenn das Display 50-60 > komplette Screens in einer Sekunde schafft, dann sollte es passen? Das Display ist dem Controller eher wurscht. Ueblicherweise haben die dann entweder einen LVDS- oder HDMI-Ausgang aufm Chip. Da wird dann das Bild eines Framebuffers mit vorher eingestellten Parametern (H,V-Timing) von der Videoeinheit draufge-DMA-t. Gruss WK
Also da muss man erst mal gucken, was ist denn so ein Video überhaupt? - Ein gemultiplexter Datenstrom, den man auseinanderklabüstern muss. Da ist Ton drin, Videostream, gegebenenfalls noch Untertitel, ...: https://de.wikipedia.org/wiki/Containerdatei - Diese demultiplexten Datenströme muss man nun in Frames aufbereiten für den Decoder. Erst jetzt geht es an die Hauptarbeit. - Ein h264 oder neuerer Datenstrom ist nicht einfach Huffman-kodiert, was auch eine µC-CPU noch berechnen kann, sondern komplexer komprimiert: Stichwort CABAC (context adaptive binary arithmetic coding, https://de.wikipedia.org/wiki/Context_Adaptive_Binary_Arithmetic_Coding ). Das alleine lastet beispielsweise einen alten Pentium voll aus. - Erst jetzt kommen die eigentlichen Frame-Daten (komprimiert) zum Vorschein: https://de.wikipedia.org/wiki/H.264#Technische_Details . - Das macht man daher besser in Hardware, da viele Millionen Rechenschritte nötig sind, um aus Referenzbild, Differenz, Frequenz- in Bildwert-Konversion, ... in die Zielbuffer zu schreiben. Moderne Codecs verwenden als Referenz problemlos 3 oder mehr vollständige Bilder. Alleine diese hoffnungslos vereinfachte Darstellung zeigt schon, das programmiert man nicht eben schnell selbst, und vor allem schafft das ein µC nicht ohne spezialisierte DSPs.
:
Bearbeitet durch User
Das Problem mit Mikrocontrollern ist der verfügbare RAM. Du musst im Prinzip (je nach Codec) mindestens 3-5 volle Frames gleichzeitig im Speicher halten können (aktuellen "Golden Frame", letzten I-Frame, letzten Frame, aktuellen Frame, zukünftigen Frame). 5 Frames bei FullHD sind knapp 40 MB, damit fällt so ein gewöhnlicher STM32 schonmal aus. Und du möchtest auch leicht schneller als Echtzeit dekodieren können, um bei eingangsseitigen Aussetzern trotzdem noch flüssig darstellen zu können. Über die Rechenleistung brauche ich vermutlich nichts zu schreiben, die fehlt da auch. Nachtrag: Ein "MPEG4 Simple Profile"-Video (also nicht MPEG4/AVC, sondern MPEG4 Part 2) sollte aber auf einem STM32 problemlos machbar sein. Ob das aber sinnvoll ist, sei mal dahingestellt.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.