Hi Deb,
When testing this I was wondering why the sequence counter didn't detect dropped
frames (which happens when you start/stop a vbi stream while streaming video).
On 02/05/2023 05:27, Deborah Brouwer wrote:
> -static void bttv_field_count(struct bttv *btv)
> -{
> - int need_count = 0;
> -
> - if (btv->users)
> - need_count++;
> -
> - if (need_count) {
> - /* start field counter */
> - btor(BT848_INT_VSYNC,BT848_INT_MASK);
> - } else {
> - /* stop field counter */
> - btand(~BT848_INT_VSYNC,BT848_INT_MASK);
> - btv->field_count = 0;
> - }
> -}
This is the root cause: this function is used to turn on VSYNC interrupts
and in the interrupt handler the field_count is incremented.
In the vb1 version of this driver this field_count is passed on to vb1, which
uses it to set the sequence counter to field_count / 2.
By removing this function the VSYNC irq is never enabled and so field_count is
always 0. So I think in bttv the seqnr field should be dropped and the field_count
mechanism re-instated.
Comparing the number of dropped frames when starting/stopping vbi it looks like
in both cases (vb1 and vb2) one frame is dropped when starting vbi. But when
stopping vbi no frames are dropped in the vb1 case, but 3 in the vb2 case.
Another thing I discovered is that for PAL the vcr_hack control has to be enabled,
otherwise the video is full of glitches. This was present before your series, and
happens even with a video signal from a proper PAL video generator, so this is really
strange. I can't remember that I needed this in the past, but it has been years
since I last tested it.
PAL capture is fine for Top/Bottom/Alternate settings, it only fails for Interlaced
and Sequential Top/Bottom capture modes.
When I have more time I will dig into this a bit more.
Regards,
Hans
