To get started, you will need a development environment such as Visual Studio 2010 or Delphi for .NET. Make sure you always keep your environment updated with the latest service packs and hotfixes.
If you're sure that you meet all prerequesites you can start to look at some of the sample codes, demos and the documentation. Remember that, the best way to learn something new, is by playing with it. So start by simply changing parameters around, changing resolutions (you get the idea).
Because of the enormous number of combinations, we cannot give you a prescribed answers to this question. The easiest way to find out, is to simply execute one of our demo applications with the parameters you're interested in. For example, if you would like to know the speed of our MPEG4Decoder then a good way to see it perform is by using FilePlayer demo application and simply play an AVI or MP4 file that matches your requirements best.
It most likely does. We have tested our stack with alot of devices and Media Server. Among them are Axis, Vivotek, Darwin, Helix..
Best way to find out is try the RTSPPlayer demo application. In case it doesn't work with your designated device or server, please us know.
The config is a simple hex string. E.g.:
To generate this VOSS/VOS/VOL group you will have to instantiate the MPEG4Encoder and feed your first frame (or dummy all zero frame) to the encoder. If you look at the byte arrays first ~30 bytes you will see three start code values (0xb0, 0xb5, 0x20-0x2f).
You will need to extract that and convert that byte array to hex and simply insert it into your fmtp.
RTP.NET has 2 1/2 modes of operation. One is using callbacks and the other is polling for packets or "both".
It is the "both" that can cause what seems to be memory leaks.
if you have a callback registered for incoming RTP packets such as this:
Returning true would signal RTPSession that you would like to keep the packet stored for later retrieval using RTPSession.GetNextPacket().
This is also true for not registering a callback at all. If you don't call RTPSession.GetNextPacket() frequently enough, then you will see memory usage accumulating.
That is because most all speech frames fit into a single UDP packet. For this reason some senders might omit the setting of markers (or precisely, they might only set it, for what is called a "talk spurt"). In these cases it is best to disable marker filtering on the jitter buffer completely for senders in that domain.
There are multiple reasons why this could happen. The client hasn't received any RTCP Sender Reports. In case of RTSP, the client has neither receive RTP-INFO or an RTCP Sender Report.
If the client client has never received any timing relevant updates, the client will not be able to function correctly. Timestamps can also be simply sporadic or have certain peaks, in which case, the device manufacturer of the server/device should be contacted.
H.264 defines inter-frame dependencies of up to 16 slices, so as defined
in the standard the decoder must keep DPB (decoded picture buffer) until
the first batch of predictive references are shifted out of this buffer.
This is not the case with H.263 and that is why you see this behavior.
Errors similar to this: System.IO.FileLoadException: Could not load file or assembly ...
They are mostly either due to not including the necessary assemblies into your project or no having installed the necessary prerequisites in order to work with MediaSuite.NET. See requirements on the product page.
This is most likely because your license expired. MediaSuite.NET license gives you free updates for one year. After that, if you choose to receive more updates, you will have to license MediaSuite.NET again. Note: License expiration does not effect your right to use the older versions of MediaSuite that fall inside the period you have purchased a license before. Your are still free to redistribute MediaSuite.NET with those versions.
Each unique IP address you try to connect to needs to serve a Silverlight policy file. If you try to access servers that do not provide such policy file for Silverlight, then your application will have to go through a proxy.
Absolutely. You can continue to use the product which you have licensed and paid for. As long as you understand that when a subscription expires, it simply means that you will no longer be issued any product updates or new product releases.
Streamcoders does not charge any royalties for redistribution of components that have been integrated into applications which you engineer.
Of course, this only applies if you have a valid license to all products which are being used within your application. Please be aware that the usage of some codecs are protected by patents. Possible royalties will have to be negotiated with their respective patent holders.
If no development is performed on the build machine and its sole purpose is to generate actual builds of your products, then no you do not need to purchase a separate license for the build machine. If however a developer uses the build machine for active development and this developer does not have a valid license to the products, then yes, he or she must acquire a license to said product.
All Streamcoders products are sold based on a subscription model. This means that when you purchase one of our products, you receive 12 months of free updates for that product from the date of purchase - be it a minor service update or a major new version. After the 12 month period and at your discretion, you can renew the subscription and receive another 12 months of free updates. If you choose not to renew, you can continue using the last version you obtained or are eligible to use. The 12 month time frame is merely for new versions/updates and has no relevance to rights of use (as long as the EULA is not violated).