Moving " [PATCH 0/0] Add support for h265/HEVC video codec” to a separate thread for clarity.
> On 19 Jun 2018, at 11:50, Frediano Ziglio <fziglio@xxxxxxxxxx> wrote:
>
>>
>> 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.
Agreed. Moved to its own thread.
> The series is adding support for a codec, how the specific ranking
> and how a codec is chosen instead of another is another topic.
Yes, but that second topic becomes of interest as a result of enabling a second codec.
>
>> 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.
Agreed. But this is answering “how”. I was asking “what” we want to do.
Snir pointed out something I had not thought of, for example, which is that the ranking may not be static, it may depend on data from both client and streaming agent, e.g. to avoid picking up a combination where one side would have to degrade to a software implementation.
A solution could be to change the current enum that lists codec in order to specify, for each codec, if it’s hardware or software. Possibly something like:
diff --git a/spice/enums.h b/spice/enums.h
index 9eaf25c..c7ff5a7 100644
--- a/spice/enums.h
+++ b/spice/enums.h
@@ -163,7 +163,11 @@ typedef enum SpiceVideoCodecType {
SPICE_VIDEO_CODEC_TYPE_H264,
SPICE_VIDEO_CODEC_TYPE_VP9,
- SPICE_VIDEO_CODEC_TYPE_ENUM_END
+ SPICE_VIDEO_CODEC_TYPE_ENUM_END,
+
+ // Add this flag if the codec is implemented in hardware
+ SPICE_VIDEO_CODEC_TYPE_HW = (1 << 30)
+
} SpiceVideoCodecType;
typedef enum SpiceStreamFlags {
That would solve that specific issue. Then we could simply rank the enum in order of “general preference for SPICE”, and pick the highest one that exists on both ends. Does that seem reasonable?
> At the moment the stream device protocol can send the list of supported codec
> to the streaming agent without any ranking.
Yes.
>
>> 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.
I assume you refer to dcc_update_preferred_video_codecs?
>
>>
>>>
>>> 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