[Spice-devel] [spice-server v2 8/9] reds: add support to ranks for video codecs

[Victor Toso]

Hi,

Thanks again for your feedback.

On Tue, Dec 13, 2016 at 08:06:50PM +0100, Francois Gouget wrote:
> So your complexity objection is about the format in which to send the
> client's codec preferences to the server: you want to send it as an
> array rather than as a single string.

No. "gstreamer" is not a video-codec, it is an *encoder*. Client-side
should not care about it. The client having to now the *encoders* to put
it in the same format that current spice-server parses is what I mean by
too complex.

A string with vide-codecs would be okay. More data, not really a
necessity but okay.

> My objection is that the client should not send codec preferences to the
> server at all and that anything else is needlessly complex.

Nowadays we have vp8, h264 and mjpeg. We can live with what we have.
In the future we will be dealing with vp8, vp9, vp10, h264, h265 and
what else might come. That's the great advantage that we got with the
gstreamer integration that you have provided :)

Needless to day that different clients might have different necessities.

I want to make it easy to have the best alternative with hw encoder and
hw decoding.

For the encoding part, host can always select what it wants but if host
does not care in providing a stream that it is in a better format for
the client, then this series will be helpful.

> [...]
> > Given the encoder:codecs we need to say, from host point of view:
> > 1-) which one is enabled/disabled
> > 2-) which one should I try to encode *first*
>
> That's exactly what the current video_codecs string does.

That's correct, but only for host-side. So, not enough for us.

> > A rank is super simple for that. Set a encoder:codec to 0 to say it is
> > disabled. If you say that default rank value is 1, any codec with higher
> > value then 1 should be tried first.
> >
> > Not sure what is the problem with rank.
>
> It's needlessly complex and does not add anything useful.

I disagree.

>
> [...]
> > Yes, there were some discussion on IRC about preference for encoding.
> > The Admin/host will have preference, always. The message about client's
> > preference will sort without changing the rank in spice-server... an
> > example is always much easier to follow:
> >
> > 1-) gstreamer:mjpeg:0;gstreamer:h264:1;gstreamer:vp8:1;spice:mjpeg:1
> >
> > -> gstreamer:mjpeg is disabled
> > -> h264, vp8, spice:mjpeg has the same rank
> >
> > 2-) client sends: vp8, mjpeg, h264
> >
> > -> array order in spice: gstreamer:vp8, spice:mjpeg, gstreamer:h264
> > -> gstreamer:mjpeg is still disabled
>
> So your example is:
>
>  1-) "gstreamer:h264;gstreamer:vp8;spice:mjpeg"
>
>   -> gstreamer:mjpeg is disabled
>   -> the server prefers h264, vp8, spice:mjpeg in that order
>
>  2-) client advertises support for vp8, mjpeg, h264
>
>   -> the server picks h264

There is some sort of confusion here. With proposal, there is an
attached value for the video-codec. So, if in (1) you say they have the
same value, the server would pick vp8 as it would prefer what clients
prefer.

Sever would pick h264 only if the rank was higher. I'll give another
example, I can see that my previous example was terrible.

1) Host sets: "gstreamer:vp8:2;gstreamer:h264:2;spice:mjpeg"
 -> gstreamer:mjpeg is disabled
 -> spice:mjpeg has default rank value 1
 -> gstreamer h264 and vp8 has rank is 2

2-) client advertises support for vp8, mjpeg, h264
 -> dup of the array, now sorted would be: video-codec (rank):
   vp8 (2), h264 (2), mjpeg (1)
 -> picks vp8

In this scenario, Admin gives high and equal preference to vp8 and h264,
maybe due hw encoding capability. Client says that prefers vp8, maybe
due hw decoding capability. VP8 is okay for both to be chosen as
preferred.

> So the only thing that ranks allow is to be able to not express a
> preference between several codecs. I just don't see the point of that.

I hope it is more clear to you now.

  toso
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20161213/c10924ce/attachment-0001.sig>