Would a larger MTU likely help?
No, this is a bad idea (and won't solve your problem anyway, if your
input source is really generating data too fast). If the MTU is too
large, you'll get IP-level fragmentation, increasing the chances of
unrecoverable packet loss.
Our "MPEG2TransportStreamF
> $ sudo ./testMPEG2TransportStreamer /dev/video2
>
> I still get data loss after a few minutes with direct read, but that
> may be a problem with the device module.
I now see that overflow occurs in the encoder device module (zero free buffers).
I see in ByteStreamFileSource.cpp that "fPreferr
On Tue, Mar 31, 2009 at 2:10 PM, Gordon Smith
wrote:
>
> Hello -
>
> After modification for input of filename, testMPEG2TransportStreamer
> can read from pipe, but not read directly from device file.
> The fread() in ByteStreamFileSource returns EIO and reads zero bytes
> for direct read.
>
> Devi
Hello -
After modification for input of filename, testMPEG2TransportStreamer
can read from pipe, but not read directly from device file.
The fread() in ByteStreamFileSource returns EIO and reads zero bytes
for direct read.
Device file /dev/video2 is saa7134-empress device on Linux debian
2.6.26-1
