1. when gst_westeros_sink_soc_init() is called, the sink calls on the display function, with that to generate the first frame thread it checks if the sink is not NULL, the signal is called.
2. when the gst_westeros_sink_soc_start_video() is called, with the capture_start event, a no. of functions are called to check the condition and collect data related to buffer, plane and get frame-related data like frame rate, frame size, frame-width, frame height, under this condition: sink->soc.emitFirstFrameSignal is set to TRUE; signal is called.

1. This signal is emitted when a new texture is ready to be displayed by the video sink. Various parameters are passed based on whether the texture is multi-planar or not and sets the appropriate values for the file descriptor, length, stride, and pointer of each plane of the texture buffer.
2. It can also be emitted when westeros_sink_dispatch event comes into play and sink->soc.enableTextureSignal is called.

1. This signal can be emitted under the condition that if a set position from the frame currently is being presented by the video server
2. This signal can be emitted under another condition that if any video status message is received from the video server related to if timecode is present where the message may contain the presentation timestamp of frames being displayed, this information can help to process messages in video synchronisation or video client connection.

To set the parameters for a Video Output Overlay, applications must initialize the flags field of a struct struct v4l2_framebuffer. Since the framebuffer is implemented on the TV card all other parameters are determined by the driver. When an application calls VIDIOC_S_FBUF with a pointer to this structure, the driver prepares for the overlay and returns the framebuffer parameters as VIDIOC_G_FBUF does, or it returns an error code. 

To set the parameters for a non-destructive Video Overlay, applications must initialize the flags field, the fmt substructure, and call VIDIOC_S_FBUF. 

For a destructive Video Overlay applications must additionally provide a base address. 

This ioctl is part of the video overlay I/O method. Applications call ioctl VIDIOC_OVERLAY to start or stop the overlay. It takes a pointer to an integer which must be set to zero by the application to stop overlay, to one to start. Drivers do not support ioctl VIDIOC_STREAMON, VIDIOC_STREAMOFF or VIDIOC_STREAMOFF with V4L2_BUF_TYPE_VIDEO_OVERLAY.  

Applications call the VIDIOC_QBUF ioctl to enqueue an empty (capturing) or filled (output) buffer in the driver’s incoming queue. The semantics depend on the selected I/O method.

To enqueue a memory mapped buffer applications set the memory field to V4L2_MEMORY_MMAP. When VIDIOC_QBUF is called with a pointer to this structure the driver sets the V4L2_BUF_FLAG_MAPPED and V4L2_BUF_FLAG_QUEUED flags and clears the V4L2_BUF_FLAG_DONE flag in the flags field, or it returns an EINVAL error code.

To enqueue a user pointer buffer applications set the memory field to V4L2_MEMORY_USERPTR, the m.userptr field to the address of the buffer and length to its size. To enqueue a DMABUF buffer applications set the memory field to V4L2_MEMORY_DMABUF & m.fd field to file descriptor associated with a DMABUF buffer.

This ioctl is an extension to the memory mapping I/O method, hence it is available only for V4L2_MEMORY_MMAP buffers. To export a buffer, applications fill struct v4l2_exportbuffer. The type field is set to the same buffer type as was previously used with struct v4l2_requestbuffers type. Applications must also set the index field. Valid index numbers range from zero to the number of buffers allocated with ioctl VIDIOC_REQBUFS (struct v4l2_requestbuffers count) minus one. Additional flags may be posted in the flags field. After calling ioctl VIDIOC_EXPBUF the fd field will be set by a driver. 

Applications call the VIDIOC_DQBUF ioctl to dequeue a filled (capturing) or displayed (output) buffer from the driver’s outgoing queue. They just set the type, memory and reserved fields of a struct v4l2_buffer as above, when VIDIOC_DQBUF is called with a pointer to this structure the driver fills the remaining fields or returns an error code. The driver may also set V4L2_BUF_FLAG_ERROR in the flags field. By default, VIDIOC_DQBUF blocks when no buffer is in the outgoing queue. 

