2

I'm attempting to using the libav libraries with Qt to decode h.264 UDP video streams, but when I use avformat_open_file, I get the following error message: 

[udp @ 0x102b5bee0] Part of datagram lost due to insufficient buffer size

The message appears about 10 times and then the attempt fails. I'm trying to decode 4 different UDP streams simultaneously, each stream with a frame rate of 25fps. Wireshark indicates that the packets are between 3000 and 10000 bytes.

Here is my call to avformat_open_input:

avformat_open_input(&formatContext, udpUrl.toStdString().c_str(), NULL, NULL)

formatContext is NULL at the time that this call is made, and udpUrl is in the format "udp://ipaddress:port".

If someone could shed some light on this issue for me it would be greatly appreciated!

Colin Ray
  • 165
  • 2
  • 14

3 Answers3

1

That error happens when you try to read a UDP datagram into a buffer that is too small. Since UDP does not guarantee delivery, this packet simply gets truncated (or dropped) depending on the implementation.

From a quick look at the documentation, it looks like you can specify the datagram size as an option on your URL (See section 6.16 UDP).

Try changing your URL to something like: udp://ipaddress:port?buffer_size=10240

Chad
  • 18,706
  • 4
  • 46
  • 63
  • Thanks for pointing me towards the documentation. That helped a lot. Still, I tried several different values for the buffer_size and nothing changed. Setting pkt_size to about 10000 eliminates all the error messages, but I still get bad data from the UDP streams. – Colin Ray Mar 22 '12 at 22:58
1

After digging around a bit more it looks like FFMPEG expects you to first encode the stream to MPEGTS when streaming raw H.264 over UDP. Sure enough, encoding the output stream to MPEGTS did the trick.

Colin Ray
  • 165
  • 2
  • 14
  • Congrats on the fix! When you are able, please make sure to mark your answer as 'accepted' so other will see your question has been answered and be able to learn from your solution. Cheers~ – Andrew Kozak Mar 30 '12 at 16:12
  • How were you able to encode the incoming streams to MPEGTS? Is it also ffmpeg on the other end or are you using a different library? Or maybe you are using ffmpeg locally? – njahnke Sep 06 '12 at 18:28
  • Previously we were using some custom code to capture and stream the raw video data. I swapped ffmpeg in for the custom code, and had it stream over udp using the mpegts format. I ended up ditching this method entirely as the host did not have enough processing power to encode the frames at a high quality and framerate. – Colin Ray Sep 26 '12 at 14:38
  • Probably too late but this error pops up when you have an encrypted stream that FFmpeg does not know how to handle (unless it's decrypted before hitting FFmpeg). Hope this helps someone. – ipruthi Jan 28 '14 at 17:30
  • @ColinRay sorry for the late comment, but did you manage to solve this issue? – eladm26 Jan 27 '16 at 09:40
0

Make sure you set the buffer_size and pkt_size options to be big enough.

udp, as any other protocols (e.g. tcp, sctp) can deliver generic formats (so mpegts, nut, mkv) or you can use rtp and rtsp and the respectively coupled formats.

lu_zero
  • 978
  • 10
  • 14