[linux-dvb] Re: VDR Playback not smooth ?

[Emil Naepflein <Emil.Naepflein@philosys.de>]

Sorry Klaus, this should go to the list only. :(

On Sat, 21 Apr 2001 23:13:29 +0200, Klaus Schmidinger
<Klaus.Schmidinger@cadsoft.de> wrote:

> The problem ist in the bad multiplexing of the data delivered from the driver.
> VDR merely stores what the driver delivers.

I don't agree fully with you here, because I found out that if you
increase buffersize the intervall between the stutter increases
correspondingly. In my opinion the reason for the problem is the buffer
code in VDR. During replay you have to feed the card constantly and fast
enough with frames. As I understood the buffering code the next data
from the file is read just then when you have to feed the data into the
driver. As reading may cause disk I/O and therefor additional delay, you
may not be able to feed the driver fast enough and cause the stutter. I
think the code has to be rewritten here into using threads for reading
and writing of files. The read thread has to constantly fill the input
buffer whenever some threshhold space is free, the write thread has to
write data to disk whenever there is some threshhold amount of data in
the buffer. This way the replay/recording threads which have to act in
real-time always can get/put data from/to the memory buffer. This causes
the illusion of infinitive fast buffer space which is very important in
real-time programming. This input and output threads can do additional
filtering to synchronize video/audio correctly. I have seen that you
have started already into this direction but have not finished yet. I am
pretty confident that this will at least reduce the stutter.

For me this buffering seems to be very important. When more and more
parallel disk acitvity is going on on the system they are a requirement
for smooth playback and recording. Yesterday I tried to run cutting
parallel to playback and sometimes the image just froze because of the
heavy disk activity. I had to kill cutting to get reasonable replay. I
have played around with hdparm parameters but couldn't fix it. Since I
have raid active the situation got worse. I noticed this already during
copying around of the data files during reconfiguration. If I have on
large copy with dd running, which gets me around 8 MB/s, the system is
very sluggish because of the high disk activity. The same is true during
cutting where the cutting rate is only limited by the disk speed. To
improve the responsivness here the cutting thread has to be limited to a
certain data rate and probably use lower cpu priority. And a improved
buffering should mask this at least from the normal user interface.

May be there is also a place in the DVB driver to increase buffering,
but I did't find the right place yet. For better control I would prefer
an improvement in VDR.

> 
> Marcus explained the reason in his posting
> 
>    http://linuxtv.org/mailinglists/linux-dvb/msg04460.html
> 
> Apparently the core problem is that audio packets arrive too late.
> According to his drawing titled "better PES" it should suffice to
> "simply" insert the audio packet earlier in the data stream, which
> means (part of) the video data would have to be held back until the
> next audio packet has arrived. However, I don't know if that's possible
> in the driver.

This problem may cause additional glitches.

> 
> The next version of VDR (based on the new API) will read the Transport
> Stream from /dev/ost/dvr and use code taken from 'tuxplayer' to store it as
> "multiplexed PES". But still, the result will only be as good as the data
> delivered by the driver...

That's true. But I think it also depends how fast you can read the data
from the driver. If you can write the data to a buffer thread the chance
of missing something is reduced to a minimum. And the buffer thread can
do additional (configurable) processing to improve the quality of the
stream.

At the moment I will refrain from changing anything here in the old VDR
version. But when the version for the new driver runs I will try to do
some tuning here. 

Emil 


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.