[PATCH 1/3] winegstreamer: Introduce new wg_transform struct.

Rémi Bernon rbernon at codeweavers.com
Fri Feb 11 17:46:47 CST 2022


On 2/12/22 00:19, Zebediah Figura wrote:
> On 2/11/22 03:36, 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 at codeweavers.com>
>> ---
>>
>> This would serve a simpler purpose than the full-fledged wg_parser, and
>> be used by synchronous transforms only (at least there's no thread on
>> the Wine side), which simply work on the push then pull loop model.
> 
> Do you by chance have a complete branch somewhere that I can look at or 
> mess with? I'd in particular like to see just how much code is 
> identical, or explicitly different, between the parser and transform 
> objects.
> 
>> The wg_transform name is chosen to be generic and possibly cover both
>> decoder and encoders (and possibly converters), but maybe it's better
>> to keep it specific for now and only design it for decoders. This would
>> simplify the format question in the next patch.
> 
> I suspect it makes more sense for it to be a generic transform object. 
>  From what I've seen GStreamer doesn't really discriminate between 
> encoders, decoders, and other transforms, and I don't think that 
> winegstreamer should either.
> 

I have three branches on top of each other, wip/wmadev/v1, 
wip/h264dec/v1, and wip/aacdec/v1 in https://github.com/rbernon/wine, 
although the last one is not polished at all and full of wip patches for 
tests.

Probably the most interesting things are in the wmadec and h264dec 
patches. As far as I could see (although I didn't test it much) the 
aacdec didn't really require anything except the format mappings.

Or, if you prefer a patch series:

https://github.com/rbernon/wine/compare/6c7b746812...cb863ca5c2.patch

Cheers,
-- 
Rémi Bernon <rbernon at codeweavers.com>



More information about the wine-devel mailing list