demuxer / muxer problems

[rippi]

We use the UMC classes for some special issues and came upon some problems.

Our application reads a video from a file and writes it into a new file without changing the data in between. The order of the applications`s activities is: Read video data, read meta data, write video data, write meta data.

The source video is a H264 stream and it is encapsulated in a MPEG2TS together with some vbi data (=meta data). The video was generated by us with the help of the UMC classes as described in my previous posting "Mpeg2 ts with VBI Data".

My problem is, that the target file is about 20% greater than the origin file. To get to the bottom of this strange thing I wrote some data into a log file. So I realised that the splitter (ThreadedDemuxer) extracts about 20% of all frames and then starts at the beginning of the stream again. A video player (VLC) starts playing the created video without showing anything for the first 20% of the video stream. But then the whole video is shown. In between VLC says something about "late picture skipped". But I think that`s another problem.
When I searched for the reasons for the reset of the splitter I reached the FrameConstructor`s Reset() method (just like the SetRate() problem I already posted a few weeks ago). Maybe these two problems correspond in some way? (btw. the SetRate() problem still exist because I didn't receive any response)

To affirm the result I did the whole thing with the generated file again. The log files showed that the muxers`s GetNextData() method sometimes does not find a frame in the stream (UMC::Status = -996). Then the next meta data is read and then the splitter finds the next frame after 180000 Bytes (normal are 1500 - 1600 Bytes).
It seems, that when the video is generated some data is put into the stream.
What could be the reason for this?
Do I have to change any important parameters?
What could be the corresponding parameters?

I already tried to change the preferred input and output buffer sizes but they had no affect on the generated video.
Is that correct? I did not find any documentation about this.
But the even more interesting question: I`m using track rules instead of splitter flags, beause I need them for the vbi data. Is that right? I experimented with the flags, too, but I just used the flags FLAG_VSPL_STOP_AFTER_INIT and FLAG_VSPL_FAST_INIT. It didn`t seem that they could help with the problem. It was only my guess, I am not sure I understood the meaning of this flags properly.

[Vladimir_Dudnik]

Hello,

I've submitted your issue to Intel Premier Support, so you will be updated regarding investigation status. Please also provide some additional information which can help us to understand the problem (version of IPP/samples, OS, hardware platform). If it is possible to provide small test stream to reproduce the issue it also may help us.

Regards,
Vladimir

[rippi]

Hello,

here are the necessary information:

- IPP Version 5.3
- Microsoft Windows XP Professional, Version 2002, Service Pack 2
- CPU: Intel Core 2 Dou

Unfortunately the upload of the videos failed.

Greetings

[Ali_Gökalp_P_]

We've implemented DataReader to read from a stream source ,and of course it doesn't support to get absolute position or size.Problem is we demux transmitted MPEG2TS data that includes video and private stream( demuxer modified as Rippi wrote in other thread) and we can get video data but no private stream.

When we used FileReader(and passing transmitted data file as parameter) instead of "StreamReader" we implemented, we can succesfully capture video and private stream data.

Is this an error related with GetSize() returning 0 , uiAbs or anything else?