Have H.264 MP4 file that plays well but upon calling SetTimePosition appears to hang the splitter [no more frames can be extracted]. QuickTime has no problem playing the file and repositioning during playback. Is there a way to submit the file to Intel for analysis? It is 12MB. Thanks.
Uploaded sdvideo_demo.mp4 to pub/incoming.
To repeat, sequential playback [IPP 6.0.0.062] is successful. However,when SetTimePosition is called, splitter hangs. In contrast, QuickTime is able to reposition during playback w/o problem.
[I work with Bob.]
Yes, Run is called, here is a snippet of the code:
// if reposition requested
TRACE("VideoThread %s Splitter::SetTimePosition %.3lf\n", (LPCTSTR)m_strStreamDisplayPath, m_lfProgressReposition);
m_bProgressRepositionVideo = FALSE;
// stop splitter
// flush decoder
// reposition splitter
if (m_lfProgressReposition > m_lfStartTime)
splitter->SetTimePosition(m_lfProgressReposition - m_lfStartTime);
// restart splitter
// set flags
bRepositionRestart = TRUE;
m_nDiscardFrame = 1;
There is a post from Artem on Intel Premier stating that SetTimePosition is not implemented and not supported, and that repositioning while playing any codec is not supported by Intel.
Obviously SetTimePosition is implemented, just look at the IPP/UMC source code.
Obviously SetTimePosition works for many files, try many MPEG-2 and MPEG-4 files.
Why would Intel make such a post?
We've received some clarification from engineering regarding the issue you are having trouble with. The SetTimePosition function is not designed to deal with fragmented streams, only continuous streams.
Here is some feedback from the engineer:
Fragmented MP4 streams have a separate index for each fragment that is why such streams can be played infinitely. On the other hand, it is impossible to implement reposition in an infinite stream. Moreover all fragments can have the same time stamp for the 1st video frame of a fragment. UMC MP4 splitter should support repositioning inside one fragment only. But this feature has never been tested.
My understanding is that this means the SetTimePosition method (and some related methods?) needs, at best, to be augmented to keep track of numbers and sizes of fragments in order to work with a fragmented stream. At worst, it needs to be modified to avoid causing a crash, but that would not necessarily allow repositioning over a fragmented stream.
Theres a bug in TrackIndex::GetEntry method (umc_index.cpp).
The problem is that fragments in your stream consist of 1 frame only and we get
an infinite value in calculations when we try to find the right frame for SetTimePosition.
Ive fixed the issue by adding the lines in bold in the file mentioned above:
m_iLastReturned = 0;
if (nOfEntries > 1)
// approximate position of requested entry
m_iLastReturned = (Ipp32s)(nOfEntries * (time - dStartTime) / (dEndTime - dStartTime));
if (pEntryArray[m_iLastReturned].GetTimeStamp() < time)
while (m_iLastReturned + 1 < nOfEntries && pEntryArray[m_iLastReturned + 1].GetTimeStamp() < time)
while (m_iLastReturned >= 0 && pEntryArray[m_iLastReturned].GetTimeStamp() > time)