[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