I'm trying to decode a stream coming from a ip camera, the stream is encoded in h264.
My application already decodes h264 stream coming from a media sdk enconder and from a ffmpeg encoder.
It works pretty well using low latency settings, but now I'm receiving a stream from that camera by RTP stream. Just take of the RTP header and passing the payload to my Intel decode lib doesn't work, the MFXVideoDecode::DecodeHeader function found the parameters correctly and allows me to start the decode, and it appears to work too but gives me just frames with garbage.
The camera RTP stream doesn't follow the RFC3984 (http://www.ietf.org/rfc/rfc3984.txt) that suppose to specifies the RTP stream format for h264.
So, currently I'm trying to look into the stream and take the NALUs one by one, by identifying the start sequence bytes (0x00 0x00 0x00 0x01), and passing than one by one to the decode lib. It still doesn't work but, before keep trying, I need to know how should I pass the NALU to the decoder, should I cut off the start sequence? The first byte that identifies the NALU type? Keep just the last number (0x01)? I've found some divergent information while I was researching so I came here to ask.
That information is essential but any other tip would be great
There are two ways by which you can receive H264 data over RTP:
1. Data in fragmented unit (FU)
2. Data in non-fragmented unit.
Can you please tell me whether you are getting your data in fragmented unit or in non-fragmented unit?
To find it just check first 4 bytes of your data after removing RTP header. If it is 00 00 00 01 then data is in non-fragmented unit otherwise it is in fragmented unit.
You are totally right about the way h264 data over RTP is supposed to be, but as I said, this ip camera I'm working with just doesn't do it this way, it puts the stream in RTP's payload as it would be in a .264 file.
I have come to this by looking into a .264 file, and it answered my question, so the DecodeFrameAsync function needs the entire start sequence 00 00 00 01 or 00 00 01.
My problem appears to be in my decode solution, which probably don't cover something.
thanks for the answer