On 11/29/18 9:47 PM, Nicolas George wrote:
Andrey Semashev (2018-11-29):
It does. avformat_open_input, avio_open and ffurl_open[_whitelist] docs all
say it's an URL and they don't perform any conversion. So the file backend
should be prepared to receive a URL, with a scheme and authority.
So either the docs are slightly wrong or the code is. Do you have an
argument to decide it is one rather than the other?
I do:
It will probably currently fail because of the escape sequence.
Exactly. Since escaping, a very basic feature of URIs, is not handled at
all, it is a clear indication that the paths are NOT meant to be
considered URIs. The documentation was added much later, and made the
same mistake you are doing now; same goes for a few private function
names.
I condider the lack of support for escape sequences a bug, which is
probably a rudiment of the past, when ffmpeg was primarily targeted for
working with local files. The fact that all these functions also accept
raw filesystem paths instead of URIs is also there for the same reason,
only with additional benefit of convenience. Nowdays, there is one
common interface for interacting with ffmpeg, and this interface is URIs
(or raw local paths). There is no third pseudo-URI option, AFAICT. So,
in my humble opinion the docs are correct, it is the implementation that
needs to catch up.
Escape sequences, if needed, can be fixed separately.
That would break a lot of working applications and is therefore not a
good idea.
If an application passes a URI and expects that it is not interpreted as
such is already broken. I could make a patch adding support for escape
sequences as well, but it seems you would not accept it. Am I correct?
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
