AW: AW: AW: Serial port interface on frame grabber

[James Cameron]

G'day vk_gst,

Your test over 19200 baud wire link may have been affected by the data
exceeding the bitrate limits at the filesink imposed by max-bitrate
and the serial port.  This would cause blocks of data to be dropped,
and the decoder would hesitate.

To test for this, run the pipeline for a minute to a file, and then
measure the size, and calculate the average bitrate demand.  e.g.

timeout --signal=SIGINT 60s \
    gst-launch-1.0 -ev videotestsrc pattern=18 ! \
    video/x-raw,width=100,height=50 ! \
    imxvpuenc_h264 bitrate=5 ! h264parse ! \
    filesink location=60s.h264 && \
        echo $(( $(stat --format=%s 60s.h264) / 60 * 8))

Your test at 19200 baud will also suffer from serial transmission
latency; 1024 bytes with a start and stop bit each will take 10240 bit
times, which is 533 ms.  You'll only need ten blocks buffered to hit
the five seconds you observed.

You may try to find the number of blocks per frame.  You might do that
by adding a videorate element after the videotestsrc, and varying the
max-rate while measuring the average bitrate demand as above.

At this stage, I doubt a receive side buffer will help, because I'm
fairly sure the data doesn't fit into the available bandwidth.  But if
you want to try, use a queue element without the default properties,
as the default is minimal compared to your transmission rate.

I'm curious as to whether the filesink property buffer-mode may make a
difference for you.  Also look at buffer-size, defaults to 65536,
which could be enough buffering to give you that five seconds.

You may find it useful to read the GStreamer source for the filesink
element.

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