A/V out of sync for BSkyB channels Channel4, More4, E4, Film4

Message ID loom.20100718T160806-751@post.gmane.org
State New
Headers

Commit Message

Günter Merz July 18, 2010, 2:47 p.m. UTC
  I've found a solution to my longstanding problem: Video and audio being out of
sync on my vdr system using xine-lib as output display/control application.

Having excluded basically any other component, I started debugging xine-lib.

The first thing I've found was: When video and audio become out of sync,
metronome doesn't seem to get any audio pts anymore, they are always 0.

I checked the mpeg_pes demuxer but the audio pts were read from the stream
throughout.

The xine libmad adaptor seemed not to forward the pts to the metronome:
It buffers the MPEG audio packets until a threshold is reached (MAD_MIN_SIZE:
2889 bytes) and then has libmad decode the packets which is send to audio out.
The pts of the last audio packet is forwarded on to metronome which can then
sync video with audio.

For the channel4 channels MPEG audio packets have a size of 576 bytes which
means it takes five packets to fill the buffer enough for processing. In the
stream every fifth audio packet contains a pts.

The result of this is: If after a seek, the last audio packet is the one with
the pts, video and audio are in sync. If the pts is in any of the four previous
ones no pts will reach metronome and video and audio will never be synced before
a new seek and even then there's a one in five chance that video and audio are
not synced.

Other channels did not show this behaviour because e.g. BBC One has an audio
packet size of about 750 bytes and send a pts every fifth packet as well. This
means that not every pts from the stream gets through to metronome but some do.
This also means that syncing after a seek is probably not as quick as it could
be but it will sync.

My workaround to this problem is for the libmad xine adaptor (1.2 version) to
start decoding not only when a the buffer has reached a theshold but also when a
pts != 0 arrives. This does mean however that the buffer isn't always filled to
the theshold and decoding might not perform as well as it could (xine developers
are welcome to think of a better solution):


I hope this is helpful to other people.
  

Comments

Darren Salt July 19, 2010, 4 p.m. UTC | #1
I demand that Günter Merz may or may not have written...

> I've found a solution to my longstanding problem: Video and audio being out
> of sync on my vdr system using xine-lib as output display/control
> application.
[snip]
> --- src/libmad/xine_mad_decoder.c.old	2010-07-17 20:00:54.000000000 +0200
> +++ src/libmad/xine_mad_decoder.c	2010-07-17 20:02:10.000000000 +0200
[snip]
> I hope this is helpful to other people.

Probably. (Would be nice if you – and others – would Cc xine-lib patches to
xine-devel, or mention them in #xine.)

Anyway, I've (sometimes) seen sync problems with Channel 4 channels on
Freeview, though I rarely watch those channels; it's possible that both cause
and fix are the same. I've committed the patch locally (for now).
  
Darren Salt July 19, 2010, 6:46 p.m. UTC | #2
I demand that Tony Houghton may or may not have written...

> On Mon, 19 Jul 2010 17:00:12 +0100
> Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
>> Anyway, I've (sometimes) seen sync problems with Channel 4 channels on
>> Freeview, though I rarely watch those channels; it's possible that both
>> cause and fix are the same. I've committed the patch locally (for now).

> Were they old black & white films by any chance?

No.

> I've noticed sync problems on those and they could well have been ones I
> recorded from one of the C4 channels. But I usually record them from
> satellite rather than Freeview.

Well... if the patch fixes those problems...
  
Tony Houghton July 19, 2010, 7:07 p.m. UTC | #3
On Mon, 19 Jul 2010 17:00:12 +0100
Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:

> Anyway, I've (sometimes) seen sync problems with Channel 4 channels on
> Freeview, though I rarely watch those channels; it's possible that
> both cause and fix are the same. I've committed the patch locally
> (for now).

Were they old black & white films by any chance? I've noticed sync
problems on those and they could well have been ones I recorded from one
of the C4 channels. But I usually record them from satellite rather than
Freeview.
  
Günter Merz July 27, 2010, 7:56 a.m. UTC | #4
Darren Salt <linux <at> youmustbejoking.demon.co.uk> writes:

> Probably. (Would be nice if you – and others – would Cc xine-lib patches to
> xine-devel, or mention them in #xine.)

I shall do so in the future. I did a followup post including a link to this
thread in the xine bug-tracker (bug 325), however, the bug-tracker doesn't seem
very active.
  
Tony Houghton July 27, 2010, 1:35 p.m. UTC | #5
On Mon, 19 Jul 2010 19:46:00 +0100
Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:

> I demand that Tony Houghton may or may not have written...
> 
> > I've noticed sync problems on those and they could well have been
> > ones I recorded from one of the C4 channels. But I usually record
> > them from satellite rather than Freeview.
> 
> Well... if the patch fixes those problems...

It looks like it does. I had a recording of an old (but colour) film
from Film 4 where the sync was way out, but it's much improved with the
patch.

Can the patch (or similar fix) be included in the next Debian release of
libxine1? I had a lot of trouble satisfying its build dependencies on my
"unstable" system.
  
Darren Salt July 27, 2010, 5:11 p.m. UTC | #6
I demand that Tony Houghton may or may not have written...

> On Mon, 19 Jul 2010 19:46:00 +0100
> Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
>> I demand that Tony Houghton may or may not have written...
>>> I've noticed sync problems on those and they could well have been
>>> ones I recorded from one of the C4 channels. But I usually record
>>> them from satellite rather than Freeview.
>> Well... if the patch fixes those problems...

> It looks like it does. I had a recording of an old (but colour) film from
> Film 4 where the sync was way out, but it's much improved with the patch.

Looks like I guessed right when including the patch in 1.1.19, then. :-)

> Can the patch (or similar fix) be included in the next Debian release of
> libxine1?

No, but it could be in libxine1-bin. ;-)

> I had a lot of trouble satisfying its build dependencies on my
> "unstable" system.

No such trouble here, but then I always build from the repository or from
packaged source...
  
Tony Houghton July 27, 2010, 6:19 p.m. UTC | #7
On Tue, 27 Jul 2010 18:11:54 +0100
Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:

> > I had a lot of trouble satisfying its build dependencies on my
> > "unstable" system.
> 
> No such trouble here, but then I always build from the repository or
> from packaged source...

That's what I did, but it indirectly (mostly or all via libmagick I
think) depended on some packages that were only available in stable
which conflicted with newer versions of other things it depended on,
including lib packages which conflicted with their own dev packages.
  

Patch

--- src/libmad/xine_mad_decoder.c.old	2010-07-17 20:00:54.000000000 +0200
+++ src/libmad/xine_mad_decoder.c	2010-07-17 20:02:10.000000000 +0200
@@ -190,7 +190,7 @@ 
     mad_stream_buffer (&this->stream, this->buffer,
 		       this->bytes_in_buffer);
 
-    if (this->bytes_in_buffer < MAD_MIN_SIZE)
+    if (this->bytes_in_buffer < MAD_MIN_SIZE && buf->pts == 0)
       return;
 
     if (!this->needs_more_data) {