[Live-devel] Possible bugs in ByteStreamFileSource and MPEG2TransportStreamFramer

[Ross Finlayson]

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

I'm not convinced that any such distinction between the behavior of 
"fread()" and "read()" is portable across OSs.  (For example, on 
FreeBSD, the man page for "fread()" doesn't mention blocking at all.)

A better solution is to add the following code to the 
"ByteStreamFileSource" constructor (which is currently empty):

#ifndef READ_FROM_FILES_SYNCHRONOUSLY
	makeSocketNonBlocking(fileno(fFid));
#endif

and continue to implement "doReadFromFile()" using "fread()" rather 
than "read()".

Please let us know if that works OK for you.  If so, I'll make this 
change in the next release of the software.
-- 

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