[vlc-devel] [PATCH] prefetch: remove read size, always request maximum
remi at remlab.net
Thu Feb 6 13:22:38 CET 2020
I don't think SMB streaming (as opposed to downloading) is a lost cause. I do think SMB streaming with libsmbclient implementation is a lost cause.
The prefetch plugin already gives maximum flexibility, within its own constraints, to the underlying access to choose how many bytes it returns in a given read, as does the core. It can't get any better without increasing the prefetch buffer size (and we have a setting for that already).
Le 6 février 2020 14:00:55 GMT+02:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>I quote you:
> "Badly behaving streams wait for the whole requested amount and do not
> perform any pipelining/buffering (e.g. CIFS, probably SFTP)."
>Why SMB, NFS, SFTP are badly behaving streams ? For me it is just like
>local I/O. You read only what you request.
>On Thu, Feb 6, 2020, at 12:28, Rémi Denis-Courmont wrote:
>> The access is free to return any non-zero size up to the requested
>read size, so the requested read size can never be too big. It can only
>ever be too small, and that's exactly why this patch made sense and
>still makes sense.
>At the VideoLabs office with 1TB network, I don't care, but at home
>with a shitty 2MB wifi, reading chunks by 16MB is terrible. Specially
>when 99% is trashed since the demuxer will only ask few kB and seek.
>> But if you need to worry about the read size, you've already lost.
>Why am I lost ? Are you saying SMB streaming is a lost cause ?
>> Small read size will cause bandwidth problems and large read size
>will cause latency problems.
>Can we find a solution for both cases in the core or the cache modules
>? I really don't see why I should cap the read size of all "badly
>If I need to do that, what size should I use ? Should I add one more
>option (likely the same that you removed in prefetch) ?
>> Le 6 février 2020 12:33:55 GMT+02:00, Thomas Guillem <thomas at gllm.fr>
>a écrit :
>>> This commit and this one on vlc-3.0 :
>are making the smb2 module ultra slow, around 10 times slower.
>>> The read size requested by prefetch is really big. This make probing
>/ seek ultra slow since a lot of small read() are executed (reproduced
>with mkv and mp4).
>>> So, I have one big question: Is the smb2 module supposed to not
>listen to the size argument and always read a smaller size ?
>>> How can I decide the read size then ? Should this size be decided by
>the core of cache modules instead (like before) ?
>>> PS: There is not the same problem with the libdsm module since the
>max read size is caped inside libdsm.
>>> On Fri, Apr 20, 2018, at 15:45, Thomas Guillem wrote:
>>>> On Fri, Apr 20, 2018, at 15:05, Rémi Denis-Courmont wrote:
>>>>> And I don't really want to hear a commit is dangerous from
>>>>> backports stuff as lightly and quickly as you have lately.
>>>> That is a bit close to false accusation IMHO.
>>>>> This was sent for review, and it was *not* backported.
>>>> Yes and I was OK with it. It's just lately that I found out that
>>>> commit might be dangerous.
>>>> Dangerous as changing the behavior of some access modules and maybe
>>>> induce some new bugs (that are access related).
>>>>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
>>>>> ma brièveté.vlc-devel mailing list
>>>>> To unsubscribe or modify your subscription options:
>>>> vlc-devel mailing list
>>>> To unsubscribe or modify your subscription options:
>>> 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