<p>Hi,</p>
<p>On 16/08/02 23:30, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>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.</code></pre>
</blockquote>
<p>Yes, I am aware of what you are describing above and I see your point.</p>
<p>Given that the current implementation of the mkv-demuxer does not currently work with things like archives in either case, nor does it do a very good job when <code>--mkv-preload-local-dir</code> is enabled, what you describe needs fixing in either case.</p>
<p>I was thinking about fixing these issues together with the patches in this patch-batch, but given the circumstances I decided not to (like I did not include the deprecation and replacement of legacy archive access/stream_filters that currently cannot be viewed as other than broken).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>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.</code></pre>
</blockquote>
<p>The impossible environment does not constitute an impossible fix in my opinion; making the art cache work with the added functionality should not be a major obstacle.</p>
<p>If the art cache needs a unique identifier for every resource, it should then include the use of fragments in a portable manner.</p>
<ul>
<li>Am I misunderstanding what you are saying, or can the new functionality be a plausible solution given some adjustments to how the art cache is implemented?</li>
</ul>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>-- 
Rémi Denis-Courmont
http://www.remlab.net/

_______________________________________________
vlc-devel mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc-devel</code></pre>
</blockquote>