[vlc-devel] [PATCH] picture: fix missing video_format_t attributes from the picture

Rémi Denis-Courmont remi at remlab.net
Mon Oct 1 19:03:33 CEST 2018


Le maanantaina 1. lokakuuta 2018, 14.40.05 EEST Steve Lhomme a écrit :
> > We of course have the issue where a /format-change/ mid-stream will
> > result in weird behavior due to the async nature of changing the
> > associated format, and the |picture_t|-processing not matching the
> > update (applying the format to too many or too few frames). After a
> > very quick conversation with |tguillem| this is something we can and
> > will address at the /vout-workshop/, though I would like to plant this
> > seed (regarding change of type and things that might need changing)
> > here on |vlc-devel| to get as many opinions as possible prior to said
> > workshop.
> 
> IMO the picture_t.format is the one to use, precisely because it can
> change between each picture. Right now the changes have to be populated
> in the pool that creates/provides these pictures and it's a mess. Apart
> from pixels/sizes needed by the decoder everything else if probably fine
> being dynamic (in the picture). So yes, we need to clean that and come
> up with basic rules.

I have to disagree here (and more-or-less agree with Filip).

picture_t is, not like its name implies, a (reference-counted) picture buffer, 
not a "picture". A single picture buffer can have different formats at 
different points in the pipeline. For instance, the decoder may output a non-
cropped format, but a user filter may change the cropping before the *same* 
picture buffer hits the display plugin.

And because it is reference counted, the format should never be changed 
anyway. That would violate the shared-read-only principle.

If you want to clean this up, AFAICT, the only way is to remove 
picture_t.format completely, and use (mostly existing) out-of-band formats 
such as decoder_t.fmt_out.video, filter_t.video.fmt_{in,out}, 
vout_display_t.source and so on. Possibly i_visible_lines and i_visible_picth 
will need to go away as well for the same reasons.

But that's an enormous undertaking.

-- 
Реми Дёни-Курмон
http://www.remlab.net/





More information about the vlc-devel mailing list