[vlc-devel] [PATCH] prefetch: reading while paused is valable
remi at remlab.net
Tue Nov 19 15:46:42 CET 2019
What would be the point in notifying the accesses and stream filter of pause if it has no implications? For the third time, the *whole* point is to notify that the data flow is suspended.
Le 19 novembre 2019 14:22:40 GMT+02:00, Alexandre Janniaux <ajanni at videolabs.io> a écrit :
>On Tue, Nov 19, 2019 at 10:43:27AM +0200, Rémi Denis-Courmont wrote:
>> The point is that pause/resume was added because some accesses needed
>it, and they don't expect data to flow during pause.
>Ok, this is clearer for my previous questions, thank you.
>Can't this be reversed so that accesses can signal they expect data to
>not flow during pause, and so it works for most use case without edge
>case and we handle the other case separately?
>It seems that there is already a can_pause for those cases, so it is
>already more or less close to this as far as I can read.
>Then there are also filters changing this can_pause to true, like es
>timeshift. So if I take your point, the issue with what I said
>previously is that in this case, we don't really know what we can
>really do in pause state and it is mostly used for the UI to know
>whether the input is pausable or not?
>> Furthermore, we can't allow reading during pause as it breaks live
>streaming. Otherwise, you'd get a huge hysteresis on pause/resume as
>you'd fill the buffer on pause and drain it on resume.
>This part concerns specifically the prefetch filter right? Is it
>because of this hystereris that you're saying this patch is wrong?
>In this case, should frame-by-frame be a different state than pause?
>> Le 18 novembre 2019 23:27:26 GMT+02:00, Alexandre Janniaux
><ajanni at videolabs.io> a écrit :
>> >On Mon, Nov 18, 2019 at 10:07:22PM +0200, Rémi Denis-Courmont wrote:
>> >> Le maanantaina 18. marraskuuta 2019, 19.13.03 EET Alexandre
>> >a écrit :
>> >> > Hi,
>> >> >
>> >> > On Mon, Nov 18, 2019 at 05:56:43PM +0200, Rémi Denis-Courmont
>> >> > > I don't see how the error message is wrong. It is not
>> >to read
>> >> > > from a paused stream, by definition. This patch looks wrong to
>> >> > The concept of a playback pipeline being paused is fairly simple
>> >> > considering the user point of view, but from the internal point
>> >> > view I would have expected that pause is just relative to
>> >> > playback itself, not everything before which would be paced by
>> >> > pool of available resources.
>> >> The concept of pause is easy. Data does not flow during pause.
>> >are no
>> >> other reasons why pause was exposed to stream filters and accesses
>> >the first
>> >> place.
>> >Sure, I hear that, it is not really a hint about why though.
>> >I should have phrase my sentence like the following:
>> >If we want data to not flow during pause, it can be achieved
>> >by two effects:
>> >+ we don't process data anymore, the whole pipeline is
>> >+ we don't switch the last frame / don't display audio, the
>> >pipeline process is stalled because paced.
>> >What Thomas is doing is the second one in this patch. I
>> >tested it and it allows seeking while pausing and brings a
>> >better UX.
>> >The two questions then:
>> >+ if we keep doing the first, how pause should be handled to
>> >allow frame by frame ?
>> >+ if we're going for the second, what are the setbacks?
>> >Do you have any hints with regards to these ?
>> >Alexandre Janniaux
>> >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:
>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