On Mon Jul 1 06:28:00 2024 +0000, Elizabeth Figura wrote:
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.
I hear that you disagree but I want to move this forward nonetheless, because it's what has been thoroughly tested now. Now I won't press toward a change of all the wg_format uses and will only limit it to the wg_transform uses where I need it.
I also don't see the difference between a custom made format and standard structures, which hold the same information and more. The standard structures are dynamically sized by design, they are supposed to be followed by codec-private data, and the additional information (apertures, colorspace, etc) would be useful in the future.