Re: video(1) -s size default overrides -r rate

[Laurence Tratt]

On Mon, Sep 21, 2020 at 05:44:17PM +0200, Jan Stary wrote:

Hello Jan,

> Presumably, as the default -s size is picked, and the camera cannot do 30
> fps in that size, -r 20 is chosen instead.
>
> If that's correct, the default size in effect overrides a specified rate.
> Is that intended?
>
> It doesn't seem to be the least surprise: the command line specifies the
> rate, and doesn't care about the size.
>
> Would it be preferable if video(1) chose -s 640x360 in that case, at 30
> fps, obeying the command line option?

IMHO, there's no way to not surprise users: users (naively, if reasonably)
want both big sizes and high frame rates, but that's generally impractical
for (uncompressed) YUY2. It *might* be more reasonable to throw an error if
everything specified can't be delivered.

However, there's a probably deeper point here. IMHO, video(1) isn't really a
sensible tool for viewing or recording video as it can't access a camera's
MJPEG mode (assuming the camera has one!) without ld tricks. In general, I
suggest that people use ffplay/ffmpeg (or something similar). Stefan Hagen
has been trying to put together an FAQ entry explaining webcam use on
OpenBSD [1].


Laurie

[1] https://marc.info/?l=openbsd-tech=160053691513681=2

video(1) -s size default overrides -r rate

[Jan Stary]

This is 6.8-beta/amd64 on a Thinkpad T400 (dmesg below)
using the following cheap USB camera/mic ("SriHome"):

uvideo0 at uhub7 port 1 configuration 1 interface 0 "webcam webcam" rev 
2.00/0.10 addr 2
video0 at uvideo0

$ video -q
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
640x360: 30, 25
640x480: 20
1280x720: 10
  controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature

By default, video(1) chooses -s 640x480:

$ video -v -O file.raw
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
640x360: 30, 25
640x480: 20
1280x720: 10
  controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature
Xv adaptor 0, GLAMOR Textured Video:
  encodings: yv12
  max size: 1280x800
using yuy2 encoding
using frame size 640x480 (614400 bytes)
using default frame rate
run time: 3.249037 seconds
frames grabbed: 50
frames played: 49
played fps: 14.773606


Now, when -r 30 is specified, this happens:

$ video -v -r-30--Offile.raw
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
640x360: 30, 25
640x480: 20
1280x720: 10
  controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature
Xv adaptor 0, GLAMOR Textured Video:
  encodings: yv12
  max size: 1280x800
using yuy2 encoding
using frame size 640x480 (614400 bytes)
using frame rate 20 fps
run time: 4.714163 seconds
frames grabbed: 72
frames played: 71
played fps: 14.848870

Presumably, as the default -s size is picked,
and the camera cannot do 30 fps in that size,
-r 20 is chosen instead.

If that's correct, the default size
in effect overrides a specified rate.
Is that intended?

It doesn't seem to be the least surprise:
the command line specifies the rate,
and doesn't care about the size.

Would it be preferable if video(1) chose
-s 640x360 in that case, at 30 fps,
obeying the command line option?


When the smaller size is specified explicitly,
the paramaters are obeyed:

$ video -v -r 30 -s 640x360 -O file.raw
video device /dev/video:
  encodings: yuy2
  frame sizes (width x height, in pixels) and rates (in frames per second):
640x360: 30, 25
640x480: 20
1280x720: 10
  controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature
Xv adaptor 0, GLAMOR Textured Video:
  encodings: yv12
  max size: 1280x800
using yuy2 encoding
using frame size 640x360 (460800 bytes)
using frame rate 30 fps
run time: 6.172711 seconds
frames grabbed: 187
frames played: 172
played fps: 27.702576

(The same happens with -r 25,
also supported for 640x360, but not for 640x480.)

Jan


OpenBSD 6.8-beta (GENERIC.MP) #0: Fri Sep 18 11:00:33 CEST 2020
h...@lenovo.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8463781888 (8071MB)
avail mem = 8192229376 (7812MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (80 entries)
bios0: vendor LENOVO version "7UET94WW (3.24 )" date 10/17/2012
bios0: LENOVO 64741EG
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 798.17 MHz, 06-17-06
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 266MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU P8400 @ 2.26GHz, 798.01 MHz, 06-17-06
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus