AV videodecoder - Review Points

[SrigayathryPugazhenthi]

1. No event for decoder state change. eg. after calling open/close in controller
2. Need to check if decoder buffer underrun/overflow tracking needed similar to decoded/dropped frames ?
3. Do we need to add PTS parameter which will be helpful during the discontinuity

[Ulrond]

Hi @SrigayathryPugazhenthi,

1. Decoder state change events after open/close

This is already supported. IVideoDecoderEventListener.onStateChanged(oldState, newState) provides exactly this — it fires on every state transition, including after open() (CLOSED → OPENING → READY) and close() (READY → CLOSING → CLOSED).

Any client that needs to observe state changes registers via IVideoDecoder.registerEventListener(). The controller (the client that called open()) implicitly receives state context through the returned IVideoDecoderController interface, while third-party observers use the event listener.

See:

• IVideoDecoderEventListener.onStateChanged()
• IVideoDecoder.registerEventListener() / unregisterEventListener()
• IVideoDecoder.getState() for polling the current state

2. Buffer underrun/overflow tracking

The current metric properties cover decode-output quality: METRIC_FRAMES_DECODED, METRIC_DECODE_ERRORS, and METRIC_FRAMES_DROPPED. These are the metrics that matter at the HAL boundary.

Buffer underrun/overflow is a pipeline-level concern that sits above the HAL — it depends on how the middleware manages the input feed rate relative to decode consumption. The decoder HAL already signals backpressure through decodeBuffer() returning false (input queue full), and IAVBufferSpaceListener.onSpaceAvailable() for pool-level flow control.

Adding underrun/overflow counters to the HAL would conflate middleware scheduling behaviour with decoder capability. If there is a specific SoC-internal buffer condition you're seeing that isn't covered by the existing error/drop metrics, please describe the scenario and we can evaluate whether a new metric property is warranted.

3. PTS parameter on discontinuity

signalDiscontinuity() is intentionally parameter-free. It marks a boundary — telling the decoder that subsequent frames passed to decodeBuffer() are PTS-discontinuous to any previously held frames. The PTS of the first frame after the discontinuity is already carried on the next decodeBuffer(nsPresentationTime, bufferHandle) call.

Adding a PTS to signalDiscontinuity() would be redundant with the PTS on the next decodeBuffer() call, and would create an ambiguity about which value takes precedence if they differ.

[srinivasgtl]

For point 2, we have onAudioUnderflow and onVideoUnderflow at the sink level, which shall provide the data if there is any underflow. The overflow and underflow info at the decoder level can be just handled with logs (for debugging). Refer to IVideoSinkControllerListener.aidl and IAudioSinkControllerListener.aidl for the underflow events.