On 2/26/22 02:33, Zebediah Figura (she/her) wrote:
On 2/25/22 14:37, Rémi Bernon wrote:
On 2/25/22 18:45, Zebediah Figura (she/her) wrote:
On 2/23/22 08:46, Rémi Bernon wrote:
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51931 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52391 Signed-off-by: Rémi Bernon rbernon@codeweavers.com
dlls/winegstreamer/wg_transform.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
What's the motivation for doing this?
(And why not, say, use a queue element instead? Not that this is particularly complex, to be fair.)
It seemed simpler like this as it doesn't need to wait on ProcessOutput to be called.
That's a good point; I did not consider that. And of course the concern of memory usage doesn't apply here.
The queue seems actually to make the code a little bit shorter, if not simpler logic.
As I intended to add one at some point, and have it wait on ProcessOutput to allow zero-copy output I think I'm going to use it here already instead.
Then it makes all the transforms async, which is slightly incorrect for the WMA decoder, but I guess it's a small price to pay and I don't think it matters too much.
If it actually does, we can later enforce synchronicity by waiting, either on output to be generated, or the queue to be empty.