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

[Rémi Denis-Courmont]

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.

-- 
Rémi Denis-Courmont