UDP Source URL Syntax

The UDP source will usually play MPEG-2 Transport data streamed over UDP or TCP sockets. But it can also play raw data packetized in RTP packets (H264, JPEG, uncompressed, etc). Some of these formats (eg: JPEG) contain all the data needed to stream the video. Others (eg: H264, uncompressed) need extra information to be passed on the URL to describe the data format. See the Notes below for a discussion on how to describe raw H264(Note 2) and uncompressed video (Note 3).

The UDP source will listen for 16 seconds for incoming data. If nothing comes in during this time, the load will fail. You can change the value of the timeout using the "Timeout" parameter described below (Note 4).

The format of the string for UDP streaming is as follows:

   udp://ip_address[:udp_port][/network_card][?param1=val1[&param2=val2]...[&paramN=valN]]

The format of the string for TCP streaming is as follows:

   tcp://ip_address[:udp_port][/network_card][?param1=val1[&param2=val2]...[&paramN=valN]]

UDP Streaming

The format of the string for UDP streaming is as follows:
 

 TCP Streaming

The format of the string for TCP streaming is as follows:

Note 1: List of parameters used by the UDP Source filter

Here is a list of the "paramN" parameters described above.

Note 2: Parameters used to describe raw H264 video streams

H264 streams sent inside RTP packets use dynamic payloads with a payload type between 96 and 127. These streams can only be decoded when there is extra information being sent using a separate communication channel. The most common method of sending this extra information is through a Session Description Protocol (also known as SDP). The SDP contains extra information describing the stream. The UDP source needs only the following:

• The payload number and the compression associated with it.

• The number of RTP units per second.

• The sequence header information (if it is not sent with the video stream).

The UDP source needs to know this information in order to process these streams. There are two useful parameters right now (rtpmap and fmtp) and their syntax is described as follows:

• rtpmap=payload_type;compression/RTP_units_per_second

These values are usually sent in the SDP information via the a=rtpmap line, as in the following example:

a=rtpmap:99 H264/90000

