[PATCH v2 0/6] MR61: winegstreamer: Dynamic transform stream format change support.

[Rémi Bernon (@rbernon)]

On Tue May 17 05:48:42 2022 +0000, Rémi Bernon wrote:
> ```
> To be clear, what bothered me about the last iteration is that the 
> format-change logic feels awkwardly split in half between the frontend 
> and backend. Hence my proposal to move it *entirely* to the 
> frontend—including keeping track of the previous type there, comparing 
> caps, and returning MF_E_TRANSFORM_STREAM_CHANGE from the front end. So 
> the existence of this field still feels awkward to me. Did I forget a 
> discussion again about why it's necessary?
> ```
> This is imo only making everything more complicated than it needs to be.
> We would have to copy back the sample and all its attributes somewhere
> in the transform, and copy it again on the next call, with a special
> conditional case just for that.
> Although I don't really see how the current proposal (or its previous
> versions) is so awkward, yes the frontend and backend are made to work
> together and share some logic. This is really just some internal API and
> I really think we should make it ad-hoc depending on our needs, for
> simplicity rather than purity. The wg_transform is only the unix side of
> MF transforms / DMO, there's really no intention to have it used
> anywhere else.
> ```
> For that matter, I could also see an argument for moving the whole thing 
> to the back end, and handling the "frontend needs to explicitly 
> invalidate the format" problem by adding a new unixlib API for it. (Or 
> maybe just destroying and recreating the wg_transform? That's not ideal 
> if it happens frequently, but I don't know if that's the case.)
> ```
> I this this would be even worse, and we will need to pass the format to
> the transform anyway. We cannot destroy the transform, we would lose the
> decoder state.
```
For that matter, I could also see an argument for moving the whole thing 
to the back end
```

Moreover, and especially for the patch introducing the format change detection, I don't see how it doesn't fit that definition now. There's no information provided from the frontend anymore, and change is detected on the backend only.

I'm not sure it'll stand for all the special cases where format change should be returned, but as far as I could check it seems to work okay that way with the few games I tried it with.

The frontend still needs to query the new format in the next change but that's all and for me things aren't "split" anymore.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/61#note_927