1. Foren
  2. Kommentare
  3. Audio/Video
  4. Alle Kommentare zum Artikel
  5. › HEVC: Fernmeldeunion gibt…

Mal wieder Scalable Video

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Mal wieder Scalable Video

    Autor: Casandro 26.01.13 - 12:14

    Schade, dass sich das früher nicht durchgesetzt hat. Die Idee dahinter ist, dass man einen Datenstrom in einer geringen Auflösung hat, und dann nur die Unterschiede zu den hohen Auflösungen überträgt. Damit kann man beispielsweise SD, HD und UHD so übertragen, dass man nur einen Kanal braucht, die entsprechenden Geräte aber nur das dekodieren was sie darstellen.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  2. Re: Mal wieder Scalable Video

    Autor: caso 26.01.13 - 13:22

    Du willst dass dein Handy oder sonst ein Gerät z.B. einen FullHD-Stream ohne aktive Skalierprozesse als 320p Video anzeigt oder wie habe ich das zu verstehen?
    Da wird doch nur Bandbreite verschwendet außer bei Broadcast-Verbindungen.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  3. Re: Mal wieder Scalable Video

    Autor: Nephtys 26.01.13 - 13:30

    Casandro schrieb:
    --------------------------------------------------------------------------------
    > Schade, dass sich das früher nicht durchgesetzt hat. Die Idee dahinter ist,
    > dass man einen Datenstrom in einer geringen Auflösung hat, und dann nur die
    > Unterschiede zu den hohen Auflösungen überträgt. Damit kann man
    > beispielsweise SD, HD und UHD so übertragen, dass man nur einen Kanal
    > braucht, die entsprechenden Geräte aber nur das dekodieren was sie
    > darstellen.

    Das ist viel zu viel Verschwendung an Bandbreite.
    Da die Endgeräte leistungsfähiger werden ist es sinnvoller, die maximale Qualität zu übertragen und dann auf dem Gerät einfach runter zu skalieren. Klappt ja bei FullHD noch klasse.

    Da gilt das allgemeine Prinzip: lieber 1 Kern mehr im Handy als einen höheren Bandbreitenbedarf.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  4. Re: Mal wieder Scalable Video

    Autor: Casandro 26.01.13 - 18:21

    Naja, die Anwendungen sind Broadcast und andere "Massendistributionsformate". Der Nachfolger von BluRay könnte so was nutzen, damit könnte man billige Chinesenplayer anbieten, aber auch Super UHD Player für 2000 Euro. Und im Gegensatz zu DVD und BluRay wären die 2000 Euro Geräte sogar besser als die billigen.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  5. Re: Mal wieder Scalable Video

    Autor: netman 26.01.13 - 23:55

    > Das ist viel zu viel Verschwendung an Bandbreite.
    > Da die Endgeräte leistungsfähiger werden ist es sinnvoller, die maximale
    > Qualität zu übertragen und dann auf dem Gerät einfach runter zu skalieren.
    > Klappt ja bei FullHD noch klasse.

    Der Vorteil ist ja gerade keine Bandbreite zu verschwenden. Wenn du nur den Stream in niedriger Qualität haben willst ziehst du nur den. Wenn du aber hohe Qualität haben willst ziehst du niedrige Qualität + Differenz zur hohen.

    Im Fall von Rundfunk spart man dabei Bandbreite, da ein Sender nicht mehr in SD und HD ausgestrahlt werden muss, sondern kombiniert für beides.

    Bei Übertragungen an einzelne Teilnehmer fällt der Vorteil zwar weg, wird aber nicht zu einem Nachteil. Dafür sinkt der Speicherplatzbedarf auf Anbieterseite, da nur noch eine Version vorgehalten werden muss. Bei Seiten wie YouTube o.ä. dürften die Einsparungen durchaus beachtlich sein.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  6. Re: Mal wieder Scalable Video

    Autor: Mrdowst 27.01.13 - 05:37

    Die Idee ist sowohl Speicherplatz- als auch Bandbreiten-Ersparnis. In meiner Diplomarbeit (Dipl. Inform. Univ.) habe ich mich mit h264/svc beschäftigt, und schon dort waren die Möglichkeiten enorm. Svc ermöglicht die Skalierung mehrerer Qualitätsdimensionen in einem stream: Auflösung, framerate und Kompressionsstärke von einzelbildern. In jeder dieser Dimensionen können mehrere Schichten (layer) im Stream codiert werden. Hat man zB drei Schichten pro Dimension (Auflösung 1080p, 720p, 360p; fps 30, 15, 7.5; Kompression lossless, jpeg 80%, jpeg 40%), so kann man den Stream in jeder beliebigen Kombination von Schichten anbieten (3 x 3 x 3 = 27 Qualitätsstufen), und die "überschüssigen" Schichten bei der Übertragung weglassen, hat dabei aber nur eine codierte Datei vorliegen. Jede höhere Schicht nutzt die redundanten Informationen der jeweils darunter liegenden. In meinen Analysen ergab sich eine Speicherplatz Ersparnis von fast 50% gegenüber einzeln vorliegenden Streams in h264/avc in Sachen Auflösung. Bei fps und Kompressionsstärke ist diese Ersparnis zu vernachlässigen, da nur bewegungsvektoren wegfallen (fps), bzw. es nur bei keyframes (kompression) zum tragen kommt. Die Ersparnis bei der Bandbreite verhält sich genauso, wenn höhere Schichten weggelassen werden.
    Das eröffnet mehrere Möglichkeiten. Ich habe in meiner Arbeit einen proof-of-concept entwickelt, einen svc stream Server, welcher Hand in Hand mit einem Proxy arbeitet, der kontinuierlich zurück meldet, wie die Situation im Netz ist. Bei Einbruch der Bandbreite reagierte der Server mit Reduktion von Qualität um Bandbreite zu sparen und somit stalling (buffer-perioden) zu vermeiden. Dabei nutze ich Auflösung für grobe, und die anderen Dimensionen für feine Anpassung. Damit bekam man trotz schwankender Bandbreite ein kontinuierliches Video mit wechselnder Qualität ohne lästige Puffer Unterbrechung. Andere, aber nicht weniger interessante Möglichkeiten gibt es bei paketverlust zb in einem WLAN oder bei Mobilfunk. In diesem Fall reagierte mein Server auch mit Qualitätsminderung, nutzte jedoch die gesparte Bandbreite, um vorwärts-Fehlerkorrektur (forward error correction, FEC) auf den Stream aufzusetzen. Ich nutzte dazu luby-transform-Codes (Details würden diesen ohnehin schon zu langen Beitrag sprengen). Trade-off hierbei ist, typische durch paketverlust auftretende bildstörungen zu vermeiden, und dafür auf etwas Qualität zu verzichten.
    Alles in allem War es eine sehr spannende Geschichte, und ich freue mich auf h265, wo hoffentlich die vielen Fallstricke und Ungereimtheiten von h264/svc beseitigt sind. Meine Arbeit kann man im Netz finden ("Enhancing user-perceived quality of experience using SVC and FEC").

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Intel Edison ausprobiert: Ich seh dich - das Mona-Lisa-Projekt
Intel Edison ausprobiert
Ich seh dich - das Mona-Lisa-Projekt
  1. Intel Edison Kleinrechner mit Arduino-ähnlichem Board als Breakout

