Support for Shikra added for Video - #569
Conversation
Signed-off-by: Abhishek Bajaj <abbajaj@qti.qualcomm.com>
Srikanth Muppandam (smuppand)
left a comment
Srikanth Muppandam (smuppand)
left a comment
There was a problem hiding this comment.
Recommended scalable design
functestlib.sh
platform_runtime_identity()
platform_identity_matches()
lib_video.sh
video_policy_lookup(platform, mode, codec)
video_stage_control_override(config, control, value, output_dir)
run.sh
platform=$(...)
policy=$(...)
effective_config=$(...)
run repeats and retries with effective_config
With this design:
- Adding a new SoC means adding policy data.
- Platform detection remains shared across audio and video.
- JSON staging has one implementation.
- Normal runs and retries cannot diverge.
- No-policy platforms use the original config unchanged.
| # if no device-tree/platform data is available (callers should treat that | ||
| # as "no match" rather than falling back to a caller-name heuristic). | ||
| # ----------------------------------------------------------------------------- | ||
| video_get_dt_identity() { |
There was a problem hiding this comment.
video_get_dt_identity() duplicates both detect_platform() and the Shikra runtime identity logic merged in PR #544 as audio_platform_is_shikra(). A future SoC alias or DT-root correction would need to be updated independently in functestlib, audio, and video. Extract a generic runtime platform identity/match helper into functestlib.sh, including both DT roots, and make audio and video consume that shared contract.
| # video_target_is_shikra -> 0/1 | ||
| # video_apply_level_override_for_target <cfg_json_path> | ||
|
|
||
| : "${VIDEO_LEVEL_OVERRIDE:=4.0}" |
There was a problem hiding this comment.
The policy model supports only one global target/value pair:
VIDEO_LEVEL_OVERRIDE=4.0
VIDEO_LEVEL_OVERRIDE_TARGET=shikra
It cannot express cases such as Shikra H.264=4.0, Shikra HEVC=4.1, and a future SoC HEVC=5.1 without adding branches or changing global state. Replace this with a policy lookup keyed by platform, mode, codec, control, and value. Adding another SoC should require one policy row, with no run.sh changes.
For example:
shikra|encode|h264|Level|4.0
shikra|encode|hevc|Level|4.0
new-soc|encode|hevc|Level|5.1
| } | ||
|
|
||
| # Convenience wrapper for the "shikra" target specifically. | ||
| video_target_is_shikra() { |
There was a problem hiding this comment.
video_target_is_shikra() has no callers and establishes a pattern that would lead to video_target_is_() helpers for every new target. Remove this wrapper. Use the shared platform identity plus the generic policy lookup.
| if video_run_once "$cfg" "$logf" "$TIMEOUT" "$SUCCESS_RE" "$LOGLEVEL"; then | ||
| run_cfg="$cfg" | ||
| if [ "$mode" = "encode" ] && { [ "$codec" = "h264" ] || [ "$codec" = "hevc" ]; }; then | ||
| if command -v video_apply_level_override_for_target >/dev/null 2>&1; then |
There was a problem hiding this comment.
Configuration preparation is duplicated in the normal path and retry path at line 1262. Every future target policy would need to remain synchronized across both branches. Resolve and stage the effective configuration once per test case, before the repeat loop, then use the same path for normal
runs and retries. Preserve helper diagnostics instead of redirecting stderr.
| BEGIN { in_level = 0 } | ||
| { | ||
| line = $0 | ||
| if (line ~ /"Id"[ \t]*:[ \t]*"Level"/) { |
There was a problem hiding this comment.
The transformation claims to be scoped to StaticControls, but it only finds "Id": "Level" and rewrites the next "Value" line. It does not track the enclosing JSON object. Make the generic staging helper structurally validate the intended object and verify that exactly one requested control changed. A malformed or ambiguous config must fail preparation rather than run with an uncertain result.
| *"$tok_l"*) | ||
| return 0 | ||
| ;; | ||
| *) |
There was a problem hiding this comment.
Remove the trailing whitespace. git diff --check currently fails here.
3 participants
Changes: