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

[sk_gst]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[sk_gst]

Hallo again James,

I followed up your suggestions and have partial progress towards the steps
you mentioned. Please be prepared to read a long  observation list. :)

1. Reading through the source code of elements 'filesink' and 'filesrc', I
see the following :
1.a.  filesink open is a normal 'open' system call, with no specific changes
for regular files or device files. The write operation first goes through
all the buffers and then writes it using the `write` system call to the file
descriptor. The mode of writing is binary.

1.b. filesrc - again 'open' and 'read' system calls. Open is performed in
read only and binary. First a 'fstat' is performed on the file to check if
its a regular file(for all other file types, the code emits an error, also
confusing for me as to device file is also considered as a regular file
here). Appropriate 'seek' is done for regular file and ignored for special
files.

I do not see any usage of blocksize in the source code for filesink and
filesrc elements. I guess its being abstracted at some other level in the
GNOME system.

2. My server is an imx6 device(running debian) and it transmits video over
the serial port to the PC running Ubuntu. I ran strace over filesink for the
initial test and the results are in the attached files. I performed the
testing with block sizes configured to 4096 and 16384. However I do not
observe any changes in the strace output.

Also the command for strace you mentioned did not work on imx6. I managed to
use the following command :
strace write[/dev/ttyUSB0]  and the trace is attached in files.

For the commands you mentioned, following are the outputs:
root@stretch-dev:/home/debian# strace -e write=5
strace: must have PROG [ARGS] or -p PID
Try 'strace -h' for more information.

Also the following commands produced the same error:
strace -e trace=write
strace -e trace=desc




I still need to perform it on filesrc, but I stopped since I do not see any
differences in the attached file, or may be I am interpreting it wrongly.
Have a look and let me know what you think about it.

I look forward for your suggestions/ideas.


filesink_blk_size_4096.filesink_blk_size_4096
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/filesink_blk_size_4096.filesink_blk_size_4096>  

filesink_blk_size_16384.filesink_blk_size_16384
<http://gstreamer-devel.966125.n4.nabble.com/file/t378365/filesink_blk_size_16384.filesink_blk_size_16384>  



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[James Cameron]

1.  in your reading of the source code for filesink and filesrc;

(a) what is the count of bytes for write(2)?

(b) what is the count of bytes for read(2)?

(c) is the return ssize_t from read(2) used?

(c) does the open(2) use a flags containing O_NONBLOCK?

Yes, in the semantics of fstat(2), a device file is a regular file; it
is not a pipe or a symlink.  A seek(2) on a serial port device file is
a null operation.

You say no usage of blocksize, but what of buffer-size?  My guess is
that blocksize is used by parent class functions which call the filesrc
and filesink functions, and controls the count of bytes for read(2) or
write(2).

2.  using strace

You've not used strace(1) correctly.  Use it in front of the
gst-launch or application program.  Add -f option to trace child
processes.

Also, another idea from previous mail in last few months; how bursty
is the serial data stream; that is if you hook an oscilloscope to the
serial wires, what proportion of time is the signal idle?

--
James Cameron
http://quozl.netrek.org/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel