On Sunday 04 December 2005 17:33, Kevin Atkinson wrote:
> Hans Verkuil wrote:
> > On Sunday 04 December 2005 17:02, Kevin Atkinson wrote:
> >>Hans Verkuil wrote:
> >>>On Sunday 04 December 2005 00:58, Kevin Atkinson wrote:
> >>
> >>I have not studied the code in detail, but here is my guess on what
> >>is going wrong.
> >>
> >>My guess is that it is due to the encoder. You start getting VBI
> >>data immenetly but there is a short (1-2 seconds) delay before you
> >>start getting MPEG data, so you drop the some VBI packets. This
> >>causes the VBI data to be displayed 1-2 seconds early since the VBI
> >>data is real time while the MPEG data is delayed. The correct
> >> action would be to delay the VBI packets instead of dropping them.
> >> Does this make sense, and are my assumptions correct?
> >
> > Yes, it makes sense, I just cannot prove or fix it from PAL
> > country.
>
> Could you give me some idea of what I need to do to fix it? The more
> specific the better.
The prefered option is to try and match VBI PTS timestamps with
timestamps in the MPEG stream. Also see my previous email with pointers
to some firmware commands that might be able to help with that.
If this does not work, then it might be possible to time the delay
between the arrival of the first VBI packet and the first MPEG data and
use that as the delay time.
It is not going to be a simple quick fix. But I'd say that the first
step is to see if you can match the PTS value from the VBI packet with
a timestamp in the MPEG file. I did look once but I couldn't find it,
but I don't have good tools to look into the MPEG file either.
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
