Using SQLite with C#
1. Include System.Data.SQLite.dll into the project
2. Optional, use IDE for SQLite (http://sqliteadmin.orbmu2k.de/)
Tutorials
01 April 2013
Submitting add-ons to a central XBMC repository - Notes
Install git on your machine ( http://git-scm.com/)
1. Check in the add-on solution into GitHub2. Subscribe to the XBMC Add-ons Mailing List
https://lists.sourceforge.net/lists/listinfo/xbmc-addons
3. Send email to
xbmc-addons@lists.sourceforge.netxbmc-addons-request@lists.sourceforge.net
Instructions how to submit xbmc add-on to a central xbmc repository:
Example of the Email
Subject: [Xbmc-addons] [Git Pull] XBMC-[name]Plugin addon - plugin.[name] version - 1.2.6 url - git://github.com/../[name].git branch - master xbmc version - dharma 10.1
Required
1) No .pyc files.
2) Add English summary and description.
you can use <summary lang="en">..</summary> and <summary lang="ru">...</summary>
(and same for description)
3) Add LICENSE.txt
4) See
http://wiki.xbmc.org/index.php?title=Add-ons_for_XBMC_%28Developement%29
5) Use an ID compatible with the convention, i.e plugin.somthing.something .
This is the place holder at the add-on in the repository.
31 March 2013
PlayOn Plug-In - Developer Notes
The plugin was written in C# with PlayOn Plugin API
Project structure
References
Util.dll (v2.0.50727)
Web References
Key classes
PlayOnPluginProvider - Contains the main logic that creates folders and loads the content using old or new API.
PlayOnPluginSettings - Contains the settings, those are visible when the pluging is open by playon.
Plugin settings
PlayOnPluginSettings.Description - "balalla"
PlayOnPluginSettings.Name - "CompanyName"
PlayOnPluginProvider.Name - "CompanyName"
+ logo
Build
Compile the plugin and rename the output *.dll to *.plugin
Copy *.plugin to
C:\Program Files (x86)\MediaMall\plugins
- This is automated in the project properties Build Events, make sure to change the paths if required in order to compile
Pre-build event command line:
del $(TargetDir)[name].plugin /F
Post-build event command line:
ren $(TargetDir)[name].dll [name].plugin
del "C:\Program Files (x86)\MediaMall\plugins\[name].plugin"
copy $(TargetDir)\[name].plugin "C:\Program Files (x86)\MediaMall\plugins"
Package
The ChannelPackager.exe will package *.plugin into *.pwn
Developer Guide
Download the ChannelPackager from
PlayOn Plugin API
27 March 2013
Timeouts in WCF service
I was getting my head around an exception I got after calling a method on my local WCF service:
"The request channel timed out while waiting for a reply after 00:00:59.9990000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout."
Obviously, the first thing I did was to increase a timeout in the web.config, guess what , no impact on the results.
So here is the summery after googling and debugging:
<bindings>
<netTcpBinding>
<binding name="longTimeoutBinding"
receiveTimeout="00:10:00" sendTimeout="00:10:00">
<security mode="None"/>
</binding>
</netTcpBinding>
</bindings>
Why changing SendTimeout does not help for hosted WCF services?
The timeout configuration needs to be set at the client level, so the configuration I was setting in the web.config had no effect, the WCF test tool has its own configuration and there is where you need to set the timeout.
ServiceHost host = new ServiceHost(typeof(FileService), new Uri("https://localhost:8443/FileService"));
host.OpenTimeout = TimeSpan.FromMinutes(5);
host.CloseTimeout = TimeSpan.FromMinutes(5);
Timeouts on client side channel
This is somewhat not as well known as the previous ones.
There is an OperationTimeout, which you can set it by casting the channel to IContextChannel. You can do it through code. The default for this is also 1 minute.
IFileService channel = ChannelFactory<IFileService>.CreateChannel(binding, new EndpointAddress("https://localhost:8443/FileService"));
IClientChannel contextChannel = channel as IClientChannel;
contextChannel.OperationTimeout = TimeSpan.FromMinutes(10);
This is the exception you will get if you are hitting this operation timeout:
"Unhandled Exception: System.TimeoutException: The request channel timed out attempting to send after 00:00:00.0100000. Increase the timeout value passed to the
call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.T
imeoutException: The HTTP request to 'https://localhost:8443/FileService' has exceeded the allotted timeout of 00:00:00. The time allotted to this operation may
have been a portion of a longer timeout."
There is another not so well known timeout on tcp transport, called ChannelInitializationTimeout, and its default value is 5 seconds.
BindingElementCollection be = binding.CreateBindingElements();
TcpTransportBindingElement tcpBe = be.Find<TcpTransportBindingElement>();
tcpBe.ChannelInitializationTimeout = TimeSpan.FromMinutes(1);
CustomBinding customBinding = new CustomBinding(be);
a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.9257860'. ---> System.Net.Socke
ts.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.ServiceModel.Channels.SocketConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
--- End of inner exception stack trace ---"
If you are web hosted, you should consider hitting timeouts set by ASPNET. There are Shutdown timeout, just like the service host close timeout, default is 90 seconds. Execution Timeout, just like our operation timeout, default is 110 seconds.
<configuration>
<system.web>
<httpRuntime maxRequestLength="4000"
enable = "True"
requestLengthDiskThreshold="512
shutdownTimeout="90"
executionTimeout="110"
versionHeader="1.1.4128"/>
</system.web>
</configuration>
"The request channel timed out while waiting for a reply after 00:00:59.9990000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout."
Obviously, the first thing I did was to increase a timeout in the web.config, guess what , no impact on the results.
So here is the summery after googling and debugging:
Availbale timeouts
Binding Timeouts
SendTimeout, ReceiveTimeout, OpenTimeout and CloseTimeout. Default = 60 sec.<bindings>
<netTcpBinding>
<binding name="longTimeoutBinding"
receiveTimeout="00:10:00" sendTimeout="00:10:00">
<security mode="None"/>
</binding>
</netTcpBinding>
</bindings>
Why changing SendTimeout does not help for hosted WCF services?
The timeout configuration needs to be set at the client level, so the configuration I was setting in the web.config had no effect, the WCF test tool has its own configuration and there is where you need to set the timeout.
ServiceHost Timeout
OpenTimeout (default is 1 minute) , CloseTimeout (default 10 sec)ServiceHost host = new ServiceHost(typeof(FileService), new Uri("https://localhost:8443/FileService"));
host.OpenTimeout = TimeSpan.FromMinutes(5);
host.CloseTimeout = TimeSpan.FromMinutes(5);
Timeouts on client side channel
This is somewhat not as well known as the previous ones.
There is an OperationTimeout, which you can set it by casting the channel to IContextChannel. You can do it through code. The default for this is also 1 minute.
IFileService channel = ChannelFactory<IFileService>.CreateChannel(binding, new EndpointAddress("https://localhost:8443/FileService"));
IClientChannel contextChannel = channel as IClientChannel;
contextChannel.OperationTimeout = TimeSpan.FromMinutes(10);
This is the exception you will get if you are hitting this operation timeout:
"Unhandled Exception: System.TimeoutException: The request channel timed out attempting to send after 00:00:00.0100000. Increase the timeout value passed to the
call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.T
imeoutException: The HTTP request to 'https://localhost:8443/FileService' has exceeded the allotted timeout of 00:00:00. The time allotted to this operation may
have been a portion of a longer timeout."
There is another not so well known timeout on tcp transport, called ChannelInitializationTimeout, and its default value is 5 seconds.
BindingElementCollection be = binding.CreateBindingElements();
TcpTransportBindingElement tcpBe = be.Find<TcpTransportBindingElement>();
tcpBe.ChannelInitializationTimeout = TimeSpan.FromMinutes(1);
CustomBinding customBinding = new CustomBinding(be);
Exception related to ChannelInitializationTimeout could look like:
"Unhandled Exception: System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message ora receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.9257860'. ---> System.Net.Socke
ts.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.ServiceModel.Channels.SocketConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
--- End of inner exception stack trace ---"
Timeouts in ASP.NET
If you are web hosted, you should consider hitting timeouts set by ASPNET. There are Shutdown timeout, just like the service host close timeout, default is 90 seconds. Execution Timeout, just like our operation timeout, default is 110 seconds.
<configuration>
<system.web>
<httpRuntime maxRequestLength="4000"
enable = "True"
requestLengthDiskThreshold="512
shutdownTimeout="90"
executionTimeout="110"
versionHeader="1.1.4128"/>
</system.web>
</configuration>
12 April 2012
Windows Media Center Plug-In
--Tatiana.golod 12:28, 14 October 2011 (EDT)
Existing solution: TFS/DefaultCollection/WMC plugin
Old solution: //depot/Code/CSharp/ConnecTV.Solution/
* Have to be VisualStudio 8 otherwise need to import templates and reinstall certificate
[edit]Building instructions
Building and registering the installers
1. Edit the Environment.bat for the correct paths, make sure you have gacutil.exe version 2 in order to register the installers
- gacutil.exe version 2 comes with .NET SDK 2.0
The solution is configured to run PreBuild.bat and PostBuild.bat files for each project to register the installers them correctly
- Build the solution twice!! the first time it will fail because the PreBuild.bat of each project try to unregister first and since nothing was registered yet it will fail.
So it goes like this:
Build all twice, if still fails 1. Build project Jasmio.MediaCenter.Service, 2. Build Jasmio.MediaCenter.Service.RemotingInterfaces.Version1 3. Build all again
2. Edit Build.reg
Building the installers - Manual
Build the library merge modules
Open command prompt
go to Jasmio.MediaCenter.Service\Setup type Build 1.3.1 Debug type Build 1.1.0 Debug
Certificate password: no12know
[edit]Building an installer instructions
2. Run Build 1.3.1 Debug in cmd (cd to Jasmio.MediaCenter.Service\Setup)
3. Run Build 1.1.1 Debug in cmd (cd to ConnecTV.MediaCenter\Setup)
(you'll get about 8 warnings, but no errors hopefully)
If it's worked, there should now be a couple of installers in the projects Debug output directory.
[edit]Debugging
To enable the debugging follow instructions in the documentaion SDK (Windows_Media_Center_SDK.chm)
Attaching a Debugger to a Windows Media Center Application using Visual Studio
- To enable the registry variables for debug you can run
EnableAddInLaunchDebugging_False.reg EnableErrorDetails_True.reg
located in ..\Program Files (x86)\Microsoft SDKs\Windows Media Center\v6.0\Tools
[edit]Strong names
Windows Media Center loads only locally-stored assemblies, which reside in the GAC, it requires all assemblies have strong names.
The following is the minimum information required to create a strong-named assembly:
- Assembly title in plain text.
- Assembly version number.
- Cryptographic key-pair file used to digitally sign the assembly.
The Strong Name tool (sn.exe) included with the .NET Framework 2.0 SDK can also be used to create a strong name key file.
[edit]Threads in Windows Media Center
WMC applications are hosted in an individual ehExtHost.exe process. (Applications running on prior versions of WMC ran concurrent with the WMC process (ehShell.exe) in their own application domain.) WMC runs each background application in a separate thread, and the application can create as many threads as it needs. Because foreground threads can prevent the application from terminating properly, a multithreaded application should use background threads whenever possible by setting the thread IsBackground property to true.
- An application can create as many threads as it wants. However, the WMC object model is single-threaded. You cannot construct a ModelItem or raise change notifications from a thread other than the main application thread. Most of the methods in the Microsoft.MediaCenter.UI namespace can only be called from the main application thread, with the exception of the methods in the Application class.
- The methods in the Microsoft.MediaCenter.TV.Epg and Microsoft.MediaCenter.TV.Scheduling namespaces can be called on any thread or on as many as needed. Events are called back on the same thread as you called them from.
[edit]Initializing, Launching, and Uninitializing the Application
Project: Jasmio.MediaCenter.UI
Class: Experience
Must implement two interfaces: IAddInModule and IAddInEntryPoint.
- IAddInModule exposes the Initialize and Uninitialize methods.
Calls flow: 1. IAddInModule.Initialize is the first method when it loads the application. 2. IAddInEntryPoint.Launch method, passing an instance of the AddInHost object to the application. This object lets the application access to retrieve information about WMC. The AddInHost object is valid only until the Launch method returns. Therefore an application must make all calls to the Windows Media Center APIs within the context of the Launch method. * After calling the Launch method, if you do not use the host object, the object could be released because .NET Remoting releases objects every five minutes if they are not used. To avoid this, use the host object or use the objects within five minutes.
Terminating the Application
Before terminating an application, WMC calls the application's IAddInModule.Uninitialize method and then briefly waits for the application to save its state, terminate any threads it created, and free any other system resources that it may have allocated. If the application's Uninitialize method does not return quickly enough, it unloads the application's application domain, terminating the application.
- You should assume that your application can be interrupted at any time. Design the application to perform lengthy operations in small steps, saving its state after each step if necessary.
- If your application needs a more deterministic environment, you should implement the application as an executable program that runs outside of WMC and use a helper application to manipulate the Windows Media Center aspects of the application.
[edit]Playing Media
Project: ConnecTV.MediaCenter
Class: ConnecTVExperience
Microsoft.MediaCenter.Hosting.AddInHost.Current.MediaCenterEnvironment
Enables applications to retrieve device information, gain access to disc changers, and control various aspects of WMC. The MediaCenterEnvironment class provides information about WMC, including its current capabilities and version number. For example, an application can use this class to display dialog boxes, play media, navigate to particular locations in WMC, and so on.
[edit]Markup
Defines a UI—how it appears visually, how it behaves, and how it interacts with code/data objects.
MCML separates code and data from UI logic. All UI development is done using MCML and is bound to data via rich binding mechanisms. All data and code are strictly non-visual.
The MCML files are embedded in the Resources.
Data binding performed in MCML, most object paths are evaluated at UI build time and their result values are set on the associated properties. However, some tags hold on to the object path and will re-evaluate it at runtime when needed.
- ObjectName is always refers to a named object within the scope of the UI.
[edit]Developing Notes
MainPage.mcml defines a single page and serves as the container for the individual views. The data binding also occurs at this page.
ConnecTV.MediaCenter.View.ConnecTVSettings - settings class
All the logs are in ApplicationDataPath (C:\ProgramData\IPTV Distribution\)
Debug log: C:\ProgramData\IPTV Distribution\IPTV Plug-in for Media Center\Debug.log
Settings (such as available packages for the user) are loaded from the settings file located in System.Environment.SpecialFolder.CommonApplicationData
Settings file C:\ProgramData\IPTV Distribution\IPTV Plug-in for Media Center\Settings.xml
Cache Files
C:\ProgramData\IPTV Distribution\IPTV Plug-in for Media Center\Cache
The localization files are copied to the:
C:\Program Files\IPTV Distribution\IPTV Plug-in for Media Center\Resources\Localization
the first time the application builds, so in order to see changes to the strings, change the appropriate file manually!!
Vianet services:
- To get the TV, Vidioteka, Archive and radio the application uses http://www.iptv-distribution.net/cas/service.asmx
(\\10.0.0.42\e$\Inetpub\iptv-distributionApplications\cas\App_Code)
- To get Teleteka it uses new service api http://ivsmedia.iptv-distribution.net/ClientService.svc?wsdl
(\\10.0.0.42\e$\Inetpub\iptv-distributionApplications\IVsMedia)
[edit]Additional help
Media Center Markup Language Reference
http://msdn.microsoft.com/en-us/library/windows/desktop/bb189388.aspx http://msdn.microsoft.com/en-us/library/bb189729
Media Center Development Blog
http://mediacenterdev.blogspot.com/2007/02/thinking-and-transferring-data-in-mcml.
Develop Media Center Addons
Short notes!!
Preparation of the environment
Should have Visual Studio 2008
1. Download and Install the Windows Media Center Software Development Kit from
http://www.microsoft.com/downloads/details.aspx?familyid=a43ea0b7-b85f-4612-aa08-3bf128c5873e&displaylang=en.
2. Download and Install GUIDGEN.EXE from (if you don't have it in VisualStudio tools)
http://www.microsoft.com/downloads/details.aspx?familyid=94551f58-484f-4a8c-bb39-adb270833afc&displaylang=en.
3. Download and install the latest build of WiX v3.0 (Wix3.msi) from
http://wix.sourceforge.net/downloadv3.html.
Build the add-on
The addon have to be registered with WMC and in GAC! In order to make a change you have to unregister it first and then to register again.
Also register it with Windows Media Center ( %windir%\ehome\RegisterMCEApp.exe)
Steps to switch to Canadian EPG in Windows Media Center
1) Install or check if it is installed HD HomeRun from
http://www.silicondust.com/support/hdhomerun/downloads/
2) Run EnableATSCandQAM.bat
3) Run USGuide.bat and select 4 (Toronto)
4) In WMC - >Tasks - >Settings -> TV -> TV Signal -> Setup TV Signal -> Select CANADA, M2N 6P4
How to Get EPG from WMC
1) Find C:\ProgramData\Microsoft\eHome\mcepg2-0.db
2) Build the WMC Addon with code from
http://social.msdn.microsoft.com/Forums/en/netfx64bit/thread/ea979075-f602-475d-b485-3a4f787dcb70 to http://experts.windows.com/frms/windows_entertainment_and_connected_home/f/25/p/79249/481843.aspx
- Note: the EPG also saved in MXF File. More info:
07 February 2012
Develop Android apps in C#
Great! Awesome! I've always wanted to write some neat mobile app, but was too lazy to learn Objective-C or Java topped with BlackBerry API or Android. That also meant learning a new IDE. Oh how lazy.
I actually even got myself Eclipse + Android SDK + Java SDK and started to play around with this but then I discovered MonoDroid, a wrap for Android for Visual Studio. I happily tossed away Java and jumped back to .Net.
So, this will give you the start :
It's almost the same Android API as in Java but using the C# syntax and .Net libraries.
Enjoy!
12 October 2011
WCF POX, JSON and SOAP Coexist
A great article, please check this out if you've got stuck on getting SOAP and REST working together
http://www.codemeit.com/wcf/wcf-restful-pox-json-and-soap-coexist.html
Thank you Ray :)
http://www.codemeit.com/wcf/wcf-restful-pox-json-and-soap-coexist.html
Thank you Ray :)
19 September 2011
Recommended references (.net Dev and related)
- Android
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.1_r2/android/widget/VideoView.java#VideoView.%3Cinit%3E(android.content.Context)
- C#
- DirectShow
http://www.gdcl.co.uk/dshow.htm
book
http://mathinfo.univ-reims.fr/image/mmVideo/cours/DirectShow3Annexe.pdf
code samples
http://www.informikon.com/directshow-tutorials/
forum
http://social.msdn.microsoft.com/Forums/en-US/windowsdirectshowdevelopment/threads
- XMarine
http://docs.xamarin.com/mono/api
forum
http://mono-for-android.1047100.n5.nabble.com/
open source (code samples)
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/2.1_r2/android/widget/VideoView.java#VideoView.%3Cinit%3E(android.content.Context)
- SQL Server Hacks and Handy scripts
http://wiki.lessthandot.com/index.php/Category:Microsoft_SQL_Server
Common Solutions for T-SQL Problems
http://archive.msdn.microsoft.com/SQLExamples
Some basics just in case
http://sqltutorials.blogspot.ca/search/label/SQL%20CASE
- Microsoft DOS and command prompt
http://ss64.com/nt/
- Find PInvoke* signature related to calling Win32
- Shell Objects
- Ask a Question
- Git
http://cheat.errtheblog.com/s/git
http://help.github.com
24 August 2011
UDP, TCP, RTP, RTSP, Unicast, Multicast... MPEG-1, MPEG-2, MPEG-4...
A data transfer protocol is a standardized format for transmitting data between two devices. The type of protocol used can determine such variables as the error checking method, the data compression method, and end-of-file acknowledgements. The protocols used to stream Windows Media-based content are RTSP and HTTP
Windows Media Services manages the use of these protocols by using control protocol plug-ins:
WMS RTSP Server Control Protocol plug-in and the WMS HTTP Server Control Protocol plug-in.
While the control protocol plug-ins handle the high-level exchange of data, basic networking protocols such as UDP and TCP are used to manage more fundamental tasks such as network connectivity and packet error correction. The RTSP protocol is used in combination with both the UDP or TCP protocols.
http://technet.microsoft.com/en-us/library/cc731604.aspx
Networking Standards :
TCP
It seems everyone's heard of "TCP/IP". You probably know that "IP" stands for "Internet Protocol". The "TCP" stands for "Transmission Control Protocol". Here is the deal: to ensure a packet arrives without errors, the sender of a packet keeps an extra copy and waits for the receiver to say "I got it okay". If the sender hears this from the receiver, the sender can discard that extra copy. If the receiver says "I didn't get it" or says nothing at all after awhile, the sender resends it. As you can see, this makes for reliable delivery but takes time. It also adds a great deal of overhead because there is a dialog between the sender and receiver. Practically all email, web pages, and other Internet traffic is sent using TCP/IP.
TCP is a key reason why your web traffic or email "slows down" but does not "break". When there is too much traffic, your packets may be discarded or lost somewhere...but not to worry! Without you even knowing it, your packets are being resent until they finally get through (and you thought you just had a "good" connection).
Analogy: TCP is like a telephone call. If you didn't hear what the other person said, you say "What?"
UDP
UDP stands for "User Datagram Protocol". It is sometimes called "send and pray" because there is no dialog between the sender and receiver. If the receiver does not get a packet, the sender will never know. "When the heck would I want that!" you may ask. Well, UDP is very efficient when there is little chance of errors (like in your LAN), or when TCP would provide "too late" delivery.
All VBrick video is sent via UDP. Hey, we are sending live video, right? If I send you video frame #1, #2, #3 .... #1000 and you display the video frames in real time as you receive them, and you didn't get frame #500, what would you do with new frame #500 if I resent it to you? Display it after frame #1000? That wouldn't look too good, would it?
Video is normally send via UDP. But there is trouble with UDP now-adays. Many corporate firewalls block all UDP packets, making it impossible for streaming video to reach desktops. This is done to prevent hackers from getting access to the network, and is also sometimes done to prevent excessive use of bandwidth. More on this later.
Analogy: UDP is like a public address system. If you didn't hear what was announced, you can't hear it again.
RTP
RTP stands for Real-time Transport Protocol. It is normally sent via UDP. It does not ensure "real time" but is a protocol that enhances the control and synchronization of real time stuff (like streaming video). Here is where it gets interesting: with MPEG-1 and MPEG-2, RTP is unnecessary because MPEG itself provides synchronization (see White Paper). Like so many standards, there are several ways to implement it. For example, you can split apart the MPEG-1 stream and send audio on one IP address and video on another, or you can send both audio & video on the same address. RTP provides timestamps that will provide audio/video sync. VBrick has long supported RTP in the VB3000 for interoperability with other vendors.
In the case of MPEG-4, the only meaningful way to send audio/video is via RTP (there is nothing like a "MPEG-1 System Stream" nor a "MPEG-2 Transport Stream"). In other words, for MPEG-4, a/v sync is provided via RTP.
Analogy: RTP is like an orchestra leader, keeping all the musicians in sync.
RTSP
RTSP stands for Real Time Streaming Protocol. RTSP is control protocol, not to be confused with IP, TCP, or UDP. However, RTP and RTSP are linked. You could find RTP without RTSP, but you would not find RTSP without RTP.
A good way to position RTSP in your mind is to think of it the same way you think of "http" and "ftp". You know, if you want to see a web page, you will enter "http://something". If you want to view a video in a player, you will enter "rtsp://something". This is only true for unicast streams, where each viewer receives their own stream from the server (i.e. from the VBrick). RTSP is not used for multicast.
Analogy: RTSP is like a "touch tone" telephone vs. the old rotary dial telephone. It is merely a method of signaling.
HTTP
The Hyper Text Transfer Protocol is often confused with the Hyper Text Markup Language. Its description is beyond the scope of this page, and on the surface seems out of place here. However, because virtually all firewalls allow the default http port (port 80) to pass, streaming video can be sent via http "tunneling". There is a severe penalty, since http is sent via TCP which increases the overhead by some 30% and magnifies the delay.
Unicast
Data (or video) can be sent via UDP or TCP, with RTP and RTSP, and can be sent via Unicast. So, Unicast is a method, not a protocol.
Unicast streaming is the default method by which a Windows Media server delivers content. A unicast stream is a one-to-one connection between the server and a client, which means that each client receives a distinct stream and only those clients that request the stream receive it.
Unicast streaming offers the benefits of interactivity between the player and server, easier setup, and multiple-bit-rate streaming capability. However, the number of users that are able to receive unicast streams is limited by the bitrate of the content and the speed of the server network. A large unicast audience can quickly overwhelm a network or server.
Multicast
Multicast streaming is a one-to-many relationship between a Windows Media server and the clients receiving the stream. With a multicast stream, the server streams to a multicast IP address on the network, and all clients receive the same stream by subscribing to the IP address.
This is different from Unicasting, and different from broadcasting (where everyone gets the data whether they want it or not). You normally have a one-way connection, ruling out TCP, so Multicast is done via UDP. There are methods in use where a receiver can signal a sender that it has received a bad packet using a different 'reverse channel'. This is called "reliable multicast" and has little value for live video transmission.
Analogy: Distributing brochures with a sign that says "Take One". Only those who want it take it.
SDP
The Session Description Protocol, for our purposes, is a file that describes a MPEG-4 stream. SDP files are uniquely created for each stream, whether the stream is multicast or unicast. SDP files are put on servers to allow them to identify a stream and replicate it to viewers.
MPEG-1 and MPEG-2 both combine audio and video into a series of 1's and 0's. Exactly how those 1's and 0's are created is defined by the MPEG standards. So, when we say "MPEG-2 Transport Stream", we can look at a document and agree on what we mean. MPEG-1 and MPEG-2 are self sufficient, but they do little to specify exactly how they might be transmitted over IP.
MPEG-4 is also self-sufficient, but rather than defining unique "MPEG" ways of sending video, it specifies sending the video using existing standards.
Among those standards are IP, RTP and RTSP.
You can send MPEG-4 video by wrapping the video steam in a RTP packet, wrapping the audio stream in another RTP packet, then wrapping each RTP packet in a UDP packet, then controlling the stream using RTSP. You can encapsulate the RTP in http if necessary (via an external server).You can send MPEG-1 System and MPEG-2 Transport streams via raw UDP (this is what we normally do in LANs). You can send MPEG-1 System Streams and MPEG-2 transport streams via RTP over UDP , e.g. stored video on demand.
Windows Media Services manages the use of these protocols by using control protocol plug-ins:
WMS RTSP Server Control Protocol plug-in and the WMS HTTP Server Control Protocol plug-in.
While the control protocol plug-ins handle the high-level exchange of data, basic networking protocols such as UDP and TCP are used to manage more fundamental tasks such as network connectivity and packet error correction. The RTSP protocol is used in combination with both the UDP or TCP protocols.
http://technet.microsoft.com/en-us/library/cc731604.aspx
Networking Standards :
TCP
It seems everyone's heard of "TCP/IP". You probably know that "IP" stands for "Internet Protocol". The "TCP" stands for "Transmission Control Protocol". Here is the deal: to ensure a packet arrives without errors, the sender of a packet keeps an extra copy and waits for the receiver to say "I got it okay". If the sender hears this from the receiver, the sender can discard that extra copy. If the receiver says "I didn't get it" or says nothing at all after awhile, the sender resends it. As you can see, this makes for reliable delivery but takes time. It also adds a great deal of overhead because there is a dialog between the sender and receiver. Practically all email, web pages, and other Internet traffic is sent using TCP/IP.
TCP is a key reason why your web traffic or email "slows down" but does not "break". When there is too much traffic, your packets may be discarded or lost somewhere...but not to worry! Without you even knowing it, your packets are being resent until they finally get through (and you thought you just had a "good" connection).
Analogy: TCP is like a telephone call. If you didn't hear what the other person said, you say "What?"
UDP
UDP stands for "User Datagram Protocol". It is sometimes called "send and pray" because there is no dialog between the sender and receiver. If the receiver does not get a packet, the sender will never know. "When the heck would I want that!" you may ask. Well, UDP is very efficient when there is little chance of errors (like in your LAN), or when TCP would provide "too late" delivery.
All VBrick video is sent via UDP. Hey, we are sending live video, right? If I send you video frame #1, #2, #3 .... #1000 and you display the video frames in real time as you receive them, and you didn't get frame #500, what would you do with new frame #500 if I resent it to you? Display it after frame #1000? That wouldn't look too good, would it?
Video is normally send via UDP. But there is trouble with UDP now-adays. Many corporate firewalls block all UDP packets, making it impossible for streaming video to reach desktops. This is done to prevent hackers from getting access to the network, and is also sometimes done to prevent excessive use of bandwidth. More on this later.
Analogy: UDP is like a public address system. If you didn't hear what was announced, you can't hear it again.
RTP
RTP stands for Real-time Transport Protocol. It is normally sent via UDP. It does not ensure "real time" but is a protocol that enhances the control and synchronization of real time stuff (like streaming video). Here is where it gets interesting: with MPEG-1 and MPEG-2, RTP is unnecessary because MPEG itself provides synchronization (see White Paper). Like so many standards, there are several ways to implement it. For example, you can split apart the MPEG-1 stream and send audio on one IP address and video on another, or you can send both audio & video on the same address. RTP provides timestamps that will provide audio/video sync. VBrick has long supported RTP in the VB3000 for interoperability with other vendors.
In the case of MPEG-4, the only meaningful way to send audio/video is via RTP (there is nothing like a "MPEG-1 System Stream" nor a "MPEG-2 Transport Stream"). In other words, for MPEG-4, a/v sync is provided via RTP.
Analogy: RTP is like an orchestra leader, keeping all the musicians in sync.
RTSP
RTSP stands for Real Time Streaming Protocol. RTSP is control protocol, not to be confused with IP, TCP, or UDP. However, RTP and RTSP are linked. You could find RTP without RTSP, but you would not find RTSP without RTP.
A good way to position RTSP in your mind is to think of it the same way you think of "http" and "ftp". You know, if you want to see a web page, you will enter "http://something". If you want to view a video in a player, you will enter "rtsp://something". This is only true for unicast streams, where each viewer receives their own stream from the server (i.e. from the VBrick). RTSP is not used for multicast.
Analogy: RTSP is like a "touch tone" telephone vs. the old rotary dial telephone. It is merely a method of signaling.
HTTP
The Hyper Text Transfer Protocol is often confused with the Hyper Text Markup Language. Its description is beyond the scope of this page, and on the surface seems out of place here. However, because virtually all firewalls allow the default http port (port 80) to pass, streaming video can be sent via http "tunneling". There is a severe penalty, since http is sent via TCP which increases the overhead by some 30% and magnifies the delay.
Unicast
Data (or video) can be sent via UDP or TCP, with RTP and RTSP, and can be sent via Unicast. So, Unicast is a method, not a protocol.
Unicast streaming is the default method by which a Windows Media server delivers content. A unicast stream is a one-to-one connection between the server and a client, which means that each client receives a distinct stream and only those clients that request the stream receive it.
Unicast streaming offers the benefits of interactivity between the player and server, easier setup, and multiple-bit-rate streaming capability. However, the number of users that are able to receive unicast streams is limited by the bitrate of the content and the speed of the server network. A large unicast audience can quickly overwhelm a network or server.
Multicast
Multicast streaming is a one-to-many relationship between a Windows Media server and the clients receiving the stream. With a multicast stream, the server streams to a multicast IP address on the network, and all clients receive the same stream by subscribing to the IP address.
This is different from Unicasting, and different from broadcasting (where everyone gets the data whether they want it or not). You normally have a one-way connection, ruling out TCP, so Multicast is done via UDP. There are methods in use where a receiver can signal a sender that it has received a bad packet using a different 'reverse channel'. This is called "reliable multicast" and has little value for live video transmission.
Analogy: Distributing brochures with a sign that says "Take One". Only those who want it take it.
SDP
The Session Description Protocol, for our purposes, is a file that describes a MPEG-4 stream. SDP files are uniquely created for each stream, whether the stream is multicast or unicast. SDP files are put on servers to allow them to identify a stream and replicate it to viewers.
MPEG-1 and MPEG-2 both combine audio and video into a series of 1's and 0's. Exactly how those 1's and 0's are created is defined by the MPEG standards. So, when we say "MPEG-2 Transport Stream", we can look at a document and agree on what we mean. MPEG-1 and MPEG-2 are self sufficient, but they do little to specify exactly how they might be transmitted over IP.
MPEG-4 is also self-sufficient, but rather than defining unique "MPEG" ways of sending video, it specifies sending the video using existing standards.
Among those standards are IP, RTP and RTSP.
You can send MPEG-4 video by wrapping the video steam in a RTP packet, wrapping the audio stream in another RTP packet, then wrapping each RTP packet in a UDP packet, then controlling the stream using RTSP. You can encapsulate the RTP in http if necessary (via an external server).You can send MPEG-1 System and MPEG-2 Transport streams via raw UDP (this is what we normally do in LANs). You can send MPEG-1 System Streams and MPEG-2 transport streams via RTP over UDP , e.g. stored video on demand.
Subscribe to:
Posts (Atom)