On Sun, Jan 12, 2014 at 7:20 PM, Ed Beroset <[email protected]> wrote: > I could, but perhaps it's a moot point. When I use "vlc > v4l2c:///dev/video:input=2" it works perfectly. When I use "vlc > v4l2:///dev/video:input=2" (which is what I'd been attempting up until your > message) I get the same errors as listed in ticket 10258. > > So, I'm happy that a solution seems to be at hand, but vlc only showed me > v4l2:// devices under the heading "Capture Devices" and I did not know of > the existence of v4l2c:// devices until just now (and don't know what they > are.) Thank you for bridging the gap for me -- what can we do to help the > next person encountering this problem?
The root of the issue is that the V4L2 spec had some ambiguity, so until very recently devices did a really bad job of advertising whether they were providing compressed video or raw uncompressed video (the issue was particularly bad in cases where a given device could provide both). The use of "v4l2c://" explicitly tells VLC that the PVR-150 is providing compressed video, which is why it works for you. If you instead tell it "v4l2://" then you're telling VLC that the device provides uncompressed video, which the PVR-150 doesn't support - that's why you're getting the error. Presumably drivers do a better job advertising what they support nowadays (primarily as a result of work Hans Verkuil did over the last year or so), so VLC should probably be changed such that specifying "v4l2://" causes it to ask the driver whether the video is compressed, and handle it accordingly. Then in the longer term the "v4l2c://" method would be deprecated entirely. Even there you probably want to add some sort of option to allow the caller to specify which to use when a device supports both, since there are advantages to each approach depending on what you're ultimately doing with the video. For example, if you're streaming it over a network then compressed is the better choice - unless you want to stream it in H.264, in which case you're better doing uncompressed so that you avoid the cost of decompressing the stream before re-encoding it to H.264. Long story short, none of this is really a problem with the IVTV driver, and if you want to see VLC's logic improved then it would probably makes sense to start a new thread over on the vlc-devel mailing list. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
