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

[Filip Roséen]

Hi Remi,

On 16/08/02 20:12, remi at remlab.net wrote:

> It wouldn't violate existing specs to the extent that I am aware.
> However, support for files within archives in URLs is desirable not
> only in VLC. It has been asked in Mozilla and elsewhere. It has been
> considered for standardization (at least by WHATWG), and maybe still
> is.
> 
> The risk of conflict with a future standard, or defacto standard by
> sole other application is therefore much higher than for the existing
> title/chapter fragment usage.

The risk of conflicting with any future standard is there in either case
given that we already store the MRLSections in the fragment, behavior
introduced in 8693bcb2.

I have been reading up on the discussions related to standardizing both
extraction of entities within archives, but also other future and current
standardizations of media-related fragments.

Below are the two reads that I think are most relevant to the on-going
discussion.

  - https://bugzilla.mozilla.org/show_bug.cgi?id=132008
  - https://www.w3.org/TR/media-frags/

> > I'm quite sure we said that we should use the fragments to define the
> > subfiles inside the archive. And that we could recurse if we encode the
> > "#" in it, to have a .zip in a .rar in an iso on a smb share.
> 
> Without a standard on fragment within archives, it might be
> problematic in the future. It is also wrong in some ways:
> - Because it changes the representation of the resource, it should be
> passed to the authority and caches. Fragments are not passed that way.
> That is hopefully inconsequential in VLC now, though I do not know for
> sure.

As the relevant RFCs describe, the purpose of a fragment is to not bother
the authority with this kind of information; it is to be dealt with in the
user-agent.

  - What do you mean when you say that it *"changes the representation"*,
    and;
  - how does this relate to accessing a *secondary-resource* (which is what
    fragments are about)? 

Yes, the future of such standardization is still untold; but waiting for a
standardization when it is a problem we have to deal with at the current
time is in my opinion unwise.

When, if ever, a standardization comes through that should of course be
favored.. but at the current time there is no standardization, and what we
are doing is not in violation of any standardization currently in practice
(as far as I know).

> - It changes the way the "final" downstream fragment is coded. We can
> no longer simply append a hash sign and the existing title/chapter
> syntax to the location.

I really hope we do not have such usage within the code-base given that it
is a pretty much direct way to mess things up in one way or another.

Even though I am still not satisfied with the name,
`vlc_stream_CreateFragmentedMRL` allows implementations to safely append
another entity without having to worry about the current state (which is
the exact purpose of having the function).

> > I don't see anything bad in the proposed solution, tbh: It does not add
> > much overhead and the code is quite well documented.
> 
> In addition, because the fragment affects the stream_t, not just the
> start time, the result will be totally wrong in any code path not
> preserving the fragments.

Given that we only respect the start-time in what is indirectly called from
`input_Create` and `input_CreatePreparser`, I do not see how this is an
issue.

The below linked patch uses the new functionality to properly propagate
such information from the stream-fragments data, to the start-time:

  - https://mailman.videolan.org/pipermail/vlc-devel/2016-July/108862.html

Any code-path not preserving the fragments should not occur given that the
fragments are parsed when creating an access, and store inside the access
(and any subsequent stream-filters that might be appended afterwards).

> I do not know the full impact, and within VLC, it is fixable but sounds tricky.

I must admit that I have spent a lot of time researching the code-base in
order to do by best to verify that the new functionality is introduced in a
matter which is safe and without misbehavior.

There is always a possibility of me missing something, and help on the
matter is (as I always say); much appreciated!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160802/388da243/attachment.html>