I'm experiencing an issue where keyframes do not appear (or are not marked correctly) in a gstreamer h264 stream encoded using vpuenc.
There are two reasons for this claim:
- After capturing the h264 to disk using filesink, I dump the frame data using ffprobe. If the h264 stream is recorded directly to disk, key_frame=1 appears for the very first frame but then never again (all other frames marked key_frame=0). When captured from the network via UDP, there is never a key_frame=1, most likely because the initial keyframe was missed.
- On the consumer side, I inspect incoming gstreamer video buffers, looking for keyframes using the condition GST_BUFFER_FLAG_IS_SET(buffer, GST_BUFFER_FLAG_DELTA_UNIT) == FALSE. This condition is never satisfied.
GStreamer producer pipeline:
videotestsrc is-live=1 horizontal-speed=1 ! video/x-raw-yuv, width=640, height=480, framerate=30/1, pixel-aspect-ratio=1/1 ! vpuenc codec=6 force-framerate=true seqheader-method=3 bitrate=524288 ! video/x-h264, format=byte-stream ! rtph264pay pt=96 ! udpsink host=192.168.3.120 port=5010
GStreamer consumer pipeline:
udpsrc port=5010 ! application/x-rtp, media=video, clock-rate=90000, encoding-name=H264, payload=96 ! rtph264depay ! h264parse ! filesink location=vpuenc-sample.h264
gst-inspect-0.10 version 0.10.35
wrapper: 1.0.35(VPUWRAPPER_ARM_LINUX Build on Dec 20 2013 15:09:05)
I do not have this issue when encoding with x264enc instead of vpuenc. Is it possible to get vpuenc to correctly generate/mark periodic keyframes?
Attached are ffprobe frame dumps for recorded streams encoded with vpuenc and x264enc. Notice the key_frame=1 appearing throughout the x264enc dump.
Original Attachment has been moved to: x264enc.h264.frames.txt.zip
Original Attachment has been moved to: vpuenc.h264.frames.txt.zip