Lines Matching full:client
12 from the client to process these buffers.
56 client
84 ``OUTPUT`` buffers must be queued by the client in decode order; for
92 buffers must be queued by the client in display order; for decoders,
218 client may call :c:func:`VIDIOC_ENUM_FMT` on ``OUTPUT``.
227 2. To enumerate the set of supported raw formats, the client may call
234 the client must first set that coded format on ``OUTPUT`` and then
237 3. The client may use :c:func:`VIDIOC_ENUM_FRAMESIZES` to detect supported
291 event, regardless of whether they match the values set by the client or
298 and the client must ensure it matches its needs afterwards.
322 given. The client must check the updated value of ``count`` after the
350 given. The client must check the updated value of ``count`` after the
358 buffers will be processed and returned to the client in order, until
368 first frame, it will not be returned to the client, until the
371 * If the client has not set the coded resolution of the stream on its own,
380 Any client query issued after the decoder queues the event will return
386 A client capable of acquiring stream parameters from the bytestream on
392 from the stream yet. If the values configured by the client do not match
488 successfully parses the stream metadata. The client must not rely on the
493 client may use this ioctl to discover which raw formats are supported for
518 ``CAPTURE`` queue. The client may choose a different format than
564 supported one to meet codec and hardware requirements. The client needs
567 6. If all the following conditions are met, the client may resume the decoding
575 requirement, the client may use :c:func:`VIDIOC_CREATE_BUFS` to add new
578 In that case, the remaining steps do not apply and the client may resume
587 However, if the client intends to change the buffer set, to lower
640 given. The client must check the updated value of ``count`` after the
646 depth), the client may query the ``V4L2_CID_MIN_BUFFERS_FOR_CAPTURE``
679 given. The client must check the updated value of ``count`` after the
685 metadata, the client must proceed as follows, before the metadata
704 In this state, the client queues and dequeues buffers to both queues via
718 The client must not assume any direct relationship between ``CAPTURE``
744 originated from, the client can set the ``timestamp`` field of the
766 Consequently, the client should avoid writing into this memory while the
771 client should make sure that each ``CAPTURE`` buffer is always queued with
783 ``V4L2_BUF_FLAG_LAST`` flag set. To determine the sequence to follow, the client
796 Should a decoding error occur, it will be reported to the client with the level
808 error code. The client may close the file handle and open a new one, or
828 treated as returned to the client (following standard semantics).
847 buffers will be processed and returned to the client until a suitable
859 In case of the H.264/HEVC codec, the client must take care not to seek
863 a crash or a fatal decode error, the client must not expect a sensible
867 corresponding buffers will be returned to the client with the
904 seek, the client may observe the timestamps to match the CAPTURE and OUTPUT
910 To achieve instantaneous seek, the client may restart streaming on the
945 Any client query issued after the decoder queues the event will return
958 = 0) and in that case it must be ignored by the client, as it does not
967 The client must continue the sequence as described below to continue the
993 The client should, for best performance and simplicity, keep queuing/dequeuing
1000 ``CAPTURE`` buffers are given to the client, the client must follow the drain
1001 sequence described below. After the drain sequence ends, the client has
1026 2. Any ``OUTPUT`` buffers queued by the client before the
1028 normal. The client must continue to handle both queues independently,
1041 ``bytesused`` = 0) and in that case it must be ignored by the client,
1053 * dequeuing the ``V4L2_EVENT_EOS`` event, if the client subscribed to it.
1059 dequeued. It is a deprecated behavior and the client must not rely on it.
1065 buffers until the client issues any of the following operations:
1073 client,
1077 client and the `Seek` sequence will be triggered.
1081 Once the drain sequence is initiated, the client needs to drive it to
1084 queues. The client is not allowed to issue ``V4L2_DEC_CMD_START`` or
1095 will initiate the `Drain` sequence, which the client must handle as described
1106 that the ``CAPTURE`` format may be reset and the client must not rely on the
1122 the client must not change the format on the ``OUTPUT`` queue. Drivers will