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

[James Cameron]

G'day vk_gst,

You asked for speculation on why you saw average bitrate demand that
was the inverse of resolution, instead of proportional to the size of
the frames.

I've never written one; but encoders work in mysterious ways.  One way
may be to divide the frame into squares and encode each square.  The
algorithm may have a preferred size for these squares, and may use
only part of a square when the video dimensions are unusual for the
algorithm.  Other encoders use macroblocks; and the same kind of
non-linearities may occur.

Try different encoders to see if there is one better suited to your
limited bandwidth and latency requirements.

Be sure you restricted the framerate during the average bitrate demand
tests; otherwise you may be encoding smaller resolutions at a faster
framerate.  That would give those kind of results.  I've not recently
tested, but the videotestsrc element may offer a higher framerate for
lower resolutions.  Add -v to your gst-launch to find out what was
negotiated.

My main reason for asking for the average bitrate demand was to ensure
it would fit within the serial link bandwidth you have available.  At
115200 baud, only one of the resolutions you tested would not fit,
possibly giving you latency from a queue outside GStreamer.

Moving to a C program should be relatively straightforward; call
gst_parse_launch, give elements names if you need to use them, and
call gst_pipeline_get_by_name to reach into them.

You might also try a Python program for fast prototyping, if that's a
language you're familiar with.

Accessing the frames from within a program takes some form of sink
element; look at appsink, or for GLib or GTK+ based programs try
gdkpixbufsink.  I've used the latter quite a bit myself, in Python.

Hope that helps.

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