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


Stacked Memory: Lecker, Stapelchips!
Stacked Memory
Lecker, Stapelchips!

Netzverschlüsselung: Mythen über HTTPS
Netzverschlüsselung
Mythen über HTTPS
  1. Websicherheit Chrome will vor HTTP-Verbindungen warnen
  2. SSLv3 Kaspersky-Software hebelt Schutz vor Poodle-Lücke aus
  3. TLS-Verschlüsselung Poodle kann auch TLS betreffen

Jahresrückblick: Was 2014 bei Golem.de los war
Jahresrückblick
Was 2014 bei Golem.de los war
  1. In eigener Sache Golem.de sucht (Junior) Concepter/-in für Onlinewerbung
  2. In eigener Sache Golem.de offline und unplugged
  3. In eigener Sache Golem.de sucht Videoredakteur/-in

  1. GSC Game World: Entwicklerstudio von Stalker neu gegründet
    GSC Game World
    Entwicklerstudio von Stalker neu gegründet

    Das ukrainische Entwicklerstudio GSC Game World ist wieder da und arbeitet bereits an einem neuen Spiel. Einer der Macher äußert sich auch zu Projekten, für die angebliche Ex-Stalker-Entwickler Geld sammeln.

  2. Android 5.0.2: Erstes Nexus 7 erhält weiteres Lollipop-Update
    Android 5.0.2
    Erstes Nexus 7 erhält weiteres Lollipop-Update

    Google hat für das Nexus 7 aus dem Jahr 2012 eine weitere Aktualisierung von Android 5.0 alias Lollipop veröffentlicht: Das Update 5.0.2 beinhaltet vor allem gerätespezifische Verbesserungen. So soll unter anderem die CPU-Leistung durch einige Kernel-Tweaks erhöht werden.

  3. Anonymisierung: Tor-Warnung verunsichert Betreiber von Exit Nodes
    Anonymisierung
    Tor-Warnung verunsichert Betreiber von Exit Nodes

    Weil das Tor-Projekt vor Angriffen auf das Anonymisierungssystem warnte, zeigte sich ein Betreiber von beliebten Exit Nodes aufgeschreckt. Als seine Server offline waren, befürchtete er eine Beschlagnahmung - nun ist er sich da nicht mehr so ganz sicher.


  1. 13:32

  2. 12:16

  3. 12:01

  4. 12:01

  5. 12:00

  6. 11:59

  7. 11:50

  8. 11:13