[FFmpeg-user] All the video captures are made at a resolution of 176x144
DiegoUG
diego.uribe.gamez at gmail.com
Wed Feb 28 01:25:40 EET 2018
I already achieved it after a little research, using this command:
ffmpeg -f video4linux2 -input_format h264 -video_size 1280x720 -i
/dev/video0 -vframes 1 -f mjpeg menu%d.jpg
ffmpeg version 3.4.1-1+b2 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7 (Debian 7.2.0-19)
configuration: --prefix=/usr --extra-version=1+b2 --toolchain=hardened
--libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu
--enable-gpl --disable-stripping --enable-avresample --enable-avisynth
--enable-gnutls --enable-ladspa --enable-libass --enable-libbluray
--enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite
--enable-libfontconfig --enable-libfreetype --enable-libfribidi
--enable-libgme --enable-libgsm --enable-libmp3lame --enable-libmysofa
--enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse
--enable-librubberband --enable-librsvg --enable-libshine
--enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh
--enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2
--enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx
--enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394
--enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r
--enable-libopencv --enable-libx264 --enable-shared
libavutil 55. 78.100 / 55. 78.100
libavcodec 57.107.100 / 57.107.100
libavformat 57. 83.100 / 57. 83.100
libavdevice 57. 10.100 / 57. 10.100
libavfilter 6.107.100 / 6.107.100
libavresample 3. 7. 0 / 3. 7. 0
libswscale 4. 8.100 / 4. 8.100
libswresample 2. 9.100 / 2. 9.100
libpostproc 54. 7.100 / 54. 7.100
Input #0, video4linux2,v4l2, from '/dev/video0':
Duration: N/A, start: 38421.120206, bitrate: N/A
Stream #0:0: Video: h264 (Constrained Baseline), yuvj420p(pc,
progressive), 1280x720 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 1000k tbn, 60 tbc
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> mjpeg (native))
Press [q] to stop, [?] for help
Output #0, mjpeg, to 'menu%d.jpg':
Metadata:
encoder : Lavf57.83.100
Stream #0:0: Video: mjpeg, yuvj420p(pc), 1280x720 [SAR 1:1 DAR 16:9],
q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc
Metadata:
encoder : Lavc57.107.100 mjpeg
Side data:
cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1
frame= 1 fps=0.0 q=3.8 Lsize= 24kB time=00:00:00.03
bitrate=5981.1kbits/s speed=0.464x
video:24kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.000000%
I do not understand very well what happened or how it works, but it
accomplishes what I need
2018-02-27 18:00 GMT-05:00 DiegoUG <diego.uribe.gamez at gmail.com>:
>
>
> 2018-02-27 8:58 GMT-05:00 Moritz Barsnick <barsnick at gmx.net>:
>
>> 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.
>>
>
> Yes Moritz Barsnick, one thing that can be seen in the commands that I
> place, where I show a list of the resolutions that the device supports in
> my localhost, detects that yuyv422 in my local takes the maximum resolution
> is 1280x720 but in the container it is 176x144 and the other curious thing
> is that inside the container appears another format that has the resolution
> of 1280x720, and that is that I do not have a deep knowledge of ffmpeg to
> use the mjpeg or h264 format and take the photo at the maximum resolution
> inside the container.
>
> Docker ------------------------------------------------------------
> -----------------------
> # ffmpeg -f v4l2 -list_formats all -i /dev/video0
> [...]
> [video4linux2,v4l2 @ 0x55e122701f60] Raw : yuyv422 :
> YUYV 4:2:2 : 160x90 160x120 176x144
> [video4linux2,v4l2 @ 0x55e122701f60] Compressed: h264 :
> H.264 : 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240
> 640x360 800x448 800x600 864x480 960x720 1024x576 1280x720
> [video4linux2,v4l2 @ 0x55e122701f60] Compressed: mjpeg :
> Motion-JPEG : 640x480 160x90 160x120 176x144 320x180 320x240 352x288
> 432x240 640x360
> ------------------------------------------------------------
> ---------------------------------
>
> local ------------------------------------------------------
> --------------------------------
> # ffmpeg -f v4l2 -list_formats all -i /dev/video0
>
> [...]
> [video4linux2,v4l2 @ 0x55b84fec19c0] Raw : yuyv422 :
> YUYV 4:2:2 : 640x480 320x180 320x240 352x288 424x240 640x360 848x480
> 960x540 1280x720
> [video4linux2,v4l2 @ 0x55b84fec19c0] Compressed: mjpeg :
> Motion-JPEG : 640x480 320x180 320x240 352x288 424x240 640x360 848x480
> 960x540 1280x720
>
> ------------------------------------------------------------
> ---------------------------------
>
>
>
>
>>
>> Moritz
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
>>
>
>
>
> --
> *Diego Alonso Uribe Gamez*
> ------------------------------
>
> *Desarrollador web*
>
> Twitter: @DiegoUG <http://www.twitter.com/DiegoUG>
>
> Google+: +DiegoAlonsoUribeGamez
> <https://plus.google.com/+DiegoAlonsoUribeGamez>
> ------------------------------
>
>
--
*Diego Alonso Uribe Gamez*
------------------------------
*Desarrollador web*
Twitter: @DiegoUG <http://www.twitter.com/DiegoUG>
Google+: +DiegoAlonsoUribeGamez
<https://plus.google.com/+DiegoAlonsoUribeGamez>
------------------------------
More information about the ffmpeg-user
mailing list