Forum: FPGA, VHDL & Co. Videostreaming, FPGA-Kamera


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich suche zur Erfassung mehrere gleichzeitiger Ereignisse eine 
Entwicklungsplattform für Bildverarbeitung auf FPGA-Basis. Könnt ihr mir 
etwas empfehlen? Im Grunde brauche ich zunächst nur bilder in 1280*960 
oder ähnlich bei einer Bildrate von 60 pro Sekunde. Wichtig ist Echtzeit 
um später  Ereignisse mit mehreren Kameras aufzunehmen, vielleicht auch 
bei höherer Bildrate. Habe bereits von Elphel (www.elphel.com) eine 
interessante Lösung gefunden, gibt es ähnliche Alternativen? Was wäre 
eine optimale Softwarelösung um mehrere Bildquellen zeitgleich 
auszuwerten (Matlab? OpenCV?) und als JPEG zu speichern?

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bei 1280x960 kommen viele Plattformen in Frage, ich wuerde etwas mit 
Xilinx Zynq Ultrascale+ nehmen, damit hat man eine Fuelle an 
Moeglichkeiten.

Was fuer Kameras wilst du denn anschliessen? Was sind deine 
Schnittstellen? Hier kann man die Auswahl dann wieder etwas eingrenzen.

von A. S. (rava)


Bewertung
0 lesenswert
nicht lesenswert
ich verstehe gerade nicht, wonach du suchst.
Du möchtest Kameras "anschließen" und die Bilder zeitstempeln. Ok. Aber 
dann fragst du nach einer Auswertungsmethodik? Wenn ich mich nicht irre, 
tun sich sowohl Matlab als auch OpenCV mit FPGAs schwer. Also sollen die 
FPGAs die Daten nur wegspeichern und die Auswertung geschieht am 
Rechner? Warum nicht gleich ein Echtzeitbetriebssystem auf den Rechner 
spielen und alles dort laufen lassen?

Oder, falls das unbedingt im FPGA sein muss: was heißt denn 
"Auswertung"? Wie komplex wird's da? Läuft ein neuronales Netz mit 
Millionen von Parametern? Oder wird nur die druchschnittliche Helligkeit 
der Bilder verglichen?

