In the case when the driver captures both fields of a frame the temporal decimation register is incorrectly set. This leads to a wrong resulting frame rate. The register is set to drop frames not fields (by setting bit 7 to zero). Therefor the number of dropped items need not to be multiplied by 2 for the case when both fields are captured for a frame. The chip itself takes care for dropping both fields of the dropped frame. As a sidenote: (2) Bktr fails to compile if BT848_DUMP is defined. Fix: Apply the following patch. This corrects both problems: How-To-Repeat: Use an application that captures full size PAL and request a frame of 12 fps from the driver. Observe the frame rate dropping to 1 fps. This is due the computation in bktr_core.c:set_fps(). When both WANT flags are 1 (capturing both fields) the difference between the maximum frame rate (25 for PAL) and the requested frame rate (12) is multiplied by two falsely assuming, that the register must contain the number of fields to drop. This yields a value of 24 and the chip drops 24 out of 25 frames resulting in a frame rate of 1. (2) Define BT848_DUMP and observe the compile to fail.
Responsible Changed From-To: freebsd-bugs->roger Over to bktr maintainer.
Responsible Changed From-To: roger->freebsd-bugs Assignee is currently away from doing FreeBSD work at the moment, so at his request, return this one to the pool.
A commit references this bug: Author: jpaetzel Date: Tue Jun 27 03:45:09 UTC 2017 New revision: 320393 URL: https://svnweb.freebsd.org/changeset/base/320393 Log: driver incorrectly handles the setting of frame rates PR: 36415 Submitted by: brandt@fokus.gmd.de Changes: head/sys/dev/bktr/bktr_core.c
15 years later....