Date: Sun, 05 Oct 1997 14:53:40 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: multimedia@FreeBSD.ORG Cc: Randall Hopper <rhh@ct.picker.com> Subject: [video] frame rate and fxtv Message-ID: <199710052153.OAA00586@rah.star-gate.com>
next in thread | raw e-mail | index | archive | help
So far I have received the following information from brooktree and I
can't seem to get the set frame rate functionality to work properly
on single frames and with odd/even frames.
For now, I suggest that fxtv emulates the frame rate functionality by
specifying the full frame rate and skipping frames based upon the
desired frame rate for video capture.
Amancio
from brooktree:
> We received your inquiry about the Bt848 PCI-based decoder recently.
> For your reference, it is repeated below:
> >> A little while ago I wrote a Bt848 driver from scratch for FreeBSD
> a public domain unix system. The driver is very popular to be watching
> TV in a multi tasking operating system and the driver has been ported
> to BSDI and Linux.
> More to the point here, my last remaining problem has to deal with
> setting the frame rate:
> This is a comment from one of the developers:
> " The problem: despite the databook's description of how temporal
> decimation on frames is supposed to work (whole frames are masked as a
> unit for purposes of synchronization), it appears that the engine is
> masking out fields, or rotating the enablement of the fields based on
> the requested number of dropped frames. Anyway, I must be missing
> something. Could sure use a set of eyes with more bt experience."
> Also, I have a simple question , what is the behavior of the video
> engine when it decides to drop a frame? does it report uniquely that
> it has drop a frame as supposed to reporting that it has dropped a
> frame due to a pci error?
> This is the current code in the driver to set the frame rates:
> static void set_fps( bktr_ptr_t bktr, u_short fps ) {
> bt848_ptr_t bt848;
> struct format_params *fp;
> int i_flag;
> fp = &format_params[bktr->format_params];
> bt848 = bktr->base;
> switch(bktr->flags & METEOR_ONLY_FIELDS_MASK) {
> case METEOR_ONLY_EVEN_FIELDS:
> bktr->flags |= METEOR_WANT_EVEN;
> i_flag = 1;
> break;
> case METEOR_ONLY_ODD_FIELDS:
> bktr->flags |= METEOR_WANT_ODD;
> i_flag = 1;
> break;
> default:
> bktr->flags |= METEOR_WANT_MASK;
> i_flag = 2;
> break;
> }
> bt848->gpio_dma_ctl = FIFO_RISC_DISABLED;
> bt848->int_stat = ALL_INTS_CLEARED;
> bktr->fps = fps;
> bt848->tdec = 0;
> if (fps < fp->frame_rate)
> bt848->tdec = i_flag*(fp->frame_rate - fps) &
> 0x3f;
> else
> bt848->tdec = 0;
> return;
> }
> >>
> It seems as if you understanding of the Bt848's Temporal Decimation
> process
> is correct. FYI, this topic is discussed on pages 41, 42, 78-83, and
> 103 of the Bt848A datasheet.
> (See attached file: L848A_A.pdf)
> The Bt848 provides temporal decimation in either a field or a frame
> basis depending on what value is loaded into the TDEC register. This
> register is allowed to have a value from 1 to 60 for NTSC and 1 to 50
> for PAL and is located in the Local Register section, Memory Mapped
> location 0x08.
> The value inserted into this register is the number of fields or
> frames skipped by the Bt848 during a sequnce of 60 fields for NTSC or
> 50 fields for PAL. Skipped fields and frames will be considered
> inactive and this inactivity will de indicated by the ACTIVE pin(# 88
> - GPI/O 17) when the Bt848 is in the Digital Video-In Mode or the
> VACTIVE and HACTIVE pins(GPI/O 17 and GPI/O 21 respectively) when the
> Bt848 is in the SPI input and output modes.
> While the Bt848 is in normal operation, these pins will indicate
> whether a frame has been dropped by the TDEC register setting because
> each signal will stay low, indicatinmg that no active video
> information is bing bursted onto the PCI bus.
> I will have to check on the behavior of the Bt848 when it drops a
> frame or two unintentionally because of a PCI error. I will send you
> this answer when I find out myself.
> Please visit our ftp site. New documentation is available at: ftp://
> bt848:pcivideo@ftp.brooktree.com/bt848/
part 2 from brooktree:
> Amancio,
> Now that your up to speed on thein and outs of the Bt848's Temporal
> Decimation process, I want to address the PCI Error issue.
> I checked on the behavior of the Bt848 when it drops a frame or two
> unintentionally because of a PCI error or delay. This condition will
> be reported though a number of different registers and pins. The
> Command and Status Register(PCI Configuration Header register location
> 0x04) on page 97 of the Bt848A_A spec. explains that when a master
> transaction is terminated with a Master Abort or Target Abort,
> bit[29] and bit[28] respectively of this register will be set.
> Furthermore, the SERR/System Error output pin(#50)from the Bt848A will
> report an address parity error to external devices in the case of an
> address parity error.
> Also, if there is a long delay in Input Video, the PRES bit of the
> DSTATUS register will denote this condition.
> Finally, the INT_STAT register(Local Register Mapped Location 0x100)
> has several interrupt status bits which will denote different
> PCI-related and FIFO-related errors. Specifically, examine
> RISC_EN[bit 27], SCERR[bit 19], OCERR[bit 18], and bits 17-12.
> This closes my responses to you regarding this inquiry. If you have
> future questions regarding the Bt848 or other encoders or decoders we
> design and manufacture, please send your questions to
> did-apps@rss.rockwell.com. Thank you for your design efforts with the
> Bt848.
> I am stilll researching an answer for you on how to enable reading
> ACTIVE pin #88 in Digital Video In Mode. I caution you that if you
> choose to use this mode to take advantage of the Complementary ACTIVE
> output, then all 24 GPIO pins will be in this mode and assume their
> complementary pin assignments. You cannot have some be in NORMAL mode
> and other in an alternate mode.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710052153.OAA00586>