[Libva] [RFC] Split <va/va.h>

[Gwenole Beauchesne]

Hi Jonathan,

On Mon, 28 Sep 2009, Bian, Jonathan wrote:

> I am not sure whether I'd go as far as splitting the header into so many 
> pieces ... it seems that this would just make it more cumbersome for 
> someone to go through the interfaces.  At least I would keep the core 
> encode/decode interfaces in the same header file.

Yes, I think we should keep the functions used for the "standard" decode 
pipeline execution within a single header. However, optional API that are 
not innerly necessary for decoding and presentation (e.g. VA images and 
subpictures) could live in a separate header. For codecs information, I am 
convinced this would be a benefit to have specific headers for them.

To be honest, I myself found somewhat suboptimal to search for 
VAPictureParameterBufferCODEC whereas a specific header would have been 
immediate. ;-) [because, if one searches for only "CODEC" he would find 
the profiles first and then have to next-next-next to get the expected 
results. Of course, he could search for the explicit structure but it's 
more chars and less intuitive then opening the va_CODEC.h file, IMHO].

So, we could reduce to the following structure:
- va.h: keep the usual encode/decode pipeline (buffers, context, surfaces,...)
- va_image: VA image related
- va_subpic.h: VA subpictures related
- va_{mpeg2,mpeg4,..}.h: codec related

Having codecs split off would also be more consistent if we were to have 
3rdparties provide HW acceleration for other codecs, so they would provide 
the headers themselves.

Regards,
Gwenole.