[vlc-devel] [PATCH 02/21] input/stream: stream-fragments: add initial documentation
filip at atch.se
Tue Aug 2 21:58:17 CEST 2016
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
> 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
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...
More information about the vlc-devel