[vlc-devel] [PATCH 02/21] input/stream: stream-fragments: add initial documentation

[Rémi Denis-Courmont]

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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/