Trying to stream a webcam through rtp with a raspberry pi.

Cating the SDP file on my desktop, and launching ffplay:

ffplay sdp.out

then streaming out this way:

ffmpeg -i /dev/video0 -c:v h264_omx -f rtp rtp://

works perfectly. But If I launch ffmpeg first THEN ffplay, ffplay stutters some error message about missing PPS and never displays any frame:

[h264 @ 0x7fd97c0008c0] decode_slice_header error
[h264 @ 0x7fd97c0008c0] no frame!
[h264 @ 0x7fd97c0008c0] non-existing PPS 0 referenced

After looking for a while I understand some intermediary frame might be missing. However, using the -g option this way does not change anything:

ffmpeg -i /dev/video0 -c:v h264_omx -g 30 -f rtp rtp://

It is a problem for me because I am using the raspberry as a securiy camera. My desktop can be restarted from time to time and I need ffplay to be able to catch after the streaming is started.

Any help is appreciated.

  • Rather than a intermediary frame being missing, it's about head frames. When ffplay starts, if the first frame it receives is not a keyframe, then that frame needs a previous (missing) frame to get decoded. That previous frame may be a I-frame not queued to be ever shown or a P frame referred to by a B-frame and would have been shown after the B-frame had it been received.
    – Gyan
    Commented Mar 3, 2017 at 8:57
  • I'm confused. Does it mean there is no solution to this problem (it's the way rdp works, the listener has to be started and then the flow started) or there would be a way to regularly insert a keyframe for the listener to be able to catch the stream in the middle. Commented Mar 3, 2017 at 9:04
  • Does the stream not become smooth after a few seconds?
    – Gyan
    Commented Mar 3, 2017 at 9:08
  • No, ffplay keeps outputing error message for ever. It is never able to display any frame. Commented Mar 3, 2017 at 9:09
  • Does replacing -g 30 with -force_key_frames "expr:gte(t,n_forced)" work?
    – Gyan
    Commented Mar 3, 2017 at 9:35

2 Answers 2


It turns out it is impossible to live stream with the RPi hardware acceleration using ffmpeg. For ffmpeg to configure the hardware acceleration to issue SPS/PPS frames during the stream and not only at the beginning of it, it needs to use a specific API of the raspberry firmware which it does not at the moment.

Raspivid and gstreamer does that though. So turn to thoses solution and forget about ffmpeg.

  • If this is the issue, then you may be able to stream the omx encode to a pipe in mpegts format and then use a 2nd ffmpeg instance to pipe to rtp. The MPEG-TS muxer will insert xPS in-band.
    – Gyan
    Commented Apr 21, 2017 at 17:45

Here my FFmpeg patch to enable inline header on OMX hardware encoder.

libavcodec/omx.c OMX_SetParameter(s->handle, OMX_IndexParamBrcmVideoAVCInlineHeaderEnable, &vid_param_inline_header); where vid_param_inline_header is a OMX_CONFIG_PORTBOOLEANTYPE struct.


  • Consider submitting a patch to ffmpeg-devel but make it an option instead of hardcoded.
    – Gyan
    Commented Dec 10, 2019 at 18:35
  • Yes but there is a last problem:( only when I enable OMX InlineHeader the latency grow over the time.There is a strange time calculation problem inside the muxer. I get a lot of "application provided invalid, non monotonically increasing dts to muxer in stream xxxx/0" and it always freeze at 3335. Commented Dec 10, 2019 at 21:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.