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.
链接已复制
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.
Hello
You maycopy the file to ftp://ftp.intel.com/pub/incoming/(where IE is also able to access)
and let us know the file name. (If the file is private, you can mark the post Private=Yes)
Regards,
Ying
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.
Thanks.
[I work with Bob.]
Yes, Run is called, here is a snippet of the code:
// if reposition requested
if (m_bProgressRepositionVideo)
{
TRACE("VideoThread %s Splitter::SetTimePosition %.3lf\n", (LPCTSTR)m_strStreamDisplayPath, m_lfProgressReposition);
m_bProgressRepositionVideo = FALSE;
// stop splitter
splitter->Stop();
// flush decoder
decoder->GetFrame(NULL, &videoOut);
// reposition splitter
if (m_lfProgressReposition > m_lfStartTime)
splitter->SetTimePosition(m_lfProgressReposition - m_lfStartTime);
else
splitter->SetTimePosition(0);
// restart splitter
splitter->Run();
// 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?
Hello Frank,
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.
Regards,
Paul
short postscript...
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)
m_iLastReturned++;
else
while (m_iLastReturned >= 0 && pEntryArray[m_iLastReturned].GetTimeStamp() > time)
m_iLastReturned--;
}
