chromeos / cros-libva Goto Github PK

Per @bgrzesik on #10:

We could use a private trait in favor of BufferType enum. Something like:

trait BufferElement: Into<Self::RawType> {
    const TYPE: bindings::VABufferType::Type;
    type RawType;

    fn raw_element_size() -> usize {
        std::mem::size_of::<Self::RawType>()
    }
}

Replace tuple structs with strongly typed and documented copy of raw struct. It would have to be converted to raw when added to the picture (or prior vaRenderPicture), but during this step we could clone Rc<>s to dependencies (like surfaces and EncCodedBuffer) to Picture<> so those wouldn't get dropped before sync. It would clean up some cros-codecs code.

Also Picture::add_buffer could accept a trait that would wrap our use cases. Like so:

trait BufferContents {
    const TYPE: bindings::VABufferType::Type;

    fn element_size(&self) -> usize;

    fn num_elements(&self) -> usize;

    unsafe fn data_ptr(&mut self) -> *mut std::ffi::c_void;
}

// Or just use slice somehow
pub struct BufferArray<T>
where
    T: BufferElement,
{
    array: Vec<T::RawType>,
    // ... deps
}

impl<T> BufferContents for BufferArray<T>
where
    T: BufferElement,
{
 // ...
}

impl<T> BufferContents for Box<T> // Or just T
where
    T: BufferElement,
{
 // ...
}

impl BufferContents for SliceData
{
 // ...
}

In this way we could handle buffer arrays and single element buffers transparently.
On top of that we maybe could look into doing some validations.

Libva mentions the following:

All VAAPI functions implemented in libva are thread-safe. For any VAAPI function that requires the implementation of a backend (e.g. hardware driver), the backend must ensure that its implementation is also thread-safe. If the backend implementation of a VAAPI function is not thread-safe then this should be considered as a bug against the backend implementation.

It is assumed that none of the VAAPI functions will be called from signal handlers.

Thread-safety in this context means that when VAAPI is being called by multiple concurrent threads, it will not crash or hang the OS, and VAAPI internal data structures will not be corrupted. When multiple threads are operating on the same VAAPI objects, it is the application's responsibility to synchronize these operations in order to generate the expected results. For example, using a single VAContext from multiple threads may generate unexpected results.

I think it's safe to implement Send + Sync for cros_libva::Display, although I haven't yet tested it.

@Gnurou

VA-API supports JPEG encoding and decoding via VAProfileJpegBaseline

• https://intel.github.io/libva/group__api__enc__jpeg.html
• https://intel.github.io/libva/group__api__dec__jpeg.html
• https://intel.github.io/libva/group__api__core.html#gga2c3be94ce142fb92a4bf93e9b1b4fa01a5b746c21e32b666d1ecb80a7cf181bcc