This should be translated by replacing the space with semicolon (';) into

rtpmap=99;H264/90000

So, the URL syntax for a H264 stream sent to port 40000 containing RTP packets with a payload of 99 and with sequence header packets (NAL units 7 and 8) sent inside the compressed stream is something like this:

udp://192.168.1.100:40000?rtpmap=99;H264/90000

•  fmtp=payload_type;sprop-parameter-sets="seq1,seq2,...,seqN"

These values are usually sent in the SDP information via the a=fmtp line, as in the following example:

a=fmtp:96 packetization-mode=1; profile-level-id=420029; sprop-parameter-sets=Z0IAKeKQFge2BqwYBBuHiRFQ,aM48gA==

In the above example, there are two sequence header strings following the sprop-parameter-sets, separated with a comma. The UDP source filter is interested only in the sprop-parameter-sets field, so this line should be translated into:

fmtp=96;sprop-parameter-sets="Z0IAKeKQFge2BqwYBBuHiRFQ,aM48gA=="

And this pair should be appended to the URL to form something like this:

udp://192.168.1.100:40000?rtpmap=99;H264/90000&fmtp=96;sprop-parameter-sets="Z0IAKeKQFge2BqwYBBuHiRFQ,aM48gA=="

The above URL syntax describes a stream streaming on port 40000, with H264 data inside RTP packets with payload type set to 99, with 90000 RTP units per second and whose sequence headers are not part of the stream. Instead, they are passed through the sprop-parameter-sets component of the fmtp parameter.

Note 3: Parameters used to describe raw uncompressed video streams

Uncompressed streams sent inside RTP packets use dynamic payloads with a payload type between 96 and 127. These streams can only be decoded when there is extra information being sent using a separate communication channel. The most common method of sending this extra information is through a Session Description Protocol (also known as SDP). The SDP contains extra information describing the stream. The UDP source needs only the following:

• The payload number and the compression associated with it.

• The number of RTP units per second.

• The video characteristics (colorspace, width, height, bits per channel).

The UDP source needs to know this information in order to process these streams. There are two useful parameters right now (rtpmap and fmtp) and their syntax is described as follows:

• rtpmap=payload_type;compression/RTP_units_per_second

For uncompressed video, compression should be 'raw', so you need to pass: rtpmap=payload_type;raw/RTP_units_per_second.

• fmtp=payload_type;sampling=sampling_mode;width=video_width;height=video_height;depth=bits_per_channel

Right now, only the following values are accepted

sampling_mode: YCbCr-4:2:2

video_width: any positive value that is a multiple of 2

video_height: any positive value

bits_per_channel: 8 (note that this means each component is 8 bits, not that there are 8 bits/pixel)

So this is a valid example for the fmtp option:

fmtp=112;sampling=YCbCr-4:2:2;width=1280;height=750;depth=8

Putting both options together, this URL tells the UDP source filter to load uncompressed, 1280x750 UYVY video from port 8003:

udp://192.168.6.101:8003?rtpmap=112;raw/90000&fmtp=112;sampling=YCbCr-4:2:2;width=1280;height=750;depth=8

Note that for the above particular case, the first few lines contains VANC (non-video) data. The useful video might have 720 or even only 480 lines. Also, the useful data might start from a certain column in the video. In such cases, you can use the LEAD Video Crop Filter to strip out non-image data and leave only the useful video portion. These details are specific to the device used to stream the video and you should consult that device's manual for more information.

Examples of Valid Strings

udp://127.0.0.1:9005 - Receives the Unicast stream from 127.0.0.1 on port 9005

udp://224.1.1.1:9005/20.5.1.200 - Receives the Multicast stream 224.1.1.1 on port 9005 using the network card with the IP address of 20.5.1.200

tcp://127.0.0.1:9005 – Receives the TCP stream from 127.0.0.1 (local computer) on port 9005

udp://192.168.1.100:40000?rtpmap=99;H264/90000 - Receives a Unicast stream containing raw H264 video with sequence headers from 192.168.1.100 on port 40000. The stream uses dynamic RTP packets with payload type 99 and the timestamps unit is 1/90000 of a second.

udp://192.168.1.100:40000?rtpmap=99;H264/90000&fmtp=99;sprop-parameter-sets="Z0IAKeKQFge2BqwYBBuHiRFQ,aM48gA==" - Receives a Unicast stream containing raw H264 video without sequence headers from 192.168.1.100 on port 40000. The stream uses dynamic RTP packets with payload type 99 and the timestamps unit is 1/90000 of a second.

udp://192.168.6.101:40000?rtpmap=99;raw/90000&fmtp=99;sampling=YCbCr-4:2:2;width=1280;height=720;depth=8 - Receives a Unicast stream containing raw uncompressed video conforming with RFC 4175 from 192.168.6.100 on port 40000. The stream uses dynamic RTP packets with payload type 99 and the timestamps unit is 1/90000 of a second. See  for more details on the syntax for playing raw uncompressed streams.

Note 4: Timeout (selected with Timeout=xxx):

While waiting for data, ltmm sends the application EC_LOADSTATUS messages informing it that the UDP source is waiting for data. If the user decides to abort the wait, you can call ResetSource, which will abort the load process with the E_ABORT error.

Append the “?Timeout=xxx” to the URL to specify a timeout value. xxx is the value in seconds of how long to wait. The default value is 16 seconds. Pass 0 for infinite wait.

Syntax:

udp://ip_address[/network_card][:udp_port]?Timeout=xxx

You can combine the Timeout parameter with the other parameters using the '&' character. For example, the following URL will specify a timeout of 60 seconds while loading a Raw H264 stream:

udp://192.168.1.100:40000?Timeout=60&rtpmap=99;H264/90000&fmtp=96;sprop-parameter-    sets="Z0IAKeKQFge2BqwYBBuHiRFQ,aM48gA=="

In the above example, I specified 3 parameters (Timeout, rtpmap and fmtp).

The toolkit sends EC_LOADSTATUS with Param1 set to AM_LOADSTATUS_WAITING_FOR_DATA and Param2 set to the number of milliseconds elapsed since the UDP source started waiting. The following example aborts the wait after 10 seconds:

LRESULT CMainFrame::OnPlayerNotify(WPARAM wParam, LPARAM lParam)

{

   switch(wParam)

   {

   case ltmmPlay_Notify_MediaEvent:

      {

         ltmmMediaEvent *pEventParams = (ltmmMediaEvent *)lParam;

         if(pEventParams && pEventParams->lEventCode == ltmmEC_LOADSTATUS)

            if(pEventParams->lParam1 == ltmmAM_LOADSTATUS_PROGRAM_PACKET_RECEIVED)

            {

               // MPEG2 Transport Demux has detected how many elementary streams are in the MPEG-2 Transport stream

               // you can now tell it to speed up the load by waiting only for the video streams to be discovered

               ILMMpgDmx *pMpgDmx = GetMPEG2DemuxInterface();

               if(pMpgDmx)

               {

#ifdef EXCLUDE_NONVIDEO_STREAMS

                  CMPEG2DemuxCallback::MarkNonVideoStreamsUnimportant(pMpgDmx);

#endif

                  pMpgDmx->Release();

               }

            }

            else if(pEventParams->lParam1 == ltmmAM_LOADSTATUS_WAITING_FOR_DATA)

            {

               if(pEventParams->lParam2 >= 10000)

                  m_player->ResetSource();   // abort the load if it takes more than 10 seconds

            }

      }

}