[Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer

[Ross Finlayson]

>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

You should instead be setting the "preferredFrameSize" parameter to 
"ByteStreamFileSource::createNew()".  See, for example, line 144 of 
"testProgs/testMPEG2TransportStreamer.cpp", or line 199 of 
"liveMedia/MPEG2TransportFileServerMediaSubsession.cpp".  If you set 
the "preferredFrameSize" parameter to 1316, then your 
"ByteStreamFileSource" will deliver that many bytes.


>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.

Hmm, reads from the input file (in this case, a pipe) are supposed to 
be non-blocking, returning only as many bytes as are currently 
available (which will always be >0, because the read is happening 
only in response to a return from "select()" on the input file's 
socket).  Perhaps there's some way you can configure your pipe to 
ensure that reads from it don't block?
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/