[vlc-devel] [V2 09/16] input: Move attachment to input_item_t

[Hugo Beauzée-Luyssen]

On Mon, Nov 16, 2020, at 4:35 PM, Rémi Denis-Courmont wrote:
> Le lundi 16 novembre 2020, 12:13:50 EET Hugo Beauzée-Luyssen a écrit :
> > Hi,
> > 
> > On Fri, Nov 13, 2020, at 7:40 PM, Rémi Denis-Courmont wrote:
> > > Le vendredi 13 novembre 2020, 12:27:25 EET Hugo Beauzée-Luyssen a écrit :
> > > > ---
> > > > 
> > > >  include/vlc_input_item.h   |  3 +++
> > > >  src/input/input.c          | 33 +++++++++++++--------------------
> > > >  src/input/input_internal.h |  4 ----
> > > >  src/input/item.c           |  5 +++++
> > > >  4 files changed, 21 insertions(+), 24 deletions(-)
> > > 
> > > I think it was intentional to track attachment in the input rather than
> > > the
> > > item. Indeed, they can be (comparatively) large, and we really should not
> > > track many of them in memory at the same time.
> > 
> > It definitely seem that it was meant to be tracked in the input. However it
> > seems to me like it belongs more in the input_item since that's what embeds
> > the attachments,
> 
> I don't think you can determine if it belongs to the input or the input item 
> on a conceptual level. The input is essentially just an instantiation of the 
> input item, so what even would be the decisive criteria here?
> 
> The bistream is also as much a property of the input item as the attachments, 
> and yet we are obviously not going to cache the bitstream in the input item.
> 
> AFAICT, the only criteria are tradeoffs between availability, speed and memory 
> use. And I am afraid that we are potentially increasing input item size by 
> several orders of magnitude, while there can be thousands of item in a single 
> process address space...
> 
> > I don't understand the argument about the memory footprint, it's allocated
> > and held by the demux in any cases.
> 
> It does not matter who extracts the data. What matters is how long it stays 
> allocated. Meta and bitstream are also extracted by the demuxer, that's simply 
> not a criterion.
> 
> > > There is also the general problem that input items are writable, and thus
> > > ill- suited to refer to reference-counted objects.
> > 
> > I don't understand that point
> 
> Input item lock can *not* protect the attachment if the attachment can have 
> more than one references - implying that the other references would not be 
> covered by the same lock.
> 

If the attachments are not stored in the input_item, I don't believe they can be fetched through the libvlc media object.
I suppose we can still inform the users through a callback during the preparse, and let them decide to hold on to the attachment or not. Would that work for you?

-- 
  Hugo Beauzée-Luyssen
  hugo at beauzee.fr