On 11/29/18 10:16 PM, Nicolas George wrote:
Andrey Semashev (2018-11-29):
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
Andrey Semashev (2018-11-29):
>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
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
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
On 11/29/18 9:24 PM, Nicolas George wrote:
Andrey Semashev (2018-11-29):
Previously, URIs with authority field were incorrectly interpreted as if
the authority was part of the path.
The "file:" prefix does not indicate a file:// URI but a path for the
file: protocol of FFmpeg.
It does.
Andrey Semashev (2018-11-29):
> Previously, URIs with authority field were incorrectly interpreted as if
> the authority was part of the path.
The "file:" prefix does not indicate a file:// URI but a path for the
file: protocol of FFmpeg.
You can check by yourself that they are not URIs by
Previously, URIs with authority field were incorrectly interpreted as if
the authority was part of the path. This commit adds more complete file URI
parsing according to https://tools.ietf.org/html/rfc8089. In particular, the
file backend now recognizes URIs with authority field and ensures that
