Frage von Ulf Jaenicke-Rößler:Hallo,
in einem VideoPlayer (;PC Anwendung) möchte ich Positionen im Video so
genau wie möglich anspringen. Verwendet wird dabei DirectShow. Mpeg
Dateien allgemein, solche mit variabler Bitrate verursachen naturgemäß
einige Probleme. Ich suche deshalb nach einer Möglichkeit, im Programm
oder auch separat mit externen Tools festzustellen, ob es sich bei einem
bestimmten Video um eine VBR Datei handelt.
Probiert habe ich die aktuelle Beta von GSpot, Bitrateview und
MPEGanalizzatore. Die beiden ersten liegen ziemlich häufig daneben
wie mir scheint (;sie zeigen VBR für Dateien an, von denen ich ziemlich
sicher weiß, dass es sich um CBR kodierte handelt). MPEGanalizzatore
zeigt viele Informationen an, in denen ich die richtige Information
leider auch nicht finde.
Deshalb die Frage: Wie kann ich VBR und CBR kodierte Dateien unterscheiden?
Worauf müsste ich z.B. bei MPEGanalizzatore achten? Gibt es ein anderes
Programm, das ich mal probieren sollte?
Viele Grüße
Ulf
Antwort von Benjamin Spitschan:
Ulf Jaenicke-Rößler wrote:
> in einem VideoPlayer (;PC Anwendung) möchte ich Positionen im Video so=
> genau wie möglich anspringen. Verwendet wird dabei DirectShow. Mpeg
> Dateien allgemein, solche mit variabler Bitrate verursachen naturgemä=
ß
> einige Probleme.
Was willst Du denn machen? Umcodieren nach CBR? CBR zu verwenden ist
ziemlich dämlich. Wenn Du in VBR springen willst, muxe Deinen Video
Elementary Stream (;ggfls. vorher demuxen) zu einem Program Stream. Da sin=
d
die "Sprunginformationen" (;Timecode usw.) dann gleich mit enthalten und
alles sollte klappen. Zum Muxen/Demuxen nimmst Du z. B. ProjectX. Wenn
nicht und Du einen vernünftiger Muxer verwendet hast, ist der Player
Schrott. Audio und Video in getrennten Dateien abzuspielen zu versuchen i=
st
auch waghalsig, obwohl es mit dem Mediaplayer Classic ja möglich ist. D=
a
kannst Du Sprünge natürlich gleich vergessen.
> Deshalb die Frage: Wie kann ich VBR und CBR kodierte Dateien unterschei=
den?
> Worauf müsste ich z.B. bei MPEGanalizzatore achten? Gibt es ein ander=
es
> Programm, das ich mal probieren sollte?
Den Bitrate Viewer von Teco [1]. Ich weiß nicht, ob das der war, den Du=
meintest, aber in diesem hier muß die gelbe Kurve einen waagrechten Ver=
lauf
zeigen, dann ist es CBR. Sowas aber geht z. B. auch in DVDlab (;Pro) im
Asset Windows.
Grüße, Benjamin
[1] http://www.tecoltd.com/bitratev.htm
Antwort von Ulf Jaenicke-Rößler:
Hallo,
vielen Dank für Deine Antwort!
Benjamin Spitschan schrieb:
> Was willst Du denn machen?
Die PC Anwendung ist ein Programm, das ich geschrieben habe. Über einen
austauschbaren Timecode (;MTC) sollen mehrere Instanzen auf verschiedenen
Rechnern synchron den Film wiedergeben (;DirectShow). Das klappt eigentlich
mit allen Filmen ganz gut, solange diese von Anfang bis Ende durchlaufen.
Leider ist das nicht der Normalfall, sondern bestimmte Positionen im Film
müssen angesprungen werden können (;etwa beim Sprung im Timecode), oder
Filme sollen anhalten und erst später weiterlaufen (;auch damit hatte ich
Probleme mit manchen Filmen).
> Umcodieren nach CBR? CBR zu verwenden ist ziemlich dämlich.
Zugegeben. Aber das ist eine einigermaßen zuverlässige Möglichkeit für
die Sprünge.
Leider habe ich, außer freundlichen Hinweisen, keinen Einfluss auf die
Erzeugung des Filmmaterials - weder Bitrate, noch Muxer/Demuxer.
Allerdings bleibt der Schwarze Peter trotzdem an mir hängen... :-(;
Zur Laufzeit zu demuxen/muxen erscheint mir nicht möglich, aber vielleicht
sollte ich einen zusätzlichen Schritt separat vorsehen. Muss ich mal überlegen.
> Den Bitrate Viewer von Teco [1]. Ich weiß nicht, ob das der war, den Du
> meintest, aber in diesem hier muß die gelbe Kurve einen waagrechten
> Verlauf zeigen, dann ist es CBR.
Ja, das war der. Das "Problem" damit war folgendes: Jemand hatte einen
VBR Stream erstellt und den, da die Vorgabe CBR war, "einfach" (;schlecht)
umkodiert. Immer noch war die gelbe Linie nicht waagerecht und der BitrateViewer
zeigte VBR an. Nicht, dass das ein Fehler des Programms war, aber ich hatte
gehofft, es gibt irgendwie einen Eintrag in einem Datei Header, der sagt,
ob VBR oder CBR ;-)
Danke nochmal für die Anregungen!
Viele Grüße
Ulf
Antwort von Benjamin Spitschan:
Ulf Jaenicke-Rößler wrote:
> Die PC Anwendung ist ein Programm, das ich geschrieben habe. Über ein=
en
> austauschbaren Timecode (;MTC) sollen mehrere Instanzen auf verschiedene=
n
> Rechnern synchron den Film wiedergeben (;DirectShow). Das klappt eigentl=
ich
> mit allen Filmen ganz gut, solange diese von Anfang bis Ende durchlaufe=
n.
> Leider ist das nicht der Normalfall, sondern bestimmte Positionen im Fi=
lm
> müssen angesprungen werden können (;etwa beim Sprung im Timecode), o=
der
> Filme sollen anhalten und erst später weiterlaufen (;auch damit hatte =
ich
> Probleme mit manchen Filmen).
Kannst Du nochmal genauer beschreiben? MTC ist dieser MIDI-Timecode.
Möchtest Du die Wiedergabe zentral von einem Master steuern? Das wird n=
ix.
Oder nur spezielle Abspielkommandos senden (;"jetzt Pause", "spiele ab
00:03:10.000", usw.)? Die Lösung wäre vermutlich ein DVD-ähnliches =
Multiplexing, bei dem Navigation Packs (;die sind genau zum Springen da)
eingefügt werden. Ist sowas machbar?
> Nicht, dass das ein Fehler des Programms war, aber ich hatte
> gehofft, es gibt irgendwie einen Eintrag in einem Datei Header, der sag=
t,
> ob VBR oder CBR ;-)
Nö, gibt's leider nicht... ;(;. Man kann es *theoretisch* am VBV-Delay
erkennen (;steht gemäßg Standard [ISO13818-2] bei VBR auf 0xFFFF, sons=
t ein
bestimmter Zahlenwert), aber das ist nur ein Indiz, weil den Decoder dies=
e
Infos heutzutage dank genügend Speicher egal ist (;das ganze dient näm=
lich
zur Berechnung der Puffergrößen).
Grüße, Benjamin
Antwort von Ulf Jaenicke-Rößler:
Benjamin Spitschan schrieb:
> Kannst Du nochmal genauer beschreiben? MTC ist dieser MIDI-Timecode.
Naja, ein Player kann MTC erzeugen und ausgeben. Die anderen empfangen
den MTC. Sie ermitteln die Position im Video anhand der Timecode Information.
> Möchtest Du die Wiedergabe zentral von einem Master steuern? Das wird
> nix. Oder nur spezielle Abspielkommandos senden (;"jetzt Pause", "spiele
> ab 00:03:10.000", usw.)? Die Lösung wäre vermutlich ein DVD-ähnliches
> Multiplexing, bei dem Navigation Packs (;die sind genau zum Springen da)
> eingefügt werden. Ist sowas machbar?
Normale Abspielkommandos kommen über TCP Netzwerk. Der Timecode dient
indirekt auch zum Steuern: Timecode "fällt aus", Timecode läuft, Timecode
springt. Dann müssen die Videos natürlich auch springen. Und das bringt
leider Probleme.
Das sind allerdings nicht die einzigen Schwierigkeiten mit Filmen.
Ich habe ein bisschen mit ProjectX gespielt und dabei wurde in einem
Problemvideo (;Absturz mit Elecard Dekoder) eine GOP Struktur ohne Frames
gefunden. ProjectX hat diese entfernt, seitdem läuft das Video. Ich musste
nur noch einstellen, dass die originale Bitrate erhalten bleibt, sonst stimmt
die Länge nicht mehr.
BTW, wenn ich Dich richtig verstanden habe, kann ProjectX auch muxen.
Stimmt das? Ich habe nämlich im Programm nichts dazu gefunden, nur zum
demuxen. Oder kann das an dem Binary liegen (;ozoon - 0.81.8)?
>> Nicht, dass das ein Fehler des Programms war, aber ich hatte
>> gehofft, es gibt irgendwie einen Eintrag in einem Datei Header, der sagt,
>> ob VBR oder CBR ;-)
>
>
> Nö, gibt's leider nicht... ;(;. Man kann es *theoretisch* am VBV-Delay
> erkennen (;steht gemäßg Standard [ISO13818-2] bei VBR auf 0xFFFF, sonst
Ja, das hatte ich irgendwo gelesen - das stimmte allerdings in den
Dateien die ich mir daraufhin angeschaut habe nicht. Die waren wohl
nicht Standard konform...
Viele Grüße
Ulf
Antwort von Benjamin Spitschan:
Ulf Jaenicke-Rößler wrote:
> Normale Abspielkommandos kommen über TCP Netzwerk. Der Timecode dient=
> indirekt auch zum Steuern: Timecode "fällt aus", Timecode läuft, Ti=
mecode
> springt. Dann müssen die Videos natürlich auch springen. Und das br=
ingt
> leider Probleme.
Wie realisierst Du in Deinem Programm das Springen? Die beste Lösung is=
t
wirklich diejenige mit Navigation Packs, so, wie es bei der DVD gemacht
wird. Das wären dann VOB-Dateien. Kannst Du nicht einen der freien
DVD-Player modifizieren, indem Du die Fernsteuerungsmöglichkeit einbaus=
t?
> BTW, wenn ich Dich richtig verstanden habe, kann ProjectX auch muxen.
> Stimmt das? Ich habe nämlich im Programm nichts dazu gefunden, nur zu=
m
> demuxen. Oder kann das an dem Binary liegen (;ozoon - 0.81.8)?
Ganz links statt "Demux" "to m2p" = MPEG2 Program Stream. Aber - wie
gesagt, ich würde am liebsten gleich auf VOB-Ebene arbeiten. Dann muß=
t Du
vorher aber alles ins DVD-Format multiplexen & simpel-authorn.
>> Nö, gibt's leider nicht... ;(;. Man kann es *theoretisch* am VBV-Dela=
y
>> erkennen (;steht gemäßg Standard [ISO13818-2] bei VBR auf 0xFFFF, s=
onst
>
> Ja, das hatte ich irgendwo gelesen - das stimmte allerdings in den
> Dateien die ich mir daraufhin angeschaut habe nicht. Die waren wohl
> nicht Standard konform...
Was da drin steht, ist wirklich egal, sodaß ich nicht mal von "nicht
standardkonform" sprechen möchte. Wichtiger ist z. B., daß der Stream=
generell nicht kaputt ist. Sind die Dateien denn DVB-Aufnahmen? Oder wer =
produziert solchen Schrott mit leeren GOPs?
Grüße, Benjamin
Antwort von Andre Beck:
Ulf Jaenicke-Rößler
writes:
>
> Die PC Anwendung ist ein Programm, das ich geschrieben habe. Über einen
> austauschbaren Timecode (;MTC) sollen mehrere Instanzen auf verschiedenen
> Rechnern synchron den Film wiedergeben (;DirectShow).
Aha. Du hast also volle Kontrolle sowohl über die Steuerung als auch
über die laufenden Streams. Dann ist das ja kein Problem.
> Das klappt eigentlich
> mit allen Filmen ganz gut, solange diese von Anfang bis Ende durchlaufen.
> Leider ist das nicht der Normalfall, sondern bestimmte Positionen im Film
> müssen angesprungen werden können (;etwa beim Sprung im Timecode), oder
> Filme sollen anhalten und erst später weiterlaufen (;auch damit hatte ich
> Probleme mit manchen Filmen).
>
>> Umcodieren nach CBR? CBR zu verwenden ist ziemlich dämlich.
>
> Zugegeben. Aber das ist eine einigermaßen zuverlässige Möglichkeit für
> die Sprünge.
Die Blödestmögliche. Mir fallen auf Anhieb zwei bessere ein: Selbst
demuxen und mit Navigationsinformationen neu muxen (;im einfachsten
Fall DVD-kompatible NAV-Packs, da gibts fertige Software), oder noch
einfacher, vorher indizieren und dann über den Index springen.
> Leider habe ich, außer freundlichen Hinweisen, keinen Einfluss auf die
> Erzeugung des Filmmaterials - weder Bitrate, noch Muxer/Demuxer.
Natürlich hast Du Kontrolle über den Mux. Du kannst jederzeit den
gelieferten Schrott demuxen und neu so muxen, wie Du es brauchst.
> Allerdings bleibt der Schwarze Peter trotzdem an mir hängen... :-(;
Dann musst Du halt zu brute force Methoden greifen ;)
> Zur Laufzeit zu demuxen/muxen erscheint mir nicht möglich, aber vielleicht
> sollte ich einen zusätzlichen Schritt separat vorsehen. Muss ich mal überlegen.
Eben. Vorher aufbereiten und fertig.
Nochwas: Warum streamst Du das nicht einfach über ein LAN? Dann ist das
100% synchron, denn die Player spielen einfach genau das, was da als
Transport Stream reinkommt, und wo der stehenbleibt, weiterläuft oder
springt bestimmt einzig der Master.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Benjamin Spitschan:
Andre Beck wrote:
> Die Blödestmögliche. Mir fallen auf Anhieb zwei bessere ein: Selbst=
> demuxen und mit Navigationsinformationen neu muxen (;im einfachsten
> Fall DVD-kompatible NAV-Packs, da gibts fertige Software), oder noch
> einfacher, vorher indizieren und dann über den Index springen.
Ja, das hatte ich auch vorgeschlagen. Welche Software meinst Du?
Grüße, Benjamin
Antwort von Andre Beck:
Benjamin Spitschan writes:
> Andre Beck wrote:
>> Die Blödestmögliche. Mir fallen auf Anhieb zwei bessere ein: Selbst
>> demuxen und mit Navigationsinformationen neu muxen (;im einfachsten
>> Fall DVD-kompatible NAV-Packs, da gibts fertige Software), oder noch
>> einfacher, vorher indizieren und dann über den Index springen.
>
> Ja, das hatte ich auch vorgeschlagen. Welche Software meinst Du?
Z.B. mplex gefolgt von dvdauthor. Beides quelloffen, kann man also an
seine Bedürfnisse anpassen.
Wobei mir wie gesagt die Idee, das zu streamen, ungleich besser gefällt.
Er hat ja laut Beschreibung ein IP-Netz, wahrscheinlich schlichtes LAN,
denn er synchronisiert schon über TCP. Nichts wäre einfacher, als darin
einen MPEG2 Transport Stream zu multicasten. Ausgangspunkt für die eigene
Entwicklung könnte z.B. vlc sein. Der ist schon modular, einen Modul
dranzustricken, der senderseitig für Stop/Go und Jump sorgt, ist wohl
nicht das größte Problem. Die Synchronität der Slave-Player ist dann
implizit gewährleistet, man braucht dort noch nicht mal komplette PCs,
es reichen geeignete Streaming Clients, Code-Beiträge, die interessante
Features hinzufügen, sind für das Projekt sicher gesund etc pp.
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Benjamin Spitschan:
Andre Beck wrote:
> Z.B. mplex gefolgt von dvdauthor. Beides quelloffen, kann man also an
> seine Bedürfnisse anpassen.
Achso, ja. Daran hatte ich auch gedacht. Ich dachte nur, dvdauthor würd=
e
gleich eine komplette Struktur mit IFOs usw. erzeugen, was hier überflü=
ssig
ist. Oder könnte das sogar noch Probleme machen? AFAIK sind die VOBs do=
ch
dateisystemunabhängig (;nur die Zeiten sind intern referenziert), die
Sprünge zu bestimmten Kapiteln werden über Bytepositionsangaben in de=
n IFOs
gemacht, oder?
> Wobei mir wie gesagt die Idee, das zu streamen, ungleich besser gefäl=
lt.
> Er hat ja laut Beschreibung ein IP-Netz, wahrscheinlich schlichtes LAN,=
> denn er synchronisiert schon über TCP. Nichts wäre einfacher, als d=
arin
> einen MPEG2 Transport Stream zu multicasten. Ausgangspunkt für die ei=
gene
> Entwicklung könnte z.B. vlc sein. Der ist schon modular, einen Modul
> dranzustricken, der senderseitig für Stop/Go und Jump sorgt, ist wohl=
> nicht das größte Problem. Die Synchronität der Slave-Player ist d=
ann
> implizit gewährleistet, man braucht dort noch nicht mal komplette PCs=
,
> es reichen geeignete Streaming Clients, Code-Beiträge, die interessan=
te
> Features hinzufügen, sind für das Projekt sicher gesund etc pp.
Ja, so wär's optimal. Allerdings muß er serverseitig dann immer noch =
die
Sprünge hinkriegen.
RTSP leistet die Steuerung. Ich weiß aber nicht, ob es da vernünftige=
Implementierungen gibt.
Grüße, Benjamin
Antwort von Ulf Jaenicke-Rößler:
Benjamin Spitschan schrieb:
> Wie realisierst Du in Deinem Programm das Springen?
Mit dem DirectShow Interface IMediaSeeking (;SetPositions).
Das gefällt mir zwar nicht, ist aber eine ganz allgemein gültige
Anweisung für (;in erster Näherung) beliebige unterstützte Filmformate.
Dass das aber nicht für alle Filmformate gleich gut funktioniert,
liegt einerseits in der Natur der Dinge und führt andererseits
zu den hier besprochenen Problemen.
> Die beste Lösung ist
> wirklich diejenige mit Navigation Packs, so, wie es bei der DVD gemacht
> wird. Das wären dann VOB-Dateien.
Das muss ich mir mal überlegen - es würde für mich eine Menge Änderungen
nach sich ziehen.
Das Programm ist im Prinzip aus einem simplen MediaPlayer hervorgegangen,
dem man, wie eben Windows Media Player oder Media Player Classic einfach
einen Film vorwirft, für den es DirectShow Filter gibt.
> Ganz links statt "Demux" "to m2p" = MPEG2 Program Stream.
Hatte bei mir irgendwie nicht auf Anhieb geklappt, da vermutete ich,
irgendwas falsch gemacht zu haben. Probier ich gleich nochmal.
> Was da drin steht, ist wirklich egal, sodaß ich nicht mal von "nicht
> standardkonform" sprechen möchte. Wichtiger ist z. B., daß der Stream
> generell nicht kaputt ist. Sind die Dateien denn DVB-Aufnahmen? Oder wer
> produziert solchen Schrott mit leeren GOPs?
Frag mich nicht. Die kenn ich nicht oder darf keine Namen nennen ;-)
Um welche Authoring/Schnittprogramme es sich handelt, weiß ich auch
nicht.
Ich habe jetzt noch andere Filme geprüft - da ist alles dabei von falschen
Bitraten (;was in DirectShow zu falscher Längenbestimmung führt), über
falsche Frameraten (;29.97fps) bis zu ganz kaputten GOPs, welche ProjectX
sämtlich wegwirft.
Nochmals danke für die Tipps - ich kann sie gut gebrauchen.
Viele Grüße
Ulf
Antwort von Ulf Jaenicke-Rößler:
Andre Beck schrieb:
> Aha. Du hast also volle Kontrolle sowohl über die Steuerung als auch
> über die laufenden Streams. Dann ist das ja kein Problem.
Jein. Die Kontrolle über die Steuerung habe ich, bei den Filmen liegt
das anders.
Es gibt (;noch) keinen Produktionsschritt in der Anwendung. Die Filme
kommen von einer Agentur oder ähnlichem und werden wie im MediaPlayer,
beispielsweise, "einfach" abgespielt.
Die Filme liegen dazu (;meist) auf den Rechnern, auf denen sie ausgegeben
werden sollen, lokal vor. Es sind auch nur selten für alle Rechner die
selben Filme, die zu einem gegebenen Zeitpunkt abgespielt werden sollen.
Ein Streaming von einem Master ist somit natürlich fast unmöglich
(;vielleicht mit Gigabit, aber trotzdem: je mehr Rechner, desto schlimmer).
Außerdem handelt es sich nicht notwendigerweise um Mpeg2 Material,
auch schon mal um mp4, avi, mov. Mpeg2 überwog bisher, und gerade
in letzter Zeit häuften sich die Probleme mit dem Filmmaterial
an sich.
[CBR zum einfachen Springen in Filmen]
> Die Blödestmögliche. Mir fallen auf Anhieb zwei bessere ein: Selbst
> demuxen und mit Navigationsinformationen neu muxen (;im einfachsten
> Fall DVD-kompatible NAV-Packs, da gibts fertige Software), oder noch
> einfacher, vorher indizieren und dann über den Index springen.
...
> Natürlich hast Du Kontrolle über den Mux. Du kannst jederzeit den
> gelieferten Schrott demuxen und neu so muxen, wie Du es brauchst.
Ja, wenn ich die Filme selber zum Abspielen vorbereiten kann.
Was die Anwendung angeht, wäre ein zusätzlicher Produktionsschritt
nötig.
Mittlerweile scheint dieser zusätzliche Schritt aber immer wichtiger
zu werden - schlimmstenfalls als "Arbeitsanweisung". Je einfacher
man es zu machen versucht, umso mehr Probleme handelt man sich mit
"Ahnungslosen" ein.
Vielen Dank für Deine Tipps - hab grad DVDAuthor zum Testen geladen.
Viele Grüße
Ulf
Antwort von Andre Beck:
Ulf Jaenicke-Rößler writes:
> Andre Beck schrieb:
>
>> Aha. Du hast also volle Kontrolle sowohl über die Steuerung als auch
>> über die laufenden Streams. Dann ist das ja kein Problem.
>
> Jein. Die Kontrolle über die Steuerung habe ich, bei den Filmen liegt
> das anders.
> Es gibt (;noch) keinen Produktionsschritt in der Anwendung. Die Filme
> kommen von einer Agentur oder ähnlichem und werden wie im MediaPlayer,
> beispielsweise, "einfach" abgespielt.
Naja, wenn das aber offensichtlich nicht geht, weil Schrott zugeliefert
wird, dann muss man halt in die Applikation eine "Wasch"stufe einbauen.
Wenn $USER also ein MPEG2 öffnet, dann dauert das ein paar Sekunden
länger, weil es dabei temporär indiziert wird. Wie das aussehen kann,
zeigt etwa VirtualDubMod.
> Die Filme liegen dazu (;meist) auf den Rechnern, auf denen sie ausgegeben
> werden sollen, lokal vor. Es sind auch nur selten für alle Rechner die
> selben Filme, die zu einem gegebenen Zeitpunkt abgespielt werden sollen.
Das las sich anfänglich anders (;ich hatte mehr an so ein Kunstprojekt
gedacht, wo jemand am Master die Show steuert).
> Ein Streaming von einem Master ist somit natürlich fast unmöglich
> (;vielleicht mit Gigabit, aber trotzdem: je mehr Rechner, desto schlimmer).
Wieso? Ich gehe mal davon aus, dass da ein Netz von Workstations steht,
von denen eine Submenge immer mit einem Projekt beschäftigt ist. Es
gibt also keine Rechner, die mehr als einen Stream gleichzeitig senden
bzw. empfangen. In einem gewöhlichen Fast Ethernet an einem aktuellen
Switch mit IGMP Snooping skaliert das praktisch unendlich (;jedenfalls
mit Codecs, die <= 25Mbps Bitrate produzieren), bei einem Switchverbund
oder fehlendem IGMP Snooping muss man zeitigstens bei insgesamt 3 bis 6
unabhängigen Streams (;also Sessions mit verschiedenem Material) Abstriche
machen, was dann primär von der Topologie abhängt.
Ich empfehle hier wie gesagt nicht irgendwelchen Real- oder M$-Blödsinn
über TCP oder Unicast UDP, sondern richtiges Streaming - also MPEG2
*Multicast* über nacktes UDP oder RTP. Da macht ein 8Mbps MPEG2 exakt
einmal 10Mbps Bandbreite, und zwar abgehend am Sender und eingehend
an jedem Empfänger. Widrigenfalls (;kein IGMP Snooping im Switch) kommen
die 10Mbps auf jedem anderen Rechner im VLAN rein und werden dort stand-
haft ignoriert.
> Außerdem handelt es sich nicht notwendigerweise um Mpeg2 Material,
> auch schon mal um mp4, avi, mov. Mpeg2 überwog bisher, und gerade
> in letzter Zeit häuften sich die Probleme mit dem Filmmaterial
> an sich.
Man könnte natürlich auch festlegen, was geht. MPEG4 Multicast ist das
kleinste Problem, AVI und MOV sind Container, die für sich keine Aussage
darstellen, wenn man nicht sagt was drin ist. Sollte das allerdings auch
Rohdaten oder rohdatennahe Streams beinhalten (;HuffYUV, YV12 etc), dann
mag es mit Streaming tatsächlich eng werden. Da stellt DV IMO die
Grenze des guten Gewissens mit 100Base Machbaren dar.
> [CBR zum einfachen Springen in Filmen]
>> Die Blödestmögliche. Mir fallen auf Anhieb zwei bessere ein: Selbst
>> demuxen und mit Navigationsinformationen neu muxen (;im einfachsten
>> Fall DVD-kompatible NAV-Packs, da gibts fertige Software), oder noch
>> einfacher, vorher indizieren und dann über den Index springen.
> ...
>> Natürlich hast Du Kontrolle über den Mux. Du kannst jederzeit den
>> gelieferten Schrott demuxen und neu so muxen, wie Du es brauchst.
>
> Ja, wenn ich die Filme selber zum Abspielen vorbereiten kann.
> Was die Anwendung angeht, wäre ein zusätzlicher Produktionsschritt
> nötig.
Der lässt sich zur Not zwingend mit dem Öffnen verbinden. Mach einfach
für jedes Format, das nicht sauber indiziert daherkommt, eine Stufe
dazu, die einen temporären Index erzeugt. Wenn man die Indexfiles
persistent macht, stört das kaum noch.
> Mittlerweile scheint dieser zusätzliche Schritt aber immer wichtiger
> zu werden - schlimmstenfalls als "Arbeitsanweisung". Je einfacher
> man es zu machen versucht, umso mehr Probleme handelt man sich mit
> "Ahnungslosen" ein.
Das Problem hat jeder Anwendungsentwickler, seit die in Redmond die
Entwicklerprostitution^WUsability erfunden haben ;)
> Vielen Dank für Deine Tipps - hab grad DVDAuthor zum Testen geladen.
Wobei das wie gesagt nur eine Anregung war, in welche Richtung man
gehen könnte. Ob DVD-konforme NAV-Packs für Deine Zwecke nicht viel
zu barock sind, kann ich nicht einschätzen. Mir erscheint die Kombi
aus zwangsindiziertem Einlesen von kritischen Videos und Streaming
Sessions mit den Mitstreitern nach wie vor ideal, könnte so aussehen:
* Alex öffnet flight thru new ppc server.mpg im Workgroup Video Player
und dreht eine Minute Däumchen, während die 2GiByte MPEG2 indiziert
werden
* Alex öffnet im Player eine neue Session "Alex' HardwarePr0n" und
lädt die Mitarbeiter, die daran gerade arbeiten, ein.
* Bea, Chris und Denise öffnen ihren Workgroup Video Player, gucken
nach aktuellen Sessions und klinken sich auf "Alex' HardwarePr0n"
ein
* Alex zeigt seinen Arbeitsstand
* Alle meinen, das wäre so Ok, man müsse es dem Chef zeigen
* Chef wird angerufen, klinkt sich in die Session ein und kriegt
zu sehen, was vorliegt.
* Währenddessen hat Denise was anderes zu tun, geht aus der Session
raus und betritt "Torbens T.G.I.F" einer anderen Arbeitsgruppe.
Dabei stört auch nicht, dass sie "samstagsarbeit wieder einführen.mp4"
nicht auf ihrem Rechner hat, Torben aber trotzdem bei dem Projekt
helfen kann, mit dem er sich grade rumquält.
Hätte das was?
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
Antwort von Ulf Jaenicke-Rößler:
Hallo,
nochmals Danke für Deine Tipps!
Sie zeigen, wie auch die Schwierigkeiten, die z. Z. gehäuft
auftreten, dass ich mich mit der Produktion oder Erstellung
des Videomaterials mehr auseinandersetzen muss - speziell
die Indizierung erscheint mir lohnend. Allerdings muss dann
an der Anwendung einiges umgeschrieben werden...
Andre Beck schrieb:
>>Die Filme liegen dazu (;meist) auf den Rechnern, auf denen sie ausgegeben
>>werden sollen, lokal vor. Es sind auch nur selten für alle Rechner die
>>selben Filme, die zu einem gegebenen Zeitpunkt abgespielt werden sollen.
>
> Das las sich anfänglich anders (;ich hatte mehr an so ein Kunstprojekt
> gedacht, wo jemand am Master die Show steuert).
Das ist durchaus ein Anwendungsfall. Allerdings wird häufig auch ein
automatischer Ablauf verwendet. Einsatzfälle sind Museen, Tagungen/
Veranstaltungen/Messen, Konferenzräume. Da gibt es dann Projektoren/Displays,
auf denen Filme abgespielt werden. Die Filme sind natürlich aufeinander
abgestimmt, aber nicht notwendigerweise identisch.
>>Ein Streaming von einem Master ist somit natürlich fast unmöglich
>>(;vielleicht mit Gigabit, aber trotzdem: je mehr Rechner, desto schlimmer).
>
> Wieso? Ich gehe mal davon aus, dass da ein Netz von Workstations steht,
> von denen eine Submenge immer mit einem Projekt beschäftigt ist. Es
> gibt also keine Rechner, die mehr als einen Stream gleichzeitig senden
> bzw. empfangen. In einem gewöhlichen Fast Ethernet an einem aktuellen
> Switch mit IGMP Snooping skaliert das praktisch unendlich (;jedenfalls
> mit Codecs, die <= 25Mbps Bitrate produzieren), bei einem Switchverbund
> oder fehlendem IGMP Snooping muss man zeitigstens bei insgesamt 3 bis 6
> unabhängigen Streams (;also Sessions mit verschiedenem Material) Abstriche
> machen, was dann primär von der Topologie abhängt.
Öh - wenn 10 (;verschiedene) Filme auf einem Master (;PC Timecode) liegen, die
auf jeweils einem Client ausgegeben werden sollen, habe ich doch 10 Streams.
Allerdings muss ich zugeben, dass ich mich mit dem Video Streamen noch nicht
auseinandergesetzt habe. Wir haben eher den "M$-Blödsinn" getestet: Datei
lesen über Windows-Freigaben :-)) Das ist natürlich nicht sehr effektiv...
> Man könnte natürlich auch festlegen, was geht. MPEG4 Multicast ist das
> kleinste Problem, AVI und MOV sind Container, die für sich keine Aussage
> darstellen, wenn man nicht sagt was drin ist. Sollte das allerdings auch
> Rohdaten oder rohdatennahe Streams beinhalten (;HuffYUV, YV12 etc), dann
> mag es mit Streaming tatsächlich eng werden. Da stellt DV IMO die
> Grenze des guten Gewissens mit 100Base Machbaren dar.
Ich habe kürzlich tatsächlich gehört, dass jemand mit DV ganz gute
Erfahrungen gemacht hat. Das muss ich demnächst auch mal probieren.
Was ansonsten das Festlegen von Formaten angeht - wir haben ja bisher
CBR bei MP2 festgelegt (;in Anbetracht der Disukssion in diesem Thread
sei die Sinnhaftigkeit mal dahingestellt) und trotzdem wurden allzuoft
VBR verwendet. Mit der Vielseitigkeit von DirectShow (;eigentlich ein
Vorteil) ist sowas auch schwer zu forcieren. Beispielsweise spielt die
Dateierweiterung (;avi/mov/mp2) beim Erstellen des DirectShow-Graphen
eine eher untergeordnete Rolle. Gut, man könnte bestimmte Dekoder
auswählen und versuchen, nur diese zu verwenden. Hmmmm.
>>Was die Anwendung angeht, wäre ein zusätzlicher Produktionsschritt
>>nötig.
>
>
> Der lässt sich zur Not zwingend mit dem Öffnen verbinden. Mach einfach
> für jedes Format, das nicht sauber indiziert daherkommt, eine Stufe
> dazu, die einen temporären Index erzeugt. Wenn man die Indexfiles
> persistent macht, stört das kaum noch.
Ja - mal überlegen wie, aber darauf wird es wohl früher oder später
hinauslaufen.
>>Vielen Dank für Deine Tipps - hab grad DVDAuthor zum Testen geladen.
>
>
> Wobei das wie gesagt nur eine Anregung war, in welche Richtung man
> gehen könnte.
Hab ich auch so verstanden :-)
> Ob DVD-konforme NAV-Packs für Deine Zwecke nicht viel
> zu barock sind, kann ich nicht einschätzen. Mir erscheint die Kombi
> aus zwangsindiziertem Einlesen von kritischen Videos und Streaming
> Sessions mit den Mitstreitern nach wie vor ideal, könnte so aussehen:
[...]
> Hätte das was?
Sicher! Größtes Problem ist für mich wahrscheinlich die Zeit, die es dauert,
das zu implementieren.
Viele Grüße
Ulf
Antwort von Andre Beck:
Ulf Jaenicke-Rößler writes:
>
>>>Ein Streaming von einem Master ist somit natürlich fast unmöglich
>>>(;vielleicht mit Gigabit, aber trotzdem: je mehr Rechner, desto schlimmer).
>> Wieso? Ich gehe mal davon aus, dass da ein Netz von Workstations
>> steht,
>> von denen eine Submenge immer mit einem Projekt beschäftigt ist. Es
>> gibt also keine Rechner, die mehr als einen Stream gleichzeitig senden
>> bzw. empfangen. In einem gewöhlichen Fast Ethernet an einem aktuellen
>> Switch mit IGMP Snooping skaliert das praktisch unendlich (;jedenfalls
>> mit Codecs, die <= 25Mbps Bitrate produzieren), bei einem Switchverbund
>> oder fehlendem IGMP Snooping muss man zeitigstens bei insgesamt 3 bis 6
>> unabhängigen Streams (;also Sessions mit verschiedenem Material) Abstriche
>> machen, was dann primär von der Topologie abhängt.
>
> Öh - wenn 10 (;verschiedene) Filme auf einem Master (;PC Timecode) liegen, die
> auf jeweils einem Client ausgegeben werden sollen, habe ich doch 10 Streams.
Du fokussierst immer noch auf *genau* einen Master. Ich hatte aus Deinen
Informationen zuvor geschlossen, dass es vielleicht eher arbeitsgruppen-
orientiert abläuft, wo jede Workstation bei Bedarf zum Master wird. Sollte
tatsächlich ein und derselbe Streaming Server 10 oder mehr individuell
einzigartige Streams an teilweise nur eine Zielmaschine pusten müssen,
dann sollte dieser Server GE spendiert bekommen. Und das ganze entweder
so gecodet sein, dass es transparent auf Unicast runtergeht, wenn nur ein
Empfänger existiert, oder die Switch-Infrastruktur muss damit zurecht
kommen, wenn es Multicast bleibt. Das ist heute keinerlei Problem (;jeder
ernstzunehmende Switch im Businesseinsatz ist managebar und hat IGMP
Snooping), aber manchmal treffe ich die absurdesten Altlasten in
professionell genutzten LANs an...
> Allerdings muss ich zugeben, dass ich mich mit dem Video Streamen noch nicht
> auseinandergesetzt habe. Wir haben eher den "M$-Blödsinn" getestet: Datei
> lesen über Windows-Freigaben :-)) Das ist natürlich nicht sehr effektiv...
Das ist wirklich maximal ineffizient. Zumal selbst M$ das besser kann:
M$ Media Encoder füttert M$ Media Services (;liegt W2k und W2k3 Server bei)
und letzteres dient als Multicast Sender. Störend daran ist nur, dass es
sich auf unerwünschte Formate kapriziert (;Windows Media in allen Farben).
Das *ist* immerhin schon mal eine Streaming-Lösung, aber eben nur eine
vollfrontale, nichts mit dem subversiven ad-hoc-Charme, den VLC entfaltet.
Guck Dir den wirklich mal an (;www.videolan.org).
--
The S anta C laus O peration
or "how to turn a complete illusion into a neverending money source"
-> Andre "ABPSoft" Beck ABP-RIPE Dresden, Germany, Spacetime <-
