On Tue Jun 18 04:07:27 2024 +0000, Ziqing Hui wrote:
If we want wg_format be able to hold large codec data. One way I can come up with is allocating the data in heap, then add a refcount member to wg_format, and we have to free the data when refcount goes to 0. But this makes wg_format really complicate, I don't think this is expected.
If I understand correctly, your concern is about the size of wg_format, either that it's too large or that we currently risk overflowing it if codec_data is larger than we expect?
Making wg_format dynamically sized is a good idea, I think, and I don't have any objection to that part. I'm relatively amenable to performing a two-step conversion as described in 5615, as well.
However, this part of the conversion only has the motivation of reducing LoC, and simply getting rid of wg_format does not even significantly do that.
At the same time, one thing I learned when redesigning winegstreamer is that having an internal, netural, well-designed API surface that each frontend can consume makes winegstreamer a great deal easier to work with. Getting rid of wg_format does away with that.