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

[Filip Roséen]

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.

It is also worth-while noting that the fragment data is extracted from the
MRL when an accessor is created, it is not part of the accessors psz_url,
psz_location, or other relevant data-member (visible to a demuxer, if any).

> I don´t know if there is code that assumes (Lib)VLC never generates URLs with 
> fragment in general. And I don´t know if there is code that relies on that 
> assumption while prepending a hash and a chapter or title range.

If there is code that assumes that (lib)vlc does not generate URLs with
fragments it is relying on a promise vlc has not guaranteed; does it not?

> I don´t think we can determine that. The only question is whether you want to 
> ignore that possibility and change the behaviour in incompatible ways 
> (admittedly, it wouldn't be the first nor the last time we do that, cough 
> cough).

I would like to be able to have a working solution to the problem, and as
it seems we have exhausted other options the drawbacks associated with this
implementation are relatively minor.

Dealing with a future standardization (regarding what we discussed earlier)
is of course an issue, but deprecating a feature in favor of a new is not
the first (and probably not the last) in terms of the codebase's history.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160802/24ba09ce/attachment.html>