[vlc-devel] [videolan] I need a stable version of VLC - willing to pay - willing to contribute programming effort - interested in partership

[Lewis G. Pringle, Jr.]

>-----Original Message-----
>From: Rafaël Carré [mailto:rafael.carre at gmail.com] On Behalf Of Rafaël >Carré
>Sent: Sunday, May 11, 2008 7:14 AM
>To: lewis at sophists.com
>Cc: vlc-devel at videolan.org
>Subject: Re: [videolan] I need a stable version of VLC - willing to pay - >willing to contribute programming effort - interested in partership
>
>Le Fri, 9 May 2008 17:25:49 -0400,
>"Lewis G. Pringle, Jr." <lewis at sophists.com> a écrit :
>
>> Folks:
>> 
>>             I have a need for a program with the functionality of VLC
>> 0.8.6f, but which is considerably more stable and robust than that
>> version of the software.
>
>VLC is quite stable & robust already.

	I didn't mean to denigrate the quality of the VLC code in any way, but our intended use may not entirely match the testing scenarios you've used. We wouldn't be investigating the use of VLC unless we saw a very high degree of underlying quality in the code and libraries you've already produced. Still - for our needs - we require a bit more.


>>             The company I’m working with is willing to contribute
>> resources (either cash or software development effort) to make this
>> happen.
>
>What kind of skills can you provide in software development?

	If you want to know a bit about my background you can take a quick look at my (somewhat outdated) resume: http://www.sophists.com/Pringles/Lewis/Lewis%20Gordon%20Pringle,%20Jr%20Resume.pdf

	Also - if you don’t want me ;-) - no offense will be taken ;-) - the company I'm representing would be willing to financially underwrite some of the VLC development work in order to expedite fixes to the area of the code we need fixed promptly.


>>             I’m working the direct angle of analyzing the code
>> myself, and trying to debug the various problems we’ve encountered,
>> but when I saw this webpage (http://www.videolan.org/team/) it
>> occurred to me that directly contacting the right person in this
>> effort might be a good way to more efficiently get what we all want –
>> a more stable and reliable version of VLC.
>
>I think listing the problems would help figuring out what's wrong.

	I'm glad you asked ;-)

	The company I represent wishes to be able to bridge video communications between two Windows Media Server instances – running on two different computers within their network. They want the kind of video streamed between these two WMS servers to be ANY kind of video (that is to say, any codec/format supported by WMS). And – this is the kicker – they want the sharing between the two WMS servers to be using multicast (so really I’m oversimplifying – there will be many more than one receiver, but the receivers will all look alike).

	We’ve investigated the obvious solutions directly using Microsoft’s WMS product, and are convinced no reasonable solution exists. So – our next attempt was to use VLC as a bridge.

	So – what do we need to work from VLC?

BASIC REQUIREMENTS:
	We need to have VLC be able to receive a video stream
	from a WMS server, and send it to another VLC instance
	using multicast (on another computer), and have that VLC
	instance receive the stream, and further send it to a WMS
	publication point on that same machine. And – we need for
	VLC to be externally scriptable (have some automation API).
	And, we need to be able to handle at least dozens of 
	streams per computer.

	The VLC architecture appears to support this very neatly.

	The approach we’ve prototyped is using RTSP. We think this is the most promising approach (but are certainly willing to listen to alternatives).

A quick picture [sorry, ascii art isn't my long suit ;-)]:

      OUTSIDE-WORLD -->–Video--> 
---------------------machine boundary -----------------------
                     [ WMS Server ] -->RTSP-U--> 
                    VLC >----Mutitcast> 
---------------------machine boundary -----------------------
	      VLC > RTSP-U -->
                     [WMS-Server] -->
---------------------machine boundary -----------------------
                OUTSIDE-WORLD

	So in this prototype scenario, we need VLC to be able to read a unicast RTSP stream from a WMS sever, and translate that to muticast output. And, on another machine, have another VLC instance read the multicast stream, and pass it to the WMS server (as unicast rtsp).

	In this scenario – ideally – little or no translation/transcoding of the video would take place (but we are willing to compromise on this if it is needed).

	Another key – and subtle point – is that we need to be able to support stream-end and new-stream-starts flawlessly (this was a fatal Achilles heel for MSFT WMS using their multicast implementation). So – for example – the source ‘OUTSIDE WORLD’ may send several videos, each with different format information, and this updated format information needs to get propagated (which WMS doesn’t support with multicast, but DOES support using unicast RTSP).

	On the question of stability and bugs with the 0.86f code:

	One area of concern is whether or not VLC will scale reasonably, as we have dozens, or perhaps as many as a hundred streams running through it at a time. With all the multithreading it does – we wonder if this area is stable.

	Another area of concern – is just for the very simple case of pulling a single RTSP stream, we find that with VLC 0.8.6f – reading a simple RTSP stream from a WMS sever – the end-of-stream doesn’t appear to get detected properly, and VLC doesn’t notice it and show the video as having stopped. In more complex cases (say a playlist with multiple streams, it breaks even worse). We would be willing to consider using HTTP between the VLC instance and the WMS instance (and just RTSP multicast between the VLCs) – but we found different bugs playing video in VLC from a WMS server. 

	Please note - our existing testing has been on a mix of Windows XP, Windows Server 2003, and Windows Vista systems. We've read enough of your forum posts to realize there maybe some platform-specific issues we've encountered, but we aren't really clear on exactly whether or not this is the case.

	As for the use of VLC 0.9 – we aren’t against this in principle. However, from testing daily builds of VLC last week, it didn’t appear nearly as reliable in testing fragments of the above scenario as 0.8.6f did. We know this can be misleading, and are willing to entertain it as a possibility, but we are in a rush, and cannot afford to wait months while 0.9 stabilizes.

	I know this leaves a great deal of detail left unsaid, but hopefully is enough to help you to scope and broad parameters of what we are looking for, so that you can direct me to the right people to talk to.

		Thanks,
			Lewis.