Test Far Cry 4: Action und Abenteuer auf hohem Niveau
Test Far Cry 4
Action und Abenteuer auf hohem Niveau

Android 5.0: Lollipop läuft schneller ohne Dalvik und länger mit Volta
Android 5.0
Lollipop läuft schneller ohne Dalvik und länger mit Volta
  1. Lollipop Android 5.0 für deutsche Nexus-Geräte ist da
  2. SE Android In Lollipop wird das Rooten schwer
  3. Android 5.0 Lollipop wird für Nexus-Geräte verteilt

  1. Kaspersky Lab: Cyberwaffe Regin griff Mobilfunk-Basisstationen an
    Kaspersky Lab
    Cyberwaffe Regin griff Mobilfunk-Basisstationen an

    Regin kann Admin-Passwörter für Mobilfunk-Netzwerke auslesen und so Basisstationen angreifen. Zudem kann es wohl Geheimdienstschnittstellen nutzen. Die Cyberwaffe kam auch in Deutschland zum Einsatz.

  2. Halbleiterforschung: Neuer Memristor kann zehn Zustände speichern
    Halbleiterforschung
    Neuer Memristor kann zehn Zustände speichern

    Irische Wissenschaftler haben einen neuartigen Memristor entwickelt, dessen Widerstandswerte gezielt verändert werden können. Damit können in nur einem Bauteil zehn Werte gespeichert werden, was sich für völlig neuartige Computer nutzen lassen könnte.

  3. Transpiler: Googles Inbox zu zwei Dritteln plattformübergreifender Code
    Transpiler
    Googles Inbox zu zwei Dritteln plattformübergreifender Code

    Um native iOS- und Android-Apps sowie die Web-App für Inbox möglichst gemeinsam weiter zu entwickeln, setzt Google auf Transpiler, die Java in Javascript und Objective-C übersetzen.


  1. 19:05

  2. 18:23

  3. 18:07

  4. 17:44

  5. 17:00

  6. 16:17

  7. 15:56

  8. 15:35