followup to the direct-surface experiments in wang-bin/fvp#379 (AMediaCodec:image=0:surface=<jobject>), device: tcl google tv, realtek rtd2875p, powervr, android 12.
sdr content is perfect in this mode — 24fps at 4k24, 56fps at 4k60, zero droughts (numbers in the #379 comment). but hdr10 / dolby vision content wedges the decoder:
file: 3840x1600 hevc, hdr10 + DV layer (platform logs Unsupported mime video/dolby-vision while probing, then plain hevc decoder configures with frame-info: ... hdr=1, transfer=0->16 i.e. PQ)
what happens:
- first open: decoder consumes input at a steady 10/s (
[QIB]V, QIB:10/s) and never releases a single output buffer — no [ROB] lines at all. audio/position keep running, screen shows the tv's HDR10 banner (display switches to hdr mode) and then stays frozen
- reopen: decoder comes up, drops a burst catching up to the resume point, outputs at 18-21fps for ~10s, then stalls the same way. display side spams
RHWC2: noPost layer_index == 0 (1800+ times) and DvoComposer: connecting state output region change — the video plane never finishes connecting. mdk ends up creating 3 decoder instances in 80s (teardown/retry loop)
- same file through the normal GL render path (image reader + gl) plays fine, tone-mapped
so it looks like the non-tunneled decoder→surface hdr handoff is broken on this soc: the display pipeline enters hdr mode but never completes, output buffers back up, decoder wedges.
i also tried the documented tunnel shape AMediaCodec:image=0:tunnel=1:window=<ANativeWindow*> — codec accepts it and renders (sdr), but feature-tunneled-playback = 0 in the configured format and surfaceflinger shows sideband stream=0x0, so the codec silently declines real tunneling (guessing it wants an audio hw sync session id, which there's no way to pass currently?)
questions:
- is hdr content expected to work in the plain
surface= mode, or does hdr on these tv socs strictly need real tunneled playback (tunnel=1 + audio hw sync)?
- if the latter, is there a way (or could there be one) to wire an av sync session through mdk so tunnel=1 actually engages? or alternatively for mdk to detect the stall and fall back?
for now my app routes hdr/10-bit content back to the gl path and keeps direct mode for sdr (fork commits: abdelaziz-mahdy/fvp@ad6f59e), which works but loses real hdr output.
happy to run any experiment on this device, it reproduces 100%.
(investigated with an AI assistant (Fable), verified on device)
followup to the direct-surface experiments in wang-bin/fvp#379 (
AMediaCodec:image=0:surface=<jobject>), device: tcl google tv, realtek rtd2875p, powervr, android 12.sdr content is perfect in this mode — 24fps at 4k24, 56fps at 4k60, zero droughts (numbers in the #379 comment). but hdr10 / dolby vision content wedges the decoder:
file: 3840x1600 hevc, hdr10 + DV layer (platform logs
Unsupported mime video/dolby-visionwhile probing, then plain hevc decoder configures withframe-info: ... hdr=1,transfer=0->16i.e. PQ)what happens:
[QIB]V, QIB:10/s) and never releases a single output buffer — no[ROB]lines at all. audio/position keep running, screen shows the tv's HDR10 banner (display switches to hdr mode) and then stays frozenRHWC2: noPost layer_index == 0(1800+ times) andDvoComposer: connecting state output region change— the video plane never finishes connecting. mdk ends up creating 3 decoder instances in 80s (teardown/retry loop)so it looks like the non-tunneled decoder→surface hdr handoff is broken on this soc: the display pipeline enters hdr mode but never completes, output buffers back up, decoder wedges.
i also tried the documented tunnel shape
AMediaCodec:image=0:tunnel=1:window=<ANativeWindow*>— codec accepts it and renders (sdr), butfeature-tunneled-playback = 0in the configured format and surfaceflinger showssideband stream=0x0, so the codec silently declines real tunneling (guessing it wants an audio hw sync session id, which there's no way to pass currently?)questions:
surface=mode, or does hdr on these tv socs strictly need real tunneled playback (tunnel=1 + audio hw sync)?for now my app routes hdr/10-bit content back to the gl path and keeps direct mode for sdr (fork commits: abdelaziz-mahdy/fvp@ad6f59e), which works but loses real hdr output.
happy to run any experiment on this device, it reproduces 100%.
(investigated with an AI assistant (Fable), verified on device)