[Libva] (H264) Reference Picture selection

[Gwenole Beauchesne]

Hi,

2014-05-12 3:34 GMT+02:00 Zhao Yakui <yakui.zhao at intel.com>:
> On Fri, 2014-05-09 at 03:06 -0600, Yuan, Feng wrote:
>> Hi,
>>
>> >>> I have a scheme where the decoder ack's received frames - With this
>> >>> information I could resync without an IDR by carefully selecting the
>> >>> reference frame(s).
>> >
>> >> Will you please describe your idea in detail?
>> >
>> >>> long term references would typically be employed as well, but it
>> >>> seems ref-pic-marking was removed may'13?
>> >
>> >> Why do you hope to use the long-term reference? As you know, the
>> >> current encoding is based on hardware-acceleration. When more the
>> >> reference frames can be selected, the driver will be more complex and
>> >> then the encoding speed is also affected.
>> >
>> >It's for implementing Cisco's clearpath technology
>> >(http://www.cisco.com/c/dam/en/us/td/docs/telepresence/endpoint/softwa
>> >re/clearpath/clearpath_whitepaper.pdf)
>> >Basically one would  periodically mark a P frame as long term reference, in
>> >case of packet loss one can thus refer to this one instead of restarting the
>> >stream with an idr.
>> >
>> >
>> >I'm not too concerned about the encoding speed as long as it's above
>> >realtime (60fps 1920x1080)
>>
>> Maybe it's more convenient If libva can have a switch for slice_header made between driver and app. Then some specially cases(ref-reorder, long-term-ref) may let app to manage slice-header.
>
> Thanks for your suggestion. If the slice-header info is also generated
> by the app and then be passed to the driver, it can be easy to do the
> operation of "re-order and long-term-ref"
>
> But this will depend on the policy how the slice header info is
> generated. (by app or the driver). Now this is exported by querying the
> capability of the driver. If we move this into the app, the
> infrastructure will be changed a lot.

Infrastructure of what? The application? No, it doesn't really change
anything but generating the extra packed slice header.

> Another problem is that it is possible that one frame has multiple
> slices. In such case the user should pass the multiple slice header
> info.

This is not an an issue. The API mandates that the packed headers are
provided in order.

Regards,
Gwenole.