Hi,
I'm looking for help with my vdr 1.6 system.
I think the problem only affects BSkyB channels Channel4, More4, E4 and Film4: those channels a/v are out of sync (sometimes more, sometimes less). Recordings from those channels are also affected.
I think that at some point, I didn't have this a/v sync issue, but I could be wrong.
My vdr uses vdr-xine with a new xine-lib 1.2 (for vdpau) as output device.
Due to the unstable nature of some of the components, I've tried exchanging parts of my output chain to their stable counterparts: xine-lib 1.1.17, ffmpeg-0.5, xine-ui-0.99.5.
Also, I've tried deactivating "Dynamic Ticks" in the kernel.
None of those measures have helped.
Can anyone here point me to where the a/v sync issue is most likely to originate from?
Can it be vdr itself? Does vdr process video separate from audio?
From what I've read so far, xine-lib delegates MPEG TS
processing to ffmpeg.
Hi,
Günter Merz wrote:
I think the problem only affects BSkyB channels Channel4, More4, E4 and Film4: those channels a/v are out of sync
Yep, same for me also using the same VDPAU libraries, and only affects those channels. The sync can usually be fixed when watching a recording by skipping back a minute and/or pausing...
You are not alone ;)
Steve
Meanwhile, I've played back a vdr recording in xine (xine-ui) (the file itself, not through vdr) and can confirm the a/v sync problem is still there.
I played back the same recording with mplayer and the a/v sync problem seems to be gone---maybe with the small note that mplayer takes a few moments to adjust. This pretty much rules out vdr and vdr-xine as the source of the problem as well.
As far as I know, mplayer and ffmpeg use the same codebase (mostly).
From the above, I deduce that xine-lib or my configuration thereof produces the
a/v sync problem.
Can anyone confirm or contradict my thesis?
If it is in fact xine-lib that is the problem, does anyone know how to approach the problem?
Am 10.03.2010 11:53, Günter Merz wrote:
Meanwhile, I've played back a vdr recording in xine (xine-ui) (the file itself, not through vdr) and can confirm the a/v sync problem is still there.
I played back the same recording with mplayer and the a/v sync problem seems to be gone---maybe with the small note that mplayer takes a few moments to adjust. This pretty much rules out vdr and vdr-xine as the source of the problem as well.
As far as I know, mplayer and ffmpeg use the same codebase (mostly).
From the above, I deduce that xine-lib or my configuration thereof produces the
a/v sync problem.
Can anyone confirm or contradict my thesis?
I have seen the same problem on german channels - but not on all, and I found a common sense: - channels with MP2 audio: sync ok - channels with AC3-5.1: sync ok - channels with AC3-2.0: not always in sync, playing back and forth helps, there also seems to be a drift over time
I am using yavdr 0.1.1 (http://www.yavdr.de) which also includes XBMC which is not based on xine. I haven´t seen any sync problems here so far.
With kind regards
Joerg
2010/3/10 Jörg Knitter joerg.knitter@gmx.de:
I have seen the same problem on german channels - but not on all, and I found a common sense:
- channels with MP2 audio: sync ok
- channels with AC3-5.1: sync ok
- channels with AC3-2.0: not always in sync, playing back and forth helps,
there also seems to be a drift over time
I am using yavdr 0.1.1 (http://www.yavdr.de) which also includes XBMC which is not based on xine. I haven´t seen any sync problems here so far.
I watch Channel4 a lot and I don't have any issues with it using xineliboutput or my Reel HDe (read: it's not noticable). But if you could tell mee the German channels, I could check with those as well.
With kind regards
Joerg
Regards,
Niels Wagenaar
Am 10.03.2010 17:22, Niels Wagenaar wrote:
2010/3/10 Jörg Knitterjoerg.knitter@gmx.de:
I watch Channel4 a lot and I don't have any issues with it using xineliboutput or my Reel HDe (read: it's not noticable). But if you could tell mee the German channels, I could check with those as well.
Don´t know if it also happens with xineliboutput. In the tests before, I had major problems with xineliboutput, even with sound output, that´s why I am glad that the yavdr team choose xine over xineliboutput which worked better so far with my configuration.
I have had major problems with ProSieben, but I also could reproduce it with ZDF, ARD and RTL, simply every channel that has a DD 2.0 audio track. Switch the audio to MP2, and the sound will be instantly in sync in all of the mentioned channels.
With kind regards
Joerg
I watch Channel4 a lot and I don't have any issues with it using xineliboutput or my Reel HDe (read: it's not noticable). But if you could tell mee the German channels, I could check with those as well.
For me the frontend doesn't seem to make a difference: - vdr-xine/xine-ui - vdr-xine/gxine - xineliboutput show the same behaviour.
Can I ask which xine-lib version is behind your xineliboutput?
2010/3/12 Günter Merz lotan_rm@hotmail.com:
For me the frontend doesn't seem to make a difference:
- vdr-xine/xine-ui
- vdr-xine/gxine
- xineliboutput
show the same behaviour.
Can I ask which xine-lib version is behind your xineliboutput?
You may :) I use the regular xine-lib version from the VDR Team PPA (1.2.0+hg+vdpau+r285+crop+v11-1tvt6). The only thing I compiled by hand (using the vdr pre-patched sources from the VDR Team PPA), is the xineliboutput plugin. Since I wanted to use the latest CVS edition.
I only have an other issue now... But I'll reserve that for a new thread.
Regards,
Niels Wagenaar
I demand that Niels Wagenaar may or may not have written...
I use the regular xine-lib version from the VDR Team PPA (1.2.0+hg+vdpau+r285+crop+v11-1tvt6).
Hmm, looks a bit old. You might do better to grab the version in Debian experimental.
[snip]
Still having my problems with the BSkyB Channel4 family channels, I had a closer look at the PES streams, more specifically the different PES streams' packet timestamps relative to each other, in recordings using DVBSnoop.
It turned out that recordings of channels that xine can handle all the time (like the BBC channels) typically have a shift of 100 - 200 ms between audio stream packets (0xC0 or 0xC1) and the video stream packets (0xE0), whereas on the problematic channels (Channel4, ...) the typical shift between audio and video stream packets is between 400 - 800 ms.
Moreover, the shift between the less frequent stream 0xBD packets and the video stream (0xE0) packets for the BBC channels is minimal (around 100 ms) and for the problematic Channel4 family channels up to 1580 ms. Neither of those channels seem to feature a non-MP2 audio channel, therefore I presume that the 0xBD stream is for subpictures and should not be relevant in this issue.
From this analysis I have a few more questions regarding xine:
Is there a boundary (say 500 ms) after which xine cannot deal handle audio/video shifts in a PES anymore?
If so, can xine be configured to handle bigger shifts (different buffer settings)?
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):
--- 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) {
I hope this is helpful to other people.
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).
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.
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...
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.
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...
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.
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.
-
Darren Salt -
Günter Merz -
Jörg Knitter -
Niels Wagenaar -
Steve -
Tony Houghton