Hi guys, as the subject already indicates: I'm about to merge pipe-video to master and just wanted to ask if anybody has still any objections?
After following Jose and Younes discussion on mesa-dev about how to design such an abstraction layer I took another round of cleaning up the interface and moved some more parts into the state tracker. So the interface between the state tracker and drivers only consist of the following now: 1. two additional functions for the screen object: get_video_param and is_video_format_supported. get_video_param gets a parameter for a specified codec (like max width/height of decoding target, which could be smaller than texture max width/height), and is_video_format_supported which checks if a texture format is supported as a decoding target for a codec. 2. create_video_decoder function in the pipe_context object, which creates a decoder object for a given codec. The decoder object in turn includes everything needed to decode a video stream of that codec and uses pipe_video_decode_buffer objects to hold the input data of a single frame of that video codec. 3. create_video_buffer function in the pipe_context object, which creates a video_buffer object to store a decoded video frame. This video_buffer object is then used for both rendering to the screen with normal pipe_context functionality and also as the input for reference frames back to the decoder. The pipe_video_buffer object is there because I think hardware decoders need some special memory layout of the different planes of a yuv buffer. There is a standard implementation that just uses normal textures as the different planes for yuv buffer, which can be used by a driver when there is no need for a special memory layout or when the driver just uses shader based decoding. The other option would be adding a PIPE_BIND_VIDEO_BUFFER flag to the resource creation functions, but I don't want to repeat functionality in the different drivers and as far as I can see the current resource functions (samplers/surfaces) can't be used to create a surface for just one plane/component of a yuv buffer and we could still clean that up to use the standard resource functions if the need arise. Everything else, especially the vl_compositor functionality, is now part of the state tracker instead of the driver. The interface was mostly designed keeping two things in mind: First it should abstract the functionality of hardware video decoding from the state tracker and second it should be possible to implement a wide variety of different video decoding apis with it. For the second part I checked that it's at least possible to do XvMC,VDPAU,VAAPI and DXVA with it. So what do you guys think about it? Regards, Christian. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
