Re: [PATCH 0/0] Add support for h265/HEVC video codec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> Hi,
> 
> 
> On 06/18/2018 05:27 PM, Christophe de Dinechin wrote:
> > As a follow up to the question I asked during the weekly meeting, what is
> > the plan for selecting between codecs?
> >
> > Easy case: client and agent have only one shared codec combination. We have
> > to pick that one.
> >
> > More complicatwed: say both sides support h264, vp9 and h265. Which one do
> > we pick?
> >
> > Right now, the only ranking I am aware of occurs in the agent, and based on
> > existing code and earlier discussions with Frediano, it’s not clear if we
> > want to use that ranking to sort codecs. It’s designed to sort plugins,
> > not codecs. It would be easy to tweak it to rank h265 higher than h264,
> > though.
> >
> > Thoughts?
> 

First I think that this discussion is OT in respect to the series.
The series is adding support for a codec, how the specific ranking
and how a codec is chosen instead of another is another topic.

> I think we should pick it according to the rank that the was given to
> the plugin (by the plugin author).
> The reason for it is that the one who wrote the plugin is the only one
> who can assess its quality.
> 

Looking all around the client can send his preference using preferred_video_codec_type
message. The streaming agent plugins have their rank based on codecs.
At the moment the stream device protocol can send the list of supported codec
to the streaming agent without any ranking.

> For example i would assume it's better to pick our nvidia h264 plugin
> (hw) than a gstreamer based
> plugin that uses gstreamer's nvenc with h265 (also hw), since although
> its h265 our nvidia plugin
> works much better and should be more stable than gstreamer's nvenc based
> plugin.
> iirc it is similar to the way gstreamer's rank its plugins. (and
> probably changing forcing a plugin or
> let the define different rank somehow could be nice).
> 
> BTW- gst-plugin is currently does not register each one of the possible
> codecs plugin's, the codec is
> picked by the user and registered with that pick .
> 
> Snir.
> 

There is some ranking code in spice-server for the codec to use for streaming
in QXL.

> 
> >
> > Christophe
> >
> >
> >> On 18 Jun 2018, at 11:20, Snir Sheriber <ssheribe@xxxxxxxxxx> wrote:
> >>
> >> This series adds support in h265 protocol to spice (intended for
> >> stream-channel streams)
> >>
> >> spice-common was also updated but bumping it in the other components
> >> and changing its required spice-protocol version does not seem necessary
> >>
> >> changed:
> >> spice-server
> >> spice-protocol
> >> spice-common
> >> spice-gtk
> >>
> >>

Frediano
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux Virtualization]     [Linux Virtualization]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]