.codecdemuxerincludeumc_demuxer.h: virtual Status SetTimePosition(Ipp64f timePos);
.codecdemuxerincludeumc_threaded_demuxer.h: virtual Status SetTimePosition(Ipp64f timePos);
.codecdemuxersrcumc_demuxer.cpp: Status Demuxer::SetTimePosition(Ipp64f timePos)
.codecdemuxersrcumc_threaded_demuxer.cpp: Status ThreadedDemuxer::SetTimePosition(Ipp64f timePos)
.codecdemuxersrcumc_threaded_demuxer.cpp: Status umcRes = m_pDemuxer->SetTimePosition(timePos);
.codecmpeg4_splincludeumc_spl_base.h: virtual Status SetTimePosition(Ipp64f position); // in second
.codecmpeg4_splsrcumc_spl_base.cpp: Status SplitterBase::SetTimePosition(Ipp64f position)
.codecvc1_splincludeumc_vc1_spl.h: virtual Status SetTimePosition(Ipp64f timePos);
.codecvc1_splsrcumc_vc1_spl.cpp: Status VC1Splitter::SetTimePosition(Ipp64f /*start_time*/)
.coreumcincludeumc_splitter.h: virtual Status SetTimePosition(Ipp64f /*timePos*/)
Note to users: after calling SetTimePosition, you must call Run.
Will also post in premier.intel.com
Thanks for sharing such information. Working with our threadeddemuxer expert, we have a summary on threadeddemuxer usage. I also copy here. Hopt it would be helpful for other users.
1)Before calling SetTimePosition()/SetRate(), users should call Stop() functions first. In the current release, the threadeddemuxer will call stop() in SetTimePosition()/SetRate() functions themselves, but we still suggest that user call stop() first for future release consistency.
2)After calling SetTimePosition()/SetRate() functions, users should call run() functions. run() method will start splitting the stream from the new place. Without such functions call, user may get "UMC_ERR_NOT_ENOUGH_DATA" error message when they call GetNextData() functions.
3) For some bit streams, after calling SetTimePosition()/SetRate(), users may get "UMC_ERR_END_OF_STREAM" errors when they try to get next portion of data. In many cases, that is because there is only ONE sequence header in the video stream (or only one SPS/PPS for H.264 video). SetTimePosition()/SetRate() will make the splitter go to some random point of video stream. The following run() function call will try to locate and parse the next sequence header before start to construct frames. Because there is only one sequence header (or SPS/PPS headers) at the beginning of the video, run() function will make the splitter go the end of the stream without finding further data. So calling GetNextData() will get UMC_ERR_END_OF_STREAM error message. The ThreadedDemuxer request the bit stream has multiple sequence headers if the video can be randomly accessed by SetTimePosition() or SetRate() functions calls
Your third comment worries me. Every MPEG-2 stream that I've seen has a sequence header packet with each I-frame (i.e., normally every fourteen frames). But I am less expert on MPEG-4 streams and my current project involves the use of them. Will find out soon if the MPEG-4 streams that I need to work with have regular SPS/PPS packets.