von Videomann (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Andreas schrieb:
> 1280*960

Das ist Tech von vorgestern. Mein Kunde hat schon vor 4 Jahren komplett 
auf HDMI2.0 umgestellt und arbeitet jetzt auf 3840x2160.

Momentan gibt es preiswerte HDMI-fähige Überwachungskameras von den 
Chinesen, die direkt über IP senden. Kriegt man über Kabel bis zu 8 
Stück dran. Auf Wunsch GigEVision. geht mir frame grabbern direkt in den 
PC. Manuelle Verarbeitung mit Video-Chips, DSPs inklusive Bildfusion, 
wenn unbedingt nötig. Brauchen aber nur wenige Kunden.

FPGAs braucht man da gar keine mehr für, es sei denn, dort muss eine 
Sonderverarbeitung rein. Militär z.B.

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für Eure Tipps!

@Tobias:

Das sollten fertige Kameramodule sein, mit paralleller Ausgabe.
Ich habe noch von Micron ein Developer Kit. Schnittstellen zum PC sind 
USB oder Ethernet. Mit günstigen USB kameras habe ich bereits 
experimentiert, da dauert es aber teils bis zu 100ms bis das Bild 
eintrifft. Per Ethernet habe ich vermutlich bessere Karten.

@rava: Die Auswertung soll selbstverständlich auf dem PC laufen. 
Entschuldige die unpräzise Angabe. Das FPGA soll zunächst die Daten nur 
schnell an den PC liefern, am liebsten schon JPEG-komprimiert. Alles 
andere kommt später. Ich muß nur wissen wann die Bilder gemacht wurden 
(auf ms genau). Also brauche ich nur den Zeitstempel vom FPGA und irgend 
eine Möglichkeit in der Software darauf zuzugreifen.

Mir ist auch klar, dass es dafür Fertiglösungen von Machine Vision 
Anbietern gibt, die alleridngs sehr kostspielig werden sobald man sie 
programmieren will.

von Andreas (Gast)


Bewertung
1 lesenswert
nicht lesenswert
@Videomann: Ich brauche nicht mehr als die Auflösung, auch wenn es 
Schnee von gestern ist. HDMI ist keine Option...
Schliesslich soll ein einfacher Algorithmus auf dem FPGA laufen, deshalb 
ist das zunächst so angedacht.

von Videomann (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Die Kameras haben heute selber alle FPGAs drinnen, die so ziemlich alles 
können, was man da machen kann und muss. Alles fertig parametrierbar. 
Schau dich mal bei den Industriekameras um. Es gibt allein in DE >10 
Hersteller, die sowas haben.

von janvi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
von Lattice gibts eine VIP Demo Board. (Video Interface Platform) Sind 
auch komplette gleich zwei Sony Sensoren drauf die gleich ein Bild 
abgeben. Die Deep Learn Bibliotheken dazu heissen Caffe und TensorFlow. 
Auswertung auf dem PC ist wegen der Leistungsaufnahme, dem schlechten 
Echtzeitverhalten, der miserablen Zuverlässigkeit, den langen Bootzeiten 
usw. zumindest beim autonomen Fahren und anderen wichtigen Anwendungen 
verpönt

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

das VIP hätte ich jetzt auch empfohlen, allerdings dann mit dem 
separaten Zusatzbrett mit GigE und USB3-Option. Da gibts auch fertige 
Referenzdesigns zum Streaming per YUV-raw oder MJPEG per RTP, guck mal 
nach RFC2435. Auf PC-seite bist du mit gstreamer sehr flexibel was 
Verarbeitung/Speicherung angeht. Wieviel Resourcen braucht deine 
Verarbeitung? Allenfalls wird's irgendwann mit BRAM eng, debayer und 
jpeg sind kleine Speicherfresser.

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok, bin jetzt einen Schritt weiter. Das Lattice-Kit paßt wohl ganz gut 
für einen ersten Ansatz. Habe auch schon einen freien JPEG-Encoder bei 
opencores.org gefunden. Die Blockartefakte bei hoher Kompressionsrate 
bereiten allerdings noch etwas Kopfschmerzen. Kennt jemant eine gute 
Alternative? Gibt es verbesserte Algorithmen oder sollte man besser auf 
JPEG2000 gehen?
Ich brauche keine neuronalen Netze oder solches. Der Algorithmus ist wie 
gesagt recht einfach und sollte wenig Blockram benötigen.

von Kameraentwickler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nimm sonst h264, JPEG und JPEG2000 sind nicht low latency. Die Bloecke 
sind bei h264 kleiner und stoeren weniger. Opencores kannst vergessen. 
Guck mal bei https://github.com/bcattle/hardh264.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Weiss nicht, was jetzt bei euch als "low latency" gelten soll, aber die 
minimalen 8 Bildzeilen (und ein paar zerquetschte) bei JPEG sind mehr 
als ausreichend, gemessen daran, dass auch bei einem 
Rolling-Shutter-Sensor intern schon einiges an Verzögerung anfallen 
kann. Das ist allerdings bei den meisten Sensoren, die Rohdaten 
ausgeben, deterministisch (also Zeitpunkt der Aufnahme bestimmbar). Wozu 
brauchst du dann noch low latency?
Bei JPEG2k kriegt man's mit Tiling auch in die Richtung, zumindest wenn 
man einiges vom Standard abspeckt, hat dann aber auch wieder irgendwann 
Block-Artefakte.
Bei JPEG kann man mit cleverem Residual-Coding die Block-Artefakte 
wegbekommen. Ist aber nicht mehr Standard und nicht mal eben so 
implementiert. Bin gespannt, wie sie's beim (zukünftigen) JPEG XS 
hinkriegen.
Bei h264 ist "low latency" recht "bedingt" und der Encoder deutlich 
komplexer.
Viel Spass kannst du bei den opencores-Sachen aber schon mal mit 
effizientem Streaming haben. Es macht einen grossen Unterschied, ob ein 
Codec nur ein "Beschleuniger" ist oder richtig synchron arbeitet. 
Ansonsten gilt, wie fast immer: Zeit ist Geld (wenn nicht Lernprojekt), 
darum würde ich mich auf den Kernalgo fokussieren und die Kompression 
wenn nötig ganz am Schluss dazukaufen.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:

> Per Ethernet habe ich vermutlich bessere Karten.
>
> @rava: Die Auswertung soll selbstverständlich auf dem PC laufen.

Da du das eine erkannt hast und das andere sowieso willst, dann verstehe 
ich nicht, wozu jetzt noch ein FPGA gut sein soll.

Es gibt doch fix und fertige Überwachungskameras, die einen RTSP-Stream 
liefern. Und selbst in recht hoher Qualität sind die nichtmal mehr allzu 
teuer (~400€ für full HD). Und sie enthalten bei diesem Preis sogar 
schon eine fertige Entzerrung für die Optik, Bewegungserkennung und 
weiteren Schnickschnack, den man benutzen kann, aber nicht benutzen 
muss...

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:

> @rava: Die Auswertung soll selbstverständlich auf dem PC laufen.
> Entschuldige die unpräzise Angabe. Das FPGA soll zunächst die Daten nur
> schnell an den PC liefern, am liebsten schon JPEG-komprimiert. Alles
> andere kommt später. Ich muß nur wissen wann die Bilder gemacht wurden
> (auf ms genau). Also brauche ich nur den Zeitstempel vom FPGA und irgend
> eine Möglichkeit in der Software darauf zuzugreifen.

Vergiss das FPGA.

https://www.ximea.com/en/products/xilab-application-specific-custom-oem/embedded-vision-and-multi-camera-setup-xix/sony-imx174-fast-color-industrial-camera

Da bekommst Du per PCIe die rohen Kameradaten direkt mit 10 MBit/s in 
Deinen Hauptspeicher geschrieben. Ohne weitere Latenzen. Direkter gehts 
nicht. Triggern kannst Du per Software oder per Hardware 
(Trigger-Signal-Inputs und Outputs vorhanden). Dann weißt Du wirklich, 
wann das Bild entstanden ist. Global Shutter ist dann auch nützlich.

fchk

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Da du das eine erkannt hast und das andere sowieso willst, dann verstehe
> ich nicht, wozu jetzt noch ein FPGA gut sein soll.

Es gibt schon eine Reihe von Sachen, die man mit einem Bild on the fly 
machen kann (und auch muss), bevor es in die Bildauswertung auf einen 
Rechner geht. Das haben schon einige lernen müssen. Idealerweise packt 
man die Daten, die der FPGA aus dem Bild ermittelt in den Datenstrom zum 
PC mit hinein. Wenn allerdings die Karte nur den Videokanal hat, dann 
wird das wiederum etwas tricky, geht aber.

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
So - hat etwas gedauert, bin jetzt ein Stück weitergekommen mit dem Kit 
von Lattice.
Der Sensor ist allerdings nicht in unserem Sinn, aber das spielt für den 
Algorithmus keine Rolle. Sorry daß ich darauf nicht näher eingehen kann. 
Mir auch klar, daß die guten Tips nicht für lau sind, aber ich wollte 
trotzdem noch ein Thema anschneiden: Bildkompression. JPEG haben wir 
evaluiert, Problem ist die Bildqualität, sonst ist die Verzögerung 
optimal. Welche Verfahren sind sonst noch im FPGA umsetzbar, kann man 
verlustfreie Verfahren sinnvoll mit niedriger Latenz im Prinzip 
schaffen, oder sollte man einen fertigen Standardcodec einkaufen?
Bisher haben wir Tests mit PNG und WebP gemacht, die ausreichend 
komprimieren. Kann also in der Richtung sein.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:
> Problem ist die Bildqualität
Klar ist JPEG verlustbehaftet. Aber die Frage ist ja: muss es unbedingt 
verlustfrei sein? Steckt in jedem Pixel eine Information, die genau so 
vom Bilsaufnehmer bis zur Anzeige/Verarbeitungssystem übertragen werden 
muss? Oder reicht es nicht aus, wenn das JPEG Bild "ausreichend gut" 
ist, weil die Information in der Gesamtheit des Bildes steckt (wie das 
z.B. bei Fotos oder Filmen so üblich ist)?

von fchk (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Komprimierung und algorithmische Auswertung von Kamerabildern vertragen 
sich nicht gut. Das gilt umso mehr, je schlechter die Bildqualität wird.

Mein Arbytegeber setzt daher PCIe-Kameras ein, die ihre Daten im 
Rohformat in Echtzeit direkt in den Hauptspeicher des PCs schreiben. 
PCIe Gen2 mit 2 oder 4 Lanes und 5 Gbit/s pro Lane lassen genug Luft für 
reichlich Megapixel bei bis zu 200 Frames pro Sekunde.

Dieses Vorgehen hat sich hier sehr bewährt.

fchk

von Camera posterior bulbi (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Andreas schrieb:
>> Problem ist die Bildqualität
> Klar ist JPEG verlustbehaftet. Aber die Frage ist ja: muss es unbedingt
> verlustfrei sein? Steckt in jedem Pixel eine Information, die genau so
> vom Bilsaufnehmer bis zur Anzeige/Verarbeitungssystem übertragen werden
> muss?

Genau, wie Ex-Cheffe (Bildverarbeitungsbude) zu sagen pflegte, JPEG ist 
verlustfrei, weil es das Rauschen entfernt und mehr als 10bit pro 
Farbkanal sind unnötig weil der Mensch eh nur ca. 1000 Farbtöne 
unterscheiden kann und die beiden unteren bits ohnehin im 
Sensor/ADC-Rauschen untergehen.

Cheffe hatte da einen eigenen Komprimieralgo, der ca 1000 Logicelemente 
benötigte. Ansonsten mal in den Klassiker ISBN: 978-3642130960 schauen, 
worauf es wirklich ankommt.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Camera posterior bulbi schrieb:
> mehr als 10bit pro Farbkanal sind unnötig weil der Mensch eh nur ca.
> 1000 Farbtöne unterscheiden kann
Mit 10 Bit pro Farbe kann ich aber über 1000³ unterschiedliche Farben 
darstellen. Da meinte er vermutlich 10 Bit für die gesamte 
Farbinformation.

von Camera posterior bulbi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Camera posterior bulbi schrieb:
>> mehr als 10bit pro Farbkanal sind unnötig weil der Mensch eh nur ca.
>> 1000 Farbtöne unterscheiden kann
> Mit 10 Bit pro Farbe kann ich aber über 1000³ unterschiedliche Farben
> darstellen. Da meinte er vermutlich 10 Bit für die gesamte
> Farbinformation.

Njein, er bezog sich auf die Grauwert-Digitalisierung eines Sensors mit 
Bayer-Matrix. Genaugenommen sprach er also nicht von Farbtönen sondern 
Helligkeitsabstufubgen einbes Graukeils die das Säugetierauge noch 
auflösen kann.

https://www.hardwareluxx.de/images/stories/newsbilder/tfreres/2015/10-bit-ausschnitt-71cbac2d6216df6e.jpg

Um die Frage zu beantworten, wieviel Farben tatsächlich nötig sind, 
müsste man vielleicht zu einem Palettenbasierenden System zugreifen, 
weil bspw tiefere Grünauflösung wohl wichtiger für die 
Bild(Helligkeits-) Information ist (deshalb hat eine Bayer-matrix auch 
doppelt soviel grün-Filter). ein Bild mit einer gut gewählten Palette 
von 1024 wirkt deutlich natürlicher als eins mit 3:4:3 bit R:G:B

https://en.wikipedia.org/wiki/Indexed_color

von Hein (Gast)


Bewertung
0 lesenswert
nicht lesenswert
fchk schrieb:
> PCIe Gen2 mit 2 oder 4 Lanes und 5 Gbit/s pro Lane lassen genug Luft für
> reichlich Megapixel bei bis zu 200 Frames pro Sekunde.

Welche Kameras und wieviele lanes?

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Hein schrieb:
> fchk schrieb:
>> PCIe Gen2 mit 2 oder 4 Lanes und 5 Gbit/s pro Lane lassen genug Luft für
>> reichlich Megapixel bei bis zu 200 Frames pro Sekunde.
>
> Welche Kameras und wieviele lanes?

verschiedene mit 2 oder 4 Lanes.

z.B.:
https://www.ximea.com/en/products/xilab-application-specific-custom-oem/Embedded-vision-cameras-xiX

oder

https://www.ximea.com/support/wiki/xib/PCI_Express_camera_-_xiB

und davon dann bis zu 6 an einem Rechner.

Weniger Latenz geht nicht.

Und wer zeitstempeln will, will keinen Rolling Shutter, sondern Global 
Shutter.

fchk

: Bearbeitet durch User
von Jürgen S. (engineer) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Da meinte er vermutlich 10 Bit für die gesamte
> Farbinformation.
Die meisten industriellen Kameras haben einen 10Bit Ausgang pro Farbe. 
Ich hatte auch schon welche mit 12 Bit x 3 und 10 Bit x 4 (RGBX).
Sensoren liefern durchaus noch mehr. Luminance mit 16 Bit in variabler 
lokaler Dynamik. Vor Zeiten war ich mal in Sensorproduktion involviert, 
welche >120dB absolute Dynamik hatten.

Im Consumerbereich wird nur abgeschnitten, entrauscht und reduziert. Je 
nachdem, was an Beleuchtung da ist.
Das liegt am HDMI-Standard der ersten Generation, bei dem man nicht 
ausreichend Bandbreite hatte. Auch mit HDMI 2.0 gehen 10 Bit nicht in 
4:4:4 mit 60Hz.


Camera posterior bulbi schrieb:
> weil der Mensch eh nur ca. 1000 Farbtöne
> unterscheiden kann und die beiden unteren bits ohnehin im
> Sensor/ADC-Rauschen untergehen.
Für Bildverarbeitung ist es unerheblich, was der Mensch sieht.
Man kann auch im Rauschen Information über Bildhinhalte ermitteln und zu 
Messungen und Berechnungen heranziehen.
Geht dann frequenztechnisch von langen Bildfiltern bis hin die 
Auflösungsgrenze des Optik, wenn nur noch 2 pxl angesteuert werden.
Muss nur die richtige Sorte Filter drauf. Das konnte ich unlängst 
eindrucksvoll darlegen!

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mehr als 8 bit sind momentan nicht das Thema, aber kann noch werden. 
Der Algorithmus arbeitet nicht auf dem komprimierten Datenstrom, aber 
fürs speichern der Sequenzen (Archivierung von Ereignissen) wäre 
Kompression vorgesehen. Es ist schlußendlich kein PC mehr im Spiel, 
außer für Loggen und nachträgliche Auswertung, der Zeitstempel ist nur 
noch für Synchronisation.
JPEG ist eigentlich ok, aber die Artefakte stören eben.
Rolling Shutter ist jetzt auch nicht das große Problem, den Sensor 
wechseln wir dann einfach aus wenn mehr Qualität gefordert wird. Ich 
stelle mir da einfach nur eine Realisierung von PNG o.ä. im FPGA vor 
aber muß auch auf Ressourcen achten

von Hein (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:
> im FPGA vor
> aber muß auch auf Ressourcen achten

Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin. 
Muss nur angeschlossen werden.

von Camera posterior bulbi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hein schrieb:
> Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin.
> Muss nur angeschlossen werden.

Sinnfreier Hinweis da:


Andreas schrieb:
> So - hat etwas gedauert, bin jetzt ein Stück weitergekommen mit dem Kit
> von Lattice.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hein schrieb:
> Andreas schrieb:
>> im FPGA vor
>> aber muß auch auf Ressourcen achten
>
> Die Zynq Ultras haben einen internen MPEG Kopressor in Hardware drin.
> Muss nur angeschlossen werden.

Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil 
in Logik macht und externen DDR Speicher braucht.

Wenn das aber kein Problem darstellt, ist das eine Klasse Sache.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas schrieb:
> Welche Verfahren sind sonst noch im FPGA umsetzbar, kann man
> verlustfreie Verfahren sinnvoll mit niedriger Latenz im Prinzip
> schaffen, oder sollte man einen fertigen Standardcodec einkaufen?
> Bisher haben wir Tests mit PNG und WebP gemacht, die ausreichend
> komprimieren. Kann also in der Richtung sein.

WebP ist m.E zu komplex für's FPGA, aber den PNG-Prädiktor kriegst du 
gut umgesetzt und kommst mit dem klassischen Bitplane-Coding und 
nachgeschaltetem Huffman-Coder auf ähnliche Kompressionsraten im 
verlustfreien Bereich, die Latenz ist da im Bereich von Bildzeilen. 
Hängt halt immens von der Bildquelle ab, ob monochrom oder Farbe, durch 
Optik bedingte Korrelationen, Bayer-Pattern usw.
Wenn's nahezu verlustfrei (kaum sichtbare Artefakte) sein darf, kriegst 
du mit blockweiser Wavelet-Dekomposition à la JPEG2k und Quantisierung 
ganz gute Ergebnisse. Fürs FPGA sind mir allerdings keine 
OpenSource-Codecs bekannt, und eine Eigenentwicklung ein recht 
aufwendiges Unterfangen.
Bei 'nearly lossless' scheiden sich generell die Geister, da gibt es 
eine Menge unterschiedlicher Metriken (PSNR, SSIM, ...). Siehe auch 
encode.ru.

Tobias B. schrieb:
> Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil
> in Logik macht und externen DDR Speicher braucht.

Die Latenz scheint da nur recht hoch zu sein, wie hoch konnte mir der MA 
auf der Messe allerdings nicht sagen.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Tobias B. schrieb:
>> Sogar mit H.264 und 265. Man muss nur beachten, dass der einen Grossteil
>> in Logik macht und externen DDR Speicher braucht.
>
> Die Latenz scheint da nur recht hoch zu sein, wie hoch konnte mir der MA
> auf der Messe allerdings nicht sagen.

Jep, das ist aber auch logisch und Codec bedingt, da holt man nicht mehr 
viel raus. Bei den Kodierungsverfahren gehen die Algorithmen auch 
zeitlich ueber die Frames. In PG252 sind die verschiedenen Latenzen 
angegeben und reichen von 1 (beim Encoding) bis 5 (beim Decoding) 
Frames.

Ist halt die Frage ob man wirklich H264 und H265 mit Echtzeit 
kombinieren muss (Kompressionsverfahren und Echtzeit beissen sich immer 
gegenseitig). Spontan faellt mir da nicht wirklich was ein, zumindest 
nicht bei Kamerasystemen in Broadcast, Automotive und Medizin. Beim 
Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle und 
selbst wenn, dann sind die ~80 ms auch kein Beinbruch (selbst fuer viele 
Echtzeitanwendungen ist das noch in Ordnung).

: Bearbeitet durch User
von Bernd (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle
Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der 
Rechner über Nacht durchlief, um das Video auf CD-Größe zu bringen ;-)

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Bernd schrieb:
> Tobias B. schrieb:
>> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle
> Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der
> Rechner über Nacht durchlief, um das Video auf CD-Größe zu bringen ;-)

Stimmt, tolles Extrembeispiel! :-D

von Hotte (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
Bernd schrieb:
>> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle
> Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der

Hier verwechselt jemand Latzenz mit Bandbreite. Klar ist die Latenz 
egal, aber die Bilder müssen in Echtzeit verpackt werden können und das 
erfordert power. Also nix mit "warten über Nacht".

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hotte schrieb:
> Tobias B. schrieb:
> Bernd schrieb:
>>> Beim Abspielen und Aufzeichnen von Content spielt Latenz keine Rolle
>> Jepp, früher(tm) beim DVD-Rippen hat es auch keinen gestört, wenn der
>
> Hier verwechselt jemand Latzenz mit Bandbreite. Klar ist die Latenz
> egal, aber die Bilder müssen in Echtzeit verpackt werden können und das
> erfordert power. Also nix mit "warten über Nacht".

Ne, das passt doch. Der Xilinx Core schafft von der Bandbreite De- und 
Encoding in 4K@30Hz (oder sogar 60Hz, muesste ich nachschauen), hat halt 
Algorithmen bedingt ein paar Frames Latenz.

Dann wurde diskutiert, dass es praktisch keine Anwendung bei dem diese 
Latenz eine Rolle spielt. Als Extrembeispiel wurde das DVD Rippen ins 
Feld gefuehrt. Von daher ist die Argumentationskette in Ordnung, ich 
denke hier ist jedem der Unterschied zwischen Bandbreite und Latenz 
bewusst. ;-)

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Jep, das ist aber auch logisch und Codec bedingt, da holt man nicht mehr
> viel raus.

Könnte man aber eigentlich. Mit streifenweiser Codierung schafft man bei 
h264 auch sub-frame Latenzen, da kann der Monitor bzw. Framebuffer noch 
eher der Bösewicht sein (Ende zu Ende überprüft mit Lichtblitz und 
Fototransistor).

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Könnte man aber eigentlich. Mit streifenweiser Codierung schafft man bei
> h264 auch sub-frame Latenzen, da kann der Monitor bzw. Framebuffer noch
> eher der Bösewicht sein (Ende zu Ende überprüft mit Lichtblitz und
> Fototransistor).

Kannst ja mal in PG252 reinschauen. Da gibts ein ganzes Kapitel zu dem 
Thema und evtl. ist diese Option sogar vorhanden?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.