On 09.01.2013, at 21:25, Anthony Liguori wrote:
> Hi,
>
> David Verbeiren <david.verbei...@intel.com> writes:
[...]
>
>> +
>> + int frame_w = ds_get_width(vs->ds);
>> + int frame_h = ds_get_height(vs->ds);
>> +
>> + /* first call for this frame: perform encoding */
>> + if ((frame.data == NULL) || (frame.count != vs->vd->h264.frame_count)) {
>> +
>> + if (!vs->vd->h264.va_dpy || (vs->vd->h264.config == VA_INVALID_ID))
>> {
>> + if (h264_encoder_init(&vs->vd->h264) != 0) {
>> + fprintf(stderr, "Failed to initialize VA H264 encoder\n");
>> + return 0;
>> + }
>
> Since we really can't guarantee that libva will initialize okay, we need
> to more gracefully handle falling back to another encoding type.
In fact, doesn't libavcodec / gstreamer support vaapi? If we could just send
our updates to a library and have that determine whether vaapi is available or
maybe fall back to software H.264 encoding, people without vaapi compatible
hardware (or software) could exploit this feature too.
Though I'm not saying it's a prerequisite to merge this patch. As a proof of
concept, it's good enough to rely on vaapi directly. I just think not doing so
would open this to a broader range of users. And it would get rid of a whole
class of problems (hardware limitations on concurrent users, X dependency, etc)
Alex
