I know this has been talked about around a thousands times on list. And I have read most of these threads but I am still getting what I think is strange behavior.
Here's what I'm trying to do:
I want to intercept every frame of an h.264 30 fps stream (not variable rate, life is good) and get its frame number and timestamp. So as I understand the doc, that should be in the GstBuf.dts and GstBuf.offset fields. I was going down the pad probe route but found that the identity plugin as per the doc a much easier and better route:
So my first pipeline looked like this:
... ! omxh264enc bitrate=10000000 ! video/x-h264, stream-format=(string)byte-stream ! h264parse ... ! identity name=nvcamid0 ! muxer
Then I connected to the "handoff" signal for my callback and saw the following:
dts : offset
0 : 816445297
106961 : 839200766
130469 : 849786717
151008 : 876858645
165810 : 909811526
I don't quite understand what the offset is here? I don't see how it can be a frame number but it is increasing monotonically (but it doesn't look like a per buffer offset either). Also the offset_end is also MAXUINT64 (essentially NONE).
Another thread with a similar request as mine can be found here:
In this case, the pipeline was augmented to push h264parse into a raw-video with frame alignment. I tried that via:
... ! omxh264enc bitrate=10000000 ! video/x-h264,
stream-format=(string)byte-stream ! h264parse ... ! tee name=tp tp. ! queue ! muxer.video_0 \
tp. ! queue ! video/x-h264, stream-format=avc ! identity
name=nvcamid0
And now of course I see no callback being called and nothing gets recorded.
Anyway, can someone kindly just explain to me what the offset means above? And do I need to throw my h264parse output back into a video raw format again to get each frame number?
Again, my goal is to capture the timestamp and frame number (and soon geotag) as a separate stream to eventually write to disk as a meta file.
Thanks!
-aps
Locked
