[vlc-devel] [PATCH] dvdnav: add Demux submodule
thomas at gllm.fr
Wed Mar 18 17:38:57 CET 2015
On Wed, Mar 18, 2015, at 16:35, Rémi Denis-Courmont wrote:
> Le 2015-03-18 01:46, Luca Barbato a écrit :
> >> I mean it locks up if the stream read does not return (in any
> >> reasonable time
> >> frame), in other words if you have a (long) blocking read. That
> >> situation is
> >> not possible for a regular file. Regular file I/O is never blocking:
> >> it either
> >> completes or fails straight away.
> > And access doesn't have tunable timeouts with poll so the problem
> > gets quite substantial.
> I fail to see how a time-out would help here. There are two things that
> you absolutely want to avoid:
> 1) getting stuck permanently even if the user tries to stop, and
> 2) reading large chunks of data at once, that might block the input
> thread for too long, leading to buffering and UI problems.
> The first problem requires a solution at the access level. This is
> already solved for native VLC plugins using net_Read(). But this was
> knowingly and conveniently ignored by the multiple authors of remote
> file system using third party libraries, as well as RTSP/live555 and
> AVIO. Agreeably, this problem is in no way specific to optical disc
> The second problem requires a solution at the demux level. The proper
> solution is to set pf_demux to NULL and perform all I/O in a separate
> thread. The "compromise" solution consists of reading only "small"
> chunks of data and returning from pf_demux in-between. DVD and BD
> parsers fail miserably here because that was never a problem with
> regular files and local drives.
I modified my patch to deactivate the readahead if we are using the
stream callbacks. I checked, each pf_demux read 2kB. Is it small enough
? If it's not OK, I'll go for the thread way.
Thank you for the explanation.
> Rémi Denis-Courmont
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel