On Tue, 2018-07-24 at 23:06 +0900, Tomasz Figa wrote: [...] > +Seek > +==== > + > +Seek is controlled by the ``OUTPUT`` queue, as it is the source of > +bitstream data. ``CAPTURE`` queue remains unchanged/unaffected. > + > +1. Stop the ``OUTPUT`` queue to begin the seek sequence via > + :c:func:`VIDIOC_STREAMOFF`. > + > + * **Required fields:** > + > + ``type`` > + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT`` > + > + * The driver must drop all the pending ``OUTPUT`` buffers and they are > + treated as returned to the client (following standard semantics). > + > +2. Restart the ``OUTPUT`` queue via :c:func:`VIDIOC_STREAMON` > + > + * **Required fields:** > + > + ``type`` > + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT`` > + > + * The driver must be put in a state after seek and be ready to > + accept new source bitstream buffers. > + > +3. Start queuing buffers to ``OUTPUT`` queue containing stream data after > + the seek until a suitable resume point is found. > + > + .. note:: > + > + There is no requirement to begin queuing stream starting exactly from > + a resume point (e.g. SPS or a keyframe). The driver must handle any > + data queued and must keep processing the queued buffers until it > + finds a suitable resume point. While looking for a resume point, the I think the definition of a resume point is too vague in this place. Can the driver decide whether or not a keyframe without SPS is a suitable resume point? Or do drivers have to parse and store SPS/PPS if the hardware does not support resuming from a keyframe without sending SPS/PPS again? regards Philipp
