Ich schreibe derzeit an einer Arbeit für die Uni, die sich mit einem Qualitätsvergleich (hinsichtlich Verzögerungszeiten, entstehend durch die Rechenzeit des Codecs) von 2 Videosystemen beschäftigt.
Meine Frage: Kann man pauschal sagen: "Je mehr Frames ein Video hat, das vom Codec verarbeitet werden muß, desto höher wird die resultierende Verzögerung sein?"
Am Besten wäre es, wenn ihr mir eine sogar eine Quelle (Internet, Literatur) nennen könntet, die diesen Schluß bestätigt! Ich hab schon ewig rumgesucht aber nie ne wirklich konkrete Antwort gefunden.
Bei Encoding und Decoding beim Streaming von einer Kamera wird es ja zwangsläufig zu Verzögerungen kommen. Ich habe diese Verzögerungen bei 2 unterschiedlichen Systemen getestet ...
Das Problem: Ein System streamt 25 Fields, dass andere 25 Frames. Bei dem System das weniger Bilder sendet ist die Verzögerungszeit höher. Zum Vergleichen müssten eigentlich beide System unter identischen Voraussetzungen laufen (also auch die gleiche Menge an Frames senden), dass ist aber technisch nicht realisierbar.
Meine Frage: Das System mit 25 Fields ist ohnehin langsamer. Kann man pauschal die These aufstellen, dass (würde man es mit 25 Frames betreiben können - also mit doppelter "Bildmenge") die Verarbeitung von weiteren Bilder zu noch höheren Verzögerungszeiten führen würde (weil der Codec ja mehr leisten muß) und somit den Schluß ziehen, dass das andere Videosystem effizienter arbeitet?
Und: Kennt jemand eine Quelle, die belegt: "Mehr zu verarbeitende Bilder führt zu höheren Verzögerungszeiten beim Codec"?!
P.s.: Es geht nicht um Verzögerungen die aufgrund von mangelnder Übertragungsgeschwindigkeit entstehen, diese ist mehr als hinreichend!
Hmm ... Es ist in der Tat ein ziemlich komplexes System. Also nochmal ein Erklärungsversuch:
Im MPEG-Standard werden bilder komprimiert. Durch die Komprimierung der Bilder wird die Datenrate gesenkt, allerdings hat der CODEC mehr Rechenarbeit. Durch die Rechenarbeit entstehen Verzögerungen im Videosystem.
Kann pauschal behauptet werden, die Kodierung eines Videos mit 25 Vollbildern (Frames) pro Sekunde dauert länger als die Verarbeitung von 25 Halbbildern (Fields, entspricht 12,5 Vollbildern)?!
Das ist doch eigentlich ne ganz einfache Frage und ich will nur die Bestätigung haben, dass ich mit der Folgerung richtig liege und bei der Verteidigung bei der Arbeit keine blöden Fragen auftauchen ;-)!
Anonymous hat geschrieben:
Kann pauschal behauptet werden, die Kodierung eines Videos mit 25 Vollbildern (Frames) pro Sekunde dauert länger als die Verarbeitung von 25 Halbbildern (Fields, entspricht 12,5 Vollbildern)?!
Ich sag jetzt einfach mal JA: Ist doch eigentlich logisch, dass die Verarbeitung von 25 Vollbildern längern dauert als die von 12,5 Vollbildern.
Jetzt die Philosophie: Das stimmt natürlich nur, wenn das alles ist, was du komprimierst. Hast du einen Film, der aus 1000 Blöcken à 12,5 Bildern besteht und einen der aus 500 Blöcken à 25 Bildern besteht, dann wird keine Unterschied zu bemerken sein.
Die Frage ist ja: Vergleichst du 25 Vollbilder mit 50 Halbbildern? Oder mit 25 Halbbildern? Welche Auflösung haben die Halbbilder? Haben die die halbe Auflösung wie die Vollbilder? Oder haben sie dieselbe, nur das jede zweite Zeile leer ist...? Fragen über Fragen...
Gast hat geschrieben:Habe selten so einen wirres Zeug gelesen.
soahC hat geschrieben:Sorry, echt, aber ich verstehs immernoch nicht.
Dem schließe ich mich an und frage mich, wo mein Denkfehler liegt? Wenn mein Computer ein Video rendert (beispielsweise aus After Effects, wo ich die Framerate und Bildgröße beliebig variieren kann), dann steht die Renderzeit selbstverständlich in direkter Relation zur Gesamt-Anzahl der Frames, weil ja jedes Bild einzeln berechnet werden muss.
Logischerweise nimmt die Renderzeit auch dann zu, wenn die Bildwechselfrequenz (frames per second) erhöht wird, weil damit auch die Gesamt-Anzahl der Einzelbilder steigt. Setze ich zum Rendern einen schnelleren Rechner ein, dann nimmt die Renderzeit logischerweise wieder ab. Es sei denn, die Prozessorauslastung lag noch nicht bei 100 % oder das Rendern war computerintern nicht effektiv organisiert.
Inwieweit das auf DV-Quellen übertragen werden kann, ist wohl nur Theorie, denn DV läuft immer mit 25 fps (= 50 fields per second).
Tut mir leid, aber es ist wirres Zeug.
Man kann doch solch eine Frage nicht stellen ohne die Rahmenbedingungen zu definieren.
Ich nehme mal an, das "Videosystem" ist ein Studio, der Encoder ein Hardwareencoder.
Nur als Beispiel: Angenommen, die Kapazität des Encoders ist mit 25 fps nur zu 10% ausgelastet dann werden auch bei 100 fps keine zusätzlichen "Verzögerungen" entstehen. Ab irgendeiner Bildrate wird der dann aussteigen. Also nix Relatives, nur Absolutes.
Natürlich wird das Bild später auf dem Monitor erscheinen, als es in der Kamera aufgenommen wurde. Und vor dem Erscheinen auf dem Monitor muss es ja noch dekodiert, usw., werden. Die Lichtgeschwindigkeit ist nun mal endlich. Deshalb hat schliesslich jede grössere Lifeproduktion eine Continuity.
Die einzig mögliche Antwort ist: Ja, ich kann durch das Encoden von irgenwas in MPEG "Verzögerungen" erzielen, wenn ich unzweckmässige Ausrüstung einsetze.
Die "Rahmenbedingungen" würden alle nur noch mehr verwirren, glaubt mir ;-)! Es handelt sich um ein Überwachungssystem (Einsatz in größeren Projekten, z.B. Bahnsteigüberwachung).
Eine Kamera streamt ihre Bilder analog zum Encoder, der enkodiert und komprimiert die Daten. Die Daten werden über ein Netzwerk zum Decoder versendet und entweder analog oder digital ausgegeben.
Da es sich um ein Testsystem handelt, in dem nur geringe Distanzen überbrückt werden und Kamera & Monitor direkt nebeneinander stehen, sieht man die Verzögerung direkt (Werte liegen derzeit ungefähr bei 1/2 Sekunde). Das heißt, man merkt dass eine Bewegung auf dem Monitor mit Verzögerung ausgegeben wird (z.B. wenn man die Hand in die Kamera hält).
Da es sich bei beiden "Videos" um Streams handelt, gibt es natürlich kein definiertes Ende ....
Und jetzt möchtest du wissen, ob die erkennbare Verzögerung geringer wird, wenn du statt 25 fps (bsp. PAL-Bild) nur 12 fps (sozusagen Stroboskop-Effekt) übermittelst?
AndyZZ hat geschrieben:Und jetzt möchtest du wissen, ob die erkennbare Verzögerung geringer wird, wenn du statt 25 fps (bsp. PAL-Bild) nur 12 fps (sozusagen Stroboskop-Effekt) übermittelst?
funnyjanni hat geschrieben:Meine Frage: Kann man pauschal sagen: "Je mehr Frames ein Video hat, das vom Codec verarbeitet werden muß, desto höher wird die resultierende Verzögerung sein?"
Nein - jedenfalls nicht zwangsläufig. Schau Dir den (in diesem Forum häufiger diskutierten) Codec von DV und Digital 8 an. Dieser, DCT genannt, arbeitet nur innerhalb von Einzelbildern. Ergo: Wolltest Du statt eines Standard-PAL-Bildes per DCT beispielsweise HD-Bilder verarbeiten, brauchtest Du einen leistungsfähigeren Hardware-Encoder. Wenn der DCT-Encoder mit Müh und Not pro Sekunde gerade die 25 PAL-Bilder schafft, wird er ein höher aufgelöstes Bild nicht mehr in Echtzeit kodieren können.
Innerhalb bestimmter Grenzen (Hardware-Encoder haben ja nur 'ne endliche Arbeitsfrequenz) könntest Du aber durch Deinen DCT-Encoder sehr wohl mehr als 25 Bilder pro Sekunde mit PAL-Auflösung schicken - kodiert wird ja bei DCT nur innerhalb des Bildes; die Rechenzeit pro Bild ist also nur abhänig von der zu verarbeitenden Bildauflösung; nicht von der Zahl der Bilder pro Sekunde. (Wie gesagt: So lange die Hardware grundsätzlich mitspielt.)
Die modernen, effizienteren Codecs - MPEG und Konsorten -, erreichen ihre höhere Kodiereffizienz wesentlich dadurch, dass sie über mehrere Bilder mitteln bzw. nur bestimmte Stützbilder vollständig übertragen. (Ich spare mir jetzt hier eine detailgenaue Erklärung, die solltest Du wissen oder nachschlagen können).
Heißt im Grundsatz: Hier ist die Verzögerungszeit immer länger, weil man ja wenigstens ein paar Bilder zwischenspeichern und die Unterschiede von einem zum anderen erkennen und in irgendeiner Form kodieren muss.
Würde jetzt nach meinem Verständnis bedeuten: Bei einem solchen System hängt die Verzögerung zunächst mal wesentlich davon ab, ob ich beispielsweise 25 oder 250 Bilder zur Datenreduktion heranziehe. Dann erst machen sich die tatsählich pro Sekunde zu übermittelnden Bilder bemerkbar sowie die Zahl der Bildpunkte pro Bild.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
