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...
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
