gst: Re-enable handling of single long modifiers

A peer may announce support for a single modifier, in which case it may
not use a choice-pod. And while the documentation in `dma-buf.dox`
requires modifiers to always be announced as `SPA_CHOICE_Enum`, this has
been supported in the past - as well as matching Pipewire conventions.

Thus, in order to not break existing clients not crash, reintroduce
handling of modifiers as a single long.

Fixes: f1b75fc6f (gst: Add support for DMA_DRM / explicit modifiers)

Solution suggested by Barnabás Pőcze <pobrn@protonmail.com>
This commit is contained in:
Robert Mader 2024-03-28 14:01:20 +01:00
parent d682d8c5aa
commit 8848c7e792
1 changed files with 17 additions and 7 deletions

View File

@ -877,8 +877,7 @@ handle_dmabuf_prop (const struct spa_pod_prop *prop,
const struct spa_pod *pod_modifier;
struct spa_pod *val;
uint32_t *id, n_fmts, n_mods, choice, i, j;
uint64_t *mods;
uint64_t *mods, single_modifier;
val = spa_pod_get_values (&prop->value, &n_fmts, &choice);
if (val->type != SPA_TYPE_Id)
@ -891,11 +890,22 @@ handle_dmabuf_prop (const struct spa_pod_prop *prop,
}
pod_modifier = &prop_modifier->value;
mods = SPA_POD_CHOICE_VALUES (pod_modifier);
n_mods = SPA_POD_CHOICE_N_VALUES (pod_modifier);
if (n_mods > 1) {
n_mods--;
mods++;
if (spa_pod_is_long (pod_modifier) &&
spa_pod_get_long (pod_modifier, (int64_t *) &single_modifier)) {
mods = &single_modifier;
n_mods = 1;
} else if (spa_pod_is_choice (pod_modifier) &&
SPA_POD_CHOICE_TYPE (pod_modifier) == SPA_CHOICE_Enum &&
SPA_POD_CHOICE_VALUE_TYPE (pod_modifier) == SPA_TYPE_Long) {
mods = SPA_POD_CHOICE_VALUES (pod_modifier);
n_mods = SPA_POD_CHOICE_N_VALUES (pod_modifier);
if (n_mods > 1) {
n_mods--;
mods++;
}
} else {
return;
}
fmt_array = g_ptr_array_new_with_free_func (g_free);