[vlc-devel] [PATCH] taglib: Enable caching on the IOStream

Thomas Guillem thomas at gllm.fr
Mon Oct 14 14:08:22 CEST 2019


On Mon, Oct 14, 2019, at 13:48, Rémi Denis-Courmont wrote:
> Hi,
> 
> TagLib has its issues, but *this* is not a problem with TagLib. In fact, it's not specific to preparsing at all. The problem was already raised for regular playback several times here and on Trac. Nor is it a problem with the 2 cache filters. Prefetch does not read too much: it *specifically* reads whatever is available, which by definition cannot be too much.
> 
> It's a problem with bad access plugins that don't abide by the stream semantics. I don't think that there's a way to work around that without fixing the faulty plugins. At least, no solutions were suggested and not disproven in past discussions.

Which one ? I don't the problem with our access plugins.

> 
> Likewise for multitrack, you can't fix it by adding it in prefetch. The only efficient way to do multitrack over the network is to open multiple concurrent sessions, so you don't need to seek.
> 
> Le 14 octobre 2019 14:27:38 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>> 
>> On Mon, Oct 14, 2019, at 13:15, Rémi Denis-Courmont wrote:
>>> Hi,
>>> 
>>> Using cache only essentially optimises for half-assed plugins that don't implement streaming like the libsmbclient-based one, but *breaks* slow bandwidth inputs even with properly implemented plugins like HTTP or FTP, which require prefetch.
>>> 
>>> I don't think we should optimise for bugs if it means breaking something else.
>> 
>> I see the problem with "cache", it will very often read more than needed.
>> "prefetch" will also read a little more than needed. During a very small time while the meta parser is parsing, the prefetch thread will continue to read (but it will be likely less extra read than "cache").
>> 
>> Also, we have an issue with taglib, it will seek back and forth in an non optimized way. That is why "cache" could be useful here since it caches more than one "tracks".
>> 
>> I see 3 solutions:
>>  - 1/ the "prefetch" plugin could handle more than one "tracks" like "cache" plugin is doing.
>>  - 2/ Add more parameters to the "cache" plugin, like "prefetch", have a way to setup the read_atone, and maybe set it to 0 for our taglib case.
>>  - 3/ Improve taglib
>> 
>>> Le 10 octobre 2019 16:54:59 GMT+03:00, "Hugo Beauzée-Luyssen" <hugo at beauzee.fr> a écrit :
>>>> We can't use vlc_stream_NewURL as it will include the skiptags filter modules/meta_engine/taglib.cpp | 3 +++
>>>>  1 file changed, 3 insertions(+)
>>>> 
>>>> diff --git a/modules/meta_engine/taglib.cpp b/modules/meta_engine/taglib.cpp
>>>> index c71a66ca58..2826a7d85c 100644
>>>> --- a/modules/meta_engine/taglib.cpp
>>>> +++ b/modules/meta_engine/taglib.cpp
>>>> @@ -842,6 +842,9 @@ static int ReadMeta( vlc_object_t* p_this)
>>>>      free( psz_uri );
>>>>      if( p_stream == NULL )
>>>>          return VLC_EGENERIC;
>>>> +    stream_t* p_filter = vlc_stream_FilterNew( p_stream, "cache" );
>>>> +    if( p_filter )
>>>> +        p_stream = p_filter;
>>>>  
>>>>      VlcIostream s( p_stream );
>>>>      f = FileRef( &s );
>>> 
>>> -- 
>>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. 
>>> _______________________________________________
>>> vlc-devel mailing list
>>> To unsubscribe or modify your subscription options:
>>> https://mailman.videolan.org/listinfo/vlc-devel
>> 
> 
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20191014/db1dd4f6/attachment.html>


More information about the vlc-devel mailing list