[PATCH 0/6] MR179: winegstreamer: Use the wg_sample structure to wrap and read media samples.

Zebediah Figura zfigura at codeweavers.com
Mon Jun 6 00:00:11 CDT 2022

I've been staring at this for a while, and I'm still not convinced that 
this abstraction is an improvement. I think I get the idea—to try to 
share code between the input and output sample path—but as far as I can 
tell the only code that's actually *shared* is the code to retrieve the 
buffer pointer itself and the maximum length. Everything else is either 
input-only or output-only. As such we end up introducing a lot of code 
into the common path that kind of obscures the otherwise simpler 
functionality of push/read. (It's also kind of confusing that we're 
reading the previous values of an output sample, or writing values into 
an input sample.)

I don't intend to let that block progress on the transform objects, but 
if it's possible I'd rather hold off on converting the parser to this 
abstraction—at least until the transforms have reached their "final" 
(zero-copy) form [not that it's immediately clear why this abstraction 
makes more sense in that case]. Would it be feasible to hold off on 
these patches for now?

More information about the wine-devel mailing list