[vlc-devel] [PATCH] prefetch: reading while paused is valable

[Alexandre Janniaux]

Hi,

On Tue, Nov 19, 2019 at 10:43:27AM +0200, Rémi Denis-Courmont wrote:
> Hi,
>
> 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?

Regards,
--
Alexandre Janniaux
Videolabs

>
> Le 18 novembre 2019 23:27:26 GMT+02:00, Alexandre Janniaux <ajanni at videolabs.io> a écrit :
> >Hi,
> >
> >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 Janniaux
> >a écrit :
> >> > Hi,
> >> >
> >> > On Mon, Nov 18, 2019 at 05:56:43PM +0200, Rémi Denis-Courmont
> >wrote:
> >> > > I don't see how the error message is wrong. It is not permissible
> >to read
> >> > > from a paused stream, by definition. This patch looks wrong to
> >me.
> >> > The concept of a playback pipeline being paused is fairly simple
> >> > considering the user point of view, but from the internal point of
> >> > view I would have expected that pause is just relative to
> >audio/video
> >> > playback itself, not everything before which would be paced by the
> >> > pool of available resources.
> >>
> >> The concept of pause is easy. Data does not flow during pause. There
> >are no
> >> other reasons why pause was exposed to stream filters and accesses in
> >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
> >freezed.
> >+ 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 ?
> >
> >Regards,
> >--
> >Alexandre Janniaux
> >Videolabs
> >_______________________________________________
> >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