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

[Filip Roséen]

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
upon.

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
-------------------------------------------------------------------------

    http://localhost/foo.zip
     |
     '- 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>