If config-file is set to the filepath of a XML file, such as is
generated by eBUS Player, it will be used to restore configuration
to the device and stream. By default, the device and stream will be
connected using the information from the config-file. Set
config-file-connect=false to connect to the camera using other element
properties, and then apply the configuration changes from the
config-file.
This also needed a change to calculating the strides, as IYU1 is 12bpp,
and GstVideoInfo defines pixel stride in bytes, so for IYU2 the stride
was calculated as zero. Instead use Pleora's own definition of pixel
stride to calculate Pleora's row stride.
Previously only one camera per physical capture card could be opened.
Multiple cameras per card can now be captured, however they must both
still be in the same process. There is no IPC implemented yet.
Some newer version of GStreamer requires the plugin name used in
GST_PLUGIN_DEFINE to match the name of the compiled module, excluding
libgst and the extension.
For example, a Mono8 642x482 would have failed to work, as GStreamer
expects the stride to be a multiple of 4-bytes, that is 644 bytes in
this example, while Pleora doesn't do this alignment. This incurs a copy
unfortunately, and there might be a way with memory meta to avoid this,
however eventually most elements will need to have the data 4-byte
aligned.
The IMPERX SDI cards support BGR, YUY2, and a unique 10-bit YUV 4:2:2
format which is not currently supported in GStreamer. For now, we'll
unpack it to AYUV64.
This has only been tested on a ExpressCard device, but is expected to
work with all IMPERX grabbers that use this SDK.
Special attention has not been given yet to timestamping or accounting
for dropped frames.
Currently if the source is interlaced this element will deinterlace.
Another mode could be supported to push out the frames as is, with
appropriate caps to indicate interlacing mode.
Previous way of creating caps left invalid colorimetry field 0:0:0:0,
which combined with a bug present in GStreamer 1.8 led to GRAY16_LE data
being corrupted when converted to GRAY16_BE (or vice versa). Current
method will properly initialize colorimetry field, avoiding this problem
in 1.8.
