[linuxtv-softmpeg] Re: VDR/softmpeg

[Michael Hunold <hunold@convergence.de>]

Hello Colin,

On 20.02.2004 16:05, ac2crp@blueyonder.co.uk wrote:
> I shall try the new OSD fix tonight. As you've made the change
> you can ignore my comments about getting per pixel alpha blending
> working! It's great this... as soon as I think I'll have to go and
> debug a problem you fix it! Thanks :-)

Currently I feel too ashamed of many parts of the code, so I better fix 
things before anybody notices... ;-)

> I didn't realise that the jerky VDR playback was caused by the data
> being sent too quickly.

Did I say that? The latest vdr-softmpeg plugin code should delay feeding 
the data, so that you get a smooth playback. The current code, however, 
probably introduces a high latency to keyboard events, because it 
unconditionally sleeps the time the decoder proposes (usually about 
200-400ms!).

> I was thinking that we could have an extra
> 'feed' thread that dripped data into the decoders as they asked for it,
> and limited the rate at which it took data. This would add an extra
> buffer into things though, which could get messy. I shall try to
> understand the code better and see if I can think of a way.

Transport stream playback uses a "pull" modell, ie. an extra thread is 
created and the data is pulled out of the dvr device as the deocder 
needs it.

VDR, however, uses a "push" model. I did not fully understand how vdr 
can be told that the data is coming in too fast. So, the current code 
checks the return value of the softmpeg function, which is essentially 
the time in milliseconds the softmpeg decoder wants the "pusher" to wait 
before providing any more data. It then simply delays execution using 
nanosleep() which is a bit hacky. VDR should be told that the execution 
should be delayed, so it can handle all things.

> I'm not sure however of the difficulty with pause. Surely it is
> sufficient just to stop sending data to libsoftmpeg, and it won't
> display anything. I can see that perhaps there might be a difficulty
> in resynchronising audio and video afterwards... is this the problem?

Hm, it shouldn't. But of course "pausing" only makes sense when you 
playback a recording, not when you watch live tv... ;-)

In theory, audio processing using FusionSound should be suspended, the 
video decoder thread should stop decoding data and the display thread 
should repeat the last decoded frame. When the user resumes, everything 
should play on smoothly from that point on.

Perhaps "libsoftmpeg" needs some kind of "type" informations, ie. if it 
should use a thread with the "poll" method or wait that it gets it's 
data "pushed", if it's playing back PES or TS data, if it's playing 
live-tv or a recording.

Using the pull model with live tv from a TS and then firing the "pause" 
function wouldn't be allowed then. There isn't a sane way that this can 
be handled: because of the fact that we simply read from the dvr device, 
but don't do anything else (ie. setting filters, buffering data), 
pausing would mean "throw away all data".

Perhaps even the basic DVB handling (ie. opening the dvr device and 
setting the right pes filters) should be handled inside libsoftmpeg as 
well. Or TS playback should be removed and only pes playback with the 
"push" model should be provided. Then it's entirely up to application to 
handle the complex things around "pause".

> Likewise, with trick modes. I believe that VDR only sends I frames during
>fast forward/rewind. I would believe therefore that what is needed is to
> have a 'turn AV sync off' switch so that no attempt is made to keep audio
> and video in sync. When this is the case, the I frames are displayed 
immediately
> as they are received. Again, there might be difficulty in 
resynchronising afterwards.

This is completely unsupported at the moment, the whole machine will 
simply go nuts. ;-) Don't even think about trying this out... ;-)

> As you've fixed the OSD I shall try to have a think about these issues.
> Thanks,
> Colin
CU
Michael.



--
Info:  To unsubscribe send a mail to ecartis@linuxtv.org with 
"unsubscribe linuxtv-softmpeg" as subject.