Hi, 2014-05-12 3:34 GMT+02:00 Zhao Yakui <yakui.z...@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. _______________________________________________ Libva mailing list Libva@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libva