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 implementation that needs to catch > up.
You are wrong. There is one common interface: that is pseudi-URI. URI is not an option. > If an application passes a URI and expects that it is not interpreted as > such is already broken. And it always was. Breaking something that works is worse than having something that never worked still not work. > I could make a patch adding support for escape > sequences as well, but it seems you would not accept it. Am I correct? As is, "fixing" the file: protocol paths to be treated as URIs would be an API break, it is not acceptable. You can propose patches to make FFmpeg support real URIs instead / in addition to its old pseudo-URI syntax, but you would need to design with API compatibility in mind. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