This ioctl start the capture or output process during streaming (memory mapping, user pointer or DMABUF) I/O.

Capture hardware is disabled and no input buffers are filled (if there are any empty buffers in the incoming queue) until VIDIOC_STREAMON has been called. Output hardware is disabled and no video signal is produced until VIDIOC_STREAMON has been called. The ioctl will succeed when at least one output buffer is in the incoming queue. Memory-to-memory devices will not start until VIDIOC_STREAMON has been called for both the capture and output stream types.

If VIDIOC_STREAMON fails, then any already queued buffers will remain queued.

The current video standard determines a nominal number of frames per second. If less than this number of frames is to be captured or output, applications can request frame skipping or duplicating on the driver side. This is especially useful when using the read() or write(), which are not augmented by timestamps or sequence counters, and to avoid unnecessary data copying. Further, get/set can be used to determine the number of buffers used internally by a driver in read/write mode. For implications see the section discussing the read() function.

To get the streaming parameters applications call the VIDIOC_G_PARM ioctl. It takes a pointer to a struct struct v4l2_streamparm which contains a union holding separate parameters for input and output devices.

It takes a pointer to a v4l2_std_id type as an argument. VIDIOC_G_STD can return a single flag or a set of flags as in the struct v4l2_standard field id. The flags must be unambiguous such that they appear in only one enumerated struct v4l2_standard structure.

It takes a pointer to a v4l2_std_id type as an argument. VIDIOC_G_STD can return a single flag or a set of flags as in the struct v4l2_standard field id. The flags must be unambiguous such that they appear in only one enumerated struct v4l2_standard structure.

VIDIOC_S_STD accepts one or more flags, being a write-only ioctl it does not return the actual new standard as VIDIOC_G_STD does. 

VIDIOC_ENUM_

FRAMESIZES

This ioctl allows applications to enumerate all frame sizes (i. e. width and height in pixels) that the device supports for the given pixel format. The supported pixel formats can be obtained by using the ioctl VIDIOC_ENUM_FMT function.

The return value and the content of the v4l2_frmsizeenum. type field depends on the type of frame size the device supports. When the application calls the function with index zero, it must check the type field to determine the type of frame size enumeration the device supports.

The VIDIOC_TRY_FMT ioctl is equivalent to VIDIOC_S_FMT with 1 exception: it does not change the driver state. It can also be called at any time, never returning EBUSY. This function is provided to negotiate parameters, to learn about hardware limitations, without disabling I/O or possibly time-consuming hardware preparations. Although strongly recommended drivers are not required to implement this ioctl. The format as returned by VIDIOC_TRY_FMT must be identical to what VIDIOC_S_FMT returns for the same i/p or o/p.

Applications use this function to query the cropping limits, the pixel aspect of images and to calculate scale factors. They set the type field of a v4l2_cropcap structure to the respective buffer (stream) type and call the ioctl VIDIOC_CROPCAP ioctl with a pointer to this structure. Drivers fill the rest of the structure. The results are constant except when switching the video standard. Remember this switch can occur implicit when switching the video input or output.
This ioctl must be implemented for video capture or output devices that support cropping and/or scaling and/or have non-square pixels and for overlay devices.

This can be used as an alternative or in addition to the ioctl VIDIOC_REQBUFS ioctl, when tighter control over buffers is required. This ioctl can be called multiple times to create buffers of different sizes. To allocate the device buffers applications must initialize the relevant fields of the struct v4l2_create_buffers structure. The count field must be set to the number of requested buffers, the memory field specifies the requested I/O method and the reserved array must be zeroed. The format field specifies the image format that the buffers must be able to handle.

When the ioctl is called with a pointer to this structure the driver will attempt to allocate up to the requested number of buffers and store the actual number allocated and the starting index in the count and the index fields respectively. On return count can be smaller than the number requested.