[vlc-devel] [PATCH] fps: clone the extra pictures we send
robux4 at ycbcr.xyz
Wed Oct 7 09:24:55 CEST 2020
On 2020-10-07 7:41, Steve Lhomme wrote:
> On 2020-10-06 16:40, Rémi Denis-Courmont wrote:
>> Le tiistaina 6. lokakuuta 2020, 15.08.35 EEST Steve Lhomme a écrit :
>>> On 2020-10-06 13:53, Steve Lhomme wrote:
>>>> The same picture is supposed to be filtered or rendered at a different
>>>> date, but the source pixels should be the same. The content is not
>>>> to be changed in the pictures we output from this filter. Even blenders
>>>> take care of this in their source picture to avoid modifying pictures
>>>> used by the decoder as reference frames.
>>> It means we can use the fps even for GPU sources.
>> We can already do that. picture_Copy() calls picture_CopyPixels()
>> which calls
>> the context copy callback. There's effectively no differences between
>> picture_Clone() and picture_Copy() for opaque pictures.
> And this has already been pointed out in the past that this is wrong. A
> clone and a copy are not the same for CPU pictures. It must not be the
> same for GPU pictures.
> And doing a copy here is also the wrong thing to do.
BTW, using picture_Copy is almost never a good idea. One of the rare
case where it makes sense is to blend subpictures into a source picture.
While it makes sense to do it on a picture coming out of a decoder,
since the pixels may be used as reference for other pictures, it makes
less sense for a picture coming from a video filter (but maybe not on
To avoid unnecessary copies we could introduce the concept of
mutable/immutable pictures. An immutable picture is a picture where
you're not allowed to touch the pixels. A mutable picture is a picture
where you can modify the pixels. A decoder would (usually) output
immutable pictures and a video filter would (usually) output mutable
Getting a mutable picture from another picture would either do a pixel
copy, if the source is immutable, and just provide a clone of the source
if is mutable.
More information about the vlc-devel