OLD | NEW |
---|---|
(Empty) | |
1 // Copyright (c) 2013 The Chromium Authors. All rights reserved. | |
2 // Use of this source code is governed by a BSD-style license that can be | |
3 // found in the LICENSE file. | |
4 // | |
5 // This file contains an implementation of VaapiDelegate, used by | |
6 // VaapiVideoDecodeAccelerator and VaapiH264Decoder to interface | |
7 // with libva (VA-API library for hardware video decode). | |
8 | |
9 #ifndef CONTENT_COMMON_GPU_MEDIA_VAAPI_DELEGATE_H_ | |
10 #define CONTENT_COMMON_GPU_MEDIA_VAAPI_DELEGATE_H_ | |
11 | |
12 #include "base/callback.h" | |
13 #include "base/memory/ref_counted.h" | |
14 #include "base/synchronization/lock.h" | |
15 #include "media/base/video_decoder_config.h" | |
16 #include "third_party/libva/va/va.h" | |
17 #include "third_party/libva/va/va_x11.h" | |
18 | |
19 namespace content { | |
20 | |
21 // A VA-API-specific decode surface used by VaapiH264Decoder to decode into | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Since this class isn't used in this .h (or .cc fil
Pawel Osciak
2013/05/21 22:32:35
Didn't want to create a separate header for it, I'
Ami GONE FROM CHROMIUM
2013/05/22 23:59:47
I think this is a bad tradeoff. It's a separate t
Pawel Osciak
2013/05/24 01:46:39
Done.
| |
22 // and use as reference for decoding other surfaces. It is also handed by the | |
23 // decoder to VaapiVideoDecodeAccelerator when the contents of the surface are | |
24 // ready and should be displayed. VAVDA converts the surface contents into an | |
25 // X Pixmap bound to a texture for display and releases its reference to it. | |
26 // Decoder releases its references to the surface when it's done decoding and | |
27 // using it as reference. Note that a surface may still be used for reference | |
28 // after it's been sent to output and also after it is no longer used by VAVDA. | |
29 // Thus, the surface can be in use by both VAVDA and the Decoder at the same | |
30 // time, or by either of them, with the restriction that VAVDA will never get | |
31 // the surface until the contents are ready, and it is guaranteed that the | |
32 // contents will not change after that. | |
33 // When both the decoder and VAVDA release their references to the surface, | |
34 // it is freed and the release callback is executed to put the surface back | |
35 // into available surfaces pool, which is managed externally. | |
36 class VASurface : public base::RefCountedThreadSafe<VASurface> { | |
37 public: | |
38 // Provided by user, will be called when all references to the surface | |
39 // are released. | |
40 typedef base::Callback<void(VASurfaceID)> ReleaseCB; | |
41 | |
42 VASurface(VASurfaceID va_surface_id, const ReleaseCB& release_cb); | |
43 | |
44 VASurfaceID id() { | |
45 return va_surface_id_; | |
46 } | |
47 | |
48 private: | |
49 friend class base::RefCountedThreadSafe<VASurface>; | |
50 ~VASurface(); | |
51 | |
52 VASurfaceID va_surface_id_; | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
const, if you like
Pawel Osciak
2013/05/21 22:32:35
Done.
| |
53 ReleaseCB release_cb_; | |
54 | |
55 DISALLOW_COPY_AND_ASSIGN(VASurface); | |
56 }; | |
57 | |
58 // This class handles VA-API calls and ensures proper locking of VA-API calls | |
59 // to libva, the userspace shim to the HW decoder driver. libva is not | |
60 // thread-safe, so we have to perform locking ourselves. | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Does this mean the public methods of this class ma
Pawel Osciak
2013/05/21 22:32:35
It's safe to call from any thread, things will not
| |
61 // | |
62 // This class is responsible for managing VAAPI connection, contexts and state. | |
63 // It is also responsible for managing and freeing VABuffers (not VASurfaces), | |
64 // which are used to queue decode parameters and slice data to the HW decoder, | |
65 // as well as underlying memory for VASurfaces themselves. | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Does this translate to "none of the other files in
Pawel Osciak
2013/05/21 22:32:35
Correct.
| |
66 class VaapiDelegate : public base::RefCountedThreadSafe<VaapiDelegate> { | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Is this actually a VaapiWrapper?
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Why refcount?
(in particular, can VAVDA hold a sco
Pawel Osciak
2013/05/21 22:32:35
Currently yes, as the decoder doesn't do anything
Pawel Osciak
2013/05/21 22:32:35
For me delegate and wrapper are almost synonymous
Ami GONE FROM CHROMIUM
2013/05/22 23:59:47
Refcounting abdicates responsibility for ownership
Pawel Osciak
2013/05/24 01:46:39
Done.
| |
67 public: | |
68 // |report_error_cb| will be used to report errors for UMA purposes, not | |
69 // to report errors to clients. | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Why not rename it to something clearer, then?
re
Pawel Osciak
2013/05/21 22:32:35
Done.
| |
70 static scoped_refptr<VaapiDelegate> Create( | |
71 media::VideoCodecProfile profile, | |
72 Display* x_display, | |
73 const base::Closure& report_error_cb); | |
74 | |
75 // Create |num_surfaces| backing surfaces in driver for VASurfaces, each | |
76 // of size |width|x|height|, and return their IDs to be managed and later | |
77 // wrapped in VASurfaces. | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Returns success.
Pawel Osciak
2013/05/21 22:32:35
Done.
| |
78 bool CreateSurfaces(int width, int height, | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
here and elsewhere, better to use a gfx::Size than
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
The impl of this assumes that this method is calle
Pawel Osciak
2013/05/21 22:32:35
Done, here and in other places.
Pawel Osciak
2013/05/21 22:32:35
Not exactly. CreateSurfaces() -> DestroySurfaces()
| |
79 size_t num_surfaces, | |
80 std::vector<VASurfaceID>& va_surfaces); | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Non non-const references.
Here and elsewhere, wh
Pawel Osciak
2013/05/21 22:32:35
Done.
| |
81 | |
82 // Free all memory allocated in CreateSurfaces. | |
83 void DestroySurfaces(); | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Should be private.
Pawel Osciak
2013/05/21 22:32:35
See above (l.78).
| |
84 | |
85 // Submit parameters or slice data of |va_buffer_type|, copying them from | |
86 // |buffer| of size |size|, into HW decoder. The data in |buffer| is no | |
87 // longer needed and can be freed after this method returns. | |
88 // Data submitted via this method awaits in the HW decoder until | |
89 // DecodeAndDestroyPendingBuffers is called to execute or | |
90 // DestroyPendingBuffers is used to cancel a pending decode. | |
91 bool SubmitBuffer(VABufferType va_buffer_type, size_t size, void* buffer); | |
92 | |
93 // Cancel and destroy all buffers queued to the HW decoder via SubmitBuffer. | |
94 // Useful when a pending decode is to be cancelled (on reset or error). | |
95 void DestroyPendingBuffers(); | |
96 | |
97 // Execute decode in hardware and destroy pending buffers. | |
98 bool DecodeAndDestroyPendingBuffers(VASurfaceID va_surface_id); | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Why is "Destroy" part of the name of this function
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
What does the bool return value mean?
I can imagin
Pawel Osciak
2013/05/21 22:32:35
I felt documentation for SubmitBuffer explained it
Pawel Osciak
2013/05/21 22:32:35
Decode() is for exactly one picture in vaapi. So t
| |
99 | |
100 | |
101 // Put data from |va_surface_id| into x_pixmap of size |width|x|height|, | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
|x_pixmap|
Pawel Osciak
2013/05/21 22:32:35
Done.
| |
102 // converting/scaling to appropriate size. | |
103 bool PutSurfaceIntoPixmap(VASurfaceID va_surface_id, | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Does this require making a context current (or som
Pawel Osciak
2013/05/21 22:32:35
No, thankfully. It's not a GL call.
| |
104 Pixmap x_pixmap, | |
105 int width, int height); | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
dest_width & dest_height ?
Pawel Osciak
2013/05/21 22:32:35
dest_size :)
| |
106 | |
107 // Do any necessary initialization before the sandbox is enabled. | |
108 static void PreSandboxInitialization(); | |
109 | |
110 private: | |
111 friend class base::RefCountedThreadSafe<VaapiDelegate>; | |
112 VaapiDelegate(); | |
113 ~VaapiDelegate(); | |
114 | |
115 bool Initialize(media::VideoCodecProfile profile, | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Should be private, and can be inlined into Create(
Pawel Osciak
2013/05/21 22:32:35
It is private :) I didn't want to inline, because
| |
116 Display* x_display, | |
117 const base::Closure& report_error_cb); | |
118 void Deinitialize(); | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
inline into dtor, since it's the only callsite and
Pawel Osciak
2013/05/21 22:32:35
I'd prefer to keep it this way, makes the destruct
| |
119 | |
120 bool SubmitDecode(VASurfaceID va_surface_id); | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
doco methods whose purpose is unclear. For exampl
Pawel Osciak
2013/05/21 22:32:35
To be honest I don't feel that way:
SubmitBuffer(
| |
121 | |
122 // Libva is not thread safe, so we have to do locking for it ourselves. | |
123 // This lock is to be taken for the duration of all VA-API calls and for | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
I think the only API that makes sense is that ever
Pawel Osciak
2013/05/21 22:32:35
Done.
| |
124 // the entire decode execution sequence in DecodeAndDestroyPendingBuffers(). | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
...and yet, it is not (see comment there).
Pawel Osciak
2013/05/21 22:32:35
See comment there please. Destroy() doesn't have t
| |
125 base::Lock va_lock_; | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
naming this va_lock_ implies it should be held onl
Pawel Osciak
2013/05/21 22:32:35
This is a lock around each libva call or calls tha
| |
126 | |
127 // Allocated backing memory ids for VASurfaces. | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
This comment emphasizes "allocated" in a surprisin
Pawel Osciak
2013/05/21 22:32:35
Well, this was also kind-of documenting what the i
| |
128 scoped_ptr<VASurfaceID[]> va_surface_ids_; | |
129 size_t num_va_surfaces_; | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
why not std::vector<VASurfaceID> instead and avoid
Pawel Osciak
2013/05/21 22:32:35
Yeah, I know this full well, and I even thought ab
| |
130 | |
131 // VA handles. | |
132 VADisplay va_display_; | |
133 VAConfigID va_config_id_; | |
134 VAContextID va_context_id_; | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Would be useful to annotate these with when in the
Pawel Osciak
2013/05/21 22:32:35
Done.
| |
135 | |
136 // Data queued up for HW decoder, to be committed on next HW decode. | |
137 std::vector<VABufferID> pending_slice_bufs_; | |
138 std::vector<VABufferID> pending_va_bufs_; | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
Do these really need to be separate?
(AFAICT they'
Pawel Osciak
2013/05/21 22:32:35
All the code that used VAAPI that I've seen, inclu
Ami GONE FROM CHROMIUM
2013/05/22 23:59:47
You just gave a great definition of what it means
Pawel Osciak
2013/05/24 01:46:39
Not exactly. I'm saying that even if it was ok to
| |
139 | |
140 // Called to report decoding error to UMA, not used to indicate errors | |
141 // to clients. | |
142 base::Closure report_error_cb_; | |
143 | |
144 // Lazily initialize static data after sandbox is enabled. Return false on | |
145 // init failure. | |
146 static bool PostSandboxInitialization(); | |
Ami GONE FROM CHROMIUM
2013/05/17 23:19:15
methods go above members
Pawel Osciak
2013/05/21 22:32:35
Done.
| |
147 | |
148 // Has static initialization of pre-sandbox components completed successfully? | |
149 static bool pre_sandbox_init_done_; | |
150 | |
151 DISALLOW_COPY_AND_ASSIGN(VaapiDelegate); | |
152 }; | |
153 | |
154 } // namespace content | |
155 | |
156 #endif // CONTENT_COMMON_GPU_MEDIA_VAAPI_DELEGATE_H_ | |
OLD | NEW |