Ok, the title is mentioning it already - this Demo is related to the decoding
of "true WebCam-streams" (not to the Cams, which hang on your USB-port),
and those Internet-Cams are usually directly accessible per Browser over http -
and then (most) often pump their stream continously, using: mime=multipart/x-mixed-replace
on a (Keep-Alive) http-Connection.
The Demo shows, how to capture such streams in a decent performance
without using a Browser-Client ... as e.g. FireFox, which has no problem with
e.g. this URL here in Helsinki (Finland): http://77.72.56.163/mjpg/video.mjpg
Important in such a scenario is a fast (M)JPEG-Decoder - and vbRichClient5 contains
a quite speedy one (based on libJPGTurbo), which works about factor 2-3 faster than
what's available on Windows per default (e.g. when decoding per WIA or GDI+).
So, to avoid using a Browser-Client (and the default-JPG-Decoder which comes with
the Browser-API), we would also need our own socket-handling for the http-GET-
request, and in this case we use cTCPClient (also from RC5) for this part.
What's also shown is, how to configure a CommandString for the quite wellknown
VLC-MediaPlayer, which supports different Streaming-Modes - and to be compatible
with true WebCam-Streaming, we have to force VLC into "multipart/x-mixed-replace"-
mode as well.
This is done in the Demo-Code in Sub Main() - and I've split the different parts
of the VLC-CommandString into easier to understand snippets, as shown below:
complete content of modMain.bas (the important parts, which ensure WebCam-compatible http-streaming are in Magenta)
So, the above code asks any time the Demo is started, if you want to Shell an appropriate
Instance of the VLC-Player (in Stream-Mode) - in case you find that unnerving, just comment
out the appropriate Lines in Sub Main().
The achieved performance is quite good - also because the final (stretched) rendering happens
over a Cairo-DirectX-uploaded Surface (which performs the final stretch to the picVid-PictureBox
in Hardware)...
The CPU-Load is only around 1% whilst receiving+JPGDecoding+StretchedRendering takes place
with about 24-25FPS receiving streamed VideoFrames from a 1280x696 VLC-transcoded Video.
(the VLC-Player which has to perform a transcoding from MP4 to MJPG in this case, has a bit
more Stress - and thus needs about 4-5% of the CPU - but it runs in a different process and
doesn't affect the VB6-App whilst doing so...
Here's a ScreenShot, which shows the whole thing in action:
![]()
And here's the Download-Link for the Demo-Zip:
WebCamRC5.zip
Olaf
of "true WebCam-streams" (not to the Cams, which hang on your USB-port),
and those Internet-Cams are usually directly accessible per Browser over http -
and then (most) often pump their stream continously, using: mime=multipart/x-mixed-replace
on a (Keep-Alive) http-Connection.
The Demo shows, how to capture such streams in a decent performance
without using a Browser-Client ... as e.g. FireFox, which has no problem with
e.g. this URL here in Helsinki (Finland): http://77.72.56.163/mjpg/video.mjpg
Important in such a scenario is a fast (M)JPEG-Decoder - and vbRichClient5 contains
a quite speedy one (based on libJPGTurbo), which works about factor 2-3 faster than
what's available on Windows per default (e.g. when decoding per WIA or GDI+).
So, to avoid using a Browser-Client (and the default-JPG-Decoder which comes with
the Browser-API), we would also need our own socket-handling for the http-GET-
request, and in this case we use cTCPClient (also from RC5) for this part.
What's also shown is, how to configure a CommandString for the quite wellknown
VLC-MediaPlayer, which supports different Streaming-Modes - and to be compatible
with true WebCam-Streaming, we have to force VLC into "multipart/x-mixed-replace"-
mode as well.
This is done in the Demo-Code in Sub Main() - and I've split the different parts
of the VLC-CommandString into easier to understand snippets, as shown below:
complete content of modMain.bas (the important parts, which ensure WebCam-compatible http-streaming are in Magenta)
Code:
Option Explicit
Sub Main() 'just a short demonstration, how to build a proper VLC-http-MJPG-CommandString
Dim FilePath$: FilePath = "C:\Tests\Test.mp4"
Dim VLCPath$: VLCPath = "C:\Program Files (x86)\VideoLAN\VLC\vlc.exe"
Dim transcode$: transcode = "vcodec=MJPG,vb=5600,scale=Automatic,acodec=none"
Dim http$: http = "mime=multipart/x-mixed-replace;boundary=--7b3cc56e5f"
Dim dst$: dst = "127.0.0.1:8080/"
If MsgBox("Shall I start a VLC-Instance for: " & FilePath & "?", vbYesNo) = vbYes Then
Shell VLCPath & " " & FilePath & " " & BuildStreamSettingsVLC(transcode, http, dst)
End If
fWebCam.Show
End Sub
Public Function BuildStreamSettingsVLC(transcode As String, http As String, dst As String) As String
Const VLCBaseSettings$ = ":sout=#transcode{@1}:standard{access=http{@2},mux=mpjpeg,dst=@3}"
BuildStreamSettingsVLC = Replace(Replace(Replace(VLCBaseSettings, "@1", transcode), "@2", http), "@3", dst)
End FunctionInstance of the VLC-Player (in Stream-Mode) - in case you find that unnerving, just comment
out the appropriate Lines in Sub Main().
The achieved performance is quite good - also because the final (stretched) rendering happens
over a Cairo-DirectX-uploaded Surface (which performs the final stretch to the picVid-PictureBox
in Hardware)...
The CPU-Load is only around 1% whilst receiving+JPGDecoding+StretchedRendering takes place
with about 24-25FPS receiving streamed VideoFrames from a 1280x696 VLC-transcoded Video.
(the VLC-Player which has to perform a transcoding from MP4 to MJPG in this case, has a bit
more Stress - and thus needs about 4-5% of the CPU - but it runs in a different process and
doesn't affect the VB6-App whilst doing so...
Here's a ScreenShot, which shows the whole thing in action:
And here's the Download-Link for the Demo-Zip:
WebCamRC5.zip
Olaf
