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 _______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
