ActiveX Video.ocx
Willibert Pfister
Ich bin auf der Suche nach einem ActiveX-Steuerelement das es mir erlaubt,
Video- und Audio-Daten an eine bestimmte IP und über einen bestimmten Port
über's Internet zu einem entsprechenden Empfänger zu senden.
Ich habe bereits sehr viel recherchiert und auch schon viel gefunden, aber
leider hatte bisher jeder Fund einen Haken.
Zum Beispiel "VideoCapX" von www.fathsoft.com kann was ich brauche, nur ist
die Performance bei Übetragung durch's Internet nicht fließend genug. Im LAN
ist es jedoch OK.
Die Video- und Audio-Daten werden im Format 160x120 Pixel per ISDN, also 64
kBit/s, zum Empfänger übertragen und sollen dort ein möglichst ruckfreies
Videobild erzeugen.
Kennt jemand ein Steuerelement für Visual Basic 6.0 mit diesen
Eigenschaften?
Über irgend einen Tipp oder eine Alternativ-Lösung würde ich mich sehr
freuen!
Ach ja: mit dem Windows Media-Format gibt es den Nachteil, daß Sendungen
zeitlich stark verzögert werden (bis zu 8 Sekunden) und dadurch eine
Kommunikation mit der Gegenstelle sehr unbequem wird.
Hat jemand diesbezüglich Erfahrung gesammelt? Vielen Dank für jede Hilfe!!!
Willibert Pfister
Schmidt
"Willibert Pfister" <williber...@t-online.de> schrieb im Newsbeitrag
news:uwqIVRWQ...@TK2MSFTNGP11.phx.gbl...
> Ich habe bereits sehr viel recherchiert und auch schon viel gefunden, aber
> leider hatte bisher jeder Fund einen Haken.
> Zum Beispiel "VideoCapX" von www.fathsoft.com kann was ich brauche, nur
ist
> die Performance bei Übetragung durch's Internet nicht fließend genug. Im
LAN
> ist es jedoch OK.
> Die Video- und Audio-Daten werden im Format 160x120 Pixel per ISDN, also
64
> kBit/s, zum Empfänger übertragen und sollen dort ein möglichst ruckfreies
> Videobild erzeugen.
Bei ISDN-Speed haben sogar die professionellen Video-Konferenzsysteme
Probleme.
> Ach ja: mit dem Windows Media-Format gibt es den Nachteil, daß Sendungen
> zeitlich stark verzögert werden (bis zu 8 Sekunden) und dadurch eine
> Kommunikation mit der Gegenstelle sehr unbequem wird.
Video-Konferenzen sind aufgrund ihrer "near Realtime"-Anforderungen halt ein
ganz anderes Thema als normales Videostreaming, bei dem auf der Senderseite
Keyframebasierte Codecs (KeyFrame, Delta, Delta,...Keyframe, Delta,
Delta...) mit großer Tiefe zum Einsatz kommen können und Clientseitig
ausreichend vorgepuffert werden kann.
Für Videokonferenzen kommen meist spezielle Wavelet-basierte Codecs zum
Einsatz, die teilweise auch mit Keyframes und Bewegungsdetektion arbeiten,
aber hierbei mit maximal 2 bis 3 Frames Tiefe auskommen müssen.
Falls man sich so etwas selbst stricken will, könnte man zum einen
MJPG-Codecs einsetzen.
Bei einer 160x120 Framegröße von 19.200 Pixeln läge ein MJPG-komprimierter
Frame so bei 1-2kByte.
Wären dann über einkanaliges ISDN allerdings nur 4-6 Frames/sec.
WaveLet-Codecs komprimieren bei gleicher Größe & Qualität etwa doppelt so
gut - man käme dann so auf 8-12 Frames/sec - das sähe dann schon
einigermaßen fließend aus.
Näher an die 15-20 Frames/Sec für flüssiges Video kommt man dann nur noch,
wenn zusätzlich zur WaveLet-Kompression mit Bewegungsdetektion gearbeitet
wird, und nur die Teilflächen übertragen werden, in denen Änderungen
auftraten.
Das Ganze hängt natürlich stark von den Qualitätseinstellungen der Codecs ab
(die Frameraten die ich angegeben habe, sind Schätzungen bei denen die
Bildqualität in Ordnung gehen dürfte). Die Codec-Hersteller werben oft mit
höheren Frameraten - ob das Ganze bei der dann einzustellenden
Qualitätsstufe noch anschaubar ist, muss man ausprobieren.
Ein fertiges Videokonferenz-OCX, das auch für schmalbandige Verbindungen wie
z.B. ISDN taugt, kenne ich auch nicht (Zoschke?) - ansonsten bleibt der Weg
über das VfW-API, die erwähnten Codecs und WinSock.
MJPG und auch WaveLet-Codecs gibt es enweder bei LEAD-Tech. (spezielles
Codec-Paket - man muss nicht die ganze Suite kaufen) oder aber auf
www.jpg.com (PicVideo-Codecs z.B. WaveLet2000 - auch sehr gut).
Olaf
Willibert Pfister
vielen Dank für Deine Ausführungen. Ich werde daraufhin weiter
recherchieren.
Und nun die Gegenfrage zu dem ganzen Sachverhalt:
Wie ist (den von Dir genannten Gegebenheiten zufolge) NetMeeting aufgebaut?
Mit NetMeeting und einer Pixelgröße von 160 x 120 habe ich das gewünschte
Ziel (praktisch) ruckfreie und damit absolut akzeptable Performance bereits
hingekriegt. Nur kann ich mit NetMeeting nicht von mir festgelegte Ports
benutzen und damit sind Clients hinter einem Router nicht erreichbar. Weißt
Du mehr ?
Danke für Deine Antwort.
Willibert Pfister
"Schmidt" <s...@online.de> schrieb im Newsbeitrag
news:%23ycK6hX...@TK2MSFTNGP11.phx.gbl...
Schmidt
> Wie ist (den von Dir genannten Gegebenheiten zufolge) NetMeeting
aufgebaut?
> Mit NetMeeting und einer Pixelgröße von 160 x 120 habe ich das gewünschte
> Ziel (praktisch) ruckfreie und damit absolut akzeptable Performance
bereits
> hingekriegt. Nur kann ich mit NetMeeting nicht von mir festgelegte Ports
> benutzen und damit sind Clients hinter einem Router nicht erreichbar.
Weißt
> Du mehr ?
Netmeeting verwendet MS-H263.
Der ist eigentlich standardmäßig beim OS dabei und sollte über entsprechende
Calls des ICM-API benutzbar sein.
Hier mal auszugsweise die Anwendung der Compressor-APIs, die die zeitliche
Komponente (Key-/Deltaframes) berücksichtigen.
ICOpen
ICSeqCompressFrameStart
ICSeqCompressFrame
ICSeqCompressFrameEnd pCV
ICCompressorFree pCV
'von den Declares her etwas unvollständig (nur das Prinzip u.
Call-Reihenfolge):
'*** global Declares
Type PCOMPVARS
cbSize As Long
dwFlags As Long
hic As Long
fccType As Long
fccHandler As Long
lpbiIn As Long 'bitmapinfo
lpbiOut As Long 'bitmapinfo
lpBitsOut As Long
lpBitsPrev As Long
lFrame As Long
lKey As Long
lDataRate As Long
lQ As Long
lKeyCount As Long
lpState As Long
cbState As Long
End Type
Public pCV as PCOMPVARS, gBI as BitmapInfoHeader
'***Global Init
pCV.cbSize = Len(pCV): pCV.dwFlags = 1
pCV.hic = ICOpen(Make4CC("VIDC"), Make4CC("H263"), 1)
gBI.biSize = 40: gBI.biPlanes = 1
gBI.biWidth = 160: gBI.biHeight = 120
gBI.biBitCount = 24 'Bit RGB as Source
gBI.biCompression = 0
If ICSeqCompressFrameStart(pCV, gBI)=0 Then msgbox "Couldn't open compr"
'***inside the capture-loop (capVideoCallback):
Dim pF as Long, BytesOut as Long, pComprData as Long
pComprData=ICSeqCompressFrame(pCV,0, ByVal VidHdr.lpData, pF,BytesOut)
'***cleanup-code
ICSeqCompressFrameEnd pCV
ICCompressorFree pCV
Olaf
Willibert Pfister
Wo könnte ich denn mein Wissen über dieses Thema erweitern ohne das gesamte
Internet abgooglen zu müssen?
Quellcode in VB über den Aufbau von NetMeeting, Messenger u.ä. zu bekommen
ist wohl nicht sehr wahrscheinlich, oder?
Die wichtigste Frage aber lautet: Selbst wenn es gelingen würde NetMeeting
"nachzubauen", würde das H.263 Protocol erlauben den Ziel-Rechner per IP und
Port anzusprechen oder müßten dann hinter einem Router oder Firewall ganze
Portbereiche freigegeben werden?
Ich möchte eine Videokommunikation mit brauchbarer Performance per Internet
in ein LAN erstellen.
Vielen Dank nochmal.
Willibert Pfister
"Schmidt" <s...@online.de> schrieb im Newsbeitrag
news:umsnwXZQ...@TK2MSFTNGP11.phx.gbl...
Schmidt
> Vielen Dank für die Anhaltspunkte.
> Wo könnte ich denn mein Wissen über dieses Thema erweitern ohne das
gesamte
> Internet abgooglen zu müssen?
WinSockets umgehen kann.
> Quellcode in VB über den Aufbau von NetMeeting, Messenger u.ä. zu bekommen
> ist wohl nicht sehr wahrscheinlich, oder?
Es gibt ein Netmeeting-SDK bei MS - (für Plugins usw.).
Wie detailliert dort der Aufbau von Netmeeting selbst beschrieben ist,
entzieht sich meiner Kenntnis - der Netmeeting-SourceCode ist sicherlich
nicht enthalten.
> Die wichtigste Frage aber lautet: Selbst wenn es gelingen würde NetMeeting
> "nachzubauen", würde das H.263 Protocol erlauben den Ziel-Rechner per IP
und
> Port anzusprechen oder müßten dann hinter einem Router oder Firewall ganze
> Portbereiche freigegeben werden?
Du verwechselst hier IMO H.263 (VideoCoding-Standard) und H.323 (allg.
Kommunikations-Standard f. Realtime-Video/Audio/Data über Netzwerke).
H.323 interessiert Dich eigentlich nicht, da Du die Übertragung mit einem
eigenen Protokoll über einen selbstdefinierten Port realisieren möchtest.
Eine effiziente Übertragung über schmalbandige Leitungen benötigt aber in
jedem Falle eine effiziente Videokompression - in H.323 als H.263-Codec
definiert (Codec in Windows vorinstalliert).
> Ich möchte eine Videokommunikation mit brauchbarer Performance per
> Internet in ein LAN erstellen.
Arbeite Dich in das Capturen per VfW-API (hier gibt es ganz gute
Codehäppchen im Internet) und in die von mir angeführten Compressions-APIs
ein (die Decompression läuft dann nahezu analog zum Compression-Example ab).
Wenn das Capturen und Komprimieren/Dekomprimieren steht, hast Du noch das
Übertragen der komprimierten Buffer per Winsock einzuschieben (mit
automatischer Anpassung der Übertragungsfrequenz an die
Leitungsgeschwindigkeit).
Insbesondere das Problem der adaptiven Winsock-Übertragung liest sich jetzt
einfacher, als es tatsächlich ist. Falls Du Unterstützung brauchen solltest,
melde Dich einfach per E-Mail.
Olaf
