[FFmpeg-devel] [PATCH] Use file protocol to deal with bogus protocol strings
Sat Sep 29 17:08:56 CEST 2007
On date Friday 2007-09-28 12:04:06 +0200, Stefano Sabatini encoded:
> On date Friday 2007-09-28 10:48:26 +0200, Reimar D?ffinger encoded:
> > Hello,
> > On Thu, Sep 27, 2007 at 11:13:32PM +0200, Luca Barbato wrote:
> > > Stefano Sabatini wrote:
> > > > Another (maybe cleaner) solution would be to request the user to
> > > > specify the protocol string for ambiguos files such as foo:movie.mpeg,
> > > > which should then be specified as file:foo:movie.mpeg. Anyway in this
> > > > case ffmpeg should say something if it can't recognize the protocol
> > > > (for example: unrecognized protocol: foo), rather than simply negate
> > > > the existence of the file.
> > >
> > > what about enforcing the "://" separator?
> > I must somehow have missed the whole issue... Why wouldn't someone who
> > want to use such filenames specify them as
> > file://file...
> > for relative and
> > file:///path...
> > for absolute path like it is done almost everywhere else?
> > Or is that not supported by ffmpeg yet?
> no, actually in libavutil/file.c there is:
> static int file_open(URLContext *h, const char *filename, int flags)
> int access;
> int fd;
> av_strstart(filename, "file:", &filename);
> so file://foo.avi
> doesn't make ffmpeg use the file protocol, while
> does it.
> With the attached patch I'm changing this behaviour, favouring the
> file://foo.avi approach.
> Note that in this way a file such as:
> is still interpreted using the file protocol (while foo://movie.avi fails).
I'm reattaching the patch: yes it should be splitted, at first
introducing the av_find_protocol_by_name function.
If this approach is acceptable I can proceed with the first one.
Linux user number 337176 (see http://counter.li.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3205 bytes
Desc: not available
More information about the ffmpeg-devel