[vlc-devel] [PATCH 02/21] input/stream: stream-fragments: add initial documentation
remi at remlab.net
Tue Aug 2 22:30:51 CEST 2016
Le tiistaina 2. elokuuta 2016, 21.58.17 EEST Filip Roséen a écrit :
> Hi Remi,
> First of all I would like to thank you for taking time to discuss this
> issue. I hope that we can reach a consensus and a solution to the given
> problem since I seem to have a fetish for playing nested entities (as shown
> by earlier screenshots).
> Maybe I should seek help or that... `;-)`
> On 16/08/02 22:29, Rémi Denis-Courmont wrote:
> > Now if you have a filter downstream of the ZIP filter (that handles the
> > fragment) and upstream of the final demuxer, it can reasonably expect that
> > identical fragment-less URL leads to identical resource and representation
> > thereof.
> > ArtCacheGetDirPath() is an existing embodiment. There may be others.
> But the final demuxer should not care about where the currently processed
> resource is located; it shall only cares about the data it receives, and
> indirectly the data it spits out.
I agree in principles. But on the one hand, that is not my point. And on the
other hand, the fact of the matter is that avformat and MKV demuxers do
manipulate their URL.
The art cache treats the URL is a unique identifier. So far this works because
the fragment does not affect the resource per se. Your patchset creates an
impossible environment whereby the fragment may need to be included or
excluded from the URL to constitute a unique identifier, in a manner that is
not reasonably predictable for the art cache.
More information about the vlc-devel