Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linuxtv-softmpeg] Re: Improvements in EPIA-M softdevice?



On Thu, 15 Apr 2004 ac2crp@blueyonder.co.uk wrote:

> Hmmm. I wonder if that's something to do with the double buffering of
>the framebuffer and video. That stuff is all handled by DirectFB - and
> the chip does the alpha blending between the video and framebuffer.

Well, it hasn't done that flickering after that.. So don't bother about
it. :)

> Did it survive even with the MPEG bugs? I put in some debug - like
> 'VIDEO BUFFER FULL' and stuff - that shows conditions where the normal
> softmpeg code would have segfaulted. If it survives those... even
> better!

It survives anything. It has never segfaulted. The picture might look
awful at times but it still keeps going. :)

> The d_cle266.c file is something that I'm not proud of :-( I agree
> that the problem occurs only during I frames.

Yes. It's sometimes worse than just frame skip.. Sometimes it shows a
garbled frame there, just full screen of garbage. Next frame is fine
again. So every 12th frame is garbage, others are fine.

This probably has something to do with channel bitrate.. There are some
channels that show just solid test screen most of the day, and that test
screen has that garbage bug nearly always. When there is real programme,
the bug changes to the frame skip version. :)

> libsoftmpeg passes a whole frame's worth of video to the decoder.
> However, the parser that I'm using looks for the next frame start
> code. It therefore doesn't return 'ready' indicating a complete
> decoded frame until it receives the next frame's start code.

Ah, I see the problem.. Hmm. Perhaps you should buffer one frame, and
delay playback so you always are one frame behind?

> libsoftmpeg also needs to know when a frame is an I frame in order to
> get correct AV sync.

Hmm, this of course has to be changed if video is delayed.. I'm not sure,
but perhaps it enough if you report the I-frame one frame too late (or too
early, hmm).. Then libsoftmpeg would have to delay the audio as well.

> segfaulted so often. I might try deleting the installed DirectFB and
> fusion sound etc in case I have some header mismatch. I thought I'd
> tried that, but I perhaps haven't recompiled everything.

Yes.. Must be something like that, because it really works very stable
here.. A lot more stable than original libsoftmpeg.

> I've copied this mail to the libsoftmpeg mailing list in case anyone
> else is interested.

Yeah, I replied only here. :)

--
Teemu
http://zuik.org/



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



Home | Main Index | Thread Index