Re: [PATCH] media: iris: Retain firmware confirmed video_format across GOP restarts

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 9/1/26 3:31 PM, Vishnu Reddy wrote:
> During speed-based rewind, the client restarts the decoder queues once
> per group of pictures (GOP), because playing a GOP-based in reverse

"playing a GOP-based [missing word?] in reverse"

> means decoding each group forward first and then showing its frames in
> reverse order, and every time this happens the driver resends the colour
> info property on the bitstream port, which firmware always treats as a
> sign that the stream's properties may have changed. 

This is a single sentence and it's way too long to parse.

> The real problem was
> that the driver never stored the video_format value that firmware had
> last confirmed, so each time colour info was resent, it used a fixed
> unspecified value instead of the real one, and value firmware received
> kept differing from what it already had. 

[newline]

> On every restart during rewind,
> this looked to firmware like a change on the bitstream port, so firmware
> sent a settings-change notification, the driver treated it as a dynamic
> resolution change and paused the port, 

[full stop]

> and the client removed its buffers

"The client then removed its buffers.."

> and built new ones for a resolution that had not actually changed, causing
> playback to stall once per group of pictures. By storing and sending back

Please use imperative mood for describing the actual action you're taking
(per Documentation/process/submitting-patches.rst)

Konrad