- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Robert,
Did you called 'Run' method of splitter after SetTimePosition?
Thanks,
Artem
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
[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;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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--;
}

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page