[vlc-devel] [PATCHv3 6/7] lib: media: copy the input item

Thomas Guillem thomas at gllm.fr
Wed Sep 30 10:05:46 CEST 2020



On Tue, Sep 29, 2020, at 17:27, Rémi Denis-Courmont wrote:
> Le tiistaina 29. syyskuuta 2020, 11.10.04 EEST Thomas Guillem a écrit :
> > > > -    return libvlc_media_attach_input_item( p_md, p_input_item );
> > > > +    input_item_t *p_item_copy = input_item_Copy( p_input_item, NULL );
> > > > +    if( p_item_copy != NULL )
> > > > +        return libvlc_media_attach_input_item( p_md, p_item_copy );
> > > > +    return NULL;
> > > 
> > > Won't that "unshare" item updates from parsing and from playing?
> > > If so, is that expected by apps?
> > 
> > Yes it will, but only for copy of medias.
> > 
> > If you create a media, play or preparse it, you will get updates.
> 
> That sounds like a regression? I'd expect updates to be shared between 
> preparsers, media players and, if that's where the item comes from, SD. At 
> least that's how it always worked. While it has its downsides, I suspect that 
> the opposite approach will turn out worse.

It's still the case, except for SD (but we don't have any modules that are updating items).

The user create media1, parse it, play it, play it again, parse it again. This will be a single media referencing a single item and the user will be able to receive all updates from every playback/preparser.

The user create directory_media, play it. The user will receive new child medias, that will reference a copy of the item sent by demuxers. One could say there is an issue in that case, but no. Indeed, demuxers, stream_filters always forget the items they send via ES_OUT_POST_SUBNODE, so there is no problem of missing update in that case.

User1 create one media1, play it, then duplicate it into media2 and pass it to User2. If User2 play media2, you don't want the User1 to receive updates from it. This patch set is also fixing this problem (but it could also be fixed independently of this patch set). 

> 
> I don't really understand why you copy items.

In order to have an immutable owner. Copy is not mandatory, I could also change owner on the fly. It could work if we assert that VLCCore should not attach any owner (in that case, we rename owner to libvlc_owner).

> 
> -- 
> レミ・デニ-クールモン
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list