media: iris: Retain firmware confirmed video_format across GOP restarts - #1842
gouravk-qualcomm wants to merge 1 commit into
Conversation
|
Dev Completion validation failed CR: 4568445 The change task for this CR could not be moved to Dev Complete because of the error above. Please resolve the issue in Orbit and re-run the failed Orbit check. |
|
Dev Completion validation failed CR: 4568445 The change task for this CR could not be moved to Dev Complete because of the error above. Please resolve the issue in Orbit and re-run the failed Orbit check. |
2 similar comments
|
Dev Completion validation failed CR: 4568445 The change task for this CR could not be moved to Dev Complete because of the error above. Please resolve the issue in Orbit and re-run the failed Orbit check. |
|
Dev Completion validation failed CR: 4568445 The change task for this CR could not be moved to Dev Complete because of the error above. Please resolve the issue in Orbit and re-run the failed Orbit check. |
4978ed9 to
17c55f2
Compare
🔨 Build Failure Analysis — PR #1842PR: #1842
VerdictThis build failure is NOT caused by PR #1842. The failure occurred during the automerge step with 137 pre-existing merge conflicts across the codebase. None of the three files modified by this PR are involved in any merge conflicts. The compilation phase never started. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1842PR: #1842 Build Status: ❌ Merge Conflict (Pre-Compilation)The build failed during the automerge step before any compilation occurred. The PR could not be merged with the integration branch due to merge conflicts in files unrelated to the PR changes.
VerdictNo compilation errors found. All 4 failures are merge conflicts in files not touched by this PR. The PR changes are isolated to the iris media driver and are syntactically correct. 📎 Detailed analysis: Full report |
PR #1842 — validate-patchPR: #1842
Final Summary
|
PR #1842 — checker-log-analyzerPR: #1842
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>
17c55f2 to
d0e98fa
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