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

[wm4]

On Sat, 25 Oct 2014 13:50:58 +0200
Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:

> On Sat, Oct 25, 2014 at 01:40:11PM +0200, wm4 wrote:
> > On Sat, 25 Oct 2014 13:14:26 +0200
> > Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> > > wm4, if you have a simple way of doing this check, please explain it.
> > > Otherwise I think EXTENSION score is good enough to signal "well, we
> > > guess that's what it is".
> > 
> > There are two solutions:
> > - actually open the video device, and try a v4l-only ioctl() to test
> >   whether it's really a device (the artificial separation between
> >   avio/probing/actual opening becomes rather annoying here)
> 
> 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.
> I guess it's not unreasonable if done in addition, but on the other
> hand, is this likely to ever increase user experience in reality?

Well, yes, this is a weakness of the current probing architecture. Code
written from scratch could just always open() local filenames, and then
test whether it's actually a video device or a normal file. (One thing
on the side: there's this special utility lib, that requires you to
call v4l2_open() instead of open(), but you can also just use open()
and then v4l2_open_fd() in the v4l-specific code.)

> > - add a specific protocol prefix that forces the input format, and which
> >   lets the user invoke video capture (think MPlayer's "tv://")
> > 
> > All in all, there's much you can do about raw devices. A video device
> > probably doesn't even need to be named /dev/video..., nor does that
> > filename need to be a reliable indicator that the device understand
> > V4L. Whatever you do, it can't be perfect, because you're working on a
> > too low level and system specific layer. "tv://" could solve that
> > actually rather elegantly, including abstracting platform differences
> > from the user.
> 
> I admittedly just assumed that v4l2:///dev/video/... would work
> currently. If not, that sounds like something that can and should
> be fixed.
> However as a convenience feature, I think it is good that /dev/video
> just ends up picking the v4l2 input, because in almost all cases
> that would be the desired behaviour.

As a user, I wouldn't really expect that this works. Rather, I'd assume
I'd have to do something special to get the program to use video.
With current ffmpeg, you have to specify _both_ the "special
thing" (the demuxer) _and_ the video device, which is a bit of a WTF.
As I said, using a special protocol (like tv://) would be a nice
alternative, which can also include automatically selecting the video
device (for the right platform!), but maybe I'm spoiled by the MPlayer
way of doing things.

> It should be possible to override the other way via file:///dev/video/... I believe?
> If I am wrong about any of that, that would probably change my opinion.
> 
> And I probably should leave this discussion to someone with a clue about
> this part of the code.
> 
> Regards,
> Reimar