Thus, for my application, using "fread()" gives incorrect behavior while using
"read()" gives the correct behavior. You are obviously much more
cognizant of the
ramifications of this change than I am, so you may decide that the
change should
not be included in the live555 library. I ask that y
>> >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
>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
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 th
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
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
