Splitter::SetTimePosition Broken?

[franknatoli]

Tried using Splitter::SetTimePosition for both MP4Splitter (for MPEG-4) and ThreadedDemuxer (for MPEG-2) and in both cases the splitter subsequently only returns UMC_ERR_NOT_ENOUGH_DATA. None of the UMC sample applications use SetTimePosition. In fact, SetTimePosition is only referenced as listed below. Has anyone used SetTimePosition (to reposition a playback)?

.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*/)

[franknatoli]

umc_threaded_demuxer::SetTimePosition calls internal method "Stop" which then calls the generic demuxer method "Stop". After completing the repositioning, the IPP code fails to restart the demuxer, hence calls to the splitter fail with UMC_ERR_NOT_ENOUGH_DATA.

Note to users: after calling SetTimePosition, you must call Run.

Will also post in premier.intel.com

[Chao_Y_Intel]

Hi Frank,

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.

Thanks,
Chao

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

[franknatoli]

Thanks, Chao. Your comments are consistent with my observations. Perhaps the recommended usage should be incorporated into the umc-manual.pdf? And perhaps the UMC sample applications should make use of SetTimePosition in some way [none presently do]?

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.