SetRate() of a H264-Video

[rippi]

Hello again,

I am just writing a small test application for playing videos.
I defined some own rules for the ThreadedDemuxer and then I wanted to set the rate manually BEFORE starting the video play: threadedDemuxer->SetRate(1.0). There should not be any changes in the behaviour of the player, because the default rate is also 1.0, of course.
Well, there are no problems in playing a Mpeg video stream, but I cannot play a H264 video (encapsulated in a Mpeg2ts).
The main problem is that the demuxer aborts reading the video data from a file after a short time and the debugger says that there ist not enough buffer (I marked the abnormal lines of the degugger):

PID 3360, ThreadedDemuxer::ThreadRoutine(): ThreadedDemuxer: Init completed: Reason: buffer(track=0) is full
PID 3360, ThreadedDemuxer::ThreadRoutine(): ThreadedDemuxer: thread exited with res = -896
PID 3360, ThreadedDemuxer::SetRate(): ThreadedDemuxer: new rate = 1.000000
PID 3360, ThreadedDemuxer::ThreadRoutine(): ThreadedDemuxer: Init completed: Reason: END_OF_STREAM
PID 3360, ThreadedDemuxer::ThreadRoutine(): ThreadedDemuxer: Init completed: unexpected error
PID 3360, ThreadedDemuxer::ThreadRoutine(): ThreadedDemuxer: thread exited with res = -895

Does anybody know this problem or what to do?

Thanks

[rippi]

Hi,
after some long hours I have got some new ideas about my SetRate problem.
Unfortunately I did not find the solution yet.

I found out, that forward playing of a mpeg video works quite find. But I do not know if it is right, that the duration of a video with a rate of 4.0 e.g. stays the same as with a rate of 1.0. There are just a few frames skipped. Is this right?

When I wanted to play a H264 video I realized, that the UMC::FrameConstructor only finds about 10% of all frames in the stream. The found frames are added to the list of samples and they are in regards of contents correctly (PTS and DTS are set).
After this the ThreadRoutine of UMC::ThreadedDemuxer aborts with the error message UMC::UMC_ERR_NOT_ENOUGH_BUFFER. The method GetNextData() of the ThreadedDemuxer says UMC::UMC_ERR_END_OF_STREAM. UMC::UMC_ERR_NOT_ENOUGH_BUFFER causes that the parameter of the blocking ID is set to the ID of the current track. That is my video. That is the reason why the GetNextData method of the UMC::Demuxer cannot deliver the UMC::MediaData of my video track.

A possible solution for SetRate(1.0) is to change the Reset method of the UMC::FrameConstructor:

Status FrameConstructor::Reset() {

AutomaticMutex guard(m_synchro);

//while (UMC_OK == m_OutputQueue.Remove());

m_bEndOfStream = false;

m_bIsOutputBufferLocked = false;

//m_lLastBytePos = 0;

m_lFirstBytePos = 0;

m_lCurPos = 0;

m_lCurPicStart = 0;

m_iCurrentLevel = 0;

//m_uiCommitedFrames = 0;

//m_uiTotalFrames = 0;

m_CurFrame.Reset();

m_LastFrame.SetBufferPointer(NULL, 0);

m_LastFrame.SetAbsPos(0);

m_LastFrame .SetTime(-1.0, -1.0);

return UMC_OK;

}

A precondition for thid solution is, that the SetRate method is called before the Run method of the ThreadedDemuxer. Setting another rate is possible, but the it will not the realized correctly in practice. Only about 10% of all frames can be extracted by the GetNextData method and only a fractional amout of them are displayed in the simple player. The playback starts very late.

Noticeably is also that there are about 10% more elements in the sample list than normal. So the elements should not be deleted in practice as I did in the example above.

This about forward playing. The backward playing seems not to work neither for mpeg videos nor for H264 videos. It is possible to set a negative rate, but the videos is played forward. Only the beginning of the video is shown, then it stops without an error message.

I would be very very thankful for a answer of my post and just more happy about a hint of what I can do now. A correctly working SetRate method would be very helpful for my application. Otherwise I have to implement all of the functions by myself. Additionally I ask myself if it is my fault, that I do not use the method correctly or if it really a bug in the UMC classes.

So, please help my!!!
Thanks

[Chao_Y_Intel]

Hello,

Could you please suggest if there is only one SPS/PPS in bit stream? Is the following information be usefual for this case?

In threadeddemuxer, 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.

Thanks,
Chao