videoCapture() for an UDP stream not working

I received RTP packets from an IP camera (RTSP protocol) and send the packets through UDP, and trying to use cv2.videoCapture() to open that UDP url, nothing shows up.

Have you confirmed you can open the UDP URL with ffmpeg or VLC? Why don’t you use the rtsp URL directly?

The rtsp URL works fine, but what I was trying to show in on a remote server which I have to use UDP to transmit the packets first to that server. So do I have to decode it the packets first to view it?

how do you do that, exactly ?

through a few communication devices, the problem I’m having right now is how exactly to decode these RTP packest into playable h264 stream.

Can you give more details, it’s not clear at all what you are doing. You have an rtsp stream over TCP or UDP which you receive on one device then

  1. Do you forward that stream via rstp?
  2. Somehow unpack the stream and send as raw UDP packets containing the h264 nal units without any streaming protocol?
  3. Decode on one box and then forward the decoded frames via UDP?
  4. Something else?

And why can’t you directly receive an rtsp stream on the end device, is it a low power device which cannot handle the decoding?

1 Like

Here is the link I am trying to work on: RTSP camera → PC1 → communication device 1 → communication device 2 → PC2 → Localhost. I forward the stream using UDP, but from camera to PC1 the protocol is TCP. I would like to view the stream on localhost, and I am able to receive packets at PC2 and forward them to localhost, but when I try to use videoCapture() at localhost using an UDP url, somehow the video doesn’t come up. I was trying to unpack the stream and send raw UDP packets, but the stream doesn’t show up on the other end as it should.

If I understand correctly you have an rtsp stream which uses tcp. You are unpacking the stream and just extracting the raw nal units then repackaging them and sending them via raw udp without a communication protocol and hoping VideoCapture will know how to read and decode them. Is that correct?

Can VLC or FFmpeg read the raw UDP stream from the localhost url? If your only requirement is udp why can’t you stream from the ip camera via udp directly, I’m pretty sure that would be the default transport protocol?

1 Like

Yeah mostly correct, I basically had whatever I received form RTSP camera and did not do any extraction (do I need to?) and send them through the link.
I tried using VLC and it does not work at all, actually I even tried on PC1, trying to stream the packets I received from the camera (without any processing to the data packets), and it does not work. I am just confused with what kind of extraction do I need to do in order for the stream to work on the other end (PC2 localhost), or should I just let the code handle everything including the decoding part of the RTP packets. That’s where I’m stuck on right now. I’m not sure if I need to manually process the RTP packets or I can let the code handle everything itself.
The reason I don’t directly stream from the ip camera via udp is because my ultimate goal is to ensure the link is working rather than simply stream it.

Before trying anything else I would confirm you can play the stream from the RTSP camera using vlc or ffplay. What does the rtsp url look like?

Previously you said

which seems to contradict this, do you mean VideoCapture works but vlc does not?

How are you streaming via udp, what does the code look like or what application are you using? Are you simply trying to change the transport protocol from tcp to udp? What does the udp url look like which you are trying to use on PC2. If you can’t play that with vlc it is highly unlikely you will be able to play it with VideoCapture.

Why can’t you do that check on PC2?

I will go do that for sure, what I did was I was trying to save the raw RTP packets as H264 file to play it on VLC, and that apparently failed, I think for it to be playable, I need to decode the packets first somehow and that’s the part where I am not too sure aboue.

It basically looks like “rtsp://{username}{password}@{ip address}{port}/LiveMedia/ch1…”

I haven’t tries to stream or VLC, but for ffmpeg I did try to use the python library and some bugs kept coming up, the system is Ubuntu 18.04. Yeah, videoCapture() worked and I haven’t tried the other two methods, I’ll look into it right away.

I am using python for receving (TCP) and forwarding (UDP), and I am trying to decode the RTP packets to make it playable on any platforms, whether it’s cv2, ffmpeg, VLC or Gstreamer, and so far failed to do so. The UDP url looks like “udp://{ip address}{port}”

I can receive the packets on PC2, but when forwarding to localhost (, stream failed to show up as intended. That’s where I’ve been stucking on for days.

You should be able to play this directly in vlc Media->Open Network Stream.

Can you share the code or api calls which do this?

I don’t understand, by decode do you mean extract the raw nal units from the RTP packet. If so why, OpenCV, FFmpeg, vlc and gstreamer handle rtsp/rtp already?

Can you play this using vlc/ffplay etc?

Are you saying that you can recieve the rtsp stream on PC2 directly but you are unable to forward the stream to localhost and that is the reason for all the processing? If so why do you need to forward to localhost and can’t you use the routing tables on PC2 to forward the “ip address” packets to “localhost” so you can directly call


If you can’t play the udp stream using vlc/ffplay this is not an issue with VideoCapture().

it’s been requested multiple times. please do it.

and forget any python “libraries” for ffmpeg. those are subprocess wrappers. the only proper ffmpeg library for python I know of is “PyAV”.

we can’t help you if you can’t present your code.

we also can’t help if you’re doing something unreasonable (like “decoding” a perfectly usable video stream and trying to throw uncompressed data across a network through unreliable channels such as UDP), but that’s impossible to tell without the code. always remember, this forum is for OpenCV, i.e. computer vision, not for video transport over networks. if that’s your issue, you need to talk to people affiliated with ffmpeg, VLC, gstreamer, …

UDP is not guaranteed to arrive. you are losing data.

any further talking is pointless. when people have trouble programming, it’s always a difference between the individual’s understanding of reality, and reality (the code). as long as you merely talk, you prevent yourself from getting help at all because we can’t determine where your perception differs from reality.