media: iris: Retain firmware confirmed video_format across GOP restarts - #1121
gouravk-qualcomm wants to merge 1 commit into
Conversation
|
Merge Check Failed: CR Not Eligible for Merge CR 4568445 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
7dc118a to
df80380
Compare
PR #1121 — validate-patchPR: #1121
Final Summary
|
PR #1121 — checker-log-analyzerPR: #1121
Detailed report: Full report
|
…GOP restarts During speed-based rewind, the client restarts the decoder queues once per group of pictures (GOP). This is because playing a GOP-based stream in reverse requires decoding each group forward first and then showing its frames in reverse order. Each restart makes the driver resend the colour info property on the bitstream port, which firmware always treats as a sign that the stream's properties may have changed. The driver never stored the video_format value that firmware had last confirmed, so it resent colour info with a fixed unspecified value instead of the real one, and the value firmware received kept differing from what it already had. On every restart during rewind, this looked to firmware like a real change on the bitstream port, so firmware sent a settings-change notification, and the driver treated it as a dynamic resolution change and paused the port. The client then removed its buffers and built new ones for a resolution that had not actually changed, stalling playback once per GOP. Store and send back the same video_format value firmware already confirmed so both sides stay in agreement across every restart, avoiding the false settings-change notification. Link: https://lore.kernel.org/all/20260905-read_video_format_from_firmware-v2-1-21a606cdd288@oss.qualcomm.com/ Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
df80380 to
fe46620
Compare
During speed-based rewind, the client restarts the decoder queues once per group of pictures (GOP). This is because playing a GOP-based stream in reverse requires decoding each group forward first and then showing its frames in reverse order. Each restart makes the driver resend the colour info property on the bitstream port, which firmware always treats as a sign that the stream's properties may have changed. The driver never stored the video_format value that firmware had last confirmed, so it resent colour info with a fixed unspecified value instead of the real one, and the value firmware received kept differing from what it already had.
On every restart during rewind, this looked to firmware like a real change on the bitstream port, so firmware sent a settings-change notification, and the driver treated it as a dynamic resolution change and paused the port. The client then removed its buffers and built new ones for a resolution that had not actually changed, stalling playback once per GOP.
Store and send back the same video_format value firmware already confirmed so both sides stay in agreement across every restart, avoiding the false settings-change notification.
CRs-fixed:4568445