6

I am developing a realtime video-streaming system which is composed basically by a server and several clients.

For now, let's ignore how packets are forwarded among the server and the clients, let's focus just on how the server can send a MPEGTS stream over UDP packets.

The stream is encoded in MPEGTS format.

What I'm trying to do is reading some packets (the main question is "how many?") and encapsulating them in UDP packets. The destination (a client) reads these UDP packets and then forward them to VLC, which is able to play MPEGTS network streams by reading UDP packets.

If I send only video packets, everything works fine, instead if I try to encapsulate in the same UDP packet, both some video packets and some audio packets, VLC is not able to decode and play the stream. I read somewhere that each UDP packet should contain 7 TS packets, but unfortunately even if I comply with this rule, VLC doesn't decode the stream correctly.

Here is a sample code of my program: http://pastebin.com/evMi6FkY

How should I encapsulate MPEGTS packets in UDP packets?

Thanks!

pAkY88
  • 6,262
  • 11
  • 46
  • 58
  • Note that vlc has a bug where it often will not play a udp stream if there is no `@` in the url, although the url does not have a username/password. Having said that, as no more than 8 188-byte ts packets fit into a udp packet, you cannot include more. (less is no problem). And a udp packet should start with the start of the ts packet, ie the first byte should be 0x47. Use wireshark to verify the data. – wimh Feb 17 '14 at 09:27
  • Did you solve your problem? I did video streaming with dvblast, send packets over UDP, and receive them with ffmpeg. Even set UDP packet sizes to 1316; But I get error: "PES packet size mismatch" regularly and output video is awful. – Dr.jacky Dec 14 '15 at 08:45

2 Answers2

3

Your problem is: "let's ignore how packets are forwarded among the server and the clients".

UDP requires you to deal with all of the issues of network transport including flow-control, error detection and recovery, path maximum transmit unit size, packetization, buffering, serialization, de-duplication, etc.

Even if you break your data up into packets of just the right size and send them at just the right rate, some will still be lost, duplicated, or delivered out of order. Your code must handle all of those conditions, otherwise you cannot trust that what you receive is what you sent.

In this particular case, I would guess that your packets have become too large, resulting in fragmentation and high drop rate. Generally speaking, it is best not to have more than about 1400 bytes per packet. But incorrect ordering, loss, and duplication are all possible as well and all become more likely as you try to send larger volumes of data.

Disclaimer: I work for a company that produces commercial UDP data transport software.

Seth Noble
  • 3,233
  • 19
  • 31
  • Hi Seth, thank you very much for your advice. I know I should handle several problems that always happen in a real environment. Now I'm just doing some tests in an experimental environment (a powerful local machine) in order to find a good manner to decode/encode packets and create a UDP stream. In this case, I think it's very unlikely that I'm losing packets on a local machine. This means that the problem is related to "how I can encapsulate video/audio packets in UDP packets". Any advice about that? – pAkY88 Jun 05 '12 at 08:37
  • 3
    Packets can and will be lost on the local machine if they are sent too fast, are too large, if a local firewall is running, or if the OS just feels like it. UDP is *never* reliable unless you make it reliable. For encapsulation, you will need a header to at least identify sequencing of the packets so that you can buffer and re-order them and/or detect loss. Keep the size down to no more than 1408 bytes, including your header. If different packets might contain different combinations of data, then add descriptive information to your header. Take nothing for granted. – Seth Noble Jun 05 '12 at 14:36
  • 5
    -1, your answer applies to general transfer of udp. But this question is about MPEG-TS. MPEG-TS is used in situations where communication is one-way and retransmits are not possible such as satellite communication or multicast udp. Packet loss is no big deal here. There is a simple checksum in a TS packet to detect errors. Then we can just discard data and re-sync. – wimh Feb 17 '14 at 09:33
  • So what do you suggest instead of UDP for video transferring?! If RTP, I'm doing realtime video-streaming in Android, so there is no RTP Player (I not found yet). – Dr.jacky Dec 14 '15 at 08:42
  • There are 3 broad choices for video transport: write your own TCP, write your own UDP, or use a toolkit like RTP (which usually builds on UDP). But capture and playback are separate issues from transport, if you are building from scratch. Proprietary toolkits (like QuickTime or WMP) tend to combine all three and try to force you to use their software from end-to-end. Even though they may use RTP, they do not provide APIs to get into it. Simplest approach: find an end-to-end package you can live with / afford. – Seth Noble Dec 14 '15 at 15:56
0

You can try https://github.com/KwikFlixTV/kwik-udp-send It's uses ts or FIFO files and send constant bitrate stream.

List of important features:

  • Sending ts file(s) as a ts udp stream

  • If there is no files to send, it sends null packets

  • Works with real-time process/threads priorities to provide stability of the stream

  • Works with FIFO files

  • Reading files to a cache buffer with an accumulation part to provide stability of the stream

pashamesh
  • 1
  • 2