[FFmpeg-devel] [PATCH] Use v4l2 input format automatically if filename starts with "/dev/video"
george at nsup.org
Sat Oct 25 14:43:39 CEST 2014
Le quartidi 4 brumaire, an CCXXIII, Reimar Döffinger a écrit :
> That would end up trying a v4l ioctl on each and every file that
> FFmpeg tries to open (unless you mean only after the /dev/video check,
> but that would not solve the issue you mention later).
> That feels a bit heavy-weight.
That would not be heavy-weight, that would be outright irresponsible:
ioctl() opcodes are not globally unique. An opcode that maps to a harmless
probe on v4l devices can trigger catastrophic consequences on other devices.
(Remember 2003, when installing Mandrake 9.2 would brick LG CD drives? That
was the same issue, but our case is worse because what Mandrake did was
actually supposed to work reliably if LG had not messed their firmware.)
(If your conclusion is that the ioctl() interface is braindead, I am right
there with you, but that is something we have to live with.)
> I admittedly just assumed that v4l2:///dev/video/... would work
> currently. If not, that sounds like something that can and should
> be fixed.
Well, "foo:" prefixes are normally reserved for protocols. We could add to
that "or formats with the NOFILE flag", that would probably make things
better. Or if we are afraid to trigger untested corner cases, have a
dedicated new flag AVFMT_PROTO_PREFIX or something.
But if we start going in that direction, why stop there? Why should
v4l2:/dev/video0 work and not rawvideo:/dev/zero? And if that last one
works, how do I specify the frame dimensions?
That brings back the discussion on whether to accept options from the file
name. You objected based on security considerations, but I still think that
a dedicated function doing clean and reliable parsing would be useful for a
lot of cases.
At the very least, the limit on what options to accept from the file name
should be decided by a proper discussion based on security and usability
considerations, not by what patches are pushed before the usual bikeshedders
(I'm #1) got up in the morning.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel