Re: [client v2 0/5] Abstract video streaming from the network details

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

 



On Thu, 6 Apr 2017, Francois Gouget wrote:

> Currently the video decoders are directly passed network messages which 
> ties them pretty closely to the network code. Should the protocol switch 
> to a new type of messages the video decoding code will need to be 
> updated. Even worse, it will have to deal with two types of network 
> messages for backward compatiblity.
> 
> So I feel it's better to try and separate the two which is what I've 
> done in the first two patches.
> 
> The third one does not really change the code much, it just separates 
> the code that creates / destroys the display_stream objects from the 
> code that handles the network messages leading to their creation / 
> destruction.
> 
> Changes from v1:
>  * Add a patch documenting the steps each frame goes through in the 
>    GStreamer decoder, along with lifetime information.
>  * Rename SpiceMetaFrame to SpiceGstFrame.
>  * Separate renaming SpiceFrame to SpiceGstFrame from the patch removing 
>    the video decoder's dependency on SpiceMsgIn messages.
>  * Tweaked that patch to minimize changes.
>  * Fixed the type of the SpiceGstFrame.sample field.


Is this round better?


-- 
Francois Gouget <fgouget@xxxxxxxxxxxxxxx>
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




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