[FFmpeg-devel] [PATCH] Use v4l2 input format automatically if filename starts with "/dev/video"

[wm4]

On Sat, 25 Oct 2014 14:43:39 +0200
Nicolas George <george at nsup.org> wrote:

> 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.)

Then there's no sane way to handle this. Basically, you need to know:
yes, this is a video device.

> > 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.

Such a flag might probably work...

> 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.

The "lavfi" libavdevice demuxer already accepts arbitrary options from
URLs. All in all, I'd say ffmpeg is not optimized for security issues.
That libavdevice things require specifying the format explicitly
actually helps a little but. But in general, a flag that indicates that
an URL is e.g. from a playlist downloaded over http might be more
helpful for security.

Why can't the frame size be detected automatically?

> 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.
> 
> Regards,
>