On Sunday 04 December 2005 18:07, Kevin Atkinson wrote:
> Hans Verkuil wrote:
> > 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.
>
> How about simply using a buffer to hold on to the VBI packets until
> the first MPEG data arrives...

That's what is happening now. But it may be that the VBI packets are 
inserted at a higher than expected rate into the MPEG stream (e.g. 
instead of 30 frames per second they are inserted twice as fast), so 
that the initial correct delay is quickly reduced to 0. This shouldn't 
be too difficult to check. And if true, then it isn't too difficult to 
fix.

        Hans

>
> > 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.
>
> If it is going to involve a lot of work I am unlikely to have the
> time to do it.  However, I am willing to try things....

_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel

Reply via email to