Hi, On Tue, Dec 20, 2016 at 10:18:48AM +0100, Christophe Fergeau wrote: > On Tue, Dec 20, 2016 at 09:18:45AM +0100, Victor Toso wrote: > > On Wed, Dec 14, 2016 at 05:23:28PM +0100, Christophe Fergeau wrote: > > > > > > My main problem with introducing the priority now is that we have > > > potential uses for it in the future, but I don't think we have users for > > > it right now. So maybe it will be the right thing to do when these > > > potential uses materialize, maybe we will want to approach things > > > differently. > > > > I agree that we might want to handle things differently in the future > > but I don't see why this would limit it to have it now and improve it > > later. > > The reason why I'm being conservative here is that as soon as you expose > this as an admin setting which can be tweaked externally, then it > becomes ABI. And I'm not really comfortable with setting in stone an ABI > for which we don't have a user at the moment. > > Christophe
I still think this was already introduced and we are only trying to improve it :) But fine. Before I split it up, what should be the expected behavior when a preferred video-codec message is received? Trying to come up with a simple example: Host has (before client's message) spice:mjpeg - gstreamer:mjpeg - gstreamer:vp8 - gstreamer:h264 Client sends: vp8, h264, mjpeg Possible results: 1) Client has preference: gstreamer:vp8 - gstreamer:h264 - spice:mjpeg - gstreamer:mjpeg 2) Client is ignored: spice:mjpeg - gstreamer:mjpeg - gstreamer:vp8 - gstreamer:h264 In (1), Admin must remove encoder:video-codec that he does not want to be used. In (2), we might need something else that I can see to make this useful without the priority part. Maybe a runtime flag for testing purposes only... SPICE_ENABLE_PREFERRED_VIDEO_CODEC or something. Thanks, toso
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
