Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linuxtv-softmpeg] Re: VDR/softmpeg
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.
Home |
Main Index |
Thread Index