0

I am working on live streaming project. We are getting UDP packets which we need to receive & then pass it to decoder , get it back from decoder & then pass it back over multicast IP.

We have implemented logic to receive raw UDP packets ( size: 1316) & pass it to decoder but it requires input in higher size ( 16K ) so we have used PipedInputStream & PipedOutputStream to get required size.

We have implemented logic to put 1316 size packets into PipedOutputStream & reading 16K from PipedInputStream & passing it into device for decoding. Once data is received from device, again making use of PipedInputStream & PipedOutputStream to convert 16K to 1316 size but when applied multi threading then looks like data is getting missed.

Is there any library which can provide same functionality ?

user161607
  • 21
  • 3
  • So you're combining multiple UDP packets into 16K chunks? Why not just have a 16K buffer into which you copy data, rather than messing around with pipes? As for "multithreading... data missed" is sounds like you have synchronization issues. Though you know of course that UDP delivery is not guaranteed? – J.Backus Aug 29 '20 at 16:28
  • @J.Backus, To be able to copy data into 16K buffer, I will have to make use of FIFO queue & then copy multiple 1316 size packets into buffer but that will not result into exact required size. Actually I need 16384 as input so I will have to write logic to handle remaining data as well. – user161607 Aug 29 '20 at 16:35
  • I am copying data of size 1316 into pipe & then taking 16384 size data from pipe & writing it into device but somehow when I am using pipe in multi threading, it looks like data is not in order in which it was written – user161607 Aug 29 '20 at 16:37
  • Do you have multiple threads receiving UDP packets and feeding into one pipe? – J.Backus Aug 29 '20 at 17:03
  • One thread is there which is receiving data over UDP & at the same time , it is putting it into queue. Another thread is there which is reading data from pipe & writing it into device. – user161607 Aug 29 '20 at 17:27
  • Then there seems to be no chance of the receiving thread putting things in the pipe other than in the order that it receives them. I suspect your problem must be elsewhere. – J.Backus Aug 29 '20 at 17:42
  • @J.Backus, Thanks for your input. I am writing test code to identify where lies the problem. – user161607 Aug 29 '20 at 18:16
  • @J.Backus, I have identified that my input stream pipe is getting full as data with which UDP packets are received is very high & consumer is consuming it very slow means this is related to fast producer slow consumer. Any idea as how to handle it? – user161607 Aug 31 '20 at 16:42
  • The 'U' in 'UDP' is 'unreliable', which means that there are no delivery guarantees, no ordering guarantees, no flow control, unless provided. So the first question is, why using UDP rather than TCP? If you have to use UDP, then you need to implement some system of acknowledgement so that the sender can know if his message was received (and you have to cope with the acknowledgement getting lost, which can lead to duplicate sends) – J.Backus Aug 31 '20 at 23:16
  • @J.Backus, I am working on IPTV solution so mpeg ts packets are received in UDP only & we don't have option to implement some system lof acknowledgement. I have found one solution to deal with queue getting full very fast. Ashes queue is what I found but don't think that it will work. – user161607 Sep 01 '20 at 16:06

0 Answers0