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

Filip Roséen filip at atch.se
Tue Aug 2 19:23:01 CEST 2016

Hi Remi,

On 16/08/02 17:54, Rémi Denis-Courmont wrote:

> Le 2016-08-01 18:32, Filip Roséen a écrit :
> >These set of patches simply strengthens the relationship between MRLs
> >and URLs by saying that we do support anchors, and will treat as what
> >they are; an anchor into a secondary-resource.
> I do recall pointing out that the archive stream filter had already solved the problem,
> at least for the most part, and without changes to the core. In other words, if you want
> to embed stuff arbitrarily, you can define custom MRL schemes. IMO, it diverges from the
> principles of the URL syntax a lot less than overloading the URL fragment.

The problem with using a custom MRL scheme is that it will be very painful
to do something like what is being done in the following screenshots:

  - http://atch.se/nested_archive_http.png

In order to properly implement a solution that uses custom MRLs, the
top-accessor responsible for opening an entity must open up another
accessor in order to get the contents of the entity in which it is acting

Looking at the implementation of `modules/access/archive/*` should give
quite a clear image of what we would have to go through for every format
that allows nested entities if we do not introduce something a long the
lines of stream-fragments.

A note about stream-filters

If the accessor responsible for handling a custom MRL does not remember to
append the appropriate stream-filters associated with the aquired resource
it will lead to unexpected data to be read (not the same as if we went
through a proper access->stream_filter->demux chain).

A naive solution to the problem would be for the accessor to call
`vlc_stream_FilterNew` on the aquired resource, though;

  - how does it know what stream-filter to append?

tl;dr it cannot.

An elaborate example

     '- bar.rar
       '- movie.avi
       '- movie.srt
     '- foo.mp3

We would have a `zip-stream_filter` that generates MRLs for the entities
inside it with a custom MRL so that the appropriate `zip-access` can handle
the extraction of the relevant element:

  1. `zip://http://localhost/foo.zip!bar.rar`
  2. `zip://http://localhost/foo.zip!foo.mp3`

When you then open-up entity `(1)`, a *stream-filter* that handles `.rar`
would spit out the following (theoretical custom MRL).

  1. `rar://zip://http://localhost/foo.zip!bar.rar!movie.avi`
  2. `rar://zip://http://localhost/foo.zip!bar.rar!movie.srt`

Then, in order to open entity `(1)` from the above, the accessor-chain
would be like the below:

  [ rar access ] -> [ stream_filter* ] -> [ demux ]
   '- [ zip access ] /* feeding/owned by rar access */
       '- [ http access ] /* feeding/owned by zip access */

Given what is proposed in the patch-batch in which this email is a reply,
it would instead look like the below, allowing "inifinite" nesting of
filters in a more straight-forward manner:

    [ http access ] -> [ zip stream_filter ] -> \ 
    [ rar stream_filter ] -> [ stream_filters* ] -> [ demux ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160802/c2ca931f/attachment-0001.html>

More information about the vlc-devel mailing list