[FFmpeg-user] All the video captures are made at a resolution of 176x144

Moritz Barsnick barsnick at gmx.net
Tue Feb 27 15:58:50 EET 2018

On Mon, Feb 26, 2018 at 16:43:50 -0500, Lindsey Williams wrote:
> "-r 1 " is just going to use the input file sampling rate, no?

Input file? We are talking about an input device (as this is a camera),
and the term is "frame rate". "-r" should be "-framerate" for a v4l2
input, but "-r" works. It requests the driver to provide this
framerate. The original poster used this in their command line.

> "You need to check with V4L utilities or ffmpeg, which formats /
> resolutions your v4l2 device provides. I would guess that docker gives you
> only an abstraction (it's a kind of virtualization, right?)."
> Agree with that.  Cameras are getting smaller and smaller.... and in order
> to get away with that software is used on the the intake signal and
> unwrapped/decompressed into larger resolutions as it goes to our screens.

But physically, they provide a certain resolution via the wire. (Only
the cra**y Windows drivers or apps upscale automatically, fooling the
user into thinking there's a larger resolution, as printed on the box.
But we're talking Linux here - no such issue from
ffmpeg's/video4linux's point of view.)

> The reason I suggested scaling is because you didn't complain about the
> image not making sense... which means ffmpeg was able to decode the stream
> and encode it into some format ( maybe not the ideal one. )

No, the issue the original poster was complaining about was that the
camera delivers the desired resolution perfectly when accessing it from
the bare operating system. When operating from with a docker container
(some sort of virtualization) on the same machine, the device driver
only presents a lower resolution. My guess: Either the default is
different inside the docker, or the "virtualization" doesn't pass on
the camera's full feature set, for whatever reason.


More information about the ffmpeg-user mailing list