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

[Rémi Bernon (@rbernon)]

On Tue May 17 03:55:11 2022 +0000, **** wrote:
> Zebediah Figura replied on the mailing list:
> ```
> On 5/13/22 04:48, Rémi Bernon wrote:
> > diff --git a/dlls/winegstreamer/wg_transform.c b/dlls/winegstreamer/wg_transform.c
> > index b6cc51aecb7..9edcd72754f 100644
> > --- a/dlls/winegstreamer/wg_transform.c
> > +++ b/dlls/winegstreamer/wg_transform.c
> > @@ -52,17 +52,27 @@ struct wg_transform
> >       guint input_max_length;
> >       GstAtomicQueue *output_queue;
> >       GstSample *output_sample;
> > +    bool output_caps_changed;
> >       GstCaps *output_caps;
> >   };
> 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?
> 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.)
> ```
```
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.

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