Re: [vdr] [ANNOUNCE] VDR developer version 1.7.15 / fix HD subtitles on arte HD

2010-07-18 Thread Reinhard Nissl
Hi,

Am 06.06.2010 14:49, schrieb Klaus Schmidinger:

> - Implemented handling of HD resolution subtitles according to v1.3.1 of
>   ETSI EN 300 743, chapter 7.2.1 (thanks to Rolf Ahrenberg).

The attached patch fixes DDS detection on arte HD.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rni...@gmx.de
--- ../vdr-1.7.15-orig/dvbsubtitle.c	2010-06-05 16:03:55.0 +0200
+++ dvbsubtitle.c	2010-07-18 21:29:50.0 +0200
@@ -660,7 +660,7 @@ cDvbSubtitleConverter::cDvbSubtitleConve
   dvbSubtitleAssembler = new cDvbSubtitleAssembler;
   osd = NULL;
   frozen = false;
-  ddsVersionNumber = 0;
+  ddsVersionNumber = -1;
   displayWidth = 720;
   displayHeight = 576;
   displayHorizontalOffset = 0;
@@ -693,7 +693,7 @@ void cDvbSubtitleConverter::Reset(void)
   bitmaps->Clear();
   DELETENULL(osd);
   frozen = false;
-  ddsVersionNumber = 0;
+  ddsVersionNumber = -1;
   displayWidth = 720;
   displayHeight = 576;
   displayHorizontalOffset = 0;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] A/V out of sync for BSkyB channels Channel4, More4, E4, Film4

2010-07-18 Thread Günter Merz
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.0 +0200
+++ src/libmad/xine_mad_decoder.c   2010-07-17 20:02:10.0 +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.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] How to properly attach stream to live view?

2010-07-18 Thread Udo Richter
Hi list, hi Klaus,

In continuation of this old topic [1] and the bug ticket [2]:

I've written a patch that changes handling of receivers in VDR. The
patch makes sure that receivers of priority of -1 won't block a device,
without re-introducing the Live TV Freeze [3] bug.

Details of this issue are very well documented in [2], patches are also
available there.


In short, -1 receivers are supposed to be disconnectable at any time,
but transfer mode runs at -1 priority too, and should not be
disconnected. Transfer mode runs at -1 so that an existing transfer mode
does not block channel switching. The solution is to let the channel
switch code know that the transfer source device will soon be available.


Cheers,

Udo

[1] http://www.linuxtv.org/pipermail/vdr/2008-June/017073.html
[2] http://projects.vdr-developer.org/issues/show/10
[3] http://linuxtv.org/mailinglists/vdr/2004/05-2004/msg00115.html

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr