Extracting H.264 from GenericByteData

MIP
, ,
1

Using Protocol Integration, I’m trying to display a H.264 stream from a camera.

Until now, I’m able to read the GenericByteData header and recognize the Codec. Then I’m trying to store the body of the packets (i.e. the packet without the header) in a file and let ffprobe analyze it.

ffprobe recognizes that it is a H.264 stream but it looks like it’s missing information to correctly decode and display it

avprobe version v11.7, Copyright (c) 2007-2016 the Libav developers
  built on Jun  1 2016 09:59:57 with gcc 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9)
[h264 @ 0072dca0] Estimating duration from bitrate, this may be inaccurate
Input #0, h264, from '.\TESTFILE.H264':
  Duration: N/A, bitrate: N/A
    Stream #0.0: Video: h264 (High), yuvj420p, 640x480 [PAR 1:1 DAR 4:3], 25 fps, 25 tbn, 29.97 tbc

I presume I should rebuild the H.264 stream in a “smarter” way than just copying the bytes, maybe adding information about sync and picture timestamps, but documentation is not helping on this topic.

Any help or hint would be greatly appreciated.

2

I asked a colleague-

Well the data itself has the correct information – meaning the syncpoint information is inside the data, it “just” needs to be parsed. So the raw data is correct, I cant see what info he is missing.

I hope others will be able to give better help..

3

I tried to use avconv to parse and convert the data to another format and look for more information

Its response contains some warnings of this type:

Discarding initial frame(s) with no timestamp.

And it just skips all the frames, outputting an empty video

When I try using -r option to force avconv to use an arbitrary frame rate, I get some kind of success: a video is generated, with wrong speed of course

I get the same results with both video-stream and video-block sub-formats

Attached, one of my raw data extraction tests

4

Again a colleague for a short glanse at this post..

Well the file he has seems to be correct h264 format. But the timestamps are not necessarily in the raw data, it is an extra field that may be encoded by some manufacturers as additional user data. However it is not there always so that is why Milestone are using rtp timestamps, and if he wants a timestamp he can get it from genericbytedata header, as it is there from Milestone side.