[Bug 763026] dc1394: port to 1.X

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=763026

--- Comment #2 from Joan Pau <joanpau.beltran at socib.cat> ---
Created attachment 327650
  --> https://bugzilla.gnome.org/attachment.cgi?id=327650&action=edit
Initial patch, working well, but with some points to discuss

This is a working proposal, but includes several points which need discussion,
and, depending on the conclusions, minor changes.
The points to discuss are marked with TODO comments in the code,
and also explained in the patch description, which I copy below for reference.
I can provide another patch with the required modifications
after the discussion, and those TODO comments hopefully removed.
This is the description of the patch:

The dc1394src is a PushSrc element for IIDC cameras based on libdc1394.
The implementation from the 0.x series is deffective:
caps negotiation does not work, and some video formats
provided by the camera are not supported.

Refactor the code to port it to 1.X and enhance the support
for the full set of video options of IIDC cameras:

  - The IIDC specification includes a set of camera video modes
    (video format, frame size, and frame rates).
    They do not map perfectly to Gstreamer formats, but those that
    do not match are very rare (if used at all by any camera).
    In addition, although the specification includes a raw format,
    some cameras use mono video formats to capture in Bayer format.
    Map corresponding video modes to Gstreamer formats in capabilities,
    allowing both gray raw and Bayer video formats for mono video modes.

    Version 0.X maps DC1394_COLOR_CODING_YUV444 to IYU2 fourcc format,
    which is not defined in 1.X. Map it to Y444 format instead.

  - The specification includes scalable video modes (Format7),
    where the frame size and rate can be set to arbitrary values
    (within the limits of the camera and the bus transport).
    Allow the use of such mode, using the frame size and rate
    from the negotiatied caps, and set the camera frame rate
    adjusting the packet size as in:
   
<http://damien.douxchamps.net/ieee1394/libdc1394/faq/#How_do_I_set_the_frame_rate>

    The scalable modes also allow for a custom ROI offset.
    Support for it can be easily added later using properties.

  - Camera operation using libdc1394 is as follows:

      1. Enumerate cameras on the system and open the camera
         identified the enumeration index or by a GUID (64bit hex code).

      2. Query the video formats supported by the camera.

      3. Configure the camera for the desired video format.

      4. Setup the capture resources for the configured video format
         and start the camera transmission.

      5. Capture frames from the camera and release them when not used.

      6. Stop the camera transmission and clear the capture resources.

      7. Close the camera freeing its resources.

    Steps 2 and 3 are done when getting and setting the caps respectively.
    Ideally 4 and 6 would be done when going from PAUSED to PLAYING
    and viceversa, but since caps might not be set yet, the video mode
    is not properly configured leaving the camera in a broken state.
    Setup capture and start transmission in the set caps method,
    and consequently clear the capture and stop the transmission
    when going from PAUSED to READY (instead of PLAYING to PAUSED).

    If caps can be (re)set while in PLAYING, the capture should
    be cleared and the transmission stopped before configuring
    the new video mode and enabling the capture again.

  - Create buffers copying the bytes of the captured frames.
    Alternatively, the buffers could just wrap the bytes of the frames,
    releasing the frame in the buffer's destroy notify function,
    if all buffers were destroyed before going from PLAYING to PAUSED.

  - No timestamp nor offset is set when creating buffers.
    Timestamping is delegated to the parent class BaseSrc,
    setting `gst_base_src_set_live` TRUE, `gst_base_src_set_format`
    with GST_FORMAT_TIME and `gst_base_src_set_do_timestamp`.
    Captured frames have a timestamp field with the system time
    at the completion of the transmission of the frame,
    but it is not sure that this comes from a monotonic clock,
    and it seems to be left NULL in Windows.

  - (Ab)use `GST_ELEMENT_ERROR` and `GST_ELEMENT_WARNING`
    until it is clear where they should be replaced by
    `GST_OBJECT_ERROR` and `GST_OBJECT_WARNING`.

  - Select the camera with a camera number property as in version 0.X,
    although it would be better to use GUID and unit properties
    (they uniquely identify the device, while the number depends on
    the set of cameras currently detected by the system).
    The GUID is 64bit identifier (same as MAC address), and could be
    handled either with an unsigned 64 bit integer type property
    or with a string property with the hexadecimal representation
    of the value. For practicality a default value should be used
    such that if the property is not set the first camera enumerated
    by the library is used. Such a default value could be the
    empty string `""` or the value `0xffffffffffffffff`
    (which is not a valid value for a GUID).
    The unit is a signed integer not commonly used, and the wildcard
    value -1 can be used to match any camera (with matching GUID).

  - Keep name `GstDc1394` and prefix `gst_dc1394` as in version 0.X,
    although `GstDC1394Src` and `gst_dc1394_src` are more descriptive.

  - Adjust build files to reenable the compilation of the plugin.

    Remove dc1394 from the list of unported plugins in configure.ac.

    Add the missing flags and libraries to Makefile.
    Use `$()` for variable substitution, as many plugins do,
    although other plugins use `@@` instead.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.