[Libva] [RFC] Split <va/va.h>
Bian, Jonathan
jonathan.bian at intel.com
Tue Sep 29 10:10:58 PDT 2009
Hi Gwenole,
Yes it's probably a good idea to have codec specific data structures live in separate header files for the reasons you pointed out. Since subpictures are closely related to images, maybe we can have image and subpicture in the same header?
Regards,
Jonathan
-----Original Message-----
From: Gwenole Beauchesne [mailto:gbeauchesne at splitted-desktop.com]
Sent: Tuesday, September 29, 2009 1:27 AM
To: Bian, Jonathan
Cc: libva at lists.freedesktop.org
Subject: RE: [Libva] [RFC] Split <va/va.h>
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.
More information about the Libva
mailing list