Understanding the property "block-size" for elements "filesrc" and "filesink" w.r.t device files in Linux

[James Cameron]

G'day,

Offhand, I don't know, but I know how to find out;

1.  read the source code for the filesink and filesrc elements, and
perhaps step through it with a debugger, taking particular note of
what system libraries are used for opening and writing to the file, as
these may add their own buffering,

2.  start the pipeline with the filesink, use lsof on a process to
determine the file descriptor that links to the device, then use
"strace -e write=33", where 33 is the file descriptor; this will give
you the buffer size that the library gives to the kernel for writing
to the device,

3.  do the same with the pipeline with the filesrc, but strace the
read syscall instead of the write syscall; this will give you the
buffer size that the library gives to the kernel for reading from the
device,

4.  see if the above two buffer sizes can be changed using the
"blocksize", "buffer-size" or "buffer-mode" properties.

Without looking at these myself, my gut feel (hypotheses) is that;

a.  the "blocksize" property on the filesink sets the size in bytes
for each buffer read from the pipeline, and will not affect writes to
the device file,

b.  the "buffer-size" property on the filesink sets the size in bytes
for write to the device file, if the "buffer-mode" property is set to
0 for fully buffered,

c.  the "blocksize" property on the filesrc sets the size in bytes for
each buffer read from the device file.

d.  increasing blocksize or buffer-size would most likely eventually
increase latency, because there will be more time between each buffer
delivery, and so the stream would take longer to start.

e.  therefore filesink and filesrc elements are best used with disk
files, not serial device files,

Let me know if you are able to falsify any of my hypotheses.

On Fri, Sep 07, 2018 at 07:50:45AM -0500, vk_gst wrote:
> Hello again GStreamer experts,
> 
> I am trying to understand the behaviour of property "block-size" for doing
> read/write operations on device files. I am using a FTDI chip USB-USB null
> modem cable ( link
> <http://www.ftdichip.com/Support/Documents/DataSheets/Cables/DS_USBNMC.pdf> 
> ) to stream real time video from client to source.  The ports are exposed as
> serial ports '/dev/ttyUSBx' on Linux system.  Now the whole setup works with
> reasonable latency of < 1 second when configured to work at 1MBaud and 2
> MBaud , with a blocksize of 4K. 
> 
> I tested the setup with a block size of 4K*4 = 16384 at both client &
> source. With the increase in blocksize, I did not see any improvement in the
> latency. I understand the latency depends on various other factors like the
> camera fps, the encoding/decoding etc. But here I am trying to understand if
> the larger block.size can help in speeding up the streaming. Also, when
> there is a change in the property block-size  for element, does it always
> affect the Tx/Rx buffer for the device file.  If not, how can they be
> configured? 
> 
> When it comes to the same setup using UDP, I see that the video streaming
> latency is far less and less noticeable. In case the block-size for serial
> ports is configured to same as UDP block size, will this help in speeding up
> the streaming ?
> 
> Can anyone explain the effects of block-size property in case of device
> files in Linux? 
> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 
James Cameron
http://quozl.netrek.org/