webStreamer - an integrated Web streaming solution

[86atc250r]

Nice little project -

I was not able to get it to work with VLC embedded in a webpage - can't get IE to allow me to install the activeX, even if I put it in my "local intranet" or "trusted sites" - just tells me it blocked it - thank you, drive thru.... No option to go ahead and install with confirmation or anything - regardless of any settings I try in IE...

Even tried it on three individual systems, including the local machine - same result - all XPSP2

WMP works fine though.

----- update

I was able to get VLC to work if I install the ActiveX component in the installer

Question - Anyone had any luck with h.264?

Thanks

[freebird]

Thanks fering.
I didn't originally suspect comclean because GB handled the videos fine. But after you mentioned the different versions of comclean, I remembered seeing that at the website. Sure enough, I was using the "quick and dirty" version. I haven't had a chance to test the other versions, but will soon and report my findings.
Again, thanks for the tip.

[Anjo]

im sure you didnt mean it - but your post seems a little on the tetchy side!

Remember that the lovely, lovely people who develop these things do it for free, in their own time!

Zero, didn't mean to sound tetchy but to the point. However reading my original post I can see how it can be construed to appear as such. Sorry, no offense meant.

As for people doing this kind of stuff on their own time, I know. I've done some MythTV coding myself on my spare time. My point regarding the source was simply that the more people who can access it, the more "hands to lend" will be available and the faster the progress of a piece of software.

