[Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer

[Wiser, Tyson]

I am using the live555 library in a Linux application that receives a low frame rate MPEG2-TS from a live source one frame at a time.  The source is not represented as a file by the OS.  To make the interface to the live555 library easier, I opened a pipe and write each frame to it as I receive them.  The read end of the pipe is given as the source to a ByteStreamFileSource instance which then feeds an instance of MPEG2TransportStreamFramer, which in turn feeds a BasicUDPSink (unfortunately my requirements do not allow me to use RTP/RTCP, which I would have preferred).  This seems to work fairly well with the following exceptions.


1.       BasicUDPSink has a default packet size of 1450.  MPEG2TransportStreamFramer asks its source (ByteStreamFileSource in this case) for 1450 bytes and then, in afterGettingFrame1, correctly limits the actual packet size to 1316 (7 188-byte TS packets).  However, it seems to discard the remaining 134 bytes (or less if less than 1450 bytes were read), which causes sync problems on almost every packet after that and wreaks havoc on the receiving end of the stream.  If I change the default packet size in BasicUDPSink to 1316, these problems go away.  This discarding of data seems like a bug to me, but I may just be using it incorrectly.

2.       Since data is given to me and thus written to the pipe frame-by-frame, it is very common that a single write to the pipe will not be a multiple of 7 188-byte TS packets (e.g. a frame might be 25192 bytes = 134 188-byte TS packets = 19 UDP packets containing 7 TS packets each + 1 UDP packet containing 1 TS packet).  While the MPEG2-TS source continues to produce frames this does not cause any problems.  However, when the source is paused/stopped it can cause the event loop to hang indefinitely.  This is due to the fact that ByteStreamFileSource::doReadFromFile is trying to read more data than it can receive and thus blocks in the "fFrameSize = fread(fTo, 1, fMaxSize, fFid);" line.  A fix that worked for me was to replace that line with "fFrameSize = read(fileno(fFid), fTo, fMaxSize);".  Since I am only working in Linux, this fix may not be cross-platform without some massaging.  Again, I consider this a bug because it doesn't behave the way I think it should, but you may never have intended ByteStreamFileSource to be used with a pipe as a source.

Thanks for the great work on this library.

Tyson Wiser

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110531/350c2c8f/attachment-0001.html>