[Libva] (H264) Reference Picture selection

Yuan, Feng feng.yuan at intel.com
Sun May 11 19:56:07 PDT 2014



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/soft
>w
>> >a
>> >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.

If app queried, driver could tell it supports both. Driver keeps current infrastructure to generate slice_header for most use cases. And probably add another logic to generate slice_data and just copy slice_header from app (advanced usage). This should be similar like decoder. But certainly, need lots efforts and libva interface may do small changes too.

>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.

Yes. Compare to slice_data, slice_header should be very small. 

Thanks
Wind


More information about the Libva mailing list