[vlc-devel] [PATCH] taglib: Enable caching on the IOStream
remi at remlab.net
Mon Oct 14 14:48:27 CEST 2019
Any access that does not do pipelining/streaming is broken if it cannot assert both low latency and high bandwidth.
This has been noted multiple times before here and on Trac.
Le 14 octobre 2019 15:08:22 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>On Mon, Oct 14, 2019, at 13:48, Rémi Denis-Courmont wrote:
>> 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:
>>>> 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
>>> I see the problem with "cache", it will very often read more than
>>> "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
>>> - 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
>>>>> 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:
>> 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:
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel