Hi Jonathan,

2011/8/17 Bian, Jonathan <[email protected]>:
> 3. Added "Ext" buffer types to extend encode parameters buffers without 
> impacting compatibility with existing encode data structures 4. Added new 
> buffer types for packed header to be sent by the app, and various buffers 
> required for video post-processing 5. Added "Ext" version of sequence, 
> picture and slice parameter buffer structures for H.264 to support High 
> Profile encoding.

Can we think about a Cap mechanism similar to VPP's one?
Or should we add a note/comment that for high-profile encoding, the
*Ext structures need to be used?

BTW, could we add an entropy_coding_mode_flag to the older API
supporting Main profile? It seems the PVR driver can also support
CABAC but there is no way to enable it through the API.

> 6. Added new functions and data structures to support video post-processing 
> (see va_vpp.h).

Can we push the latest vaapi-ext changes? It seems the current fd.o
tree does not contain the latest additions and this split to va_vpp.h.

Some extra comments:
- s/VA_ENC_INTERLACED_PIC_AFF/VA_ENC_INTERLACED_PAFF/  to align with
the MBAFF definition?
- VAEncH264VUIBufferH264 is still present. Either the comment is no
longer accurate or we need to drop it. Besides, the bitfields won't
compile with an ISO C compliant compiler
- VAEncSequenceParameterBufferH264Ext needs to be documented more:
  - target_usage is a little ambiguous. Is this specific to HW rate
control? Or driver-based rate control?
  - rate_control_method needs correct enums, possibly not exposing
Gen's values directly. :)
I am wondering if we could also add a "custom" one, meaning
app-controlled through additional API we will define.

I also see that we have VAEnc*BufferExtTypes, why can't we alias Ext
sequence, picture & slice parameter buffer types to the original types
and let the driver determine the actual type through the size
parameter?

I think we can drop the VA_ENUM_MAX definitions since this won't be
useful in practise. What are they used for?

Thanks,
Gwenole.
_______________________________________________
Libva mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libva

Reply via email to