[vdr] Re: VDR 1.3.12 buffer optimizations - SOLVED!

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Reinhard Nissl wrote:
> 
> Hi,
> 
> Klaus Schmidinger wrote:
> 
> > Note that right now the Transfer Mode is a little "jerky" at the beginning,
> 
> That's absolutely true and it makes vdr-xine almost unuseable (a huge
> prebuffer of 4 seconds seems to be a workaround most of the time). But I
> currently have no idea whats wrong nor do I know how to improve the situation.

I already have a few ideas how to improve things in Transfer Mode (some
provided by Marco Schlüßler) and will see that I can come up with an
improved version one of the next days.

> Strange is that I get buffer overflows although PlayVideo() was never called
> to deliver this data. The logfile entries below were created like that: when
> VDR calls PlayVideo() the first time after SetPlayMode(1) I write a "." on
> console which tells me that "soft start" begins. When this "." appears I
> manually switch on to the next channel.
> 
> So the sequence was like that:
> 
>         20.21.22.23.24.25[no dot]26.27.

Looks like the TM's ring buffer is written to too soon.
I'll take care of this in an improved version.

> Another issue concerns dolby audio: has there anything changed in breaking
> down those packets into smaller ones? I ask because a lot of FIXMEs are
> triggered in my code that deal with packet reassembly.

The only difference I can think of is that up to now cRemux::Process() has
only retruned _one_ PES packet per call, while now cRemuxGet() returns all
the PES packets that are currently available (for better throughput).

If you need the old behaviour I could add a flag to cRemux::Get() that
makes it return only a single PES packet at a time.

> ...
> > Also, I'd like to hear whether this patch actually improves things for _your_
> > systems, too.
> 
> I cannot see a big improvement as the most CPU intensive job is decoding and
> displaying the MPEG stream. But it seems that Astra HD plays a bit more
> fluently than before.

The difference is mainly visible when doing several parallel recordings.
I can tell that this has been vastly improved :-)

Klaus