References ▼
This is the interface for the LEAD MPEG2 Transport UDP Source filter.
You can control this filter using this interface and by passing parameters to the UDP Source URL. See the UDP Source URL Syntax topic for more information on the URL parameters.
| Type | Name | Description |
|---|---|---|
| IUnknown * | CallbackObj | The user callback that will be called when certain events occur. At the moment, there is only one event (EVENTTYPE_NODATAAVAILABLE), which indicates the UDP source has not received any data. You can use this callback to receive notifications indicating no data is arriving and cancel the wait. |
| The user callback object should implement the ILMSrcCallback interface. | ||
| LEADTOOLS uses this interface internally when you load a stream using the UDP source filter. The Play and Convert objects will automatically intercept the ILMSrcCallback notifications and will send MediaEvent notifications to inform you when EVENTTYPE_NODATAAVAILABLE is fired by the UDP source. In other words, you do not need to implement the ILMSrcCallback interface to take advantage of this feature. See the Aborting Loading From The RTSP, ONVIF, and UDP Source Filters topic for more information. | ||
| VARIANT_BOOL | CallInSameThread | Enables or disables the calling of the CallbackProc notifications in the same thread that set the ReceiveProcObj property. Possible values are: |
| • VARIANT_TRUE - Call the notifications in the same thread that set the callback. This reduces the performance and requires the application to process messages, otherwise the callback will not get called. It is the default and is required for platforms that have problem with multi-threading, like VB 6.0 or .NET. This is the default. | ||
| • VARIANT_FALSE - Call the notifications in any thread of the process. Use this setting for best performance in platforms that can handle this. This is the recommended mode for C++ applications. But you should be aware that your callback will not be called in the main thread, so you need to take care when you interact with the user interface. |
Stops the process of logging the time information.
Time information can be used to determine exactly when the source started receiving data.
Logging can be enabled in the source by the URL, See the UDP Source URL syntax topic for more information.
Logging will increase the amount of memory used by the process, so it is recommended that you disable logging by calling StopLogging once the start time for the received stream has been logged.
| Return | Description |
|---|---|
| S_OK | Successful. |
| < 0 | An error occurred. |
Specifies the stream offset (in bytes) for which you want to get the receive time.
Pointer to a variable that will be updated with the receive time (in 100-nanosecond intervals since January 1, 1601 (UTC)).
Returns the time at which data for a certain stream offset has been received.
The method will succeed only if logging has been enabled for this stream by passing the Logging=1 parameter to the URL. See the UDP Source URL syntax topic for more information on the URL syntax.
You will typically call this method to get the receive time at which the first key frame in the stream has been received. You can also call it to get the receive time for offset 0, but that might not be too useful since there is no guarantee that the data at offset 0 contains the first key frame in the stream. And using the receive time for offset 0 can induce slight errors in the calculations in situations in which the first key frame was received hundreds of milliseconds or even seconds after the initial data.
So it is recommended you call this method using the offset you received from ILMMpgDmx::StartStreamOffset, because that is the offset of the first key frame in the stream.
Once you have the receive time, you can convert it to a filename by using ConvertTimeToString. And you can convert the filename back to the receive time using ConvertStringToTime. Embedding the receive time into the filename allows you to preserve the receive time without the need for storing the value in an extra database through some other external means.
The receive time is in 100-ns units since January 1, 1601, equivalent to the FILETIME Windows API structure value. In .NET, you can convert this value using the DateTime.FromFileTime method.
To find out the difference in seconds between two ReceiveTime values, you can use this formula (commas were added to make it easier to see the number of zeros):
diff_in_seconds = (ReceiveTime1 - ReceiveTime2) / 10,000,000
Here is some pseudo-code showing you how you put all these together (error checking is ignored to make the code easier to understand):
void SetOutputFilenameAndStartConverting(IltmmConvert *pConvert){// set the source URL with logging enabled (very important)pConvert->put_SourceFile(L"udp://127.0.0.1:9005?Logging=1");pConvert->put_TargetFormat(ltmmCapture_TargetFormat_MPEG2_TRANSPORT);pConvert->put_TargetFile(L""); /* set a dummy output file to build the graph */CComPtr pUnknown;pConvert->GetSubObject(ltmmConvert_Object_SourceFilter, &pUnknown);CComPtr pUDPSrc;pUnknown->QueryInterface(IID_ILMUDPSrc, (void **)&pUDPSrc);pUnknown.Release();pConvert->GetSubObject(ltmmConvert_Object_Splitter, &pUnknown);CComPtr pDmx;pUnknown->QueryInterface(IID_ILMMpgDmx, (void **)&pDmx);double startOffset;pDmx->get_StartStreamOffset(&startOffset); /* get the start offset */double receiveTime;pUDPSrc->GetReceiveTime(startOffset, &receiveTime); /* get the receive time */pUDPSrc->StopLogging(); /* stop logging now that I have the receive start time */BSTR outputFilename;pUDPSrc->ConvertTimeToString(receiveTime, L"c:\\output\\", L".mpg", &outputFilename);pConvert->put_TargetFile(outputFilename); /* set the real output filename */SysFreeString(outputFilename); /* free the string returned by ConvertTimeToString */pConvert->StartConvert();}
| Return | Description |
|---|---|
| S_OK | Successful. |
| < 0 | An error occurred. |
| LTMM_E_LOGGING_NOT_STARTED | Logging was not enabled (you did not pass "?Logging=1" to the UDP URL). |
Converts a receive time obtained from GetReceiveTime. Convert the string back to the receive time using the ConvertStringToTime method.
The receive time, in 100ns units since January 1, 1601 (UTC) (as obtained from GetReceiveTime).
Optional string containing the prefix (usually the folder where you will store the output file).
Optional string containing the suffix (usually the file extension).
Pointer to a variable that will be updated with the string. The value returned should be freed using the SysFreeString windows API function.
The string returned by this function will be as follows:
<pszPrefix>YYYY_MM_DD__hh_mm_ss_fff<pszSuffix>
Where <pszPrefix> and <pszSuffix> are the valued passed as parameters, YYYY, MM and DD represent the date (year using 4-digits, month and day using 2 digits) and hh, mm and ss are the time (hours, minutes, seconds using 2 digits) and fff are milliseconds using 3 digits.
| Return | Description |
|---|---|
| S_OK | Successful. |
| < 0 | An error occurred. |
| E_POINTER | pRet is invalid (NULL) |
| E_OUTOFMEMORY | There is not enough memory to allocate the resulting string. |
Converts a string obtained from ConvertTimeToString back to the value returned by GetReceiveTime.
The string as returned by ConvertTimeToString.
Pointer to a variable that will be updated with the receive time, in 100ns units since January 1, 1601 (UTC).
The source string passed to the function should have the following format, (otherwise the method will fail):
<pszPrefix>YYYY_MM_DD__hh_mm_ss_fff<pszSuffix>
<pszPrefix> and <pszSuffix> will be ignored and the time will be reconstructed using the time indicated by YYYY, MM, DD, hh, mm, ss and fff.
See GetReceiveTime for more information on how to convert the receive time to other values that might be useful.
| Return | Description |
|---|---|
| S_OK | Successful. |
| < 0 | An error occurred. |
| E_POINTER | pReceiveTime are invalid (NULL). |
| E_INVALIDARG | The pszString value is not formatted correctly. Make sure it is the same value returned by ConvertTimeToString. |