More eye-balls on a target means better quality as well (e.g. that's why the security community insists on publishing all their algorithms, for the purpose of peer reviews).

[Anjo]

normanr is right, it just can't find VLC installed on your PC. Either manually edit the webStreamer.xml file, or hit the Settings button at the bottom of the streamer page.

..

and anjo, yes the source is "omitted" from the zip. I'm actually a fan of open source, but I see no benefit from releasing badly disorganized code of a beta version that no one would understand but me. When things are finally settled down, I'll clean up the code, add comments, and probably have the source go out as well.

sgilani and normanr, thanks for the constructive replies!
I can't believe I missed the VLC path configuration in the XML file! I wonder if I might have downloaded some old file set earlier :-) Downloading the zip attached in the first message of this thead got the streamer working without a hitch.

As for the source, I understand your argument. Perhaps one perculiar aspect with regards to open source is that as a developer one often gets a bit *vain*. Contrary to proprietary / closed source software, much more attention is given on the code quality since it's obvious others will be looking at the code. However, I hope this is something we can all eventually be able to get over (the vain part), so that we can get stuff *out there* faster and together with others refactor as needed until the object model and interfaces are arranged in a natural way. But I totally respect your decision in this case, since I've also suffered from the same feeling on numerous occasions

The one part I was trying to add was a pure "streaming" aspect (w.o. transcoding) since my PVR is running on very weak hardware and I'd like to set up a VLC daemon on a more powerful box to do the transcode. The changes I was looking to do was adding a config item or two to the config file so that the WEB-UI could reference a URL on another machine for delivering video to the VLC browser plugin (aside from the addition of a pure streaming profile w.o. transcoding of course).

E.g. Two machines referred to as P (PVR) and T (Transcoder).
1. A request arrives to P for streaming a video file.
2. VLC is started on P for streaming the requested video file to the configured destination on T ( e.g. TORT ).
3. The VLC daemon on T intercepts the network stream, transcodes it and makes it available for clients on TORT
4. P renders the web UI with a reference to TORT as the source for the VLC plugin.

Pretty simple scheme which would off-load the expensive transcoding work from the PVR to another (likely more powerful) machine.

If it would not be too much bother, do you think you could squeeze these minor changes in? Otherwise I'll just wait until you've done your cleanup

[normanr]

Unfortunatly too many times I've seen 'beta' products being released, and then the dev ends up with no time to get it up to 'production' quality. So the community is stuck with a half done output, and no code. I'd rather see the code out there from the start, so that the dev can start accepting patches, etc. I won't deny that sanitising patches can be a pain, but the dev time is cut down.

Pure streaming is available via the EWA at the moment, or are you actually looking for the ability to do the VLC transcoding on the other machine? That sounds quite tricky, because I think you need to launch VLC on the transcoding machine. What about installing a second copy of EWA+webStreamer on the second machine and pointing it to the PVR? That way you have two interfaces, and the high end machine does the transcoding.

[sgilani]

What about installing a second copy of EWA+webStreamer on the second machine and pointing it to the PVR? That way you have two interfaces, and the high end machine does the transcoding.

You read my mind I understand what Anjo was saying with using a daemon on the transcoding machine, but that's quite an involved setup.. what normanr is suggesting is much more straightforward, more efficient, and will get the job done.

And don't worry guys, the source code will be out before you know it.

[Anjo]

I'm looking to do transcoding on a separate machine.
Regarding "EWA+webstreamer", excuse my ignorance, but what is EWA?

Any suggestion which can accomplish the same result (offloading the responsibility of transcoding from the PVR machine) with less effort than the proposed one would naturally be preferable. So if this "EWA+webStreamer" solution is easier than just starting VLC on a separate machine, noone is more satisfied than me

Edit:
The proposed change wasn't *that* involved. Let me exemplify even further.

First, on the transcoder machine, a VLC process is started (e.g. as a service or startup folder in windows) like

Code:

vlc udp://@:%PORT% :sout=#transcode{vcodec=%VCODEC%,vb=%VBR%,scale=%SCALE%,acodec=mp3,ab=%ABR%,channels=2}:duplicate{dst=std{access=http,mux=ts,url=:1234}}

Then, for each client request on the PVR, webStreamer would simply spawn a process like the following command line.

Code:

vlc %SOURCE_FILE% :sout=#duplicate{dst=std{access=rtp,mux=ts,url=%TRANSCODER%:%PORT%}}

The client would then simply connect to the stream through the plugin in the browser or via a stand-alone VLC instance like

Code:

vlc -vvv [url=http://%TRANSCODER_MACHINE%:1234]http://%TRANSCODER_MACHINE%:1234[/url]

Edit: Just found out about the code tag which avoids destroying input code examples..

[elite]

I'm looking to do transcoding on a separate machine.
Regarding "EWA+webstreamer", excuse my ignorance, but what is EWA?

Enhanced Web Admin I believe - (bleeding edge web admin for gbpvr)

[sgilani]

The proposed change wasn't *that* involved.

Yes, your description is what I assumed you meant... but now you're starting an instance of VLC on your PVR machine to do nothing but push an RTP stream of the video to your transcoder box, which then does the transcoding for the client. This really would disrupt the code quite a bit as I would now have to worry about two machines, rather than just the one with GBPVR. And to be honest with you, the vast majority of people will not have a separate machine being utilized to transcode, so I don't think it's worth coding up a new feature/setting to accomplish such a task, especially when there's a much more straightforward solution to the problem.

If you went the route with installing EWA and webStreamer on the transcoding box, then everything just falls into place, and you eliminate the step of needlessly using VLC just to get the file to the transcoding box.

[Koenie]

I have webstreamer working nicely trough the built in cassini webserver. I however access the webadmin trough apache for performance reasons (video stutter on the server when accessing the built in webadmin) and would like to do the same with the webstreamer.

The webstreamer main page displays OK, the child window comes on OK but clicking on the start button does not produce the video.
On the server the VLC transcode process is not started eighther. This part of the appache log might tell you guys something:

VLC media player 0.8.4a Janus
[00000268] main interface: creating httpd
[00000000] main root error: option sub-original-fps does not exist
[00000285] subtitle demuxer error: failed to recognize subtitle type
[00000271] main input error: no suitable demux module for `/subtitle://\\server\video\Mr. Bean\Mr. Bean_20060225_20302105.txt'
[00000000] main root error: option sub-original-fps does not exist
[00000288] subtitle demuxer error: failed to recognize subtitle type
[00000271] main input error: no suitable demux module for `/subtitle://\\server\video\Mr. Bean\Mr. Bean_20060225_20302105.logo.txt'

I guess it has someting to do with the .txt extension.

Any help is greatly appreciated.