<p>Hi Remi,</p>
<p>On 16/08/02 20:12, remi@remlab.net wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>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.</code></pre>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>Below are the two reads that I think are most relevant to the on-going discussion.</p>
<ul>
<li>https://bugzilla.mozilla.org/show_bug.cgi?id=132008</li>
<li>https://www.w3.org/TR/media-frags/</li>
</ul>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>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.</code></pre>
</blockquote>
<pre><code>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.</code></pre>
</blockquote>
<p>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.</p>
<ul>
<li>What do you mean when you say that it <em>“changes the representation”</em>, and;</li>
<li>how does this relate to accessing a <em>secondary-resource</em> (which is what fragments are about)?</li>
</ul>
<p>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.</p>
<p>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).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>- 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.</code></pre>
</blockquote>
<p>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.</p>
<p>Even though I am still not satisfied with the name, <code>vlc_stream_CreateFragmentedMRL</code> allows implementations to safely append another entity without having to worry about the current state (which is the exact purpose of having the function).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>I don't see anything bad in the proposed solution, tbh: It does not add
much overhead and the code is quite well documented.</code></pre>
</blockquote>
<pre><code>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.</code></pre>
</blockquote>
<p>Given that we only respect the start-time in what is indirectly called from <code>input_Create</code> and <code>input_CreatePreparser</code>, I do not see how this is an issue.</p>
<p>The below linked patch uses the new functionality to properly propagate such information from the stream-fragments data, to the start-time:</p>
<ul>
<li>https://mailman.videolan.org/pipermail/vlc-devel/2016-July/108862.html</li>
</ul>
<p>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).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>I do not know the full impact, and within VLC, it is fixable but sounds tricky.</code></pre>
</blockquote>
<p>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.</p>
<p>There is always a possibility of me missing something, and help on the matter is (as I always say); much appreciated!</p>