[vlc-devel] [PATCH] fps: clone the extra pictures we send

[Steve Lhomme]

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 
>>>> going
>>>> 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 
deinterlacers).

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 
pictures.

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.