Re: [vdr] vdr-1.6.0 and syncearly
Am 27.03.2008 um 21:01 schrieb Reinhard Nissl: > I'd say it's suggested. At least it is part of my H.264 patches. What does the sync early patch do? Ciao, Dominique ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Dominique Simon schrieb: >> I'd say it's suggested. At least it is part of my H.264 patches. > > What does the sync early patch do? Vanilla VDR waits for an I frame before it passes video (and audio) data on to output devices. Further more, audio data is still not passed on from that time, because VDR takes some time to decide which audio track shall get selected. The sync early patch addresses these issues. Audio and video packets are passed on a soon as they make up a valid frame. The result is that you can already hear the audio track before the video appears on screen. This is because video decoding can only start with an I frame. Any frames before the I frame won't appear on screen. But passing these frames to the output device has the benefit that PTS' (presentation time stamp) for these frames are passed on to the output device which needs this information to synchronize audio and video. As a result, audio and video will be in sync already when the first image appears on screen. That's why the patch got called "sync early". Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] DVB-S2 + H.264 support for VDR-1.5.18
Hi,
Reinhard Nissl schrieb:
attached you'll find updated patches for VDR-1.5.18.
The patch named *-dvbs2-* additionally adds DVB-S2 support to VDR
(based on VDR-1.5.14) and requires to use the DVB drivers
from the multi-proto tree (see URL below for further details).
The other patch is without DVB-S2 support and therefore most
suitable for DVB-C users.
VDR-1.5.14 reported changes to transponder data incorrectly. The
attached dvbs2 patch contains a fix for this issue by introducing
TransponderDataToString().
The patch includes now the formerly addon patch which fixed building
after recent multiproto changes.
The attached addon patch fixes a logic error in
cIteratorImplSourceNidTid. The error caused VDR to skip updating
transponder information for almost all channels.
The error is not related to DVB-S2 nor H.264 but slipped into
these patches at the time when I extended the patches to contain
formerly released speedup patches.
Have a look at this page for more instructions on this concern:
http://www.vdr-wiki.de/wiki/index.php/OpenSUSE_VDR_DVB-S2_-_xine
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.5.18-dvbs2-other/channels.c 2008-03-19 22:34:14.0 +0100
+++ channels.c 2008-04-01 19:28:45.0 +0200
@@ -1075,8 +1075,8 @@ cIterator cChannels::GetChanne
}
virtual void *First(void) { return FindMatchingChannel(false, true); }
virtual void *Last(void) { return FindMatchingChannel(true, true); }
-virtual void *Prev(void) { return FindMatchingChannel(false); }
-virtual void *Next(void) { return FindMatchingChannel(true); }
+virtual void *Prev(void) { return FindMatchingChannel(true); }
+virtual void *Next(void) { return FindMatchingChannel(false); }
virtual void *Current(void) const { return current ? (cChannel *)current->Object() : NULL; }
};
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
This kind of "problems" I had too.. When I report that playback is going faster than recording. I.e. you start recording and after awhile (maybe only 10 second) you start playback of that recording. Because playback is faster that "real life" you reach (in some poin of time) place where you are 0 (zero) seconds behind on going recording. AND in that point your playback start freeze and jump loop. -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
On Tue, Apr 1, 2008 at 7:44 AM, JJussi <[EMAIL PROTECTED]> wrote: > recording. Because playback is faster that "real life" you reach (in some > poin of time) place where you are 0 (zero) seconds behind on going recording. > AND in that point your playback start freeze and jump loop. Playback is faster then watching live tv?! Maybe if you skip past the commercials or something! I've started playing back a recording many times before it was finished and never had a problem with lockup or that the playback was going faster then live tv! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
