Le maanantaina 5. joulukuuta 2022, 4.51.34 EET zhilizhao(赵志立) a écrit : > > On Nov 19, 2022, at 02:48, Zhao Zhili <quinkbl...@foxmail.com> wrote: > > > > From: Zhao Zhili <zhiliz...@tencent.com> > > > > Unlike the pipe protocol, fd protocol has seek support if it > > corresponding to a regular file. > > --- > > Sometimes it's the only way to access files via file descriptor, e.g., > > requesting a shared file on Android: > > https://developer.android.com/training/secure-file-sharing/request-file > > > > doc/protocols.texi | 24 +++++++++++++++++++ > > libavformat/Makefile | 1 + > > libavformat/file.c | 51 +++++++++++++++++++++++++++++++++++++++++ > > libavformat/protocols.c | 1 + > > libavformat/version.h | 4 ++-- > > 5 files changed, 79 insertions(+), 2 deletions(-) > > Ping for review.
VLC does this (with a slightly different syntax, i.e. fd://$NUM) and in hindsight, I think that it was a big mistake. It should not be possible to refer to an opaque handle from within the URL. This leads to all sorts of mischief, bordering on security issue, in the common case that the URL string is untrusted. To support this use case, IMO, the file descriptor should be passed explicitly via a trusted channel, *not* the URL. -- Реми Дёни-Курмон http://www.remlab.net/ _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
