On Sat, 25 Oct 2014 13:50:58 +0200 Reimar Döffinger <reimar.doeffin...@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.doeffin...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel