[Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer

[Wiser, Tyson]

Ross,

Thanks for the reply.  Please see my comments inline below.

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

Thanks for pointing this out.  I should have notice this but didn't.
This is a much better solution.

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

I agree that, since a select call was made, we are guaranteed that there
is at least one byte available for reading.  I think the problem lies in
the fread() function.  From the Linux man page and other online documentation
I get the impression that fread() will block until the requested amount of
data has been read, there is an error, or EOF is reached.  On the other
hand, the read() function is not blocking and returns the requested amount
of data or less if the requested amount is not currently available.