FF card AV sync problems, possible fix to VDR (fwd)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Kartsa wrote:

> So I would like to raise this one up again. After applying the two
> changes (dsyslog("TS continuity error (%d)", ccCounter) and { *FrameSize
> = 0; dsyslog("cAudioRepacker: FrameSize == 0"); } in remux.c) I still
> get these lines in log (and -l 3 in vdr startup)
> 
> vdr: [3600] cAudioRepacker(0xC0): skipped 232 bytes to sync on next
> audio frame
> vdr: [3600] cAudioRepacker(0xC0): skipped 240 bytes to sync on next
> audio frame
> vdr: [3600] cAudioRepacker(0xC0): skipped 492 bytes while syncing on
> next audio frame
> 
> Why does these skipping of bytes appear?

When do you get these lines?

They are OK just after starting a recording or starting transfer mode.

cAudioRepacker tries to suppress this message while initially syncing
but as the sync pattern is allowed to appear as audio frame data, it is
likely that cAudioRepacker get's in sync by mistake.

After having synced, cAudioRepacker uses the indicated frame length as a
guide when looking for the next audio packet. If the sync pattern isn't
found at the guided position, it will seek for it and report the number
of bytes skipped to find it.

This procedure is executed all over the time and once cAudioRepacker has
found a real sync pattern, the indicated frame length will guide
cAudioRepacker precisely to the next audio frame.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux