commit e27d61ec227308f56c1af39a440ae272c01b3c3a
author Miguel Casas <mcasas@chromium.org> Tue Apr 30 14:26:37 2024
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Apr 30 14:26:37 2024
tree a2feb6c0a5cd8a9e05432aef39b513b7f14467f1
parent 0133ffe8eda976bfa76ce5553e92d7e812934e3e

[124] media/gpu/V4L2StatefulVD: Fix Reset() routine

"seeking" during a <video> playback is implemented via a Reset()
 and a number of Decode() calls until the desired position ("resume
point") is reached. ToT code seems to enrage MT8173's (Hana) driver:
sometimes a decoded frame from "before" the reset would be stuck in
the CAPTURE queue, not letting the decode process restart. Otherwise
it simply stops decoding altogether.

Instead of debugging the specific sequence that would please this
legacy driver, this CL simply closes the queues and driver FD. This
seems to work just fine for both said MT8173 (e.g. Hana) and
Qualcomm SC7180 (e.g. Trogdor).

After this CL:
- V4L2StatefulVD is not left ready for Decode() after Reset() -- a
provision is made to Initialize() explicitly in that case.
- Initialize() can be called after a flush (a.k.a. "drain"); with
this CL, Initialize() cannot call Reset(), so the necessary actions
are inlined.

Verified with a significant number of Tast tests on hana and
trogdor.

(cherry picked from commit 537ba536fd56c1fff34d0fe406d4b87b8268d1b3)

Bug: 279980150
Change-Id: I786fefd51d42ea90effbb3dc3b7b8d8661f950a8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5474676
Reviewed-by: Nathan Hebert <nhebert@chromium.org>
Commit-Queue: Miguel Casas-Sanchez <mcasas@chromium.org>
Cr-Original-Commit-Position: refs/heads/main@{#1291051}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5497581
Cr-Commit-Position: refs/branch-heads/6367@{#1048}
Cr-Branched-From: d158c6dc6e3604e6f899041972edf26087a49740-refs/heads/main@{#1274542}