h264 in mp2ts in rtp - cant get splitter/decoder init on running stream

[Intel_C_Intel]

Greetings,

I am trying to get h264 streaming working using mp2ts as container and rtp as network protocoll.
It works with VLC as server if the client is already running (listening) before the stream is started. If the stream is already running I get the splitter initialitzed (UMC_OK, track = h264) but the video_info required for the decoder setup provides only incorrect (unset) information (width=0,height=0 etc.)
No matter how much further data is read from the stream the splitter never seems to get hold of any valid information.
I am mainly using code fragments from the simple player example (CodecPipeline).

My code works already using mpeg2 video instead of h264 so I believe my init procedure is somewhat ok.
Also loading the mp2ts/h264 stream from file succeeds. File loading shows the above mentioned splitter init problem if the start section is truncated. (Note: the first frame in the file is an I-frame)

My questions at this moment are:

1. Is there anybody who has succeeded using a similar setup?

2. Are there specific requirements for the h264 video stream to enable the splitter to locate required information from the running stream (SPS/PPS etc.)?
(my test video is using primarily P-frames with an I-frame every 10 seconds / other mp2ts packed h264 videos with higher I-frame rates dont work either - with VLC as server - or own UMC/Rtp server app.)

3. Is it possible to get some information from the splitter about what went wrong with the initialization?


Any helpful comments are appreciated since I have no more ideas on how to address this problem.

[Zhe_F_]

I have a similar issue with MPEG4 encoder/decoder.

The following code works fine:

While(...)

{

pEncoder->GetFrame(...);

pDecoder->GetFrame(...);

}

The first frame is I frame. I frame interval is 100 frames. No B frames, just P frames between I frames. (Defaults in the mpeg4.par parameter file in the sample code.)

However, if the decoder starts decoding using the second frame (the first P frame), it could not decode. The decoder will try to initialize itself using the following frames with an error message of "Error: Can't find Visual Object or Video Object start codes or short_video_start_marker ". Even the 100th frame, the next I frame could not save it either.

I suspect the issue I have with MEPG4 is similar to the issue you have with H263...

Please help.

[rob_otter]

Hi,

I think the problem lies in some required information for the decoder that is only located at certain places in the file/stream. For file access it is no problem if this info (in case of h264 its PPS/SPS) is stored at the start or end of file. But for streaming - with the possibility of accessing an already running stream, like joining a live video conference - this information must (I believe) be available at regular intervalls from the stream. So you will have to encode your video stream this way.
We just did that and ... well it works somehow. I am now able to get on a running stream in about 5% of the attempts. In the other 95% the splitter just parses through the incoming data and never finds anything but that it is dealing with an mp2 transport stream containing an h264 file.

What helped me was to parse the incoming rtp payload data for the 0 0 1 byte sequence indicating an h264 header. The following 3-4 bytes then tell what data is next. The streams that did not work at all contained the decoder setup info (SPS/PPS) only once at the beginning.
The video we encoded now contains this data along with every I-Frame so that accessing an already running stream seems possible.

Possibly the same (or perhaps some better) strategy may help in your case. I find it still difficult to find out the source of problems when working with video streaming. It can be my own code (mostly), the video stream, the umc-classes or even a slow computer unable to sync into a high def h264 stream.

Hope that helps a bit,

Regards