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

[James Cameron]

G'day vk_gst,

Sorry, I was a bit terse with my explanation.

Let me put it another way.

Using a system perspective, the video source, the aircraft GStreamer
pipeline, the wireless transmission, and the ground GStreamer pipeline
together form a system.

When you can substitute alternate parts into a system, you can
discover behaviours of other parts, or test them more fully.

So far you have tested with the system in roughly the expected
arrangement of parts, and with a USB serial adapter in place of the
wireless link.  Your results of those tests show that there is
something about the wireless transmission that causes GStreamer to act
outside your expectations.

But there is always doubt; could this be something that GStreamer
could do better?  Could you configure GStreamer better?  What is
actually happening to cause the problem?

So my suggestion was to set aside the wireless transmission; just for
the purpose of testing all the other parts together.

By emulating the wireless transmission; as a GStreamer element or a
program using named pipes or pseudo-terminal devices, you can explore
the behaviour of the rest of the system under different conditions.

Imagine a program which creates two pseudo-terminal devices, then
reads bytes from one, and writes the bytes to the other.  You could
then write a GStreamer pipeline that writes to the first device, and
write another GStreamer pipeline that reads from the second device.
It should work identically to a GStreamer pipeline over UDP.

Then extend the program to track number of bytes over time, and delay
writing bytes by enough time to yield an effecitve 115200 baud
throughput.

Then extend the program still further to randomly inject the kind of
latencies that are observed on the wireless link.

Is that any clearer?

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