[MPlayer-dev-eng] [PATCH] demux_lavf: add urlprefix suboption.

[Nicolas George]

Le decadi 20 germinal, an CCXXI, Reimar Döffinger a écrit :
> I don't see a point in making it configurable.

The idea was to be sure not to risk breaking anything unless the user wants
to risk it.

> In addition don't we already remove the prefix in cases where we know we
> have to?

As far as I can see, the prefix is only removed when the URL is prefixed
with "ffmpeg://" (and that prefix is trimmed too).

> The idea behind it was that libavformat would call back to the stream
> layer so that caching, stream dumping etc. would be working.

That would be nice indeed, but it applies only to "real" A-V muxing formats,
when packets are demuxed from a single file / byte stream.

For formats that use several files, it makes less sense: what would stream
dump mean for example? If the format uses external references (Matroska
segment linking) or is a kind of playlist, stream dump would require
rewriting the file to change the file names: unreasonable.

Also, remember that Anton made av_register_protocol2() private about two
years ago: there is no chance of implementing the "mp:" protocol without
dropping support for libav and/or shared linking.

> Unfortunately quite a few demuxers nowadays are designed after the
> principle "who needs such things as caches or proper layering in
> software", so that is probably unrealistic, but I don't like too much
> hacks that both will not work automatically nor encourage better design.

I am afraid "proper layering" is rather hopeless when it comes to A-V
formats with advanced features.

Cache is indeed useful. I wonder whether it would not be more efficient to
implement the cache after the demuxer: cache demuxed packets instead of
caching muxed bytes. I do not know whether MPlayer currently supports that.

> That said if you want it, I'd suggest a bool option described something
> like "allow FFmpeg to access file directly". I admit I didn't think it
> through too well though.

If there is no advert effect, since the "mp:" protocol will never come, just
removing the prefix would be even simpler.

(Note: I just noticed that the use case I had in mind will work well just now
because the file is always played from the current directory, and therefore
the "mp:" prefix is considered part of the file name, not the base path. But
getting it to work without that lucky happenstance would be better.)

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130429/76ba8221/attachment.asc>