[Spice-devel] [spice-server v6 7/9] reds: drop sscanf() in favour of g_strsplit()

Frediano Ziglio fziglio at redhat.com
Thu Feb 2 09:45:28 UTC 2017


> 
> On Wed, Feb 01, 2017 at 01:39:26PM +0100, Victor Toso wrote:
> > Hi,
> > 
> > On Tue, Jan 31, 2017 at 03:54:01PM +0100, Christophe Fergeau wrote:
> > > On Tue, Jan 31, 2017 at 07:16:04AM -0500, Frediano Ziglio wrote:
> > > > >
> > > > > From: Victor Toso <me at victortoso.com>
> > > > >
> > > > > As there is a need to iterate over every encoder:codec pair and we
> > > > > do a check for every encoder and every codec, g_strsplit() is less
> > > > > complex and easier to follow.
> > > > >
> > > > > This change makes much easier to extend the input which is
> > > > > currently a list of tuples encoder:video-codec.
> > > > >
> > > > > Signed-off-by: Victor Toso <victortoso at redhat.com>
> > > >
> > > > I had a though this morning about the syntax.
> > > >
> > > > We are moving from a set or "encoder:codec" separated with ";" to a
> > > > set of "encoder:codec:priority". All this to allow same priority in
> > > > the list. Why not having a "light" separator, something like
> > > >
> > > > "gstreamer:vp8 gstreamer:h264;gstreamer:h264;spice:mjpeg"
> > > >
> > > > (not the space). So the first 2 will have same "priority" while the
> > > > others less (but different) ?
> > >
> > > Do we need to have an extra-smart string-based syntax like this? Or
> > > can we side-step this problem by having a higher-level API?
> > 
> > Indeed, if it gets too complex, an extra API would be better.
> > If we agree in having an extra API, we can drop this patch but
> > suggestions for the API are welcome :)
> 
> My plan was all along to figure out the API while adding support for
> this in QEMU/libvirt, but I never got to it. So no idea :)
> 
> Christophe
> 

Something like


typedef struct SpiceCodec {
   const char *encoder;
   const char *codec;
   uint8_t priority;
} SpiceCodec;

int spice_server_set_video_codecs(SpiceServer *reds,
                                  const SpiceCodecs *codecs, unsigned num_codecs);


Qemu is quite command line friendly so having a string as Victor
proposed is not that terrible.

libvirt is building Qemu command line from an XML file so it could be not
a string but a structure like

   <video-codecs>
     <video-codec>
       <encoder>gstreamer</encoder>
       <codec>mjpeg</codec>
       <priority>1</priority>
     </video-codec>
   </video-codecs>

but still would have to build something for Qemu, maybe a multiple argument like
  -qxl-video-codec gstreamer:vp8:1 -qxl-video-codec gstreamer:mjpeg:1
(or some options for qxl)

Recently I was working on OpenSSL and the cipher suite string, the
string is flexible but the parsing/filtering/ordering is possibly
quite complicated (https://linux.die.net/man/1/ciphers).

Frediano


More information about the Spice-devel mailing list